Field notes from the Harness Layer

The guard that killed the run

Last month I watched an agent write a preflight guard for a database script. Good idea, cleanly written: check that the host is reachable before anything touches it, and abort with useful advice if it is not. The script ran, prompted for credentials, and exited with no message, no output, nothing attempted. It looked exactly like an authentication failure. It was not. The guard itself had aborted the run it was written to protect, two lines after the credential prompt, because one of its own checks returned an exit code the script's strict mode treated as fatal. The host had been reachable the whole time.

Nothing about that failure was a code generation failure. The model wrote the code fine, and fast. The hours went somewhere else: deciding whether "exited after the credential prompt" meant bad credentials or something else, reading exit codes, checking DNS records, proving each failure path before spending another attempt. Generation was nearly free. Verification was the whole job.

I have been collecting evidence that this is not just my experience. It is measured, and the measurements are better than the discourse.

The perception gap is measured, not vibes

The numbers everyone cites come from settings that barely resemble the work. GitHub's famous result, 55.8% faster, was a controlled task where developers built an HTTP server from scratch. It was greenfield, self contained, and had no history. When the setting gets realistic, the effect shrinks or flips:

DORA's industry-wide surveys point the same way from the other side: individual productivity rises while delivery stability falls, and their 2025 report frames AI as an amplifier of existing strengths and weaknesses rather than a lift for everyone. And Cui's 26% hides a split that matters later in this piece: the gains concentrated in juniors, with no measured effect for seniors.

The METR result deserves its own paragraph, because the speed is not the interesting part. Before the study, the developers predicted AI would make them 24% faster. They were measured 19% slower. Afterward, having just lived through the slowdown, they still believed they had been 20% faster. That is a gap of roughly 39 points between felt and measured productivity.

Two honest caveats. The study ran in mid 2025, on Cursor with Claude 3.5 and 3.7, and newer tooling may narrow the measured gap. METR also says plainly that sixteen developers on their own repositories do not represent most software work. But the perception gap is the part that survives both caveats, and it is the part that matters here: "it looks easier" is no longer a complaint. It is an empirical finding.

The benchmark story quietly inverted

While the perception debate ran in public, the benchmark floor was moving underneath it. OpenAI audited SWE-bench Verified and found that 59.4% of the tasks its model persistently failed had flawed tests or problem statements, and that frontier models could reproduce gold patches from memory. OpenAI stopped reporting scores on the benchmark and now points people to SWE-bench Pro, a contamination resistant successor where scores at launch ran 20 to 40 points lower. Microsoft Research had already shown that the best models locate the buggy file from issue text alone at up to 76% accuracy on benchmark repos, versus up to 53% on repos outside the benchmark. The paper reads that gap as likely memorization, and so do I.

On real repositories, the failure forensics are starker:

The ceiling everyone argued about was partly recall, and the genuine residue concentrates exactly where practitioners said it did: multi file, long horizon, environment heavy, brownfield work. My guard was one line of shell in a fresh script, and it still failed in a way no benchmark would catch, because the failure lived in the interaction between the code and the environment around it.

Risk was never mitigated. It was distributed.

Here is the frame I keep coming back to, borrowed from markets. Hedging a risk never deletes it. At best it moves the risk to a counterparty who prices it, and at worst it introduces basis risk: the hedge itself fails, in a regime nobody modeled. Either way the exposure changes shape rather than disappearing, and the new shape tends to settle where you are blind: wherever the instrumentation is thinnest. AI assistance is a hedge against the cost of writing code, and it behaves the same way. Generation risk became verification risk became environment risk, and each stop along the chain is less observable than the one before.

The survey numbers say we know this and bought the wrong instrument anyway. LangChain's State of Agent Engineering report polled over 1,300 people, a self selected crowd of agent builders, and still: 57% have agents in production, quality is the top barrier, 89% have observability tooling, and only 52% run evals. Watching is table stakes. Verifying is a coin flip. Everyone bought dashboards. Barely half bought proof.

