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.

This is what maturity looks like. Not the headlines from a decade ago promising a printer in every home. Not the democratization of manufacturing we were told was coming. Just a major company quietly using 3D printing because it’s the best tool for a specific job.

What we’re talking about

Let me back up. 3D printing builds objects layer by layer from digital files. Unlike traditional manufacturing that cuts away material (like machining) or pours it into molds (like injection molding), 3D printing adds material only where it’s needed. Think of it like a very precise glue gun that follows computer instructions.

The technology has been around since the 1980s for industrial prototyping. But around 2010, key patents expired, prices dropped, and suddenly desktop versions became available. That’s when things got interesting. And overhyped.

The 2015 peak

As a student of industrial design engineering, I was deep into 3D printing around 2015. I spent countless hours with these machines, and I wasn’t alone. That year marked the peak of inflated expectations. The narrative was simple: soon, everyone would design and print their own products at home. Need a phone case? Print it. Want custom kitchenware? Print it. Broken part? Just print a replacement.

CES 2015 was the high-water mark. 3D Systems brought Will.i.am on stage as their Chief Creative Officer. Companies showcased chocolate printers and ultra-cheap resin machines. The tech press declared we’d all own 3D printers as commonly as microwaves.

What actually happened? Most of those consumer-focused companies stumbled or pivoted. MakerBot, which had led the consumer charge since 2009, struggled with quality issues and eventually shifted focus. The home 3D printer revolution never arrived.

But something more interesting happened instead.

Where it actually works

The iPhone Air port isn’t an isolated case. McLaren’s Formula 1 team now produces over 9,000 parts per year using 3D printing. Wind tunnel models, aerodynamic components, even tooling for carbon fiber layup. They’ve cut production time for certain large parts from weeks to three days. When you’re racing and every second counts, that speed matters more than any cost savings.

This is rapid prototyping at its finest. Need to test five different wing designs before the next race? Print them all this week. Traditional machining or molding would take months and cost far more.

For one-off designs and low-volume manufacturing, 3D printing has proven itself reliable. Medical devices, custom aerospace components, specialized industrial parts, these aren’t gimmicks. They’re production-ready applications where the technology genuinely shines.

I believe this represents 3D printing’s actual strength: not replacing traditional manufacturing, but filling specific gaps where traditional methods are too slow, too expensive, or geometrically impossible.

The consumer reality check

Walk around Etsy today and you’ll find a thriving ecosystem of makers selling 3D-printed products. Custom phone stands, articulated dragons, board game organizers, plant markers. Some sellers have built real businesses here. But most people don’t have a printer at home. And if they do, they print little plaything gadgets.

We’re far from the original promise. Remember the vision? You’d browse a marketplace like Nike’s, pick a shoe design, input your exact foot measurements for a perfect fit, customize the colors and support structure for your running style, and print that unique pair at home overnight. Your shoes, designed for your feet, impossible to manufacture any other way.

Why is that? Because there are still so many layers of work in-between thinking of an idea, and making it. You need to articulate your idea, measure it, CAD design it, mechanically design it, and manage to print it.

And also, that is really not the point I think of 3D printing. More pragmatically, 3D is another manufacturing technology, slowly becoming also a viable one. To create unique complicated to manufacture components.

Where we’re now instead is much more industrial, and much more practical. Apple using 3D printing to make a thinner port. McLaren using it to iterate faster. Medical companies using it to custom-fit devices. These are real improvements, just not the radical transformations we were promised.

Not democratization, but another tool

The 3D printing revolution was about the democratization of manufacturing. It has become a tool in the arsenal of manufacturing techniques we have available. Like injection molding for high-volume plastic parts. Like CNC milling for precise metal components. Like casting for complex shapes. Each has its place.

3D printing’s place? One-off designs, rapid prototyping, low-volume manufacturing, and geometries that would be difficult or impossible with other methods. That’s valuable. That’s worth the decades of development. It’s just not the revolution we imagined.

The GenAI Question

The biggest question facing 3D printing now is whether generative AI will finally bridge that barrier between idea and object.

