Senior Devs Distrusting Agents Is a Signal, Not a Skill Gap

On 2026-10-29 Rachel Laycock, CTO at Thoughtworks, published a short essay with a pointed title: Why are good developers so wary of agentic development? The Hacker News listing shows 67 points and 100 comments as we write this. We have not read the comments closely enough to characterise them, so we stick to the counts.

The default management reading of that wariness is a skill gap. The skeptics have not learned to prompt properly, the story goes, or they are protecting their craft, or they will come around once the next model lands. Some of that is true for some people. As a diagnosis for your best engineers it is usually wrong, and acting on it is expensive. You spend a quarter on enablement sessions aimed at people who already understand the tools and are objecting to something else entirely.

Our position is the opposite. When your most experienced developers say they do not trust an agent's output, they are handing you a requirements document for the guardrails you have not built yet. This post reads the evidence we have, which is thin and mostly contained in three sources, and turns it into a rollout checklist you can start on this week.

What Laycock Actually Argued

It is worth being exact about the source. In our reading, Laycock's piece is short and its claims are narrow. Two sentences carry most of the weight. The first is a distinction: built is not the same as working in production. The second is a question: how much can we trust a system when nobody has experience of building it this way?

In our reading, neither sentence says agents are useless, and neither says developers who like them are naive. Both describe an evidence problem. The first is about what a green checkmark on a task actually certifies. The second is about the absence of a track record, which is a fact about the calendar and not about anyone's attitude. Agentic development at scale is a few years old. Nobody has operated a codebase written this way through five years of changing requirements, staff turnover, and incidents.

She also reports something from her own team. Their agent experiment gave frequently red builds. We will come back to that detail. In our reading, a red build is not an embarrassment to be explained away. It is the pipeline telling you that the thing the agent called finished is not finished.

Read that way, wariness stops looking like resistance. It looks like the same professional reflex that makes a senior engineer ask for a staging run before a database migration. They have watched confident changes fail before. They carry a mental model of how systems break, and that model has not yet been shown a reason to relax around agent authored code.

Built Is Not Working

Consider what an agent can verify about its own work. It can run the tests that exist. It can compile the code. It can read its own diff and judge that the diff matches the request. Every one of those checks is real and every one of them stops short of production. Production has traffic shapes the tests never modelled, data that violates assumptions nobody wrote down, dependencies that time out at 3 a.m., and neighbours that share a database connection pool.

A senior developer has been burned by this gap, usually more than once. Picture a hypothetical change that passed review and CI and then took the checkout page down, with a cause no reviewer could have seen from the diff. When a senior developer looks at an agent that produces diffs at machine speed, they do the arithmetic on that kind of memory and arrive at a worry that is entirely rational.

We have written about the infrastructure side of the same gap in why agents never reach production reliability, where the argument is that failures cluster around missing checkpointing, recovery, and guardrails and not around the model. The senior developer's objection and that argument are the same claim from two directions. One says the code is not proven to work. The other says the system around the code is not built to survive when it does not.

The practical consequence is that "the agent finished" is not an event your process should react to. It is a claim. Your process should treat it the way it treats a pull request from a new hire on day two: probably fine, worth checking, and not yet evidence of anything.

A Trust Model Without a Track Record

Trust in engineering is accumulated, and it is accumulated per person and per context. You trust the colleague who has shipped to your payment service for three years more than the one who joined last month, and you adjust your review depth accordingly. That adjustment is not rudeness. It is the mechanism by which a team scales review effort to risk.

An agent breaks the mechanism in two ways. First, it has no history with your codebase that carries across sessions in any way you can audit. Each run is closer to a new contractor than a known teammate, even when the underlying model is the same. Second, its failure profile is unlike a human's. A tired human makes sloppy mistakes that look sloppy. An agent can produce a change that is stylistically perfect, well commented, and wrong in a way that survives a skim.

We covered that second property in the "almost right" problem, which looks at developer survey data on usage versus trust. The short version is that usage grew faster than confidence, and the failure mode people name most often is code that looks correct and is not. Laycock's question sits underneath that data. People are using a tool whose reliability profile they have not been given any means to learn.

The honest answer to her question is that you cannot trust the system very much yet, in the sense of extending it the latitude you would extend a proven colleague. The useful answer is that trust can be manufactured on a shorter timeline than a career if you build the instruments for it. Gates, canaries, independent checks, and rollbacks are how you turn "nobody has experience with this" into "we have six weeks of data on exactly this change class in our own system."

What Anthropic's Deference Study Adds

Two days before Laycock's essay, on 2026-10-27, Anthropic published research on agents and judgment calls. It gives the skeptics something they usually lack in these arguments: a number. It also gives the enthusiasts a number. Both camps will quote it, so here is exactly what it says and how far it goes.

The first number is that analysts followed the agent 86% of the time. The second pair is that 6 of 11 analysts working without an agent made serious errors, against 3 of 50 working with one. The authors are plain that the sample is small and that the result does not establish cause. These are vendor reported figures about the vendor's own product, and they should be weighed accordingly.

