In agentic workflows, the bottlenecks are definition and review

The bottleneck in agentic coding has moved away from typing code. Given a well-understood and reasonably scoped task, agents can produce plausible multi-file changes in minutes. In my own work, smaller models handle more of the implementation than I expected.

“Well-understood” is doing a lot of work in that sentence.

Before generation, someone still has to decide what the change should do, what it shouldn’t touch, and what would count as success. An agent presented with ambiguity will pick an interpretation and start building. The result can be internally coherent, pass its tests, and still solve the wrong problem.

This was always part of software engineering. Cheap code generation has exposed it as a separate constraint. Leonardo Stern, an engineer at Agoda, makes a similar argument: coding was never the main bottleneck, and the constraint is moving towards specification and verification.

I’m experimenting with OpenSpec to make the definition side more explicit. I keep the proposal, requirements, design decisions, and acceptance criteria separate from implementation. I’ve only just started using it, so I don’t know whether the extra structure consistently pays for itself. My working hypothesis is that ambiguity is cheaper to find in a specification than in a generated diff.

The other side of the workflow is verification. LLMs do not enforce instructions deterministically. A rule in a prompt can influence the output, but compliance remains probabilistic. The model may misunderstand the rule or trade it off against another instruction while still producing something convincing.

Another model can help find problems, especially when reviewing with fresh context. I still see that as a reviewer rather than an enforcement mechanism.

I’m trying to move every enforceable invariant out of the prompt. If a rule can be expressed through linting, type checking, tests, or static analysis, I want a deterministic check for it. A prompt saying “don’t violate this rule” is guidance. A check that fails when the rule is violated is enforcement.

Those checks should run independently of the agent as mandatory gates. Otherwise the agent can forget to run them or make a change without producing the expected evidence. For the same code and configuration, I want the same verdict regardless of what the model thinks it has done.

A deterministic verdict can still be wrong. Tests and static rules are only as good as the requirements they encode, and a green pipeline can enforce a mistaken assumption with perfect consistency. It can confirm that the tested behavior works; it cannot confirm that we asked for the right behavior.

That remaining step requires human validation. I want the reviewer to see evidence tied to the acceptance criteria rather than having to reconstruct everything from the diff. That might include screenshots for visual states, short recordings of interactions, or focused test output for behavior that can be exercised automatically.

The evidence also deserves scrutiny. It is selected by the same agent that produced the change, so it may confirm the agent’s interpretation while omitting the thing it misunderstood. A reviewer still has to ask what is missing and reproduce important paths when the risk justifies it.

OpenSpec may prove too heavy for small changes. Specifications can drift from implementation, and more automated checks can create false confidence when they cover the wrong things. I’m starting to judge the workflow by the cost of establishing confidence in a change. I’m still finding out whether this approach reduces that cost or moves it into a new set of artifacts.