AWS Builder Center

Builder Center

Harness Engineering with Kiro: Spec-Driven Development for the Multi-Agent Era

Harness Engineering with Kiro: Spec-Driven Development for the Multi-Agent Era

Spec-driven development is the Control layer of harness engineering, not a competing paradigm. See how Amazon Kiro's three-phase spec workflow plus a 9-agent topology rearchitected a full prototype stack in a single day, with >80% test coverage, green CI, and CDK-deployed infrastructure.

Dimas Jackson

Harness Engineering with Kiro: Spec-Driven Development for the Multi-Agent Era


As AI coding agents move from novelty to production workhorses, two terms have dominated engineering discourse in 2026: Harness Engineering and Spec-Driven Development (SDD). While they are often discussed as separate paradigms, practitioners building production-grade agentic systems quickly discover that spec-driven development is not a competing approach—it is a specialized discipline within harness engineering.
In this post, I'll explain how these concepts relate, show how Amazon Kiro implements spec-driven development as a practical harness, and share my experience using Kiro CLI's multi-agent orchestration to rearchitect an entire personal internal prototype stack—from prompt to deploy—in a single day, with production-grade quality gates including >80% unit test coverage, CI pipeline validation, and IaC reconstruction via AWS CDK.

The Rise of Harness Engineering

The term "harness engineering" was coined by Mitchell Hashimoto—creator of Vagrant, Terraform, and the Ghostty terminal—in his February 2026 blog post "My AI Adoption Journey." After months of disciplined experimentation with AI coding agents, Hashimoto arrived at a definition born from practice:
"Harness engineering is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again."
Hashimoto described two concrete forms this takes: (1) better implicit prompting via AGENTS.md files—where each line is based on a bad agent behavior that it almost completely resolved, and (2) actual programmed tools—scripts to take screenshots, run filtered tests, and other verification mechanisms paired with AGENTS.md entries to make the agent aware of them. In his words, this is not a one-time setup but a continuous engineering practice: "I'm making an earnest effort whenever I see an agent do a Bad Thing to prevent it from ever doing that bad thing again. Or, conversely, I'm making an earnest effort for agents to be able to verify they're doing a Good Thing."
The foundational equation became: Agent = Model + Harness. The model provides intelligence; the harness is the system—code, configuration, execution logic—that makes that intelligence useful. Everything that is not the model itself belongs to the harness.
OpenAI validated the concept at production scale in their blog post "Harness Engineering," describing how an entire product was built by agents operating within carefully engineered harnesses—demonstrating that harness engineering is not just a solo-developer practice but a methodology for shipping software through coordinated agent teams at enterprise scale.
A position paper from NTU Singapore (He et al., April 2026) formalized the layers with the CAR decomposition:
  • Control (C): Durable artifacts—AGENTS.md files, repository maps, architecture rules, tests
  • Agency (A): Mediated action surfaces—tools, APIs, code execution, delegation structures
  • Runtime (R): State management, checkpoints, retries, budgets, traces, and failure recovery

Spec-Driven Development: The Control Layer Made Practical

Spec-driven development emerged in 2025 as a direct response to the failure mode of "vibe coding"—agents that produce plausible code but drift from intent, hallucinate APIs, and decay as projects scale. Even Andrej Karpathy, who coined the term "vibe coding" in February 2025, acknowledged a year later that we are entering the age of agentic engineering—orchestrating agents against detailed specifications with human oversight.
The key insight is this: spec-driven development is not an alternative to harness engineering—it is the Control layer instantiated as executable specifications. Specs are feedforward control artifacts within the harness. They anticipate the agent's behavior and steer it proactively, reducing the probability of drift before any code is written.
But a complete harness requires more than specs. It needs sensors (test suites, linters), orchestration (multi-agent topologies, delegation), runtime governance (budgets, checkpoints), and infrastructure (Git, sandboxed execution). Specs are essential—but insufficient alone.
This is where Kiro comes in.

Kiro's Spec-Driven Workflow

