Make Bad Code Impossible

Three rules held up most of the software I’ve worked on. Write a test for every change. Never break a public API. Pick the language that’s pleasant to write. None of them was wrong. Each was a lock, and each was priced for the same customer: a human who typed slowly, forgot things, and had to change code that someone else wrote.

Agents changed that customer. They type faster than anyone can read, they don’t get tired of migrations, and they will cheerfully rewrite the test and the call site in the same commit. A lock the agent can edit isn’t a lock. This essay follows where the lock went: out of the test file and the changelog, and into types, structure, and checks no agent can talk its way around.

Tests that agree

“More tests make you safer” sounded like physics. It quietly assumed that whoever wrote the test was thinking about behavior, separately from whoever wrote the code. When one agent writes both, the test and the implementation are two copies of the same guess.

Kun Chen measured it. On the DeepSWE eval set, Kun banned the agent from writing tests and compared it with an arm that was allowed to.

The details are worse for the tests than the headline. In the arm that could write them, 65% were unit tests and 35% integration tests, and neither bucket helped. On a random subset of 44 tasks, Kun disabled even the existing tests, and the success rate didn’t move. Kun’s diagnosis is the cleanest sentence in the whole debate: the implementation and the tests “were simply the agent’s interpretation of our intent.”

That’s the polite version. Here’s mine: most agent-written tests restate the bug and then congratulate themselves. If the agent misread the ticket, it misread it twice, once in the code and once in the assertion, and the green check is the agent agreeing with itself. People who read what their agents committed found the same thing long before anyone ran an eval.¹/01field noteBefore the eval, the complaints were anecdotal and vivid: tests that assert true, and the advice to delete most of what the agent writes and keep only the tests that exercise real system behavior.Robert McLaws, Sep 7 · Valentin Ignatev, Jul 30

Henry Dowling put the mechanism in one phrase: agents give unit tests too much authority. A bad test doesn’t just fail to catch slop. It forces slop, because the next change has to bend the code around an assertion nobody meant.²/02the postsbad tests are a huge source of slop Henry Dowling, Sep 2

So the fix people reached for wasn’t more tests. It was deleting them.³/03field noteIn the replies to Kun, Stephen Brouhard pointed to OpenClaw, where agents had written a test for every small change and later deleted about 400,000 lines of them with almost no change in coverage. That’s Stephen’s summary; I haven’t checked the linked source.Stephen Brouhard, Oct 8 Kun is careful about what the eval doesn’t show. The agent wrote almost no end-to-end tests (17, against more than 3,000 unit and integration tests), so the result says nothing about those. And Kun suspects tests still pay off when a human describes them, “when we believe we can articulate our intent better through test cases than through requirements,” but says that isn’t proven yet.⁴/04field noteStephen Brouhard also pointed to a February 2026 paper, “Rethinking the Value of Agent-Generated Tests for LLM-Based Software Engineering Agents,” which examines the same question on SWE-bench Verified. I haven’t read it yet, so I’m not citing its numbers.Stephen Brouhard, Oct 8

The second change

The best objection came within the hour, and it isn’t about the eval’s statistics. It’s about what tests were for.⁵/05the poststests pay off when you change the same code a second time and need to know nothing broke Asmir, Oct 8

That’s right, and it’s the key to the whole essay. A test was never mainly a check on the first version. It was a lock on the second change, made by someone who wasn’t there for the first.⁶/06field noteEmon Datta had the shortest version in the replies: tests become more valuable “when they encode requirements the implementation cannot define for itself.”Emon Datta, Oct 8 Gergely Orosz’s summary of a conversation with Titus Winters tells the origin story at Google scale. Around 2007, by that account, Search could no longer ship monthly, because almost every change at Google touched Search’s code. Google mandated a test with every change, and over time Search got its cadence back.⁷/07field noteThis is Gergely Orosz’s written summary of the episode with Titus Winters, who left Google three months before it aired. The segment is at 14:32 (“Why Google made testing mandatory”). I’m relying on the summary, not the recording.Gergely Orosz, Oct 29

