Photon delivered my site — how do I ask for changes after launch without losing what works?
4 min read
You ask for changes the same way you asked for the site: a plain-language request in your Photon workspace, and you lose nothing because your live site stays exactly as it is until you choose to republish. Every account has its own workspace, and its files stay there between sessions, so a change request does not start from scratch. The lead agent plans it against the site you already have, the worker agents run the change, and the result comes back as a private preview that only you can see. Publishing is the moment a page folder goes live at its sentx.site address — and until that moment, your current live version is still the one visitors see. The loop is: describe the change, review the private preview, republish only when it checks out.
Source: Photon AI Coding Agent — Describe It, Get It Built | SentX SI
That safety comes from the flow, though, not from a guarantee. The one real exposure is that the check is yours: there is no documented diff tool or rollback button in the product, so the quality of your preview pass is the whole method.
Source: Photon AI Coding Agent — Describe It, Get It Built | SentX SI
Decide the size before you write a word Before describing anything, classify the change. A small edit fits the existing structure — new text, a different color, a reordered section, an updated image. A re-scope adds structure: a new page, a new feature, a different template or flow. The classification matters because it tells you how much "must not change" language the request needs. A typo fix needs none. Adding a pricing page means navigation changes on every page that links to it, and that is exactly the kind of change that quietly touches things you never mentioned, so the brief has to name it explicitly.
Phrase the change like the original brief The checkable-brief rules you used for the build carry over unchanged: state what the thing is, what it must do, and what it must not do. One sentence is enough to start a change — "make the hero headline shorter" is a complete request — and you add files or details when you have them, such as a screenshot of the section you mean. For anything beyond a small edit, the "must not" lines are where you protect what works. For example, a change brief for a new pricing page might read: "Add a /pricing page with three tiers, and add Pricing to the main navigation. Do not change the contact form, its fields or where it sends submissions, and do not restyle any existing page." That brief is checkable, because you can hold the finished work to each line — and holding it to those lines is the whole point.
Source: Photon AI Coding Agent — Describe It, Get It Built | SentX SI
Watch the plan for scope creep When the request goes in, the lead agent assembles the plan, and you can watch it and each agent's status while the work runs. That plan is your early warning. If you asked for a small edit and the plan starts reworking pages you did not mention, that is the moment to rephrase — not after the work is done. A Watcher checks every running task and steers it when it stalls, repeats itself or drifts from your request, which is a real guardrail for this loop, and Photon will also surface any decision that is yours to make rather than guessing. One practical note: republish rounds are work, and the work costs usage. If you have not set a daily, weekly or monthly spending limit, set one before you start iterating.
Source: Photon AI Coding Agent — Describe It, Get It Built | SentX SI
Check the preview against the live site before republishing Finished work arrives in Results, where you open it, preview it, download it or publish it — so a changed site goes through the same preview-then-publish flow as the original. Do not publish on arrival. Open the preview and walk the site page by page against what is live, starting with the parts you did not ask to change, because those are the ones you must verify actually stayed. Check each "must not" line you wrote: the form, the colors, the copy, the existing pages. Only when the preview checks out do you publish, and the folder goes live at its sentx.site address — that publish is your checkpoint for this round. If something you did not ask for has changed, do not publish; send another request that names exactly that part, and repeat.
Source: Photon AI Coding Agent — Describe It, Get It Built | SentX SI
Two limits to keep in view. An account can publish up to 25 sites, each up to 3,000 files and 200 MB, so a re-scope that adds many files can, eventually, push against those ceilings — and the workspace is where you would see that before publishing. And because the comparison is a manual pass, keep each round small: one change, or one tightly grouped change, per cycle. The loop holds when every publish is something you checked, not when you describe everything at once and hope.
Source: Photon AI Coding Agent — Describe It, Get It Built | SentX SI
Sources
- Photon AI Coding Agent — Describe It, Get It Built | SentX SI — SentX SI
Supported claims and limits
- Every account has its own workspace, and its files stay there between sessions
- A lead agent plans the work and assembles a team of AI agents for it
- The agents write, run and check the work in your workspace while you watch the plan and each agent's status
- A Watcher checks every running task and steers it when it stalls, repeats itself or drifts from the request
- Photon asks when a decision is yours to make
- Finished work arrives in Results, where you open it, preview it, download it or publish it
- A page is visible only to you until you publish it; publishing puts its folder online at its own address on sentx.site
- An account can publish up to 25 sites, each up to 3,000 files and 200 MB
- One sentence is enough; add files or details when you have them
- Set a daily, weekly or monthly spending limit
- The page documents no diff tool, rollback, version history, or stop control for running tasks