Amazon Kiro implements spec-driven development through a structured three-phase workflow. As Marc Brooker wrote: "for the first time, there are tools developers can use to translate common-sense descriptions of desired program behavior into real, working systems."
The workflow operates as follows:
1. Requirements ( requirements.md ) — The developer enters a natural language prompt. Kiro expands it into user stories, each with acceptance criteria written in EARS (Easy Approach to Requirements Syntax) notation. The structured format explicitly captures preconditions, triggers, and expected system responses, covering edge cases that developers would otherwise discover during implementation.
2. Design ( design.md ) — Based on the EARS requirements and the existing codebase, Kiro generates a technical design document including architecture decisions, sequence diagrams, and technology stack choices.
3. Tasks ( tasks.md ) — The design is decomposed into discrete, sequenced implementation tasks with dependency tracking. Each task is atomic, testable, and has clear completion criteria.
The spec stays alive: when requirements change, you edit the spec and regenerate code. The spec becomes the source of truth for both the human and the AI. In harness engineering terms, these three documents constitute the Control layer—durable artifacts that constrain and guide every downstream agent action.

Multi-Agent Architecture with Kiro CLI

Specs tell agents what to build. But for complex projects—full-stack refactors, multi-service architectures, enterprise-grade delivery—you need to coordinate who builds what, with which permissions, and how they verify each other's work.
This is where Kiro CLI's multi-agent orchestration transforms spec-driven development from a single-agent workflow into a production delivery system.
Using the  /spawn  command, I built a 9-agent system where each agent has a defined lane, scoped permissions, tools, and specific outputs. The orchestrator (powered by Claude Opus 4.7) plans work and delegates tasks; the sub-agents (each powered by Claude Opus 4.7) execute within their lanes:
Agent
Lane
Writes code?
Key Outputs
pm-planner
Planning
No
PRDs, roadmaps
pm-scrum-master
Delivery coordination
No
Sprints, status
software-architect
Design
No
HLDs, ADRs, NFRs
software-engineer
Code
Yes
Features, fixes, unit tests
qa-tester
Verification
No
Bug reports, acceptance matrix
security-specialist
Builder-side security
Yes
Threat models, secure-coding fixes
security-auditor
Assurance-side security
No
Framework findings, evidence
devops-engineer
Build + deploy path
Yes
CI/CD, IaC, containers, K8s
observability-engineer
Telemetry + SLO platform
Yes (config/IaC/dashboards only)
Instrumentation, SLOs, alerts, dashboards
Several design decisions are worth highlighting:
Separation of concerns through permission governance. Most agents (5 of 9) have no write access to production. The security-auditor operates in strict read-only mode—a clear separation between builder-side security (which writes code) and assurance-side security (which only audits). The devops-engineer has prod write access but is gated by plan-before-apply governance.
Delegation via  /spawn . Any agent can delegate tasks to any other agent. The pm-planner doesn't write code—it spawns tasks to the software-architect, who designs and delegates implementation to the software-engineer, whose output is verified by the qa-tester. This mirrors how high-performing human teams operate, but at machine speed.
Model allocation strategy. Claude Opus 4.7 runs the orchestrator because it excels at multi-step planning, coherent long-horizon sessions, and coordination across agents. Also, it runs on all sub-agents because it provides excellent execution within well-scoped task boundaries. This stronger model for planning and for execution—is a harness design decision.

Case Study: Full Stack Refactor in One Day

With the multi-agent architecture in place, I rearchitected a personal prototype stack end-to-end in a single day. Here's how the workflow unfolded:

Step 1: Prompt

I described the refactoring goal in natural language to the orchestrator agent and ask him to spawn task for subagents as needed. The prompt captured the high-level intent: what needed to change, why, and what the target architecture should look like.

Step 2: Spec Generation

Kiro expanded the prompt into the full spec-driven workflow:
  •  requirements.md  with EARS-notation acceptance criteria for every user story
  •  design.md  with architecture decisions and component interactions
  •  tasks.md  with sequenced, atomic implementation tasks
The orchestrator (Opus 4.7) reviewed the specs for coherence and completeness before proceeding.

Step 3: Multi-Agent Execution

The orchestrator delegated tasks across the agents via  /spawn . Work proceeded in parallel where dependencies allowed:
  • The software-architect produced HLDs and ADRs
  • The software-engineer implemented features and wrote unit tests
  • The devops-engineer reconstructed the IaC via AWS CDK
  • The qa-tester validated outputs against the acceptance matrix
  • The security-specialist produced threat models and applied secure-coding fixes
  • The security-auditor reviewed findings in read-only mode

Step 4: Quality Gates

Every stage passed through automated verification:
  • >80% unit test coverage — achieved by the software-engineer agent, validated by qa-tester
  • Linting passes — all code met style and quality standards
  • CI pipeline green — the full pipeline ran and passed
  • IaC validated — AWS CDK synthesized and deployed successfully, managed by the devops-engineer with plan-before-apply governance

Step 5: Human Review via Kiro IDE

