The short version: repeating an instruction in your system prompt genuinely helps. It stops helping at around four repetitions. Everything after that is superstition, and it costs you tokens.

That’s the whole finding. It cost about a dollar to get, and I think it’s a nice little thing to know on a Tuesday.

This is the first of what I want to make a weekly habit here. Pick one claim that floats around about AI coding agents, test it in a weekend, publish the numbers whether or not they’re flattering. Not research. Just somebody actually checking.

Why I bothered

You’ve seen the advice. Repeat the important instruction. Put it at the top and the bottom. Say it twice so the model takes it seriously. Everybody does some version of this, myself included, and I’ve never seen a number attached to any of it.

Then a paper came through my daily brief with an actual shape for it. Han-yu Wang’s When More Becomes Less: Position-Dependent Repetition Effects in Language Models (paper: arXiv 2608.04021, briefing: 6 August) tests what happens as you add more copies of a target, and finds the answer depends on where the copies sit. Copies stacked next to each other climb and then flatten out. Copies spread away from where the model reads out produce a hump, rising to an early peak and then falling.

That’s a specific, checkable claim about something I do every week, so I checked the half that matches how I actually write prompts.

I wrote my guess down first, which is a rule I’m keeping. My guess was that I’d see the hump, including the fall. I was wrong, and being wrong sent me back to read the paper properly, which is its own small lesson.

What I actually did

The setup is deliberately boring.

I picked one rule a model can either follow or not: use single quotes, never double quotes. Then I asked for six ordinary Python functions, the kind of thing you’d write on any given afternoon. Merge some intervals. Flatten a dictionary. Parse a version string.

The only thing that changed between runs was how many times that quote rule appeared in the system prompt: zero times, once, twice, four, eight, or sixteen. Same rule, just repeated more.

Thirty tries of each combination. 1,080 runs total, on Gemini 2.5 Flash, all of it on Vertex.

Checking the answers needed no judgment calls. I ran Python’s own tokenizer over the generated code and counted strings that opened with a double quote. Zero of them means it followed the rule. That’s it. No model grading another model, no me squinting at diffs deciding what counts.

The zero-repetition runs are the important control. That’s where I never mention quotes at all, which tells me what the model does when left alone.

One detour worth mentioning: my first three candidate rules were all duds. I tried “no comments,” “no docstring,” and “no type hints,” and the model obeyed all three about 99% of the time on the first ask. You can’t measure whether repetition helps when there’s no room left to improve. So I went looking for a rule the model actually resists, and quote style turned out to be one.

What came back

The control row is my favorite number in the table. Left to itself, the model used double quotes every single time. Not most of the time. All 171 of them. So its habit here is about as strong as a habit gets, which makes the rest of the table mean something.

Say the rule once and you’re at 74%. Say it four times and you’re at 97%. Those two are far enough apart that I’m comfortable calling it real.

Past four, the line goes flat. Eight and sixteen land inside the same range as four. My predicted decline never showed up, and to be straight with you, at this sample size I could miss a small one. What I can say is that nobody is getting paid back for repetitions five through sixteen.

Here’s the part I only understood afterward. I stacked all my copies of the rule right next to each other, which is the adjacent case in Wang’s paper, and adjacent is exactly the case that’s supposed to climb and then flatten. The hump I went looking for belongs to the other case, where the copies are spread out away from where the model is reading. So this didn’t contradict the paper. It landed on the paper’s prediction from a completely different direction, with a natural-language rule handed to a coding model instead of tokens in a probe. That’s a better outcome than the one I predicted, and I’d have missed it entirely if I hadn’t gone back to the source.

Three things I didn’t expect

The average is hiding almost everything. Two of my six tasks hit 100% on the very first mention and never wavered. Another one, merging intervals, sat at 20% with a single mention and needed four to climb to 97%. So repetition isn’t broadly making the model more obedient. It’s rescuing the specific spots where the model’s habit is fighting your rule. If none of your work looks like those spots, you’re paying for nothing.

Most of these cells are coin flips. Between half and two thirds of my task-and-repetition combinations came back neither all-pass nor all-fail across thirty identical runs. Same prompt, same model, same settings, different answer. If you’ve ever tweaked a prompt, run it twice, and concluded the tweak worked, this is the number that should bother you. It bothers me.

The leftover violations had a shape. Once the rule appears even once, ordinary double-quoted strings disappear completely. What survives is the triple-quoted docstring at the top of the function. The model seems to file """this""" under documentation rather than under strings, so a rule about quotes never reaches it. If you’ve had a constraint that got obeyed everywhere except one stubborn place, that’s probably what’s happening. The model has the thing in a different mental drawer.

Takeaways: Enterprise and Personal Use

If you work somewhere with a prompt library. Cap repetition at about four in your templates and spend the leftover room on examples instead. The bigger one is the coin-flip problem: if your team evaluates a prompt change by running it once before and once after, that process is theater. Ask how many runs before you ask what the result was. Three is a floor. Ten is better.

If you’re building something on your own. When a rule isn’t landing, repeating it up to four times is the cheapest fix you have and it genuinely works. If four doesn’t do it, stop repeating and change something else, because five through sixteen bought me nothing. And when a constraint gets followed everywhere except one place, go look for the thing the model has filed under a different name, the way a docstring isn’t a string.

What this isn’t

This is one person, one weekend, one model. It’s not state of the art and it isn’t trying to be.

I tested Gemini 2.5 Flash with thinking off, on one day. Different model, different family, or thinking switched on could all move this. I tested one rule about syntax, repeated literally, with every copy in the same place. Rules about behavior, or rephrased each time, are untested here.

The big untested one is spacing. Every copy of my rule sat in one block, and the paper says that’s the case that flattens. Spreading the copies through the prompt is the case that’s supposed to turn around and hurt you, and that’s the next experiment rather than a caveat I can hand-wave. And these were six small standalone functions, not a real repository with a real agent loop, which is exactly the kind of thing that usually doesn’t survive the jump.

One more, because it nearly cost me the whole experiment. My first real run threw away most of its samples as unreadable. Gemini’s thinking tokens count against your output limit but get reported separately, so a limit that looked generous was quietly eaten by reasoning and the actual code got cut off mid-word. Worse, it cut off more often in some conditions than others, so what survived was skewed differently in every column. Before I caught it, my headline number read 39%. After, 88%. Same code, same model, same afternoon. If your evaluation setup doesn’t record why generation stopped, it can hand you a confident wrong answer and never mention it.

Run it yourself

It’s all public. The guess I wrote down before running, the code, the checker, and every one of the 1,080 runs including the ugly ones.

git clone https://github.com/nkhola/field-tests
cd field-tests/ft-01-say-it-four-times
python analyze.py

If you run it and get something different, I genuinely want to hear about it.

This one came out of The Post-Human Briefing, my daily AI and markets brief. Machine-built, human-audited. New Field Test most weeks.

My bet is still on top-down AI-assisted software engineering. Durable human advantage moves up the abstraction tree while agents absorb the leaves. I’ve argued the two halves of that position already in the last two posts, and I’ve been living it for a year, watching agents take over code I used to be proud of writing.

A bet deserves an audit, though. So this finale in a 3-part series is a status check rather than a memoir: what the trend data shows as of mid-2026, why the loudest skeptics are conceding ground, and where the bet could still lose.

The Leaf Nodes Are Being Absorbed, On Schedule

The claim that agents will keep improving at implementation work doesn’t need my intuition. It has a measured curve.

In October 2023, the original SWE-bench paper reported the best model of the day resolving 1.96 percent of real GitHub issues. OpenAI’s cleaned-up SWE-bench Verified launched in August 2024 with GPT-4o at 33.2 percent. Claude 3.7 Sonnet reached 62.3 percent in February 2025. GPT-5 claimed 74.9 percent that August. By mid-2026 the benchmark is close to saturated, which is why the labs have mostly stopped bragging about it.

METR measures the same slope differently: the length of task a model can finish at a 50 percent success rate. Their March 2025 paper found that horizon doubling roughly every seven months; their January 2026 update put the frontier at over five hours of human-equivalent work and the doubling time closer to three months. Whatever else is true, “the leaf nodes will improve” stopped being an opinion sometime in 2024. It’s the most consistently measured trend in software. Believe the slope.

