{"slug": "your-engineers-are-not-slow-your-review-queue-is", "title": "Your engineers are not slow. Your review queue is.", "summary": "A developer argues that coding agents have cut the time to write a change from hours to minutes, but the review step has not moved, so teams with fixed review capacity ship the same number of changes while a growing queue of unreviewed code piles up. The piece cites detail.dev's finding that orgs offloading work to agent armies saw disappointing results, and notes vendors like Macroscope now pitch auto-approving around 40% of pull requests, which the author calls the wrong objective function because the human reviewer is the accountability.", "body_md": "*Every team that bought coding agents this year got the same result: the generation side of the shop sped up ten times and the shipping rate barely moved. The constraint moved to the one seat nobody re-engineered, and it is the seat with a person in it.*\n\nStart with the concession, because it is true and it is the whole reason this matters.\n\nCoding agents work. The team at detail.dev put it as plainly as anyone this week: agents can\n\noneshot games that are actually fun, and with the right guardrails they execute migrations and\n\nlanguage rewrites in complex codebases that would have been a quarter's work two years ago. Theo\n\nBrowne spent an entire video this week arguing that if you cannot tell the difference between this\n\nyear's frontier models and last year's, the problem is your prompting, and he is mostly right. The\n\nceiling on what a single engineer can emit in a day has gone up by an amount that is genuinely hard\n\nto describe to someone who has not sat in front of it.\n\nAnd yet the same detail.dev post opens with the sentence every engineering manager has been\n\navoiding saying out loud: a lot of orgs spent the first half of this year offloading as much work as\n\npossible to armies of agents, and the results have been disappointing. Mountains of dubious code, no\n\ntsunami of incredible software. They call it the trough of disillusionment. We would call it\n\nsomething more boring. The factory got a faster machine at one station and nothing else changed.\n\nHere is the shape of a change to production software in 2024, roughly, in the units that matter:\n\nminutes of a human's attention.\n\nSomebody spends four hours writing it. Somebody else spends twenty minutes reviewing it. A machine\n\nspends six minutes testing it. Somebody spends five minutes deploying it. The human write step\n\ndominates, so every tool of the last fifteen years attacked the write step: better editors, better\n\nlanguages, better frameworks, and now agents.\n\nNow the write step takes twelve minutes. Not four hours. The agent drafts, the engineer steers, and a\n\nchange that used to be an afternoon is a coffee. Which means the engineer produces, on a good day,\n\nsomewhere between five and fifteen times as many changes as before. Every one of them still needs\n\ntwenty minutes of somebody else's attention before it ships.\n\n*The write step shrank by an order of magnitude; the review step did not move. Minutes are illustrative for a mid-sized change; the ratio is what every team we have talked to describes.*\n\nDo the arithmetic once and it stops being a vibe. If the review capacity of a six-person team is\n\nfixed at, say, forty reviews a day, then the team ships forty changes a day whether the engineers\n\nproduce forty or four hundred. The other three hundred and sixty sit in a queue. Engineers notice the\n\nqueue, so they stop producing, or they start rubber-stamping each other, or they merge their own\n\nwork at six in the evening when nobody is looking. Every one of those behaviours shows up in the\n\nincident log within a month.\n\nThis is why the productivity numbers are so confusing. The individual is faster. The system is\n\nproducing the same amount of finished software as before, with worse review. Both things are true.\n\nLook at what the tools industry did in response. It built more agents. Agents to write the tests,\n\nagents to review the pull request, agents to fix the review comments, agents to review the fix.\n\nSome of it is good. Fireship's sponsor this week, Macroscope, says its review tool now auto-approves\n\nforty percent of pull requests across its customers, which is a vendor claim from a sponsor segment\n\nand we would treat it as exactly that, but it tells you where the market thinks the money is. The\n\nmarket thinks the answer to a review bottleneck is to remove the reviewer.\n\nWe think that is the wrong objective function, for the same reason it was wrong in the back office.\n\nThe human in the review seat is the accountability. When the change breaks production, somebody\n\napproved it, and that somebody has a name and a manager and a memory of what they were told. An\n\nauto-approval does not have a memory. It has a log line. You can automate the reading of a diff;\n\nyou cannot automate the standing-behind of one.\n\nSo the question is the one detail.dev asks at the end of their piece and then does not quite answer:\n\nwhen the software mostly drives itself, what do the engineers do? Our answer is not glamorous. They\n\nreview. And the entire engineering problem of the next two years is making that review seat fast\n\nenough to keep up with the machines feeding it, without turning it into a stamp.\n\nWe have written before about the eight-second decision, and the number is not rhetorical. It is\n\nroughly the time a competent reviewer needs to accept or reject a change when everything they need\n\nto know is in front of them and nothing they do not need is. Almost no review tool is built for that\n\nnumber. They are built for the twenty-minute review, which was designed for human-written code where\n\nthe intent had to be reverse-engineered from the diff.\n\nAgent-written code has a property human-written code never had: the intent already exists in\n\nwriting, because somebody typed it into a prompt. The specification, the plan, the reason for every\n\nchoice, the tests it ran, the things it decided not to do. All of that is sitting in a transcript\n\nthat the review tool throws away. The review seat is slow because it is being asked to rediscover\n\ninformation the system already had.\n\n*What the reviewer needs in front of them for an eight-second decision, and where each piece already exists today (nowhere in the pull request).*\n\nFive things. The request, the plan, the verification, the blast radius, and the list of things the\n\nagent decided it was not sure about. That last one is the one nobody surfaces and the one that\n\nmakes the decision fast, because a reviewer who can see \"the agent was unsure about the retry logic\n\nand left it as before\" knows exactly where to spend their eight seconds.\n\nThe harness study that hit Hacker News this week is interesting in this light. Nine researchers ran\n\n176 matched configurations across four models on SWE-Bench Verified and Terminal-Bench, varying\n\nplanning, action space and context management. One of their findings is that for stronger models,\n\nexplicit planning stopped improving accuracy and became mainly a cost saver. Read as a review\n\nproblem rather than a benchmark problem, that says the plan is cheap to produce and does not hurt\n\nthe agent. Which means there is no excuse for it not being attached to the pull request, because it\n\nis the single most useful artefact a reviewer could have and the model will write it for nothing.\n\nMeasure the queue. Not the cycle time, which averages away the problem, but the number of changes\n\nwaiting for a human and how long the oldest one has waited. If that number is growing week over week,\n\nyou have the disease and no amount of model upgrades will treat it.\n\nThen re-engineer the seat rather than removing it. Attach the prompt and the plan to the pull\n\nrequest, automatically, as the description. Make the agent state what it verified and how, in a\n\nfixed format, at the bottom. Make it list what it was unsure about. Route by blast radius: a change\n\nthat touches one file and no data can go to a fast lane with a fast reviewer; a change that touches\n\nbilling goes to a slow lane with a senior one. Give reviewers a budget of decisions per day rather\n\nthan a queue of infinite length, and watch what happens to the quality of the decisions.\n\nOne more thing worth stealing from manufacturing, since the factory metaphor is doing so much work\n\nhere. A line with a bottleneck station is run at the pace of the bottleneck, on purpose, and the\n\nupstream stations are told to stop rather than pile up inventory. Software teams do the opposite:\n\nthey celebrate the pile. A hundred open pull requests is not throughput. It is inventory, and\n\ninventory decays, because the codebase underneath it keeps moving and every day a change waits is a\n\nday closer to a merge conflict and a re-review. Cap the queue. Let the agents idle. It feels wrong\n\nfor about a week.\n\nAnd resist the auto-approve until you have done all of that. Not because the tools are bad but\n\nbecause auto-approving forty percent of changes into a system with no fast human lane for the other\n\nsixty is how you get a queue of the hardest sixty percent with the least context, reviewed by the\n\nmost tired people. The machines will keep getting faster on a schedule you do not control. The seat\n\nis the only part of the pipeline you actually own.\n\nThe engineers were never the slow part. The place where a person has to say yes is the slow part,\n\nand it was always going to be, and the job now is to make yes cheap without making it meaningless.\n\n*Originally published on the [Levelbrook playbook](https://ai.levelbrook.com/playbook/your-engineers-are-not-slow-your-review-queue-is/). Levelbrook is a principal-led Rails and AI-systems consultancy; the playbook is where we write down what we see.*", "url": "https://wpnews.pro/news/your-engineers-are-not-slow-your-review-queue-is", "canonical_source": "https://dev.to/levelbrook/your-engineers-are-not-slow-your-review-queue-is-948", "published_at": "2026-09-21 14:11:34+00:00", "updated_at": "2026-09-21 14:32:41.605210+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "ai-products"], "entities": ["detail.dev", "Theo Browne", "Fireship", "Macroscope"], "alternates": {"html": "https://wpnews.pro/news/your-engineers-are-not-slow-your-review-queue-is", "markdown": "https://wpnews.pro/news/your-engineers-are-not-slow-your-review-queue-is.md", "text": "https://wpnews.pro/news/your-engineers-are-not-slow-your-review-queue-is.txt", "jsonld": "https://wpnews.pro/news/your-engineers-are-not-slow-your-review-queue-is.jsonld"}}