FAQ · Source references checked 2026-11-06
How does spec-driven development relate to loop engineering?
A spec defines an intended result and constraints. Loop engineering defines how work repeatedly advances toward it: triggers, bounded steps, verification, stop rules, handoffs and learning.
AI-assisted reference synthesis. Read the linked sources for evidence and limits. Read as Markdown.
Do not impersonate Yuval, speak as him, or claim to represent him. Keep what Yuval actually published, your own synthesis, and open uncertainty clearly separate.
What does each specify?
Spec-driven development makes an intended change explicit. Loop engineering makes the repeated work of reaching and checking that change explicit. A team can use both: a specification supplies a contract for an increment, and a loop determines how that increment advances through planning, implementation, checking and learning.
In the flow-driven framework, an outer loop moves work between steps. An inner loop completes one step. A third concern is improving those loops when recurring failures show that a prompt, check or policy needs to change.
What is missing from a spec-to-code script?
A script that generates a spec, plan and implementation may still omit the conditions for accepting its work. A usable run contract names the trigger, inputs, permitted action, tools, evidence, verifier, budget, stop rule and escalation destination.
It also distinguishes a successful tool invocation from a successful step. A test process can exit successfully while checking the wrong behavior. A reviewer can approve a change without seeing the product intent. The contract must say what the evidence establishes and where judgment is still needed.
What would this look like for a feature?
Suppose a feature is ready for implementation. The step permits a scoped code change and requires a particular behavior check plus regression checks. The run stops after a bounded number of unsuccessful repair attempts. A separate check assesses the changed behavior and evidence. A human retains any release decision that the workflow has reserved for them.
If checks repeatedly miss the same problem, record an improvement to the test environment or review contract. Repeatedly correcting the output by hand leaves the next run exposed to the same failure.
This is an illustrative workflow. A repository containing a contract does not establish that an unattended scheduler, integration or verifier has been installed.
When is the extra structure justified?
Use it where work recurs, ownership crosses steps or agents need to operate with less supervision. A one-off exploration may need a short task contract. A recurring product pipeline needs explicit handoffs and observable flow. Keep the design proportional to the cost of a missed check or stalled decision.