Two numbers complicate the slope, and they belong in the same paragraph as the cheerful ones. When Scale built SWE-bench Pro (September 2025) to resist contamination, with larger multi-file tasks from unfamiliar repos, the same class of frontier models dropped to roughly 23 percent. And practitioners are voting with their anxiety: in the 2025 Stack Overflow survey, 84 percent of developers use or plan to use AI tools while only about 3 percent highly trust the output and nearly half actively distrust it. Adoption tracks the curve. Trust tracks the gap.

Read together, the numbers say the absorption is real and fast where work resembles the training distribution, and thins where tasks get larger, stranger, and less checkable. Which raises the only question that matters for the bet: what, exactly, makes work checkable?

Why the Skeptics Are Turning

The engine under the curve is not a secret. OpenAI’s o1 described it in late 2024 and DeepSeek-R1 demonstrated it in the open in January 2025: reinforcement learning against answers a machine can check. Code is the ideal substrate for that loop, because the compiler and the failing test are free verifiers, available at whatever scale training needs.

That mechanism explains the most interesting sociological fact in the field. The skeptics are conceding. And they’re all conceding the same narrow thing. François Chollet spent years as the discipline’s most rigorous LLM skeptic, and when o3 cracked his ARC-AGI benchmark in December 2024 he called it a genuine breakthrough while founding a lab premised on a different road to intelligence. By December 2025 he was crediting “remarkable progress on LLM-driven refinement loops” in commercial frontier models. Andrej Karpathy’s sober middle position is the same concession from the other direction: agents genuinely handle the routine layer, and still bloat the codebase the moment the architecture gets custom. Nobody converted to scaling faith. They conceded that refinement loops against checkable feedback work, and that coding is where feedback is cheapest. Cheap feedback compounds.

That’s the audit’s core finding. The trend is steepest exactly where verification is cheap, and the tree is really a gradient of verification cost. A leaf has a verifier the training loop can afford: it compiles, or the test goes red. One level up, the verifier gets expensive, because a module boundary proves itself over months of change traffic. At the root, the verifier is an incident review, or the market. So the bet, restated with the precision it lacked: agents keep absorbing everything with a cheap verifier, corner cases included, because a corner case is just a test nobody wrote yet. That half I’d sign today. What stays human is the layer where feedback arrives late and entangled, and no training signal exists to climb it.

Honesty about the evidence: I looked for a controlled study isolating how much agent success depends on specification precision versus abstract intent, and I can’t find one. Both sides of this bet are quoting vibes on that question. The study is missing, and whoever runs it will move the argument more than the next benchmark will.

Correct Is Still Not Fast

One caveat survives the audit intact. PerfCodeBench (May 2026) found models still trailing expert implementations on system-level optimization, especially parallelism and GPU work, and SWE-Perf shows repository-level performance gains require understanding the system, not passing its tests. Casey Muratori’s old critique of clean abstraction still bites: a tidy interface can hide cost from the reviewer as effectively as from the machine. The agent knows the words: batch, vectorize, cache, async. Knowing the words isn’t the same as owning the cost model, and a correct function can still be the bottleneck. Unpriced abstraction remains the most expensive thing in a generated codebase.

The Data Question

The part of the trend that could bend is the training data. Research on model collapse (Shumailov et al., The Curse of Recursion) shows that recursive training on generated data can erase the tails of a distribution, and the tails are where the hard cases live. They’re also where seniors were made. The counter-evidence is real too: when synthetic data accumulates alongside real data rather than replacing it, collapse may not be inevitable, and dose and curation matter. The conclusion I trust is conditional, and it loops back into practice: a passing patch with a hidden defect may be worse than noise, while a rejected diff with a good explanation may be the most valuable training example a company produces. Judgment traces, not more code, are the scarce training input.

The most valuable training artifact you produce this year might still be the PR comment that explains why a clean diff was wrong.

Where That Leaves the Human

I’ve already argued the near-term job in this series: the review economics when code gets cheap, and the retrieval problem that decides whether an agent can operate inside a legacy system at all. I won’t restate either; they’re one click away.

What this post adds is the vertical answer. The human doesn’t get to park at the root and doesn’t need to defend the leaves. What’s defensible is movement: choose the level, descend when the situation demands it, come back up carrying what the machine couldn’t check. The two jobs that show no sign of absorbing are pricing an abstraction before production bills for it, and owning outcomes no test can certify in advance.

And the falsifiable version, since a bet that can’t lose is just a mood: if design-level feedback ever gets as cheap as a failing test, the middle of the tree goes the way of the leaves, and I’ll write the correction myself.

Until then, it is a top-down bet. Just a top-down bet with muddy boots.

The phrase “AI-friendly codebase” is becoming an architectural requirement.

Some systems are easy for agents to work inside. The boundaries are explicit. The tests say what matters. The schemas are visible. The business rules live somewhere other than one senior engineer’s head. The agent can load a bounded context, make a change, and trip a deterministic alarm if it crosses a line.

Other systems ask the agent to infer an organization.

That is where things get expensive.

Legacy systems don’t merely have old code. They encode old communication patterns. Conway’s Law gets physical inside a twenty-year enterprise codebase: the table name, the duplicated validator, the half-retired service, the batch job no one can remove, the permission check that lives in the caller because the platform team lost an argument in 2017.

An agent trained mostly on public code does not see that history. It sees a shape and completes the nearest public pattern. That is architectural hallucination.

This is what I mean by jagged intelligence in software. The agent can be startlingly competent in one pocket of the system and strangely naive one layer over. It produces a clean API client, then misses the business rule hidden in a batch job. It explains the architecture pattern beautifully, then applies it to the wrong organization.

Vibe Coding Is Low Node Density

The purest version of top-down programming is vibe coding: describe the thing you want, let the model generate the implementation, run it, complain until it works.

For throwaway software, this can be delightful. I don’t want to pretend otherwise. The joy is real - I coded up a quiz show app in about 20 mins that my wife and I regularly enjoy.

Production is where the missing middle layers show up.

The problem with vibe coding isn’t the altitude. I like high abstraction levels. The problem is node density: too few intermediate constraints between intent and implementation.

A senior engineer working top-down does more than say “build the app.” They supply contracts and name trust boundaries. They write fixtures, lock the migration, and decide which failures must be loud. Constraint before generation, instrumentation after.

A vibe coder often supplies a wish.

The agent fills the empty space with training data, which usually means tutorial-shaped code: get the request through, make the UI respond, store the thing, return success. The median tutorial just wants the reader to feel progress before lunch.

Moltbook is a useful warning because the failure was boring. According to Business Insider’s February 2026 reporting on Wiz’s disclosure, researchers found a Supabase configuration problem that exposed email addresses, private messages, and a large number of API authentication tokens. Skip the easy readings, the ones where Supabase is uniquely dangerous or one startup is the symbol of all AI software. The useful lesson is subtler: functional generation won’t automatically include the security posture that production requires.

If the constraint isn’t present, the model may not invent it.

Legacy Is A Retrieval Problem

Enterprise leaders tend to describe legacy modernization as a code transformation problem. Translate COBOL to Java. Extract services from the monolith. Move workflows to cloud primitives.

That is only the surface.

The harder problem is retrieval. The knowledge needed to make a safe change is scattered across source code, deployment scripts, data contracts, incident history, regulatory interpretations, and human memory. Agents are brittle in exactly that environment because the relevant fact is rarely sitting next to the line that needs to change.

The agent needs context structured around the decision it is making. Which service owns this field? Which downstream report treats null as meaningful? Which customer migration created the exception, and which team must approve a change because their batch job still reads yesterday’s files?

Most legacy companies don’t know the answers in machine-readable form. Many barely know them in human-readable form.

So the agent applies the public pattern. In a greenfield SaaS app, that may be good enough.

In a legacy enterprise, the public pattern can be wrong because the real architecture is the fossil record of the company.

The research on domain-specific languages shows how deep this goes. An industrial case study at BMW (arXiv 2604.24678, April 2026) found that ordinary prompting was not enough for repository-scale generation in their Xtext-based DSL; the path that worked required structured representations of the folder hierarchy plus parameter-efficient fine-tuning. It sounds narrow because the file extension is unusual. The pattern is everywhere. Every large company has a DSL, even when it doesn’t call it one: a YAML convention, a spreadsheet template that drives pricing, a workflow engine configured through UI state, or the private meaning of “eligible” inside billing code. Public training data is weak on these private languages, and the agent can still produce plausible artifacts. Plausible is not safe.

