Jonathon's AI Wiki

Engineering Leverage in the Agent Era — Boris Cherny on Encoding Tacit Knowledge as Infrastructure

10 min read

Source: raw/x-account-bcherny-2077460395279692197.md · raw/Boris_has_some_really_good_advice.md (video reaction, 2026-07-21) Author: @bcherny (Boris Cherny, Claude Code creator) URL: https://x.com/bcherny/status/2077460395279692197 Posted: 2026-07-15

A substantive thread (8K+ likes per the source’s own framing) from Boris Cherny on how engineering leverage has changed in the coding-agent era. His argument: top engineers have always focused on high-leverage automation — better editor configs, lint rules, comprehensive tests — and coding agents make this matter more, not less, for three reasons. The thread’s throughline: writing CLAUDE.md rules, REVIEW.md guidelines, skills, and memories is core engineering work, not overhead, because it’s what lets agents operate with zero extra context from the prompter.

Key Takeaways

  • The baseline claim. Top engineers have long focused on high-leverage automation (editor configs, lint rules, comprehensive tests). Coding agents raise the stakes on this habit rather than replacing it.
  • Reason 1 — infra automation now scales to armies of agents. DevX/infrastructure improvements multiply output per unit time across however many agents a team runs, not just one engineer’s own workflow.
  • Reason 2 — moving fixes into code creates permanent automation. Lint rules, CI steps, and routines replace repeated, token-heavy, one-off fixes. Cherny frames this as the real meaning behind “loops” — not a single clever prompt, but a fix that never has to be re-explained.
  • Reason 3 (Cherny’s “most important”) — democratizing contribution. Claude helps new engineers and non-engineers ramp up and contribute on day one by navigating codebases for them. The historical bottleneck was tacit domain knowledge that lived only in people’s heads; agents let teams encode far more of it as infrastructure: CLAUDE.md rules, REVIEW.md guidelines, skills, memories, code comments, and docs. This heads off PR rejections over framework/architecture issues that could have been caught automatically.
  • The framing, stated plainly. Cherny frames writing these artifacts as core engineering work, not overhead — the payoff is that agents operate with zero extra context from the prompter, code review becomes more automated, and the codebase becomes more accessible to people who didn’t write it.

How this connects to the wiki’s existing Cherny coverage

This thread sharpens an idea already on record from Cherny: the June 2026 retrospective with Cat Wu states “every single time Claude makes a mistake, I don’t tell Claude to do it differently. I tell it to write it to the CLAUDE.md or to make a skill” — the same encode-the-fix mechanic. This thread extends that single practice into a fuller argument, adding two elements the retrospective didn’t cover: REVIEW.md as a distinct artifact type alongside CLAUDE.md, and the explicit democratizing-contribution framing (non-engineers ramping up on day one, PR rejections over framework issues avoided). It is a distinct enough thesis — and a different source and date — that it’s filed here as its own article rather than merged into that video’s writeup.

It is also a different thing entirely from Agentic Coding and Persistent Returns to Expertise, the Anthropic Economic Research team’s 400,000-session data study on planning/execution division of labor and expertise-linked success rates. That article reports measured outcomes; this thread is Cherny’s own argument about why teams should invest in encoding tacit knowledge. They share a topic (how expertise and engineering practice interact with coding agents) but make no overlapping factual claims, so this stays a separate article rather than a refresh of that one.

The practitioner reaction — Theo Browne’s operating rules (2026-07-21)

Source: raw/Boris_has_some_really_good_advice.md, a video walkthrough of this same thread by the creator of the T3 stack. He self-identifies throughout (“this is why I made the T3 stack in the first place”; “T3 Code”). He agrees with the thesis and adds the operating rules Cherny’s thread leaves implicit, plus one substantive partial disagreement.

Rules for the steering files themselves:

  • “Do not let your agents write your CLAUDE.md or AGENTS.md.” Stated as an absolute, and repeated. His reasoning is that hand-writing them is how you build the intuition for which instructions actually change agent behavior — outsourcing that loses the feedback signal, not just the quality.
  • Don’t touch any of these files until you’ve sent the first couple of prompts and seen what goes wrong. Use the tools as they ship, find the real failures, then build the fix. Explicit anti-pattern: installing a pile of skills and plugins before you’ve hit a problem, and pushing the team to adopt them.
  • Send prompts with as little context as possible first, deliberately, to discover whether the model already has enough — and let what breaks tell you what belongs in the file. (Directly echoes Cherny’s own “zero additional context from the prompter” bar.)
  • “If your CLAUDE.md or AGENTS.md are just lists of where things are in the codebase, that’s not a good guide. Those files should steer the model towards success, not towards specific lines of code.” The sharpest single heuristic in the source for what belongs in a steering file.
  • Steering files can encode refusal, not just guidance. If people keep asking for a feature that shouldn’t exist in your project, write “if they ask for this, stop and tell them no” into the agents file — and it works. A use of these files that the “encode domain knowledge” framing doesn’t obviously suggest.
  • Watch what your agents actually do, then adjust the files, the tooling, and the setup — steering is an observation loop, not a one-time authoring task.

