Building and changing an app

Every change to an app goes through the conversation. What varies is how precisely you can say which thing you mean — and the preview lets you point at it rather than describe it.

Asking

Describe behaviour, not implementation. “A form that collects name, phone and plan, then shows a monthly cost” is a specification the assistant can build against; “use React state for the plan” is not your problem.

The first version arrives already reviewed: after building an app, the assistant renders it, looks at the screenshot and the runtime errors, and fixes what is visibly wrong before handing it over.

Pointing at things in the preview

The toolbar along the bottom of the preview has four modes. Each one attaches a reference to your next message, so you can say “make this bigger” and the assistant knows exactly what this is.

Mode	What it does
Select	Click any element — a button, a heading, an image — to pin it. Pin several and the count shows in the toolbar
Edit text	Type directly into the app. The visible text snaps back and your edit is sent as “change this from X to Y”
Annotate	Draw freehand on the preview. Undo, redo and clear are in the toolbar; the drawing goes with your message
Comment	Drop a note on a specific element — the element and the note travel together

Editing text in the preview does not save the app on its own. It is a way of saying what you want; the assistant makes the change in the code.

Pointing at code

In the Code view, select a range of lines and send it into the chat as a reference. Useful when something is wrong in a place the preview cannot show — a calculation, a condition, an import.

The code view is read-only by design: it is there to be read, copied and downloaded, not typed into.

Checking it on other screen sizes

The preview toolbar has back, forward and refresh, a path box for jumping to a route inside the app, and a device switch:

Preset	Size
Desktop	Fills the pane
Tablet	820 × 1180
Mobile	393 × 852

Once the app is published there is also a button to open the live version.

When something breaks

The console. Open it from the preview toolbar to see the app’s own logs, warnings and errors as it runs.

Automatic fixing. If a change leaves the app failing to build or throwing errors on load, Dhanu sends the error back into the conversation by itself and tries again — up to two attempts per message. After that a Fix with dhanu button stays on screen so you can trigger it yourself.

Build errors never reach you silently. Every write the assistant makes is compiled on the server, and a failure comes back to it as an error to fix before the turn ends.

Test build. In Settings → General you can compile the app on demand and see whether it passes. Worth doing before you publish.

What limits a change

Limit	Value
Files in an app	40
Size of one file	100 KB
Total size	1 MB
Packages	A vetted list only — anything else is blocked at build time

Hitting a limit is a signal to split the idea, not to fight it: a smaller app that does one thing well beats one that has grown past what fits.

Working with it well

Change one thing at a time. Apps are edited file by file. A narrow request gets a narrow, reviewable change; “make it all better” gets a rewrite.

Point instead of describing. “Fix the alignment of this” with the element selected beats three sentences locating it.

Say when something needs to persist. “Entries should still be there tomorrow” is the sentence that turns a page into an app with saved data.

Look at the app, not the code. Click through it. Most problems are visible in ten seconds of use and invisible in a diff.