Coding agents reward judgment, which is why seniors use them most

Most people have the wrong picture of vibe coding. They imagine a beginner typing wishes into a box and getting an app back. I understand why that story spreads, it's a nice one, but it doesn't match the numbers and it doesn't match what I see when I use these tools myself. In my experience the people who get the most out of coding agents are the ones who already know what good code looks like, which is close to the opposite of the popular image.

The Pragmatic Engineer's 2026 survey on AI tooling, by Gergely Orosz and Elin Nilsson, found that 55% of respondents regularly use AI agents, and the heaviest users were staff+ engineers, at 63.5%. These are the people with the most years behind them and usually the least patience for tools that waste their time. If agents were mostly a crutch for beginners, that group would be near the bottom of the list, not at the top.

Fortune reported on a July 2025 Fastly survey that found senior engineers ship nearly 2.5x more AI-generated code than junior ones, because they're better at catching mistakes before they compound. The same article has the less flattering half too. Nearly 30% of seniors said fixing AI output ate up most of the time they'd saved, against 17% of junior developers.

I believe both numbers, and they don't contradict each other. Seniors ship more because they can tell quickly when the output is wrong, and they pay for it more often because they're the ones who notice and then have to fix it.

Knowing when not to hand the work over

The most useful account I've read of an experienced engineer adopting these tools is Mitchell Hashimoto's "My AI Adoption Journey". He describes six steps, from "Drop the Chatbot" to "Always Have an Agent Running", and two details from it are important.

The first is a line enthusiasts tend to skip. He writes that part of his efficiency gains came from "understanding when not to reach for an agent", because pointing an agent at something it will probably fail at is a waste of time. Yes, that sounds obvious, but you only know what it will fail at if you know the work yourself. It's a judgment call, and a beginner isn't in a position to make it yet.

The second is step five, which he calls "Engineer the Harness". Whenever an agent makes a mistake, you take the time to make sure it never makes that mistake again. Sometimes that means a line in an AGENTS.md file about a wrong command or a wrong API, sometimes it means a script (for screenshots, for example, or filtered test runs) plus an AGENTS.md note so the agent knows the script exists. It's not glamorous work, but it's what good engineers have always done for a new person on the team, i.e. write down where the traps are and automate the checks so nobody has to remember them.

Most of what senior judgment adds happens before and after the typing, and an agent makes that more valuable, not less, because it produces so much more output that someone has to judge. In practice that means scoping the task small enough to verify, spotting the wrong turn in the first twenty lines of output instead of after the last two hundred have piled up, knowing which output to throw away instead of trying to patch it into shape, etc.

Simon Willison has written about this more carefully than almost anyone. In May he described his "disturbing realization that vibe coding and agentic engineering have started to converge" in his own work. I respect that he said it out loud, it would have been easier not to.

I'll admit the same. I skim more than I did a year ago. When the tests pass and the diff looks like what I asked for, I'm tempted to trust it, and most of the time that's fine. The problem is that "most of the time" is exactly where people stop checking, and that's when the rare bad change gets through.

My guardrails don't replace judgment, but they keep it from wearing down quietly over months of things mostly going fine. I make the agent run verification scripts, so "it works" means something specific and not a general feeling. I keep an AGENTS.md that grows every time something goes wrong, the way Hashimoto describes. And I decide how deeply to review a change before I open the diff, so a change to authentication gets read line by line while a change to a button label doesn't. If I decide after reading, the size of the output and how confident it looks end up deciding for me.

Where the judgment comes from

If agents amplify judgment, the more interesting question isn't one for engineers at all, it's one for everyone else. An analyst or an operations lead can now get an agent to build something, and they often know their domain better than any engineer does. What they usually don't have is the software instinct that tells you which output to distrust, which data shouldn't leave the building, and when to stop and ask someone.

That judgment has to come from somewhere. Some of it can live in the platform, through review steps, access rules and a narrow job for each app (that's a large part of what we're building at Workbricks). The rest still has to come from people, which is why I don't expect seniors to matter any less for a long while yet.

Judgment is the key.