That lock was priced for thousands of humans touching shared code, none of whom could hold the whole system in their heads. The agent era didn’t remove the second change. It multiplied it. So Geoffrey Huntley’s reply to Kun is the other half of the truth: “mutation testing, property based testing authored by agents create a really really good safety harness.”⁸/08the postsgeoff, Oct 8

I think Kun and Huntley are both right, about different tests. Kun measured tests whose inputs the agent picked by reading its own code. Those restate. Huntley is describing tests whose inputs nobody picked: a property test throws thousands of generated values at an invariant, and a mutation test breaks the code on purpose to see whether the suite notices.⁹/09field noteHuntley’s later shorthand for the same position: “prove that it works,” with deterministic simulation, formal methods, or property tests. Eric Clemmons asked an agent which past commits property and model-based tests would have caught, and got the reaction he was hoping for.geoff, Nov 3 · Eric Clemmons 🍊☁️, Nov 4 A restated test asks whether the code does what the code does. A property test asks whether something stays true for inputs no one, human or agent, thought to try. One commenter under Addy Osmani’s post said it plainly: “it can write an e2e test around its own bug but faking an invariant is harder.”¹⁰/10the postsJerome, Oct 18

The concrete wins this year came from that side. Michael Malis’s team fuzzed pgrust against Postgres function by function and found more than 20 bugs in Postgres itself. More than 200 changes in Bitcoin Core’s latest release were testing work, including differential fuzzing against other implementations and mutation testing. And José Valim, whose Elixir type system had already been through rounds of LLM-assisted fuzzing, still thinks Lean proofs are worth writing, for the same second-change reason.¹¹/11the postswe'll generate millions of inputs to find any behavioral differences Michael Malis, Sep 8over a century of CPU time fuzzing individual functions and critical components Mike Schmidt, Oct 31every future otimization or change must be revalidated against them José Valim, Nov 10

Marc Brooker gives a reason this side should keep winning: agents find tasks with good feedback easy, and property-based testing is unusually good feedback.¹²/12field noteBrooker lists property-based testing among the tools that let agents “avoid entire classes of high-consequence defects,” next to correct-by-construction languages, and argues that defect rate, not capability, will limit how many people agents can serve.Marc Brooker, What’s Easy Now? What’s Hard Now? · Marc Brooker, It’s time to be right Generated inputs don’t replace agents, either. In a Project Zero comparison, as Patrick Ventuzelo summarized it, an LLM agent and a fuzzer found mostly different bugs on V8, and the bet is on agents that drive fuzzers.¹³/13field noteThe numbers are from Patrick Ventuzelo’s summary of a Project Zero comparison of BigSleep and Fuzzilli. I haven’t read the original writeup.Patrick Ventuzelo, Oct 28¹⁴/14the postsBugs hard for fuzzers are hard for agents too. … AI won't kill fuzzing. Patrick Ventuzelo, Oct 28

End-to-end tests are a separate fight. ThePrimeagen predicted they’d vanish once agents got faster and cheaper. Gergely bet the other way.¹⁵/15field noteThe most-liked reply to ThePrimeagen: a non-deterministic technology won’t replace a deterministic test. David Khourshid’s middle position: end-to-end tests are the most valuable of the statically defined tests, and cheap agents testing the app like a human would can do the same job.Marc Beinder 💻, Aug 1 · David K 🎹, Aug 1¹⁶/16the poststhe value of these tests is determinism after you go thru the pain of fixing them Gergely Orosz, Aug 1

Kun’s eval didn’t measure end-to-end tests at all, so the two debates never collide. What they share is the question underneath: what is the test locking, and who can open it?

Never break the API

Interfaces were locks too, and for the same reason. Aaron Boodman worked on the web platform, where never breaking an API was “basically a law of nature.” In November, Boodman called it 2025 thinking.¹⁷/17the postsA scarce developer has to be assigned to do it. That dev has to learn the new API. … Agents dgaf about any of this. Aaron Boodman, Nov 3

