I spend a lot of my day launching coding agents and making guarantees about their output. They follow a standard SDLC pipeline: plan, design, code, test. I can only guarantee that which I can test deterministically, and I noticed something: the further a task is through the pipeline, the more guarantees I can make about the corresponding artifact.
Planning documents are pretty abstract. Mine have a required structure, and I can definitely test for that. But the real measure of quality is in the prose. This is natural language, and there is no equivalent of lint. LLM reviewers can and do assess it, but they're stochastic, so no promises, just good feelings. Or humans, also non-deterministic.
But once I get to the code, I have some real constraints. Does it compile? If so, that means I know that it is syntactically valid. Passes lint? Then it meets the rules my project has learned through hard lessons. Static analysis flags problematic patterns. There is a rich set of well-exercised tools that make deterministic assessments.
The tests go even further: I get a binary pass/fail that represents an assertion about the expected behavior. That doesn't necessarily mean that I have the right tests, just that it passes the test. (I've built plenty of pipelines that ship code that passes the wrong tests.) But once the tests are dialed in, the verification is largely automatic.
Each of these artifacts is a verification surface, something the stage exposes that I can check against. As I move down the pipeline, I can pin down more of that surface deterministically. This creates a ladder of constraint. Language becomes a structured plan, the plan becomes code, and the code becomes behavior exercised by tests. As the artifacts become more constrained, the deterministic ceiling rises.
That realization shapes how I think about agentic pipelines, whether for code or any other process. The pipeline starts with an expression of intent, typically in natural language written or spoken by a human. Formal guarantees are difficult if not impossible. But, as it progresses through the steps, it gradually migrates to something more restricted where deterministic tests are routine.
The model didn't become smarter through that progression. It was the artifacts that changed in a way that raised the deterministic ceiling.
That's why I really started focusing on the pipeline: it is something I design. A designed pipeline, for code or any process, is elegant when it intentionally chooses intermediate artifacts that allow us to raise the ceiling and thus make hard guarantees about the final product.
Choosing your intermediate representations is choosing how much of the work you can verify. That is a design decision, not an accident. And that is how you build pipelines that produce output you can trust.
The framework behind this: Trust Topology →