Cheap Code, Expensive Pitfalls.

The Inversion

For decades, writing code was slow and expensive. We knew what we wanted to build, but getting it built was excruciatingly time-consuming. Our software development processes were geared around making an inherently slow process that required intimate knowledge as painless as possible.

In 2026, this is inverting. AI is making writing code fast and cheap, but knowing what to build, how to evolve it in the best interests of an organisation, and maintaining technical oversight of it all are becoming more challenging than ever.

Most web application development teams are currently optimised for a bottleneck that no longer exists, and the changes we need for an AI-first development process aren’t being made.

What AI is Actually Automating

AI is collapsing the time between "I know what I want" and "I have working code."

If your mental model of software development was that it primarily involved writing code, this will sound like the entire thing has been automated, but it hasn't.

Software development was never primarily about writing code. It was about figuring out what to build, understanding why it matters, how it should work, and predicting how it will interact with everything else.

Once software is live, it becomes about observing, learning, and iterating towards higher-level business objectives with more what, why and how examination.

Producing code is just one part of this complex process. The part where decisions get transcribed into something a computer can execute. The rest happens outside the code editor. AI is helping speed that up too, but it's nowhere near automated yet.

How This is Changing Development

Although it’s not full software development automation, AI code generation isn’t a minor shift either. It has fundamentally altered the economics of web application development, the shape of teams, and what it means to be a programmer.

Code that once took days now takes minutes, and prototypes that once required a team now require a laptop and an afternoon. Products and features that weren’t economically viable can now be created cheaply, and the automation opportunities available to small and mid-sized organisations have increased dramatically.

That transformation is real, but with that comes a new set of problems we need to take into consideration in order to make the most of the opportunities AI gives us.

The Accountability Vacuum

When a human developer writes problematic code, the accountability chain is clear. The developer wrote it. A team code-reviewed it. A manager signed it off. A company employs them all. It’s not perfect, but it's a system where most issues can be traced back to a bug introduced by a person.

When AI writes code, that chain blurs uncomfortably. The developer is much less likely to understand everything they produce, and their coworkers are overwhelmed with code review requests now that the company is generating so much more code. When an API is deployed without adequate security, and customer data leaks, who’s going to be held responsible?

This isn't theoretical. Courts, regulators, and professional bodies will all have opinions about where responsibility lies when AI-generated code causes harm. Organisations with development teams need to be able to show they’re taking oversight and accountability seriously, so they don’t vibe code their way into a lawsuit.

Speed Creates Its Own Risks

Fast code generation is great, but it means unwanted side effects get faster too. Fast accumulation of technical debt. Fast deployment of security flaws. Fast erosion of institutional knowledge about how systems work.

Development teams can now iterate faster than they can keep up with the changes being made. And when new features are just a prompt away, it’s all too easy to lose sight of the product problem you're actually trying to solve.

The bottleneck has moved from production to comprehension — both technical and product. Teams that miss this shift will find themselves maintaining systems nobody truly understands. They’ll be debugging code nobody wrote, and defending architectural decisions nobody recalls making. All in service of a product that doesn’t make sense to their customers.

The New Developer Skillset

There's a tempting narrative that the developers who thrive will be the best prompters, but this undersells what's actually needed.

Prompting is table stakes. Every developer will learn to prompt adequately, just as everyone learned to use search engines. The developers who genuinely thrive will need to strengthen some of the non-programming skills their jobs already require:

• Critical oversight. Spotting subtle bugs. Recognising security antipatterns. Maintaining mental models of systems they didn't write. This requires judgement that comes from having written a lot of code yourself, having debugged systems at 3am, and having seen how innocent decisions cascade into production downtime.
• Systems thinking. Understanding how components interact, where failures will cascade, and which abstractions are load-bearing. AI can generate a service in minutes. Knowing whether that service belongs in your architecture at all is a different skill entirely.
• Product sense. When code is cheap, knowing what to build matters more than knowing how to build it. Developers who understand user problems, business constraints, and can prioritise ruthlessly will outperform those who just execute well on the wrong things.
• Communication. More code, faster, means more coordination overhead. Explaining technical tradeoffs to non-technical stakeholders. Writing documentation that actually helps. Aligning with other teams before your AI-generated microservice breaks their AI-generated microservice.
• Learning velocity. The tools are changing monthly. The developers who treat their workflow as permanently provisional, who stay curious rather than defensive, will adapt while others calcify.

For now, those best at adapting to this new world are likely to be the most experienced human programmers. Junior developers who never learned to build systems the "old" way face a genuine challenge. The shortcuts that make them productive today may leave gaps in the judgement they'll need to grow. Finding ways to build that foundational understanding, even while using AI tools, is important.

Organisational Implications

If code is cheap, what should you spend money on? The answer probably isn't "more engineering." It's "different engineering."

Product focus is doubly important now. If you can build anything quickly, the cost of building the wrong thing is the opportunity cost of not building the right thing. Your competitors have cheap code too, and as iteration pace accelerates across the industry, the teams that understand what users actually need will pull ahead of those still guessing.

Security and compliance review matter more because more code means more opportunity for bugs. Thorough automated testing becomes critical to ensure AI-generated components actually work together. With less human oversight baked into code production, you need more automated oversight explicitly built around it to compensate.

Feedback loops need to tighten as well. When you can ship five experiments in the time it used to take to ship one, you need to know which ones worked five times faster. Insight that arrives after you've already built the next three features isn't insight, it's archaeology.

The pattern here is straightforward: as code production speeds up, everything else needs to speed up too, or it just becomes the new bottleneck. That means investing in automation for all the unglamorous work that surrounds the code itself. The typing got faster, and now everything else needs to catch up.

The Opportunity Underneath

Buried in all this caution is endless opportunity. Software that would have been too expensive to build can now exist. Experiments that would have taken months can happen in an afternoon. Markets too small to justify traditional development can now be served effectively.

The companies that capture this will treat cheap code as raw material, not finished goods. Raw material still needs refining, inspection, and judgement about whether it's fit for purpose. A pile of lumber isn't a house, just as a repository full of AI-generated code isn't a product.

The optimistic version of this story is that we figure out how to use cheap code wisely. The pessimistic version is that we ship faster than we think, accumulate problems faster than we solve them, and end up with fragile systems nobody understands. Which version we get depends on remembering why we're building software in the first place, and adapting our approach for an AI-automated world.