Building in Caffeine is not a one-shot generator. It is a conversation. You write, Caffeine builds, you review, you write again — until the app is exactly what you had in mind. This loop is not a failure of prompt craft; it is the productive core of the workflow.
Every message updates the app and goes to draft first — you review before anything goes live. That is the difference between Caffeine and a classic code generator: you never see a surprise in the production canister.
> THE CORE LOOP
1. PROMPT
You write a message — an idea, a correction, a new direction. That is your input into the conversation.
2. REVIEW DRAFT
Caffeine builds a new draft version. You see the result before anything goes live. No surprises in the production canister.
3. PROMPT AGAIN
Something off? Write the next message. Every message updates the app and produces a new draft for review.
4. REPEAT UNTIL HAPPY
As many times as you want. There is no limit on updates — only your credit budget decides when you stop. Each iteration brings you closer to the goal.
5. PUSH TO LIVE
When you are happy: one click, and the draft becomes the live canister on the Internet Computer. Tamperproof, permanent, sovereign.
> DRAFT FIRST — ALWAYS
Every message produces a new draft version of the app. You see the result in draft mode — you can click, scroll, test. Only when you press 'Push to Live' does the draft become the real canister on the Internet Computer. Until then, your live canister stays untouched.
That means: you can experiment without fear. A bad draft costs credits, but it never costs you your live app. The last good draft stays until you consciously push live.
[NO LIMIT ON UPDATES]
> EVERY BUILD STARTS FRESH
Every build starts with a fresh scan of your current draft. Caffeine reads the state of the app, plans the change, and builds. This applies to version 1 just as much as version 700 — the scan is always fresh, the build is always incremental on the current state.
You don't have to worry that an old version gets 'forgotten' or that the build starts from a stale state. Version 700 works just as reliably as version 1 — the fresh scan guarantees Caffeine always builds from the current state.
> SEND MESSAGES WHILE A BUILD IS RUNNING
You don't have to wait for a build to finish. You can send a message mid-build — Caffeine picks it up and reacts. Three typical scenarios:
ADD CONTEXT
You notice a missing edge case while the build runs? Send a message with the missing detail — the running build picks it up.
CHANGE DIRECTION
You decide mid-build that a different approach is better? Write it. The Composer routes the new intent to the agents — no restart.
STOP IT
The build is heading the wrong way? Write 'Stop'. You stay in control — the build halts, you keep the last good draft.
> THE LOOP IS PRODUCTIVE, NOT FAILURE
The Low-Prompt Method (Section 1) teaches you to minimize correction rounds as waste — the more precise your first prompt, the fewer credits you burn. That stays true. But the loop itself is not failure: it is the normal way you refine an app. A builder who does 20 iterations has not failed 19 times — they have learned 20 times and shaped the app iteratively.
The difference: bad prompts that force correction rounds are waste. Targeted iterations that turn a good app into a great one are productivity. Both are loops — but only the first costs you credits without value. Celebrate the loop as a tool, not as an admission of bad prompts.
> EVERY ITERATION IS RISK-FREE
On the Internet Computer, canister upgrades are orthogonally persistent — your data survives every code change. That applies to every iteration in your loop. You push version 47 live, discover a bug, write a correction, push version 48 — your user data stays untouched. No migration scripts, no data-loss risk, no 'let's hope the upgrade works'.
This connects the loop to the proactive audit habit (Section 9): iterative auditing is productive because every iteration is risk-free. You can audit after every push, correct, push again — and the cycle repeats without you ever fearing data loss. That is the ICP advantage that makes the loop possible in the first place.
> QUICK START PROMPT
Copy this prompt to put Caffeine explicitly into loop mode — draft-first, fresh scan per build, and clear expectation that you will iterate.
I will build this app iteratively. Treat each message as one step in a conversation, not a one-shot request.
Rules:
- Every message updates the app and goes to draft first. I review before anything goes live.
- Start each build with a fresh scan of the current draft state — do not assume a stale baseline.
- I may send messages while a build is running: to add context, change direction, or stop it.
- There is no limit on iterations. I will stop when the draft matches what I want.
- Only push to live when I explicitly say so. Until then, keep everything in draft.
First step: read my app description and build the initial draft. Then wait for my next message.[THE LOOP IS THE FEATURE]
[CREDITS ARE THE ONLY LIMIT]
> THE FOUR LOOP TYPES — THE DEEPER FRAMEWORK
The core loop above is the practice you live every day in Caffeine. Beneath it sits a deeper framework that the Claude Code team at Anthropic officially defined in their blog post 'Getting started with loops' (June 30, 2026). It distinguishes four loop types along two axes: what triggers the loop and what stops it. Caffeine's conversational build loop is essentially a turn-based loop — you prompt, Caffeine builds, you review, you prompt again. The goal-based, time-based, and proactive patterns are advanced agentic concepts that show where loop engineering is heading — useful context for builders who want to understand the broader agentic landscape.
The four types are axes for trigger and stop design — not a mandate to enable everything at once. Not all tasks require complex loops; start with the simplest solution and use these patterns selectively.
TURN-BASED LOOPS
// Trigger: A user prompt
// Stop: Claude judges it has completed the task or needs additional context
// Best used for: Shorter tasks that are not part of a regular process or schedule
// Managed usage by: Write specific prompts and improve verification using skills to reduce the number of turns
You hand off: The check
Every prompt you send starts a manual loop with you directing each turn. Claude gathers context, takes action, checks its work, repeats if needed, and responds. This is the agentic loop. You hand off the verification check.
GOAL-BASED LOOPS (/goal)
// Trigger: A manual prompt in real-time
// Stop: Goal achieved OR maximum number of turns reached
// Best used for: Tasks that have verifiable exit criteria
// Managed usage by: Setting a specific completion criteria and explicit turn caps, e.g. 'stop after 5 tries'
You hand off: The stop condition
A single turn is often not enough for complex tasks. Agents do better when they can iterate. You extend how long Claude keeps iterating by defining what done looks like with /goal. When you define the success criteria, Claude doesn't have to make a determination on what is 'good enough' and end the loop early. Each time Claude tries to stop, an evaluator model checks your condition and sends it back to work until the goal is met or a number of turns you define is reached. You hand off the stop condition.
TIME-BASED LOOPS (/loop, /schedule)
// Trigger: A specified time interval
// Stop: You cancel it, or the work completes (the PR merges, the queue is empty)
// Best used for: Recurring work, or interfacing with external environments / systems
// Managed usage by: Set longer intervals or react based on events rather than time
You hand off: The trigger
Some agentic work is recurring — the task stays the same and only the inputs change (e.g. summarizing Slack messages every morning). Other work depends on external systems, and a simple way to interface with one is to check it on an interval and react to what changed (e.g. a PR which may receive code reviews or fail CI). /loop runs on your computer, so if you turn it off, it stops. You can move the loop to the cloud by creating a routine with /schedule. You hand off the trigger.
PROACTIVE LOOPS
// Trigger: An event or schedule, with no human in real time
// Stop: Each task exits when its goal is met. The routine itself runs until you turn it off
// Best used for: Recurring streams of well-defined work: bug reports, issue triage, migrations, dependency upgrades, etc.
// Managed usage by: Routing routines to smaller, faster models and using the most capable model for judgment calls
You hand off: The prompt
The primitives above, along with other Claude Code features like auto mode and dynamic workflows, can be composed into a loop for long-running work. A proactive loop chains: /schedule (research preview) to run a routine that checks for new reports; /goal to define what done looks like and skills to document how to verify it; dynamic workflows to orchestrate agents that triage each report, fix it, and review the fix; auto mode so the routine runs without stopping to ask for permission. You hand off the prompt.
> OFFICIAL SUMMARY — FOUR LOOP TYPES
The Claude Code team's summary table comparing all four types at a glance:
| Loop | You hand off | Use it when | Reach for |
|---|---|---|---|
| Turn-based | The check | You're exploring or deciding | Custom verification skills |
| Goal-based | The stop condition | You know what done looks like | /goal |
| Time-based | The trigger | The work happens outside your project on a schedule | /loop, /schedule |
| Proactive | The prompt | The work is recurring and well-defined | All of the above, and dynamic workflows |
Turn-based
- You hand off
- The check
- Use it when
- You're exploring or deciding
- Reach for
- Custom verification skills
Goal-based
- You hand off
- The stop condition
- Use it when
- You know what done looks like
- Reach for
- /goal
Time-based
- You hand off
- The trigger
- Use it when
- The work happens outside your project on a schedule
- Reach for
- /loop, /schedule
Proactive
- You hand off
- The prompt
- Use it when
- The work is recurring and well-defined
- Reach for
- All of the above, and dynamic workflows
[KEY PRINCIPLE]
> HOW THIS MAPS TO CAFFEINE
Caffeine's conversational build loop is essentially a turn-based loop: you prompt, Caffeine builds a draft, you review, you prompt again. You hand off the check — Caffeine performs verification (fresh scan, draft-first, build plan), and you decide when 'good enough' is. That is exactly the hand-off structure the Claude Code team describes for turn-based loops.
The other three types are not exposed as separate primitives in Caffeine today — but the framework helps you understand the architecture: goal-based loops (with /goal and an evaluator model) are what Caffeine applies internally when the Composer verifies a build plan against requirements. Time-based and proactive loops (/loop, /schedule, dynamic workflows) are the direction agentic building is moving — recurring audits, automated triage, scheduled builds. When you use Caffeine today, you live the turn-based loop; the framework shows you what could come next.
Practical takeaways: (1) Write specific prompts and use skills to reduce the number of turns — that is the official recommendation for turn-based loops and aligns with the Low-Prompt Method from Section 1. (2) When you build more complex tasks with verifiable exit criteria, state them explicitly as a goal — that is the goal-based mindset, even without the /goal primitive. (3) Plan recurring work (audits, dependency upgrades) as its own scheduled loops, rather than mixing it into every build loop.
> SOURCES & REFERENCES
The four loop types and their official definitions come from the Claude Code team at Anthropic. Full credit goes to the original:
- // claude.com/blog/getting-started-with-loops — published June 30, 2026
- // code.claude.com/docs/en/goal — /goal docs
- // code.claude.com/docs/en/agent-sdk/agent-loop — agent loop docs
// Loop Vibe Coding Checklist
- I understand that building in Caffeine is a conversation, not a one-shot generator
- I know the core loop: prompt → review draft → prompt again → repeat → push to live
- I know every message goes to draft first — I review before anything goes live
- I know there is no limit on updates — only my credit budget stops me
- I understand every build starts with a fresh scan — version 700 works like version 1
- I can send messages mid-build — add context, change direction, or stop it
- I celebrate the loop as a productive tool, not as an admission of bad prompts
- I understand ICP upgrade safety makes every iteration risk-free — no fear of data loss
- I know the four official loop types (turn-based, goal-based, time-based, proactive) and their trigger and stop criteria
- I understand Caffeine's conversational loop is essentially a turn-based loop — I hand off the check
- I know not every task needs complex loops — start simple and use patterns selectively