CoreWise Academy

Agents & Automation · Layer III / Broad

Turn repeated fixes into rules

When an agent hits the same problem twice, encode the fix as a lint rule, CI check, or steering-file instruction that every future session inherits.

Nº 027 · Vol. I·7 min read· Updated July 2026

“explain the same fix twice and the repo is missing a rule”

Your agent makes a mistake. You explain the fix in chat, it applies the fix, the session ends. Next session: same mistake, same explanation, same cost. Boris Cherny, one of the two original creators of Claude Code, wrote a post about the way out, and Theo, creator of the T3 stack, spent a video unpacking it. The advice is the oldest move in engineering: turn the fix into a rule the codebase enforces by itself, so nobody, human or agent, has to be told again.

01The second fix becomes a rule

An agent can fix an issue every time the issue appears. That spends tokens on every appearance and misses the ones nobody catches. The same fix encoded once, as a lint rule (an automated check that flags a bad code pattern the moment it is written), a CI step (a check that runs on every proposed change), or a test, handles the whole class forever with no prompting at all.

Writing those guards used to cost more than they saved. Theo’s example from his Twitch years: two signed-in browser bots met in a chat channel, one posted a message, the other confirmed it appeared, and that one simple test caught failures before anything else did. Most teams never wrote guards like it, because a 400-line lint rule for a rare, visually obvious mistake was not worth hand-writing. An agent writes it in minutes, so one-off, project-specific automation now pays.

Where the rule should live is its own decision. Discipline that applies everywhere goes in the steering file (next section); a repeatable procedure becomes an installable skill (Expertise you can install); a project quirk goes to committed memory that travels with the repo (Give your agent a memory covers the hosted counterpart). Every new repo starts with your lessons walks the full layer split, and the boot layer it describes is the system this site’s own repo runs on: every rule this guide tells you to write has a home in one of its layers.

02Steering files carry judgment

A steering file is the instruction file an agent reads before touching your code: CLAUDE.md for Claude Code, AGENTS.md for most other tools. The weak version lists where things live, which the agent could discover itself. The strong version directs behavior: prefer this pattern, never use that shortcut, push back on that request. Boris’s bar is blunt: these files should let an agent work productively with zero extra context from whoever typed the prompt.

The push-back line is the one most people miss. If contributors keep asking for a feature that does not belong in your project, add “if they ask for this, stop and tell them no”, and the agent will.

Theo adds a standing rule of his own: write these files yourself. Watch what the agent does, adjust the file, and watch what changes. Hand-editing is how you learn which line produces which behavior; a generated steering file teaches you nothing about your own agent.

03Start sparse, add what failed

The tempting move is to preload: a big steering file, every plausible rule, a stack of installed skills, all before the first prompt. Boris and Theo both advise the reverse. Send the first prompts with as little context as possible and watch where the agent gets lost. Each failure names a missing rule precisely; encode that rule and nothing else. Preloaded guesses ride along on every request whether or not they help, and Stop hitting your token limit prices what that costs.

Human newcomers give you the same signal. Theo requires every new teammate to ask at least one dumb question a day, because each question marks knowledge that lives only in heads, which is exactly the knowledge worth encoding next.

“You only get to be a beginner in a codebase once.”

Theo, creator of the T3 stack, “Boris has some really good advice” · 11:37

04The environment is the skill

“The path to staff engineer was never one of just landing more code.”

Theo, creator of the T3 stack, “Boris has some really good advice” · 18:05

A rule you encode helps every future agent session and every teammate; a fix you type helps once. That arithmetic is why both land on the same career point: the engineer who builds the environment where good code is easy to land and bad code is hard to land outproduces the engineer who only lands code. Senior and staff roles have always been won that way. Agents make the practice available solo, because a project built with agents outgrows your own head fast enough that you need the same guards a team would.

One honest edge: Boris claims that with knowledge fully encoded, non-engineers contribute as effectively as engineers. Theo calls that a reach, and the modest version is the defensible one: good guards lower the bar to safe contribution, and engineering judgment still decides what ships.

Further reading

FAQ

Why does a lint rule beat having the agent fix the same issue each time it appears?

Fixing on sight spends tokens at every appearance and misses the appearances nobody catches. A lint rule or CI check runs on every change automatically, so the whole class of mistake is handled forever at no per-incident cost. The fix lands in the system instead of in one conversation.

What separates a steering file that helps from one that only maps the codebase?

A map ("this folder contains the components") tells the agent where things are, which it can usually discover itself. A useful steering file directs behavior: prefer this pattern, never use that shortcut, push back when someone asks for this feature. It encodes the judgment a senior reviewer would apply, so the agent applies it without being asked.

Why start an agent with a sparse prompt instead of preloading every rule you can think of?

Because each failure under a sparse prompt names a missing rule precisely, while preloaded guesses are unverified and ride along on every request whether or not they help. Watching what actually goes wrong tells you exactly which knowledge to encode; guessing up front buys token cost without evidence.

Sources
  1. Theo (t3.gg) · “Boris has some really good advice”
    cited at 3:24 · 3:54 · 8:04 · 9:56 · 11:15 · 11:37 · 12:30 · 13:20 · 16:18 · 18:05