Vibe Coding
An idea is described in everyday language, implemented with AI, and refined through experimentation. This can help with exploration and early prototypes. Reliable software also needs explicit rules, tests, and human review.
Framework · a two-minute introduction
Three loops. One continuous cycle.
LoopsWork connects three questions:
- What should be built?
- Does it create the intended impact?
- What do we learn from it?
Learning becomes the next build. The loops may be active in parallel.
Understanding AI development: Vibe Coding & Loop-Coding
AI-assisted software development includes different ways of working. What matters is how requirements, verification, and feedback connect.
Loop-Coding
LoopsWork uses this term for development across all three loops: a small, versioned spec guides implementation. Tests and people verify the result; after release, impact and insights feed back into the work.
An idea can start with Vibe Coding and then become a small, testable spec. Specification Driven Development establishes the agreement; Loop-Coding carries it beyond delivery into impact evaluation and learning.
01 / BUILD
Build Loop
Describe, implement, and accept a small, testable change.
- Purpose
- Small Spec
- Build
- Review
- Acceptance
Prevent Feedback Debt: agree in the spec who will evaluate impact after release and when. Make it visible in practice →
Show all Build Loop steps B1–B10
The ten existing steps with responsibilities, AI support, evidence, and handoffs:
B1Select 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.
- Human responsibility
- PO + Delivery Team
- AI support
- Scout
- Evidence
- Bounded task with the next piece of evidence.
- Handoff
- Clarify first when uncertainty is high.
B2Understand the need
Collect real examples from users and Feature Partners. Try a small prototype if needed.
- Human responsibility
- PO + Feature Partner + Team
- AI support
- Scout
- Evidence
- Confirmed problem and concrete examples.
- Handoff
- Alongside V1: What improvement do we expect?
B3Agree on the spec
Record behavior, examples, failure cases, and acceptance criteria. Include the measurement requirements from V2. For critical components, also agree on observability, useful alert triggers, and failure behavior; the optional Reliability & Observability section can help. Finish with a quick slice check: is the spec small enough for a bounded context and an independent review? If needed, split it into coherent, independently verifiable specs. The Product Owner and team confirm the split. Version the agreed source spec clearly so people and AI work from the same agreement.
- Human responsibility
- PO + Feature Partner + Team
- AI support
- Scout
- Evidence
- A jointly confirmed spec with an ID, version, owner and a fixed reference to the valid version.
- Handoff
- Clarify critical unresolved rules before implementation. For contradictions or budget pressure, use the Spec Clinic: preserve the useful core, postpone convenience features, and update the spec and tests together.
B4Plan implementation
Review the repository, dependencies, and risks. Select suitable, versioned AI skills and assemble only the relevant context: the current spec, relevant files, examples, and errors. Give each split spec its own task and context while keeping shared interfaces and dependencies visible. Define small changes, test commands, budget, and agent boundaries.
- Human responsibility
- Delivery Team
- AI support
- Planner
- Evidence
- Reviewed plan and clear AI agent brief.
- Handoff
- Humans make new architecture decisions.
B5Red · Write tests
Turn confirmed criteria into test cases. The test should fail because the behavior is missing. For critical components, also test the agreed failure, fallback, and recovery behavior.
- Human responsibility
- Delivery Team
- AI support
- Reviewer
- Evidence
- A meaningful failing test.
- Handoff
- Return to B3 for a contradiction; fix infrastructure failures first.
B6Green · Implement
Build the smallest suitable implementation. Use specific test failures as feedback. Include the agreed logs, metrics, monitoring configuration, alerts, and failure behavior.
- Human responsibility
- Delivery Team
- AI support
- Workmaster
- Evidence
- Relevant tests pass.
- Handoff
- Do not weaken agreed criteria on your own. Under budget pressure, agree on scope shaping in the Spec Clinic. Stop at the attempt limit; do not silently extend the budget.
B7Refactor · Simplify
Improve structure and maintainability while preserving the agreed behavior. Run the tests again.
- Human responsibility
- Delivery Team
- AI support
- Workmaster
- Evidence
- Understandable code with tests still passing.
- Handoff
- Return to B6 for a regression, to B3 for a new requirement.
B8Review independently
Independently review a small, cohesive change with its spec reference, tests and evidence. Assess integration, security, architecture and, where operations are affected, observability, alert response and recovery according to risk.
PR review & merge approval
A pull request (PR) presents a proposed code change for review before it is integrated into the shared codebase (merged).
A named human reviewer in the Delivery Team reviews the change according to its risk and decides on merge approval. Passing tests are important evidence, but do not replace technical judgement.
Workflow, review scope & boundaries
Small Specs need Small PRs too.
Keep changes cohesive and easy to review. Rigid line limits do not achieve this; split large, mixed changes into meaningful pieces.
- Present a small change with a current spec reference, explicit boundaries and evidence.
- Automated checks and a separate agent review prepare the human review. Results and open findings remain visible on the PR.
- The named human reviewer in the Delivery Team assesses the change and remaining risks. They document merge approval for the reviewed version or request corrections.
- Resolve blocking findings and review again. Resubmit relevant changes made after approval; the earlier approval does not automatically cover them.
What is reviewed?
- Spec & scope: Does the change meet the spec and stay within the agreed scope?
- Clarity & architecture: Are the change’s structure, maintainability and architecture sound?
- Security & data access: Are security, data access and permissions adequately protected?
- Tests & failure cases: Are tests and checks meaningful, including relevant failure cases?
- Interfaces & existing functionality: Have effects on interfaces and existing functionality been checked?
- Operations & rollback: Where operations are affected: are monitoring, alerting, rollback and recovery defined and supported by evidence?
Review depth follows risk: a text change needs less scrutiny than a change to permissions, payments or data migrations. Conditional items may be marked “not relevant” with a brief reason.
Agents support. Humans approve.
The agent review is a separate review task with access to the spec, changes and relevant evidence, in a separate AI context. The generating agent’s self-assessment is not sufficient. A separate agent does not guarantee correctness either. Agents provide findings and proposed corrections; humans decide on approval.
The Workmaster coordinates the workflow and makes open reviews or missing evidence visible. This does not grant automatic approval authority. Merge approval in B8 and controlled release in B10 remain separate decisions.
Three checks, three questions
- PR-Review · B8
- Is the technical change sound and ready for integration?
- Domain acceptance · B9
- Does the solution meet the agreed requirement?
- Value Loop
- Does the released solution achieve the expected impact?
These checks complement one another. None replaces the others.
Long-waiting or oversized PRs delay feedback and increase the risk of rework. Keep open reviews visible and address them promptly to limit feedback debt early. Make feedback debt visible →
- Human responsibility
- Named human reviewer in the Delivery Team
- AI support
- Reviewer with a separate review task in a separate AI context; Workmaster coordinates open reviews
- Evidence
- Documented technical merge approval for the reviewed version with evidence.
- Handoff
- Return blocking findings to B3, B5 or B6, resolve and recheck them. Relevant changes after approval require another review.
B9Accept the business outcome
Use the Acceptance Slot to test real scenarios with a prepared test version, data, and roles. The Feature Partner confirms the criteria or describes specific gaps. Handle new requests separately. For critical components, completion also requires evidence for the agreed observability and tested failure behavior, alongside the business functionality.
- Human responsibility
- Feature Partner; Product Owner clarifies changes
- AI support
- Reviewer prepares
- Evidence
- Confirmed criteria or a specific correction brief.
- Handoff
- Silence is not acceptance. Agree on a deputy and a response time.
B10Release in a controlled way
Activate the change and record the release and user group. Check operations and data collection. Verify the agreed monitoring signals, alerts, and recovery paths. Scale the depth and effort to the criticality.
- Human responsibility
- Team + named release owner
- AI support
- Workmaster within the permitted scope
- Evidence
- Stable activation and verified measurement data.
- Handoff
- Hand over to V3. In an incident, use the agreed rollback path.
02 / VALUE
Value Loop
Check whether the intended impact occurs, beyond whether the software works technically.
- Observe
- Compare
- Decide
Make Feedback Debt visible: track released changes with unevaluated impact, including age, review date, and ownership. Make it visible in practice →
Show all Value Loop steps V1–V6
The hypothesis and measurement plan start early. Scorecard, evidence, monitoring, telemetry, and the Value Review support interpretation and decisions later.
V1Form an impact hypothesis
Describe the target group, problem, and expected improvement. Include user feedback.
- Human responsibility
- PO + Feature Partner
- AI support
- Scout
- Evidence
- Testable impact hypothesis.
- Handoff
- Starts during B2, not after development.
V2Plan measurement
Agree on a baseline, target, comparison, data volume, and guardrail metrics. Include technical operating indicators only when they clearly affect users, business impact, or system reliability.
- Human responsibility
- PO + Measurement Partner + Team
- AI support
- Impact Analyst
- Evidence
- Feature Scorecard and required measurement events. For a pure bug fix, evidence that the expected state has been restored may be sufficient.
- Handoff
- Handoff to B3: measurement becomes part of the spec, tests, and implementation.
V3Collect data
From activation onward, verify the release, user group, and measurement points. Correct faulty data collection.
- Human responsibility
- Measurement Partner + Team
- AI support
- Impact Analyst supports
- Evidence
- Reliable, attributable data source.
- Handoff
- Receives the handoff from B10. Do not interpret unreliable data as impact.
V4Analyse data
The data pipeline calculates metrics. People check completeness, comparability, and side effects.
- Human responsibility
- Measurement Partner
- AI support
- Impact Analyst
- Evidence
- Report on usage, impact and uncertainty.
- Handoff
- Metrics are calculated. AI can explain them but must not invent missing values.
V5Understand the findings
Consider the numbers alongside user experience. Identify alternative explanations.
- Human responsibility
- PO + Feature Partner + Measurement Partner + Team
- AI support
- Impact Analyst
- Evidence
- Reasoned assessment, including its limitations.
- Handoff
- Not enough data? Define a specific investigation plan and a new review date.
V6Make the product decision
Keep, improve, expand, investigate further, or roll back. The Product Owner decides within the agreed mandate. For higher-level decisions about goals, budget, or priorities, they bring the findings and recommendation to the appropriate decision-maker. Record the owner and next action.
- Human responsibility
- Product Owner with team and partners
- AI support
- Impact Analyst prepares
- Evidence
- Traceable product decision.
- Handoff
- Feed improvements back to B1, a new hypothesis to V1, and process findings to L1.
03 / LEARNING
Learning Loop
Insights change specs, tests, agent context, prompts, rules, or working conditions.
- Understand
- Adapt
- Improve
Reduce Feedback Debt: resolve outstanding feedback and apply insights to the next spec, tests, or working agreement. Make it visible in practice →
Show all Learning Loop steps L1–L6
Turn observations into a bounded experiment, evaluate its benefit, and embed what works for the next change.
L1Gather experience
Capture rework, waiting time, acceptance returns, successful work, and team feedback. Record incidents, false alarms, and near misses as feedback. Also capture the AI skill version, context size, missing information, and AI costs with relevant evidence. AI skills and AI context explained.
- Human responsibility
- Team + partners; Loop Guide reviews the working context
- AI support
- Learning Guide
- Evidence
- Evidence from Build and Value.
- Handoff
- Runs from the start, including for bugs, support, and small tasks. No individual performance scores.
L2Understand patterns
Choose a relevant problem and investigate possible causes. Separate observations from interpretations.
- Human responsibility
- Team + Loop Guide
- AI support
- Learning Guide
- Evidence
- Bounded problem with a hypothesis about its causes.
- Handoff
- Escalate organisational obstacles to the responsible leader.
L3Agree on an experiment
Define a small change, expected benefit, measurement, budget, owner, and review date. For example, improve an AI skill or change how AI context is selected. Trial them separately so the cause of any result is clear.
- Human responsibility
- Team decides; Loop Guide facilitates
- AI support
- Learning Guide
- Evidence
- A testable experiment.
- Handoff
- At most one deliberate process experiment per team at a time.
L4Try it in everyday work
Apply the change to suitable upcoming tasks. Observe effort and impact.
- Human responsibility
- Named owner in the team
- AI support
- Depends on the task
- Evidence
- Comparable cases and documented experience.
- Handoff
- Harmful side effects are a signal to stop early.
L5Assess impact
Compare the old and new ways of working on similar tasks. For AI skills and context, compare output quality, rework, human review time, and AI costs. Record the observed improvement and uncertainty.
- Human responsibility
- Team; Loop Guide facilitates
- AI support
- Learning Guide
- Evidence
- Retain, adapt or discard.
- Handoff
- Take unclear causes back to L2 and unsuitable actions back to L3.
L6Embed learning
Turn proven learning into specs, tests, monitoring, alert thresholds, more resilient architecture, working agreements, AI skills, or AI context templates. Feed incident learning into the next spec in B3. The team approves the version, owner, and rollback path. Share evidence and limitations in the Learning Exchange, then reuse the learning deliberately in B4.
- Human responsibility
- Team approves; owner maintains
- AI support
- Reviewer or responsible AI agent
- Evidence
- A verified rule for subsequent work.
- Handoff
- Feed learning back into Build and Value. Other teams decide whether it applies to them.
Guidance for all three loops
Principles
The shared rules behind the cycle. Open a principle for the full explanation.
Impact sets the direction.
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.
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.
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.
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 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 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, 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
Explore further
More about implementation
These topics support the three loops in everyday work.