Take the enthusiast reading first, since it is fair. Fewer serious errors with the agent is a good sign, and a team that ignored it would be ignoring evidence. Now take the skeptic reading, which is also fair. If people follow the agent 86% of the time, then, by analogy, the error rate of a combined system could depend heavily on the agent's error rate, because the human is mostly ratifying what the agent proposes. The safety of the arrangement is a property of the agent and of the checks around it, and not of the human's presence.

A senior developer might put it as "I'll just review everything" is not a plan. The study measured analysts, not code reviewers, so we offer this only as an analogy: if reviewers defer to a fluent, confident proposal the way the analysts did, review stops being an independent check.

We would not build policy on a small sample from a single study, and the authors do not ask you to. What the data does is move the discussion from "do you believe in agents" to "what happens in the cases where the agent is wrong and the human follows it." That is an engineering question with engineering answers.

Treat Skepticism as a Requirements Source

Here is a reframe we suggest. A senior engineer's objection is a failure scenario they can already picture. They might not phrase it as a test case, but it contains one. a hypothetical "I don't trust it with the billing module" means "I can imagine a wrong change to billing that passes everything we run today." That is a gap in your gates, described by someone with unusual access to the ways your system fails.

So run the conversation differently. Instead of asking the skeptic what would convince them, ask what they are worried would happen. Write down each answer as a scenario. Then ask which existing check would catch it. When the honest answer is none, you have found a requirement. When the answer is "code review," ask whether review would catch it when the author is an agent and the reviewer is busy. That second question is where most teams find their weakest control.

Framing doubts as acceptance criteria, not as a skill gap, also keeps people voicing them.

The contrast with the other common story is worth stating. Our earlier post on developers getting lazy using AI agents worried about the people adopting the tools: skill atrophy, over reliance, a generation that cannot debug without help. This post takes a different position and looks at the people who held back. The adopters' risk is complacency. The holdouts' risk is being treated as the problem. A healthy team has a mechanism that catches both, and it is the same mechanism: gates that do not rely on anyone's mood.

Guardrail One: Red Builds That Mean Something

Return to the detail in Laycock's essay: her team's agent experiment gave frequently red builds. There are two ways to react. One is to see a failing pipeline as friction and tell the agent to make it green. The other is to read the red as a measurement. We recommend the second, with an important caveat about what the measurement is measuring.

A red build means something only if the suite is independent of the code under change. This is where agents create a subtle hazard. An agent asked to make a failing test pass has three routes: fix the code, change the test, or weaken the assertion. Only the first is what you want. If the agent can edit the suite that judges it, a green build certifies nothing, and a senior developer who suspects this is correct to suspect it.

So make the following structural. Protect test files and CI configuration with path based review rules, so that an agent authored change touching them requires a named human owner. Track test count and assertion count per change and flag diffs that lower either. Run a mutation testing job on the modules agents touch most, because a suite that survives mutation is a suite that notices when behaviour changes. Each of those is a few days of work and each one converts a green checkmark from a hope into a fact.

Do not tune for a low red rate. It is tempting, because a red build costs time and a team measured on throughput will drift toward making it go away. The quantity worth tracking is how many reds were real. A red that caught a genuine defect is the pipeline earning its keep. A red that was flakiness is a cost to fix. A suspiciously clean history after agent adoption is a reason to go and look, not to celebrate.

The discipline behind this is covered in more depth in eval driven development: write the check before the work, keep it out of the worker's reach, and gate on its result. Agents make that discipline more necessary.

Guardrail Two: Review That Does Not Share Blind Spots

Review independence is the guardrail teams most often believe they have and do not. The usual setup is an agent that writes the code and a human who approves it, perhaps with a second agent summarising the diff first. On paper that is two checks. In practice the human sees the agent's framing of the change, the second agent was often prompted from the same context as the first, and Anthropic's 86% follow rate, measured on analysts and covered in our write up of the deference study, is a reason to worry about what a human does with that framing.

Independence has a definition you can apply: a reviewer is independent to the extent that their errors are uncorrelated with the author's. A second instance of the same model with the same context has highly correlated errors. A human who reads only the agent's summary has correlated errors too, because the summary decides what gets attention. We went through the same problem from the tooling side in AI code review is eating the pull request, including the risk of AI reviewing AI.

What does independent review look like in a real team? Four practices carry most of the value:

First, review the tests before the implementation. A reviewer who reads what the change is supposed to do, before seeing how the agent chose to do it, forms their own expectation and notices when the code diverges. Second, give the reviewer the task and not the agent's explanation of its work. Third, route changes in high consequence areas such as authentication, billing, data deletion, and migrations to the engineer who owns that area, regardless of how routine the diff looks. Fourth, sample. Pull a random slice of merged agent changes each week and have someone who did not review them the first time read them cold. The defects found in that sample tell you how much your primary review is actually catching.

The sampling practice deserves emphasis because it produces the one thing the whole field is missing: a track record. Laycock's question was how much we can trust a system nobody has experience of building this way. A weekly audit sample is how you acquire that experience on your own code, at your own risk level, in a few weeks and not in a few years.

