An agent can do the whole mechanical build: read a brief, set up a project workspace, write the pages against a shared template, generate the meta tags and structured data, build to static output and publish it to Cloudflare Pages on a custom domain with a working certificate. What stays with a human is everything that has to be true or has to be promised, which means the facts about the business, the claims it is willing to stand behind, the prices, the legal posture, the voice, and the decision to press publish.
The division of labour, stated plainly
A build agent is fast, literal and untiring. It will produce a complete Astro project, keep the canonical URL and the Open Graph tags in step, write JSON-LD that describes the blocks actually on the page rather than blocks it imagined, and run the same check for the fortieth time without getting sloppy. That is real work, and it is the kind of work that usually gets skipped when a human is doing it by hand at eleven at night.
What it cannot do is know things. It does not know whether the business is VAT registered, whether the phrase “family run since 1996” is accurate, whether same-day callouts are genuinely available in August, or whether the owner is comfortable with a number on the pricing page. Those facts live in a person’s head, or in their accounts, or in their diary. The agent’s job is to build well around whatever the person supplies, and to leave an honest gap where nothing was supplied.
That sounds like a small distinction. It is the whole thing. A site is not a pile of markup; it is a set of statements published under someone’s name, and someone has to be answerable for each one.
What the brief has to carry
The brief is the single richest human input in the process, and the quality of the finished site tracks it almost exactly. A brief that says “modern site for a plumbing firm” produces a competent, generic site. A brief that says the firm covers three named postcodes, works on commercial boilers rather than domestic, will not take emergency callouts, and wants enquiries by email rather than phone produces something a real customer can use.
In practice, a brief earns its keep when it settles:
- What the business actually does, in the words its customers use
- Who it serves, and who it does not want to hear from
- Claims that can be evidenced, and the evidence behind them
- Anything that must not be said, including prices, timescales and guarantees
- How an enquiry should reach a human, and how fast that human replies
The last one is worth more thought than it usually gets. This site’s own answer is one working day, and messages from the contact form go straight to an inbox rather than into a ticketing queue. That is a promise a person made and has to keep. No agent can decide it on their behalf.
What happens inside the workspace
The agent runs as a long-lived service on Fly and picks up a brief into its own project workspace. From there it works against the shared Q-Code.ai template: Astro, design tokens in a single theme file, SEO and accessibility already wired in, and a configuration file that everything else reads from. Content goes in as markdown and JSON. The build produces static output, and that output is what gets published.
The template matters more than it looks like it should. Because the tokens, the layout and the head tags are already settled, the agent is not making a thousand small aesthetic decisions on every project and getting a slightly different answer each time. It spends its effort on the content and the structure, which is where the variation between two businesses actually lies.
Some of those template decisions are opinionated in a way that is easy to miss. Site-wide details live in one config file, so the visible “last updated” date, the sitemap’s lastmod and the dateModified in the page’s structured data cannot disagree with each other. Noindexed pages carry a robots meta tag and are kept out of the sitemap, but they are deliberately not blocked in robots.txt, because a crawler that is forbidden from fetching the page never reads the noindex tag it was supposed to obey. A person reasoned that through once. Every build inherits it.
The judgement calls that stay with a person
Pricing is the clearest case. The honest position on this site is that cost depends on what you need, and that quoting a number which later changes is worse than saying so. An agent asked to fill a pricing page will fill it, and if the brief is silent it will reach for something plausible. Plausible and wrong is the failure mode that costs an owner money, because a published price is a price a customer expects to pay.
The legal pages run on the same principle. They are generated from a small configuration file, and the switches in it are factual questions about the deployment: does it use analytics, does it set cookies, does it have a contact form, which jurisdiction governs it, and from what date the terms are in effect. This site answers those with analytics yes, cookies no, contact form yes, England and Wales. Get one of those wrong and the privacy notice describes a site that does not exist. Nobody but the operator can confirm them, so nobody but the operator should.
Scope is human too. An owner deciding that the services page matters more than a blog, or that the phone number should be nowhere on the site because the office cannot cover the calls, is making a business decision with a design consequence. The agent implements it. It should not be the one making it.
Voice is a decision, not an output
Every word the platform generates obeys one written style contract: no em-dashes, UK English, answer the question in the first sentence, name the concrete thing instead of gesturing at a category, never invent a price or an accreditation. That file is injected into the generation prompt and then enforced afterwards by a linter that rejects failing text so it is written again rather than quietly shipped.
The enforcement is the interesting half. A prompt is a request; a lint is a rule. Asking a model politely not to write “in today’s fast-moving world” works most of the time, and most of the time is not a standard. Checking the output and throwing it back is a standard.
What the contract cannot do is choose the register. A firm of solicitors and a mobile valeter both deserve good prose, and they do not deserve the same prose. Someone has to decide whether this business sounds formal or plain-spoken, whether it says “clients” or “customers”, whether it is comfortable with a joke. On this site that decision was made in the first blog post, why this blog exists, and everything written since has had to match it.
Publishing, and who is answerable
Going live is one action. The built output in dist/ goes to Cloudflare Pages, the custom domain resolves to the deployment, and HTTPS works with a certificate issued automatically. There is no manual upload, no dragging a folder into an FTP client, no forgotten redirect.
Because publishing is cheap, the discipline has to come from somewhere else. The date shown to readers is bumped when the site changes what it says, not every time it is rebuilt, because a lastmod that moves on every build tells a crawler nothing and gets ignored. That is a human judgement about meaning, applied to a machine-generated file.
The review before publish is where the human input concentrates. Two things are worth reading properly every time: any sentence containing a number, and any sentence containing a promise. Numbers are where fabrication hides, and promises are what the owner has to honour or retract. Layout problems are embarrassing for an afternoon. An invented turnaround time is a complaint.
Where it goes wrong
The main risk is not that the agent produces nonsense. Modern models rarely do, and a template plus a lint plus structured data generated from the page’s own arrays removes most of the ways nonsense used to creep in. The risk is that the agent fills a silence. Leave the brief vague about accreditations, and something reasonable-sounding appears where nothing should. Leave it vague about coverage, and a service area quietly widens.
The fix is unglamorous and it works: say what is true, say what must not be said, and read the numbers and the promises before it goes live. Everything downstream of that, the markup, the meta tags, the sitemap, the certificate, the deploy, is work a machine should be doing, and doing it well is a solved problem now. Deciding what the site claims is not, and it should not be. If you want to talk through where that line would sit for your own site, send us a message and a person will answer.
Frequently asked questions
- Does anyone check the site before it goes live?
- Yes. The build is automated, but publishing is a decision, and the review before it focuses on any sentence containing a number or a promise. Those are the two places where an error costs the owner something real.
- How much detail does the brief need?
- Enough to settle the facts and the boundaries: what the business does, who it serves, which claims can be evidenced, and anything that must not appear. Style and structure can be worked out during the build; facts cannot be guessed.
- What happens if the brief leaves something out?
- The honest answer is that a gap is where a fabrication is most likely to appear, which is why the platform is instructed to write around missing facts rather than invent them. If a price, timescale or accreditation is not supplied, the page says less rather than saying something untrue.
- Can the agent change the site after it is published?
- Yes. Content lives in markdown and JSON files, so an edit is a small change followed by another one-click deploy. The date shown to readers is updated when the meaning of a page changes, not on every rebuild.
- Who is responsible for what the site says?
- The person whose name is on it. The platform builds and publishes, but the claims, prices and legal statements are the operator's, which is why those are the parts a human has to confirm.