Developer experience investments in standard tools, clear validation, structured codebases, and accessible context help both developers and AI agents.
2
AI agents make code review more important because engineers spend much of their time reading generated code and teams produce more pull requests.
3
Poor codebases and weak reviews create a cycle where agent productivity falls, while better development environments can make agent productivity increase over time.
Summary
Max Kanat-Alexander argues that software teams should invest in development practices that remain useful even as AI coding tools change. Standard development environments, familiar tools, native CLIs and APIs, fast deterministic validation, testable code, clear system structure, and written requirements all help agents work more effectively. They also help human engineers. AI coding changes the balance of software work toward reading and reviewing code. Teams therefore need faster feedback during agent iterations, explicit ownership for pull requests, better review workflows, and a sustained quality bar. Kanat-Alexander is direct about the risk of letting agents add low-quality changes to confusing legacy codebases. Over time, that creates more friction and reduces agent productivity. Apprenticeship in code review is also necessary because junior engineers learn this skill by reviewing code with experienced engineers. His final principle is that investments that improve work for humans are safe investments even when the technology changes.
Standard development tools give agents familiar patterns to work from
Kanat-Alexander recommends industry-standard development environments, including common package managers and linters. These tools are more likely to match what models encountered during training. Teams can write instruction files to force agents through unusual local tools, but he says this means fighting the training set. He advises undoing custom, obscure setups where possible. He also says obscure programming languages are harder to use in day-to-day agentic development, although enthusiasts will continue creating new tools. The underlying enterprise advice predates coding agents: teams should not put an untested technology into a service that handles critical production traffic just because it appeared recently.
Agents need native interfaces for actions that matter
An agent needs a CLI or API to take an action directly. Kanat-Alexander acknowledges that computer use can make an agent operate a browser through Playwright, but he questions why a team would choose that when a native CLI is available. Text interaction is the format agents understand most naturally, and native interfaces avoid an extra layer of browser orchestration. He especially recommends this approach where accuracy has a strong effect on the agent's usefulness. The advice applies to internal systems as well as developer tools: anything an agent must operate should have a clear interface that can run at development time.
Deterministic validation must explain what went wrong
Objective, deterministic validation increases an agent's capabilities because it gives the agent a concrete signal for its next step. The source of the validation matters less than its quality and the clarity of its error messages. A bare 500 Internal Error does not tell an agent what failed or what to change. Tests and linters have always benefited from actionable errors, but agents depend on them even more because they iterate from feedback. Kanat-Alexander warns that asking an agent to add tests to an untestable codebase can produce meaningless tests, such as one that only checks whether a button successfully pushed itself.
Code structure and written context determine what an agent can reason about
Agents work better when the codebase has a structure that allows a human or a machine to follow its logic. In old enterprise systems, the information needed to understand behavior may not exist in the code, and the structure may make reasoning impossible. An agent can compensate by repeatedly running the system and observing what breaks, but this is much less capable than reasoning from the code directly. Systems also need tests that expose more than a superficial success. Documentation should capture requirements, design intent, external inputs, and the reasons behind decisions. An agent cannot know about an unrecorded meeting or tribal knowledge. It does not need documentation that merely repeats information already clear in the code.
AI coding turns software engineers into code reviewers
Software engineers have always spent more time reading code than typing it, but Kanat-Alexander says AI coding makes this especially clear because writing code now includes reading generated code. Teams also produce far more pull requests after adopting agents, which makes large-scale review a bottleneck. The goal is not to shorten review until quality suffers. Teams should make each response fast while preserving the time needed to reach a sound result. This applies both to an engineer correcting an agent and to a pull request moving through a team. Human response time is part of the agent's iteration speed.
Review ownership and review quality need explicit systems
A request in a team Slack channel asking any of ten people to review a pull request usually leaves one highly responsive person doing most of the work. That arrangement cannot handle a large increase in pull requests. Kanat-Alexander recommends assigning reviews to specific people, distributing them through a system, and setting service-level objectives with some enforcement. Teams also need to show whose turn it is after comments, replies, and new pushes. Relying on Slack messages to announce that a pull request is ready again is inefficient. The review bar must remain high because accumulated low-quality changes make the system harder for both humans and agents to use.
Apprenticeship is how engineers learn to review code well
The people who are best at code review often spend their time in meetings, high-level reviews, and strategy work instead of teaching others through reviews. That leaves junior engineers without a direct way to become better reviewers and software designers. Kanat-Alexander says that in more than 20 years he has not found a better method than having experienced engineers perform good code reviews with less experienced colleagues. This matters more when agents produce many changes, because teams need more people who can inspect code and decide what should happen next. Review capacity is therefore also a training problem.
Bad codebases and weak reviews create a declining agent cycle
A confusing environment and a poor codebase cause an agent to produce code that is increasingly difficult to trust. A frustrated developer may eventually send the pull request for review with only a guess that it works. If reviewers are overwhelmed or reviews are low quality, they may rubber-stamp it. More bad changes then make the codebase harder to understand, which further reduces the agent's productivity. Kanat-Alexander contrasts this with a positive cycle: when teams improve the environment, validation, structure, context, and review process, agents can help developers become more productive and make further improvements. His checklist ends with the principle that what helps humans also helps AI, even when a particular investment does not improve the agent as expected.
"If somebody else has a better way of doing this than doing code reviews with people, I would love to know because in the 20 plus years that I've been doing this, I have never found a way to teach people to be good code reviewers other than doing good code reviews with them."14:42
Who should watch
Developer experience teams deciding which infrastructure and tooling investments will remain useful as coding agents change.
Engineering leaders dealing with legacy codebases, slow validation, or a growing pull request backlog.
Teams adopting agentic coding that need to preserve review quality and teach engineers how to inspect generated code.
