Before you replace your dev team with AI, read this

If you run an engineering organization in 2026, you’ve probably watched your output metrics climb while delivery stayed roughly where it was. More pull requests. More lines merged. A velocity dashboard that stays green. And somehow the same features shipping on the same timeline, with more incidents than you expected.

That gap is the story of this year. AI removed the constraint that shaped software teams for decades. It didn’t remove the other ones, and it made some of them much more expensive.

I’ve been building software for 21 years, and I use AI every day. It’s changed how I work more than any tool since version control. What follows isn’t an argument that AI writes bad code. It’s an argument about where the work went.

Writing code stopped being the bottleneck

For most of the history of this industry, implementation capacity was the scarce resource. A team could only write, test, and prepare so many changes in a quarter, and planning was mostly about allocating those hours.

Code review worked in that world because of a happy accident of relative speed. A senior engineer could read code faster than anyone could write it, so review kept pace without anyone designing it to. Nobody chose that arrangement. It fell out of the fact that writing was slow and reading was fast.

AI broke that relationship. One engineer can now run several agents at once, each producing changes that need human attention. Generation got cheap and parallel. Review didn’t. Architectural context, risk judgment, product knowledge, and security awareness still sit with a small group of experienced people, and that group didn’t get bigger.

So the constraint moved downstream, onto exactly the people AI was supposed to free up. Teams report more AI code, more pull requests, faster implementation, slower review queues, more senior review work, and no meaningful change in how fast anything actually ships.

AI amplifies the judgment it’s given

A well-directed agent builds precisely what you described. That’s the promise, and it’s also the problem. When your description was vague, underspecified, or wrong about how the system actually works, you find out at high speed and at scale.

This cuts both ways, and the direction depends entirely on who’s holding the tool. Given weak judgment, AI produces fast, confident chaos. Given strong judgment, it’s the biggest force multiplier our profession has ever had. The tool is the same. The output isn’t.

When code was expensive, a bad specification cost you a week of one person’s time. When code is cheap, a bad specification costs you a codebase. The discipline of knowing what you want to build, and why, matters more now than it did three years ago.

The failure mode is confident plausibility

Here’s the part that catches teams by surprise. When an inexperienced engineer writes weak code, the problems announce themselves. Awkward structure, obvious gaps, things that look wrong on a first read. Review catches them because they’re visible.

AI-generated code fails differently. It reads as clean, consistent, and competent while hiding misread requirements, wrong edge cases, and logic that’s subtly incorrect in ways that only show up under real traffic. Studies comparing AI-authored and human-authored pull requests find meaningfully more issues per change in the AI-authored ones, including security problems, and those issues are harder to spot because nothing on the surface signals trouble.

Catching them requires having seen the underlying problem before. Not pattern-matching on style, but recognizing that this cache invalidation will be wrong under concurrency, that this component will break the moment someone translates it into German, or that this form is unusable with a screen reader even though every test passes. You can’t review your way to that with a checklist. It comes from having been burned.

Agents are missing most of your context

An agent generates code against a narrow slice of what it would need to know to get it right. It sees the codebase as it exists today. It doesn’t see the incident that produced the strange workaround in the payments module, the decision to keep an old API alive for one large customer, or the six months of arguments behind your data model.

Intent isn’t in the code. Intent is in how the code got that way, and in the constraints your team carries around in its collective head. Someone has to supply that: in the architecture, in the prompts, in the boundaries, and in the moments when an agent proposes something reasonable that happens to be exactly wrong for your business.

That’s not a prompt engineering problem. It’s an experience problem.

The most valuable thing I build makes AI work better

There’s a version of this argument that ends with “so hire senior engineers to review more code.” That would just turn your best people into a queue.

The better answer is to change what the agents are working with. This is most of what I do now, and it’s why design systems have become more valuable rather than less. A component library with narrow, well-typed APIs, tokens named for intent rather than appearance, usage rules sitting next to the code, and accessibility built into the shared components does something specific. It makes the correct choice the easy choice for whoever reaches for it, whether that’s a new hire or an agent generating twenty screens.

Guardrails scale in a way that review doesn’t. Lint rules, type checks, visual regression tests, and automated accessibility checks in CI give an agent fast, specific feedback without consuming a senior engineer’s afternoon. When the system encodes your standards, you stop depending on a person to catch every violation by reading.

That’s the leverage available right now, and it takes someone who knows what good looks like to build it.

What experience actually buys you in 2026

It isn’t typing speed. It hasn’t been typing speed for a while.

It’s someone who can decide what to build and say no to the rest. Someone who can direct agents at a real problem, then verify what comes back, including the parts that look fine. Someone who knows which decisions are cheap to reverse and which ones you’ll live with for five years. Someone who builds the systems, tooling, and standards that let everyone else, human and otherwise, move quickly without quietly breaking things.

AI made code abundant. It made judgment the scarce resource. The teams doing well right now are the ones that noticed the difference.

If your team is working out what this means for how you hire and how you build, I’m happy to talk it through.