Jonathon's AI Wiki

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

5 min read

Source: raw/x-account-bcherny-2077460395279692197.md 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.

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.

Graph View

Backlinks