AI Writes 100% of Our Code. Here's What Nobody Tells You.

Fri Jul 17 2026

I split my professional life between two worlds. In one of them, the development process is 100% based on AI: agents write the code, agents review it, agents open the pull requests — production software for several companies, built this way every day. In the other, I manage a backend team that works the traditional way: skilled engineers, local environments, AI as an assistant.

Living in both worlds at the same time gives me a comparison most posts about "AI coding" don't have: real production work on both sides of the fence.

We are currently testing our automated process head-to-head against local development done by strong engineers with a good set of skills. These are my notes so far.

What's genuinely better

The process runs unattended. This is the one that changes the economics. You write a good task definition, and the implementation happens while you're in a meeting, reviewing something else, or sleeping. Your job shifts from producing code to reviewing outcomes. The cost of a feature stops being "engineer-hours typing" and becomes "minutes of definition plus minutes of review".

Parallel development is free. A human pays a heavy price for context switching; an orchestrated fleet of agents doesn't. We routinely have several features and fixes moving at the same time for different clients. Nobody is "blocked on the one person who knows that module".

Standardization stops being a fight. Every team has coding guidelines; almost no team follows them consistently, because enforcement happens in code review, socially, one nitpick at a time. Agents follow the guidelines every single time — the standard lives in the process, not in someone's patience. Our internal framework conventions are applied with a consistency I never achieved with humans, myself included.

Everything is measurable. Every task leaves a trace: how many iterations it took, what the review found, where the definition was ambiguous. We collect these stats team-wide and use them to recalibrate — better task templates, better guidelines, better review checklists. Try doing that with human development without everyone hating you.

Measurement matters more than it sounds, because feelings lie. METR ran a randomized trial where experienced open-source developers were 19% slower with AI tools — while estimating afterwards that AI had made them 20% faster. Whatever side of that result you land on today, the lesson is the same: if you're not measuring your process, you don't actually know what it's doing.

What genuinely hurts

Small changes got slower. This is the async tax. When a developer has the code open in their editor, "move that button, rename that field" is a 30-second fix. In an async agent process, the same correction is a full round-trip: write the instruction, wait for the run, review the result. For small corrections, latency dominates everything.

You see errors after the implementation, not during it. A developer typing wrong code often notices in the moment — the types don't fit, the test goes red, something smells. In an async process, a wrong assumption surfaces when you review the finished work. The mistake is the same; the feedback loop is a full cycle longer, and a wrong direction costs you the whole iteration.

Testing locally is more painful than it should be. When the agent's work lands in a branch, verifying it means fetching the branch, installing dependencies, reproducing the environment, running the flow. The engineer who wrote the code locally already had all of that warm. Today this friction is real, and it pushes teams to trust the diff more than the running software — which is exactly the wrong instinct.

Where I think this ends

The honest observation is that the pros are structural and the cons are tooling. Unattended, parallel, standardized, measurable — those are properties of the model itself. The async tax, the late error detection, the painful local verification — those are engineering problems: better preview environments, faster loops, agents that run the app and show you the result instead of handing you a branch.

The industry data points the same direction. The 2025 DORA report found AI adoption among developers at 90%, with a positive relationship to delivery throughput — but also more instability, and 31% more PRs merging with no review at all. Their core finding matches our experience exactly: AI doesn't fix a team, it amplifies whatever process is already there. That's why the standardization and the stats above matter more than the model you pick.

Structural advantages tend to win once tooling catches up. That's my bet for the market: not "AI replaces developers", but the bottleneck moving from writing code to specifying and verifying it. The valuable skill is becoming what we'd call a good tech lead's skill set — defining problems precisely, reviewing critically, designing the process — applied at a scale one person never had before.

I don't think local development with a strong skill set disappears; for tight-loop, exploratory work it's still clearly better, and our own comparison reflects that so far. But for well-defined, standard, parallelizable work — which is most of the backlog in most companies — the automated process is already competitive, and it improves every month while human typing speed doesn't.

And our jobs?

I don't buy the apocalypse. Some people predict engineers being replaced entirely, and that's simply not what the day-to-day looks like: someone still has to define the problem, judge the trade-offs, review critically, and own the outcome. That someone is an engineer, and I don't see that changing.

But I'd be dishonest if I told you nothing changes. My honest read is harder to hear: the number of open positions will decrease considerably, and the level of knowledge required to get a decent one will be higher. The middle of the market — turning well-specified tickets into working code — is exactly what automates first, and that's where most job offers used to live. The engineers who thrive will be the ones who can do what the process can't: specify precisely, verify ruthlessly, and decide well.

We'll keep running the experiment. When we have numbers worth sharing from the automated-vs-local comparison, I'll publish them here.

References