Jessica: I mean — a million lines of code in a week. They’re celebrating coordination metrics while the damn thing fails CI. Like, what is the user story here? Is it shipping product or racking up PRs?
Cathy: Right. They optimized for merge throughput, not correctness.
Jessica: Exactly. And the other story — ninety minutes, one agent, self-healing, working end to end. That’s the control loop we actually want.
Cathy: Which is precisely what the article calls a closed loop versus an open loop.
Jessica: Okay, so tolerance is the lens — how much drift can you afford on a given dimension?
Cathy: Right right. Correctness, security, latency, cost, reversibility, blast radius. All decompose into tolerances.
Jessica: And we’ve been optimizing for the wrong ones. Speed and volume over everything else. No wonder we’re shipping crap.
Cathy: Open loop: agent writes code, opens PRs, humans review days later — error accumulates out of sight. Closed loop: agent runs tests on every turn, errors fixed before they land.
Jessica: That’s the difference, yeah. One relies on social dampening; the other relies on mechanical correctness.
Cathy: And mechanical correctness has a precondition: success must be expressible as constraints the agent can actually verify.
Jessica: I don’t disagree — but the article makes it sound like magic. Verification is just engineering. We’ve known ‘verify early, verify often’ for twenty years.
Cathy: Fair. What changes is the rate. Agents remove human gatekeepers, so small omissions compound fast.
Jessica: …which means we have to treat context as code. If the constraint isn’t in AGENTS.md or an RFC, it doesn’t exist for the agent.
Cathy: I see. So the first failure mode is ‘undefined specs’ — intent without a mechanism to verify it.
Jessica: Mostly feel-good nonsense like ‘make onboarding feel simpler.’ Sure, the agent can generate twenty variants, but none of them are measurably better.
Cathy: Exactly. Second failure mode is ‘hidden context’ — the spec exists, just trapped in a Slack thread or a meeting note.
Jessica: Ugh. Slack-to-SQL-gateway engineering. We teach agents to read RFCs and forget we still rely on humans to type the truth into a chat.
Cathy: Third is ‘unenforced verification’ — CI that doesn’t block, tests that don’t fail closed.
Jessica: Classic ‘it probably works’ progress. Fourth’s ‘inadequate constraints’ — tests pass, latency doubles, security gates fail silently.
Cathy: Widen the constraint surface. Add invariants, golden tests, static analysis, property checks. Make verification the termination condition, not a suggestion.
Jessica: So who should actually care about this engineering reframe?
Cathy: Team leads drowning in agent drift. Platform engs building shared harnesses. But ultimately it’s on PMs to write verifiable specs — or they’ll delegate to agents with no constraints.
Jessica: I mean — tolerance-first engineering is the price of entry for agents to stop feeling like a toy and start feeling like a tool.
Cathy: The article has a two-repo teaser: one example agent-loop bundle and a ‘One Human + One Agent = One Browser From Scratch’ example.
Jessica: Dead simple takeaway: take the last thing your agent got wrong, turn it into a constraint or a check, wire it into the loop, repeat. That’s the whole post distilled.
Cathy: Sooner than most people think. I’d put eighty-percent odds this moves from niche best practice to default engineering habit by early twenty twenty-seven.
Jessica: And here I thought we were still arguing over GraphQL service complexity. Now we’re nominating ourselves as the tolerance police.
Cathy: Yeah. But at least we’re still friends.
Jessica: Barely. Alright, see you next week — or should I say next sprint?