TestFit, Generative Design, and AI

The first line of code that would eventually become TestFit was written in C++ in 2016. After contemplating the problem of generating a building with parking + life safety + massing + circulation + unit mix + kit of parts + leasing office — so many different kinds of criteria — we chose to build our codebase in C. This would enable the most amount of math to happen the fastest, closest to the user. This forced us to generate quality buildings and make it an incredibly interactive experience. In 2017, Generate locally → Edit locally became our goal. Generate means the software lays out a complete scheme; edit means you grab that scheme and change it by hand; locally means on your own computer, fast enough that the two can trade places all day.

At this time there was a rise of cloud compute — users could compile Dynamo scripts and solve them in Refinery for multi-variable optimization. (Dynamo is Autodesk’s visual-scripting tool for Revit; Refinery was Autodesk’s tool for running those scripts across many combinations of inputs and comparing the results.) For me, though, living in the real estate world, the use cases felt design-exploration heavy: shape a tower based on the sun, or move nine towers around a large site to optimize for views. Both impressive, but missing the mark for an apartment community designer. What was needed was a much larger universe of geometries that could be solved for and then optimized against.

In 2024 it felt like every design tool in AEC (architecture, engineering and construction) got an “AI” sticker, and the sticker hides two different machines. One is a large language model, an LLM: the kind behind the chatbots, which learns patterns from an enormous pile of examples and produces whatever looks likely. The other is what TestFit has been building since 2016: procedural code that can only draw the buildings its rules allow, plus a search that runs that code thousands of times and keeps the schemes that hit your numbers. For an apartment site, “looks likely” isn’t the bar. The scheme has to park, exit and make its unit count. In January I put it this way on LinkedIn: “The world is very bullish on ‘AI’ right now. The building design industry forgot about generative design.” This post is about the second machine.

Note on timing (October 2026 edit): this post went up on May 17, 2024, less than eight weeks before TestFit Generative Design shipped in version 5.0 on July 10, 2024. Read the lists below as a pre-launch inventory. The dated record of what had actually shipped follows them.

The TestFit Language Model

The name is half a joke and half a claim. It isn’t a neural network. It’s the vocabulary of building types TestFit can generate, plus the rules that make each one valid: where the stairs go, how wide the corridors run, how the parking ramps. An LLM learns its vocabulary from data. Ours was written by hand, one typology at a time, starting with the stair, fire-wall and unit rules I described in 2018.

Since there is not currently any kind of massive structured dataset for, say, Texas Donuts (the mid-rise apartment ring built around a courtyard or a parking garage) to be drawn from an LLM, we have created procedural logic to solve just that — a Texas Donut, and many more building types. Our market coverage in the US includes:

• High Density Multifamily / Hotel: Tower, Podium, Wrap, Donut, and Gurban (urban mixed-use: apartments over ground-floor retail, with the parking built in) configurations
• Low Density Multifamily / Hotel: Garden Apartments, Townhomes, Single Family Rentals, Villas
• Industrial Warehouses: Cross-dock, Single loaded
• Parking: Surface, Structured, Prefab
• Office: Spec Office
• Retail: Surface Parked Pad Sites
• Data Centers: In Alpha
• Everything else: Manual Massing Mode

Our goal for our users, in light of the AI revolution, is to open up the TestFit Language Model to be generated upon, explored, optimized, filtered, and ultimately to supercharge the Generate portion of the Generate → Edit feedback loop. The model also encompasses:

• Site Definitions: Metes and Bounds (the surveyor’s bearings-and-distances description of a lot line); Setback Dimensions; Setback Profiles (form-based setbacks)
• Topography: Cut and Fill Severity and Footprint Level Cut and Fill (how much earth has to come out, or go in, to set each building on level ground)
• Data: Available FEMA and flood zone data

What had shipped, and what was a promise

Note on the record (October 2026 edit): the lists above mix three tenses: things that had shipped, things still in testing, and a goal. TestFit’s release record, which dates each feature’s first release from November 2017 to March 2026, pulls them apart.

So on the day I wrote this, the vocabulary was real and the search on top of it was less than eight weeks out. After launch, version 5.2 on September 25, 2024 added unit-mix and parking-mix goals and filters built automatically from live zoning data; preset filtering followed in October and cut-and-fill filters in December. Nine later releases in the record improved Generative Design, the latest in March 2026. The LLM part isn’t in it.

What “generative” means here

Even our own release record files Generative Design as “AI layout optimization,” so let me be specific. On launch day I described it like this: “saved presets are used as a custom seed to generate thousands of schemes automatically.” A preset is a saved set of building parameters, something TestFit had supported since version 1.0 in April 2018. A seed is the starting point the solver varies. The machine takes configurations a person already trusts, varies them across the site, draws every variation with the same typology rules as a scheme you’d solve by hand, and lets you filter the results against your goals. Nothing in that loop predicts a building from examples. It searches a space the rules already fenced in.

The closest it came to learning from data shipped that October: a firm could let Generative Design seed new sites from every deal saved in its TestFit workspace. That’s data, but it’s the firm’s own past schemes used as starting points, not a model trained on them.

Four days after this post I tried the unreleased tool and asked for, verbatim, “320 units @ 875 average with a 1.73 parking ratio and a minimum building efficiency of 82%.” It returned five schemes I hadn’t considered. Every term in that request is something the procedural model already counts. Parking ratio is stalls per unit: 320 × 1.73 = 553.6, so 554 stalls, because nobody builds 0.6 of a stall. Building efficiency is unit area divided by gross building area. Reading 875 as the average unit size in square feet, 320 × 875 = 280,000 sf of units, and at 82% or better the gross building can’t exceed 280,000 ÷ 0.82 ≈ 341,500 sf. A model that draws what looks likely can’t promise any of those numbers. A generator that counts them can filter on them.

It’s also narrower than what I predicted in 2018, in my first post on generative design, where design optimization would become a sixth phase of practice and optimize for everything from cost and energy to community impact. What shipped six years later optimizes for what the model can count: units, unit mix, parking, zoning controls and, by December 2024, earthwork. Energy and community impact aren’t among its goals in the record.

The judgment

The constraint engine — the thing that makes a TestFit building actually buildable — is what separates a generative design tool from a useful one. AI without constraints produces geometry. AI with constraints produces buildings. That distinction is the whole game.

Here’s where I land, with two years of hindsight. The search was the headline, and it shipped less than eight weeks after this post. The vocabulary under it, every typology written down as rules, is the part we’ve been building since 2016, and it decides what the search can find. So when a design tool says AI, ask what its generator can draw and what it refuses to draw. If the answer to the second question is “nothing,” you’re buying geometry.