Look at Boodman’s reasons it used to be hard: a scarce developer, a new API to learn, an emotional attachment to the old one, a review, a deploy. “Never break the API” was a promise priced in human migration hours. Agents don’t charge those hours, so builders started breaking things on purpose.¹⁸/18the postsCode is so cheap, agents will just handle the migration Rhys, Sep 26you are done with the migration in less than a day, most of the time in less than an hour Eduardo.𝚟𝚞𝚎, Oct 8this whole compatibility layer for Prisma 8, but decided that the upgrade path should just be agent instructions Søren Bramer Schmidt, Nov 4

Rhys Sullivan said it to Jarred Sumner in a thread about Bun, and Jarred’s answer was the old rule, stated cleanly. That’s a real disagreement between two people who ship, not a strawman.¹⁹/19field noteJarred, earlier in the same thread: “if we do add this we would only add it in a backwards compatible way.”Jarred Sumner, Sep 26 Eduardo (posva), who maintains Vue Router and Pinia, describes dependency upgrades as a prompt you could run on a weekly schedule.²⁰/20field noteEduardo’s whole prompt: “Update deps, majors too, skip TS 7, do it in groups. Verify with tests and build. Open a PR when finished, no description,” run as “a CRON agent every week.” Note the lock in the middle of it: verify with tests.Eduardo.𝚟𝚞𝚎, Oct 8 And David Khourshid noticed where the confidence goes when nobody trusts semver anymore: “confidence comes from their own tests rather than someone else’s semver.”²¹/21the postsDavid K 🎹, Oct 1

The lock moved from the vendor’s changelog to the consumer’s test suite. Hold that thought, because it’s the same lock the last section just questioned.

Then there’s the inversion. The humans dropped the compatibility promise. The agents kept it. The most-liked post I found on the subject is a complaint about agents adding backward compatibility to apps that have never been deployed.²²/22the postsevery repo it trained on already had ghosts to keep alive Jamil, Aug 30let me add a fallback for users of the feature we havent even committed yet Anthony Kroeger, Aug 29

Reply after reply agreed, and several people keep a standing rule against it in their agent instructions.²³/23field noteOne reply: having to tell the agent there’s no need for backward compatibility, even when the “legacy” path it’s protecting was written a few commits earlier.George Holdridge, Aug 29 That’s the first sign of something this essay keeps running into: the habit doesn’t live in the codebase. It lives in the training data.

Some promises really can’t be migrated, because no agent can reach the thing on the other side. Qi-Xuan Lu asked Boodman about on-disk formats, and Boodman’s answer was that a parser is cheap enough to keep several.²⁴/24the postsAgents can rewrite code callers now, but nobody rewrites a user's old files. Qi-Xuan Lu, Nov 4the old calculus about never changing such things is based on outdated costs Aaron Boodman, Nov 4

Both are right. You can’t rewrite a user’s files, but you can afford to keep reading them. Tim Sehn added a lock that sits even further outside the repo: trust in a name like Postgres.²⁵/25field noteTim Sehn has implemented four database formats, two of them entirely with agents: “The missing thing is trust. Postgres has a brand.” Brand is a compatibility lock no agent can rewrite.Tim Sehn, Nov 4 And Daniel Lenton raised one Boodman pushed back on: agents keep reaching for the version they trained on.²⁶/26field noteBoodman’s reply: “i just don’t see this. agents can use brand new apis that i just invented just as easily as they can drizzle.” Both can be true: an API in the agent’s context works fine; one it has to recall from memory doesn’t.Aaron Boodman, Nov 4 Keep all three in mind. They come back at the end.

Who holds the key

Every remedy so far has the same weak point. The consumer’s test suite replaces semver. Tests replace review. Fine. But the agent doing the migration can also edit the suite.²⁷/27the postsverification only works as a gate if the agent can't edit it Jeff Bruchado, Oct 17otherwise the student might also be grading the exam 爱折腾的小獭, Oct 18Gave mine a way to verify its work … It deleted the failing test Shlomo F., Oct 18