A private language your agents can’t learn becomes a tax on every change they touch.

MCP Is A Start, Not An End

Anthropic introduced the Model Context Protocol in November 2024 as an open standard for connecting AI assistants to data sources and tools. The announcement names exactly the problem enterprises feel: sophisticated models are constrained when trapped behind information silos and legacy systems.

I think MCP matters because it admits that context is now infrastructure.

A connector isn’t a brain, though. Wire an agent into Slack, GitHub, Postgres, Jira, Confluence, and a document store, and you’ve created access, not understanding. Access is where the problem starts.

The hard part is deciding what the agent is allowed to retrieve, what it should trust, how retrieved facts should be ranked, which tool calls are reversible, which side effects require approval, and which old document is superseded by last quarter’s incident report.

This is the enterprise version of node density. The organization needs constraints between intent and action: knowledge graphs, typed APIs, append-only logs, contract tests, generated architecture maps, data lineage, permissions, human approval gates. The exact tools will change. The shape will not.

Agents need a world they can interrogate without accidentally changing it. Then they need a smaller world where they can act.

Agent-Readable Architecture

I’d define an agent-readable system by four properties, each with a blunt test attached.

• Retrievable knowledge. The facts a change depends on can be found by query, not by tenure. Can the agent discover who owns the API, and which contract and migrations sit behind the field it’s about to change, without asking a person?

• Explicit boundaries. Can it tell public interface from internal convenience? A system that can’t say where its edges are asks every reader to guess, and agents guess in public patterns.

• Executable verification. Can it run the relevant tests without knowing the team’s folklore? Ground truth has to be a command.

• Bounded action. Can it propose a change that touches one area, with an obvious reviewer and a rollback plan that fits in a sentence?

Many great human systems are not agent-readable, because humans are good at social lookup. They ask Priya. They remember the incident, know which doc is wrong, and hear the tone in the architecture review.

Agents don’t have that network unless the company builds it.

The research is converging on this from below. Princeton’s SWE-agent team (arXiv 2405.15793, NeurIPS 2024) treated the agent’s view of a repository as a design problem in its own right and named it the agent-computer interface: structured search, bounded file views, edit commands, and feedback on every change. Interface design alone changed what the same model could fix. The readability lives in the environment, not the weights. The counterevidence is just as instructive. A study of repository context files (arXiv 2602.11988, February 2026) found that AGENTS.md-style files raised inference cost by over 20% on average without generally improving success. The popular repository-overview format didn’t help at all. The files earned their keep in one place: specifying non-standard practices the agent couldn’t guess. Curated exceptions helped where volume didn’t.

Platform companies are circling the same idea for products and calling it agent experience. The research world has it for tools. Nobody has written the formal treatment at the system level, the one that would tell a CTO what to excavate first, and I’m suspicious of anyone who claims to have it this early. These four properties are my working draft. I expect the field to overwrite them.

This is where I think the next architecture competition happens. AI-native companies won’t merely be faster because they use agents. They will be faster because their systems will be born with fewer private meanings: code, docs, tests, schemas, and operational history arranged so an agent can retrieve the right slice and act inside a bounded scope.

Legacy companies still have domain depth, and that depth is valuable, but is it retrievable? The agent sees the codebase the way a consultant sees an org chart on day one: confidently, incompletely, and with fallible optimism.

An agent-readable architecture is one where the machine can find the rule, touch the right surface, and fail loudly when it misunderstands.

The Verification Tax

I think the fight over AI coding is less about taste than people admit.

At one pole, Andrew Kelley bans LLM-generated contributions from Zig. His argument is economic. Maintainers do not have infinite review time, and a low-effort AI pull request spends the scarcest resource in the project: the attention of someone who can actually tell whether the patch belongs there.

At the other pole, Andrej Karpathy gave us the language of vibe coding, and then the industry took the phrase as permission to stop touching the keyboard. The emotionally honest version of that position is seductive: if the agent can produce the code, why keep paying the human cost of typing it?

Both reactions make sense. That is the uncomfortable part.

The human cost of generating code has gone down significantly while the cost of trusting code has remained the same. Every team that adopts agents eventually runs into this conversion rate. Implementation time turns into verification debt. Sometimes the exchange rate is favorable. Sometimes it is awful.

That is the verification tax.

The Kelley-Karpathy Split Is Rational

I do not read Kelley’s position as nostalgia for hand-written code. I read it as a maintainer protecting the review loop. A compiler project is a hostile environment for median code. It cares about undefined behavior, portability, bootstrap constraints, diagnostics, performance, language design, and a hundred small invariants that are obvious only after years inside the project.

An agent can write code that looks like a contribution but the contributor remains a human, at least for now. That distinction matters. A human who submits a clumsy patch can learn the project. Review time may be an investment. A drive-by AI patch usually has no future learning curve attached to it. The human submitter can disappear, leaving the maintainer to explain the difference between “passes local tests” and “belongs in the compiler.”

So the ban is not irrational. It is a local policy for a system where review bandwidth is the production bottleneck.

Karpathy is also not irrational. He is reacting to a different production function. If I am building a prototype, exploring an API, or generating scaffolding around a clear boundary, an agent can be absurdly useful. I have had the same experience: the code appears faster than my hands can make it. The first draft often gets me to the real question sooner.

The split appears because people are measuring different loops. The enthusiast measures time-to-first-working-version. The skeptic measures time-to-correct-and-maintainable-version. Those are not the same metric.

The perfection loop, even with agents in it, scales down the expected AI speedup.

The METR Result Was A Warning, Not A Verdict

The best empirical work I have seen does not give either side a clean victory. METR’s 2025 randomized trial studied 16 experienced open-source developers working on 246 tasks in mature projects they already knew. The developers expected AI tools to make them faster. Afterward, they still felt faster. Measured task completion time went the other way: with the early-2025 tools in that setting, they were slower.

I would not turn that into a law. Sixteen developers is not civilization. The tools have already improved. The study also focused on mature projects, which are exactly where hidden context matters most.

But that is why I take the result seriously.

The interesting finding is not “AI makes developers slower.” The interesting finding is that experienced engineers can feel acceleration while the system slows down. Prompting feels like progress. Watching the agent stream code feels like progress. Accepting a patch feels like progress. The meter spins.

Then the senior engineer starts paying the bill.

They read the diff. They chase the invariant. They notice that the agent used the local helper but bypassed the authorization boundary. They ask why the migration touches a table it does not own. They wonder whether the “cleanup” changed behavior. None of this work vanished. It moved downstream.

A separate 2025 study of Copilot adoption in open-source projects found the same shape from another angle: less-experienced developers produced more, but the added maintenance and review burden shifted toward core developers. That is the profession in miniature. Output rises. Judgment becomes the choke point.

The Dangerous Code Looks Boring

A syntax error is a kindness, but we all know that the worst AI-generated code is not the code that obviously fails.

The dangerous patch looks cruelly normal. It follows the local naming style. It imports the expected library. It adds a test. The test is often too close to the implementation, but at a glance the ritual has been performed.

Then you look closer.

The schema migration assumes a nullable field is always present because every fixture had it. The retry loop catches the broad exception and converts a partial write into a silent success. The authentication check moved below a cache read because the agent optimized for the happy path. The refactor split one ugly function into four clean ones and lost the fact that a side effect had to happen before the second branch returned.

This is where senior engineers are feeling the profession change under their feet. The old loop was: think, type, run, revise. The new loop is closer to: specify, generate, inspect, constrain, reject, generate again. That is not a small tooling change. It changes where competence lives.

When I hand-write code, some checks happen before language. My hands do not type the broad catch. My hands do not put the auth check after the cache read. My hands have absorbed scars from old outages, old bugs, old reviews, old shame. The agent has absorbed public code. That is not nothing. It is also not my production history.

So when the agent writes, the senior engineer has to externalize instincts that used to be silent. Write the invariant. Write the acceptance test. Write the boundary. Write the “do not touch this table” instruction. Write the review checklist. The tacit has to become executable.

