Photon delivered my project — what should I check before I accept it, if I can't read the code?
5 min read
The short version: hold the delivered work against your brief, run it end to end in the private preview, test it at phone width, and confirm every promised element is actually there — before you publish, because a page is visible only to you until that moment. Photon, SentX SI's AI coding agent, hands back finished work, not a snippet to paste. You describe the result you want — one sentence is enough — and a team of agents plans the work, writes and runs the code, checks it and delivers it to Results, where you open it, preview it, download it or publish it. The check Photon describes — agents checking the result, a Watcher steering any task that stalls, repeats itself or drifts — runs while the job is in progress, and it is part of why the work arrives finished. But the decision to accept is yours, and the pass that supports it has to be one you can do without reading the code. You can: Photon's own page is explicit that no coding knowledge is required, and it treats reading the files the agents wrote as a developer capability. A non-developer's check is behavioral, not code-level, and that turns out to be exactly the right kind of check for the decision at hand.
Source: Photon AI Coding Agent — Describe It, Get It Built
The four steps below are my editorial suggestion, not a tested result and not a documented Photon procedure. They are built from what the product page says the delivered work is and what you can actually observe in the preview.
-
Match the brief point by point. Before you open anything, write down what you asked for. If you gave one sentence, expand it into four checkable lines: what the thing is for, who uses it, what it must do, what it must not do — the same move the brief guide for Photon rests on, the idea that if you can write those lines down, you can hold the finished work to them. Then walk the deliverable and mark each line met, not met, or can't tell. Can't tell is a legitimate result, not a failure: it is a question you ask Photon in plain language before you publish, not a surprise you discover after. A one-sentence brief produces more can't tell than a detailed one; that is what the detailed brief is for next time.
-
Run every user flow end to end. Whatever the core action of the work is, do it in the private preview, all the way through. A booking site means filling the form, submitting it, and confirming the submission lands. A dashboard means clicking through every tab and filter. A multi-page site means walking the main routes from the home page. End to end is the operative phrase: a form that renders but does not accept, a button that goes nowhere, a step that dies at the confirmation screen — these only appear when you complete the flow instead of glancing at it. For documents and files, the flow is the reading: open every section, check the tables, and verify the names, figures and dates are yours rather than sample placeholders.
-
Check mobile rendering. Phones are where a large share of your visitors will arrive, so a passing desktop view is not a pass. Shrink the preview to phone width and re-walk the main flow; if you can reach the preview from a phone, do it there too. Text should not overflow or overlap, buttons should be tappable, menus should open, forms should fit. If the preview does not let you see the phone-width view, treat that as a gap to close with a question rather than an assumption.
-
Confirm the promised content is actually present. Separately from does it work, check is it there. Every page, section, image, number and piece of copy the brief promised — including the things so obvious they feel checked: the contact email, the address, the prices, the dates. This step earns its place because generated work often looks complete exactly where something is missing, and a placeholder paragraph or a default image can sit inside an otherwise flawless page. Read the finished work the way you would read a submission from someone else, not the way you would read your own plan.
When a step fails, do not publish and do not start over. Describe what is wrong in plain language — the same channel you used to request the work — and the result comes back as a fresh private preview. The loop is check, describe, re-check, and each pass runs against work the agents have already built rather than against empty space.
Source: Photon AI Coding Agent — Describe It, Get It Built
What the four steps cannot see is real, and worth naming: code quality, performance under load, security. Those live behind the developer-only surfaces, and the internal check that covers them is the agents' business, not yours. A clean behavioral pass does not certify the code; it certifies the narrower claim a non-developer can actually stand behind, which is that the work you can see does what the brief says. That is the right standard for the decision in front of you, because the decision is publish — and the page stays private until you make it.
The habit has a name, and it is one SentX already practices. The Victoria model card lists as a known limit that answers can contain incorrect facts, citations or calculations, and the counter-habit is simple: open the cited source and check the supporting passage. Here the documents are just different — the delivered preview is the source, and your brief is the passage you check it against. Think with Victoria, build with Photon; checking the build against the brief is how the two halves stay honest to each other. Publish when the preview passes, and after launch the same loop keeps working, because your live site stays exactly as it is until you choose to republish.
Source: Photon AI Coding Agent — Describe It, Get It Built; Victoria AI Model Card | Capabilities, Evidence and Limits
Sources
- Photon AI Coding Agent — Describe It, Get It Built — SentX SI
Supported claims and limits
- Photon is SentX SI's AI coding agent that takes a plain-language request and returns finished work, not a snippet to paste; owner-stated, not independently validated
- Finished work arrives in a Results area where the user can open, preview, download or publish it; documents the surface only, not what a passing check establishes
- A page is visible only to the user until published; no claim about post-publish rollback or versioning
- Websites, documents and diagrams can be previewed inside the workspace; no preview fidelity, completeness or mobile-behavior claim
- A Watcher checks every running task and steers it when it stalls, repeats itself or drifts from the request; owner-stated internal check with undefined criteria, not a quality guarantee
- One sentence is enough to start, with files or details added when available; establishes the input, not any match between input and output
- No coding knowledge is required; developers can additionally write team instructions, connect a server and read every file the agents wrote
- The brief article linked on the page states that if you can write down what the thing is for, who uses it, what it must do and must not do, you can hold the finished work to them; limited to that article's claim
- The 'Think with Victoria, build with Photon' line appears on the page verbatim; a brand statement, not a measured result
- Victoria AI Model Card | Capabilities, Evidence and Limits — SentX SI
Supported claims and limits
- Known limits state that answers can contain incorrect facts, citations or calculations, with the counter-habit to open cited sources and check the supporting passage; first-party disclosure, not an independent finding