At the bottom, you’re in the syntax. The commas, the brackets, the precise implementation of a function. It’s the craft of making code work.

One rung up, you’re designing functions and classes within a domain. You understand patterns, you write clean code, you make good local decisions.

Higher still, you start seeing dependencies. How different modules interact. How changes in one part ripple through another. You stop thinking in files and start thinking in systems.

Then comes full mastery of an application. Everything in it, every quirk, every critical dependency it relies on. The people at this level are the ones who can debug anything in their domain because they hold the whole picture in their head.

Keep climbing and the view expands beyond one app. You understand the landscape; how multiple systems depend on each other, how they serve business logic, where the data flows. These are the rare engineers who can parachute into any fire and instantly pinpoint what went wrong.

Near the top, it turns into strategy. You’re mapping not just technology but organizational dynamics. Incentives, accountabilities, competing priorities between departments. And you’re thinking in time; how decisions made today create lock-in, technical debt, or opportunity years from now.

At the very top, you’re thinking in markets. Competitors, business models, how the entire enterprise stack serves or undermines strategic positioning.

Here’s what makes this ladder exhausting: you never stop needing the lower rungs. A CTO still needs to drop into syntax sometimes. But the context switch between strategy and semicolons is brutal. The wider the gap you have to jump, the more it drains you.

The engineers who thrive won’t be the ones who write the best code. They’ll be the ones who can hold the most rungs in their head at once.

We used to think in a single mode. Desktop apps were designed for a mouse. Click buttons, drag sliders, navigate menus. Photoshop is the extreme version of this; hundreds of tiny buttons, panels everywhere, built for precision pointing. Then over the last few years we’ve seen a de-cluttering of those buttons. The command bar popped up, reachable via cmd+K in apps like Notion, Linear, Raycast. Allowing you to type in the tool you’d need.

Then we have mobile. Entirely different in terms of interaction. A touch is different from a click. Buttons got bigger. Interfaces got simpler. Gestures like swiping, pinching, pulling became intuitive and expected. Though maybe tablets made it a bit weird. An iPad with a keyboard and trackpad behaves like a laptop. Flip the keyboard off and it’s a giant phone. The same device, two completely different interaction models.

But here’s where it gets interesting. The oldest interface is making a comeback.

The command line interface. The original computer interface, before everything went graphical, is growing again. AI coding assistants live in the terminal. Apps like Obsidian and Google Workspace have announced first-party CLI support, in order to be operable by AI agents. This developer-first workflow is increasingly text-command-first. And it’s not just for developers anymore. Apps are exposing programmatic interfaces to a much wider audience.

APIs have been the backbone of B2B software for years. CommerceTools, the commerce engine, is API-first by design. It doesn’t even pretend to be a complete application, it’s a platform developers build on top of. Notion opened up full read-write access through its API. Now MCP servers (Model Context Protocol) add another layer. They’re essentially abstraction layers on top of REST or GraphQL APIs, designed specifically for AI agents to interact with applications. Your app doesn’t just serve humans anymore. It serves other software.

The apps that are going to win are the ones that support all of these modes simultaneously.

Linear gets this right. It’s keyboard-first for power users. It has a beautiful click-based GUI for everyone else. It works on mobile with touch. It has a CLI. It has an API. It has MCP support. Every type of user, every type of device, every type of interaction covered.

That’s the new bar. Not just a great UI. A great interface. Plural.

Traditional SaaS has a beautiful cost structure. You invest heavily in development; build the product, ship it, maintain it. But serving users is almost free. A few servers, some bandwidth, done. Whether you have a thousand users or a million, the marginal cost per user is tiny. That’s why SaaS companies can charge $10 a month and make enormous margins at scale.

LLMs flip this on its head.

Development costs are massive, not just building the model, but training it, which requires obscene amounts of compute. Then, unlike SaaS, every single user interaction costs money. Every query, every token, every response. The operational cost doesn’t flatten at scale. It grows with usage.

And here’s the cultural problem: we’ve been trained to expect fixed pricing for online software. A flat monthly fee, use it as much as you want. Netflix, Spotify, Notion, unlimited usage for a predictable price.

LLMs can’t deliver that without losing money on heavy users. The math doesn’t work. The distribution of usage is wildly uneven, a small percentage of users consume a disproportionate amount of tokens, racking up costs that the subscription fee doesn’t cover.