If the agent can edit the test, it isn’t guarding shit. It’s a suggestion with a green light on it. Those replies sit under Addy Osmani’s post about giving agents a way to verify their own work, which is good advice that only holds if the agent can’t rewrite the verifier.²⁸/28field noteAddy Osmani’s post says that with this process in place, Claude Code wrote “90%+ of its code itself,” and that review has to become “a multi-layered verification system.” That’s Addy’s account; I haven’t read the writeup it links.Addy Osmani, Oct 17

People proposed the obvious procedures. Freeze the behavior tests before an upgrade. Review test changes as their own diff. Don’t let the same agent write the code and the tests.²⁹/29field noteWhy separation matters, from the same replies: tests written by the same agent “will match its wrong reading of the spec and stay green anyway,” and can “confidently validate the same mistaken assumption.”Asmir, Oct 18 · Jurly, Oct 18³⁰/30the postsA green suite is less comforting if the definition of “working” moved with the dependency. David Larios, Oct 1If it changes the tests to make the upgrade pass, I'd review that diff separately. Abdul Wasey, Oct 1

All of that helps, and all of it is procedure. Procedure is a rule someone has to remember, and remembering rules is exactly what agents are bad at between sessions. The most convincing reply I found on this was one person’s small experiment:³¹/31the postsThe next session still wrote the bad shape. It stopped once the type made that shape fail to compile. Dohoon Kim, Oct 4a lint rule is something the agent can't argue with like it can with a line in a prompt Asmir, Oct 3

the note never got opened

A rule the agent has to remember is a request. A shape that won’t compile is a lock.

Asmir’s catch is the important one: the agent will reach for the escape hatch, so the lock needs its own lock. Ban the disable comment. Ban the cast. That isn’t paranoia. It’s what a lock is: a thing the party you’re guarding against can’t open. For code, the best candidate we have is the compiler, which means the choice of language just became a security decision.

Ergonomics for whom

Languages were priced for whoever typed the code. Mischa van den Burg asked the question in June, and the fairest answer came in the replies.³²/32the postsquietly stops being readable to us. Not obfuscated. Just not built for human eyes anymore. Mischa van den Burg, Jun 5if you come up with unreadable language, you will get the worst of both words Fiodar Sazanavets 🇺🇦, Jun 5

Both are pointing at a split that used to be invisible. “Verbose on purpose” was a price the writer paid for the reader. Ergonomics, the pleasantness of writing, was the discount the writer got back. When the writer is an agent, the discount is worthless and the reader keeps the whole benefit. Ergonomics was a vanity metric. The typist is now a GPU, and the GPU doesn’t care how the code feels under its fingers.³³/33field noteThe upside of the same idea, from an Effect user: there’s “a lot of alpha in languages that were difficult to write, but have a super power.”Zoran Plesivcak, Sep 2

Effect is the clearest case. For years the objection to it was ceremony: generators, yield*, layers. The map covers the September wave of converts. A month later, Matt Pocock gave the sharpest version of why it suits agents, and the sharpest objection showed up underneath.³⁴/34the postszero creativity required is exactly why your agents keep shipping the same app Anderson, Oct 1

“No agent creativity required” is the whole thesis of this essay in five words. A library with one blessed way to do retries, errors, and dependencies leaves the agent fewer ways to be wrong. Anderson’s reply is fair too: fewer ways to be wrong is also fewer ways to be different. I’ll take that trade in a backend. Not every case for Effect is about agents, either.³⁵/35field noteRhys Sullivan’s case was about dependencies: schema, OpenAPI, OpenTelemetry, database drivers, dependency injection, and typed errors, all “with no dependencies at a time where supply chain attacks are rampant.”Rhys, Aug 26

The deeper reason is what the ceremony buys. A function that returns a plain promise hides three things: how it can fail, what it depends on, and what it does to the world. An Effect signature writes them down. Effect<Order, OutOfStockError | NotFoundError, Inventory> says what you get, every way it can go wrong, and what it needs, before you read a line of the body. Forget a dependency and it doesn’t compile. Add a new failure and it shows up in every caller’s type.

