The Corrections You Stop Making

Tuesday, late afternoon. I'm reviewing the fifth agent-written pull request of the day and I catch myself doing the thing I'd pull a junior up on: scrolling. The diff looks fine. Tests pass, the screenshots match the design, the code is tidy. Somewhere around the third file I notice text-[#4f46e5] sitting in a className, a raw hex value lifted straight out of the design file, and I realise I've probably approved this exact thing twice already today.

I'd corrected this mistake before. More than once. The agent pulls colour values from design specs literally instead of using the design system's semantic tokens. The rendered output is pixel-identical, so nothing catches it. Not the tests, not the linter as configured, not a reviewer whose attention is spent on the logic. It becomes a problem months later, when the palette changes or a dark theme ships and forty hardcoded hex values don't move with it.

What annoyed me wasn't the mistake. It was that I'd already paid the attention to catch it, twice, and the correction had evaporated both times.

Judgement doesn't parallelise

The economics of my job had shifted under me without my noticing. Producing a diff is no longer where my time goes; judging one is. An agent can draft three pull requests while I'm reviewing the first, and my review quality at 4pm is measurably worse than at 9am. Typing scaled. Judgement didn't.

For a while I treated this as a stamina problem. Review more carefully, take breaks, cap the number of agent tasks in flight. That helped at the margins, but it misread the situation. When I looked honestly at a month of my own review comments, most of them weren't judgement at all. They were repetition. The same conventions, re-explained. The same context, re-supplied. My scarcest resource was being spent re-teaching things I'd already taught.

Every correction you make in review is context the agent didn't have. A correction you make twice is context you failed to keep. I'd been paying interest on that debt in the currency I could least afford: attention.

Writing it down, once

So the hex value got a file. My agent setup keeps a directory of small markdown memories, one fact per file, loaded when relevant. The entry looks like this:

---
name: no-raw-hex-in-classnames
description: Never use arbitrary hex values in Tailwind classes
metadata:
  type: feedback
---
 
Use semantic tokens (`text-neutral-900`), never raw values
(`text-[#1e293b]`).
 
**Why:** a raw value renders correctly today and silently detaches
the component from the design system. Theme changes and dark mode
will never reach it.
 
**How to apply:** when a design specifies a colour, find the token
that resolves to it. If no token matches, that's a design-system
gap to raise, not a reason to hardcode.

Three things about this entry did the work. It records the why, so the agent can generalise to cases I didn't enumerate. It records how to apply the rule, including what to do at the edge (no matching token exists), which is where agents usually improvise badly. And it's one fact in one file, so it can be found, updated, or deleted without archaeology.

The mistake never came back. Not because the model got smarter. The model is the same. My setup got smarter, and it stayed smarter across sessions, across projects, and through two model upgrades.

What didn't work first

I want to be honest about the failed attempts, because the failures shaped the approach more than the successes did.

My first instinct was to put everything in the always-loaded instructions file. Every convention, every preference, every past incident. It grew past three hundred lines and the agent started treating it the way people treat long terms and conditions: technically present, functionally ignored. Worse, some rules went stale. One pointed at a script that had been renamed months earlier, and I watched the agent burn ten minutes trying to run it. A stale rule isn't neutral. It costs more than no rule, because it spends the agent's trust and my time simultaneously.

The always-loaded file is expensive real estate. It now holds only what's true everywhere, all the time. Everything else lives in the memory ledger and loads when it's relevant.

I also trialled a tool that sat between me and the model and rewrote context on the fly to save tokens. It was clever, and I uninstalled it within a fortnight. It had silently modified configuration I hadn't asked it to touch, and once I couldn't say with confidence what the agent was actually reading, every review got harder, not easier. Whatever enters the context window, I want to have put it there or at least be able to see it. Quality control starts with knowing what the thing being controlled was told.

Keeping sessions short and claims verified

The other half of this is context hygiene, which is less about what goes in and more about what accumulates.

Long agent sessions rot. Forty minutes in, the context window holds every dead end, every abandoned approach, every half-corrected misunderstanding, and output quality degrades in ways that are hard to attribute. I stopped fighting this. Substantial tasks now go to a fresh agent with a clean context and a tight brief, and I review the outcome, not the transcript. The task brief forces me to state what "done" means, which turns out to be half the review done in advance.

And "done" is no longer something the agent gets to assert. The workflow requires evidence before claims: run the tests and show the output, run the linter, paste the failing case that now passes. This sounds bureaucratic and takes seconds. Its real effect is on me. When a claim of completion arrives with evidence attached, my review starts from verified ground and my attention goes to design and intent, the things that actually need a senior engineer. Cheap machine time spent proving the basics buys back expensive human attention for judgement.

For bigger changes I go one step further and put a second agent in the loop as a reviewer before I ever see the code, cycling drafts until the reviewer runs out of objections. The first drafts an implementation; the second, with fresh context and no attachment to the approach, critiques it. It catches an embarrassing amount. My attention is the bottleneck resource in the whole system, so spending tokens to protect it is the easiest trade I make all week.

From a personal ledger to a team one

The pattern scaled in a way I didn't plan. Our engineering chapter now keeps its agent conventions in a git repository: versioned, code-reviewed, with owners for each area. When someone makes a review correction worth keeping, it lands as a pull request, gets reviewed like any other change, and every engineer's agent inherits it from then on.

It's onboarding documentation, really, for a teammate with perfect recall and no memory. The compounding return is the same as good onboarding docs for humans, with one difference that still feels unfair: this teammate actually reads them, every single time.

None of this is exotic. It's the discipline senior engineers already trust, CI gates, review culture, documented conventions, pointed at a new kind of colleague. The heroic version of AI-assisted quality, where one tired human out-reviews a tireless code generator, was never going to hold.

The measure I watch now is a quiet one. It isn't review throughput or how many issues I catch. It's noticing, mid-review, that a correction I used to make weekly has simply stopped being needed, and that the attention it used to consume is back where it belongs, on the parts of the diff no ledger entry could ever cover for me.