Plans Should Ship Like Software

Software teams can tell you exactly what changed between Tuesday's build and Wednesday's, who changed it, why, and which tests ran before it shipped. Most building teams can tell you the sheet got a revision cloud.

I've spent my career between those two worlds. In BIMposter Syndrome I wrote that CAD was a better pencil, not a new language. That was its genius and its limit. We digitized drafting and kept the workflow: file names, memory and a stack of PDFs as the system of record.

Buildings don't need to become software. Their information should ship like it. Versioned, diffed, tested and documented for the person who has to act on it. This essay is about where that analogy earns its keep and where it breaks, because it does break.

A relabel is a recompile

Start with the smallest change there is: renaming a room. Change a room from office to assembly and its shape doesn't move. But occupancy, egress, exits, fire protection and mechanical design can all change underneath it.

My relabel study uses six equal rooms with hypothetical occupancy, ventilation and electrical rates. Relabel one and watch the occupant count, the airflow and the circuits recalculate. The rates are made up on purpose. The dependency isn't.

Try it: click rooms to switch office and assembly, then drag their size, and watch occupants, airflow and electrical load recalculate.

Scale that up and you get a change of use. Convert a warehouse to housing and structure, floor-to-floor, plumbing and egress were all arranged for a different program. Every one of them has to be rechecked. The label is one word. The work is tracing its consequences through the whole specification. A model can expose those dependencies only if its classifications are explicit, and somebody still has to review the result.

The generative engine is a compiler

A generative engine takes high-level inputs, program, site constraints, design rules, and translates them into candidate layouts without asking you to specify every geometric step. That's what a compiler does.

My compiler study packs rectangular modules on three equal floors, deterministically. A room is placed only when a complete slot is available. It doesn't check occupancy, exits, financing or structure, and it says so.

The analogy is useful because it puts the designer in the right seat. The brief is the source code. The layout is one compiled output. If the output fails, the useful question is which input or rule produced it, and which constraint is binding. A good engine makes that path inspectable instead of presenting a candidate as self-explanatory.

I've said it before and I'll keep saying it: AI without constraints produces geometry. AI with constraints produces buildings. And even with constraints, generated layouts can satisfy every encoded rule while missing qualities nobody managed to formalize. The designer still evaluates and refines. In 2018 we ran 120 iterations on one site and came back with a fat stack of data. Somebody still had to read that stack and pick.

An integrated development environment for real estate

Put the loop together and you get an IDE, an integrated development environment. Define the program, check the constraints, generate layouts, inspect the metrics. Program is the input, constraints are the rules, layouts are the output, metrics are the tests.

The value is feedback while the brief is still cheap to change. A parking requirement or a travel-distance check can tell you why a candidate fails during feasibility, not during permitting. My study plots every variation by gross area, so you compare options instead of drawing each one.

The honest boundary: the tool reports only what its rules and data cover. Its output is a design aid. It isn't proof of entitlement, code compliance or construction readiness.

Floor plans are interfaces

A software API declares what it accepts and what it returns. A floor plan does the same job between the building and whatever happens inside it. It organizes rooms and routes, and it has to provide utilities, access and the conditions the use requires. A tenant leasing a space is integrating with that interface.

My interface studies make the contract explicit. One lists what each room accepts and provides, because a room with enough area can still lack the services or access its program needs. Another states a dimensional contract, an 8 ft room, a 3 ft door, a 4 ft corridor, as example requirements, and shows what breaks when one side changes. Those numbers are teaching values, not code.

The payoff is designing for change. A change of use might need different service capacity or access even if the room outline stays put. Clear interfaces show where flexibility is real and where a change reaches into other systems. The metaphor frames those dependencies. It doesn't promise universal flexibility, and anyone selling "flexible space" without that list is selling a word.

Buildings are products, not projects

Software teams ship version 2. Building teams too often start from zero.

A garden-apartment building can be treated as a product a developer repeats, so the next one starts from the last plan, the last details and the last building's operating experience. My product study compares two options on a single row of rooms and one core: repeat a fixed module, or fit the same room count to the site's frontage. Geometry only, no cost or approval claims.

