Skip to content

The chat

The conversation on the left of the project page is the only way to change your app. What it remembers, how to phrase a change, and what the messages in it mean.

The left column of the project page is a conversation with the builder. It is the whole interface for changing your app — there is no settings panel, no visual editor, no code editor.

What is in it

Three kinds of message.

Yours, as right-aligned bubbles. Every one of them started a build run.

The builder's, under the heading Bookbag with the logo beside it. These are the summaries it writes when a run ends, rendered as formatted text — lists, bold, code all display properly.

System messages, which appear when something happened that was not a conversation. The only one you will see in practice is the note a version restore leaves: "Restored N files to their state before run #12."

While a run is live

A pending message appears with a spinner beside Bookbag, and the builder's words stream into it as the model writes them. You are watching it think, not waiting for a result.

Underneath sits a bordered panel with the last eight steps — each one an icon and a line: Read app/page.jsx, Wrote components/ServiceList.jsx, Installed: npm install date-fns. See Build steps for what each can say.

When the run finishes, the streaming text and the step panel are cleared and replaced by the builder's final message.

The composer

At the bottom. Its placeholder is Describe the next change…, or Building… while a run is live, when it is also disabled — you cannot queue a second message.

The send button becomes a square stop button during a run, tooltipped Stop this build. Pressing it shows Cancelling after the current step…; the run stops at the next step boundary and keeps everything already written.

What the builder remembers

The whole conversation for this project, every time. Not a summary, not the last few messages — all of it, replayed into the model before your new message.

This is why short follow-ups work:

Make it two columns.

Actually, revert that.

The thing you added at the bottom — move it above the form.

You do not have to restate what the app is or what you asked for three messages ago.

When a project's history gets very long it is compacted first, so the model's context window is not exhausted. This is automatic and you never see it happen.

The builder is also given the current list of files in your project at the start of every run, so it never has to spend a step working out what exists.

Writing a good change request

One change per message. This is the single biggest factor. A message asking for six things typically comes back with three of them done, and untangling that costs more than six separate messages would have.

Name the thing. "The pricing card's border is too heavy" is far better than "it looks off". If you know the file, name the file.

Describe the symptom when you are not sure of the cause. "Clicking Book does nothing" tells the builder to go and look. "Add an onClick to the Book button" tells it to do something that may not be the problem.

Say what you already tried. The builder reads the history, so "the last change did not fix it — the button still does nothing" is real information.

Be concrete about visual changes. "Smaller" is ambiguous; "about half the height" is not.

Things you cannot do from the chat

  • Edit a file yourself. The Code tab is read-only. Download the source if you want to edit by hand.
  • Undo the last message. Use Version history instead; it rolls files back properly.
  • Run more than one change at once. One run at a time per project.
  • Reach outside the project. The builder can only touch files inside your app.

The "Get me unstuck" card

If the most recent run failed, an amber card appears above the composer:

Get me unstuck Fresh attempt that reads the error first and verifies the fix.

This is not a retry button. It starts a run with a different brief — one that names the previous failure and orders the builder to read the error log first and verify before claiming success. See When a build fails.

Where the chat is kept

Permanently, with the project. Deleting the project deletes it. There is no way to clear the conversation without deleting the project.

Everyone with access to the project can read the whole chat, including viewers. It is a shared record, not a private one.

Next