That is painful because tacit knowledge was part of the status game of engineering. The expert knew without saying. Agents punish that.

Legacy Humans Have The Same Problem As Legacy Systems

There is an obvious version of this argument for companies. A twenty-year-old enterprise system contains valuable domain knowledge in the worst possible format: tribal memory, stale diagrams, incident lore, Jira archaeology, Slack threads, and modules shaped by reorganizations no one remembers.

But the same thing is true of a twenty-year engineer.

The legacy engineer has immense knowledge. The question is whether that knowledge can be turned into constraints an agent can use. If it stays as private taste, the agent cannot benefit from it. If it becomes tests, interfaces, threat models, migration rules, and retrieval context, it becomes a force multiplier.

That is the pivot I care about.

The engineer who refuses all agents may still be right inside a compiler, kernel, database, allocator, or safety-critical system where the review tax overwhelms generation speed. The engineer who refuses to learn agent direction in ordinary product engineering is making a different bet: that typing will remain scarce enough to protect them.

I do not buy that bet.

Typing is getting less scarce. Good constraints are getting more scarce. So is taste. So is the ability to know which generated solution is subtly wrong.

The New Seniority

A junior developer with an agent can now create more surface area than a senior engineer can review. That sentence should make managers nervous.

It does not mean juniors become useless. It means the old apprenticeship model breaks if the junior never develops the internal model the agent is replacing. If all they learn is prompting and acceptance, they become fast at producing code they cannot defend.

It also does not mean senior engineers can retreat into purity. A senior who only says “no AI” may be protecting quality in one loop while losing the larger shift in production. The future engineer has to know how to create a harness around the agent: small diffs, deterministic tests, explicit contracts, locked migrations, typed APIs, repeatable benchmarks, permission boundaries, and review gates that fail before a human gets tired.

This is where my loyalties are. I am betting on top-down processing, but not the lazy version where a prompt replaces engineering. I mean top-down as constraint design. The human decides the shape of the system, the invariants that matter, the blast radius, the evaluation, and the language in which success is judged.

The agent fills in leaves. The human owns the tree.

That is a more abstract job, but it is not an easier one. It may require more engineering maturity, because the code no longer carries as many visible fingerprints of its author’s uncertainty. The uncertainty is still there. It is just hidden behind fluent syntax.

The verification tax is the price of that fluency.

I do not want to go back to a world where every leaf node is hand-written. I also do not want a world where nobody can explain why the generated forest is safe to walk through.

The interesting work is in the middle: make human judgment explicit enough that machines can act inside it, and make machine output bounded enough that humans can still verify it.

It is the new software engineering with the private parts of judgment dragged into the light.

The cost of drafting code has collapsed. An agent writes in seconds what used to take a sprint. But the cost of verifying that code has not moved at all. It is still a senior engineer reading a diff, line by line, deciding whether the system’s promises survived.

Kent Beck’s Tidy First? was written as a guide for human refactoring. Read in 2026, it is something stricter: a prerequisite for letting machines change production code without losing control of what the code actually does.

The Fluency Trap

There is a natural signal of uncertainty in human code. Junior developers write syntax that looks hesitant. You can read a pull request and spot the boundaries of their understanding. The rough edges tell you where to focus.

Language models do not hesitate. They produce polished, confident syntax even when hallucinating logic. A function that silently drops an authentication check reads exactly like a function that preserves it. The visual signals of uncertainty are gone.

This is the fluency trap. Teams treat AI code review like human code review, approving massive diffs because they look professional. The actual technical debt being accumulated is trust without verification.

The Tangled Commit

A tangled commit mixes structural changes with behavioral changes. For a human author, this is annoying to review. For an agentic pipeline, it is the failure mode that matters most.

Consider a concrete scenario. An agent is asked to add request logging to a service. To “clean up” the file, it also extracts three helper functions, renames two variables, and flattens a nested conditional. The PR is 400 lines. The logging feature is 12 of them.

Buried in the extraction, the agent drops an early-return guard clause that validated an authentication token. The remaining 388 lines of syntactically perfect structural changes provide cover. The tests pass because no test targeted that specific guard. The reviewer, scanning for the logging feature, approves.

The privilege escalation ships silently. It surfaces weeks later, traced back to a “refactoring” nobody asked for.

When behavior and structure change in the same diff, verifying that no existing invariants were broken becomes intractable. The blast radius of the change exceeds what any reviewer can hold in working memory. Reliability decays with the size of an unverified rewrite, and the decay is steep.

The Cost Asymmetry

Beck roots Tidy First? in two economic principles: the time value of money and the option value of code. Software creates value in two ways. What it does today, and what it could do tomorrow. A well-structured module preserves the option to change cheaply later. A tangled module forecloses that option by coupling every future change to a full rewrite.

When agents write the code, the generation half of this equation collapses. The cost of producing a first draft approaches zero. But the verification half stays fixed. A senior engineer still has to read the diff, trace the invariants, and decide whether the system’s contracts survived. That labor does not scale with the speed of generation.

The result is a permanent asymmetry. There are tasks where AI delivers clear returns: converting a messy JSON payload into a strictly typed DTO against a deterministic schema, or writing a pure function that an existing test harness can validate instantly. Generation is expensive to do by hand, and verification is cheap. The economics work.

Then there are tasks where the savings are illusory. A cross-repository refactoring, a complex business logic change, a structural migration. The agent generates the code in seconds, but the reviewer must re-derive the agent’s reasoning path across the entire dependency graph. The cognitive labor does not disappear. It relocates downstream, lands on the reviewer, and gets more expensive because the diff is bigger and the intent is less legible than a human’s.

Organizations that measure productivity by commit throughput are measuring the wrong side of the equation. The constraint is verification. The metric that matters is how quickly a reviewer can confirm that a diff did what it claims and nothing else. Every tangled commit makes that confirmation slower. Every isolated tidy makes it faster.

Guard Clauses and Dead Code: Why Tidying Is Physical

Beck’s tidying maneuvers read differently when the coder is a transformer.

Guard clauses. Beck recommends returning early to reduce cognitive load. For an agent, a guard clause physically flattens the abstract syntax tree. Flat ASTs mean the model spends less attention capacity tracking nested conditional state. Each level of nesting is a branch the transformer must hold in its weights during generation. Flatten the branches and you reduce the probability of a logic inversion. The tidying changes the computation.

Dead code removal. Beck says delete dead code because it confuses humans. The agentic version is harsher: dead code poisons the prompt. An agent reading a deprecated branch will sample tokens from it and generate hallucinations based on obsolete interfaces. Every unreachable function is a tax on the context window. You pay for that mess in tokens, latency, and degraded reasoning. Dead code removal is garbage collection for the prompt.

These are not metaphors. Guard clauses reduce the model’s branch prediction state-space. Dead code removal shrinks the noise floor of the context window. Beck’s tidying maneuvers have mechanical consequences for transformer-based generation that he could not have anticipated.

Ousterhout’s End-State and Beck’s Transition Function

I wrote previously about John Ousterhout’s “Deep Modules.” Deep modules define the spatial shape a codebase needs for constrained LLM attention to work. They give the agent a clean boundary to operate within.

But how do you reach that state safely when the current codebase is a shallow, coupled mess?

Beck’s answer is the transition function. You tidy first, verify that behavior did not change, then alter behavior in a separate step. The tidying moves the structure toward Ousterhout’s ideal. The separation ensures you can prove each step independently.

Skip the separation and watch what happens. An agent is asked to add a caching layer to a service with a shallow, highly coupled module structure. To make the cache fit, the agent refactors the data access layer: extracting interfaces, renaming internal methods, consolidating three query functions into one. The cache works. But the consolidated query function silently changed the sort order of results because the agent optimized for the cache’s access pattern rather than preserving the original contract. The tests pass because no test asserted sort order. The regression surfaces in a downstream report that nobody connects to the caching PR for weeks.

The agent did two things in one step. You can verify neither independently. Beck’s rule prevents this by making the structural tidy a separate, provable operation. The feature prompt inherits a clean structure and produces a small, focused diff.

You cannot ask an agent to refactor a shallow module into a deep module while simultaneously adding a new feature. Current models routinely fail on multi-file structural refactoring, frequently dropping branches or inverting logic. The transition must be isolated. Tidy, then verify. Only then, change behavior.