Can AI tools make it as simple as describing what you want in plain English and getting a printable file? Some early experiments suggest yes. But I’m curious more than convinced. The gap between “AI can generate a rough 3D model” and “AI can generate a structurally sound, printable, functional object with proper tolerances” is significant.

If genAI does crack this problem, if it becomes as easy to create a custom 3D object as it is to generate an image with DALL-E, then maybe we’ll see a second wave of consumer 3D printing. A more realistic one, focused on truly custom objects that make sense to print rather than everything.

For now, I’m watching. The technology for making things is getting simpler. The software layer is the remaining bottleneck. Whether AI solves that remains to be seen.

What I take from this

Ten years after the hype peak, 3D printing has found its place. It’s in Apple’s manufacturing process. It’s on McLaren’s pit wall. It’s in medical device companies and aerospace manufacturers. It’s on Etsy shops run by makers who learned the tools and found profitable niches.

It’s not in most homes. It probably never will be, at least not as a general-purpose manufacturing tool. And I think we’re better off for having realistic expectations.

The lesson, for me, isn’t about 3D printing specifically. It’s about how new manufacturing technologies actually get adopted. They don’t replace everything that came before. They find specific problems they solve better than existing tools. They mature slowly. They integrate quietly into supply chains and workflows. And then one day, without much fanfare, they’re making the USB-C port in your phone.

Cloud is the iron beneath our software. The servers, hard drives, and network cables that physically deliver the bits and bytes that keep our businesses running. To consumers cloud is vaguely known as that magical infinite storage bucket for photos and Netflix content, yet for almost all businesses nowadays, cloud is also a critical piece of infrastructure to keep things running. Business processes, customer support, websites, apps, and what not.

This infrastructure works much like our roads and highways. A system of not just roads, but also gas stations, parking lots. A system of servers, storage, networking, CPUs and GPUs. And just like highways, cloud infrastructure requires enormous investment to build and maintain.

For years, we became used to the idea of a handful of US tech giants dominating this infrastructure. They had first-mover advantage. They had scale. They had capital. The strategy was simple: bigger, better, faster. More data centers. More regions. More services. Build infrastructure everywhere so any app can scale instantly anywhere on the planet. And Europe fell behind. It tried to respond through regulation. GDPR, data protection, sovereignty requirements. Important, but not at all sexy. A stick to threaten with, not a carrot.

Enter Lidl. A discount grocery chain.

Lidl’s gamble

In 2018, Schwarz Group, the company that owns Lidl and Kaufland, faced a decision about their cloud infrastructure. They were managing 575,000 employees across 13,700 stores in 33 countries. Mountains of operational data. Customer loyalty programs. Supply chain logistics. Employee records.

The obvious move was AWS, Azure, or Google Cloud. Instead, they decided to build their own.

Why? Partly because US cloud providers operate under US law, creating genuine legal exposure for European companies under GDPR. But also because at their scale, the business case for owning infrastructure made sense. Only a company the size and complexity of Schwarz Group could justify that investment.

They built StackIT. And it worked. And a year ago, in September 2024, they spun it out as a commercial cloud provider, taking a leaf out of Amazon’s 2007 playbook that ultimately let to AWS.

And here’s the thing: it’s working.

SAP signed up. Bayern Munich signed up. The Port of Hamburg signed up. These aren’t startups looking for cheap hosting. These are major organizations choosing StackIT over the US hyperscalers. Amazon also noticed, and responded with a € 7.8 billion investment in “AWS European Sovereign Cloud”.

Now the question isn’t whether this is working (it clearly is). The question is how and what does it mean?

The business case shift

The hardware and software powering the datacenter operations has seen a dramatic leap in commoditisation. Price of ever powerful servers and harddrive storage has continued to come down. And software like OpenStack to manage this hardware has emerged as a reliable backbone for cloud providers.

That shift has changed the business case for data centres. Yes they still require massive amounts of investment, and massive amounts of operational costs. But the numbers are no longer insurmountable, in order to provide a reliable service. That has made it possible for Lidl to build the business case to invest and build StackIT.

And that sheds light on a different strategic consideration; is bigger always better?

Is bigger always better?

StackIT operates data centres only in Germany and Austria (for now). That is a big difference to the Amazon’s and Google’s of the world, selling ‘edge computing’ (servers globally available, instantly serving customers close by).