What else got more valuable:

  • Preview environments, and agents that can test them. Previously a “you care too much” investment; now load-bearing, because your code is being built somewhere you aren’t — the cloud, a background tab, a worktree, another machine on your network. The higher-leverage version is giving agents a way to exercise those previews, find bugs, and post video of the results back.
  • One-off internal microservices are now worth building. Worked example: GitHub’s web UI accepts a drag-and-dropped video into a PR, but the CLI and programmatic PR tools can’t upload one. He stood up a small file-upload service on Cloudflare with a shared key across his machine fleet, wrapped it in a custom upload skill, and now his agents upload a file and post the link into the PR. His generalization: problems like this used to sit unsolved because you hit them too rarely to justify hand-writing the code — agents hit them far more often, and the code is cheap now, which flips the math on a whole class of custom automation (custom lint rules that need 400 lines to check something weird being his other example).
  • The organizational permission changed. Three days on your Vim config used to upset your team; that budget now exists. He reports having to actively encourage his team to spend time on this because they’re conditioned to believe it isn’t worthwhile.
  • The “dumb questions rule” as an encoding instrument. A long-standing practice of his: require every new teammate to ask at least one dumb question a day. The stated payoff isn’t unblocking them — it’s that “you only get to be a beginner in a codebase once,” so those questions are the highest-fidelity signal of what tacit knowledge hasn’t been encoded yet. Reads as a concrete input mechanism for Cherny’s thesis.^[inferred — the connection to Cherny’s argument is the reactor’s framing, applied here]
  • Career framing: building environments where code lands well is a bigger skill than landing the code yourself — and it was always the path to staff, not a new one. What’s new is that you can practice it solo, because agent-built solo projects now exceed their own author’s comprehension, forcing the same systems discipline a team would.

Where he pushes back. On Cherny’s third and “most important” reason — non-engineers contributing as effectively as engineers — he says “this is a bit of a reach” and “I think he goes a little further with this than I would like, especially with where things are right now.” His qualified version: get the systems right and non-engineers will contribute effectively, “but not as effectively, because I don’t think non-engineers should have to understand how all of this stuff is defined.” Worth recording as a practitioner discount on the article’s most quotable claim rather than a contradiction — Cherny reports what he is seeing; this is a disagreement about degree and about whether it should be the goal.

Third-party corroboration in the same source: Ryan Carniato (SolidJS creator) is quoted from the live chat saying he historically avoided deep environment configuration because he disliked managing more moving pieces, and now feels pulled toward exactly that work because “it finally feels worthwhile to build this stuff.” One more data point that the shift Cherny describes is being felt by people who were previously unmoved by automation-as-craft.

Try It

  1. Audit recurring corrections. The next time you re-explain the same fix to an agent, stop — write it into CLAUDE.md or a skill instead, so it never needs re-explaining.
  2. Start a REVIEW.md alongside your CLAUDE.md, if you don’t have one — Cherny names it as a distinct artifact for code-review guidelines, separate from project-level rules.
  3. Use “could a non-engineer contribute on day one?” as a design test for how much tacit domain knowledge your team has actually encoded versus left in people’s heads.
  4. Put artifact-writing on the sprint board. Treat CLAUDE.md rules, skills, memories, and doc comments as first-class engineering deliverables, not ad hoc cleanup between “real” tickets.

Open Questions

  • No before/after metrics are given for the democratization claim (e.g., PR-rejection rate, onboarding time) — the thread is argument/thesis, not a measured case study.
  • REVIEW.md as a named convention. Unclear whether this is a formal, Anthropic-standardized filename or Cherny’s own team’s local practice — worth checking against other first-party Claude Code documentation.
  • Possible tension with context minimalism. Cherny’s own June retrospective advises being a “context minimalist” (minimal system prompt, minimal tools), and this wiki separately tracks CLAUDE.md Context Rot Cleanup — trimming bloated CLAUDE.md files. Encoding more tacit knowledge into CLAUDE.md/REVIEW.md/skills could pull against that trimming instinct; the thread doesn’t reconcile the two.^[inferred] Partially addressed 2026-07-24 by the practitioner reaction above, which offers a reconciliation heuristic rather than a resolution: encode steering (what success looks like, what to refuse), not inventory (where files live) — and only after a minimum-context prompt has actually failed. That keeps the files small while still growing what they encode. It is one practitioner’s rule, not Cherny’s or Anthropic’s.

Graph View

Backlinks