OpenAI is trapped in this. They need platform pricing expectations (flat, predictable) but have infrastructure cost structures (variable, per-use). And this isn’t just an OpenAI problem. It’s a structural challenge for the entire industry. Until someone figures out how to make per-token costs negligible, or finds a pricing model users will accept, the LLM business model remains a very expensive bet.

Apps are becoming public property. At least, that’s how it feels to users.

When Sonos launched their redesigned app, people hated it. Features disappeared. Familiar UI patterns changed. Something they used every day was suddenly alien. The Dutch public broadcaster did the sam, moved from a decent app to a horrible one. Both companies said the same thing: “It took courage. We needed a stable foundation for the future.”

Users didn’t care about foundations. They cared that their thing was broken.

This raises two problems nobody talks about honestly.

The first is technical. We like to say software can be molded over time. Iterate, improve, ship. But sometimes a codebase is so far gone that a complete rebuild is the only option. And rebuilding means starting from scratch. Which means losing features. Achieving feature parity with the old version is brutally hard and expensive, especially when the old version accumulated years of small additions that nobody documented properly.

The second is cultural. Designers get bored. Engineers want to work on new things. A product that’s been stable for years feels stale to the people building it, even if users love it. I suspect the Sonos redesign wasn’t driven purely by technical necessity. Someone wanted to make something new. The problem is that “new” for the builder means “broken” for the user.

And underneath both problems sits a deeper truth: as a user you never really own your software.

Every app you depend on can change overnight. An update you didn’t ask for can remove the feature you relied on most. You have no say, no vote, no recourse. You’re at the whims of whoever controls the update cycle.

That’s the feature parity problem. Not just the technical challenge of rebuilding without losing functionality. But the uncomfortable reality that the software you shape your life around doesn’t actually belong to you.

Building an internal tool is getting trivially easy. Keeping it running reliably is not. Uptime, monitoring, bug triage, incident response, that’s where the real pain lives. And most small businesses can’t justify a full-time devops hire for their handful of custom tools.

Here’s what I think should exist: an AI devops engineer monitoring your platform 24/7.

Not a dashboard. Not an alerting system. An actual reasoning agent that catches bugs, analyzes root causes, and creates pull requests to fix them. One that has very clear, very strict permissions, so you always know your data won’t be touched. One that escalates intelligently, only waking you up at 3 AM when it genuinely matters.

An AI engineer you can yell at the next morning when it turns out the midnight alert was a stupid typo. One that apologizes, learns, and adjusts its threshold.

But it goes deeper than firefighting. The real value is in the long view. An AI devops engineer that tracks bugs over time, spots structural patterns, and brainstorms with you: why wasn’t this caught in testing? Why does this endpoint keep failing? What architectural weakness keeps producing the same category of incident?

Self-healing systems are the dream. Bugs automatically caught, analyzed, fixed. But even short of that dream, there’s enormous value in a tireless, always-on engineer that handles the grunt work of keeping software alive.

That’s a startup waiting to be built.

Not the concept, the bar. The bar has moved so far that what used to be “viable” now feels embarrassing.

Users are spoiled. And they should be. They use beautifully designed apps every day. Smooth animations. Instant responsiveness. Features that just work. Their reference point isn’t your competitor’s MVP, it’s the best app on their phone.

Launch something half-baked and they’ll push right through it. One clunky interaction, one missing feature, one loading spinner too many, gone. They’re not coming back to check your next release.

We still have frameworks that make building fast. But meeting modern expectations is harder than ever. Users expect polish from day one. They expect the feature set of a mature product from your beta. They expect speed, reliability, and design quality that used to take years to achieve.

The irony: building is cheaper and faster than ever, but the bar for “good enough” has never been higher.

The MVP was designed for an era where shipping something imperfect was acceptable because users had patience and alternatives were scarce. Neither is true anymore.

Trump needed things dumbed down, everyone laughed.

But here’s the thing nobody admits: simplification is an incredibly valuable skill. And almost nobody can do it well.

The trick isn’t making things short. It’s making things simple without losing the essence. Crafting a story that can be followed instantly. Where every part is understood on its own. Where the pieces build toward a conclusion that stands on its own weight.

