This is the first in a series of posts about what shipped in Caffeine V3. This one covers the new build architecture. Next up: how V3's design system produces better-looking apps.
If you've ever had Caffeine forget what your app looked like after 50 changes, here's why that happened, and why it won't anymore.
For V3, we rebuilt how Caffeine builds apps from the ground up. Until now, Caffeine used a sequential pipeline, essentially composed of a chain of agents that ran one after the other: plan the app, build the backend, build the frontend, run a quality check, deploy. Each step had to finish before the next could start. If step three discovered a problem with step two, there was no way to go back.
This worked well enough for simple apps. But as projects grew (more pages, more features, more iterations) the pipeline started hitting walls. Context windows would fill up. Earlier decisions would get lost. Quality would degrade.
V3 replaces the sequential pipeline with a team of specialist agents that can work in parallel, iterate across multiple rounds, and pass learnings between each round, all coordinated by an orchestrator we call the Composer. Think of it this way: instead of expecting one person to do it all, you now have a company working for you.
From one agent to a team
The Composer never reads or writes code. Its job is to break your request into tasks, dispatch them to the right specialists, collect the results, and decide what to do next. The specialists do the actual work:
- A Discovery agent scans your project to understand exactly where things stand before anything changes
- A Product agent turns your request into structured requirements the whole agent team can work from
- A Design agent creates a visual system (color tokens, typography, layout guidelines) that every frontend decision follows
- Frontend engineers write React code;multiple can run in parallel for different pages
- A Backend engineer writes Motoko code for the Internet Computer
- A Quality agent reviews the code and runs visual tests
When you ask Caffeine to build something, the Composer takes over in the background. While the build runs, you can keep chatting, add context, change direction, or stop the build entirely if you need to.
Waves: how the team coordinates
The Composer organizes work into waves. Within each wave, independent tasks run in parallel. Between waves, results flow forward.
A typical build looks like this:
- Wave 1 — Discovery scans the project. The Product agent produces a spec.
- Wave 2 — Design creates visual tokens. Backend writes API contracts. Both happen at the same time.
- Wave 3 — Frontend builds the app structure, using the design tokens and backend contracts from the previous wave.
- Wave 4 — If the app has multiple independent pages, they're built in parallel (each by a separate frontend agent).
- Wave 5 — Quality review against the original requirements, plus visual tests.
- Deploy.
The key insight is what happens between waves. Every specialist returns a structured result: what it built (so downstream agents know what's available), what it learned along the way, and what problems it found but couldn't fix. These flow forward, so that each wave starts with more context than the last, and learnings persist across builds, so the system gets smarter over time.
This creates two properties the old pipeline never had: Parallelism, which simply means that within each wave, independent tasks (design, backend, multiple pages, etc.) run at the same time. The old pipeline could only do one thing at a time. And iteration, where the Composer can run as many waves as needed. If the frontend discovers it needs a backend change, the backend engineer gets dispatched again. If quality review finds issues, another wave is added to fix them. The old pipeline ran once, start to finish.
Not every change needs the full team. If you're asking for something targeted, like changing a color or fixing a title, the Composer recognizes this and dispatches a single agent directly, skipping the full wave cycle. Complex features get the full pipeline. Quick fixes get a quick path.
Fresh context, every build
Every build starts clean. Even if you're just tweaking a heading, Caffeine re-examines the project from scratch before making any changes. This is deliberate:AI models do their best work without the accumulated weight of previous sessions dragging them down.
What does carry over between builds is a lightweight file of preferences and accumulated learnings. Metadata about how to work with your project, not a snapshot of the project itself. A project with 50 files and 700 draft versions works just as well as a brand new one. Better, actually: Caffeine captures what works for your specific project over time, so each build is more informed than the last. The opposite of what you were experiencing before.
You can see what's happening now
In V2, you sent a message, saw a "Building your app..." indicator, and waited. For complex apps, that could mean minutes of silence with no way of knowing what was happening or whether things were going well.
V3 shows you the build in real time. A task checklist shows each piece of work the Composer planned, with status indicators as tasks complete, fail, or get skipped. Progress summaries describe what Caffeine is working on right now. And there's a stop button — you can halt a build mid-flight if you realize you want to change direction.
The checklist maps directly to the wave structure. You can see when the design step finishes, when the backend is being compiled, when multiple pages are being built in parallel, and when the quality review is running. If something fails, you see which task failed and what happened.
Smarter error recovery
The old pipeline had a single quality check at the end — and it was checking whether the code was structurally sound, not whether the app actually worked. Does the code compile? Yes. Does clicking the "add to cart" button actually add the product to the cart? Nobody checked. V3 tests for both: structural quality and functional quality are different things, and both matter.
V3 catches problems as they happen. Backend code is compiled before frontend work begins. Frontend code is type-checked after every round of changes. The quality agent validates the finished app against the original requirements and grades each one — passed or failed, with reasons. It also takes screenshots of the running app and checks them against the design brief — is the text readable on its background? Are the interactive elements where they should be?
When something does fail, the Composer retries with context: the error details, the learnings from the failure, and a fresh context window. No fighting through accumulated mistakes.
This extends to deployment too. When a deploy fails, the error flows back to the Composer. It reads the error, attempts a fix, and retries the deployment — often before you even notice something went wrong. If a build truly can't be completed, it's cleanly discarded rather than left in a broken state.
What didn't change
Your projects still work the same way. You still describe what you want in plain language. You still get a draft you can preview, iterate on, and publish.
What changed is everything that happens between your message and the result.
Next in this series: how V3's design system and the DESIGN.md brief produce more consistent, better-looking apps.