Loop Engineering and Spec-Driven Development: The Spec Is the Stop Condition

Loop engineering and spec-driven development solve the two halves of the same problem. A loop keeps an AI coding agent working without you prompting it; a spec tells the loop what "done" means. Without a spec a loop never knows when to stop; without a loop a spec waits for you to remember it.

Two ideas that arrived a few months apart

Spec-driven development answered the first wall people hit with coding agents: vague prompts produce plausible code that does the wrong thing. Write the spec first — scope, files, acceptance criteria — and the agent builds the right thing more often.

Loop engineering answered the next wall: even with good specs, you're still the one starting every run. Design a loop that wakes the agent, gives it a job and checks the result, and the work keeps going while you do something else.

They're usually discussed separately. They shouldn't be.

A loop needs a stop condition. A spec is one.

Every serious description of loop engineering — Addy Osmani's essay, Anthropic's "Getting started with loops", the arXiv study — comes back to the same requirement: a loop runs until a condition a machine can check is true. "Improve the onboarding" is not a condition. "The three acceptance criteria in this spec pass" is.

Look at what a good spec contains:

• What changes and why — the job for this run of the loop.
• Which files — the boundary the agent should stay inside.
• Acceptance criteria — the verifier's checklist.
• Out of scope — what the loop must not wander into.

That's a loop's job, boundary, verifier and guardrail, written down before the run starts. Spec-driven development is how you write a loop's stop condition well.

A spec needs a loop, or it goes stale

The common complaint about spec-driven development is that specs freeze: written once, wrong after the first surprise, ignored by week two (living specs vs frozen specs). A loop fixes that from the other side. When the spec is the thing the loop checks against, it has to stay true — and when the work merges, the spec closes, so the board reflects what actually shipped.

Who writes the spec?

Here the two ideas meet a practical question. If every loop needs a spec, someone has to write a lot of specs. There are two sources:

• You, when you know what you want built. Classic spec-driven development.
• Another loop, when the work is something you didn't know about yet — a security hole in yesterday's change, a webhook that can be replayed, a query with no index. A loop that watches the codebase finds the problem and writes the spec; a second loop (your coding agent) builds it.

The second source is the interesting one. It's the difference between an agent that finishes what you ask and a product that improves itself.

How Tekk puts the two together

Tekk runs the finding loops and keeps the specs:

1. Twelve loops watch your codebase — Security, Reliability, Backend, Payments, Performance, Testing, React, Code quality, AI engineering, Observability, Alerts, Product analytics (the list). Each wakes when your code changes, when Sentry fires, or when part of its area has gone unexamined.
2. A finding becomes a proposal with what it noticed and what it would do. You greenlight or decline it.
3. A greenlit proposal becomes a spec on your board — scope, files, acceptance criteria, a build-order checklist. You can also write specs by hand; they land on the same board.
4. Your coding agent builds the spec through the Tekk MCP server — Claude Code, Codex or Cursor.
5. The merge closes it. A PR with Closes TEK-123 completes the spec, but only once its checklist is done (how that works). The checklist is the stop condition.
6. The merge feeds the next run. It's the next change the loops read.

Specs are the unit of work. Loops are what keeps the work coming and closing. Tekk never writes or ships code itself.