Why good developers are wary of agents: HN argued trust, then talked about evidence

Rachel Laycock, CTO at Thoughtworks, asked a fair question on her blog: why are the developers who usually adopt new practices first holding back on coding agents? Her answer fits in the TL;DR: their caution "comes from knowing that built isn't the same as working in production." The Hacker News thread ran to 140 comments from 90 people. Our read: the thread framed it as trust and accountability, but the comments that moved the argument were about evidence, and specifically about what a team checks before a change merges, whoever wrote it.

The question underneath

Laycock lists the questions experienced developers still ask of agent output: "Are we confident this is the right behaviour? Does it work as expected?" and "What happens when something fails?" Then the bigger one: "How much can we trust a system when nobody has experience of building it this way?"

We counted what the thread talked about. Of the 140 comments, 15 mention tests or testing, 14 review, 10 accountability, 7 production, 4 proof, and only 2 the word "verify" or "verification". The thread kept circling the people and rarely named the check.

Camp 1: a passing test is evidence, not proof

The sharpest comment was four lines from Jaygles: "LLMs can only produce evidence. Producing proof requires a human" (Jaygles). They split developers into those who require proof before shipping and those who do not.

matt3210 named the habit that worries them: "I'm weary of the culture of ship it if it passes tests even if someone (a reviewer) has concerns" (matt3210). treespace8 lumped test-driven development in with agents as practices that dilute trust, summarising TDD as "The test pass, so my software is good" (treespace8). That drew pushback for its unfairness to TDD, but the parody describes a real failure: a green run read as a verdict on behaviour.

Camp 2: accountability, and who it belongs to

treespace8's opening line, "Software works because someone is accountable for it", started the longest sub-thread. CodeMage moved it somewhere useful: "you need to establish accountability for quality, not for individual changes" (CodeMage). pls-dnt-deploy gave the management version: "You can delegate responsibility, not accountability" (pls-dnt-deploy).

Both point the same way. An agent can carry responsibility for a change. Someone still owns the system of checks that decides whether the change was right, and that system is what makes the change trustworthy.

Camp 3: regimes instead of reading

x3haloed made the strongest pro-agent case: "if your verification, testing, and observability regimes are good enough, the exact implementation shouldn't matter" (x3haloed). The reply from 4b11b4 is the most useful line in the thread: "those regimes you list aren't likely going to be done by accident" (4b11b4).

Others sketched what such a regime looks like. luc_ imagined "a system that sits on top of that and pokes and prods the binary to see if it behaves like it's supposed to" (luc_). louiereederson suggested "broader/deeper observability attach and synthetic user monitoring" to "offset some of this" (louiereederson).

roncesvalles gave the reason reading still matters: "The process of reading what you wrote both elucidates something more about the problem, and elicits from you some aspects about the program's behavior that you do care about but didn't consider before" (roncesvalles). A regime only checks what someone thought to write down, and reading is where many of those expectations come from.

Camp 4: how the careful ones actually work

mrweasel reported what they see from their strongest colleagues: "They outsource certain tasks to the AI and verify the output" (mrweasel). graemep gave both halves of the experience: Claude "constantly makes incorrect assumptions, or implements the wrong thing", and it is also "VERY fast at finding and fixing some bugs" (graemep).

gopalv had the best analogy, from years of summer interns: "if an intern can bring down production, it is not the intern's fault" (gopalv). The guardrail is the team's job, not the newcomer's.

What each camp would gate a merge on

Camp	What it would check before merge	What that check misses
Evidence, not proof	A person signs off on behaviour, not just a green run	Scale: a person cannot read every agent change
Accountability	An owner for the quality system, not for each diff	Nothing by itself; it says who builds the checks, not which
Regimes instead of reading	Automated checks on behaviour, plus production monitoring	Whatever nobody wrote an expectation for
Verify the output	The developer checks each delegated task	Consistency: it depends on who is checking

The takeaway

The wary developers and the enthusiasts agreed on more than the thread suggested. Both accept that agent output is evidence. They disagree on whether the checks that turn evidence into confidence exist yet in a given team, and 4b11b4 is right that they do not appear by accident.

So the practical question for a team is not "do we trust agents?" It is "for this change, what did we check, against which written expectation, and who wrote that expectation?" If the answer is "the agent's own tests passed", that is Jaygles' evidence, and a person still has to supply the proof.

Caveats. One thread, one article, read and sorted by us. The topic counts are keyword matches over comment text, so a comment can count in several rows and the counts are rough.