Generative Design...

Nearly every time I demonstrate our product, TestFit, there is a designer that revolts to the very idea that an algorithm can place staircases, units, or fire walls in a building. Well, this technology is here, and it is here to stay.

The AEC world needs to get ready to be in the business of Design Optimization. You know those five phases of the design process we all hear about? PD, SD, DD, CD, CA? Well, in the future there will be a sixth phase. It will be done during every step of the process. DO — Design Optimization — is your newest product.

Optimize for every single thing under the sun: Cost, Energy, Water, Wastewater, Security Systems, Parking Systems, Views, Ease of Construction, Accessibility, Embodied Energy, Return on Investment, Community Impact. The list goes on. If LEED has your head hurting, just wait for design optimization credentials to roll out.

That's the pitch. (The five phases, for anyone outside the trade: predesign, schematic design, design development, construction documents and construction administration.) Here's what the revolt gets wrong, and what the pitch leaves out. The designer in the demo is afraid the algorithm is deciding the design. It isn't. It's deciding the parts of the design that were always rules. And it can't decide the one thing that list above needs most: which goal wins when two of them disagree.

What the Algorithm Decides

Take the three things that set off the revolt. In TestFit, each one is a short list of rules. Stairs: within 50 feet of a dead-end corridor, a stair at least every 250 feet, at least one per building area, one in each corner of the garage. Fire walls: keep each building under an adjustable maximum size, use as few buildings as possible, never put a fire wall in a corner. Units: course them along the building to fill the mass, within limits on width, depth, size and glazing. Those are our product's rules as I laid them out in Let's Face It, Connecting Nodes Sucks, not a code book. They stand in for checks a designer would otherwise redo by hand on every scheme.

None of that is design judgment. It's drafting with a rulebook, and a machine does it faster and more consistently than I ever did with a polyline. Once the rules exist, the software can lay out a scheme in an instant and then do it again with a different input. We ran 120 iterations on one site and came back with a fat stack of data to analyze. Trace paper cannot compare.

The stack is only worth reading if every number in it came from its own plan. In Ultimate Building Metrics I separate assumed usable area (gross area times a share picked in advance, say 87%) from calculated usable area (draw the corridor and the cores, meaning the stair and elevator shafts, subtract them from the floor plate, keep what's left). Put an assumed 87% on 120 options and all 120 tie on usable area. Draw each option's corridors and cores and subtract them, and the options finally differ. That's the second thing generative design actually decides: it calculates, for every option, the numbers you would otherwise have assumed.

What It Leaves to Judgment

Now go back to that list. Cost, energy, views, ease of construction, return on investment: those aren't rules. They're goals, and they pull against each other. The two schemes in Ultimate Building Metrics show how fast that happens. Both put 60,000 sf of floor area on the same 60,000 sf parcel. Scheme A stacks it as three floors of 20,000 sf; Scheme B as four floors of 15,000 sf.

A generator can produce both, measure both and rank both on any score you name. Rank on usable area and A wins. Rank on open ground and B wins. Every row is a calculation; choosing the row is not. Whether those 5,000 sf are a parking count or a lawn is not in the plan, so no score can know. You could hand the generator a parking requirement and let it score the ground, but then someone has already decided the ground is for parking. Someone has to say what the ground is for.

Views and ease of construction are harder, because neither is a number until someone decides how to calculate it from the plan. A "good views" credit with no calculation behind it is an assumed 87% in disguise: every option gets the same credit, so the search learns nothing. And some goals exist mainly to restrain others. Chase floor area per foot of perimeter and the plate drifts toward a circle, which is compact and miserable to build. Ease of construction is the goal that says no. How hard the search should listen to it is a judgment, not a calculation.

So What Is Design Optimization?

It isn't the phase where a computer picks the building. It's the phase where you write down the rules, define how each goal is calculated from the plan, decide how much each one counts, and then read the results asking the questions the rules don't cover. The machine does the search. The designer decides what "best" means and answers for it. That's the newest product I meant: not the optimized scheme, but the definition of optimal.

So here's my answer to the designer in the demo. Let the algorithm place the stairs, the fire walls and the units, and make it show you calculated numbers for every option. Don't let it choose the objective. If you can't say how a goal is calculated from the plan, it isn't ready to be optimized; make that call yourself, out loud, the way I'd build Scheme A because nobody could name what B's extra ground was for.

A note from 2026: TestFit's third major revision of generative design, shipped in version 5.19, generates some 1,500 options the instant any filter adjusts, chasing parking stall yield, and lets any parameter be pinned. The split held. The machine searches; the designer decides what holds still and what counts as better.