Rituals in the Build Loop 4
Flow CheckB5 · B6 · B8 · B9
RefinementB1 · B2 · B3 · B4
Spec ClinicB1 · B3 · B4 · B6 · B9
Acceptance SlotB8 · B9 · B10
DEEP DIVE · ALL LOOP STEPS
Explore steps, evidence, and feedback.
Select a step in the map. Responsibilities, agent support, evidence, and rituals are available in context.
Three loops. One shared impact.Select a step
Rituals in the Value Loop 3
Roles in the Value Loop
Rituals in the Learning Loop 2
RetrospectiveL1 · L2 · L3 · L5
Learning ExchangeL5 · L6
Roles in the Learning Loop
Value → BuildPlan measurement (V2) to make the spec (B3) more precise.
Build → ValueRelease (B10) enables data collection (V3).
Learning → bothEmbed learning (L6) changes AI skills, AI context and test cases.
All three loops are active in parallel. Steps run clockwise; new findings may reopen earlier steps.
Build Loop1 / 10 steps
Does the change meet the agreed need?
One small change · Minutes to days
B1
Select a problem
Work can come from the board, executive team, company strategy, higher-level initiatives, or the team itself. The Product Owner and team clarify the task and set priorities within their agreed mandate. For bug fixes, a reproduction, expected behavior, and test case are often enough for a work card. Before starting, they align with the accountable decision-makers on goals, fixed constraints, decision rights, and the investment boundary: human effort, AI costs, expected value, and review points. Scope can be negotiated within the explicitly approved space. Conflicts about goals or budget go to the appropriate decision-maker.
Accountability & AI support
Humans are accountable for
AI supports
Evidence & handoff
Bounded task with the next piece of evidence.
Clarify first when uncertainty is high.
Related rituals 2
Prevent Feedback Debt: agree in the spec who will evaluate impact after release and when. Make it visible in practice →
01 / PRINCIPLES
The seven principles
Impact sets the direction.
Start with an improvement for people. An idea is not valuable simply because it is technically possible or generates a lot of code. The Product Owner, team, and Feature Partner clarify which problem should change and for whom. This creates a verifiable impact hypothesis.
Clarify the intended impact first. Then choose the next suitable change.
How this principle helps day to day
Before implementation, record what is observed today, what should improve, and which evidence supports the next decision. The measurement plan from the Value Loop feeds into the spec and tests from the start.
Example · shopping cart
‘Customers should be able to correct quantities more easily’ describes the need. ‘More users with a filled cart reach checkout without extra price errors’ is the impact hypothesis. Use suitable data and user feedback to check it.
A correctly delivered feature may provide little value. The Value Loop supports the decision to keep, improve, investigate further, or roll back.
A spec creates clarity.
The spec is the shared agreement on intended behavior. It describes rules, examples, failure cases, and acceptance criteria. People and agents use the same confirmed version; tests and code reference it.
Agree on intended behavior before the agent implements it.
How this principle helps day to day
Plain language and concrete examples are enough to start. Assign critical open questions to an owner and resolve them before affected implementation. The team adds interfaces and technical boundaries; the Measurement Partner adds required measurement points.
Example · shopping cart
‘Quantities should be editable’ leaves many questions open. Be specific: ‘Given a line item with quantity 1, when its quantity is set to 0, then remove the line item and recalculate the remaining cart.’
For a small bug, a reproduction, expected behavior, and regression test may be enough. Clarity needs relevant information, not the longest possible text.
Small steps. Fast feedback.
Check early instead of letting large changes grow unchecked. A small step shows whether the need was understood and the implementation works. Concrete feedback shapes the next work.
Deliver the next verifiable change. Use the result to choose the next step.
How this principle helps day to day
During planning, define the next evidence point: a test case, review, business feedback, or observation after release. Technical feedback often arrives within minutes; reliable impact measurement may take longer. The loops therefore run in parallel.
Example · shopping cart
Implement the quantity change first and test normal quantities, 0, and stock limits. Then trial usability with a Feature Partner. A finding can lead directly to a small correction.
Small specs create small changes. Small changes can be checked faster, shortening feedback and learning loops.
AI needs a clear task, feedback, and boundaries.
An agent receives a specific, bounded task. Include the valid spec, relevant context, expected evidence, and permitted tools. Test and review feedback supports focused correction.
Define the task, verification criteria, and boundaries. Clarify missing foundations first.
How this principle helps day to day
Before the run, record what the agent may read or change, which tests it must run, and when it must stop and hand back to people. Keep budget, attempt limits, and a human owner visible. More reasoning does not expand decision rights.
Example · shopping cart
Workmaster implements only the confirmed quantity rule. It may change relevant files and run tests. It asks for clarification when criteria conflict and does not weaken requirements or protected tests independently.
Implementation and independent review use separate AI contexts. Plausible text does not replace test evidence.
Humans remain accountable.
Humans decide. Agents support. Agents prepare options, implement work, and provide findings. Named people remain accountable for priorities, business rules, technical approvals, and product decisions.
For every decision, clarify who decides, under which mandate, and using which evidence.
How this principle helps day to day
The Product Owner prioritizes within the agreed mandate. The team is accountable for the technical approach and quality. Feature Partners confirm business behavior; the Measurement Partner checks what the data supports. The Loop Guide supports collaboration and learning.
Example · shopping cart
An agent suggests deferring discount codes. The Product Owner and team decide the split. A Reviewer provides findings on price calculation; the named human owner decides approval.
Roles may be combined, but decision rights, delegates, and handoffs must remain clear. Conflicts outside the mandate go to the appropriate decision-maker.
Learning changes how work gets done.
Learning becomes useful when it improves the next work. The team gathers evidenced experience from Build and Value, identifies a relevant pattern, and trials a bounded change. Proven learning becomes specs, tests, AI skills, or working agreements.
Understand one pattern. Trial one change. Evaluate its impact.
How this principle helps day to day
Separate observations and assumptions. Set value, owner, budget, and review date for an experiment. At most one deliberate process experiment per team keeps impact traceable. Adapt or discard what does not help.
Example · shopping cart
Shipping thresholds repeatedly cause rework. The team adds boundary cases to the spec template and checks whether errors and review effort decrease on later tasks. If useful, adopt the rule and share it with other teams.
Context selection and spec slicing can also be experiments. Evaluate output quality, rework, and review time, alongside AI costs. Do not evaluate individuals.
Small Specs, Small Context
Small Specs reduce context. Large tasks often require extensive background knowledge, files and dependencies. LoopsWork therefore shapes work into small specs that can be implemented and reviewed independently. The agent receives the information needed for that particular step.
Shape the task so the agent needs less context.
- Large taskUnderstand the need and overall goal
- Small SpecsSplit meaningfully
- Less contextRelevant rules and files
- Better resultsPrecise Small Changes
Less unnecessary context supports more precise agent work. Small Changes are quicker to review, shortening feedback and learning loops. Reduced token and model usage may also lower costs; splitting and coordination involve effort too.
Small Spec → Small Context → Small Change → Fast Feedback
Small, yet meaningfully independent
A spec should be as small as possible while remaining meaningfully implementable and testable on its own. Tasks that are too small create administrative and coordination effort. Necessary domain rules, interfaces, dependencies and test cases remain part of the context.
B3 → B4 · brief quality check
Slice: Is the spec small enough?
Check whether the spec can be implemented with manageable context and then reviewed independently.
- Can the spec be understood with clearly bounded context?
- Can it be implemented without explaining large parts of the system?
- Can the outcome then be reviewed independently?
If any answer is “No”, split the spec further. PO and team confirm the split before planning implementation.
An entire checkout
“Build a new checkout including vouchers, payment methods and error handling.”
Bounded work steps
- Create the basic checkout structure
- Select a payment method
- Apply a voucher
- Handle an invalid voucher
- Display a payment error
Each spec receives its own acceptance criteria. Link shared interfaces and dependencies; also check related changes in integration.
Subtasks serve more than project organisation here. Above all, they reduce the context an agent needs to understand for each step.
Existing tools such as subtasks can split large requirements into smaller specs. What matters is a small, relevant context per step, rather than the Jira structure.
In AI-assisted software development, also known as software development with AI or AI Coding, the principle combines clear requirements with AI support. It complements Specification Driven Development: the agreed spec guides implementation and review; meaningful scope shaping keeps both manageable.
Vibe Coding explores ideas through prompts and experimentation. In LoopsWork, Loop-Coding connects small agreed specs, verification, impact evaluation, and learning. Explore Vibe Coding and Loop-Coding.
View the slice in the Build Loop · How AI agents help with scope shaping
02 / TIMING
What happens when?
A piece of work does not pass through three separate queues. Choose a point in time to see what happens in parallel.
Build
Value
Learning
The connectionIn refinement, connect the problem, investment boundary, and measurement plan. V2 provides B3 with measurement requirements. Resolve open rules in the Spec Clinic.
Illustrative timeline. Timing depends on risk and data volume; there is no mandatory three-week cycle.
03 / FEEDBACK CONNECTIONS
This is where the loops connect.
Make impact buildable.
The measurement plan defines events and guardrail metrics. They are included in the spec, tests, and implementation from the start.
Deliver. Observe. Decide.
The release starts the observation period. The product decision in V6 can trigger a new small change in B1.
Turn experience into a working agreement.
A recurring failure becomes an experiment. What works becomes a test, spec example, or agent rule.