From the Present Map to the Next Paradigm
The field has burned through four names for its frontier in four years. Prompt engineering carried 2022 through 2024, context engineering owned 2025, harness engineering arrived early in 2026, and loop engineering was coined this June. Each new name moved the leverage outward, from the words you type toward the cycle that types them for you. The discipline that makes any of it trustworthy has not moved at all. Every harness I run today answers to that discipline before anything else.
What a Harness Is
In Chapter 14 I mapped the Agent Stack, the runtime anatomy of a single coding agent. The model sits at the core, the first of its seven layers. Five more wrap around it, and the seventh binds them all.
"The whole system around the model binds scaffold, tools, memory, loop engine, and gates into one working agent."
That seventh layer is the harness.
The same word now names a market. Foundation models sit at the bottom (Claude, GPT, Gemini). Command-line coding agents run above them as the substrate everything else plugs into (Claude Code, Cursor, Aider, Cline, Codex CLI). Harnesses sit on top. A harness, as I use the word here, is a configuration layer that constrains and orchestrates a coding agent toward a specific development workflow. It ships as some combination of slash commands, sub-agents, skills, hooks that fire scripts at fixed points in a run, Model Context Protocol (MCP) servers that connect outside tools and data, templates, and methodology documents. A harness constrains, structures, and directs an animal that is otherwise willing to wander.
The industry is still arguing over the word's edges. OpenAI's February 2026 harness-engineering post claimed the broad sense, "every piece of code, configuration, and execution logic that isn't the model itself," and Addy Osmani later compressed the same camp into "if you're not the model, you're the harness." The Hugging Face agent glossary takes the narrow view, restricting the word to the execution layer while conceding that products like Claude Code apply it to the whole system. I hold the broad sense, and I call the narrow sense what Chapter 14 called it, the loop engine. However the vocabulary settles, the proportions already have. Researchers at the Mohamed bin Zayed University of Artificial Intelligence tore down Claude Code in April 2026 and measured, by line count, roughly 98.4 percent of the production coding agent as harness infrastructure and roughly 1.6 percent as AI decision logic. Nearly all of the agent is the part you design.
I did not learn this layer from a diagram. I learned it fighting one. I started with GitHub's spec-kit, and every run wanted to do more than I asked, spawning extra subagents, inventing new commands, and loading skills that were never part of the request while I watched the thinking threads scroll past, halting and redirecting whenever the workers wandered. The harness was doing its job. Its design center was productivity without contracts, and expansiveness is what that design center produces. So I put governance agents on the input and the output, and I thought of the result as a methodology. Mapping this landscape corrected me. The governance agents were a different kind of harness, the methodology was never a free-floating idea, and the map that follows is the one I wish I had when I started.
From Prompt to Loop
Those four names from the opening are not marketing. Each names a real discipline, and each wraps the one before it without replacing it. Prompt engineering engineers the words you send. Context engineering engineers the information the model sees. Harness engineering engineers the environment a single coding agent runs in. Loop engineering engineers the cycle that drives the work across time.
The newest name arrived with unusual velocity. Peter Steinberger seeded it on June 7, 2026. "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." Addy Osmani named and codified the discipline days later, defining it as "replacing yourself as the person who prompts the agent. You design the system that does it instead." Boris Cherny of Anthropic's Claude Code team endorsed the workflow in the same window, describing his own job now as writing the loops that prompt Claude rather than prompting it himself. The kickoff post reportedly crossed 6.5 million views within days, and the anti-pattern already has a name. When the failure mode gets named within weeks, the practice has momentum.
The distinction that matters for this map is environment versus cycle. A harness equips a single coding agent run. A loop keeps poking coding agents on a schedule, spawns helpers, verifies results, and feeds itself the next task. Loop engineering does not sit beside the harness layer. It sits on top of it.
"Loop" is now doing four jobs in this chapter. The eval loop is the inner correction cycle that grades and retries an agent's work inside a single stage (Chapter 9). The loop engine is the execution layer of the Agent Stack, the part that calls the model, runs the tools it asks for, and decides when a task is done (Chapter 14). The Loop, capitalized, is the unit of execution in Agentic-Oriented Development (AOD), one governed revolution of the Agentic Development Lifecycle (ADLC) scoped to a single issue. The ADLC is this book's six-stage flow from Discover through Document, and the industry is minting adjacent lifecycle names (Amazon Web Services ships an AI-Driven Development Life Cycle, AI-DLC), so treat the overlap as convergence, not coincidence. And loop engineering is the discipline of designing the cycle that keeps revolutions turning without a human spinning the wheel.
Osmani names six components of a well-built loop, and every one already has a home in this book. Worktrees are context isolation (Chapter 2) applied to the filesystem so parallel coding agents never collide. The other five map the same way, from automations landing on orchestration (Chapter 8) to durable state landing on the Knowledge Loop (Chapter 11). AOD taught the parts. Loop engineering named the assembly.
The loop, though, is the easy half. Loop engineering's own authors concede as much every time they list the risks. Osmani names the verification burden ("a loop running unattended is also a loop making mistakes unattended"), comprehension debt, the growing pile of shipped code nobody on the team understands, and cognitive surrender, the habit of accepting whatever the agent produces without judging it. Comprehension debt is what the Document stage and the Knowledge Loop exist to pay down (Chapter 11). The other two are gate questions wearing new coats. Evals as control flow answer the verification burden (Chapter 9). Checkpoint Gates put governance sign-off between execution and acceptance (Chapter 8). Security Gates enforce policy as executable tests instead of documents (Chapter 10). And the Governance Triad carries veto authority through every stage, which is the standing answer to who says no while the human is away. The gates are the hard half, and gate discipline is what this book has been building since Part II.
On the Agentic Maturity Ladder from Chapter 6, the four-level climb from Vibe Coder to Agentic Engineer, the lineage maps cleanly. Prompt engineering is the Level 2 craft, context engineering is the Level 3 craft, and harness engineering and loop engineering are both parts of how a Level 4 Agentic Engineer works. Loop engineering is not a fifth rung. It is the runtime component of Level 4. The agentic engineer designs the cycle, governs it, and improves it, and that is a bigger job than keeping it spinning.
The Four Categories
By mid-2026 the open-source harness landscape has consolidated into four categories, and the cleanest way to tell them apart is the question each answers. Spec-driven harnesses answer "what are we building?" by keeping the human as the author of intent while coding agents execute. Software development lifecycle (SDLC) enforcement harnesses answer "how do I do this stage well?" by scaffolding each stage with skills while the human stays the orchestrator. Autonomous pipeline harnesses answer "who builds what, in what order?" by casting coding agents into roles across the full lifecycle. Governance harnesses answer harder questions, "who approved this?", "what happened?", and "is this allowed?", and they cut across the other three categories rather than competing with them.
The categories mark design centers, not fences. Spec-Kit's constitution leans toward governance. BMAD writes specs.
Adoption is lopsided, though stars measure attention, not production use. As of July 1, 2026, the date every star count in this chapter carries, Obra Superpowers sits at 243,000 GitHub stars for SDLC enforcement, Spec-Kit at 117,000 and OpenSpec at 58,000 for spec-driven work, and BMAD-METHOD at 50,000 for autonomous pipelines. Governance, the category where AOD-Kit lives, is the smallest of the four by reach. Nearly every harness on this map targets Claude Code as its primary substrate, which says more about where the runtime standardized than about any one vendor.
Touring the Reference Implementations
Spec-Kit (117,000 stars). GitHub's toolkit is the reference implementation for spec-driven development. It layers a constitution above per-feature specs, walks work through eight gated commands from constitution to implementation, and supports the broadest compatibility in the landscape, more than thirty coding agent integrations as of its June 2026 release. Deploy and monitor sit out of scope, and governance stays partial. The constitution leans that way, but nobody signs off.
Obra Superpowers (243,000 stars). Jesse Vincent's skill collection, the phenomenon of the SDLC-enforcement category, leads with test-driven development (TDD), dispatches subagents liberally, leans on git worktrees to keep parallel work isolated, and stays light on the agent's working memory. It scaffolds the stages it covers well and governs none of the pipeline.
BMAD-METHOD (50,000 stars). Nothing stops a persona from drifting except the prose that defined it. The reference implementation for autonomous pipelines casts six named personas (analyst, product manager, architect, developer, user-experience designer, technical writer) and moves work between them through structured document handoffs, with documents as the source of truth. Role multiplication is the cost, and its governance rides on convention rather than contract.
AOD-Kit (20 stars). This one is mine, and it is the only harness in the landscape whose primary spine is role authority and structured sign-off. The Governance Triad holds approval as a hard gate before implementation. The product manager (PM) agent holds the what and the why, the Architect agent holds the how, and the Team Lead agent holds the when and the who, and no worker spawns until they sign off. Twenty-three commands and twelve sub-agents ship the workflow. Reach is what it misses.
OpenSpec (58,000 stars) and Compound Engineering (22,000 stars) earn brief mentions. OpenSpec tracks spec deltas, so every change to intent produces a reviewable changelog. Compound Engineering feeds every fix back into rules, so a codebase gets easier to build in over time.
One harness on this map no longer exists in its original form. GSD, the "get-shit-done" harness, was the velocity story of the autonomous pipeline category. Its flagship repository was archived on June 26, 2026. Its maintainer had been unreachable since roughly the first of April. The community relaunched the work as the open-gsd fork, which has drawn about 5,600 stars since late May. That is the verified spine, and the spine is the lesson. A landscape in which a category leader collapses because one person goes silent is a landscape that has not answered its own trust questions. Who approved this, what happened, and is this allowed?
The open-source scope of this map is a choice, not blindness. Amazon announced Q Developer's retirement in May 2026 in favor of Kiro, which runs spec-driven development through structured requirements gates. Tessl raised a reported $125 million in late 2024 for commercial spec-driven tooling built around a registry it says holds more than 10,000 prebuilt specs. Anthropic opened a Skills Marketplace. The commercial entrants validate the categories. The open-source landscape is where the patterns stay inspectable.
The Three Flavors of Governance
The most useful finding from mapping this territory is that governance is not one thing. Three flavors exist in the wild, and each answers one of those three trust questions.
Process and role governance answers "who approved this?" AOD-Kit implements it by encoding approval authority as agent roles and requiring Triad sign-off before implementation begins. It sits before the work.
Code and provenance governance answers "what happened?" Spec-Kitty (1,400 stars) implements it as an append-only local audit log that records every governed action as it runs. It sits during and after the work. Spec-Kitty is the closest peer to AOD-Kit on this map, and I read it as a complement rather than a rival. A sign-off without a record is a promise, and a record without a sign-off is an alibi. Teams end up wanting both.
Agent and runtime governance answers "is this allowed?" AxonFlow (69 stars on its main repository) enforces policy at the tool-call boundary, and the project claims more than eighty built-in policies checked in milliseconds before a tool is permitted to run. It sits at the moment of execution.
The runtime flavor is industrializing fastest. Microsoft's agent-governance-toolkit, created in March 2026 and near 4,600 stars by July, combines policy enforcement with zero-trust identity, where no agent is trusted by default, and adds a sandbox around execution. The project claims coverage of all ten items in the Open Web Application Security Project (OWASP) Agentic Top 10. When a platform vendor that size enters a category, the category has stopped being a hobby.
The three flavors compose. They do not substitute for one another, and as of this writing no single open-source harness covers all three. A team that wants full coverage today assembles it.
Where AOD-Kit Fits, Honestly
AOD-Kit owns one cell of this map. No other harness in the landscape encodes approval authority as agent roles, and the "who approved this?" question has held up in every build I have run since the spec-kit days.
It does not own the other two cells. Provenance is Spec-Kitty's ground. Runtime enforcement belongs to AxonFlow and, increasingly, to Microsoft.
AOD-Kit has 20 stars. Its peers on this map hold 1,400, 22,000, 50,000, 117,000, and 243,000. That is a gap of two to four orders of magnitude, and no amount of framework elegance erases it.
Role authority is also the hardest flavor to retrofit, which is why I still hold the position. You can bolt an audit log onto almost anything, and you can wrap a policy check around any tool call, but approval authority has to be designed into the workflow from the first command. And the Three Flavors framework matters more than any single dot on it, including mine. The map is the contribution. The dot is the bet.
The White Space
Start with what the map does not show. Delivery and monitoring sit nearly uncovered. Only AOD-Kit treats the ADLC's Deliver stage as first-class work, with a dedicated devops agent, while BMAD and Compound Engineering touch delivery in passing. Monitoring is emptier still, and it sits past the lifecycle's named stages entirely, in the operations work that starts once the code is live. Spec-Kitty and AxonFlow watch the harness itself through audit trails and runtime guardrails, but no harness constrains a coding agent doing observability or incident response on the software it shipped.
The governance flavors do not compose anywhere either. No open-source harness unifies process, provenance, and runtime governance in one system. And the newest discipline has no reference implementation at all. Loop engineering, weeks old as a name, exists as pattern write-ups and small command-line tools.
My prediction is that the next twelve months move into this white space, and the likeliest new arrival is the operations harness, one that constrains coding agents through deploy, observability, and incident response. Codrut Andrei's Product Security in 2026 report supplies the forcing function. Traditional governance cadences, the annual penetration test, the quarterly review, the human-only code review, cannot move at the speed coding agents ship. When that mismatch gets painful enough, the governance white space fills first.
What Coding Agents Become Next
Two capabilities are coming that will stress every category on this map.
The first is long-term autonomy and goal chaining, coding agents that pursue goals across sessions and days rather than within a single context window. Lucas Rodrigues's agentic AI framework named the capability back in 2025, and loops running on schedules are the mechanism carrying it into practice. AOD's building block for it is Project Knowledge (the memory model's second layer), the repo-scoped memory that preserves intent across sessions (Chapter 11). True goal chaining needs persistence beyond specs, though. The goal itself has to survive handoffs the way requirements survive them today.
The second is self-improvement, coding agents that modify their own configuration from accumulated experience. AOD's Systematic Evolution trait (Chapter 6) is the human-driven version, where failures become rules but a human decides which failures deserve to. Fully autonomous self-improvement aims the three trust questions at the agent itself. Who approved the rule the agent just wrote for its own behavior? What did it change? Was the change allowed? Nobody has answered those at the harness layer yet.
The gate argument recurs. Capabilities that extend across time extend the verification burden across time. Longer autonomy means more gates, not fewer, because every unattended hour is an hour someone eventually answers for.
Marketplaces Multiply the Trust Questions
Above individual systems, an ecosystem layer is forming. Rodrigues's framework calls it agent marketplaces and contracts, agents published, discovered, and composed the way microservices were a decade ago.
The early evidence is countable. Anthropic's Skills Marketplace lists roughly 600 skills. The MCP ecosystem passed 20,000 servers by one directory's count (PulseMCP, which indexes broadly, against roughly 9,600 in the official registry), and monthly downloads of the protocol's developer toolkit (its SDK) hit 110 million by the April 2026 MCP Dev Summit's figure. The Agent2Agent (A2A) protocol, the standard for agents talking to agents across vendors, reached v1.0.1 under the Linux Foundation with more than 150 organizations behind it. Agents are becoming things you install from a catalog.
Marketplaces make governance harnesses more critical, not less. Composition at ecosystem scale multiplies every trust question this chapter has asked. Who approved this agent for this system? What did it actually do once installed? Is it allowed to touch what it is touching? One unreachable maintainer took down a category leader this June. And abandonment is the gentler failure, because package registries taught everyone that someone eventually publishes a lookalike agent built to be installed by mistake, a malicious turn that belongs in the security companion to this book. Scale that trust surface to a supply chain of composed agents, and the three governance flavors stop being a category on a map and start being procurement criteria.
The Next Paradigm
The shift after AOD will not be conceptual. It will be operational. AOD answers a collaboration question, how humans and coding agents build software together. The next paradigm answers a scale question, how agent-built systems get governed when no human can watch every loop.
The convergence is already visible inside the loop-engineering literature. Osmani positions a "Factory Model" above loop engineering, the system that builds the software rather than the person who runs the tools. AOD arrived at the same layer from the governance side. Chapter 16's Agent Factory creates agents under a governance contract, deciding what gets spawned, with what configuration, on whose approval. The Factory Model that survives contact with production is the governed one, where creation itself passes through a gate. Raw autonomy is the other bet, and some closed-loop commercial platforms are already making it, removing the human reviewer entirely and trusting simulation to catch what review used to. The distance between those two endpoints is where the next decade of this discipline gets decided.
The governance questions that outgrow the development harness, agent identity, runtime enforcement, audit at scale, are security questions. That territory is where my writing goes next, in the security companion book to this one, and it is where tachi, my open-source agentic threat modeling tool, puts these principles to work. Buyers are moving the same direction. Andrei's report documents procurement teams demanding security evidence before the sale instead of questionnaires after it. A harness that produces evidence as a byproduct of the workflow is built for that world. A harness that produces velocity alone is built for the demo.
Positioning Yourself for What Comes
Three audiences need three different moves.
For practitioners, match the harness to the itch rather than the star count. If specs as the source of truth is the itch, Spec-Kit or OpenSpec scratches it. Builders who want composable skills for their own workflow should start with Superpowers or Compound Engineering. A team that wants a role-cast running its pipeline gets that from BMAD. Spec-Kitty adds the record of what happened. AxonFlow or Microsoft's toolkit stands guard at the tool-call boundary. And when the question that will not go away is who approved this, AOD-Kit was built to answer it.
For teams, pick the governance flavor by the question that hurts most. If nobody can say who approved a change, start with process and role governance. If nobody can say what happened while the coding agents ran, start with provenance. If nobody can say whether an action was allowed, start with runtime enforcement. Most teams eventually need at least two, and none of the three composes the others for free.
For builders, the white space is the invitation. Deploy and monitor sit uncovered. No harness unifies the three governance flavors. Loop engineering still lacks its reference implementation. And because the categories stack (Triad governance can sit on top of a spec workflow, and runtime hooks can wrap either), the next great harness may be a composition rather than an invention.
The Map and the Position
AOD is a position, not a destination. It lives in the governance category, carries the process-and-role flavor, and supplies the gate discipline the loop era has not yet built for itself. Star counts will shift and categories will merge. Maps go stale. Positions compound.
The field will name a fifth frontier, and the names will keep moving outward, from the words to the window to the environment to the cycle, with whatever comes next wrapping all of it again. The discipline stays where it has always been, at the gates, the points where someone answers for the work. Anyone can spin up a loop now. The gates are still the work.
What's Next
This is Part 21 of a series on Agentic-Oriented Development.
Coming next: The Paradigm Is Shifting
Chapter 22 closes the series with the synthesis, walking the book's spine once from end to end, from the four pillars to the gate discipline that carries them into the loop era.
About the Author: David Matousek is Solution Compliance Lead for the BEST Program at the Commonwealth of Massachusetts, sharing practical insights on agentic development and enterprise risk. He leads compliance, risk, and security architecture for the Business Enterprise System Transformation program, and maintains AOD-Kit, an open-source toolkit for agentic-oriented development, and tachi, an open-source agentic threat modeling tool that puts AOD principles into practice. He is the author of Agentic-Oriented Development, available to read in full at agentic-oriented-development.com. Connect with him on LinkedIn to compare notes, share your experiences, or visit davidmatousek.com to explore how these principles apply to your organization.