Building

Writing prompts

How to describe changes so the model gets them right the first time.

Updated 21 Sept 2026

The model sees your entire project — every file, the chat history, and the template's conventions — before it writes anything. You don't need to paste code or explain the stack. What it needs from you is intent, scope and any decisions you care about.

The shape of a good prompt

Say what, for whom, and what "done" looks like.

Add a customers page for our sales team: a searchable table (name, company, owner, status), a "New customer" form, and a detail page per customer showing their call log. Search should filter on the server.

That prompt gives the model the feature, the audience, the fields, and one implementation constraint. It will pick the schema, routes and components itself.

What works well

  • One feature per prompt. "Add auth" and "add billing" are two prompts. Smaller change sets are easier to review and cheaper to redo.
  • Name the data. Listing the fields you care about ("amount, category, note, date") prevents guesses you'll have to fix.
  • State constraints, not implementations. "Filter on the server", "must work on mobile", "no external UI library" — the model handles the how.
  • Reference what exists. "Use the same card style as the dashboard" or "extend lib/items.ts" — it knows those files.
  • Attach a screenshot when layout matters. See Attachments.

What to avoid

  • Vague adjectives alone. "Make it better" produces arbitrary changes. "Make the table denser and add sorting on every column" does not.
  • Contradicting the stack. The project is Next.js App Router with Postgres; asking for a different framework won't be honoured.
  • Secrets in prompts. Put API keys in .env (see Environment variables), never in chat.

Iterating

Follow-ups are cheap because context is preserved. Prefer a sequence of focused prompts:

  1. "Add the expenses table and a form to add one."
  2. "Now list expenses grouped by month with totals."
  3. "Add a delete button with a confirmation."

If a change went in a direction you don't like, reject it and re-prompt with what was wrong, rather than layering fixes on top.

Long tasks

Big prompts are fine. Qyant streams the whole response, keeps going when the model reaches its output limit (it asks the model to continue from exactly where it stopped, up to four times), and never cuts a healthy generation short on a timer. A long multi-file change can take several minutes; the progress stays visible the whole time.

Cancelling

Click Stop while a response is streaming. Whatever was produced so far is kept in the chat, marked as interrupted, and nothing is written to the project.

Prompt length

Prompts can be up to 20,000 characters. Pasting a spec or a page of requirements is a good use of that.