A few weeks ago I was reviewing a pull request an agent had written. It wasn't broken. Nothing was wrong, exactly. But something was off: a naming convention that didn't match the rest of the file, a structure that technically worked but sat slightly sideways from how everything else in that part of the codebase was shaped.
It doesn't break anything. It just adds up. One convention breaks down in a corner, another file implements something slightly differently, a naming decision gets made that's inconsistent with everything around it. None of it is catastrophic. But it accumulates. Agent-driven development makes it accumulate faster than you'd expect.
I've been thinking about this since writing about the developer role changing, that shift from authoring code to directing agents. I love shipping great software. The moving-faster part, holding multiple things in parallel, I've come to genuinely enjoy. But when you let agents drive, things drift.
The Zed team wrote about this recently, framing it as a tension between "vibes" and craftsmanship, shipping fast versus building something worth maintaining. That landed. It's something I've felt in actual code reviews where the codebase starts to fragment. The moments where an agent implements something that technically works but doesn't fit the bigger picture I'm holding in my head.
What I'm still working out is how to hold both.
Tool choice is part of it. Claude Code and Zed's agent panel are both part of my workflow, but they feel different. In Claude Code I'm more abstracted: focused on the task, reviewing output. In Zed I'm closer to the code. I move between them deliberately depending on what the work requires. The choice of tool shapes my relationship to what gets produced.
Continuous review is most of it, not just before merging but as a constant habit throughout. Agents produce a lot of output quickly, and there's always a gap between generating code and actually understanding what was produced. Regular review is how I catch drift before it becomes the default.
But the biggest shift has been in how I think about documentation. Not for other developers. For the agent. Architecture notes, naming conventions, decisions about structure. When the agent has a clear picture of what the codebase is trying to be, its output is more consistent. Docs aren't an afterthought. They're the shared language between me and the tools I'm working with.
None of this is settled. But I keep coming back to that word: language. I'm not just directing agents. I'm writing the model they work from. The code is downstream of that.