What you pay for when an agent writes the code

A founder of an HR platform wrote on LinkedIn in September that developer salaries are falling for one group only. The other group, people who understand architecture, can frame a problem, try more than one tool and deliver in a week what used to take a month, gets offered more, he says. I agree with the split. One role is missing from it: whoever checks that the fast result can go to production, and takes responsibility for it. Speed is the cheap part now. It is included in the price of the tool. I build my own apps with several coding agents, and my own hours in that work sit exactly where the post is silent.

What the post says a company should buy

The post ends with advice: hire a developer who understands AI, budget for tokens, and cut where you see the least added value. The comments fill in the other side. One person described the brief he now hears from management: throw it into AI and you have it. Others wrote about companies that want a few seniors and agents instead of a team.

The post describes well what makes building faster. Architecture, problem framing, more tools. All true. It does not say who then decides that the output is fine, and in my practice that is the part that does not shrink with speed. In one run I describe below, the agents finished seven tasks. I was then left with four to six hours of reading and deciding, and without them nothing from that run would have shipped. When someone promises a week instead of a month, I ask who reads the diff in that week.

One run, seven tasks

On 11 September 2026 I had seven open tasks in Linear for my own site: a CV item in the navigation, a restyle of the Insights filters, gaps in the 404 page, a split of the e2e suite, identity in the hero, an audit of the page heroes and a document for one decision about the CV. I put four agents on them: Claude Code as the controller, and under it Codex CLI 0.153, GitHub Copilot CLI 1.0.82 and Mistral Vibe 2.23. Each task got its own git worktree and a list of files it may touch. None of the worker agents could use git, run a build or read environment secrets. The build and Playwright ran only in a pinned container on my machine.

Two of the seven tasks died before they began. Codex hit its usage limit after reading the repository rules, before its first edit. I re-routed them to Claude subagents, not to a more expensive model.

When the agents finished, my part started. I read every diff myself, and every diff also went to a second reviewer from a different model, read-only. I do not take an agent's summary as evidence, because it was written by the party that wants the change to pass. The reviewer found two things that were fixed before the pull requests were opened: the filters had a touch target under 44 pixels, and one change to the headers had a mistake I come back to below. I refuted two more of its objections by running the tests.

The cost of that run on my side: four to six hours of review and integration (an estimate, not a stopwatch) and six runs of the pinned container. The full matrix of four browsers takes 30.8 minutes, confirmation runs take two to four, and the container serialises everything. The result: seven pull requests, all green in CI. The merge stayed with me.

The agents did the fast part. Seven pull requests cost me half a day of human reading; it is the only ratio I have measured, and it comes from one run on my own site. What I would hold in general is narrower: the person who reads must not be the one who wrote it.

What surfaced in that run

The filter restyle was purely visual. The plan for it said the filters must have a URL contract: click a topic, the address gets a parameter, the page re-renders. An agent wrote an e2e test for that. The test failed in CI and in the container, but only for the first click from the page without a parameter. The address changed, the page did not update, and the network log showed no request. Next served the navigation from its prefetch cache and never fetched the dynamic page.

I ran the same probe against production. Same thing. The bug had been live before this task and nobody saw it, because the Insights section shows an empty state either way for now. I did not weaken the test. I fixed the cause, prefetch off on the filter links, and a component test has guarded that since, so a later "optimisation" cannot bring it back. The next run, 273 tests in Chromium, passed.

Someone in the thread described the reaction he gets to his work with AI: the AI did it anyway, so what. That test existed because the task said what the change must guard, and it found me my own old bug. Had I weakened it to pass, the bug would still be running in production.

Where I was wrong

The first run of the full matrix: 564 tests passed, 87 failed. Of those, 81 were in WebKit, spread across booking, the CV, navigation, the language switcher, the 404 pages and control geometry. A button that should be 52 pixels measured 30.

A probe inside the container showed something else. The stylesheets were registered but no rule applied, the page did not hydrate, and the console said "Error performing TLS handshake" for every asset. One cause. The app sends a Strict-Transport-Security header and a CSP upgrade-insecure-requests directive. Chromium and Firefox ignore both on http://localhost; WebKit does not. Every stylesheet and script went to https, where nothing listens.

I fixed it at the source, so that a gate across several browsers could exist at all. And the first version of my fix was wrong. I dropped the headers whenever the server address did not start with https. But the headers are evaluated at build time, and the production image only receives its address at runtime. Production would have lost HSTS, silently. The independent reviewer caught it while reading the diff; that is the header mistake mentioned above. The final condition is the reverse: the headers are omitted only when the address explicitly says http://; a missing value keeps them.

The second WebKit run: 128 tests passed, one failed, one was flaky. The failed one tested a high-contrast mode WebKit does not have, and is skipped there. The flaky one sampled a 200-millisecond transition once; now it polls. It cost a day on one cause instead of seven tasks. Independent review has to cover the verifier's own fix too.

How to tell "done" when an agent writes the code

The post says companies need a token budget. They do. But tokens are not the only new cost, just the easiest one to put a number on. This is the list I built for my own site, and a team can set it up on its own:

• Give every agent task its own worktree and a file list. An agent never has git or a deployment.
• Have the diff read by a person who did not write it. The agent's summary is not evidence.
• Put a second reviewer from a different model on every diff, read-only. I still decide which findings hold: in one review I accepted three of ten suggestions on copy and three of four on tests. Eight of fourteen did not survive checking.
• Keep one set of gates before the word "done": tests, type check, lint, format, build, production smoke. Run the e2e suite on more than one engine; mine is 27 spec files against four browsers including mobile Chrome. Run pixel comparison against the design on one engine only, because each engine renders slightly differently and a pixel difference between engines is not a bug in the site.
• When a whole engine fails, look for one cause, not eighty. A probe for missing assets is faster than reading eighty assertions.
• Never weaken a test to make it pass. If it fails, it has either found a bug or it measures the wrong thing; both are work, neither is a reason to switch it off.
• Never deploy to production without the manual sign-off of one named person. Mine: branch off dev, pull request into dev, pull request from dev into main, and the deployment waits until I approve it. Whether an agent wrote the code or I did.

Without outside help this gets stuck in two places: when nobody is named as responsible for the release, and when agents were added faster than the people who read their diffs. The first you check by asking who signed off the last release. The second shows up in one ratio: how many pull requests were created per day and how many of them somebody read in full. One reader has a ceiling. Once the number of pull requests per day goes above it, you need a second reader, not a faster agent.

What I do on the first day

Everything I describe here is from my own site, where I am my own lead. If I joined a company tomorrow that is dealing with this, I would not start with agents. I would start with how the company recognises "done" today: which tests exist, what CI runs, who approves a deployment and whether anyone does it by name. Only then would I bring in agents, because without a gate agents just produce unread work faster.

When I disagree with the team lead, say they want to ship an agent's output without the e2e suite, I hold the gate. Without verification I do not sign off "done", even if that means a delay. When I leave, I hand over three things: the working rules in the repository that agents and people read before every task, the decision records with their reasons, and the e2e suite that guards the approved behaviour after I am gone.

A team can set up everything above on its own; nothing in that list needs me. At the two points where the list gets stuck, you need a person who is responsible for the release. That is the work I do.

I build frontend systems for products that have to last. Open to senior and lead frontend roles in Prague or remote (EU), employee or contract.