The Two-Prompt Pipeline

Agents are fast and compute is cheap. Why bother tidying? Just let the agent rewrite the whole file.

Because a 400-line whole-file rewrite by a non-deterministic model is a reliability problem you cannot review your way out of. Writing is cheap. Proving the rewrite did not introduce a silent failure remains wildly expensive.

The defense is a strict two-prompt pipeline that isolates structural refactoring from feature generation.

Phase one: the pure refactor. The agent is prompted strictly to tidy the structure without altering behavior. This phase is constrained by a tripwire test: a locked unit test written before the agent touches the file, targeting the exact data contract of the module. The agent is forbidden from editing the tripwire. If the structural tidy accidentally alters runtime behavior, the tripwire fails and the loop terminates.

A tripwire test for a user service might look like this:

// LOCKED — do not modify. Tripwire for structural tidy.
test('user service contract', () => {
  const result = createUser({ name: 'test', role: 'viewer' });
  expect(result).toStrictEqual({
    id: expect.any(String),
    name: 'test',
    role: 'viewer',
    permissions: ['read'],
  });
});

If the agent’s refactoring changes the return shape, the permissions array, or the role mapping, this test catches it before the PR exists.

Phase two: the behavioral delta. Only after the structural changes have been committed and verified does the agent receive the second prompt: add the feature. Because the codebase was tidied in phase one, the feature diff is small and isolated. The reviewer reads a focused block of business logic instead of parsing 400 lines of mixed intent.

By separating the prompts, the pipeline creates a verification boundary. Each diff answers one question. Did the structure change safely? Did the behavior change correctly? The reviewer never has to answer both at once.

The Diff as the Unit of Trust

The future of software economics belongs to the teams that enforce the strictest structural boundaries around their agents.

I do not review code anymore. I review diffs. The diff is the unit of trust in a codebase maintained by machines. When that diff is clean and isolated, I can verify it. When it tangles structure and behavior into a single commit, I cannot. No one can. The reviewer’s correction ability drops toward zero, and whatever the agent introduced ships unchecked.

The engineering role has shifted. I write the interface. I write the tripwire test. I set the boundary that triggers an alarm when the agent crosses it. The agent implements. I own what ships.

Writing is cheap. The proof is expensive. The only way to afford the proof is to keep the diff small enough to read.

Tidy first. The machine cannot guess what you meant.

I keep a copy of A Philosophy of Software Design on a short shelf. Eight books, maybe. The ones I still argue with.

Ousterhout’s argument is simple: the enemy of a good codebase is complexity, and the weapon against it is the deep module, a simple interface masking a large hidden implementation. His justification was cognitive load. Human brains hold limited state. Deep modules reduce what you need to hold simultaneously. That justification is now beside the point. The conclusion is more important than ever.

The thing doing most of the implementation work in a modern codebase is running on a transformer with a bounded attention mechanism and a hard token budget. Its cognitive limit is a hardware constraint. When you hand it a shallow module, the failure is a broken production invariant that surfaces three months later with no traceable origin.

The Private State It Was Not Supposed to Touch

Here is the failure mode that clarified this for me. A research team tasked an LLM-based coding agent with adding a statistics dashboard to an existing React application. The app had a public API for reading task data. The agent inspected the interface, found several preconditions to satisfy and parameters to order correctly, and made a calculation.

It skipped the API. It reached into the internal state store and wrote directly to _todos and _nextId, two private variables that were never part of the contract.

Every test passed. The feature shipped. Six months later, a developer refactored the internal state representation. The statistics dashboard broke silently, returning stale numbers with no exception raised, no error logged at the call site, nothing. Just wrong output that a user eventually noticed.

The agent took the cheaper path, not the correct one. The shallow public API cost more tokens to satisfy than writing to the private array. So it wrote to the private array. That is the optimization function at work: minimize tokens, pass the tests, ship the diff.

Ousterhout spent a chapter explaining why information hiding matters. The agent confirmed it empirically, by violating it.

What the Benchmarks Say About Boundaries

The behavioral data at scale matches the pattern from that single incident.

Autonomous agents on SWE-bench, which draws from real GitHub issues across production repositories, resolve roughly 71% of tasks requiring a single-file edit. On tasks requiring changes across multiple files, that drops to roughly 28%. Forty-three points. The gap is not a task difficulty artifact. It is what happens when an agent needs to trace across an abstraction boundary to understand what a change will do.

A deep module makes that boundary cheap. Load the signature, understand the contract, work. A shallow module makes the boundary expensive. Load the implementation, load the callers, load whatever adjacent module holds the state this function implicitly depends on, load the configuration that gates behavior. Every file is tokens. Every token is attention budget that the model cannot spend on reasoning.

You cannot solve this by expanding the context window. A million tokens of shallow module dependency graph does not give the model more understanding. It dilutes the signal with more surface area. The agent still fails; it just fails more expensively.

What Gets Generated When You Ask for Modular Code

Tell an agent to write modular code. Watch what comes out.

Files will be small. Directories will be organized. Interfaces will be defined and injected. It will look correct on a whiteboard. Then try to change a single struct and discover that the definition has leaked into six different files, each of which needs to be updated atomically or the system breaks. The agent distributed a single logical responsibility across the filesystem rather than encapsulating it. The coupling is real; the modularity is cosmetic.

Researchers who systematically analyzed AI-generated codebases at scale named this the “Modular Mirage.” The visual pattern of modularity is present. The semantic isolation that makes modularity useful is absent.

The longitudinal benchmark SWE-CI measures what happens to a codebase over months of agentic maintenance, spanning commits rather than single pull requests. Across those continuous integration loops, most autonomous agents introduced breaking regressions into previously working code on more than 75% of extended tasks. The agent fixed the current ticket. It walked backward over something that worked. The reason is shallow boundaries: a local edit had non-local consequences the agent could not see from within its context window.

The “Define Errors Out of Existence” Chapter Lands Differently Now

Ousterhout’s advice here is to design APIs so that certain errors cannot occur at the call site. If a substring function returns empty on out-of-bounds indices rather than throwing, the caller never needs to handle an exception that carries no actionable information.

Read that chapter again with an agent in the caller role.

An agent hitting an API that throws granular exceptions must write branching logic. It must predict the shape of the error object. It must anticipate edge cases that the API designer could have swallowed once and hidden from everyone downstream. LLMs do this poorly. They will guess the error structure, write a try-catch that catches too broadly, and move on. When the function returns a success code on a corrupted internal state, the agent proceeds to build the next layer on that foundation. The error surfaces far from the origin, in behavior that looks plausible for a while before it obviously is not.

There is a term for this failure mode in the research: silent failure rate, meaning the proportion of API contract violations that produce wrong behavior without raising an exception. Silent failures compound across agentic workflows in a way they never did with human developers, because the human would notice the wrong output during review. The agent will not.

State-of-the-art coding agents top out around 34% success when patching confirmed security vulnerabilities. A large fraction of that failure traces back to this: the agent patches the visible exception path and misses the invariant that was being enforced implicitly by the calling code it just restructured.

An interface that cannot be called incorrectly is not merely a convenience, for agents, it is the only safe interface to expose.

The Margin Note I Would Add to Chapter 11

Ousterhout’s “design it twice” principle is about forcing yourself to draft a second interface before committing to the first. The discipline surfaces what the first draft was actually exposing.

My margin note: every parameter in the signature is a token you are billing your agent maintainer.

The practical test I run before approving any interface: can an LLM use this correctly, zero-shot, from the function signature and a one-line docstring, with no additional context loaded? If the answer is no, the interface is too shallow. That standard is Ousterhout’s standard. The entity being measured has changed, and the measurement has gotten stricter.

Expose twelve configuration flags and you have written a form, not a module. A probabilistic system will fill it out incorrectly.

What the Book Got Right About a Problem It Did Not Know Existed

A Philosophy of Software Design was written for an era when the bottleneck was human working memory. The advice was correct. The frame was narrow.

Deep modules are the only mechanism that gives an autonomous agent a cleanly bounded scope to work in. The interface becomes the contract that defines what the agent can safely assume, touch, and ignore. When that contract is weak, the agent does not operate on a module. It operates on the entire graph of things the module implicitly depends on, which may be larger than its context window and will certainly be larger than what its attention mechanism can hold coherently.