If you’re a German bank, a Dutch healthcare provider, or a French government agency; do you actually need data centres in Singapore, Sydney and São Paulo? I think not.

Most European businesses serve primarily European customers. Global distribution is not a feature. It is irrelevant complexity. And that just might turn out to be one of the hyperscaler’s Achilles’ heels. All that cloud scalability brings complexity.

StackIT strikes me as being more down to earth. Asking what do businesses actually need? And since cloud as a concept has become a sort of no-brainer for businesses, the actual requirements for it are also clear. Data in Europe. Full GDPR compliance. Reliable performance. Fair pricing. Good developer tooling. And maybe most importantly; no vendor lock-in. That means that a business with a no-nonsense, down-to-earth value proposition, would actually stand a good chance.

The European pattern

StackIT fits a broader pattern I’ve been noticing.

I see certain European technology companies succeeding by flying completely under the radar. Hetzner, the German hosting company with a developer cult following. Proton Mail, the Swiss email service becoming a serious Gmail alternative. OVH and Scaleway in France. Dozens of European VPS providers. These companies share a philosophy: deliver good service at fair prices. Largely skip the marketing theater (I mean, just look at their websites).

This is a distinctly un-Silicon Valley approach. And I think it just might work for European customers. More down-to-earthness. And it looks to me StackIT is this philosophy at enterprise scale.

StackIT didn’t emerge because some founder had a vision. It emerged because a company faced a real problem (where do we put our data?), built a solution methodically, and realized others had the same problem. And StackIT didn’t succeed because of European regulation. Its value proposition on its own is strong enough. GDPR is just a helping hand in pushing customers to look for European alternatives.

This might be how European innovation actually works: slower to emerge, less hyped, solving genuine problems with sustainable models when real need meets real opportunity.

What I’m watching for

I’m watching whether this represents the beginning of a European cloud resurgence. A rethinking of what we actually need from our servers. And potentially a shift away from the traditional cloud platforms with their lock-in services. A simplification, and re-embracing of good old European servers. Whether running on VPS (virtual private servers), or on larger (EU) cloud providers like StackIT.

And I’m curious to see what other European companies might follow this playbook. What other foundational tech has changed to shift the business cases around. And what other tech can be productised by European businesses, to serve other European businesses.

And I’m watching whether we’re seeing a return to practical, down-to-earth business thinking more broadly. Less “change the world” aspiration, more “solve real problems well at fair prices.”

• Mastery used to be about skill and taste matching up, the slow repetitive practice to build up skills

• AI allows a higher volume of iterations, thus making ‘meta skills’ of editing and recognising value a lot more important, becoming more like a film director than a solo craftsperson.

• That tools enables speed, but success depends on intentional engagement, using iterations to shape thinking iteratively, rather than lazy copy-pasting.

What does it mean to be a master of something? To be a great programmer, designer, or writer? The path to mastery has always been the path of 10,000 hours. But what does that really mean? I believe that path is about iterating, making something, seeing how it's not quite right, and making tiny adjustments toward the next version. An almost unconscious process of getting better through repetition.

And what happens when AI tools enter that picture? I believe AI tools are changing, *expanding* what we mean by mastery and craftsmanship. They're challenging what we think of as 'getting good at something.'

When friction was the teacher

What does it mean to get good at a skill? To develop a craft? Getting good used to require helpful friction. The process where the process is ‘expensive’, and thus makes you invested in the outcome. Think of a photographer having to manually develop pictures. All that work for a single picture, makes you really understand all the nuances of skill required to get it, and makes you invested in the outcome. There is an incentive to optimize the process, to develop the skills. That slow process is a teacher.

Ira Glass talked about this famously too; mastery comes from doing something again and again and again. Until your taste starts to match your skills. When taste and skill are matched, that is what we call ‘craft’. A journalists cranks out piece after piece, a programmer slams the keyboard again and again until it works, gradually building that intuitive understanding of their medium.

taste + skill = craftsmanship

So if craftsmanship used to be about the levelling of combined taste and skill; then how is AI changing this?

