Software has been hit by the tidal wave of coding agents. Models are still doubling in capacity every seven months. A week feels like three months, a month like a year.
The sheer intensity of what’s going on is forcing me to think deeply about what should my priorities be as an engineering manager. I’ve come up with three:
- Help the team adapt to the tidal wave: blindly going with best practices was never a good idea. But to do that in times of high change and uncertainty is plain driving the car off a cliff. At the same time, pretending like it’s 2023 is foolish; some of this revolution is useful and will stick. We need to cherry pick innovations. Help the team figure out, out of the torrent of new innovation, what works for us and what doesn’t. Sift through the noise to find good engineering. Use old principles to find a sense of direction.
- Actively prevent AI burnout: drop the 10x speed requirement now taken for granted. Understand that we’re still the same humans with the same human brains. If comprehension is a hard requirement, accept that it takes time and push back on endless acceleration. Ask the team to slow down, to understand their code, to avoid working too much. To recognize how working with agents is addictive. This is a dangerous time to be running around like a headless chicken – we need to take more care of others and ourselves than in normal times.
- Avoid our codebase becoming into legacy code: legacy code is code that no one understands. If we move too fast and delegate too much to AI, we’re creating legacy code. This could well be the death knell of a software startup.
I feel three camps are forming: the skeptics, which see little value in AI. The believers, which are going in the direction of dark factories, with the Claude Code team as the masthead. And a middle ground that refuses to give up review and comprehension but is willing and able to cherry pick the technology. I think the dividing lines are: 1) AI is useful / AI is not useful; 2) all code must be reviewed and understood / don’t look at the code, just at the spec and the end product. The three priorities above are really stemming from that choice of the middle ground.