Practice
Building a website with AI in 2026: the workflow that actually holds up
Coding agents are good enough to build real sites now. The skill is not prompting — it is supervising a loop, and knowing where to stop trusting.
In short
The most reliable way to build a website with AI in 2026 is to treat the model as an agent inside a supervised loop — observe, plan, act, evaluate — rather than as a one-shot code generator. You keep ownership of architecture, secrets, and verification, and let the agent handle the repetitive implementation. The limiting factor is your ability to verify output, not the quality of the prompts.
There is a version of this advice that is already obsolete: prompt a model, receive a page, deploy it. That produced beautiful demos and unmaintainable repos. What works now is less glamorous and much more durable.
The loop is the unit of work
Every serious coding agent runs the same internal cycle: inspect the repository, decide what to do, edit or run something, read the result, then decide again. Once you understand that shape, you stop treating the model as an oracle and start supervising it.
- Observe — let it read the real files, not your summary of them.
- Plan — ask for the plan before the code. A wrong plan executed confidently is more expensive than no code.
- Act — one bounded change at a time, so a regression is attributable.
- Evaluate — run the build, the tests, the type checker. Then look at it yourself.
Where agents genuinely win
Boilerplate, type definitions, repetitive refactors, and — underrated — writing the tests you were avoiding. Also the unglamorous half of any project: the config file nobody wants to touch.
Where they still need you
- Architecture that will survive its own first rewrite.
- Anything involving secrets, billing, or a public URL.
- Judgment calls about taste — what a page should feel like.
- Deciding what to delete. Agents add; a good codebase needs subtraction.
A model will happily rewrite working code to satisfy a request that did not need touching. Knowing when to say "stop, revert that" is the job.
Keep the secrets out of the client, always
This is the failure I hit while building the concierge on this very site. I wanted a chat widget backed by a real model. The naive version puts an API key in client code, which means shipping a working credential to every visitor in the JavaScript bundle — where it is readable by anyone who opens devtools.
The fix is architectural, not stylistic: put a server or edge function between the browser and the provider, read the key from the environment at request time, and never let it into the bundle. On a fully static site the edge function is the server boundary that otherwise does not exist.
What I would tell my past self
- Set up the loop before writing any feature.
- Get verification running first: build, typecheck, one real browser check.
- Decide the secret-handling story before you need the API key, not after.
- Keep your design system intact. An agent will happily ship a generic component that fights what you already built.
Building has gotten genuinely easy. Verification, taste, and shipping have not. Those are still the parts that are yours.
More Keep reading
Field note · 2 minStatic sites, edge functions, and the secret that almost shipped
A `.gitignore` is not a security model. Here is what actually keeps an API key off a public website, and the mistake that taught me.
Explainer · 2 minSEO when there is no click: being the source AI answers with
Answer engines synthesise instead of linking. What that rewards instead of keywords — and what quietly stopped working.