How to Edit an AI-Built Site After Generation: Guide

You edit an AI-built site by describing the change in plain language. On Zugo each chat edit costs 3 credits, applies to the existing project rather than regenerating it, and is checked in a sandbox before you see the result. If the change is bigger than a description, export the code to GitHub and edit it as a normal codebase.

Almost nobody publishes the first build. The build is a starting point, and the useful skill is knowing which changes are one sentence, which are five, and which mean starting the page again.

What can you change with one sentence?

More than people expect, as long as the instruction names a specific thing and a specific outcome. The builder is working with the page it already made, so pointing at an element by what it says is usually enough to locate it.

Text is the easiest category. "Change the headline to X", "rewrite the about section in first person", and "shorten the three feature paragraphs to two lines each" all land reliably, because there is no ambiguity about what should end up different.

Layout and style follow. "Make the hero full height", "move testimonials above pricing", "use a warmer palette", and "increase spacing between sections" are single edits. So is "make the buttons larger on mobile", which is worth asking for more often than people do.

Adding a section is also one edit. "Add an FAQ with these five questions and answers" gives the builder the content and the placement, which is all it needs. The pattern that fails is "add an FAQ" with no questions, because then it invents them and you spend a second edit correcting the invention.

What makes an edit prompt work?

Name the target, the change, and the constraint. Three clauses, in that order, and the hit rate goes up sharply.

The pattern in the right-hand column is the same every time: something concrete has to be different afterwards, and you could tell from a screenshot whether it happened. If you cannot state that test, the instruction is not ready.

Batch related changes and separate unrelated ones. "Change the headline, shorten the intro, and swap the button colour to green" is one coherent edit at 3 credits. Mixing that with "add a booking system" in the same message gives you a muddled result and costs the same.

How much does editing cost, and when does that matter?

Editing is priced per action, so a session is predictable before you start.

An edit at 3 is half the price of a fresh build at 6, which sets the practical rule: two focused edits are cheaper than a rebuild, five scattered ones are not. When you find yourself on the fourth vague instruction, stop and write a better prompt from scratch instead.

Free gives 5 credits, which is enough to try an edit but not a build. Pro is $25 a month with 200 credits, and Business is $99 a month. The pricing guide breaks down what a typical project consumes end to end.

Hi-Fi mode costs double in both directions: 6 for an edit and 12 for a build. Use it when visual quality is the point of the change and standard mode when structure or copy is.

When should you rebuild instead of editing?

There is a real threshold and crossing it late is the most common way people burn credits.

Rebuild when the structure is wrong rather than the details. If the page has the wrong sections in the wrong order for the wrong audience, editing it into shape takes four or five instructions and still carries the original assumptions. One better prompt at 6 credits gets you further.

Edit when the structure is right and the specifics are wrong. Copy, colours, spacing, adding a section, connecting a service, correcting a price: these are edits, and chaining eight of them on a good foundation is normal and cheap.

There is a middle case worth naming. If you have made a dozen good edits and one bad one, ask for the specific reversal rather than rebuilding: "put the pricing section back above the FAQ" is 3 credits, while a rebuild throws away the dozen.

Whatever you do, keep the prompt that produced a good build in a text file. A prompt you can paste again is a specification, and it is the cheapest insurance in the whole workflow.

What happens to the site while you edit it?

Each edit produces a new version of the project, and each version is booted in a sandbox before it reaches you. A build that fails to start is reported as a failure rather than handed over, which lowers the risk of publishing a blank page. It does not remove the need to look at the result.

That check is technical, not editorial. It confirms the project loads and renders. It does not know that you meant "Tuesday" and typed "Thursday", and it cannot tell whether the new headline is better than the old one. The verified builds explainer covers exactly what the check does and does not catch.

Publishing is a separate action from editing, so an edit does not go live until you publish it. That gap is the safety margin: look at the change first, then push it out.

Test on a phone after any layout edit. The most common regression from a visual change is a hero that looks composed on a laptop and cuts off its own button on a 390 pixel screen.

Can you edit the code directly instead?

Yes, and for some changes it is the right answer. Export the project to GitHub and you have an ordinary repository on your own account that any developer can open. The project belongs to you, so this is a right rather than a favour.

Take that route when the change is genuinely programmatic: a third-party API with an unusual auth flow, a data transformation with real rules, or performance work that needs profiling. Very specific business logic is reached through repeated edits in the builder or through code, and code is faster past a certain complexity.

The honest trade-off is that these are two workflows rather than one continuous path. Decide which side of the line a project lives on before you invest a month of chat edits into it. The code export guide covers the mechanics and what you get in the repository.

Where does chat editing stop?

Three limits, named plainly.

It does not replace a development team on a complex product. A builder is excellent at getting to a working, published, real thing quickly. A product with a large data model, unusual integrations, and a team maintaining it eventually wants developers, and the export exists so that day is a handover rather than a rewrite.

Ambiguity gets interpreted, not queried. An instruction with two possible readings will be resolved one way, and it may not be your way. That costs another edit, which is why the specificity in the table above pays for itself immediately.

Large restructures are worse than a fresh prompt. Asking one edit to change the audience, the layout, and the offer at once produces a compromise. Rebuilding from a clearer description is cheaper and better.

Inside those limits, editing is where most of the actual work happens: describe the change, look at the result, publish when it is right. Start a project at zugo.dev and treat the first build as the draft it is.