One prompt is not an engineering process: how four specialists review our AI-written code

Anyone using AI to build software today usually works in one linear conversation: write a prompt, get code back, paste it in and hope nothing breaks in production. For a typo in a footer, that is more than enough.

For work where brand, security, mobile usability and data come together, it is a risk. A single generalist agent focused on the visual design easily misses something: an input field that makes the page zoom in on an iPhone, HTML that is not sanitised safely, or a database table without access rules.

That is why at For the Dream we do not rely on one agent that has to guard everything at once. Larger changes follow a fixed route: plan, build, and then a review by four specialists who each guard only one domain. Only when all four give the green light does the code move towards production.

In this article we explain how that route works, who does what and where its limits are. We illustrate it with a made-up but realistic scenario: a law and insurance firm, which we call Vanguard Legal & Indemnity here, asks for a new online intake for claims and mandates.

1. Not every task needs a committee

The route starts with a simple question: how big is this change? A small adjustment goes straight through, a larger one gets the full review.

If a partner at our example firm asks to change a phone number in the footer, it goes direct and is done within minutes.

If the same firm asks for a new intake, with photography per practice area, readable text over those photos, a confidential form to submit a claim and documents, and automatic onboarding of new clients, that touches several pages, forms, storage and security. That request enters the full route, and a status file is created that tracks where the task stands throughout.

2. The route in five steps

The full route has five fixed steps. After building, it splits into four parallel reviews, which then come together at a single gatekeeper.

If a review fails, the task goes back to a targeted repair step and then through the reviews again. That loop is deliberately limited: after two repair rounds the system stops and a person takes over. The order and the rules are fixed. What the agents write within a step remains the work of a language model and is therefore not predictable to the letter. That is exactly why there is a review behind it.

3. What happens in each step

Step 1: mapping the existing code

Before any code is written, the first step maps the existing code with a code graph: an index that knows which function uses which other function. That is more reliable than searching for text. For our example, this step finds where the colours and typefaces of the design system live, where the cards per practice area are built, which server functions process the form, and which parts depend on them.

Step 2: the plan, and a person who approves it

The second step produces the technical plan. For our example it has three parts. The photography for Litigation, Cyber Insurance and Mergers and Acquisitions gets a fixed focal point, so faces never disappear behind text or get cropped. Over those photos come gradients that guarantee a contrast of at least 4.5:1, the WCAG standard for normal text. And the form and the database schema are designed.

For major structural choices, the route pauses here. A person approves the plan or sends it back, and only then does building start.

Step 3: building

The third step writes the TypeScript, the React and Next.js components, the CSS and the server functions. In a typical AI workflow the process stops here. For us this is only halfway: as soon as the code is done, the four reviews begin.

4. The four specialists

After building, four specialists examine the change at the same time. Each guards one domain, works from a fixed list of rules and has no interest in sparing the builder.

Specialist 1: security

On a legal or insurance platform, one leak can expose legal privilege or a policyholder's data. This specialist checks every changed file on three points.

• Sanitising HTML with an allowlist, not with regular expressions. Free text in a claim description is sanitised with a library such as DOMPurify, which only lets permitted tags through and removes <script>, <iframe>, <object> and inline event handlers.
• Bot checks that do not block real clients. A form filled in too quickly often points to a bot. If a visitor's clock runs ahead of the server's, the measured time can come out negative. The specialist checks that such a measurement is not treated as a bot.
• No personal data in logs. The server logs keep only the outcome and the reason, never names, policy numbers or case content.

Specialist 2: mobile and frontend

A lawyer or in-house counsel reviewing an urgent claim on an iPhone has no use for a shifted layout or a page that suddenly zooms in.

• At least 16 pixels in form fields. Every <input>, <select> and <textarea> has a font size of at least 16 pixels on screens narrower than 768 pixels. Any smaller, and Safari on iOS zooms in as soon as someone taps a field.
• A sticky header that stays put. overflow-x: hidden on a parent element turns it into a scroll container, so a sticky header no longer sticks. The specialist requires overflow-x: clip, which cuts off horizontal overflow without that side effect.
• A compact header and responsive buttons. The mobile header stays one row high, and buttons get touch-action: manipulation, so a quick double tap is not read as a zoom gesture.
• Readable text over photos on every screen. The contrast of at least 4.5:1 is measured again at 320, 390, 768, 1024 and 1440 pixels wide, with no horizontal overflow.

Specialist 3: backend and data

When a policyholder reports a claim or in-house counsel requests a conflict check, the data has to be correct and shielded.

• Keys and relations. Records get UUIDs as keys, and strict foreign keys apply between claims, mandates and policyholders.
• Access per row. Row-Level Security in PostgreSQL ensures each record is visible only to the organisation and the role entitled to it.
• Login links that survive a virus scanner. Corporate mail filters often open links automatically to scan them. A login link that is used up on that first opening no longer works for the real recipient. The specialist checks that the link first shows a page where the user confirms themselves.

Specialist 4: QA and runtime

Reading code is not enough; it also has to run. This specialist actually builds the project and tests it in a browser.

• It runs the type check, the linter and a full Next.js production build.
• It has an automated browser (Playwright) open the pages on mobile, tablet, laptop and desktop, and checks contrast, keyboard tab order, the calmer variant for people who prefer less motion (prefers-reduced-motion) and the absence of errors in the console and the network.

5. Repairing without an endless loop

What happens when a specialist finds something? Suppose that in our example security and data give the green light, but the mobile specialist reports two problems: the policy number field is set to 14 pixels on mobile, so iOS zooms in, and on the Cyber Insurance card the contrast drops to 3.6:1 on a 390-pixel screen.

The gatekeeper collects only what failed, with the exact file and line, for example ClaimForm.tsx line 42 and practice-card.module.css line 18.

The repair step changes exactly those two points: the field's font size goes to 16 pixels, and the gradient on the card gets darker at the bottom.

Then only the reviews that failed run again, plus the QA specialist, which always runs. Security and data keep their green status, unless the repair touched their files.

After at most two repair rounds it is done or the system stops. If a problem persists after the second round, the responsible developer takes over with a report that states per file and per line what is still wrong. That way an agent does not keep trying endlessly and burning tokens.

6. Always visible where the task stands

Throughout the route, the system keeps a status file. At any moment a developer can see which step is running, which reviews are green and what is still open. For our made-up example, the final state after one repair round would look like this:

What this does and does not deliver

This way of working does not make software flawless. It does reduce the chance that an entire domain is overlooked because one agent was focused on something else. Each specialist looks only at its own list, the repair loop is limited and when in doubt a person decides.

The difference between a prototype and a platform an organisation can build on lies in the rules you do not deviate from. By writing those rules down and having four specialists test every change against them at the same time, we make them enforceable rather than dependent on whoever worked on it that day.