That requires two things most people don’t have simultaneously.

First, you need to deeply understand your material. You can’t simplify what you don’t fully grasp. The physicist who explains quantum mechanics in plain language understands it better than the one who hides behind jargon. Simplification isn’t dumbing down, it’s distilling.

Second, you need to understand your audience. What they already know. What they care about. What metaphors will land. What level of abstraction they can comfortably hold in their head.

Most experts fail at this. They know their domain inside out but can’t explain it to anyone outside their bubble. They mistake complexity for rigor. They confuse “thorough” with “clear.”

The people who can take something genuinely complex and make it genuinely simple, without losing the truth of it, are rare. And valuable. In any field.

Type one: building the models. This is the original ‘AI engineering’. The field formerly known as machine learning, data science, sometimes operations research. Deep research, deep statistics, data pipelines. These engineers build the foundational algorithms; a recommendation engine trained on purchasing patterns, a large language model consumed via API. It’s science-heavy, math-heavy, and requires understanding things most software engineers never touch.

Type two: engineering with AI as a tool. This is traditional software engineering, but with AI supercharging the craft. The systems are still deterministic; same input, same output. The engineer uses Claude Code, GitHub Copilot, or ChatGPT the way a previous generation used Stack Overflow. The skill here is judgment. Knowing when the AI’s suggestion is good and when it’s garbage. Managing a team of agents. Keeping code quality high when generating of code is cheap.

Type three: building products with AI inside them. This is the new discipline. Prompt engineering, token optimization, context management, cost control. The art of embedding a stochastic system, one that gives different outputs for the same input, inside a deterministic application. You’re introducing unpredictability into a system designed for predictability. That’s a fundamentally different engineering challenge.

We got good at this. Really good.

We learned where the rubber hits the road, where deterministic systems meet the chaotic real world. Where humans click buttons they shouldn’t, enter data incorrectly, or unintentionally bypass the system in ways nobody anticipated.

So we built fault-tolerant systems. Systems designed to handle the unexpected gracefully. Input validation. Error boundaries. Fallback states. An entire engineering discipline built around the principle: the system is predictable, the world isn’t, and we need to bridge that gap.

And where users and the physical world (a physical hard-drive failing for example) used to be the chaotic actors in those systems, we are now adding a third catogory; Large Language Models.

LLMs are fundamentally different.

They are stochastic systems. Systems where the same input can produce different outputs. Not because something went wrong, but by design. The randomness is the feature.

Stochastic systems, from the Greek word “stokhastikos”, meaning “skilled in aiming”.

This breaks everything we know about testing, debugging, and reliability. You can’t reproduce a bug in a stochastic system the way you can in a deterministic one. You can’t write a test that guarantees a specific output. The system doesn’t have “correct” behavior in the traditional sense, it has a probability distribution of behaviors.

We spent decades mastering deterministic systems. Now we’re building products that embed their opposite. Stochastic components inside deterministic shells. Unpredictability wrapped in predictability.

That’s not just an engineering challenge. It’s a philosophical shift in how we think about software.