What if there is no real effort necessary in creating the artifact? If AI can automate that? How does that change how we learn the necessary skills? But it also opens up possibilities, by sheer volume of explorations available. But here is what I find fascinating: this speed doesn’t necessarily mean we’re learning less. It means we’re learning differently.

How learning is changing

What we’re seeing isn’t the death of learning through practice - it’s the practice evolving into something new. The question isn’t whether we can still get really good at things in this new world. It is whether we’re disciplined enough to learn just as deeply from this completely different process.

Think about what's actually happening when you work thoughtfully with AI-generated iterations. You're not just passively looking at outputs, you're building a new kind of creative muscle. Each variation becomes a case study in *what works and why*. The key word is *thoughtfully*. The hard work isn't in the manual creation anymore. It's in the mental work of evaluating and understanding. The work of keeping your mind with the iteration, not be distracted in the moment, truly be with the AI, to master and create together.

Back to Ira Glass, the equation of craftsmanship still holds. Taste + Skill = craftsmanship. But the actual ‘skill’ is changing. The skill of recognizing, editing and “coaching” the artifact between taste and what’s made, is becoming more important. Not the actual skill of making, but the more meta skill of editing. I believe the craft is shifting from being good at making things to being good at recognizing and refining quality. We're becoming less like the solo craftsperson carefully shaping each piece, and more like a film director working with a talented crew to create something none of them could achieve alone.

This shift demands new kinds of creative skills that are just as challenging as traditional methods:

• Getting Crystal Clear About What You Want: Working effectively with AI requires you to explain your creative goals with incredible precision. You can't be vague and hope the tool will "figure it out." This forces a level of clarity about what you're trying to achieve that many traditional methods never demanded.

• Making Sense of Options Quickly: When you can generate dozens or hundreds of creative options, you need to develop the ability to rapidly identify what works, what doesn't, and *why*. Your capacity to quickly spot quality becomes a core skill, maybe *the* core skill. It's like being a talent scout, but for ideas.

• Developing Sophisticated Taste: In a world where anyone can generate many options, your ability to identify the truly great stuff becomes your main advantage. This isn't just having opinions—it's developing an increasingly sharp sense of what makes something exceptional.

Rethinking the 10.000 hours

Here’s where it gets really interesting. If you commit to deeply understanding each iteration, not just glancing at the surface but genuinely digging into why one version works where another fails, you’re potentially accessing a learning intensity that previous generations couldn’t imagine.

Where a carpenter might first create just a dozen pieces a year, what if you could make hundreds? Learning a little less of each, but in total volume so much more?

That is essentially what we’re having access to now. If we approach learning with the right mindset. The 10,000 hours don’t disappear; they get compressed into a much denser learning experience. The struggle doesn’t vanish, it transforms into a different kind of mental and creative work.

What does that look like? A graphic designer used to spend hours manually adjusting layouts, testing color combinations, tweaking typography. Each change took time and effort. Now they can generate dozens of variations quickly, but the real skill becomes recognizing which variations actually solve the design problem, understanding *why* certain combinations work better, and knowing how to guide the tools toward better solutions. *The learning happens in the analysis and direction, not just in the manual execution.*

For me, this represents an incredible democratization of creative exploration. We're no longer limited by how much physical material we can afford or how much time each experiment takes. We can test ideas that would have been too expensive or time-consuming to attempt before. We can fail faster, learn faster, and work toward excellence at speeds that were previously impossible.

The Discipline of Speed

But crucially, none of this happens automatically. The tools give you the capability; you have to supply the discipline. The risk isn't that AI makes us less creative. It's that we get lazy in how we use it.

We all know the shitty LinkedIn posts that are directly copy-pasted from chatGPT. Zero skill, or taste for that matter, involved. That is not speed, that is laziness. The difference is entirely in how intentional you are. Are you using these tools to avoid the hard work of creative thinking, or to amplify your capacity for that work? Are you letting the tools make your creative decisions for you, or using them to refine and strengthen your own judgment?

The creators who thrive in this new landscape won’t necessarily be those with the strongest traditional skills (though those certainly help). They’ll be the ones who can navigate this expanded creative possibility space with good judgement, refined taste and strategic thinking.

Think about what becomes possible when the friction of creation drops dramatically. A designer can test dozens of approaches to a brand identity. A programmer can prototype multiple solutions to see which one actually works best. A writer can explore different narrative structures for the same story.

