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 — and the speed of agent-driven development means it accumulates fast.
I've been thinking about this since I wrote about the developer role is changing — the shift from authoring code to directing agents. I love shipping great software, and that part of it — moving faster, holding more in parallel — is something 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. What resonated is that this isn't hypothetical. It's something I've felt in the 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.
Some of it is tool choice. 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.
Some of it is continuous review — not just before merging, but as a constant habit throughout. Agents produce a lot of output quickly, and the gap between generating code and understanding it is real. 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.