The Prototype Is Not the Product
There's a piece of AI orthodoxy doing the rounds that I want to push back on. The idea that, in a world where anyone can build anything, the new moat is taste or vision.
It's a comforting story, particularly for people who've always believed their ideas were the most valuable part. Implementation used to be the toil, AI takes care of that toil, and all that's left is to lazily one-shot your way to the next SaaS unicorn. I think it overstates what AI has actually solved, and misses what's genuinely changing.
Building well is still difficult. AI hasn't removed the engineering challenge so much as lowered the barrier to producing something that looks like a finished product. Throwing a demo together in an afternoon is one thing. Turning it into a genuinely good product is quite another, and AI is a lot better at the first than the second. That isn't necessarily a question of capability. Rather, refinement is an accumulation of decisions, and most of what informs those decisions lives in people's heads rather than anywhere the model can see.
Part of the reason is how these models work. Left to their own devices, they gravitate toward the most likely answer, which usually means the most conventional one. That goes for technical choices as much as aesthetics. Average is a reasonable place to start, but I would say it's a pretty poor place to finish, and I'm sure most would agree.
Ideas have always been ten a penny (or "dime a dozen" for my American's), and what made implementation valuable was never purely the code. What pulls a product away from average is the process of building it. You draw on lessons from experience to make sensible decisions, and each of those decisions adds to the experience you bring to the next. Repeat that across hundreds of small choices and you end up with something no single prompt could produce. That iterative experience is what makes the product what it is.
That isn't to say taste and vision count for nothing. You still want both, they just aren't the moats they're pushed as being. If engineering, design and development were foregone conclusions at the pedestal of taste and vision, plenty of us would have made GTA 6 long before Rockstar. Lots of people have a high-level idea of what a great open-world game might be, but that's never been the hard part.
Look at the AI game slop being pumped out at the moment. Plenty of it looks compelling, and yet almost none of it stays fun for more than about ten seconds. Nobody is swapping Mario Kart for whatever monstrosity came out the end of ChatGPT after a couple of prompts.
What has actually changed is who gets to go through that process. Design, product and engineering have always been separate roles, and partly that's because they need different skills. However, a lot of it came down to cost. Engineering time was expensive, so we built a whole process around protecting it. Specs, mockups, tickets, estimates, handoffs. Most of that ceremony exists to squeeze the ambiguity out of a problem before it reaches the expensive bit.
That made sense when getting something wrong cost you a sprint. It makes a lot less sense when it costs you a couple of hours, if that. Now that so many of the small technical choices are no longer a real hurdle, you can work through the ambiguity as you build, rather than trying to resolve it all up front. Being able to change course like that is arguably agile in its purest form. The whole philosophy rests on the assumption that software, unlike a bridge or a building, is inherently able to change.
So the roles start to collapse into one. Someone who can take an abstract problem, navigate its ambiguity and turn it into a technically robust product. That means holding a deep understanding of the problem in front of you alongside a bird's-eye view of where it fits into the wider product, and drawing on experience to nudge each small decision towards the robustness of the whole. It also means being able to step back and ask why you're solving this problem at all, and whether there's a better way.
None of that is new. It's precisely what good software engineers have always done, and it's learnt through experience and practice, not conjured from vision or taste. AI has moved us further up the abstraction chain, but it hasn't changed the fundamental part of the role. If anything, it's why engineers continue to be valuable, if not more so.
In practice, working further up the chain might mean building the harnesses around AI itself. The loops and evals that make systems more efficient and more autonomous. What it doesn't mean is relinquishing responsibility for the technical implementation under the hood, or for validating that it actually works.
What AI does shift is where the bottlenecks sit. When fewer of them are purely technical, the role puts more emphasis on a broader range of skills, like creativity, communication and management. Plenty of engineers have always had those, but haven't always had the opportunity to exercise them. The upshot is that people are likely to end up much less of a one-shot trick pony.
In the hands of experienced engineers, AI lets us be more ambitious. If the barrier to building has dropped, the answer isn't to build the same things cheaper. Another todo app is not a meaningful contribution to the world of software anymore. The more interesting work is in problems that were too complex or too messy to take on before, which happen to be exactly the ones where one-shotting doesn't get you very far.
AI might get you to the prototype, but the hard part is still everything after it. Wherever we sit in the abstraction chain, solving problems is still the anchor at the end of it.