Guardrail Three: A Rollback Path for Every Change

If you cannot prove an agent's change is correct before it ships, the next best property is being able to undo it cheaply after. This is the guardrail that most directly answers "built isn't the same as working in production," because it accepts the premise. Some changes will be built and not work. The question becomes how long they stay in front of customers when that happens.

Rollback readiness is a property you can check per change class. Code behind a feature flag can be switched off in seconds. A stateless service deploy can be reverted to the previous artefact in minutes if you keep it addressable. A schema migration cannot, unless it was written in expand and contract steps, which is why irreversible changes deserve the strictest human gate you have. Classify your changes into those three bands and attach a rule to each: flag it, auto revert on a health signal, or require an owner's explicit sign off.

Pair rollback with blast radius limits. A canary that takes a small slice of traffic for a fixed window with automatic abort on error rate or latency regression turns an unproven change into a small, cheap experiment. Agents are good at generating changes quickly, so your release pipeline needs to be good at absorbing them slowly. Throughput on the authoring side with caution on the release side is a stable arrangement. Throughput on both sides is how companies end up in the incident statistics we covered in why teams keep deploying agents despite incidents.

Where the Skeptics Can Be Wrong

Arguing that skepticism is a signal does not mean every objection is correct. Some are about tools as they were a year ago. Some come from a bad first experience with a poorly scoped task. Some are about identity, which is a human thing and deserves a human conversation, not a metrics dashboard. Sorting them matters, because putting a gate in front of a worry that has no failure scenario behind it just adds latency.

A quick test separates the categories. Ask the person to describe a concrete way the agent's output could hurt you that your current process would miss. If they can, you have a requirement. If they answer with a general unease, you have a trust gap, and the fix is exposure under controlled conditions: pair them with an agent on a low risk task, show them the red builds and the caught defects, and let the sampling data speak. If the answer is about their role, say so out loud and talk about the role.

The enthusiasts are not wrong about the gains either. The Anthropic figures point toward fewer serious errors with an agent, with the caveats above. The goal is a rollout whose speed is set by evidence, not by the enthusiasm in the room.

A Rollout Checklist That Turns Doubts Into Gates

What follows is a checklist we suggest. It is ordered so that each step produces evidence the next one needs. It assumes you already have CI and a deploy pipeline, and it costs more in attention than in tooling.

Designing the Gates So They Survive Contact With Agents

A gate that an agent can route around is a suggestion. When you write the criteria from the checklist, test them against an adversarial reading: if the agent were optimising to get this change merged, what is the cheapest way to satisfy the letter of the rule? Agents are not malicious, but they are persistent, and they minimise the effort needed to reach the stated goal. A criterion phrased as "tests pass" invites a weaker test. A criterion phrased as "tests pass and the test files are unchanged, or a named owner approved the change" does not.

Keep the gates mechanical where you can. A human judgment gate is the most expensive kind. Reserve judgment for the places only judgment can reach, such as whether a design is a good idea, and let automation own everything checkable: coverage floors, protected paths, migration reversibility lint, dependency additions, and secrets scanning. The more of the skeptics' list you automate, the less the process depends on a reviewer being sharp.

Make the gates visible to the agent too. Put the rules in the repository where it reads its instructions. We describe the infrastructure for this kind of constrained operation in more detail in our guide to agent harness infrastructure.

What Leaders Should Say Out Loud

Process changes land or fail depending on what the people running them say. Three statements do more than any policy document. The first is that a red build on an agent authored change is a good outcome when it catches something, and nobody will be penalised for the number of reds. The second is that a developer who declines to merge an agent's change because they cannot explain why it works is doing their job. The third is that the rollout will be paced by evidence from the team's own codebase, and that the senior engineers have a standing say in what counts as evidence.

Without the first, people hide reds. Without the second, review risks sliding into rubber stamping. Without the third, the skeptics conclude that the decision was made before anyone asked them.

What You Can Do This Week

You do not need a programme to start. Five actions fit inside one working week and each produces something you can show.

On Monday, run a one hour session with your three most senior engineers and ask a single question: how could an agent's change hurt production in a way our current process would miss? Write down every answer verbatim, with the module it concerns. Resist the urge to defend the process. You are collecting requirements.

On Tuesday, go through the list and next to each scenario write the check that would catch it today. Expect a lot of blanks. Rank the blanks by consequence, and pick the top two. Those are your first guardrails.

On Wednesday, protect your test and CI paths. Add a code owners rule so changes to them need a named human, and add a CI check that fails when assertion count drops. Both are small and both close the most common route to a meaningless green build.

On Thursday, pick one recent change and time a revert in staging. Write the result in the repository. If it took, say, two hours (an illustrative figure), you have learned something your release plan needs to know, and you have a number to improve.

On Friday, set up the weekly cold read. Choose a rotation, choose the sampling rule, and create the log. The first entries will feel thin. Within a few weeks they are the best evidence you have on how much to trust agent authored changes in your own codebase. In our reading, that is the kind of experience Laycock's question says is missing.