That feedback loop changes what "repeat" means. Keep what worked: unit plans, site organization, delivery knowledge. Revise what didn't work for residents, operations or construction. Every project becomes another iteration of the product. The limit is obvious: sites, markets and codes vary, so the product has to adapt to its place without losing what it learned.

Every layout is a pull request

A layout is a proposed change to a shared design. Like a pull request, it should show what's changing, what it adds or removes and which requirements it addresses. Review the change, not just the new picture.

My diff study keeps it to two rooms at a fixed 16 ft depth with two equal doors, and it counts a review topic only when its dimensions actually change. That's the discipline: a revised arrangement might improve an adjacency while quietly changing circulation, area or coordination. Making those effects visible lets collaborators decide whether to take the change.

Parallel alternatives work the same way. A team can explore two structural approaches, keep each path legible, and go back if the decision changes. My branching study proposes two different wall locations against one baseline. Change both to different values and you get exactly one unresolved field, a merge conflict, which is a better outcome than finding it in the field.

Try it: drag branch A's edge and wall and branch B's depth and wall, and watch the combined plan flag the one conflicting field.

A short change note, what moved and why, ties the record to the design itself. That history beats file names and memory every time.

Version the set

Building documents already have versions. We just don't treat them that way. Permit sets, issued-for-construction documents, addenda and record drawings are stages in one history.

My versioning study takes a 480 SF baseline, 384 SF of rooms and 96 SF of access, and an explicit map of seven dependent artifacts. Change the geometry and the map names what must update. That's the whole idea. When a drawing or spec changes, the team should know what else it touches and what work is already underway.

Construction documents are build artifacts: outputs that translate design intent into coordinated instructions. So ask the build questions. Which version of the model produced this set? Which standards did it use? Which checks ran before issue? Fast-track packages make this sharper, because a foundation package released early has to agree with interfaces that later packages haven't drawn yet.

And here's where the analogy breaks hard. You can roll back a deploy. You can't roll back a pour. Buildings can't be updated without physical work, approvals and site coordination. Versioning fixes the information process. It doesn't remove the cost or risk of changing built work. And a git-like workflow for buildings would need tools that understand building parts and relationships. Ordinary source control can't diff a model meaningfully on its own.

Architecture needs a package manager

Teams solve the same problems over and over: connections, assemblies, wet walls, accessibility conditions. A package manager in software lets you reuse a component while tracking its version and dependencies, instead of copying it without context.

My package study resolves a unit package's wet wall against the plan it's dropped into. Reuse only helps when a component's assumptions are visible. A wall assembly depends on climate, structure, code, materials and installation. You need to know what the component contains, where it's been used and what has to change for this project. A library makes proven work easier to find. It doesn't make it universally right.

Try it: step through dropping unit packages into the host plate and resolving each wet wall against the host's chases.

Docs should read like Stripe's

The best developer docs I know are written for the person who has to act on them: organized around decisions, explicit about versions, with an example for every rule. Architecture docs should read that way.

My spec study writes up one small room as three spec lines, each naming a parameter, its rule, the section it cites and the trade that acts on it. Pin the spec to one edition of the accessibility standard and the room clears its turning circle with space to spare. The door line reads from requirement to installation, and an opening that's too narrow fails on the plan and in the spec line together.

Re-pin the spec to a newer edition and one line changes. The changelog records it, and the same room can come up short. Nothing in the room moved. The edition did.

Try it: switch the spec between editions and between new and existing buildings, and watch the turning circle pass or fail on the plan.

That's version pinning, applied to a spec. Same room, different edition, different answer, with a record of why.

Where this leaves us

Every analogy in this essay has a limit, and I've tried to name each one. Trades aren't microservices. Buildings aren't deploys. A linter isn't a building official. But the habits under those analogies, explicit inputs, visible dependencies, diffs, version pins and docs written for the person doing the work, are some of the cheapest quality improvements this industry still hasn't adopted.

Draw like an architect. Ship like an engineer.

Generate, compare and version your options on a real site. Book a TestFit demo and run this on your own site.