The creative landscape ahead looks incredibly exciting to me.

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.

• Platform shifts are fundamentally about new tech becoming reliably available at a predictable, accessible cost; fostering trust and experimentation

• AI is unique in that it constitutes two platform shifts

• The first platform shift is technological; commoditising natural language as a building block. Thus making it easier to integrate with the ‘fuzzy’ real world. Thus holding the potential to transform virtually every service, applications and business.

• The second shift is societal in nature; getting used to machines doing what we previously (proudly) did not imagine a machine capable of doing

“AI is a radical platform shift”. We have been hearing this for a decade. A lot more these last three years. And so much more the last three months.

Yet, with so much talk about ‘shift’, I’m often confused as to what that means. What constitutes a platform shift? Hell, what does ‘platform’ even mean?

Start with the foundation

"Platform" is one of those wonderfully vague words. You can stretch it to fit almost anything – the internet, an OS, an online marketplace like Uber. For me, when I cut through the noise, a ‘platform’ is simply a foundation. It's something stable and predictable enough that you can rely on it to build something else on top. Think of the electric grid: you plug in an appliance trusting the power will be there, consistent and reliable, without a second thought. That’s a platform – a bedrock you can build upon.

Consider the telegram. Not the messaging app, the old-fashioned “analogue” messaging service. This wasn't a single invention but a stack of innovations, big and small, from understanding electromagnetism to the operational know-how of amplifying signals. The telegram itself was built upon the earlier platform shift of widely available electricity. And what did the ‘platform’ of the telegram enable? Messages at virtually zero marginal cost, zipping across the country almost instantly. It famously bankrupted the Pony Express in what felt like a week. More profoundly, these cheap, fast messages supercharged commerce by enabling businesses to coordinate activities across vast distances , accelerated the spread of news which shaped public opinion, and allowed for the management of larger, more complex organizations. It was a catalyst.

The platform shift of the telegram was about the consistently predictable price and availability of service. It became something you could reliably use, a dependable tool at your disposal.

And this is what a platform shift is truly about: economic viability and accessibility, fostering enough trust that others view the new technology as a reliable tool. New tech gets invented all the time. Brilliant ideas often simmer for years. But the shift? That only happens when the cost of using that technology drops, when it moves from the R&D labs and the hands of a few into the grasp of many. It’s when it stops being a precious, prohibitively expensive artifact and starts becoming a tool – something to experiment with, something you can even afford to ‘waste’ a bit, to play around with, without betting the entire farm.

Platform shifts, therefore, are about unleashing experimentation. They mark the transition from "Can I even touch this?" to "What if I could…?". A platform shift in itself doesn’t hold intrinsic value; it holds potential for value creation. It’s like a powerful new drill in a workshop; the excitement isn’t just the drill itself, but what we can now build with it because the technology has become cheap enough, and consistent enough, to take that leap of faith.

The AI shift is different

Which brings me to AI. It feels different. The buzz around this is louder, more persistent. What explains this?