I saw a lot of hype about AI. A lot of promise. And a lot of misunderstanding. Talk to any software engineer and they will tell you AI is (still) shit). Yet LLMs captured the imagination, in particular of non-technical people. The [imagination](https://incontext.digital/p/the-two-platform-shifts-and-why-ai) of abstract thinkers, strategical thinkers. The executives.

Dreaming of automatically making stuff, without having to learn any code. Of automating anything. Of rapid prototyping. Halving the cost of digital expenses. The end of SaaS lock-in, and the end of being locked in by those annoying vague and expensive software engineers and development agencies you depend on to run your digital business.

Yet LLMs are flatlining in what extra benefits they give us. Microsoft is in AI trouble, OpenAI has code red, and thanks to Google Nvidia no longer has the monopoly on LLM capable chips. So much investment has been built on this imagination that it is interesting to see if we will end up in an AI bubble in 2026.

But in terms of ‘regular business’ I believe we will see a return to normal in 2026. Of the ‘AI will replace jobs’ hype dying down a little. Of development agencies taking over work, and us continuing as we have always done.

LLMs will go the route of 3D printing. Revolutionary and a gateway technology for sure, but probably one mostly for the ‘backend’ of technology and business. Gradual progress.

But what about audio design? Audio in product design is usually a byproduct. The sound of a bluetooth speaker upon connecting. Or the sound of an app notification.

But I think audio might just play a more and more crucial role as a computer interface. We have Siri, Gemini, AI note takers joining our meetings. We are rumored to be getting an audio assistant from OpenAI later this year.

It looks like audio might become a second sense, next to the visual screens we are used to interfacing with. Which begs the question; what about audio design? How ought a computer to sound? And how ought those sounds mix with other sounds? The environment we use our computers in, the music that is on simultaneously while working, the meeting going on at the same time? Audio literally joining the conversation also requires a thoughtful audio footprint, that blends well into its environment.

The discipline of sound design, up till now mostly associated with sounds of media and video (like games, movies) might offer an interesting foundation to build upon. But I’ll be on the lookout for the first audio design vacancies, and audio design as a discipline taking off this year.

The core of the weirdness I believe is this; predictability.

Click any “AI Assistant” button and you’re rolling the dice. Will it rewrite your entire document? Suggest a single word change? Completely misunderstand what you wanted? Nobody knows.

This breaks something fundamental about interface design.

Good UI design is about removing anxiety. When you see a red “Delete” button, you know exactly what happens next. The trash icon means trash. The save button saves. Users build mental models based on consistent, predictable behavior.

AI throws all of that out the window.

Every AI prompt is a black box. You type something in, cross your fingers, and hope the algorithm interprets your intent correctly. Sometimes it nails it. Sometimes it does something completely random. Sometimes it just fails silently.

We’ve created interfaces where the primary interaction is guessing.

This isn’t just bad UX—it’s the opposite of what interfaces should do. Instead of reducing cognitive load, AI features often increase it. Users could easily spend more mental energy trying to craft the perfect prompt than they would just doing the task manually.

Most “copilot” features feel like they were added because everyone else has one, not because they actually improve the user experience. They’re checkbox features. Marketing bullets. Not tools that genuinely help people get work done.

The best AI implementations hide their complexity. They work predictably, even if the underlying technology is probabilistic. They feel like magic, not gambling.

But those are rare.

Most copilots are just expensive guessing games dressed up as innovation.

That’s the real innovation. Not the size of the models or the training data, it’s that they understand natural language the way we actually use it. Messy, contextual, full of exceptions.

You can tell ChatGPT “make it more professional but keep the casual tone” and it gets it. Try programming that instruction into traditional software. You’d spend months defining what “professional” means, building taxonomies for “casual,” creating exception handlers for edge cases.

But here’s the problem: that natural flexibility crashes into digital reality.

Digital systems are fundamentally rigid. Databases need structured fields. APIs expect specific formats. Workflows demand binary decisions. Yes or no, approved or rejected, category A or category B.

The world isn’t binary. It’s fluid.

When you tell an LLM “this customer is frustrated but loyal,” it understands the nuance. When you try to put that same customer into your CRM, you’re forced to pick: frustrated OR loyal. The system can’t handle both. It can’t capture the contradiction that makes the insight valuable.

This creates a translation problem that didn’t exist before.

Pre-LLM, we accepted that software was clunky. We learned its language. Dropdown menus, mandatory fields, rigid categories. We bent our thinking to fit the system.

Now LLMs show us what natural interaction feels like. We can think out loud, change our minds mid-sentence, reference context from three conversations ago. The AI gets it.

But then we hit the wall. The LLM understands perfectly, but it still has to cram that understanding into the same rigid systems we’ve always had.

The innovation of natural language interface is real. But it exposes just how fundamentally broken our digital infrastructure is for handling the way humans actually think and work.

We’re not just building better AI. We’re discovering that everything else needs to be rebuilt too.

As technologists, we’re obsessed with non-linear work. Automation. Exponential curves. Making everything faster, more efficient, infinitely scalable.

But here’s what we miss: some work will always be linear.

When my water pipes need replacing, it’s still four people working for a day. A digging machine might speed things up a bit, but it’s fundamentally the same job. One day of work.

Having coffee with a colleague? An hour. Something that can’t be accelerated. Something you wouldn’t want to accelerate.

There’s a hard limit to what can be digitized.

Digital is purely administrative. It facilitates. It connects. But it doesn’t replace the core work that actually matters; the human work, the physical work.

Think about it: why do we even need all this digital infrastructure? What’s the real core of digital technology?

Connection, maybe. But even that has limits.

We keep trying to optimize everything, to make everything non-linear and scalable. But the most meaningful work remains stubbornly linear. Building something with your hands, solving a real problem for a real person, having an actual conversation.

And that’s not a bug. It’s a feature.

So why is mobile absolutely terrible at text?

Think about it: when you need to write anything substantial, you reach for a laptop. Mobile keyboards are cramped, autocorrect is aggressive and wrong, and thumb-typing longer messages feels like punishment. We’ve optimized the world’s most personal computing device for everything except the interface that’s supposed to define our digital future.

Voice was meant to solve this. For decades, we’ve been promised that speaking to our devices would free us from keyboards. Apple launched Siri in 2011. Amazon’s Alexa arrived in 2014. Google’s been pushing voice for even longer.

But voice input still sucks.

It’s not private — you can’t dictate a sensitive email on the train. It’s error-prone — try explaining technical concepts to voice recognition. And it’s surprisingly low bandwidth. Reading is faster than listening. Typing (when you have a real keyboard) is faster than speaking. We all hate voice messages because they waste our time.

This creates a fundamental tension in computing. The interfaces we’re now building assume text input. But the devices we carry make text input painful. Voice hasn’t bridged that gap and likely won’t anytime soon.

Maybe this points to something bigger: the future isn’t actually text-first. Maybe text interfaces are just a bridge—a way to interact with AI until something better emerges. Or maybe we’re heading toward a world where serious work happens on devices with real keyboards, while mobile becomes purely consumptive.

Either way, the contradiction is real. And it suggests our assumptions about the “text UI future” might need rethinking.

But here’s my frustration; these tools often end up running the business.

Companies bend themselves around ERP systems. They hire expensive consultants to jam their processes into rigid data models. They spend months of expensive consulting work adapting workflows to fit software that was built for someone else’s idea of how your business should work.

This architecture (and, let’s be frank, the ERP business model) make ERP expensive and inflexible. Worse still, because those ERPs run on architectures from the 90s, they can never adapt ever to anything modern, without once again going through a very painful migration process.

Rigid ERP makes employees hate their jobs. Or at least their computers. Think about the software you use personally - your phone, your apps. They adapt to you. They learn your patterns, get out of your way. Now think about the software you use at work. It feels like a punishment. Forms with mandatory fields, workflows that make no sense. Interfaces that look like they’re straight out of 2004. No wonder doctors hate their computers. Most have simply given up hope

A new type of ERP

Here’s a different approach; build ERP systems that adapt to businesses, not the other way around. The architecture would mirror Notion - a core foundation where you can define you own database, objects and properties. Everything pluggable. Every bit of customisation you want can be easily build. With plugins and API calls that do not break the core system.

This would open up three powerful possibilities:

Maintainable modern UI. The core team can evolve the interface with current design standards. Think design systems that feel coherent and modern while letting users build their own workflows. Software that bends, not breaks.

AI-generated plugins. When the plugin API is simple and well-documented, generative AI can create custom extensions on demand. Need a specific workflow? Generate it. Business process changes? Adapt it instantly.

Malleable data structures. Like Notion’s graph of objects, the data model evolves as your business evolves. No expensive consultants. No code changes. Anyone can adjust the structure as processes and insights develop.

The result? ERP that doesn’t feel restrictive—it feels empowering.

What this enables

Small, specialised development teams could build hyper-personalized ERP systems for local businesses. Developers and designers working directly with users, building and continuously adjusting tools that actually fit.

Small businesses could finally afford the same quality tooling as large enterprises. No more choosing between expensive, bloated systems and doing everything in spreadsheets.

The real opportunity isn’t just better software. It’s flipping the relationship between businesses and their tools.

Instead of businesses serving their software, software finally serves businesses.

What he meant was this. When design gets murky, when you get stuck in your head, return to the person. The actual human with the actual problem. Solve for that. Nothing else. Everything else follows.

This is the cornerstone of good design, of course. We know that. This is not new. But it is good to be reminded every now and again; what truly makes a designer

What does all of that mean? I believe it is a response to a changing landscape, but only for those firms. Nothin substantial is going to change in venture capital. Here’s my logic;

These firms are jumping on the AI bandwagon, making a strategic choice to be more hands-on. They see a big opportunity in making vertical AI companies. And are willing to make a big bet. These VCs are equipping themselves not just to fund, but to help forge these businesses. Be more hands-on. And that means restructuring their setup.

For founders, this suggests a changing dialogue: an opportunity for capital that comes with deeper, more operational collaboration. It points towards a future where investors are more like co-builders in the long craft of creating sustainable, category-defining companies. This is less a revolution, more a considered evolution in the art of venture.

There is an opportunity in that tension.

Companies are caught between two realities. Their employees expect AI tools that actually help; smart assistants, automated workflows, intelligent data analysis. But their legal teams won’t let corporate secrets flow through third-party APIs.

The solution isn’t to give up on AI. It’s to bring AI in-house.

Three paths to private AI

The cloud-hosted approach. Rent private GPU clusters from providers like Hetzner or Fly.io. You get dedicated hardware in a data center, but it’s still managed infrastructure. Pay monthly, scale as needed, upgrade without buying new boxes. This feels like the sweet spot for most businesses right now—private enough for lawyers, flexible enough for rapid AI development.

The on-premise service model. Buy or rent actual hardware that sits in your office. Think a stack of Mac Studios wired together, but with a maintenance contract. It’s like the old IBM model from the 1950s—you get the hardware and the expertise to keep it running. Complete control, zero data leaving your building.

The prebuilt cluster approach. Sell businesses a complete package—computers, GPUs, software, all pre-configured. Plug it in and start training models. No IT department headaches, no linking machines together, no wondering if your setup actually works.

What makes this work

The real opportunity isn’t just selling hardware. It’s making private AI actually usable.

Most businesses can’t hire AI engineers. But they might have one or two developers who could fine-tune models if the platform made it simple enough. That’s the key; build developer tools so good that tweaking AI models becomes easy, a competitive advantage, not a technical nightmare.

And businesses need proof their data stays safe. Complete telemetry. Zero data loss guarantees. Show them exactly what’s happening to their information.

Why now

Smaller AI models keep getting better. What required massive server farms last year now runs on expensive-but-manageable local hardware. The gap between cloud AI and on-premise AI is shrinking fast.

Meanwhile, the business case gets stronger every month. Companies see AI boosting productivity but hate the privacy trade-offs. They want both benefits—and they’re willing to pay for infrastructure that delivers them.

The businesses that figure out private AI first will have a serious edge. And someone needs to build the infrastructure to make that possible.

They’ve grown steadily—20% annually in recent years—but they haven’t had their podcast moment. That explosive, culture-shifting breakthrough where everyone suddenly gets it.

The bottleneck has always been narration.

Most audiobooks sound flat. Lifeless. Text written to be read silently gets read aloud by someone who treats every sentence the same. No rhythm. No emphasis. No soul.

The good narrators—the ones who bring personality and energy—create hits. But hiring them is expensive. Recording is expensive. Direction is expensive. Publishers pick their battles. And also, no clear business model to get that investment back. For the most part, audiobooks are still meant to be bought as a whole, rather simply streamed like a podcast or a song.

This creates a vicious cycle. High production costs mean high prices. High prices mean listeners hesitate to try new books. Limited audience means limited budgets for good narration.

But I’m hopeful there is two factors that are changing this completely.

First is business model. We’re used to paying for Spotify, and Spotify would like you to spend more time in their app. They are rolling out support for audiobooks; giving users an incentive to simply try a book, and publishers an incentive to stream books and get paid for them. It also allows publishers, like podcasters, to ad-support their books; adding another revenue model to their business. Users are now more used to audio from podcast, I’m hopeful audiobooks will catch on as well.

Second change is the promise of genAI. Which could change the narration game completely. Paradoxically, AI could replace the robotic (albeit human) voices of audiobooks we have today, with much more intonation. Making bland text a lot more fun to listen to. That means that every book suddenly can have engaging narration and the cost drops from thousands of dollars. Publishers are more free to experiment. And that means listeners can browse freely without the $15-per-book commitment anxiety.

This isn’t just about making audiobooks cheaper. It’s about making them discoverable. Let’s give audiobooks their moment to shine