A customer describes their business and Giant Context generates a real website from it, grounded in their own materials, editable block by block afterwards. That shipped a month ago and it is the thing the whole project exists to do.
Getting there taught me the most useful thing I know about building with language models.
Every five years or so a startup needs a website and I end up building it. I am a platform engineer. I am not a web designer, I have never been one, and I am comfortably overqualified to be assembling a page builder on top of a decade of plugins. It is the job I most want a machine to take.
The obvious version is one prompt. Describe the business, ask a model for a website, take what comes back. I built that early to see what it gave me, and it gave me what you would expect. Confident, generic copy that reads like every other AI website and says nothing specific about the company.
A single prompt asks for the strategy, the structure, the copy and the styling in one decision. Nothing in the output can depend on anything else in the output, because there is no earlier step for a later step to build on. What comes back is the average of every website the model has read.
What made it work was watching how a competent designer actually builds a site. The human process encodes an order that matters.
Nobody good writes a finished homepage in one pass. They work out what the business is and who it is for. They decide what sections the page needs and in what order, the shape before the words. Then they write the copy for each section, knowing its job. Then they lay it out, style it, and step back to check whether the assembled page holds together.
Each step depends on decisions the previous step made. You cannot write good section copy before you know what the section is for, and you cannot know that before the page has a structure.
So the builder walks that sequence one stage at a time. Strategy. Structure. Section copy. Layout and styling. A review pass over the assembled result. There are more stages than that and the list grows as I find where the process breaks, but the shape is the point. A stage does one job, hands its decisions to the next, and no stage is asked to hold the whole website at once.
The clearest evidence for that came from cutting context. The schema describing every available block ran to 413KB, and the model was generating styles unreliably from it. Stripping the style definitions out of what gets sent took the schema to 52KB, and the output improved. The extra context was not merely expensive, it was causing wasted iterations.
A stage given only what its job requires does that job better than a stage handed everything. Which is the same reason the sequence works at all, arriving from the other direction.
The stages do not design from the model's imagination. They design from the customer's own files.
Before a site is generated, the customer's uploaded materials, their brand documents, their product information, their own writing, have been turned into searchable context. Each stage draws on that as it works, so the strategy is about the actual business, the copy uses their product names, and the claims trace back to their documents rather than being invented.
Generic AI writes about a hypothetical company. This writes about yours, because it read your files first.
Splitting one model call into several breaks the software in new ways.
Style detection runs as its own stage. A small fast model reads the request for global style instructions while the main generation runs, so two model calls are in flight at the same time and their results have to merge in the right order before anything reaches the screen.
A streaming connection stays open while a model thinks, and a connection carrying nothing for thirty seconds gets closed by a proxy in between, so the server sends a heartbeat every few seconds to keep it open. A stage that never returns holds the whole generation open behind it, so a request is capped at 300 seconds and a single model call at 120. The values a stage produces are held in memory rather than written down, so a turn of the loop can lose what an earlier stage decided.
None of those are prompt problems. They are the problems of running several processes at once and getting their results back in one piece, and one of those processes is a language model that takes minutes and sometimes returns nothing.
A single prompt has none of this. One call, one answer or one error. Giving that up buys the quality described above and costs a system that can fail halfway through and lose its place. Making a generation survive a failure and pick up where it stopped is the work in front of me.
To build an agentic pipeline for a task, you have to understand the task well enough to describe its process.
I wanted a machine autonomous enough to do the job I did not want to do myself. That did not excuse me from having the expertise. To build the pipeline that designs websites I had to learn how good web design proceeds, what comes before what, why strategy precedes structure and structure precedes copy. A process I cannot describe is a process I cannot automate, so building the autonomous version forced me to understand the thing I was trying to avoid doing by hand. The expertise moved from doing the task to modelling it, and modelling it demands understanding it deeply.
That holds past websites. Point a pipeline at customer support, legal review, financial analysis, and the hard part is never the model. It is whether you understand the discipline well enough to break it into the ordered steps an expert actually follows.
So when you want a language model to do a large creative job, do not write a bigger prompt. Learn the process a competent person follows, break it into stages where each does one job and hands its work to the next, and make the model produce structure instead of prose.
Remote, Pacific time, full-time or contract. Get in touch.