Spec-Driven Development For-the-Win: Disposable Code, Living Blueprints, and Building Like a Boss

Part 3 of the series "Beyond Vibe Coding: The Engineering Blueprint for Reliable AI Agents"

🗺️ The Series Roadmap: Beyond Vibe Coding

In 2026, software development is drowning in fragmented buzzwords: Harness Engineering, Loop Engineering, Context Engineering, Spec-Driven Development, Evaluators, and Sandboxes. Are they competing frameworks? Redundant prompt techniques? Or something fundamentally new?

This four-part series unifies these concepts into a single, cohesive architectural blueprint for building software with AI without writing code manually:

• Part 1: From Vibing Chaos to Reliable Agents: The What, Why, and How of Harness Engineering We diagnose the hangover of vibe coding, unpack the paradigm shift of shifting developer interventions left, establish our bedrock formula (Agent = Model + Harness), explore the Lewis Hamilton motorsport analogy, and deconstruct the deterministic components that make up a production developer environment.
• Part 2: Loop Engineering in the Harness: Autonomous, Self-Correcting Systems We fire up the dynamic runtime engine of the harness: deconstructing the core loop components, establishing hybrid evaluation rubrics (deterministic tests + LLM goal fidelity + tool trajectory verification), and applying the Ratchet Principle.
• Part 3: Spec-Driven Development For-the-Win: Disposable Code, Living Blueprints, and Building Like a Boss (This Article) We explore Spec-Driven Development (where code is disposable and specifications are the single source of truth), master Google Antigravity's unified harness and interactive slash commands (/grill-me, /plan, /goal, /boost, /learn), and combine formal specs on disk with autonomous tactical workflows in your session.
• Part 4: Scaling the Harness: Practical Loop Patterns, ADK 2 Graphs, Recursive Harness², and Enterprise Production (Coming Soon) We unpack the anatomy of a loop iteration (LIVING_MEMORY.md, ephemeral subagents, and beating attention dilution), demonstrate practical ways to wire loops into any repo (including Google ADK 2 graphs), explore Google Research's recursive Harness² framework, and scale to enterprise production on Google Cloud.

Fuel for the Engine: Replacing Vibes with Verified Intent

In Part 1, we used the race car analogy for the agentic harness and built the deterministic chassis. In Part 2, we built the powertrain: the autonomous execution loop, hybrid evaluation rubrics, and the Ratchet Principle.

Crucially, in Part 2 we established a foundational architectural discipline: decoupling reusable engineering guardrails from the task specification.

We centralised the "how we build" — coding standards, test-driven development mandates, security constraints, and automated linting rules — into persistent workspace context (GEMINI.md, AGENTS.md) and Agent Skills. That gave our loop its invariant engineering discipline.

So what fuels the loop? What defines "what we build"?

If you pair rigorous engineering guardrails with vague, casual chat prompts and hand-waving, you won't get quality software. You'll get AI slop at 50 tokens a second.

This is where Spec-Driven Development (SDD) enters the frame. As Google Developer Advocate Lee Boonstra brilliantly captured in her whitepaper Spec-Driven Production Grade Development in the Age of Vibe Coding, formalising the task into a structured, testable specification transforms a slop generator into a precision instrument.

It also unlocks a fundamental architectural shift: code is disposable, but specifications are the permanent source of truth.

Because your engineering context, linters, and evaluation rubrics already govern quality, the generated source code is merely an ephemeral byproduct. If business requirements change or an implementation runs down an architectural blind alley, you don't spend days manually untangling spaghetti code. Your standing guardrails stay untouched; you sharpen the task specification, and let your harness regenerate a clean solution from first principles.

In Spec-Driven Development for Agentic Software Engineering: Harnessing Human-Agent Teamwork, researchers demonstrated that unconstrained conversational agents inevitably suffer from compounding specification drift — a phenomenon where tiny misunderstandings compound across successive turns. Without a fixed specification, it is virtually guaranteed that the final output will drift away from your architectural intent.

SDD eliminates this drift by introducing immutable contract checkpoints at every phase, keeping the agent firmly on the rails instead of letting it wander off into the weeds.

