What I Lose When AI Writes the Code
On understanding, authorship, and the shift from building software to reviewing it.
I recently realized that I don’t enjoy using AI coding agents to implement substantial changes at work. They can shorten the path from an idea to working code. I am trying to understand why that productivity often makes the work less satisfying for me.
My current explanation is that coding is part of how I think. The design continues to change as I implement it. A type that looked natural on paper becomes awkward at its call sites. An error path forces a decision about which layer owns recovery. A performance assumption sends me to a profile or generated assembly.
I start with an idea and form a model. Implementation exposes constraints, so I revise the model. Observing the result starts another iteration. Writing code produces evidence about what the code should be. That process can make even a small diff enjoyable.
An AI coding agent compresses that process. I give it an approximate description, repository context, and constraints; it returns an implementation for me to test and review. I enter after most of the construction decisions have been made.
Even a sound implementation leaves me reconstructing its boundaries, data flow, and failure behavior. I can recover that understanding by reviewing the code, but reconstructing decisions after the fact differs from discovering why they were needed.
I first thought the problem was another layer of abstraction. That explanation falls short. I already rely on operating systems, compilers, databases, runtimes, containers, and network protocols. I don’t need to implement a database to reason about transactions, indexes, replication, or isolation. I can write Go while reasoning about escape analysis and inspect assembly when the boundary matters.
Those abstractions expose models that support prediction. They hide details but provide concepts for reasoning about behavior and places to inspect the result. The models are incomplete and the abstractions sometimes leak; conventional software isn’t perfectly transparent either. I can still connect an operation to a documented mechanism, observable state, or source code when behavior surprises me.
AI coding agents move the boundary to implementation itself. Their output is ordinary code and remains available for inspection. My own process also includes intuition and mistakes, but I am present for them. With an agent, I delegate the implementation and receive the result of many small decisions I never had to make. Understanding those decisions becomes a separate task.
That delegation also changes my role. Without an agent, I design and write an implementation, then the computer executes it. With an agent, I describe an outcome, the agent writes the implementation, and I review it. Review is serious engineering work, requiring judgment about correctness, security, operability, performance, and compatibility once the code exists rather than as I write it.
Many engineers may prefer that division, especially when it removes routine implementation or makes a change practical. Productivity and enjoyment are separate dimensions. A workflow can deliver more software while giving me less contact with the reasoning that makes the software legible to me. I like building software more than causing software to be built.
I have noticed that I enjoy AI much more when it helps me investigate a system than when it implements the change for me. I can ask it to explain assembly, look for possible races, generate adversarial cases for an invariant, compare execution plans, trace an unexpected allocation, or help investigate a failure. These uses shorten the search while leaving me responsible for what I build and how the evidence changes the design. When an agent implements a feature instead, I receive code whose decisions I need to reconstruct during review.
The boundary is fuzzy. Generating a test can influence an implementation; explaining a failure can contain the essential fix. I will probably judge each use by whether it improves my model of the system or hands me an artifact whose model I must recover. My discomfort may be specific to using AI as a surrogate programmer. Agentic development and automated verification still interest me. I am also interested in building reliable systems around probabilistic output; I don’t necessarily enjoy putting that system between me and the implementation.
The same preference probably explains why I keep gravitating toward systems and performance work. Progress there often requires understanding what the runtime, compiler, network, or storage system is actually doing. AI can assist in these areas too. For now, I suspect I enjoy AI most when it helps me inspect that mechanism and leaves me to build with what I learn.