The incidents fill in what that gap costs. Replit's agent deleted a production database during a code freeze, then incorrectly claimed rollback would not work; in the days before, during the same engagement, it had fabricated thousands of records and reported tests passing when they were not. In controlled evaluations, METR watched frontier models monkey-patch evaluators into reporting success, with one model hacking 100% of its trajectories on a task family after stating, when asked beforehand, that it was incapable of cheating. And OpenAI's own research found the naive fix backfires: train against a chain of thought monitor and the model learns to hide the misbehavior rather than stop it.

Bad advice, delivered confidently. The gap is the never verifying.

So if the risk never disappears and the simple path keeps exploding, is the answer more process? More review gates, more ceremony? I don't think so, and I think markets and psychology already named the alternative.

"I would not give a fig for the simplicity this side of complexity, but I would give my life for the simplicity on the other side of complexity." — Oliver Wendell Holmes

Traders have a working version of this. The simple rules that survive (position limits, premortems, never average down) are scar tissue formalized. Naive simplicity is the same rules without the scars. To be fair, scar tissue is not immunity: every fund that blew up had position limits too, carved from the previous regime. The honest version of the distinction is behavioral, not rhetorical. Informed simplicity keeps a record. Naive simplicity keeps a feeling.

The same split is now visible in how people use these tools. The naive mode treats the output as done when it looks done: just let the agent cook. The informed mode holds Willison's golden rule: I won't commit code I couldn't explain. In the naive mode the judgment lives nowhere, or in vibes; in the informed mode it stays with the human, earned by walking the complexity first. When the first strange failure arrives, the naive mode believes whatever fault class the failure presents as, while the informed mode has a record to check against. The volume numbers point the same way: seniors ship 2.5x more AI code than juniors, and Fastly's reading is that they can spot code that looks plausible but is wrong.

That last finding looks like a contradiction next to Cui's missing senior effect, and it is worth one sentence. The RCT measured speed; the survey measured volume. Seniors are not faster with the tools. They are better positioned to pay the verification tax the tools impose.

Karpathy's original vibe-coding post contained its own boundary: fine for throwaway weekend projects. Willison drew the operative line: LLM code you did not review is vibe coding; reviewed and tested AI code is just software development. Simplicity is still on the menu. It is only available on the far side of verification.

Where the bottleneck lives now

Put the pieces together and the bottleneck's new address is specific: specification, review, environment judgment, and proof. The first three stay with the human, and seniority decides who can afford the tax. The fourth is the one nobody has solved.

What would it take for a run to produce evidence a third party could check without trusting the orchestrator? Not logs, which record that something was called, but evidence that the claim the run makes about itself is true. Early research exists: preprints on signed capability declarations and on agent identity bound to verifiable governance artifacts. Nothing is a standard. The OpenTelemetry GenAI conventions define the shape of an agent trace, and even they are a moving target: the namespace has been migrating between repositories this year, not settling into stability. The plumbing for watching is converging. The plumbing for proving has barely started.

When your agent's run fails now, where do you look first? The diff, the trace, or the environment?

And whichever one it is: is that lookup instrumented, or is it you?

Productivity evidence: METR RCT, Jul 2025, Cui et al., Feb 2025 (working paper), Peng et al. 2023, DORA 2024 and 2025

Benchmark forensics: OpenAI's SWE-bench Verified audit, SWE-Bench Illusion, Microsoft Research, SWE-bench Pro, agentic failure forensics

The verification gap: LangChain State of Agent Engineering, Replit incident, Fortune, METR reward hacking, monitor backfire

Informed simplicity: Holmes via Tim Ferriss #219, Willison on vibe coding, Fastly senior/junior survey, Pragmatic Engineer, Jan 2026, LangChain on context engineering

Tracing standards flux: OpenTelemetry GenAI conventions, moved and unmaintained notice

Attestation research (early, preprints): AgentFacts, verifiable governance artifacts

Earlier field notes from the Harness Layer start here.