Like any ‘platform’ that came before it – PCs, the internet, cloud, mobile – AI is built on a stack of pre-existing technologies and innovations. It relies on the vast datasets from the internet, our collective digital literacy (we’re all comfortable with chat apps, aren't we?), and countless innovations in machine learning and chip design. And AI, like its predecessors, holds the promise of enabling vastly new tools, services, and businesses.

But that alone doesn’t explain the persistent, almost feverish buzz that has surrounded AI for years, a hum that seems to grow louder by the day. I believe that extraordinary energy comes from the human-ness we instinctively ascribe to current AI, particularly language models. Using ChatGPT feels uncannily human. We see its outputs and attribute to it human-like abilities, creativity, even understanding. And in turn, we affirm our own amazement with what we perceive as its creative power. We are rapidly getting used to a technology that feels human, even though we intellectually know it is not.

It is this anthropomorphism that explains the buzz, I believe. It is the continuing amazement at creativity that fuels inspiration and concern. It is these human-like abilities we don’t quite know how to make sense of. And therefor it is these abilities that keep us circling back to the potential disruption of AI. Especially for us technologists.

It’s a more philosophical fascination, and it’s this abstract quality that can also make the conversation feel a bit unmoored. Because for all the exciting experiments and breathless talk, we are still in the early days of seeing how AI will fundamentally reshape the fabric of our daily lives and work. I, for one, am incredibly excited to find out.

The two platform shifts

And this is why AI, I believe, constitutes two platform shifts rolled into one.

The first shift is purely technical, fitting the classic model. It’s about the underlying technology and the new potential it unlocks. Large Language Models are making language itself a programmable, malleable material. This allows us to bypass traditional complexities in software development – often skipping the need for intricate data integration scripts or complex user interfaces for a whole range of tasks. Because language is so fundamental to nearly everything we do, the applicability of this technical shift is almost boundless, promising disruption and innovation across countless domains.

The second platform shift is driven by this anthropomorphism. Perhaps "paradigm shift" is a more accurate term here, as it’s more about a change in our societal relationship with technology. It’s about us getting used to the idea of machines performing tasks – logical, creative, conversational – that we once considered uniquely human. Remember the Mechanical Turk in the 18th century? Though ultimately a clever hoax, its illusion of a chess-playing automaton captivated imaginations. It wasn't about the reality of that specific machine, but about the idea it sparked – what if machines could reason, strategize, create? That captivation, that speculative wonder, is mirrored today with AI. Our amazement at what AI appears to do fuels an immense creative and speculative energy, even if we're still figuring out its true nature and limits.

It is this second, more paradigm-shifting aspect – our continued amazement at machines doing what we previously thought only humans could – that fuels so much of the intensity in today’s ‘platform shift’ discussions.

Personally, I’m extremely excited about how the ‘technological commoditization’ of natural language via AI can disrupt services, applications, and fundamentally change how we interact with information and systems. But I confess, I am perhaps even more excited by the sheer energy, creativity, and boundless curiosity that this era of increasingly anthropomorphized tech inspires.

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.

Your business shouldn't serve your software. But let's be honest—most of the time, it does.

You've seen it everywhere. Companies hiring expensive consultants to jam their workflows into rigid ERP systems. Teams forced to use interfaces that feel like punishment. Businesses spending months bending their processes around software built for someone else's idea of how work should happen.

This drives me crazy.

I'm a tech strategist. I've built systems, wrestled with architectures, lived in the world of APIs and databases. But I'm also obsessed with strategy, with design, with how we organize our work and empower ourselves.

And here's what I've been watching unfold: tech is finally reaching a point where we can flip this relationship.

The tools that used to require entire engineering teams are becoming accessible to everyone. The rigid architectures that locked us into inflexible systems are giving way to malleable, adaptable platforms. Small businesses are building custom solutions in weekends. Local companies are creating tools that rival what enterprises spend millions on.

This isn't about becoming a software company. It's about becoming the architect of your own efficiency.

I started InContext because this shift deserves more than surface-level trend reports or dense technical papers. It deserves exploration by people who aren't professional developers but who are curious about what's suddenly possible.

For years, I've been obsessed with these questions in the shadows, as a hobby. How do our tools shape our businesses? How can we leverage tech to become more creative, more productive, more empowered in our work? What happens when we stop adapting to our software and start making our software adapt to us?

This is my attempt to open up that conversation.

Every few weeks, I'll explore a specific shift happening in the tech world and translate what it means for your business. We'll look at new tools, emerging patterns, real experiments from people who are quietly discovering what's possible. Sometimes we'll get technical about software architecture—but always in service of practical possibilities.

I'm not here to persuade you to adopt every new trend. I'm here to help you see around corners. To spot opportunities others might miss. To give you permission to experiment with ideas that might seem too ambitious.

Most importantly, I want this to be a conversation. The best insights come from seeing how different people approach the same challenge. I want to hear about your experiments, your frustrations with current tools, your "what if" moments.

Think of this as your translator for what's shifting in tech—and what it means for how you work.

Because the future belongs to businesses that shape their tools, not the other way around.

Welcome to InContext.

—Stijn

P.S. A question for you; What are the three (tech) frustrations in your business you believe there simply must be a better way, but your people assure there isn’t? Let me know, let’s have a chat.