For years, the industry swung between two dysfunctional extremes: either spending months drafting bloated, upfront documentation that was obsolete before deployment, or weaponising a poor understanding of "agile" to jump straight into code with zero planning.

SDD finally closes that gap. Iterating on a half-page specification with an AI partner takes five minutes. The harness then builds and verifies the code in the sandbox in ninety seconds. You inspect working software, get instant empirical feedback, update the contract, and loop. It delivers the deep architectural rigour that enterprises require, at the blistering feedback cadence that agile was always supposed to deliver.

In other words, SDD plus an agent takes genuine agile principles to their logical conclusion.

The SDD Lifecycle as a Continuous Loop

In an agentic workflow, clear documentation isn't cumbersome ceremony — it is a superpower. Spec-Driven Development is emphatically not a rigid, 200-page document that gathers dust in an enterprise SharePoint graveyard. It is a continuous, living lifecycle that evolves in near real-time alongside the codebase.

Let's take a look at the SDD lifecycle:

Don't let the formal diagram labels fool you into thinking this is a return to heavyweight waterfall processes. In an agentic workflow, Steps 1, 2, and 3 happen collaboratively in minutes — often in a single conversational exchange — to produce that concise living blueprint:

1. Scope & Edge Discovery (The WHAT): A quick dialogue pinning down user intent, non-goals, and boundary conditions. No 50-page PRD; just conversational clarity on what's in scope and what's out.
2. Interface Contracts & Boundaries (The HOW): Nailing down the API shape, schema constraints, and Operational Boundaries (Always Do, Ask First, Never Do) before authoring implementation code.
3. Acceptance Criteria & Test Scenarios (The PROOF): Declaring how success will be proven — a few lines of Gherkin or a failing test stub — giving the agent an unambiguous finish line.
4. Automated Code Generation: The agent consumes the living specification within the sandboxed harness, generating implementation code constrained strictly by the contracts and boundaries agreed in steps 1 to 3.
5. Testing & Continuous Validation: Automated test runners execute unit, integration, and static analysis suites directly against the test specification. Simple code defects are patched by Part 2's inner execution loop, while discovered requirement gaps loop straight back to refine the living spec.

Concrete Artifact: A Production Spec Blueprint (tasks/plan.md)

What does a real specification look like when fed into an agentic harness?

It should not be an informal prompt. It is a structured, version-controlled markdown artifact living directly in your repository.

Here is a reference blueprint of a production tasks/plan.md specification for a cloud service (in this case, an audit event logger backed by Cloud Spanner):

# Implementation Spec: Cloud Spanner Audit Event Logger

## 1. Architectural Scope & Contracts

- **Component:** `AuditEventLogger` service in `services/audit_logger.py`
- **Persistence:** Cloud Spanner table `audit_events` (Schema: `event_id STRING(36)`, `timestamp TIMESTAMP`, `actor STRING(128)`, `action STRING(64)`, `payload JSON`)
- **Transport:** Async gRPC client via `google-cloud-spanner` Python SDK

## 2. Three-Tier Operational Boundaries

### Always Do

- Enforce strict typing on all method signatures using PEP 585 standard types.
- Ensure all database writes use Spanner Mutation batches (`spanner.insert_or_update`) rather than ad-hoc DML statements.
- Run `uvx ruff check --fix .` and `uvx codespell -s` after any file modification.
- Practice TDD: author failing test in `tests/test_audit_logger.py` before touching service code.

### Ask First (Human Verification Required)

- Adding any new third-party Python dependency to `pyproject.toml`.
- Modifying Spanner DDL or altering table schemas.
- Proposing changes to the shared gRPC authentication interceptor.

### Never Do

- Never hardcode service account keys, project IDs, or credentials; rely strictly on Application Default Credentials (ADC).
- Never execute inline `python -c` snippets in terminal sessions.
- Never catch generic `Exception` without re-raising or logging with structured traceback.

## 3. Phased Vertical Decomposition

