Author: John O’Kennedy
Key Takeaways
Everyone can write code now. But coding was never the hard part. The planning and processes around building reliable software is. AI makes good teams dramatically faster, but it doesn’t replace the engineering judgment that separates a prototype from a production system. If anything, the fundamentals matter more now because AI amplifies whatever is already in your codebase, good or bad.
Code is cheap. Software still costs the same.
In 2026, we are drowning in code. Between Claude Code, Cursor, and agentic workflows, the cost per line has effectively dropped to zero. But here’s the grounded truth that almost 2 decades of building software has taught me. Code is a liability. Only the working solution is an asset.
When you use AI to generate ten thousand lines of code in an afternoon, you haven’t just “built more.” You’ve created a massive surface area for entropy, security risks, and technical debt. If you don’t have the engineering fundamentals to govern that volume, you aren’t accelerating your business. You’re building a bigger, faster problem.
It’s the same pattern we see at the strategic level, most mid-market companies are adopting AI, but few have the foundations to make it stick. The execution gap between AI ambition and AI results is widening, not closing.
Just as the majority of the population being literate didn’t eliminate the need for professional editors and publishers, the democratisation of coding hasn’t eliminated the need for professional software engineers. If anything, it’s made them more essential. Software development jobs have actually been increasing since the beginning of 2025, and AI-exposed roles are driving above-trend wage growth [3]. The market is telling us something.
The Hidden Cost of AI-Generated Code
Right now there’s a spectrum of how people work with AI. At one end you have vibe coding, the iterative prompt-and-pray approach the fastest way to turn a code base into slop. At the other end you have what’s increasingly being called agentic engineering, structured approaches like spec-driven development (SDD) and the Research-Plan-Implement (RPI) framework that bring real discipline to how AI writes code. These are genuinely better ways of working. They produce better code, fewer surprises, and more predictable outcomes.
But even with good agentic engineering practices, you still have to combat entropy. The moment you scale any of these approaches to a large system or layer them onto an existing codebase, software fundamentals are what keep things from falling apart.
Every time you regenerate without thinking about the design of the whole system, your codebase gets worse. John Ousterhout calls this complexity: “anything related to the structure of a software system that makes it hard to understand and modify.” The Pragmatic Programmer describes it as software entropy, the natural tendency of systems to decay with each change if no one is actively investing in the design.
AI doesn’t escape this law. It accelerates it.
The models have learned their patterns from the internet, from all of our old code, the good and the bad. And the uncomfortable truth is that most code on the internet is mediocre at best. So when an AI fills in the blanks of an underspecified prompt, it reaches for familiar patterns: unnecessary abstractions, defensive duplication, backwards compatibility shims nobody asked for. Recent benchmarks bear this out. AI-touched code introduces 153% more design flaws and an 8x increase in duplicated code compared to human-written baselines [1]. Meanwhile, refactoring activity has dropped by nearly 40% as teams prioritise speed over structure [1]. You can end up with enterprise-grade complexity in two weeks with a small team running hot on agents.
I’ve seen this firsthand with AI prototyping work. You start with the best intentions, clean structure, clear boundaries. But if you’re optimising purely for speed, things spiral. The question every team needs to ask early is: are we building a quick demo for investors, or a stepping stone towards a long-lived system? Because the answer changes everything about how you design that system. For businesses, that distinction is the difference between a disposable prototype and a codebase that can actually support growth.
Moving Up The Stack
I want to be clear about something: I’m not an AI sceptic writing a cautionary tale. I’m someone who went all-in. I use Claude Code for all of my implementation work, and I think it’s the most significant productivity shift I’ve experienced in my career.
But “100% agentic coding” is a divisive phrase because it sounds like you’re letting the machine do your job. The reality is the opposite. What actually happens is you move up the stack. You spend more time on architecture, on system design, on verifying that what’s being built actually makes sense. You become the director, not the typist. And the leverage cuts both ways. Good decisions get multiplied, but so do bad ones.
Andrej Karpathy frames this well: vibe coding raises the floor for what everyone can do, but agentic engineering is about preserving the quality bar of professional software. You’re still responsible for your system. You still need to know that user IDs should be persistent identifiers, not email addresses stitched together from different services. You still need to understand that there’s a difference between a view over shared memory and an unnecessary copy. The details of the API? Let the AI handle that. The fundamentals of why your system is designed the way it is? That’s still on you.
Here’s what nobody tells you about working this way. I’ve never worked this hard in my life. There are biological limits to how much information a human can process, and AI-assisted development is pushing right up against them. Moving up the stack isn’t laziness, it’s necessity. The volume of decisions, the pace of change, the sheer amount of code flowing through a team. It’s unlike anything I’ve seen in all my years as a dev.
Why AI Development Hits a Code Review Wall
Here’s a concrete example from a current project. We’re a large team, all using AI-assisted development. Everyone is generating more code than ever. Sprint velocity looks incredible on paper as story points are flying through development. But they’re stacking up in peer review.
This isn’t just us. Industry-wide, the volume of AI-generated code is projected to outstrip human review capacity by 40% [2]. Teams are merging 98% more PRs that are on average 154% larger than before [1]. The code is being written, but nobody can read it fast enough.
We require at least two reviewers per pull request, and we’re not willing to compromise on that. So what’s happening is that sprints are finishing with more work “in review” than ever before, but not proportionally more work “completed.” The review process, humans reading code, understanding context, verifying correctness, has become the bottleneck.
Some people would say the answer is to automate reviews too by using an AI reviewer. But that would be missing the point as reviews are not just for keeping up code quality it’s more a tool to ensure knowledge about the system is shared throughout the team. AI reviews are only surface level. It can spot a missing null check, but it can’t tell you that the architectural decision three files deep is going to make the next feature impossible to build. That still requires someone who understands the system. And that someone needs to be experienced enough to spot what the AI got subtly wrong, because 61% of developers now report that AI produces code that looks correct but is unreliable [1].
For this project we’re choosing to slow down rather than surrender quality. And that’s a real trade-off that real teams are making right now. It’s not just theory.
Why Software Engineering Fundamentals Still Win
The Pragmatic Programmer has a concept called “outrunning your headlights.” It means driving so fast that you can’t stop within the distance your headlights illuminate. AI, by default, outruns its headlights constantly. It produces massive amounts of code and only then thinks about whether it type-checks, passes tests, or fits the broader design.
The solution isn’t less AI. It’s better engineering discipline applied to how you use it.
Modular architecture matters more. If your codebase is a tangled web of shallow modules and implicit dependencies, AI will get lost navigating it and so will your team. Deep modules with simple interfaces, as Ousterhout describes, give both humans and AI clear boundaries to work within. You test at the interface. You verify at the boundary. The implementation behind that boundary? That’s where AI excels.
Testing discipline matters more. Test-driven development isn’t just good practice anymore. It’s a forcing function that keeps AI taking small, verifiable steps instead of generating a thousand lines and hoping for the best.
Design investment matters more. Kent Beck’s principle, invest in the design of the system every day, is the antidote to AI-accelerated entropy. Every time you skip that investment to move faster, you’re borrowing against the future maintainability of your system.
We’ve had clients who never allowed time for refactoring or stepping back. Eventually it catches up. The codebase becomes unmaintainable. In some cases, it practically needs a rewrite. In others, we’ve been able to save projects by breaking monoliths into smaller, well-bounded services. But the pattern is always the same. The teams that invest in design early can absorb change. The teams that don’t, can’t. No amount of AI tooling changes that equation.
The Pragmatic Middle Ground
The healthiest approach I’ve found is somewhere between “move fast and break things” and “review every semicolon.”
It starts with scoping. AI agents work within a context window, typically around 100k tokens. If the relevant code, tests, and documentation for a task don’t fit in that window, the agent is working blind on parts of your system. So you break features down into smaller, focused tasks that an agent can fully comprehend. This is where modular codebases pay for themselves, each module is a self-contained unit that fits comfortably in context. Then use AI for what it’s genuinely good at: generating boilerplate, exploring approaches, rubber-ducking a design problem, polishing the implementation details you’ve already thought through.
The real skill is knowing where your leverage is. Not all code is equally important. Non-critical modules with good test coverage? Let AI handle them end-to-end. Core business logic, security boundaries, financial calculations? That’s where you need to understand every line, because that’s where the cost of getting it wrong is highest. You can outsource your thinking, but you can’t outsource your understanding. The goal isn’t maximum speed. It’s maximum sustainable speed, where you’re moving significantly faster than before without the codebase decaying under you.
One thing I’d add for developers earlier in their careers: dial back the agentic coding. Prioritise learning over productivity. The friction of writing code yourself is what builds your mental model of the system, and that understanding is exactly what makes you effective when you do eventually work with AI at full speed.
What This Means for Businesses
There’s no question that AI has raised the floor. Anyone can build a demo. Anyone can prototype. That’s powerful, and there are genuine use cases for rapid AI-built prototypes. Investor demos, proof of concepts, internal tools that don’t need to scale.
But if you’re building a system that needs to be secure, maintainable, and reliable, the kind of system that processes financial transactions, handles patient data, or runs a business, you need engineers who understand why a system is built the way it is. Not just engineers who can prompt an AI to build it. This is why we invest in experienced engineers with deep tenure. In a world where AI-generated code carries a 23.5% higher incident rate than human-written baselines [1], the experience to catch what the AI misses isn’t a nice-to-have. It’s what stands between your system and production incidents.
The irony of the AI age is that while code has gotten cheaper to produce, the cost of bad code has gotten higher. When you can generate ten thousand lines in a day, the blast radius of a poor architectural decision is enormous. You need people who can tell the difference. People who have felt the pain of maintaining a system built without those considerations.
AI makes good teams faster. It doesn’t make fast teams good.
The Bottom Line
AI has changed the way we build software forever. As a company, we prioritise staying at the forefront of these tools because the productivity gains are real and significant. But the developers who will thrive aren’t the ones who generate the most code. They’re the ones who understand systems deeply enough to direct AI effectively. The ones who know when to speed up and when to slow down, who invest in design, who read the critical paths, and who treat AI as a force multiplier for good engineering rather than a replacement for it.
The fundamentals haven’t changed. If anything, they’ve become the competitive advantage.
If you’re navigating AI-assisted development and want an honest conversation about what it takes to build systems that last, talk to our engineering team. We’ve been doing this for over two decades, and we’re still learning every day.
Sources
- AI Code Analysis Benchmark Reports — Exceeds.ai, 2026. Benchmarks on AI vs human code quality including incident rates, design flaws, and duplication metrics.
- AI Code Review for Enterprise — Pensero.ai, 2026. Research on the AI code generation gap and enterprise review capacity.
- The AI Job Apocalypse Is a Complete Myth — a16z, 2025. Data on software development job growth and wage trends in AI-exposed roles.
- A Philosophy of Software Design — John Ousterhout. On complexity, deep modules, and interface design.
- The Pragmatic Programmer — David Thomas & Andrew Hunt. On software entropy, outrunning your headlights, and engineering discipline.
- Andrej Karpathy: From Vibe Coding to Agentic Engineering — AI Engineer Conference, 2025. On the distinction between vibe coding and agentic engineering.
