Editing by chat

There's no separate "edit mode" — every message you send in an app's chat is another turn of the same coding agent, with full memory of what it has already built.

How the agent decides what to change

The agent reads the current state of your project (its file tree, recent history, and its own progress ledger) before making a change, so it can:

• Make targeted edits instead of rewriting unrelated files.
• Avoid losing existing code — a dedicated guard refuses any edit that would silently drop code behind a placeholder like // rest unchanged instead of actually including it.
• Catch cross-file breakage — if it removes or renames something another file depends on, it flags that before you find out the hard way.

Good follow-up requests

Be as direct as you'd be with a developer sitting next to you:

"Move the search bar to the top"

"The submit button should be disabled while saving"

"This crashes when the list is empty — fix it"

You don't need to describe how to fix something — just describe the problem or the desired behavior.

Modes: Auto vs. Plan

The composer has a mode toggle:

• Auto (default) — the agent makes changes directly, testing as it goes.
• Plan — the agent proposes a plan and explains what it would change, without writing any files. Use this when you want to review an approach before committing to it, especially for larger or riskier changes.

Verifying a change actually worked

After any change that touches code, the agent is expected to run a verification step (tests, a build, a lint) before considering the turn finished — and if it can't, it will say so explicitly rather than silently skip it. If a test starts flipping between pass and fail across identical runs, the agent will flag it as flaky rather than pretend the fix worked because one run happened to be green.

Attachments

You can attach files (images, PDFs, .docx) to a message — for example, a screenshot of a bug or a spec document — and the agent will read them as part of the same turn.