If You Want an Agent Transition, Spend Time on Initial Setup
Boris Cherny's note on automation matches what I have been telling teams for weeks: the leverage is encoding judgment into infrastructure, not burning tokens on the same bug forever.
For the last two weeks I have been on stages and in meetings with large-company executives saying the same thing too many times: initial setup is where agent work is won or lost. Token maxing taught me that the expensive part is not the clever prompt. It is whether the environment already knows how you work.
I kept wondering if that was only my bias. Then a note from Claude Code lead Boris Cherny lined up with it almost exactly.
What strong engineers already did
Boris points at an old habit. The best engineers spent real time on vim automation, lint rules, e2e tests, and other ways of automating the work around the work. They multiplied their own output before agents existed.
That habit is higher leverage now for three reasons he names, plus a few that matter in practice.
Automation multiplies by agent count
Used to be, better DevX made one person faster. Now the same automation can speed up every agent you run. One shared rule is not a personal convenience. It is fleet throughput.
Moving a problem into code can retire a whole class of pain
Agents can re-fix the same issue every time they see it. That burns tokens and still misses cases. If you instead have Claude write a lint rule or a CI step, that class of failure stops showing up. The “loop” people talk about is not retrying forever. It is deleting a category of problem.
Automation is how other people contribute
We already see engineers shipping on day one, and non-engineers contributing at a level that used to require a full eng seat. The remaining wall is domain knowledge that only lives in someone’s head. That used to be “onboarding.” It has to become writing: docs, rules, examples, review standards.
What can become infrastructure has expanded
Lint, types, and tests used to be the main portable knowledge. Now comments, skills, CLAUDE.md rules, and agent memory can hold almost any judgment you can state clearly. If a reviewer rejects a PR with “we don’t use that framework” and never encodes the rule, the team failed the infrastructure step. The knowledge stayed tribal.
The actual homework for every team
Write CLAUDE.md, REVIEW.md, skills, and docs until an agent can do productive work without a human pasting extra context every turn. That is the same automation work seniors always did, pointed at agents.
I read Boris’s framing as a redefinition of senior work in the agent era. The scarce skill is not typing code faster. It is moving the judgment in your head into the repo or the shared drive as soon as you notice it. Team strength will show up in what the repository already knows, not only in who is online.
Initial setup feels slow. Skipping it is how teams buy expensive models and still spend the day re-explaining the same standards to a blank context window.
Join the newsletter
Get insights on the latest AI.