When you describe an app in chat, Caffeine's AI generates the complete application — frontend, backend, and data storage — automatically. You don't write code, configure servers, or manage a database. The AI handles all of it, then deploys the app to a live URL.
What the AI generates
Every Caffeine app has three layers, all generated together:
Frontend — the interface your users see and interact with. Built in React and TypeScript. The AI generates the layout, components, styling, and any images or assets the app needs.
Backend — the server-side logic. Written in Motoko, a language designed specifically for apps running on the Internet Computer. The backend handles data storage, business rules, access control, and any integrations with external services.
Data layer — data is stored inside the app itself using Motoko's built-in persistence model. There is no separate database to configure. Data lives on the Internet Computer network alongside the app logic.
The AI team
Caffeine doesn't use a single AI to build your app. It assembles a team of specialist agents, each responsible for a different part of the work:
- Discovery — scans your existing project to understand its current state before any changes are made. This runs on every build, even small ones, so the team always has an accurate picture of your project.
- Product — translates your request into structured requirements. In Guided mode, this is the agent that asks you clarifying questions before building.
- Design — creates a design brief for your app: colors, typography, spacing, and layout guidelines. All frontend work follows this brief, which is why your app looks consistent across pages.
- Frontend engineers — write the interface code. Multiple frontend agents can work in parallel on different pages.
- Backend engineer — writes the server-side code in Motoko.
- Quality — reviews the finished code against your original requirements and runs visual tests to catch issues.
These agents are coordinated by the Composer — an orchestrator that breaks your request into tasks, dispatches the right specialists, collects results, and decides what to do next. The Composer never writes code itself.
A Data Intelligence agent is also available during chat. When you ask a question about your app's actual data — such as how many users are signed up, what orders came in today, or what values are stored in a particular table — the AI can query your app directly and return the real answer rather than a guess.
You can keep chatting while a build runs. The build happens in the background, and you can send additional messages or stop the build at any time.
Waves: how work is organized
The Composer organizes work into waves — phases where independent tasks run at the same time. Between waves, the results from one phase flow forward into the next.
A typical build looks like this:
- Discovery and requirements — the Discovery agent scans the project while the Product agent produces a specification from your request.
- Design and backend — the Design agent creates visual guidelines and the Backend engineer writes the server-side code. Both happen at the same time.
- Frontend foundation — the frontend is built using the design guidelines and backend contracts from the previous wave.
- Additional pages — if the app has multiple independent pages, they are built in parallel by separate frontend agents.
- Quality review — the Quality agent checks the code against the original requirements and runs visual tests.
- Deploy.
The Composer can run as many waves as needed. There is no fixed number of steps. If something in a later wave reveals a problem with earlier work, the Composer can go back — dispatching the backend engineer again, for example, if the frontend discovers it needs a new endpoint.
How agents share information
Between waves, every agent passes three things forward:
Contracts — what the agent built that other agents can use. For example, the backend agent reports its available endpoints and data types, so the frontend agents know what to connect to. The design agent reports its color system and font choices, so every page follows the same visual style. Agents receive contracts from earlier waves so they know exactly what's available — they don't have to re-read every file in the project.
Learnings — short observations about non-obvious things discovered during the work. For example: "this particular keyword is reserved and can't be used as a variable name" or "this hook returns an object, not an array." These flow forward to later waves so the same mistake isn't repeated. Learnings also persist across builds — the system gets smarter over time as it accumulates knowledge about your specific project.
Issues — problems that were found but not fixed. If the quality review finds a broken form handler, it reports the exact location. The Composer can then dispatch a targeted fix in a follow-up wave.
Fresh context, every build
Every build starts clean. Even if you're just changing a button color, the Discovery agent scans your project first to understand its current state.
AI models produce their best work when they have plenty of room in the context window. The more accumulated history and stale state you carry forward, the worse the output gets. Rather than trying to maintain a growing memory of your project across hundreds of iterations, Caffeine starts fresh each time and re-discovers what it needs.
The practical result: a project with many files and many draft versions works just as well as a brand new project. The AI never degrades because it never accumulates stale context. If you've experienced Caffeine losing track of your app after many changes — that problem is solved.
What does persist across builds is a lightweight file of user preferences, verified build commands, and accumulated learnings. This is information about how to work with your project, not a snapshot of the project itself. The code is always read fresh.
The design brief
Before any frontend code is written, the Design agent creates a DESIGN.md file — a structured design brief that serves as the single source of truth for how your app should look. It includes the color palette, typography rules, component styling, layout principles, and design guardrails. All frontend agents in the build follow this brief, which is why your app's visual style stays consistent across pages.
You can influence the design by describing the visual direction in your prompt, modify the design brief directly after it's generated, or provide your own. For the full details, see Influencing Your App's Visual Design.
Error recovery during builds
Caffeine checks for errors at every stage of the build, not just at the end:
- Compile checks run between every coding wave. Backend code is compiled before frontend work begins. Frontend code is type-checked after every round of changes. Errors are caught early, not at the end.
- The Quality agent validates against your original requirements. Each requirement is graded as passed or failed, with reasons.
- Failed tasks are retried with context. If something fails, the Composer dispatches it again — including the error details and any learnings from the failure. The retry gets a fresh context, so it's not fighting through accumulated mistakes.
- The Composer can go back. If a later wave discovers a problem with earlier work, the Composer can dispatch the relevant agent again. The old sequential pipeline couldn't do this.
- Deployment errors are caught too. If a deployment fails, the error flows back to the Composer, which attempts a fix and retries. The Quality agent also captures console logs and screenshots during builds, flagging runtime errors that wouldn't show up in a compile check.
- Automated app testing reports exactly what was verified. Before your draft is deployed, an automated tester runs a local copy of your app and walks through its main flows — checking that the things your app is supposed to do actually work. When the tester can verify everything, it confirms the result. When something could not be tested — for example, a UI interaction the tester could not reach — it reports only the specific gaps, not the entire flow, so the message you receive accurately reflects what was and was not checked.
If a build truly can't be completed, it's cleanly discarded rather than left in a broken state.
Build budget management
Caffeine monitors how much a build is spending as it runs, and adjusts agent behaviour to keep the result within your credit budget.
When a build becomes expensive, the AI automatically narrows its focus:
- Conserve mode — the AI stops adding optional work or expanding scope, and concentrates on completing the core features you asked for.
- Finish mode — the AI moves directly toward a deployable result. New feature work stops; agents prioritise getting a working app out the door.
- Hard stop — if the budget is fully reached, the Composer stops dispatching new agents and deploys the most recent working checkpoint instead of continuing. If no deployable checkpoint exists, the build ends cleanly without deploying.
This means a very expensive build may deliver a working but smaller result than your original request, rather than continuing to consume credits on features that would exceed your budget. The AI will tell you what it delivered and what it was not able to include.
Build progress
While a build is running, you can see exactly what's happening. A status indicator appears just above the chat input as soon as the AI starts working — showing Reasoning while it plans, then switching to a task count (X of Y tasks done) once work is underway. It also shows a scrolling summary of what the AI is thinking about right now. You can stop the build at any time using the stop button in this indicator, or expand it to see the full task checklist.
The full task checklist shows each piece of work the Composer planned, with status indicators as tasks complete, fail, or get skipped. If something fails, you see which task failed and what happened.
As the AI generates code, files appear in the Code panel progressively — you can switch to the Code tab at any point during a build and watch files stream in as they are written rather than waiting for the build to finish.
When a build finishes successfully, a version card appears in the chat showing the version number and links to preview the draft or view that version. This card stays in your conversation history as a persistent anchor — you can return to it at any time to open the preview or revert to that version.
Web search during builds
Caffeine searches the web automatically while building your app. If your app needs a third-party API, Caffeine can find the right one and learn how to use it. If a feature requires a specific library or code pattern, Caffeine looks it up. You don't need to find or paste documentation — describe what you want and the AI researches what it needs.
Clarification modes
You can control how much the AI asks before building. The setting is in the chat bar:
- Instant — the AI builds immediately without asking questions
- Guided — the AI asks clarifying questions before building, then confirms it's ready before starting
Switch between modes at any time. Instant is fastest; Guided is useful for complex requests where getting the details right matters. See Choosing a Build Mode for more detail.
Choosing a builder model
You can choose which AI model builds your app. Different models trade off capability and price, so you can use an efficient model for everyday changes and a more capable one when a change is especially demanding.
The available models are:
- Default — Caffeine picks the model for you. Recommended when starting out, with the best quality-to-price ratio.
- Claude Opus 5.5
- Claude Fable 5.1
- Claude Sonnet 5
- GPT-6 Astra
- GPT-6 Sol
- Kimi K3
- DeepSeek V4.1 Flash
The model picker shows each model's price in credits per 1 million tokens — input, output, and cache input — so you can compare before you build. You are charged for the tokens the AI uses at the rates of the model you picked. See How AI usage is priced.
To change the model, open the model picker in the chat bar. Anyone who can build in the project can change it — the owner, collaborators with build access, and, in a team workspace, the team member assigned to the project. The choice is saved for the project when you send your next message. Every AI agent working on the project uses it for every build, whoever starts it.
If a model you picked is retired, the picker marks it as No longer available and your next message uses the default model. Pick another model at any time.
How iteration works
Building with Caffeine is a conversation. After the first version is generated:
- Describe what you want to change and the AI updates the app
- Each message can add features, fix bugs, adjust the design, or change behavior
- Every change goes to your draft first — you review it before pushing it live
- There is no limit on how many updates you can make — each update is charged for the tokens the AI uses
Because every build starts with a fresh scan of the project, your app doesn't become harder to work with over time. Draft version 700 works just as well as draft version 1.
Frequently asked questions
What AI does Caffeine use?
Caffeine uses a team of AI agents working together to build your app. You choose which AI model they use from the model picker in the chat bar, or leave it on Default and let Caffeine pick the model for you. See Choosing a builder model for the full list.
Which builder model should I choose?
Start with Default. It is recommended when starting out and gives the best quality-to-price ratio. If a change is especially complex, try a more capable model for that change. The model picker shows each model's price per 1 million tokens, so you can compare costs before you switch.
Does changing the model affect my existing app?
No. Your app's code and data stay exactly as they are. The new model is used from your next message onward.
Can collaborators change the builder model?
Yes. Anyone who can build in the project can change it from the model picker in the chat bar. The choice is shared: it is saved for the whole project when they send their next message and applies to everyone's builds after that, so let your collaborators know if you switch to a model with different pricing. View-only collaborators can't change it.
What is Motoko?
Motoko is the programming language Caffeine uses for backend code. It is the first language designed specifically for AI-built apps. It includes built-in data migration safety — if an update could cause data loss, Motoko rejects it and the AI rewrites it. You never interact with Motoko directly.
What is a self-writing app?
A self-writing app is built, updated, and maintained entirely through natural language conversations with AI. No human writes code. On Caffeine, every app you create is a self-writing app.
Can the AI make mistakes?
Yes. The AI can misunderstand a request or generate code with bugs. Caffeine catches many errors automatically — compile checks run between every wave, and the Quality agent validates the finished app against your requirements. If a build still doesn't do what you wanted, describe the problem in the chat and the AI fixes it. Building with Caffeine is an iterative process.
Does the AI remember previous conversations?
Each build starts with a fresh scan of your project, so the AI always has an accurate picture of your app's current state. It also retains accumulated learnings from previous builds — patterns it discovered, preferences you expressed, and build commands it verified. Cross-project memory is not supported — each project has its own independent conversation.
Over time, the AI also learns things about you as a person — such as your role, the industry you work in, your goals, and your preferences — from your conversations. It uses this to give you more relevant responses and suggestions across your projects.