The senior engineer’s job in 2026 is not writing code. I write the interface. I write the test. I set the boundary that triggers an alarm when the agent crosses it. The agent implements. I own what ships.

Ousterhout did not intend to write the survival manual for the post-human codebase. Reading it in 2026, that is what it is.

I do not want to write another memory-wall post. Khola.Blog has already asked modern CPUs to testify under oath, and they have been very clear: scattered memory is expensive.

The more interesting reread of Introduction to Algorithms in 2026 is not that the RAM model hides cache behavior. It does. That is old news here.

The interesting part is that CLRS becomes more important when code is cheap.

When an agent writes an algorithm, the first question is no longer “can someone type the implementation?” The first question is “what did this implementation promise, and can I prove it kept the promise?”

That is the part of CLRS that survives. Not the fantasy that every memory access costs the same. Not the idea that a textbook data structure is automatically a production data structure. The durable part is the discipline: invariants, bounds, recurrences, amortized reasoning, reductions, and worst-case analysis.

I do not read CLRS as a performance manual. I read it as the language a reviewer needs when the patch was written by something fast, confident, and indifferent to production.

The Book Is About Promises

The most useful thing CLRS teaches is not a catalog of named algorithms. It is a way to talk about promises.

A loop invariant says what must remain true before and after each iteration. A worst-case bound says what happens when the input stops being friendly. Amortized analysis says when a rare expensive operation is paid for by a sequence. A reduction says one problem is at least as hard as another. Work and span say parallelism has a critical path, no matter how many processors the scheduler can see.

Those ideas are not academic decoration. They are review tools.

If a generated function claims to maintain a sorted prefix, I want the invariant. If it claims expected linear time, I want to know where the randomness comes from and who can influence the input. If it claims amortized constant time, I want to know whether the tail event is acceptable in the caller’s fault domain. If it spawns work aggressively, I want to know where the span ends and where coordination overhead starts.

Sample tests do not answer those questions. They show that the code survived a small cross-examination.

CLRS gives a reviewer the better cross-examination.

The RAM Model Stops At The Hot Path

The RAM model is a deliberate simplification. It gives every ordinary memory access a constant cost so the proof can focus on how the algorithm scales.

That is not a bug in CLRS. That is the contract of the model.

The mistake is carrying that model into a hot path after the proof is done. Two traversals can both be O(n) and still behave nothing alike. A scan over a contiguous vector gives the processor a boring access pattern. A walk through a linked structure creates a chain of dependent addresses. The notation groups them together because asymptotic analysis is answering a different question.

This is why I do not want the CLRS post to become another cache sermon. The hardware lesson matters, but it is not the main event. The practical rule is smaller:

Use CLRS to prove the shape of the algorithm. Use the machine to price the implementation.

Big-O gets the first vote. The profile gets the final one.

Production Libraries Are Edited Algorithms

The best production algorithms are rarely naked textbook algorithms. They are edited algorithms.

Rust 1.81 began replacing its stable and unstable slice sorting implementations, but it took until Rust 1.95 in April 2026 to finally roll the new logic out across every single sort_by, sort_by_key, and select_nth variant in the standard library. The new algorithms improve runtime performance and compilation time, and also actively try to detect incorrect Ord implementations that would prevent a meaningful sorted result.

That second point is the one I care about for this post.

Sorting is not just “put these values in order.” Sorting assumes the comparison relation behaves like an order. If the comparator violates that contract, the algorithm is no longer operating on the problem it was designed to solve. Rust’s current slice documentation describes the stable sort as based on driftsort, combining quicksort’s fast average case with mergesort’s worst-case behavior and run detection. It also warns that invalid ordering can panic or produce unspecified order. Making that safe and fast across every variant required deep, layout-aware engineering. The textbook algorithm is just the starting point; the production implementation is an exercise in managing the machine.

That is CLRS in production clothing: the algorithm needs a mathematical contract before performance even enters the room.

Hash tables make the same point from the data-structure side. Abseil’s Swiss Table design notes describe metadata bytes and group matching for lookup. Its container guide recommends absl::flat_hash_map and absl::flat_hash_set for general use, while spelling out the trade-off: flat storage helps the general case, but rehashing invalidates pointers and node-based variants still matter when pointer stability is required.

That is the engineering version of the CLRS lesson. The asymptotic target is not enough. The implementation has to choose which promise matters: lookup speed, pointer stability, memory overhead, iteration behavior, adversarial input resistance, or migration safety.

The textbook gives the vocabulary. The library makes the trade.

The New Failure Mode Is Plausible Wrong Code

The dangerous agent output is not always nonsense. Nonsense is easy.

The dangerous output compiles. It has the right shape. It imports the local helper. It passes the examples in the prompt. It looks boring enough to merge.

Then the comparator is not a total order. The recursive dynamic program has no real memoization boundary. The randomized algorithm uses a predictable source. The priority queue choice is fine for the lecture but wrong for the update pattern. The graph traversal mutates the structure whose invariant it is pretending to inspect.

These are not aesthetic failures. They are contract failures.

A human reviewer can miss them too. The agentic shift just changes the volume and confidence of the patches. It moves the hard work from writing code to rejecting code that is plausible but underspecified.

That is why the review should not begin with style. Style can wait. First, I want the algorithmic contract:

1. What invariant does this code preserve?

2. What is the worst case, and who can trigger it?

3. Is the expected-case argument relying on randomness, distribution, or trust?

4. Does the amortized event fit the caller’s latency budget?

5. Which input breaks the mental model but still satisfies the type signature?

6. Is this a place to use a standard library implementation instead of generated code?

7. If the path becomes hot, what data layout does the proof ignore?

That checklist is not anti-agent. It is anti-magic.

The Margin Note

I would not write “the RAM model is a lie” in my copy of CLRS. That is too cute and not quite true.

I would write this instead:

Valid for proof. Insufficient for cost. Mandatory for review.

The first sentence protects the book. The second protects the system. The third is the update for machine-written code.

CLRS does not teach agents to write good software. It gives humans the language to reject software that only looks good. That distinction matters more now, not less, because the cost of producing plausible code has collapsed.

The workflow does not just need faster generation. It needs stricter judgment. Every generated algorithm still owes the same debt: state the invariant, respect the bound, name the bad input, and prove that the implementation you shipped is the one the proof was talking about.

I do not think The Pragmatic Programmer has aged out. I think the environment around it has become less forgiving.

The book is not really about tools. It is about engineering posture: take responsibility, keep systems easier to change, make feedback loops tight, test what can fail, and refuse to live with broken windows. That posture still holds. What changed is the failure surface.

In 2026, a code agent can produce a week of mediocre abstraction before lunch. A laptop-class chip can execute billions of instructions per second and still spend the hot path waiting on scattered memory. A global control plane can replicate bad state across regions faster than a human can open the incident channel.

That does not make pragmatism obsolete. It makes the old advice more literal.

ETC Has a Physical Layer

The book’s central design rule is ETC: easier to change. That rule is still the right one. The mistake is treating “easier to change” as a synonym for “more abstract.”

That is how codebases end up with a hierarchy for every noun, an interface for every class, and a dependency-injected trail of breadcrumbs between one integer and the next. It feels civilized in review. It often benchmarks like a pile of receipts.

Modern CPUs do not run class diagrams. They fetch cache lines.

Intel’s Lunar Lake design puts more attention on power, memory proximity, and a memory-side cache. Apple’s M5 pushes unified memory bandwidth to 153 GB/s. Those are not licenses to ignore locality. They are evidence that silicon vendors are spending real die area and packaging complexity to hide the cost of moving data.

Software can still defeat all of it with pointer chasing.

The common agent failure is not exotic. Ask for a particle update loop, a pricing pass, a simulation tick, or a ranking transform, and the default output often looks like this:

struct Particle {
    float x;
    float y;
    float z;
    float vx;
    float vy;
    float vz;

    void step(float dt) {
        x += vx * dt;
        y += vy * dt;
        z += vz * dt;
    }
};

std::vector<Particle> particles;

That shape is fine until the loop matters. Then every iteration drags fields through memory as an object bundle, whether the CPU needs all of them or not.

For a hot loop, I want the data shaped around the access pattern:

struct ParticleBlock {
    std::vector<float> x;
    std::vector<float> y;
    std::vector<float> z;
    std::vector<float> vx;
    std::vector<float> vy;
    std::vector<float> vz;

    void step(float dt) {
        for (size_t i = 0; i < x.size(); ++i) {
            x[i] += vx[i] * dt;
            y[i] += vy[i] * dt;
            z[i] += vz[i] * dt;
        }
    }
};

This is not an argument for flattening the whole application into arrays. It is an argument for performance tiers.

Business policy can afford indirection. Hot loops, storage engines, serialization paths, rendering, compression, matching, ranking, and simulation usually cannot. In those places, ETC means the future maintainer can find the data flow, predict the memory access, and benchmark the change without spelunking through ceremony.

The pragmatic move is not “object-oriented” or “data-oriented.” The pragmatic move is knowing which part of the system is paying rent to the cache hierarchy.

Big-O Is Missing the Invoice

Big-O is not wrong. It is incomplete.

It throws away constants because that is what makes asymptotic reasoning useful. The machine puts those constants back with interest. A branch mispredict, a cold cache line, a TLB miss, a failed prefetch, and a recursive call frame all live outside the clean little expression.

That is why production sorting implementations use hybrids. The high-level algorithm carries the asymptotic guarantee. The small-partition fallback respects the machine.

For tiny contiguous ranges, insertion sort can beat a theoretically superior algorithm because it walks memory in a boring pattern. Boring is a feature. The hardware can prefetch it. The branch predictor can learn it. The compiler can see it.

The lesson is not “always use insertion sort.” That would be a cargo cult with a better haircut. The lesson is that the crossover point belongs to the benchmark, not the blog post.

This is the update I would write into the margin of the book: estimate first, then measure at the physical boundary. If the path is CPU-bound, measure cache misses. If it is I/O-bound, measure queueing and tail latency. If it is distributed, measure retries, coordination, and blast radius.

An asymptotic proof is the start of the conversation. A profile is where the machine gets a vote.

Agents Make Broken Windows Cheap

The book’s broken-window rule gets more important when code is cheap.

A human usually leaves a broken window one commit at a time: a vague name, a duplicated branch, a swallowed exception, a test skipped because the release is late. An agent can stamp out the same damage across twenty files with a confidence that feels suspiciously like authority.

The dangerous part is not that agent-generated code is bad. The dangerous part is that it is plausible.

It compiles. It uses the local framework. It names things in the house style. It may even come with tests. Then the system gets a new retry loop without jitter, a cache without invalidation, a transaction boundary around network I/O, or a catch-all handler that turns a real fault into quiet data corruption.

That changes the human job.

I do not review agent output as prose. I review it as an untrusted patch from a fast junior engineer with perfect typing and no memory of production.

The review checklist is blunt:

1. What invariant does this code claim to preserve?

2. Where does it fail closed, fail open, or fail loud?

3. What resource does it acquire, and where is that resource released?

4. What happens under retry, cancellation, partial failure, and duplicate delivery?

5. Which test would have failed before the fix?

6. Which benchmark proves the abstraction did not move the bottleneck?

That is not anti-agent. It is pro-accountability.

I would also keep an agent audit trail for serious systems. Not a theatrical “AI disclosure” badge. Useful metadata: model family, tool permissions, prompt or task summary, human approver, files touched, tests run, and any ignored failures.

The point is not blame. The point is defect analysis. If one model or workflow repeatedly creates the same kind of race, leak, or injection bug, I want that pattern visible.

Pride of ownership still means what it meant in the book. I signed the change. I own the blast radius.

Paranoia Survived Contact With Reality

The strongest part of The Pragmatic Programmer is its distrust of happy paths.

That distrust looked almost old-fashioned during the era of framework optimism. It does not look old-fashioned after the 2025 cloud incidents.

AWS published a summary of the October 19-20, 2025 DynamoDB disruption in us-east-1. The root trigger was a latent race condition in DynamoDB’s automated DNS management system. A stale DNS plan was applied, cleanup removed the active regional endpoint addresses, and DynamoDB endpoint resolution failed. The primary DynamoDB disruption recovered in hours, but EC2 instance launch recovery took far longer because dependent control-plane systems had entered congestive collapse.

That is the part worth studying. The first bug was a race. The real lesson was coupling.

A regional DNS management defect impaired a foundational datastore. Services that depended on that datastore could not make forward progress. Recovery created a herd effect. The system then needed throttling, restarts, and careful queue reduction before it could breathe again.

Google Cloud’s June 12, 2025 incident was smaller in duration but cleaner as a lesson. Google described a Service Control change for quota policy checks that lacked the right error handling and was not protected by a feature flag. A policy update inserted blank fields into regional Spanner tables. The metadata replicated globally within seconds. The null pointer path crashed Service Control binaries across regions and some restarting tasks created a herd effect on the underlying Spanner table.

The bug was not mysterious. The propagation path was.

This is pragmatic paranoia in production language:

1. State that can replicate globally needs staged propagation.

2. Automated deletion needs velocity limits.

3. Critical policy paths need feature flags that default off.

4. Control planes need failure isolation from the services they manage.

5. Restart loops need jitter and backoff before they become load generators.

6. Monitoring cannot depend entirely on the system it is meant to diagnose.

“Crash early” is still good advice inside a bounded fault domain. It is reckless advice when the crash loop can synchronize globally.

The rule I use is simple: crash local, recover global. Assert at the boundary where bad state enters. Quarantine the bad input. Keep the serving path degraded if safety allows it. Make the supervisor boring, bounded, and explicit.

The Merge Queue Is Now Architecture

The book treats automation as a professional baseline. That part now includes the merge queue.

When agents produce many small patches, a sequential queue becomes a throughput bottleneck and a correctness risk. A long queue encourages bigger batches. Bigger batches make failures harder to isolate. Harder isolation creates slower review. Slower review invites more automation to pile up behind it.

That is a feedback loop, not a tooling inconvenience.

Speculative CI is the right mental model. Test the next few queued changes against predicted future states of main. If patch A is expected to land, test B on top of A. If A fails, throw away the speculation and recompute. The trade is obvious: spend more compute to protect human attention and reduce queue latency.

The expensive part is deciding what to test.

I want deterministic test selection based on ownership and dependency graphs. I want property tests around parsers, protocol boundaries, money movement, authorization, and data structure invariants. I want replay of historical counterexamples before random generation burns a cluster. I want performance checks only where the patch touches a known hot path.

The starter kit is no longer just formatter, unit tests, and CI. For agent-heavy development, the starter kit is the operating system for trust.

What I Would Change In My Copy

I would not rewrite The Pragmatic Programmer. I would add margin notes.

Next to ETC, I would write: “Easier to change includes easier to profile.”

Next to DRY, I would write: “Agents duplicate intent more often than text.”

Next to Design by Contract, I would write: “Contracts are the spec the agent does not get to improvise.”

Next to Crash Early, I would write: “Only inside a fault domain with a supervisor.”

Next to Don’t Live With Broken Windows, I would write: “Machine-generated broken windows still count.”

Next to Pragmatic Teams, I would write: “The human team owns context. The agent owns nothing.”

That last one is the real update.

The industry keeps trying to turn software engineering into text generation. The book’s answer is still better: software engineering is judgment under constraint. Tools change the cost curve. They do not remove responsibility.

I want agents in the workflow. I also want cache-aware data structures, explicit invariants, boring release controls, and incident reports that name the coupling. The distinguished engineer in 2026 is not the person who types the most code. It is the person who can still see the system after the code becomes cheap.

Structure and Interpretation of Computer Programs teaches that computer science is a branch of mathematical logic. It builds processes in an idealized sandbox where memory is infinite, pointer dereferences are instantaneous, and execution frames carry zero cost.

Nevertheless, in the systems of 2026, hardware is not a mathematical plane. It is a thermal and spatial grid. The elegant abstractions of classical computer science run directly into microarchitectural bottlenecks. Specifically, lexical environments and closures collapse under the physical constraints of the memory wall.

Structurally, we must discard the illusion of infinite memory to analyze how software structures interact with the silicon layer.

The Microarchitectural Cost of Pointer Chasing