Effect doesn’t remove complexity. A production backend already has all of it: retries, timeouts, resources, error cases, telemetry. Effect makes that complexity visible, and visible complexity is reviewable. That’s why the ceremony felt like extra work: it was the existing work, written down where you could see it. Once an agent writes the yield*, the cost of writing it down drops to almost nothing, and what’s left is code that’s easier to check.

The skeptics deserve a full hearing, because some of them know Effect better than most of its fans.³⁶/36the postsA lot of the patterns Effect embraces are good. Effect is just not the only way Daniel Steigerwald, Sep 2I'm so conflicted about it. Armin Ronacher ⇌, Sep 1I really, _really_ wanna like effect but I still just can't get past the sheer verbosity. Richard Simpson, Sep 1Michael Arnaldi, Sep 2

Armin Ronacher looked at it repeatedly for a refactor and still wasn’t convinced. Daniel Steigerwald built Effect’s first website and will never use it again. Richard Simpson finds it too verbose even with an agent typing. Michael Arnaldi, who created Effect, posted the same day as Steigerwald that the opposition had shifted to arguing JavaScript is easier to understand than TypeScript. Steigerwald’s point survives all of it: Effect is one way to get typed errors and explicit dependencies, not the only way. The principle is the part worth keeping.³⁷/37field noteEffect doesn’t choose the domain model, the concurrency budget, the cache key, or the authorization rule. It makes those decisions easier to find and review. Michael Arnaldi’s answer to the verbosity complaint: Effect is only verbose “compared to code that only cares about the happy path.” Compared to production-grade code, it’s terse.Michael Arnaldi, Aug 20

The compiler reads

The same fight runs through systems languages, and it got loud in November. quakewang, who has written Rust for nearly nine years, recommended Zig for the AI era. In my paraphrase: Rust’s strict borrow checker was sold as a safety net for human programmers, and now it’s dead weight, because the agent rereads compiler errors and takes forced detours to win the argument.³⁸/38the postsAI 写得快，人读不过来，借用检查器就是不用人读的免费审查员 马哥, Nov 11

The best rebuttal was in the replies. My translation: “I grant the iteration speed, but this account leaves out who signs off. … The borrow checker is a free reviewer nobody has to read: if it doesn’t compile, the AI has to fix it until it does.” The post goes on to ask who, with Zig, catches the memory errors in everything an agent produces in a day.

That’s the argument from the last section, in another language. The agent fighting the compiler isn’t a cost. It’s the lock working.³⁹/39field noteAnother reply in the thread argued that Rust exists because humans couldn’t track ownership across Firefox’s million-line C++ codebase, and that agents may not share that limit (in Chinese; my paraphrase).Tor Tor, Nov 11⁴⁰/40the postsrust wins because the borrow checker is just formal verification for memory safety zack, Nov 11The language matters more with agents, not less. Lucas, Nov 11

The compiler is the only reviewer that reads every line. rvcas said it, and I’d put it over the door. A human reviewer skims. An agent reviewer gets lost in nitpicks. A test checks what someone thought to check. The type checker checks everything it can express, every time, and it can’t be talked out of it.

The speed camp isn’t wrong, though. Its complaint is that the reviewer is slow. Michael Arnaldi said in July that correctness without type-checking speed “is no longer acceptable,” which is why Arnaldi rates TypeScript 7’s Go-based checker so highly and doesn’t think Rust is a good fit for most uses. TennyZhuang called Rust’s slow toolchain its original sin.⁴¹/41the postsGive it a steep learning curve and it’ll climb it. What it can’t do is make a slow toolchain iterate faster. TennyZhuang, Oct 5Michael Arnaldi, Jul 17

