The builder turns a customer's prompt and their uploaded materials into a finished marketing page, laid out and written and styled, in a sequence of steps. Each step is a model call with a narrow job, because a single prompt cannot do the whole thing. For a few weeks in early April, that sequence produced pages that were wrong in a way no test could catch.

Two of the jobs in that sequence are easy to confuse, and the confusion is the whole problem. One job is deciding what the page should be made of, the claims it makes, the proof it offers, the things it asks a visitor to do. A different job is deciding how those pieces are arranged, which ones become sections, what order they run in, how the columns divide. On a whiteboard the two are obviously separate. In a chain of model calls they overlap, because every call is capable enough to do a little of both, and the natural way to build the chain is to let each step improve the result as it passes through. So the step meant to decide contents also sketches a layout, and the step meant to arrange the layout also adds or drops a section it has decided the page needs. Each change looks like an improvement on its own. What has actually happened is that two different steps have each decided the structure of the page, from their own view of it, and the two structures do not match.

In ordinary code, an overlap like that usually announces itself. Two functions that both set the same field collide, a type complains or a test fails, and you find the exact place they disagreed. Model calls do not collide. Each one returns a complete, valid result and hands it on. The step that arranges the page returns a perfectly good arrangement, and it has done nothing wrong. It did the job it was given. It just had no way to know the page it was handed was already shaped by an earlier step that thought that same job was its own. Nothing between them checks whether the two agree, so no error fires. The page comes out as a mix of two structures that were never reconciled, and that mix has no structure of its own. From the outside it looks like the model being unreliable. The real problem is that two steps were allowed to answer the same question, and no one was put in charge of the answer.

So I split the two jobs between the two steps and let neither reach into the other.

The first step, the one that reads the customer's materials, I call the content step. It used to do both jobs at once. It decided what the page should say and, in the same pass, roughed out how those parts should be arranged. I cut it back to the first job. It now produces one thing, a plain list of what the page should contain, the testimonials it can draw on, the pricing it should show, the features and process steps and questions it should answer. That list says nothing about layout. I call the list the inventory, and there is nothing in it to arrange, because it records what the page is made of and not how the page is built.

The second step lays the page out, and I call it the designer. It became the only place any arranging happens. It takes the inventory and decides the actual page, which items become sections, in what order, how the columns divide, which parts are given weight. Every structural decision is now the designer's to make. The content step can no longer overrule those decisions, because the content step no longer makes any. It produces a list, and turning that list into a page is the designer's job alone.

One stage answers what. The next answers how. Neither can answer both.

The immediate return is pages that hold together, which is not a small matter when the product is a website builder and structural incoherence is a common reason an AI-built site reads as untrustworthy. A customer forgives a plain page. They do not forgive one that argues with itself.

The larger return shows up when something goes wrong. Before the split, a wrong page was almost impossible to debug. Both steps had shaped its structure, so there was no way to point to the one that got it wrong. All you could say was that the model had produced something incoherent, which is not a complaint you can act on. Now the two jobs live in different steps with a typed handoff between them, so a wrong page can be traced to the step that caused it. If the content is right and the layout is wrong, the fault is in the designer, so I fix the designer and leave the content step alone.

There is a familiar name for half of this. Splitting a system so each piece has one job, so you can change that piece without breaking the others, is separation of concerns, and every engineer trusts it to keep a codebase manageable as it grows. The other half is what got separated. These two jobs are not two pieces of code. They are two kinds of judgment, deciding what a page should say and deciding how it should look, the work of an editor and the work of a designer. Because it is a separation of concerns, it behaves like one. I can change how a page looks without touching what it says, and change what it says without breaking how it looks. Either side can grow on its own. We have always known how to do this with code. Doing it with the decisions a model makes is the new part.

It also made the builder safe to grow. A new kind of content, a comparison table, a logo strip, is one more entry in the inventory and one more item the designer knows how to place. Adding it does not touch the stage that decides what a page needs, and it does not touch the authority over layout. The two questions stayed two questions as the builder took on more of them, which is why the range of pages it can build has climbed without the pipeline losing the separation it started from.