The AI coding shift: your engineers just got faster, and your codebase might be in trouble

There's a moment in almost every founder conversation this year where someone pulls up their phone and shows me a feature their team shipped over a weekend. A real feature — auth, a dashboard, a payments flow — built by one engineer with an AI agent, in the time it used to take to write the ticket. The pride is genuine, and it should be. Something extraordinary has happened to the cost of producing software.

Then I ask the question that changes the temperature of the room: who has read all of it?

That question is the whole story of where we are. AI coding tools are the most significant leverage software teams have ever been handed, and they are also quietly creating a category of risk that doesn't show up in the demo, doesn't show up in the sprint review, and shows up with brutal timing during a fundraise or a security audit. Your job is no longer to decide whether to use these tools. That decision is made. Your job is to decide what you put around them.

The visible half and the invisible half

The visible half is easy to fall in love with. Around 40% of new code is now AI-generated, the best agentic tools went from novelty to default in under a year, and developers consistently rank them among the things they most love using. The leverage is not hype. It is real, and it is large.

The invisible half is what happens to that code after it's generated. Code isn't valuable because it exists; it's valuable because it's understood, reviewed, secured and maintainable. None of that got cheaper. In a lot of teams it got more expensive, for a simple reason: there is now far more code, produced far faster than any human can actually read. The bottleneck in software was never typing. It was understanding — knowing what to build, why, and whether the thing you just built is correct and safe. AI demolished the typing bottleneck and left the understanding bottleneck completely intact. The work didn't disappear. It moved from writing to reviewing, and reviewing is harder, slower and far less fun.

The productivity paradox

Here's the finding that should make every founder pause. In controlled studies this year, experienced developers using AI tools felt roughly 20% faster — and were measurably slower on real tasks in their own codebases, by a similar margin. Feel and reality pointed in opposite directions.

Generation is instant; verification is not. The agent produces a confident, plausible, well-formatted pull request in seconds. Then a senior engineer spends forty minutes working out whether it's actually right, whether it handles the edge cases, whether it quietly broke an assumption three files away. The reward is front-loaded and the cost is back-loaded. Multiply that across a team and everyone feels fast, the burndown chart looks healthy, and shipping real, stable features takes just as long.

The bill that arrives late

Two kinds of debt accumulate under fast AI adoption, and both come due at the worst possible time. The first is security debt. Analyses this year put the share of AI-generated code containing at least one security weakness somewhere between roughly half and two-thirds, and static-analysis vendors are reporting on the order of a tenfold increase in AI-related findings compared with a couple of years ago. The dangerous part isn't that the code is obviously broken — it's that it often works. It passes the unit tests. It demos perfectly. The weakness reveals itself under real-world conditions, or under the gaze of an investor's technical due-diligence team.

The second is comprehension debt, and it's the more insidious of the two. AI generates code several times faster than a human can genuinely understand it, so teams accumulate modules that work but that no living person fully grasps. For a while this feels fine. Then something breaks at 2am, or a key engineer leaves, or you need to change the thing everyone has been quietly afraid to touch — and you discover that you don't own your codebase. You're renting comprehension you never built.

What this does to your hiring plan

Entry-level engineering demand has fallen sharply, and some large companies have openly slowed or paused junior hiring, citing AI. The logic is uncomfortable but straightforward: much of what junior engineers used to do was exactly the codified, well-specified work that AI now does instantly. The "hire a cheap junior to crank out code" play is largely over.

But the conclusion many founders draw from that — we need fewer engineers, and they can be cheaper — is exactly backwards. If AI generates most of the code, the scarce skill is no longer production. It's judgement: knowing what to build, recognising when the agent's confident output is subtly wrong, owning the architecture, holding the line on security and comprehension. That's senior work, and it cannot be vibe-coded. A small team of people who can review, architect and say "no, regenerate that" will out-build a larger team drowning in code none of them understand.

The playbook

1. 1
   Measure shipped-and-reviewed, not lines.

   Retire any metric AI can inflate on its own. If your team's velocity looks like it tripled, that's a signal to check your metrics, not to celebrate.

2. 2
   Put a review gate on every AI pull request.

   Human review plus automated static analysis before anything merges to your main branch. No exceptions for "it's just a small change" — small changes are exactly where confident-but-wrong output slips through. This one gate neutralises most of the security-debt risk for almost no cost.

3. 3
   Decide where agents run free and where they're fenced.

   Prototypes, internal tools and throwaway experiments: let the agent rip. Authentication, payments, the data model, anything touching customer data: senior review mandatory, slow on purpose. The mistake is treating your whole codebase as one risk zone.

4. 4
   Hire for judgement, not throughput.

   In interviews, stop testing whether someone can write a function from scratch — the agent does that. Test whether they can spot what's wrong with a function the agent wrote.

5. 5
   Manage comprehension debt deliberately.

   Make it a rule that every module which ships has a human owner who can explain it. If nobody can, it doesn't merge until someone can. This single norm prevents the drift into a codebase your team rents instead of owns.

None of this is an argument against AI coding. The leverage is genuinely the biggest shift in how software gets built in my career. But leverage is neutral: the same agent that ships your MVP in a weekend can bury a vulnerability in a pull request nobody read, or grow a codebase faster than your team can understand it. Which outcome you get isn't determined by the tool. It's determined by what you choose to build around it. AI coding doesn't remove the need for senior engineering judgement — it raises the price of not having it.