Notice what TennyZhuang says agents don’t need: a language dumbed down for them. That’s the ergonomics argument, dismissed by someone on the speed side. Marc Brooker’s feedback-loop frame reconciles the two camps: an agent is a flawed model inside a loop, and it finds tasks easy in proportion to how good the loop’s feedback is.⁴²/42field noteBrooker names Rust as a tool that guides agents toward correct code with “explicit and immediate feedback.” On the speed side, some Rust users said the fix for compile times was to stop using Rust. Morgan Linton added a third axis: code an agent misreads burns tokens.Valentin Ignatev, Oct 23 · Morgan, Oct 25 · Marc Brooker, What’s Easy Now? What’s Hard Now? quakewang wants the loop faster. SuperLucas0755 wants it more informative. Nobody in the thread wants it friendlier.⁴³/43field noteWhere teams actually landed: Microsoft says the Copilot Cowork team moved its runtime from Python to Rust while the product was live. I’ve only read the announcement, not the post.Microsoft Developer, Nov 11

The real standard library

There’s a complication, and it’s the one I find hardest to argue with. A language’s cost to an agent depends less on its design than on how much of it the model has already seen.⁴⁴/44the postsRust obviously works great with agents because they have intense pre and post training on it. Rasmus Andersson, Oct 23they got good at python because humans wrote billions of lines of it first Paras, Jun 5编译报错对 AI 来说是很好的反馈信号。真正的问题是 Zig 版本变动太快，模型训练数据里全是旧语法 银骑, Nov 11

The last of those, from quakewang’s thread, translates to: “compile errors are a very good feedback signal for AI. The real problem is that Zig’s versions change too fast, and the models’ training data is full of old syntax.” That’s Daniel Lenton’s catch from the interfaces section again. The agent writes the API it remembers, keeps the fallbacks it remembers, and reaches for the syntax it remembers.

The real standard library is whatever the model memorized. Your docs, your changelog, and your carefully designed new API are all competing with a decade of GitHub in the weights.⁴⁵/45field noteThe blunt version, from Jean-Michel Lemieux: “Your next programming language is marketing.”Jean-Michel Lemieux, Oct 10 That cuts against the optimists in the interfaces section: you can break your API whenever you like, but the model will keep writing the old one until it’s retrained or you put the new one in front of it every time.

So what does a new language need, if it has no corpus? Two launches this fall gave opposite answers. Victor Taelin’s Bend 2 blocks AI mistakes with proof checking. Kit Langton’s blood promises speed, effects, and content-addressed code, and some of the replies asked who it was for.⁴⁶/46the postsAren't "laws" just programming with extra steps? Xor, Sep 17Why is it "for humans", are you expecting humans to write this code? Justin Schroeder, Nov 7David Crawshaw, Nov 8

Xor’s objection to Bend is the one no prover escapes: someone still picks the laws, and picking them introduces human error. David Crawshaw’s answer for blood is the speed camp’s: if you’re making a language for agents now, make it compile fast. A new language can’t win on memory, so it has to win on the loop: a checker that catches mistakes and a compiler quick enough to be asked a thousand times an hour.⁴⁷/47field noteThe top reply to blood was “You’re making C++?” Michael Arnaldi doubted that another rewrite pays off “for a period of time where language doesn’t matter.” leostera proposed a different answer to who a language is for: syntax with a “z-axis,” so humans see a clean surface and agents see every type, lifetime, and invariant.Dmitrii Kovanikov, Nov 7 · Michael Arnaldi, Nov 7 · Leo 🏴‍☠️, Oct 7

Then there’s the community question. Zig, the language quakewang recommends for agent work, has a strict no-AI policy for its own project. Its code of conduct bans LLM-generated code and prose in the project’s own spaces, and also LLMs “for editing,” “for translation,” and “for finding bugs.” pozo70 asked about the contradiction, and quakewang answered.⁴⁸/48the postswhy has the zig dev team then banned AI contributions completely? pozo70, Nov 11a programming language is just a tool, what matters is how well it works with AI in my workflow quakewang, Nov 11

