Generating layouts that respect a grid
Generated layouts drift because spacing, column counts and breakpoints are conventions the model has to infer. Stating the grid explicitly, constraining spacing to a named scale and giving one correct example of a comparable layout removes most of the drift.
The recognisable signature of a generated layout is not a glaring error. It is a section with a 22-pixel gap where everything else uses 24, a two-column split that is not quite the grid, a heading with slightly more air above it than its neighbours.
Nothing is wrong enough to name. The page just feels slightly assembled by someone who was not looking at the other pages.
The grid is implicit, so state it
Your grid lives in a container component, a breakpoint config and a shared understanding among the team. None of that arrives with a request to build a section.
Writing it out costs four lines: the container width, the column count, the gutter, the breakpoints and what changes at each. It is unglamorous and it removes most of the drift.
Say which component owns the padding
A large share of layout bugs, generated or not, come from two elements both trying to own horizontal padding. Stating that the page container owns it and sections must not add their own is one sentence that prevents a recurring problem.
Make arbitrary values impossible
If spacing comes from a named scale and raw values are rejected by a lint rule, 18px cannot appear. The model picks a step because steps are all there are.
This is the same principle as tokens, applied to rhythm. The constraint does the work that review would otherwise have to.
Show one good example
A correct existing section — real markup, real class names, real structure — communicates your conventions more precisely than any description of them. It carries the nesting, the naming and the spacing decisions all at once, including the ones nobody wrote down.
Pick an example close in shape to what you are asking for. A two-column feature block teaches a two-column feature block; a hero does not.
Verify mechanically
Eyes are poor at catching a six-pixel inconsistency and good at catching it three weeks later in production. A check that scans generated markup for off-scale values, unknown class names or components used outside their allowed context catches it immediately.
Generation is fast enough that the bottleneck moves to review. Automate the part of review that is mechanical, and spend the human attention on whether the layout is any good.
Frequently asked questions
Why does the output look right but feel off?
Usually near-miss spacing — 18px where the scale says 16, a gutter that is close but not equal. Individually invisible, collectively the reason a page feels unfinished. Constraining to a closed scale removes the whole class.
Should I generate markup or a layout description?
Generate markup that uses your components, and check it. A layout description has to be translated by someone anyway, and the translation is where the grid gets lost.
