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.
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.
If a build truly can't be completed, it's cleanly discarded rather than left in a broken state.
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.
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.
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 (subject to credit usage)
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. Different agents use different AI models depending on their role — fast, lightweight models for scanning and design work, and powerful models for writing code and quality review. You don't choose or configure anything — Caffeine selects the right agents for each task automatically.
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.