Modern out-of-order execution engines derive their massive throughput from memory-level parallelism. Linear array scanning aligns perfectly with hardware prefetchers, allowing the CPU to compute the address of the next contiguous element instantly. Speculative loads pull cache lines into the L1 cache before the execution engine requests them. Consequently, the effective latency approaches the blazing fast 3-cycle L1 speed of the Apple M4.

Conversely, sequential pointer chasing is inherently hostile to modern hardware pipelines. Lisp pairs, binary trees, and deeply nested closures rely on scattered heap allocations. When traversing a linked list, the exact memory address of the subsequent node remains unknown until the current node’s payload is fetched from main memory.

This serialization creates an unbreakable dependency chain that blinds the hardware prefetcher. As memory-level parallelism collapses, the Reorder Buffer rapidly fills with stalled instructions, forcing the execution unit to wait out the agonizing 100-nanosecond latency of DRAM.

Because a modern processor operates near 5 GHz, a single DRAM access wastes 500 clock cycles. If the CPU possesses a decode width of 8 instructions per cycle, the penalty is severe. The processor throws away over 4,000 potential instruction executions per memory hop. Thus, pointer chasing forces massive CPUs to operate at a fraction of their theoretical throughput.

The Jungle Walk Mental Model

Imagine driving on a straight highway where you speculatively look ahead and accelerate. The CPU prefetcher is your cruise control, bringing the road ahead into view before you reach it. Pointer chasing is like walking through a dense jungle with a machete. You cannot see the next step until you clear the immediate brush. Your speed is restricted to how fast you clear each step, forcing your massive out-of-order cores to stand idle.

The Bridge: How Environments Map to Silicon

The penalty of pointer chasing extends far beyond isolated CPU cache misses; it fundamentally dictates the failure modes of distributed edge infrastructure. An environment frame (or a closure) is a massive, deeply nested graph of pointers scattered across the heap.

Serverless platforms like AWS Lambda and Cloudflare Workers promote a strict stateless execution model. However, to bypass the extreme latency of cold starts, these platforms maintain warm execution environments by reusing the underlying container or V8 isolate across multiple sequential invocations. When a V8 isolate keeps a closure “warm”, it is effectively keeping that massive, scattered pointer graph alive. When the runtime must traverse this graph (either during execution or garbage collection sweeps), it defeats the CPU’s hardware prefetcher. Simultaneously, the sheer volume of retained state shatters the memory limits of the serverless container.

The Stale Air Lock Mental Model

Serverless warm environments are like a submarine air lock reused without flushing. The global frame is the main chamber, whereas the local handler invocation is the inner chamber. If stale credentials or closures are left in the main chamber, the next occupant breathes toxic air, inheriting the corrupted, recirculated state.

AWS Lambda Closure Scope Retention

A prominent pathology involves aggressively caching data in the global scope. In one documented incident, an engineering team deployed an image generation pipeline on AWS Lambda by initializing asynchronous callbacks outside the handler. Under sustained load, the closures created during each invocation captured strong references to massive buffer arrays.

Because the global environment frame retained strong bindings to these scattered closures, the V8 garbage collector was entirely blocked from reclaiming the memory. The Resident Set Size climbed relentlessly with each warm invocation until the container exhausted its 5 GB memory limit and was terminated via SIGKILL. The resolution required strictly scoping mutable arrays to the local execution frame inside the handler, ensuring complete destruction upon function termination.

Cloudflare Workers Credential Bleed

State bleed also corrupts configuration security. On March 21, 2025, Cloudflare’s R2 object storage experienced a massive global outage caused by an architectural failure to strictly isolate global environment frames. During a routine key rotation, an engineering team inadvertently pushed new authentication credentials to a development instance instead of production.

When the old credentials were deleted from the backend, the production Workers were left holding a stale, globally bound context frame. Because the Worker reused its warm environment, it continued attempting to authenticate using the deleted keys. The resolution required deploying updated credentials to force the instantiation of new environment frames.

Bridging the Abstraction Gap

Ultimately, physical hardware realities dictate high-performance software architecture. Lisp’s elegant functional model has not failed, but it breaks down completely in hot-path, high-throughput data processing. Tree structures and closures remain perfectly valid for high-level business logic where the network is the actual bottleneck.

Nevertheless, the memory wall mandates contiguous memory arrays and explicit Data-Oriented Design (DOD) for performance-critical execution. Flat buffers and static memory layouts respect the physical thermal grid. In summary, if hot-path software abstraction ignores the hardware substrate, the inevitable outcome is a massive spike in latency.

Martin Kleppmann’s Designing Data-Intensive Applications is basically required reading for backend engineering. The core premise still holds up: data volume, complexity, and velocity constrain architecture far more than raw CPU cycles.

But hardware doesn’t stand still. Reading the book in 2026 requires updating the physical variables Kleppmann used in his assumptions. When you swap in modern NVMe storage and unified compute engines, the structural trade-offs he outlines shift significantly. Here is a look at what actually survives contact with modern production infrastructure.

1. Storage: The Metal Layer

Kleppmann dedicates a lot of space to the trade-offs between the traditional B-Tree and the Log-Structured Merge-tree (LSM-tree).

The B-Tree updates fixed-size logical disk pages in-place. DDIA correctly points out why this was a problem on magnetic hard disk drives (HDDs). Modifying a small record meant reading an entire page into memory, updating it, and writing it back to random locations. Because HDDs rely on mechanical arms, random seeks killed your IOPS.

LSM-trees bypassed this by turning random writes into sequential logs. Data is appended to a Write-Ahead Log and a memory buffer, then flushed to disk as immutable Sorted String Tables. It solved the HDD write bottleneck but introduced the compaction tax. Background compaction burns CPU and saturates disk I/O, which causes unpredictable tail latency spikes.

The 2026 Reality: The modern data center runs on enterprise NVMe SSDs. These drives use highly parallel flash channels that largely neutralize the performance gap between sequential and random writes.

More importantly, modern enterprise SSDs have internal hardware controllers that perform transparent compression directly on the physical I/O path. If you use a modern B-Tree variant that logs zero-padded delta updates, the NVMe hardware instantly compresses the zeroes away. This drops the write amplification of the B-Tree from over 200x down to roughly 20x.

For general-purpose workloads today, the B-Tree is usually the better default. You get predictable read performance without paying the LSM compaction tax, because the hardware solved the random-write problem for you.

2. Distributed Data: The Network Layer

When dealing with distributed transactions, DDIA covers coordination protocols like Two-Phase Commit (2PC). In 2PC, a coordinator asks all participating nodes to place pessimistic locks on database resources before committing.

While the book acknowledges the performance hit of 2PC, its blocking nature is a complete non-starter in modern async architectures.

The 2026 Reality: Today’s infrastructure relies heavily on long-running AI workflows and agent swarms. A single workflow might take hours to resolve. You cannot hold synchronous database locks across a distributed cluster for hours without causing complete system gridlock.

The industry has largely abandoned strong global consistency in favor of eventual consistency. We rely on Orchestrated Sagas and the transactional outbox pattern. You isolate the transaction locally, commit it, and publish an event to trigger the next step. There are no distributed locks held across service boundaries.

3. Derived Data: The Unbundling Layer

One of the best concepts in DDIA is unbundling the database. Instead of treating a single RDBMS as the system of record and fighting to keep caches in sync, you treat an append-only event log (like Kafka) as the source of truth. The database and search indexes are just materialized views derived from that log.

To handle analytical workloads in this model, DDIA discusses the Lambda Architecture. This involves maintaining a slow batch pipeline for accuracy and a fast stream pipeline for real-time approximation.

The 2026 Reality: In practice, Lambda was an operational nightmare. You had to write, debug, and maintain your business logic twice across two different frameworks. That pattern is dead.

The maturation of unified execution models like Apache Flink operating over Lakehouse formats like Apache Iceberg has eliminated the need for it. “Batch” is now just treated as a bounded stream operating over a finite dataset. You get ACID transaction guarantees directly on top of scalable object storage. You write the pipeline once, and it handles both real-time ingestion and historical batch queries using snapshot isolation.

Final Thoughts

DDIA is still the best baseline we have for distributed systems theory. The abstractions are correct. But as engineers, we can’t treat the implementation details as dogma. The physical hardware dictates the architecture. Update the hardware assumptions, and the correct architecture changes with it.