Coding with Agents; Managers and Builders
in programming, aiLike many software engineers I’ve been experimenting with coding agents as part of my day job.1 My approach is still in its infancy: a handful of tabs and sessions organized by tmux, terminal split in half while coaching Claude through planning and implementation, mostly focusing on just one task at a time. I haven’t seen the productivity boost lauded by tech executives, but I remain impressed by the kinds of things Claude Code gets right.
The more I work with agents, the more my job becomes centered around reviewing code. And reviewing code is difficult! Properly reviewing a diff requires acclimating within the headspace of the proposed change and understanding its tradeoffs. Since I don’t participate in the act of building, I lack the context and theory behind the change. So when I review the code, simply reading the diff isn’t sufficient.
The situation is a little different with AI agents because I drive the upfront planning and problem description. In theory, I have the context of the change, and even if I lack the process of typing it I have a general idea of how it came to be. But in practice, coding with AI still feels a lot more like reviewing a pull request than it does building a feature.
All this to say, my day-to-day workflow is catered
more towards reviewing code than writing code.
tmux is absolutely essential
because it allows me to manipulate my terminal to prompt agents,
investigate implementation details, or run one-off tasks.
delta is the newest addition to
my kit, improving the look of git diff since I now scrutinize every
line of code in my working tree before wrapping it together into a
commit. ripgrep and other CLI
interfaces are essential for crossing the gap between agent and manual
work.
As I work more with AI tools, my feelings towards programming have grown more complicated. The shift from mostly writing code to mostly writing product specifications is not one I’m particularly happy about. For many, coding is nothing but an obstacle in the way of a successful product. For me, coding is artistic expression. Building programs and structuring code in a maintainable way is fun! Hell, editing text is fun.2 Spending less time writing code and more time writing specs or reviewing changesets has been a difficult transition.
I’ve seen others mention this shift as a schism between builders and managers. Folks who prefer composing instructions that delegate to agents, AI or human, are managers. Folks who prefer typing text into an editor and watching programs come alive are builders. Managers love the workflows AI tools enable. Builders lament them. I won’t go so far as to say I lament them, but more and more I find myself avoiding AI tools on my personal projects.
I’m also worried that AI causes skill to atrophy. Anthropic recently released a paper studying the impact of AI on skill formation3 in junior developers and the results do not look good. What this means for the industry in coming years is an unnerving thought.
Footnotes
-
For the record, I staunchly refuse to use AI for any of the writing on this blog. Or really, any of my creative endeavors. I see AI merely as a productivity tool, not a substitute for creativity. ↩
-
It helps when you practice fancy keybindings, adding an extra layer of problem solving to the process of refining text in an editor. ↩
-
Anthropic’s research into these kinds of topics is exactly why I’m happy to support their AI tools. ↩