- [ ] **Phase 1: Domain Models & Test Scaffolding**
  - Define `AuditEvent` Pydantic / dataclass model in `models/audit.py`.
  - Author unit test mocking Spanner database client in `tests/test_audit_logger.py`.
  - *Verification:* `uv run pytest tests/test_audit_logger.py` runs and fails with `NotImplementedError`.

- [ ] **Phase 2: Service Implementation & Batch Mutations**
  - Implement `log_event()` and `log_batch()` methods in `services/audit_logger.py`.
  - Implement transient backoff retry logic for `Aborted` and `DeadlineExceeded` Spanner errors.
  - *Verification:* `uv run pytest tests/test_audit_logger.py` passes 100%.

- [ ] **Phase 3: Static Analysis & Hygiene**
  - Execute static analysis and spellcheck suite.
  - *Verification:* Zero warnings from `ruff` and `codespell`.

Notice the power of the operational boundaries (Always Do, Ask First, Never Do). This is where harness engineering neutralises the wild unpredictability of vibe coding. The agent knows exactly where it has autonomous authority (writing tests, formatting code) and where it must yield control to the human conductor (modifying schemas, adding dependencies).

What vs How: The Two Layers of a Living Specification

Now, is a single technical plan like our Spanner blueprint the only way to frame a specification? Definitely not.

In production engineering, specifications often operate across two complementary layers:

1. The Functional Specification (spec.md — The "WHAT" & "WHY"): User-centric and technology-agnostic. It defines the business goals, persona expectations, explicit non-goals (what the agent must not build, preventing scope creep), and verifiable acceptance criteria. It deliberately avoids mentioning specific Python classes, database drivers, or file paths.
2. The Technical Implementation Plan (plan.md — The "HOW"): Codebase-aware and execution-focused. It translates the functional spec into concrete file impact maps (which files to create, edit, or delete), data schemas, library dependencies with explicit versions, and ordered task checklists.

Our Spanner example above is a compact technical execution plan — bundling architectural scope, operational boundaries, and phased vertical slices into a single actionable file for the loop.

The Three-Tier Boundaries (Always Do, Ask First, Never Do) represent a key operational pattern within that plan: they govern the agent's blast radius and autonomy envelope. As we'll explore in the next section, these boundaries can live directly inside a task plan, or be codified globally as a non-negotiable project constitution.

Spec Anatomy: Token Physics and Behaviour-Driven Contracts

When crafting a specification, two practical disciplines make the difference between an agent that drifts and one that executes with surgical precision:

