Theo on Boris Cherny’s Advice for Engineering with AI Agents

Software engineering has changed quickly, and I understand why developers who loved tailoring editors and environments feel left behind. I enjoyed those things too, from Sublime Text to VS Code and the T3 stack. Yet I have found that the same curiosity and care can be rewarding when building workflows for agents.

Boris Cherny, one of Claude Code’s original creators, wrote about why experienced engineers’ automation skills remain valuable. I disagree with some of his broader statements about the future of engineering, but this post speaks to people who enjoy making tools and environments work better for themselves and their teams.

I want to reach both developers who miss what they loved about their work and people trying to help colleagues adapt. For me, these new workflows have made building fun again. The skills I developed before agents—understanding systems, spotting friction and making tools—still matter.

Boris starts with familiar examples: editor automation, lint rules for recurring mistakes and end-to-end tests that replace repetitive manual checks. These investments have long multiplied an engineer’s impact. His argument is that they can become even more valuable when many agents depend on the same environment.

At Twitch, one of my favorite tests used two browser sessions on a channel: one bot sent a chat message and another verified it appeared correctly. It was simple, but it caught failures before many other checks. I love that kind of clever, focused way to make a complex system observable.

Boris’s first point is that developer-experience and infrastructure automation can speed up both people and the agents they run. Preview environments are a good example: work may happen in a cloud environment, a worktree or another machine, and a reliable way to inspect the result can help everyone involved.

I noticed my agents could not conveniently attach videos to pull requests through the tools I was using. I built a small upload service and a skill so they could upload a file and add its link. The important part is the loop: notice a recurring obstacle, build a tool and watch whether it actually helps.

A viewer who creates SolidJS says he is newly interested in this kind of automation because it now feels worthwhile, even though he previously disliked managing extra moving parts. I recognize the appeal: small improvements can be satisfying, especially when their feedback arrives quickly.

Teams may also be more willing to invest time in these experiments when the benefits extend to multiple agents and colleagues. I encourage my team to look for opportunities they might previously have dismissed. The investment still has a cost, so it should solve a real recurring problem.

Boris’s second point is to turn repeated fixes into code. An agent could repair the same issue whenever it appears, consuming time and tokens and sometimes missing cases. A tested lint rule, CI check or routine can catch a defined class of issues repeatedly, although its coverage depends on its design and maintenance.

Some project-specific checks used to be too much effort relative to how often the issue occurred. If agents make implementation and testing easier, a custom rule or action can become worthwhile. My upload service is one example: a problem hit more often by agents finally justified a dedicated solution.

The third benefit is making a codebase easier for others to contribute to. Boris suggests agents can help newcomers navigate and even let non-engineers contribute as effectively as engineers. I think that last claim goes too far today: people can contribute in new ways, but expertise and review still matter.

Domain knowledge often lives in people’s heads. Some of it can be captured in architecture, tests, types and lint rules; some can also be expressed in comments, skills and project instructions. The goal is to make good decisions and feedback available to the next contributor, not to assume documentation captures everything.

I see this as a responsibility of experienced engineers: build structures that help other people and their agents keep the codebase healthy. Guards might be automated checks, architectural choices or plain Markdown instructions. Each has limits, so watch how the work behaves and improve the system when it fails.

One practice I call the dumb-questions rule asks new teammates to ask at least one basic question each day. The question helps them, but it also reveals where the codebase or onboarding is confusing. A person is new to a codebase only once, so that perspective is valuable for preventing future friction.

Good infrastructure can help non-engineers contribute, but I do not expect them to understand every architectural decision. I prefer engineers to take responsibility for important project guidance. In particular, my advice is not to hand over authorship of CLAUDE.md or AGENTS.md entirely to an agent without understanding what is in it.

Observe what agents do, then adjust instructions, tools and the environment to steer them. The purpose is to provide useful feedback when something goes wrong, not to assume an agent will magically infer everything. Project guidance can also explain why certain requested changes do not fit the project.

This feels familiar to me: the T3 stack was exciting because separate pieces combined into an end-to-end development experience. I now get similar satisfaction from combining agent instructions, tools and feedback into a workflow. The implementation is new, but the pleasure of building a coherent system is familiar.

Boris recommends that teams document domain knowledge in project guidance, review instructions, skills and other infrastructure so agents and future contributors can work more effectively. This extends a long-standing engineering practice: automate what can be automated and make important knowledge accessible.

Do not rush to install every skill or plugin before understanding the problem. Start with the configured tools, try a few real tasks and observe what goes wrong. Then add targeted guidance or automation. A useful project file steers decisions toward success; it is not merely a long directory listing.

My more debatable claim is that these skills help people grow into senior roles: making the whole team more effective can have more impact than only increasing your own output. Career paths differ, but learning to build shared systems and feedback loops is valuable whether you practice on a team or a solo project.

For a solo project, agents also expose gaps in my own assumptions because they do not automatically carry everything I know in my head. I have to make the environment understandable and provide feedback. That work helps me learn, and it has made building enjoyable in a new way.

The industry’s changes can be unsettling, and I hope this gives colleagues a way to explore them together. Start with what you enjoy, find a real source of friction and improve it. For me, that has made building more fun than ever.