With all quality gates passing, I reviewed the final commit in Kiro IDE. The IDE provided full visibility into what each agent had produced, the specs that guided them, and the test results that validated their work. I interacted with the agent to make final adjustments and implement the application.

Step 6: Deploy

The application was deployed using CDK, the commit passed tests, lint and security validation pipeline. One day—from prompt to production-ready (personal prototype).

Lessons Learned: Harness Engineering in Practice

What worked

Specs as the coordination contract. The requirements.md, design.md, and tasks.md documents served as the shared source of truth across all 9 agents. When the software-engineer needed to understand intent, it read the spec—not a chat transcript. This eliminated drift.
Scoped permissions prevented chaos. With 9 agents operating concurrently, permission governance was essential. The qa-tester couldn't accidentally overwrite production code. The security-auditor couldn't modify what it was auditing. The devops-engineer's plan-before-apply gate prevented infrastructure surprises.
Split security lanes caught issues early. The security-specialist (builder-side) wrote fixes during implementation, while the security-auditor (assurance-side) independently verified in read-only mode. This mirrors enterprise security practices—but automated and fast.
Human review at the end, not micro-management in the middle. I didn't intervene during agent execution. I set the specs, defined the harness, and reviewed the output. This is the correct human role in agentic development.

What required iteration

AGENTS.md tuning. Following Hashimoto's principle, every time an agent made a mistake, I updated the harness to prevent recurrence. The AGENTS.md files grew throughout the project—each line representing a resolved failure mode.
Task decomposition granularity. Too coarse (large tasks) caused drift—agents would lose context and hallucinate. Too fine (micro-tasks) created overhead and fragmented work. The sweet spot was tasks that could complete in 10-20 minutes of agent time.

Practical Implications for Builders

Start with specs, scale with harnesses. If you're adopting AI coding agents today, start with Kiro's spec-driven workflow. It delivers immediate value: structured specifications that prevent drift and ensure code matches intent. As your ambitions grow—multi-agent systems, full-stack delivery, production deployments—invest in the full harness: permission models, delegation structures, quality gates.
Design multi-agent systems with separation of concerns. Don't give every agent full access. Define lanes, scope permissions, and enforce governance. The plan-before-apply pattern for infrastructure changes is non-negotiable in production.
Invest in quality gates that agents can execute. Agents can achieve >80% test coverage when guided by well-written specs. But the harness must include automated verification: read logs, take screenshots, test runners, linters, CI pipelines. These are the sensors in your harness—the feedback mechanisms that catch errors before humans see them.
Treat the harness as a living engineering practice. Your AGENTS.md, permission models, and task decomposition strategies will evolve with every project. This is not a one-time setup. It is, as Hashimoto said, an ongoing engineering practice.
Measure the harness, not just the model. When you achieve a 1-day refactor, ask: was it the model or the harness? In my experience, holding the model fixed and changing the harness (better specs, tighter permissions, smarter delegation) yields the largest improvements. The model provides intelligence. The harness makes it useful.

Conclusion

Spec-driven development and harness engineering are not competitors—they are nested. SDD is the Control layer of harness engineering, made practical and accessible by tools like Amazon Kiro. When combined with multi-agent orchestration via Kiro CLI's  /spawn  command, the result is a delivery agentic team that can refactor entire stacks in hours, not weeks.
The human role shifts fundamentally: from writing code line-by-line, to defining specs that capture intent, designing harnesses that enforce quality, and reviewing output that meets production standards. The agents do the implementation. The engineer does the engineering.
If you're building with AI agents today, start here:
  1. Try Kiro's spec-driven workflow on your next feature—let it expand your prompt into requirements, design, and tasks
  1. Experiment with  /spawn  for multi-agent delegation on complex refactors
  1. Invest in your harness: AGENTS.md, permission models, quality gates, and the discipline to improve them every time an agent makes a mistake
The era of agentic engineering has arrived. The question is no longer whether agents can write code—it's whether your harness can make them write the right code.

References:
  • He, C. et al. "Harness Engineering for Language Agents: The Harness Layer as Control, Agency, and Runtime." NTU Singapore, Preprints, April 23, 2026.
  • Trivedy, V. "The Anatomy of an Agent Harness." LangChain, March 10, 2026.
  • Rajasekaran, P. "Harness design for long-running application development." Anthropic Engineering Blog, March 24, 2026.
  • Böckeler, B. "Harness engineering for coding agent users." martinfowler.com, April 2, 2026.
# kiro# ai-agents# agents# ai# agentic-ai
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article