Generative Layouts & Planning

Under the hood, most generative planning is an optimisation problem, and it has two ingredients you must supply. Constraints are the hard rules a valid layout cannot break: a required schedule of areas, minimum room sizes, adjacencies (kitchen next to dining, cores within reach), circulation widths, setbacks, and code limits. Objectives are what you want to maximise or minimise: usable-area efficiency, daylight, saleable unit yield, view quality, construction cost, walking distances. The tool then searches the solution space - the vast set of arrangements that satisfy the constraints - looking for ones that score well on the objectives.

The catch is that objectives usually conflict. More units may mean worse daylight; more efficiency may mean duller circulation. So good tools do not return one answer; they return a set of options along a Pareto front - the frontier where you cannot improve one objective without sacrificing another. Reading that frontier is a design act: it externalises the tradeoffs you would otherwise juggle in your head and lets you choose a position on them deliberately. This is the real gift of generative planning - not automation, but a fast, legible map of what is possible and what it costs.

It helps to notice how different this is from how designers usually work. Left to ourselves, we tend to develop one or two schemes deeply and defend them; the solver develops hundreds shallowly and stays neutral. Each mode has a blind spot - the human risks anchoring too early on a favourite, the machine risks optimising a narrow definition of 'good' - and the productive move is to use them against each other. Let the tool flood you with the breadth you would never explore by hand, then bring the depth, taste and context that it structurally cannot. Seen this way, generative planning is less a replacement for space planning and more a very fast, very literal-minded collaborator whose output you must always translate back into architecture.

The tools split into two families that behave very differently, and confusing them is a common mistake. The rule-and-optimisation family is deterministic and explainable. It builds layouts from encoded logic and searches with algorithms - evolutionary solvers, packing heuristics - so its dimensions are real and you can trace why an option scored as it did. This family dominates practice: TestFit for building and site feasibility (massing, unit mix, parking), Finch and Hypar for rule-based floor plans, Autodesk's generative design (Refinery / Dynamo) for custom problems, and Forma for residential unit studies. These are the tools you can put a real feasibility number behind.

The learned / diffusion family generates plan images from patterns learned across many drawings - the same technology as image generation, pointed at floor plans. It is wonderful for variety and mood and hopeless for metrics: the dimensions in a diffusion-generated plan are not real, walls do not close, and areas are decorative. In 2026 this family is research-grade for real projects. Treat its output as inspiration to redraw, never as a plan to build. The practical rule: know which family you are holding. One gives you numbers you can defend; the other gives you sketches you must verify from scratch.

The reason the distinction trips people up is that the two can look identical on screen. A diffusion plan renders with the same line weights and room labels as a computed one, so nothing on the surface warns you that its 3.2-metre bedroom is a decorative accident rather than a measured decision. This is where a lot of well-meaning enthusiasm goes wrong: someone screenshots an impressive AI plan, quotes its areas in a meeting, and only later discovers the numbers were never real. The safeguard is a habit, not a feature - always ask of any generated plan, 'was this computed from rules or drawn from patterns?' If computed, you can interrogate the metrics; if drawn, you extract the idea and rebuild it properly before a single dimension is trusted.

Generative planning pays off most on well-defined, repetitive problems, because those are the ones you can honestly encode. Residential unit layouts and mixes, office floor-plate efficiency, hotel-room stacking, parking geometry, hospital or lab modules, and early site-massing feasibility all have measurable objectives and clear rules - exactly the diet these solvers thrive on. On a housing scheme, exploring unit-mix and yield options that would take a team a week can take an afternoon, and you arrive at the client conversation with the tradeoffs already mapped.

Where it struggles is anywhere the value lives in things you cannot easily encode: the experiential, cultural, contextual and phenomenological qualities that make architecture more than packing. A solver has no notion of arrival, of how light moves through a day, of what a threshold means, of the specific life a family will live in a home - unless you reduce those to a proxy, and the proxy is always lossy. It will also cheerfully exploit gaps: forget to constrain something and it will produce a technically optimal, practically absurd plan. So generative planning is a superb feasibility and options engine and a poor final-design engine. Use it to widen and inform the decision; keep the decision, and the qualities no metric captures, yours.

Context sharpens this further. A layout that is optimal in the abstract can be wrong for a particular place - a plan that maximises daylight in a temperate climate may bake interiors in a hot-dry Indian town, where the encoded objective should perhaps have been controlled light and cross-ventilation instead. Local codes, plot idiosyncrasies, cultural norms about privacy and gathering, and even the way a market values certain unit types all sit outside the solver unless you deliberately encode them - and many of them resist encoding at all. This is not an argument against the tools; it is an argument for using them with your eyes open. The solver handles the combinatorial heavy lifting; you supply the situated judgement that decides whether an efficient plan is actually a good one for this place, these people, this brief.

Because the tool optimises what you tell it, the two skills that decide whether generative planning helps are framing the problem and curating the output. These are worth naming as skills, because neither comes automatically and both are learnable - and both are firmly the designer's job, not the software's. Framing is where architectural knowledge enters the loop: knowing which adjacencies actually matter, what a sensible corridor width is, how to turn a vague ambition like 'good daylight' into a measurable objective without flattening it. Curating is where taste and responsibility enter: the solver ranks, but only you can weigh a numerically inferior option that is simply better to inhabit.

Framing means being explicit and complete about constraints and honest about objectives - and stress-testing your own inputs, because the failure mode is silent: a wrong minimum, a missing adjacency, an objective you weighted too heavily, and you get plausible, well-ranked, wrong plans. A compact way to write a brief for a solver:

Program:     48 units - 40% 1BHK, 45% 2BHK, 15% 3BHK
Hard rules:  6m setback all sides, 2 cores, corridor >= 1.5m,
             every unit gets >= 1 openable external window
Maximise:    saleable area, units with morning daylight
Minimise:    corridor area, north-facing single-aspect units

Curating means treating the returned set as an editor treats submissions: read the Pareto front, understand each tradeoff, pull the two or three options worth developing, and combine or override where your judgement sees what the numbers missed. Never ship the top-ranked option just because it ranked top - the ranking only reflects the objectives you happened to encode. A quick numeric read of a returned option set helps you see the shape of the tradeoff before you dive into drawings:

# rank options by a weighted blend of normalised objectives
def score(o, w):
    return w["yield"]*o["yield"] + w["daylight"]*o["daylight"] \
         - w["cost"]*o["cost"]
# you choose the weights - that choice is a design decision, not the tool's

The weights are yours; own them, and the tool becomes an amplifier of judgement rather than a replacement for it. A final habit worth keeping: record why you chose the option you did, in a line or two, because that reasoning - not the solver's score - is what you will defend to a client, a planner, or your future self.