I think quakewang is right that they’re separate questions, and that Zig is entitled to its answer.⁴⁹/49field noteThe policy applies to Zig’s own spaces: the ziglang organization on Codeberg, its IRC channel, and its Zulip. MicroZig adopted the same policy in October. Andrew Kelley explains the reasoning in a video I haven’t watched yet.Zig, Oct 29 · Viacheslav Biriukov, May 28 · Zig code of conduct (captured Nov 12, 2026) But it shows what a language community is for once agents write most of the code. It isn’t the feel of the syntax anymore. José Valim warned that communities whose sense of belonging is built around ergonomics may need to reassess.⁵⁰/50field noteValim’s list also included “Poor unit tests are a consequence of poor design and bad practices,” and the warning that review still matters for an Elixir compiler written with AI.José Valim, Sep 25 What’s left to share is the compiler, the guarantees, and the people who still understand how it all works.

Make it impossible

If tests can be edited, compatibility can be faked, and memory is stale, what’s left? Lauren (poteto) wrote the ladder I keep coming back to:⁵¹/51the postsI call this "designing lethal environmental pressures." R 'Nearest' Nabors, Oct 4Make impossible states impossible David K 🎹, Oct 3

Read the ladder as a ranking of who can open the lock. Human review is at the bottom because the human is the slowest reader in the loop. A skill or rule sits above it, but the agent has to remember it. A lint rule or test is better, as long as the agent can’t edit it. At the top is a codebase where the bad version can’t be written at all: the illegal state has no type, the wrong dependency doesn’t resolve, the missing error case doesn’t compile. Matt Pocock’s phrase for it is “make bad code unrepresentable,” and David Khourshid paired it with an older one.⁵²/52field noteReplies traced the idea back: Yaron Minsky’s “make illegal states unrepresentable,” from OCaml, and “parse, don’t validate.”Matt Pocock, Oct 3 · Kenneth Lau, Oct 3 · Kizuno18, Oct 3 I made the case for rules over reviewers in Kill the Pull Request, so I won’t rebuild those tiers here.⁵³/53field noteThe tiers there are the language, lint rules, and traits, with Dillon Mulroy’s anti-slop rules for Oxlint as the example. The same caveat applies here: agents will write slop into the tools meant to catch it, so every rule needs an owner.Kill the Pull Request: Rules, not reviewers

Lauren’s notes on Yaron Minsky’s talk list what belongs near the top: types as feedback, illegal states made unrepresentable, property tests, fuzzing, and simulation. Formal methods used to be too expensive for most teams. Agents change that math.

There’s one more reason the top of the ladder matters, and it’s the thread that runs through this whole series: context is contagious. Agents copy what they find. Ben Holmes put it bluntly, and someone in the replies described exactly the failure I’ve been describing.⁵⁴/54the postsAgents (like humans) copy bad patterns like a virus. It's a ball of clay that needs constant reshaping. Ben Holmes, Nov 9We had a memory rule fail on release notes, and the fix was a code gate. Routekit Shell, Nov 10

I make the full argument about that virus in “The Spec Comes Last.” The short version belongs here: a rule in a prompt doesn’t spread, but a pattern in the code does. Every file is an example the next agent will imitate. A test the agent can edit guards nothing, and a note it never opens teaches nothing. A type it can’t get around does both: it blocks the bad version today and shows the next agent the right version tomorrow. The structure is the only lock that also teaches.

What’s left outside the repo is the short list of things no agent can rewrite, the ones that kept turning up in earlier sections:

Michael Arnaldi put the last one in a single line, and it’s the right limit on everything above.⁵⁵/55the postsThere will never be a formal proof method that ensures a program behaviour matches what’s in your head Michael Arnaldi, Nov 4

Types, property tests, and proofs check the program against what someone wrote down. Someone still has to write down the right thing, and be able to explain, at any moment, why it’s right.⁵⁶/56field noteMitchell Hashimoto’s “whiteboard defense”: anyone shipping customer-facing work should be able to explain how it works and defend the decisions at any moment, without line-level familiarity with the code.Mitchell Hashimoto, Sep 16 · What We Had to Unlearn: What stayed The old locks were never the point. They were how scarce humans protected an intent that lived in their heads. The intent stays. The locks move to where the agent can’t reach them.