Every week there’s a new demo of someone building a full app in twenty minutes with AI. A SaaS scaffold. A working prototype. A thing that would have taken a team a sprint, conjured from a prompt and a conversation.
It’s impressive. It’s real. And it’s almost entirely beside the point.
I’ve been building software for over twenty years. I’ve been building with AI agents for a while now. And the thing that strikes me most isn’t how much code AI can produce. It’s how little that production matters compared to the decisions it can’t make for you.
The building part is now easy
Let’s be honest about what happened. The barrier to producing working code dropped dramatically. AI can generate functions, scaffold architectures, wire up APIs, write tests. Things that used to take days now take hours. Things that required deep familiarity with a framework can now be figured out in a conversation.
Producing code is no longer the scarce resource. Any AI agent will happily generate whatever you ask for. The scarce resource is knowing which code should exist in the first place. Which problem it should solve. Which approach to take when there are fifteen valid options. Which dependencies to accept and which to refuse. How to structure it so it still makes sense six months from now.
That part hasn’t gotten easier. If anything, it’s gotten harder. Because when producing code is fast, the cost of producing the wrong code goes up. You end up with something that works, ships and solves the wrong problem. And that’s a more expensive mistake than slow code, because it looks like progress.
The shift we don’t talk about enough
Most of the discourse around AI and software development focuses on code production. Lines written. Features shipped. Time saved. And by that measure, AI is transformative.
But code production never was the real bottleneck. The bottleneck is in knowing what the right code is. Not syntactically. Architecturally. Strategically. Which module should exist? What should it not do? What trade-offs are you making, and are you making them deliberately or by default?
AI accelerates everything that happens after those decisions. It doesn’t help you make them. Which means the decisions carry more weight than they ever did. And the developers I see struggling with AI aren’t struggling with the tooling. They’re struggling because they never had to articulate why they were writing certain code in the first place. The work used to take long enough that the direction sort of emerged along the way. Now the code arrives before the thinking catches up.
Why and how, not what
The question that matters when you’re building with AI is not “what can I produce?” You can produce almost anything. The question is: why does this code need to exist, and why should it be built this way?
Why this problem? Why this approach instead of the twelve alternatives AI would happily generate? Why this architecture, with these trade-offs, optimising for these principles? Why stop here instead of adding the five features AI just suggested?
These are the questions that separate software that matters from software that merely exists. And they’re exactly the questions AI can’t answer for you. Not because the technology isn’t there yet. Because they’re not questions about code. They’re judgment calls rooted in context, values and vision that no model has access to.
The same applies to how you build. The architectural decisions. The things you choose not to abstract. The dependencies you refuse to take on. The moment you decide that three simple lines of code are better than the elegant pattern AI proposed. These choices compound over time, and they’re the difference between software that lasts and software that was merely produced.
The unexpected second shift
Here’s the part I didn’t expect.
AI doesn’t just change how fast you build. Used differently, it changes how you think about what you’re building. Not by telling you what to think, but by creating a space where your thinking gets tested.
When you explain your reasoning to an AI agent, when you articulate why you’re making a certain architectural decision or why you’re prioritising one feature over another, something happens. The act of articulating forces clarity. The response, whether it’s a challenge, a question or an alternative you hadn’t considered, forces you to examine your assumptions.
This is different from code generation. This is AI as a thinking partner. Not replacing your judgment, but pressure-testing it. And in my experience, the most valuable moments with AI aren’t when it writes code for me. They’re when it asks me something that makes me realise I haven’t thought something through.
I wrote recently about pulling a product launch because the product didn’t match the argument I’d been making. That realisation didn’t come from staring at code. It came from being forced to articulate my reasoning and confronting the gap between what I was saying and what I’d actually built. AI was part of that process. Not by writing better code, but by asking better questions.
That’s a fundamentally different relationship with the tool than “generate this for me.” It’s closer to rubber-ducking with a colleague who happens to have read everything and has no ego investment in being right.
What this means for developers
The role isn’t going away. But it is changing shape.
If your value as a developer was primarily in translating requirements into code, that value is compressing. Not to zero right now, but significantly. The mechanical act of writing software is becoming less of a differentiator.
What’s becoming more valuable is everything around the code. The ability to identify the right problem. The judgment to choose the right approach. The discipline to say “not this, not now.” The architectural thinking that makes software maintainable, extensible and honest about its trade-offs.
In other words: the stuff that was always supposed to be the job, but that got buried under the sheer volume of code that needed to be produced.
I think that’s a good thing. Not because AI is saving us from boring work. But because it’s exposing a truth that was always there: the hardest part of building software was never the building. It was the thinking. And the developers who were already good at the thinking are finding that AI makes them significantly more effective. Not because it does the thinking for them, but because it clears the space for them to do more of it.
The real question
The conversation about AI and software development will keep evolving. The tools will get better. The demos will get more impressive. The “I built this in 10 minutes” posts will keep coming.
None of that changes the fundamental question: do you know why you’re building what you’re building, and can you defend how you’re building it?
If you can, AI is the most powerful accelerator you’ve ever had.
If you can’t, it’s the fastest way to build something that soon doesn’t matter anymore.