By Chris Meredith
Something quietly flipped in software development this year, and most people outside the industry haven’t noticed it yet.
For the last four decades, the central constraint in building software was human throughput. How fast could your engineers write code? How many developers could you hire? How quickly could they ship? Companies competed on talent density: getting the best people in the room, because human output was the bottleneck.
That bottleneck is gone. Or at least, it moved.
In 2026, the constraint isn’t writing code. It’s understanding it.
The Vibe Coding Problem Nobody Talks About
Last year, a term started circulating in engineering circles: “vibe coding.” The idea was simple and, honestly, a little alarming. You describe what you want to an AI. The AI writes the code. You ship it. You don’t always read it closely. It vibes.
The phrase was half-joking at first. A meme. Engineers dunking on junior devs who trusted AI output too blindly.
Now it’s a business model.
I’ve talked to engineering leaders at companies ranging from seed-stage startups to mid-size SaaS firms. The story I keep hearing is some version of this: their teams are shipping two, three, sometimes five times as much code as they were eighteen months ago. AI agents are writing first drafts of entire features. Engineers are reviewing, testing, and occasionally rewriting. But mostly reviewing.
The role flipped. Not overnight, and not everywhere. But the direction is clear.
And here’s what that flip creates: a review bottleneck that nobody designed for.
When Code Outruns Understanding
There’s an old rule in software engineering: you should be able to understand any line of code in your codebase. Not memorize it. Understand it. Know why it’s there, what it does, and what happens if it breaks.
AI-generated codebases are stress-testing that rule.
The problem isn’t that AI writes bad code. Often it writes quite good code, in the narrow sense of “does what I asked.” The problem is volume. When one engineer can prompt their way to 10,000 lines of working code in an afternoon, the standard review process (one human reads every line) becomes mathematically impossible to sustain.
So corners get cut. Code ships with a lighter review. The engineer trusts the AI’s output more than they should, because the alternative is slowing down to a pace that defeats the purpose.
Engineering communities have begun trading post-mortems about exactly this kind of incident: a production failure traced to an AI-generated authentication module that passed tests, looked fine on review, and carried a subtle flaw that sat dormant for weeks before causing a security breach. No human would likely have written it that way; a human would have recognized the pattern as dangerous.
The AI did exactly what it was asked. The ask was incomplete.
The Skill Nobody Hired For
Here’s the irony. Companies spent years optimizing their hiring process to find people who could write good code quickly. Leetcode gauntlets. Whiteboard algorithms. “What’s your lines-of-code output?”
The new job, the one that actually matters now, is different. It requires knowing what AI gets wrong. Understanding failure modes that aren’t obvious in a code review. Recognizing patterns that look right but carry hidden assumptions. Asking better questions of the AI so the output is useful and not just plausible.
None of that maps cleanly to the skills companies hired for. The best “vibe coder” and the best code reviewer are often not the same person.
Some engineers are adapting fast. They’re learning to treat AI output the way a seasoned editor treats a first draft: with productive skepticism, pattern-matching against experience, catching the stuff that sounds right but isn’t. These people are genuinely more productive than they’ve ever been.
Others are drowning. Not because they’re bad engineers, but because the game changed and their instincts are calibrated for a different problem.
What Security Looks Like When the AI Writes First
The security implications get less attention than the productivity story, but they’re significant.
Traditional security vulnerabilities in software fall into recognizable categories: SQL injection, buffer overflows, improper input validation, weak cryptography. Humans make these mistakes in patterned ways. The security industry built tooling, training, and code review checklists around human failure modes.
AI failure modes are different.
AI-generated code can be technically correct and structurally flawed at the same time. It can implement an algorithm perfectly while using it in a context where the algorithm is wrong. It can produce code that passes every automated security scan while containing logical vulnerabilities that the scan wasn’t designed to catch.
Security researchers are only beginning to characterize what “AI-generated code vulnerabilities” actually look like as a category. Early patterns are emerging: over-trust in external inputs, subtle race conditions in async code, authentication logic that works for the happy path but fails in edge cases the AI wasn’t prompted to consider.
The Five Eyes intelligence coalition issued a warning earlier this year that AI-enabled cyberattacks were coming faster than expected. What’s less discussed is the other side of that coin: AI-generated code creates a new attack surface, not because AI is bad at security, but because humans reviewing AI output are operating at the edge of their cognitive capacity.
The Bottleneck Moved. The Org Chart Didn’t.
Most software organizations haven’t structurally adapted to this shift yet.
They still have the same ratio of developers to reviewers they had three years ago, even though the volume of code requiring review has multiplied. They still run the same sprint planning process, with the same velocity metrics, even though “velocity” now measures something different than it used to.
A small number of companies are experimenting with what a review-first culture actually looks like. More senior engineers in explicitly review roles. AI tools built specifically for auditing AI-generated code, which is its own kind of recursive problem. New testing philosophies that focus less on “did this code do what I asked” and more on “what did this code assume that I didn’t ask.”
The companies that figure this out will have an advantage. Not because they’re writing more code, but because they’ll actually understand what they shipped.
The Honest Version of the Productivity Story
The productivity gains from AI coding tools are real. I don’t want to undersell them. Teams that have integrated these tools thoughtfully are shipping faster, handling more complexity, and enabling smaller teams to build things that used to require much larger ones. That’s genuine and important.
But the honest version of the productivity story includes the bottleneck it created.
We built cars without building roads first. We’re generating code faster than we’ve built the systems to understand it. At some point, the gap between “shipped” and “understood” becomes a liability that shows up as incidents, security breaches, and technical debt accumulating faster than anyone realizes.
The engineers who will matter most in the next five years aren’t the fastest prompters. They’re the ones who can look at ten thousand lines of AI-generated code and tell you, quickly and accurately, what it actually does, what it assumes, and where it’s going to break.
That’s a skill the industry isn’t hiring for yet. It probably should be.
Chris Meredith writes about AI, technology, and what it actually means for real people. Follow along on Substack: monkeyattack.substack.com
