Logo Usage Lens
Engineering

The four stages of AI-assisted coding

UsageLens • • 1,193 words • 5 min read
#aiCodingAgents#engineeringPractice
Feature image

You type a description of what you want. The agent writes it. It works. That moment — the first time it really works — is the starting gun.

What follows is a cycle. Most developers go through it in the same order. What differs is the speed.

Stage 1 — Amazement

The first stage is genuine. An AI agent writes real code from a rough description, handles edge cases you didn’t mention, and does it in seconds. In 2026, with modern agents, the code is often good. It compiles. It runs. Sometimes it’s better than what you would have written yourself.

The honest reaction is this changes things. And it does.

Stage 2 — Adoption

Once you’ve seen what the agent can do, the natural next step is to use it more — and then to start more things, because shipping suddenly feels cheap. A side project that would have taken three weekends takes one. A feature that needed a sprint gets done before lunch.

There’s also a social layer. Colleagues are using it, other companies are announcing how much they’re shipping, and the feeling — if I slow down, I fall behind — starts to feel like fact. That pressure is real. But it compounds the enthusiasm in ways that are hard to separate from FOMO.

This is the phase where teams fully commit: management gets briefed, estimates get revised, roadmaps expand. The story becomes the story. And once enough people have repeated it to enough stakeholders, it gets hard to revise.

Stage 3 — Reality check

The code works at the prompt level. The codebase level is a different matter.

After a few weeks or months of heavy agent use, patterns start to show up. Duplicated logic in three places because the agent didn’t know it already existed. Abstractions that almost make sense but don’t quite fit. Edge cases that were handled — but handled wrong. Variable names that sound plausible but mean the opposite of what you’d expect.

The work shifts. Instead of building features, you spend your days reviewing AI-generated pull requests, re-prompting on failures, switching models when one gets confused, and writing fixes for previous fixes. The hours are the same. The output is different — and often harder to reason about than code you wrote yourself.

This stage isn’t a sign that AI tools don’t work. It’s a sign that generated code needs the same review as any code, and that the review is a cost that wasn’t in the original estimate.

Stage 4 — Realization

AI coding tools raise output faster than they raise certainty.

The METR 2026 AI usage survey — self-reported by 349 technical workers — found that developers in early 2026 estimated a roughly 3x speed multiplier and 1.4–2x value increase from AI tools. Those numbers are larger than 2025 estimates, and the trajectory is still rising. Something real is happening.

But the same team’s earlier controlled experiment — where they actually measured completion times rather than asking how fast people felt — found that developers overestimated AI’s effect on their time by about 40 percentage points. There’s a persistent gap between the speed you feel and the speed you can measure. METR is careful to note that 2026 agents are better than the 2025 ones they tested, so the controlled slowdown from that study shouldn’t be taken as the final word. Still, the perception gap is worth taking seriously.

It exists for a reason. Code still needs review. It still needs testing. Someone still needs to own the system architecture — to know why a piece was built the way it was, and what will break when it changes. That work is still done by people, typically experienced engineers, and AI agents don’t make it cheaper.

AI as a code generation tool is genuinely useful. AI as a replacement for engineering judgment is a different claim, and the evidence for that is much thinner.

The experience axis

Here’s what the four-stage description above understates: the speed at which you move through the cycle depends almost entirely on how much experience you have.

A senior engineer has seen bad abstractions before. They recognise the smell of code that works today but will be painful next quarter. They read a pull request and know which parts to trust and which to rewrite before merging. When the reality check arrives, it arrives fast — sometimes in hours, sometimes after a few days of use. Realization isn’t a revelation; it’s a confirmation of something they already suspected.

Junior developers don’t have that pattern library yet. They can’t see what’s wrong with an abstraction because they haven’t maintained one through three refactors. They can’t spot the edge case that was handled wrong because they haven’t debugged that class of bug before. So they stay in the amazement and adoption stages longer — sometimes for many months.

And that stretch is hard. They’re shipping more than they ever have. Managers are pleased. Everything feels like it’s working. Then something breaks in a way that’s difficult to trace. Or a senior colleague reviews their work and points out that the architecture will need to be rebuilt. Or they try to extend a feature and find the generated codebase is a maze with no map.

The disillusionment hits later and lands harder. There’s also more invested in it by then — professional identity, team expectations, months of commits. Walking back the narrative is painful.

Research broadly supports this asymmetry. Studies of junior and mid-level developers find they get the biggest measured productivity gains from AI tools — because they’re getting the most help with things they didn’t know how to do quickly. Getting more help, though, is not the same as building better judgment.

The one thing that changes how this goes

The goal isn’t to skip the cycle. You probably can’t. But you can move through it faster, and with less damage, if you treat the agent as a very fast contributor whose work is always reviewed before it lands. Not with suspicion — just with the same attention you’d give to a strong junior who writes a lot of code but doesn’t always know the full context.

The teams that get into trouble are the ones that let the agent ship directly into production, or that equate “it runs” with “it’s right”. The ones that come out ahead are the ones that keep someone in the loop who knows the difference.

At UsageLens we use AI agents to help write our code — but what works for us is taking smaller, controlled steps and reviewing everything the agent produces. That lets us react early, before a generated shortcut turns into a problem down the road. It’s closer to a lead reviewing a strong junior’s work and gently steering it in the direction we want it to go.

Further reading:

← Back to Blog