Coding Agents: Driving In Gears — Ian Cooper - Staccato Signals

Coding Agents: Driving In Gears<br>July 10, 2026The Value of Understanding Code

In an agentic engineering world, what is the value of the code ? We set the agent a goal, provide the requirements and the behaviors the system should exhibit, and ask it to write code to deliver them. When that is done, do we review the output, correct it, and iterate toward an outcome? Or is the code something ephemeral we regenerate as needed and never really read? Is it an artifact we care about, or a by-product? The answer decides where and how we apply human engineering effort, and how much work we let the agent do before any review: one task, all of them, or something in between.

In this post, we tackle that question:

First, why is the code still worth reading, even when an agent writes it?

Second, why does that make our certainty — not a fixed choice of human-in- or human-out-of-the-loop — the variable that should drive how we work?

Third, what is a practical model for turning that certainty into a decision about how big a step to take before we review?.

Along the way, we will show how we should distinguish between natural language, how we talk about the model, and the language in which the model is written.

Why does this question matter?

If we consider code an important artifact and operate with humans in the loop, your pipeline will be subject to Amdahl's Law, and we will be limited by the speed of the human review steps. In that case, it seems counterproductive to use more than a handful of agents (with sub-agents for context management or model swapping). Generating code faster will quickly lead to work queuing for the human reviewer. Your throughput can be no higher than that of the human reviewer. Accelerating beyond a handful of agents increases complexity, such as managing merge queues or coordinating builds, without being able to move faster than the human capacity limit.

If we decide that code is not an important artifact, you can remove humans from the loop, and the constraint shifts to your ability to generate valuable requirements. Typically, that requirement takes the form of a specification. In that case, you want to move as fast as budget constraints allow. It makes sense to use a swarm or workflow to create a factory that spits out code that meets the requirement. (Specification is a very overloaded term in agentic coding. In this context, we mean a document that describes all the software's requirements. Having worked in the era when specifications were common, we know they are detailed, with numbered, tracked, and cross-referenced requirements and a supporting test pack. Creating that kind of specification is a considerable investment of human/agent time for a complex product. Much specification-driven development doesn’t refer to this; instead, it refers to collaboration between a human and an agent via a design document. More on that in another post.)

It's worth noting that engineering happens in both approaches: observing the code or creating a detailed specification. In economic models of automation, there are always “weak link” tasks that constrain how fast you can go.

This post takes the first path: code is an artifact we care about, and humans stay in the loop to read it. The swarm-and-specification factory of the second path deserves its own treatment, and I'll return to it. But even on this path, the binary is too crude. “Humans in the loop” is not a single setting; it is a dial. The rest of this post is about what sets that dial. The answer, as we'll see, is our certainty about the theory we are building. Hold that word; we'll come back to it once we've established why the code is worth reading at all.

Two paths. Answer the value question one way, and the human reviewer is your ceiling; answer it the other way, and specification quality is your ceiling. This post looks at the top path.

Why is Reading the Code Important

In the post Coding Is Dead, Long Live Programming, we discussed the idea that programming is theory-building. Briefly, since we moved on from assembly or C as a programming language to languages like C++, Java, C#, Go, etc., code is no longer simply an instruction set for registers and memory; instead, it's how we create a model that we can share with a compiler, a model that expresses our theory of how we can automate a solution to a business problem, and a model that the compiler can turn into an instruction set.

Coding is simply the act of recording the model we have designed in code that both we and the compiler can understand. TDD, done right, helps us produce a theory by exploring it through tests of its fitness for the problem space.

We noted that the code is important because a 3GL remains the optimal medium we have today for describing a computable theory to solve a business problem.

We need to read the code for several reasons:

To gain fresh insights by reviewing the theory captured in...