I see a recurring pattern in how experienced engineers react to AI-generated code: measured skepticism about its production readiness. That skepticism is legitimate when pointed at naive, prompt-and-ship workflows — but it often misses where the real engineering challenge sits.
The quality of AI-generated code is largely a function of the environment it runs in. Projects where agentic coding works well share a common trait: significant engineering investment went into defining the harness before the model was ever invoked. The code that comes out is not impressive because the model is impressive — it is because the spec is precise, the constraints are enforced, and the feedback loop is automated. That investment is non-trivial, and it is where I believe engineering teams have the most valuable contribution to make today.
There is also a subtler point worth making explicit: in this paradigm, code should be treated as a derived state — an artifact produced from a specification, not the specification itself. If the spec changes, the code is regenerated. If the code conflicts with the spec, the code is wrong, not the spec. This inverts the traditional relationship where the codebase is the source of truth and documentation trails behind it. It also has practical implications for how we handle merge conflicts: when two agents produce conflicting implementations, the resolution happens at the spec level, not the code level. Code conflicts are a symptom of spec ambiguity.
Three interlocking concepts structure how I think about this: Spec-Driven Development, Harness Engineering, and Loop Engineering. Each addresses a different layer of the problem, and none is sufficient without the other two.
Spec-Driven Development
The first discipline shift is moving the center of gravity from the prompt to the specification. In Spec-Driven Development (SDD), the spec is not scaffolding you discard once coding begins — it is the artifact from which implementation is derived, validated, and iterated.
This matters because AI agents are extremely sensitive to the quality of their inputs. An underspecified prompt produces underspecified code. A well-structured specification — covering intent, constraints, acceptance criteria, and architecture principles — gives the agent the context it needs to make consistent, coherent decisions across a non-trivial task.
Practically, this means establishing a constitution (governing principles and standards) before you write a single line of production code: naming conventions, testing expectations, API standards, security boundaries. These constraints are not bureaucratic overhead — they are the mechanism by which you steer the model.
GitHub's Spec Kit is a practical open-source toolkit that operationalises this workflow. It provides a structured pipeline of slash commands (/speckit.constitution, /speckit.specify, /speckit.plan, /speckit.tasks, /speckit.implement) that guide both the developer and the agent through progressive refinement — from high-level intent down to executable tasks — rather than asking for everything in a single prompt.
Harness Engineering
Spec-Driven Development solves the input problem. Harness Engineering solves the environment problem.
A harness is the totality of context, constraints, and feedback signals that surround the model at runtime. It has two sides:
-
Guides (feedforward): structured inputs that shape what the model produces —
AGENTS.mdorCLAUDE.md, spec and task files, architecture documentation, coding conventions. These are the instructions the model reads before acting. - Sensors (feedback): automated signals that evaluate what the model produced — linters, type checkers, test suites (unit and E2E), and review agents. These close the loop by surfacing errors the model must correct.
The harness also includes bootstrapping and memory mechanisms — an init.sh that primes the agent's environment, a progress.md (or equivalent session memory file) that maintains continuity across sessions, and git discipline that makes agent-authored commits reviewable and reversible.
The insight is that the model itself is not the product. The harness is. A well-engineered harness makes the model's output more predictable across different agents, different sessions, and different team members.
Loop Engineering
If harnesses add structure, Loop Engineering adds motion. It is the discipline of designing agentic workflows as closed feedback loops rather than linear pipelines.
In a loop, the agent does not just execute — it generates, observes, corrects, and re-generates. The sensors in the harness (tests failing, types mismatching, a review agent raising a concern) become signals that drive the next iteration. The model is no longer a one-shot code generator; it is a participant in a continuous refinement cycle.
This is a fundamental shift in how we think about software construction with AI:
| Vibe Coding | Loop Engineering |
|---|---|
| One prompt → one output | Iterative cycles with feedback |
| Developer reviews output manually | Automated sensors surface issues |
| Context is lost between sessions | Memory and init files preserve state |
| Quality depends on prompt luck | Quality emerges from loop convergence |
The transition to Loop Engineering also changes what engineers need to be good at. The skill is no longer writing the most impressive single prompt. It is designing the harness, calibrating the sensors, and structuring the spec so the loop converges reliably.
Putting All Together
Spec-Driven Development ensures the model always has a well-structured, intentful input. Harness Engineering provides the environment that surrounds the model — guides to steer it, sensors to correct it, memory to sustain it. Loop Engineering is the operating mode that ties everything together: the model runs inside the harness, receives feedback from the sensors, and iterates until convergence.
None of the three is sufficient alone. Without a spec, the harness has nothing meaningful to validate against. Without a harness, even a perfect spec produces unreliable results. Without a loop, both the spec and the harness are one-shot artifacts rather than living parts of an engineering system.
Practical Implications
For teams moving toward agentic development, these concepts translate into concrete engineering decisions:
-
Treat
AGENTS.md/CLAUDE.mdas a first-class engineering artifact. It is the primary feedforward guide. Version it, review it, evolve it. - Adopt a spec-first workflow. Use GitHub Spec Kit or equivalent to enforce constitution → spec → plan → tasks before implementation begins.
- Invest in automated sensors. The ROI of a test suite multiplies in an agentic context — tests are not just quality gates for humans, they are correction signals for the model.
-
Design for session continuity. An agent that loses context between sessions is inefficient.
progress.md, memory files, and structured init scripts are not optional niceties — they are part of the harness. - Measure loop convergence, not prompt quality. The right metric is: how many iterations does it take for the model to produce output that passes all sensors? Optimise for that, not for the impressiveness of individual outputs.
The future of software engineering is not about having the best prompt. It is about building the best harness.
The Open Question: Token Economics
There is one dimension of this I do not have a satisfying answer to yet: cost.
Loop Engineering, by design, is token-intensive. Every feedback cycle — a failed test triggering a correction, a review agent raising a concern, a type error being resolved — consumes tokens. Multiply that by the number of sensors, the number of iterations per task, and the number of tasks in a non-trivial project, and the expenditure grows fast. Add the risk of a loop that never converges — a genuinely hard engineering problem the model cannot solve within its constraints — and you have a potential runaway cost with no deterministic ceiling.
How should businesses reason about this? Right now, I think the honest answer is: we are still figuring it out. The economics today look like: token cost is a proxy for engineering time saved, but the exchange rate is opaque and volatile. Some loops are efficient. Others — particularly those dealing with ambiguous specs or poorly calibrated sensors — are not. The harness quality directly determines how expensive the loop gets, which is another argument for investing in it upfront.
There is also a model trajectory argument. The reasonable expectation is that future models — whether transformer-based or built on architectures we have not standardised on yet — will require fewer tokens to achieve the same outcome. Inference efficiency is an active research and engineering frontier. The same task that takes 50k tokens today may take 5k in two years. That would fundamentally change the economics and make loops that are currently prohibitive much more viable.
But I would not bet an engineering strategy on that timeline — and the external signals are not encouraging. On July 14, 2026, New York became the first US state to impose a one-year moratorium on new hyperscale datacenters, citing rising utility bills, water usage, and grid risk. [^1] Seattle had already enacted a similar ban in June. More than a dozen other states are considering the same. Token spend is not an abstraction: it maps directly to power draw, cooling, and water consumption in physical infrastructure that communities are now actively pushing back on. The efficiency trajectory I described assumes that capacity continues to grow. That assumption is no longer guaranteed.
For now, the practical posture is: design loops that terminate, build harnesses that reduce iteration count, and treat token spend as a signal about spec and harness quality — not just a cost to absorb.
[^1]: "New York becomes first state to impose one-year pause on new AI datacenters", The Guardian, July 14 2026. https://www.theguardian.com/us-news/2026/jul/14/new-york-moratorium-ai-datacenters
Top comments (0)