1. Token Physics & Formatting Science (The Hybrid Markdown + YAML Rule): Large language models do not interpret abstract data structures; they process tokenised text. In recent agent compilation research (such as the SkCC study highlighted in Lee Boonstra's whitepaper), LLM agents suffered up to a 40% performance drop when fed generic, unoptimised Markdown documents. For Gemini models, the sweet spot is Hybrid Markdown + Conditional YAML. Use clean Markdown headers (#, ##) to anchor broad system context and global narrative instructions. Meanwhile, render structured configuration, data contracts, and entity schemas (especially with nesting depth > 3) in flat, compact YAML rather than verbose JSON or XML. YAML achieves significantly higher parsing accuracy for deep configurations while eliminating the heavy "reasoning format tax" of JSON closing brackets and quotes.
2. Behaviour-Driven Development (BDD) with Gherkin: Vibe prompts describe vague wishes ("make a friendly booking system"). A production-grade spec describes verifiable state transitions. Wrapping acceptance criteria in declarative Gherkin syntax (Given / When / Then) forces the model into a deterministic State → Action → Outcome sequence:

Scenario: Booking a table with active dietary preferences
  Given a customer with dietary preference "gluten-free" recorded in session
  When they request a reservation for 2 guests on Friday at 19:00
  Then verify table availability via the Cloud SQL reservation tool
  And confirm the booking, returning a structured reservation ID

(Side note: even standard Markdown engines natively support gherkin syntax highlighting out of the box — proving just how universally recognised this format already is! Not Medium, of course!)

By providing explicit preconditions, the exact tool to trigger, and the expected outcome, you remove all ambiguity. The agent doesn't need to guess your intent; it simply fulfils the contract.

Practical Tooling for Spec-Driven Development

You don't have to invent your own specification formats or build bespoke SDD tooling from scratch. The agentic engineering community has converged on several robust frameworks, each suited to different developer workflows.

1. The spec-driven-development Skill

• What it is: An open-source Agent Skill (created by Addy Osmani) that enforces specification discipline as an autonomous conversational workflow loaded directly into your agent's context.
• How you use it: Installed in your workspace (.agents/skills/) or global configuration (~/.gemini/config/skills/), you trigger it conversationally at the start of any feature (e.g. "Use spec-driven development to scaffold the audit logger"). The agent enforces a strict 5-stage sequence (Scope Check → Specify → Plan → Tasks → Implement), pausing at each gate to surface its technical assumptions:

ASSUMPTIONS I'M MAKING:
1. Target runtime is Python 3.13 managed via uv.
2. Data persistence uses Cloud Spanner with dialect GoogleSQL.
3. Authentication relies on Google Cloud ADC / IAM principal tokens.
-> Confirm or correct before proceeding.

• What it outputs: A single, consolidated tasks/plan.md file committed to your repository — exactly like our Spanner blueprint above — featuring architectural contracts, Three-Tier Boundaries (Always Do, Ask First, Never Do), and an ordered checklist of test-verifiable tasks.

2. GitHub's spec-kit

• What it is: An open-source CLI toolkit and prompt harness created by GitHub that standardises specification-first software development through dedicated commands, project-level constitutions, and multi-file dossiers.
• How you use it: Executed via CLI or interactive slash commands (/speckit.specify → /speckit.clarify → /speckit.plan → /speckit.tasks → /speckit.implement). You run each step as an explicit command in your terminal or IDE, validating proposed designs against a non-negotiable Project Constitution (.specify/memory/constitution.md). It also includes independent, lightweight workflows for Bug Fixing (assess → fix → test) and Idea Assessment (intake → define → decide).
• What it outputs: A modular, version-controlled dossier under specs/<feature-branch>/ containing separated files: spec.md (the user-facing WHAT), plan.md and data-model.md (the technical HOW), research.md (library versions and decisions), and tasks.md (an atomic execution checklist).

3. Google's Conductor Extension

• What it is: An AI-native extension and visual workspace assistant from Google that guides developers through context gathering, specification authoring, and test generation directly inside their editor.
• How you use it: As announced on the Google Developers Blog, Conductor now natively supports Antigravity. It lives directly inside your editor sidebar: initiating a structured context-gathering flow, clarifying ambiguous requirements, and validating test coverage before unlocking code generation.
• What it outputs: An established set of structured, version-controlled Markdown files — specifically product.md (vision and scope), tech-stack.md (dependencies and architecture), spec.md (contracts and acceptance criteria), and plan.md (task execution). Just like any other SDD framework, these files are committed to the repo and loaded straight into Antigravity's context window as the permanent source of truth.

Google Antigravity: The Unified Developer Harness

Where does all of this come together in practice?

Up to this point, we have talked about harness components conceptually: hierarchical context rules, MCP servers, sandboxed environments, evaluation rubrics, and living specifications. But developers need a concrete runtime to orchestrate all these moving parts into a cohesive workflow.

In the Google ecosystem, that orchestrator is Google Antigravity.

Antigravity is not another chat assistant bolted into the sidebar of an editor. It is an AI-native developer harness engine built from the ground up around the Plan → Do → Verify engineering cycle. Rather than expecting a single model prompt to handle everything in one turn, Antigravity operationalises harness discipline: actively coordinating the engineering environment around the model, managing context, enforcing boundaries, and verifying outcomes.

Inside the Harness: What the Engine Coordinates

Don't mistake Antigravity for a passive chat assistant that merely answers questions and suggests snippets. A true developer harness actively coordinates the engineering environment around the model:

• Automatic Rule & Policy Enforcement (No Copy-Pasting Prompts): Rather than expecting you to copy-paste prompts or manually configure system instructions, Antigravity natively discovers and binds hierarchical rule files (~/.gemini/GEMINI.md, workspace/.agents/rules/, and workspace/GEMINI.md — which is completely interchangeable with workspace/AGENTS.md depending on your team's conventions). It ensures your coding standards, package policies, and architectural requirements are deterministically bound to every model invocation.
• First-Class Agent Skills & MCP Orchestration: Antigravity was built from the ground up for progressive disclosure. It tracks installed skills via lightweight metadata headers, dynamically expanding full instruction sets and schemas only when relevant tasks are triggered. Once declared in your configuration, it natively handles tool registration, schema discovery, and execution against both local and remote MCP servers (such as developer-knowledge and Cloud Logging).
• Isolated Sandboxing with Blast-Radius Control: Commands executed by Antigravity run inside an isolated sandbox by default. The agent has full read/write access to your workspace, but network access and modifications to host-level operating system files require explicit privilege elevation. This gives the agent freedom to compile, test, and refactor code rapidly without placing the developer's workstation at risk.
• Subagent Spawning & Context Isolation: Long-running development tasks often require diverse capabilities. When an agent needs to survey documentation across twenty web pages or perform an in-depth accessibility audit, Antigravity can spawn isolated subagents (like dedicated research or browser agents). The subagent executes its bounded task, returns a synthesised result to the parent orchestrator, and terminates — keeping the primary context window lean and focused.
• Subagent-Driven Development (Task Implementers & Reviewers): Beyond ad-hoc research, structured SDD harnesses split implementation across specialised subagent personas. Rather than cluttering the primary conversation with thousands of lines of intermediate compiler output and syntax churn, Antigravity can dispatch each task to an isolated Task Implementer subagent with a pristine context window. Once implementation completes, an independent Task Reviewer subagent evaluates the code against the specification contract, passing only a clean verification receipt back to the primary orchestrator.

One Core Harness Across Five Developer Surfaces

Now, where does this harness live?

Crucially, Google Antigravity delivers this identical harness engine across four developer surfaces, alongside a programmatic Python SDK:

• The Antigravity App (formerly Antigravity 2.0) — a dedicated desktop application designed for intent-based building, allowing you to direct autonomous agents, review visual artifacts, and orchestrate projects without having to worry about the underlying code.
• The Antigravity IDE — a standalone, AI-first code editor (built on VS Code) for developers who want a complete coding workspace with intelligent tab completions, inline refactoring, and in-editor sidebar assistance.
• The Antigravity Extension — brings the complete harness directly into your existing editor of choice (VS Code, JetBrains, Visual Studio, or Zed) so you don't have to abandon your familiar tools.
• The Antigravity CLI — a full Terminal User Interface (TUI) for developers who live in the command line or remote SSH sessions, and want the interactive harness experience in their terminal.
• The Antigravity SDK — a Python library for programmatic orchestration, headless automation, scripted workflows, and custom multi-agent systems.

Across all these surfaces and tools, the underlying configuration engine, context rules (~/.gemini/ and workspace/.agents/), MCP servers, and sandboxed execution runtimes are completely identical.

This addresses one of the biggest roadblocks in enterprise adoption: the IDE lock-in barrier. As I explored in Meet the Antigravity Extension: Gemini Code Assist on Steroids, in Whatever IDE You Love, tens of millions of developers — and enterprise security policies — will not simply abandon their favourite IDEs overnight. By packaging the entire unified harness into an extension for VS Code, JetBrains, and beyond, Google ensures teams get full harness intelligence without having to abandon their existing toolchains.

Supercharged Harness Workflows (Slash Commands)

Antigravity provides a number of "slash" commands out-of-the-box. Rather than typing out long prompt instructions, you can trigger key harness behaviours directly using these commands:

/grill-me

The antidote to underspecified requirements. Instead of accepting a vague prompt and guessing how to implement it, Antigravity initiates a structured, one-question-at-a-time interview to stress-test your thinking, interrogate boundary conditions, and resolve ambiguities before a single file is modified.

Real-world prompt:

/grill-me on the Spanner schema and backoff retry behaviour in tasks/plan.md

/plan

Switches the agent into dedicated planning mode. Rather than immediately modifying files, Antigravity surveys the codebase, maps out dependencies, and presents a structured implementation plan with verification steps for your review and sign-off before execution begins.

Real-world prompt:

/plan refactor services/audit_logger.py to use async batch mutations with zero breaking changes

/goal

Initiates an autonomous execution loop for long-running tasks. Rather than pausing after every step to ask for input, the agent works through the task list, diagnoses test failures, handles retries, and yields control only when the objective is fully achieved and verified.

Real-world prompt:

/goal implement Phase 2 of tasks/plan.md, fix any failing pytest assertions, and ensure ruff passes

/boost

Transforms a single model session into a coordinated team of subagents executing tasks or adversarial reviews in parallel. In loop engineering, /boost is the easiest way to implement decoupled multi-agent verification — pairing a builder subagent with an independent critic subagent so a single model instance never marks its own homework.

Real-world prompt:

/boost run an adversarial security and race-condition review of our Spanner transaction handler

/learn

The mechanical realisation of the Ratchet Principle! When you guide or correct an agent during an interactive session, running /learn extracts the operational lesson and crystallises it directly into your workspace rules. The lesson is immediately persisted to disk so future sessions never repeat the mistake.

Real-world prompt:

/learn always wrap Spanner Mutation writes in exponential backoff when catching Aborted errors

Slash Commands Alone vs. Formal SDD

At this point, I know what you might be thinking:

"Hold on, Dazbo. If Antigravity already gives me /plan and /goal out of the box, why do I need formal SDD skills like Conductor, spec-kit, or the spec-driven-development skill? Isn't that just extra ceremony?"

Great question. Here's the thing: it comes down to the trade-offs between tactical session planning and long-term architectural governance:

An Enterprise Option: Combining SDD with Tactical Slash Commands

You don't always need both. For everyday feature slices, targeted refactors, or rapid bug fixes, Antigravity's native slash commands (/plan and /goal) provide plenty of structure with zero setup overhead. Conversely, for architectural reviews, a standalone SDD dossier alone might be all your team requires.

However, when you are tackling large, multi-component enterprise initiatives, nesting these layers into a hybrid workflow is a powerful option. You can use formal SDD as the macro-architectural envelope on disk, and Antigravity's native slash commands as the micro-execution engine in the session.

Here is an example four-phase hybrid pattern you can adopt when orchestrating complex features:

1. Phase 1 — Macro Architecture (The Outer Spec via Formal SDD / Conductor / spec-kit): Before generating any implementation code, establish the enduring system blueprint on disk. Define machine-readable API contracts, data schemas, test stubs, and the operational boundary rules (specs/api_contract.md, tasks/plan.md). Because these are committed to version control, they survive across sessions, branches, and team members.
2. Phase 2 — Specification Stress-Testing (/grill-me): Once the initial specification is drafted, invoke /grill-me against the spec file. Antigravity acts as a relentless, sceptical peer reviewer. It interrogates boundary conditions, probes error handling paths, questions concurrency models, and surfaces hidden assumptions before signing off on the architecture.
3. Phase 3 — Autonomous Tactical Execution (/plan + /goal + /boost): With the formal spec locked, feed a single vertical slice from your task plan into /goal (or /boost for separated Builder/Critic verification). Antigravity's autonomous workbench takes over, executing the tactical inner execution loop we built in Part 2: it uses /plan to map out immediate file edits, executes changes inside the sandbox, validates against deterministic linters and semantic rubrics, and loops autonomously until every gate is green.
4. Phase 4 — Hardening the Harness (/learn): When the agent encounters an unexpected runtime quirk or discovers a project-specific constraint during the /goal execution loop (such as a subtle gRPC serialisation rule or sandbox path issue), invoke /learn. Antigravity extracts that operational lesson and crystallises it directly into workspace/.agents/rules/ or your root rule file (GEMINI.md / AGENTS.md). The ratchet clicks; the harness hardens; and the entire team permanently benefits from the discovery.

Sustainable Team Engineering: Defeating Approval Fatigue

Adopting Spec-Driven Development doesn't just change how you interact with an AI model — it fundamentally alters team engineering culture.

When teams first adopt automated coding assistants, they often fall into a trap known as review theatre. Developers find themselves staring at a 1,200-line diff generated in three seconds, trying to manually verify every line of syntax. Developer experience studies consistently highlight that frequent AI tool users suffer significant cognitive burnout when trapped in manual code reviews. Eyeball inspection simply does not scale to agentic velocity.

SDD breaks this cycle by establishing a clean division of responsibility:

• Humans review the intent and the contracts: You evaluate the architectural trade-offs, the boundary constraints, and the acceptance test scenarios.
• The harness verifies the code: Linters, sandboxed test suites, and evaluation rubrics verify the disposable implementation syntax.

By shifting human review from syntax nitpicking to spec and contract design, engineering teams eliminate approval fatigue while maintaining rigorous production quality. If the contracts and test scenarios are sound, and the automated verification suite passes in the sandbox, you can merge with confidence.

Summary & What's Next: Scaling the Harness

We have now brought together our deterministic chassis (Part 1) and our autonomous loop engine (Part 2), fuelled by living specifications committed directly to the workspace (Part 3) and orchestrated through Google Antigravity.

But how do you introduce loop engineering into any existing repository in under five minutes? How do you prevent multi-turn loops from collapsing under context bloat? And what happens when you put a recursive meta-loop around the harness itself?

In Part 4 (The Finale), we take our harness to the next level:

• The Anatomy of an Iteration: How sandboxed environments, ephemeral subagents, and LIVING_MEMORY.md filter out noise and beat attention dilution.
• Practical Ways to Wire Loops into Any Project (And How to Combine Them): From zero-code Markdown rules (GEMINI.md + RUBRIC.md) and loopy (LOOPS.md) to /goal and programmatic Google ADK 2 graphs.
• Google Research's Harness² (Harness-Squared): Recursive agent harnessing (Propose → Probe → Compose) that optimises the editable components of your harness across tasks without retraining a single model weight.
• Enterprise Production Pillars on Google Cloud: Bridging your local developer harness to cloud-scale production.

👉 Continue to Part 4: Scaling the Harness: Practical Loop Patterns, ADK 2 Graphs, Recursive Harness², and Enterprise Production (Coming Soon)

See you in the finale!

Before You Go

• Please share 📢 this with anyone that you think will be interested. It might help them, and it really helps me!
• Please give me loads of claps! 👏 (Just hold down the clap button.)
• Please leave a comment 💬. Interaction is good!
• Add a star ⭐ on my repos!
• Follow 👉 and subscribe 🔔, so you don't miss my content.

References and Useful Links

Spec-Driven Development

• Spec-Driven ADK Agent Development with Antigravity and Spec-kit | Google Codelabs
• Getting started with Spec Driven Development in Antigravity | Google Codelabs
• Spec-Driven Development with Antigravity CLI — Structured Agent Workflows with Skills and MCP | Google Codelabs
• Evolving Spec-Driven Development: Conductor Now Supports Antigravity | Google Developers Blog
• Spec-Driven Production Grade Development in the Age of Vibe Coding by Lee Boonstra (Google)
• Spec-Driven Development for Agentic Software Engineering: Harnessing Human-Agent Teamwork
• github/spec-kit: Toolkit to help you get started with Spec-Driven Development
• spec-driven-development skill by Addy Osmani

Google Antigravity & Ecosystem

• Google Antigravity Documentation
• Introducing Google Antigravity | Google Antigravity Blog
• The AI-Native Developer Experience, Part 2: Harness Engineering with Google Antigravity by Jaroslav Pantsjoha

Dazbo's Related Articles

• From Vibing Chaos to Reliable Agents: The What, Why, and How of Harness Engineering (Part 1) by Dazbo
• Loop Engineering in the Harness: Autonomous, Self-Correcting Systems (Part 2) by Dazbo
• Meet the Antigravity Extension: Gemini Code Assist on Steroids, in Whatever IDE You Love by Dazbo
• Dialling Our Agents to 11: Agent Skills You Need to be Using! by Dazbo
• Dazbo's Portfolio