Generative building design with AI: where the process breaks
Manual iteration of planning solutions hits arithmetic: during the time allotted for concept, the team manages 4–6 variants, and chooses among them by subjective "like / dislike", not by metrics — usable area, insolation, structural frame cost.
The remaining configurations are simply not considered, although the best compromise between economics and regulations most often lies precisely among them.
Automation of variant development without constraints has the opposite effect.
The generator produces hundreds of layouts, but without explicitly set boundaries — building footprint, structural grid spacing, engineering services zones — most of them are irrelevant and are still filtered manually. Speed of generation does not turn into speed of decision-making.
The second source of failure is divergence with related disciplines.
A layout that has passed area checks diverges from load-bearing structures, ventilation shafts and routes, because this is checked at the next stage, when changing the space-planning solution is already expensive. Edits come in waves, and each one returns the project to the start of approval.
Generative building design with AI works not when it draws fast, but when it can discard the inadmissible: norms and links with related disciplines are set as model constraints, not as a check at the end. We break down how this is closed.
What changes in the office's work: speed of variants and checks
The generative loop works not with one concept, but with a field of variants defined by site constraints: building footprint, number of floors, areas, insolation, structural grid spacing.
Overnight, 20–40 variants are calculated with metrics for each, and 3–4 developed solutions go to review instead of one.
The cycle "edit — recalculate — check" is reduced from weeks to hours.
Changing height no longer entails rebuilding plans, sections and schedules — everything is calculated from a single parametric model, and the number of iterations until an agreed variant drops severalfold.
Exchange with related disciplines goes through IFC, so the model is not rebuilt for each participant's tool.
Collisions are caught on the model, not on site: intersections of engineering networks with load-bearing structures, mismatched elevations, insufficient ceiling height, inadmissible passages.
These classes of failures are most expensive to fix after documentation release — and they are closed before the drawing goes to construction.
Compliance checking becomes part of recalculation rather than a separate stage: formalized rules — fire access roads, evacuation routes, insolation, maximum areas — are run for each variant with a report showing exactly where it is violated. The expert makes the decision but stops searching for violations manually.
Solution search modes: comparison of approaches and constraints
Solution search modes differ in where the admissible boundary lies and who controls it: the algorithm exploring the variant space, or the engineer setting the rules.
Free search assembles layouts and forms from a training set — it finds non-obvious configurations but does not distinguish "unusual" from "inadmissible."
Search by hard constraints works conversely: the space is clipped by norms, site regulations and technological requirements before generation. Fewer variants, but each one passes a formal check, and the result is reproducible with the same input data.
| Mode | When suitable | Where it hits limits |
|---|---|---|
| Free search | Early stages, concept search, boundaries not yet fixed | Many unfeasible variants, manual checking of each draft |
| Hard-constraint search | Typical objects, dense development, strict regulations | Narrowed solution space, non-standard moves are lost |
| Hybrid mode | Working design: need both variability and compliance | Requires structured rules and a configured data model |
Hybrid mode combines both approaches: the generative part proposes drafts, hard constraints cut off the inadmissible, and solution quality criteria sort the remainder.
The choice of mode is dictated not by taste but by the readiness of input data — completeness of the parametric model, availability of machine-readable checks, freedom of planning solutions per the brief.
Solution quality criteria are set in advance and measurably: share of variants that passed checks, robustness to edits in input parameters, time to first suitable variant, labor intensity of bringing it to working documentation. If these metrics are not fixed, comparison of modes becomes an argument about tastes.
Implementation stages: from rules audit to system handover
Generative building design starts not with the model, but with the rules by which the office makes decisions. While these rules live in the experience of two or three lead engineers, the system will produce an average variant instead of a project-specific one.
Therefore the work order is built so that rules are first captured from practice and only then fixed in code.
-
Design rules audit — collect regulatory requirements, typical solutions and internal office constraints: site placement, number of floors, insolation, fire gaps, structural schemes.
Review 15–20 past projects: which decisions were made immediately, what was redone and at what stage.
-
Formalization and system design — turn rules into checkable conditions, and agree the result with the chief architect. On the diagram, record what data goes to input, where variants are calculated and at what point a person confirms the choice.
-
Configuration for the office — the system is configured to your templates, element families, section composition and output formats. The output is variants in a familiar structure, not abstract diagrams that need redrawing.
-
On-project validation — take a real project and run both paths: manual and through the system. Compare layouts, material consumption, number of reworks, time to first agreed variant.
-
Refinement based on comments — discuss discrepancies with designers and refine rules or interface. The cycle repeats until the engineer stops returning the task for reassembly.
-
System handover — documentation, operating procedure, training for designers and the support owner. After handover, the office can change rules and add typical solutions independently.
Each stage ends with a verifiable result, so you can stop at any step and get a working fragment, not a draft.
Configurations, rules and regulations: what remains with the office
A generative design system is valuable not in itself but because the office can change its behavior without a developer.
Therefore at stage closure we hand over not "access to the service" but a full set of artifacts by which the team reproduces any result and edits rules with its own hands.
- System configuration — generation settings files: variant parameters, constraint weights, mapping of rule sets to object types, profiles for different design stages.
- Description of rules and constraints — what the system considers admissible, what it discards and why; each constraint with a reference to a clause of norms or the office's internal standard.
- Solution templates — typical scenarios (sections, parking, public blocks) with ready setting sets, so a new project starts from a proven configuration, not from scratch.
- Team workflow procedure — who approves the variant at which step, how deviation from the typical solution is recorded, at what point the chief project engineer joins.
- Documentation and instructions — deployment, roles and access, model update procedure, troubleshooting typical failures with ready actions.
- Configuration change log and rollback procedure — visible who changed a rule and when, and there is a place to return if the new set causes degradation in variant quality.
- Acceptance task set — reference input data with expected result: after any rule edit, the run shows whether related scenarios were broken.
We verify these artifacts on a live office task together with your engineers: they change a rule themselves, run the acceptance set and confirm that the system responds predictably.
This way the project stops depending on the contractor — what remains is a working tool with clear documentation.
Case: layout variability grew severalfold in one cycle
Starting point
12-storey residential building: layouts were born manually — the team managed to calculate 2-3 configuration variants, each took 8-10 working days.
Geometry, areas, insolation and evacuation routes were calculated in different files and consolidated manually, so comparison was based on the latest edit, not on a metric set. Disputed decisions remained disputed, and layout variability hit the designer resource.
What was changed and what was achieved
We assembled a generative model: site parameters and regulatory constraints at input, layout rules in the core, export to the working environment through Autodesk Revit at output.
The generator iterates layouts and calculates areas, efficiency coefficient and constraints itself, cutting off the nonviable before showing it to the engineer.
Metrics before and after: 2-3 variants in 8-10 days versus 40-60 variants in a 4-6 hour cycle; initial evaluation of one variant reduced from 3-4 hours to 5-7 minutes; the share of configurations passing regulatory checks on the first run grew from about one third to 85%. The engineer reviews not everything but 5-8 finalists sorted by the objective function.
The decision on the section was made on the second day instead of two weeks, and reviews during approval halved: disputes were closed by comparing metrics.
Generative building design here works not instead of the architect but as an expansion of the search space, where the choice remains with the human.
What to do if the office already has a base of typical solutions?
There is no universal answer: the choice between refining the existing base and a new system is determined not by the volume of the existing base but by whether it is suitable as a data source.
If typical solutions are stored as ready drawings, blocks can be inserted from them, but variants cannot be generated — generation needs a parametric description, not a picture.
Therefore we start with an inventory: what is stored, whether geometry, nodes and text parts are linked, whether solutions repeat from project to project.
On a sample of several dozen objects, it is visible whether the result is reproducible from a set of input conditions — this is the selection criterion.
| Scenario | When suitable | Limitations |
|---|---|---|
| Refining the existing base | solutions are already parameterized, there are unified templates and documentation rules | ceiling on number of variants, inherited errors transfer into new projects |
| System alongside | the base is heterogeneous or non-parametric, and the current process cannot be broken | accumulated experience is inherited partially, reference data synchronization needed |
| Hybrid | the base is large, but section quality varies: take the structural frame from it, build engineering anew | integration is more complex, an explicit data model owner is needed |
The choice between these paths is a choice between speed of the first result and the development ceiling. Refinement gives an effect quickly but preserves the structural limitations of the base.
A new system removes them, but requires time for transferring reference data and training designers.
In practice, the hybrid path more often wins: proven sections remain as is, while variant generation and compliance checking are built as a separate layer above them. Describe how your base is structured — we will return with an assessment and transition plan.
Technical concerns: data, norms, responsibility
Objections to generative building design usually concern not the model itself but what surrounds it: quality of input data, regulatory constraints, integration into the current process and the area of responsibility for the released result. We review each before start — it is at this stage that projects most often stop.
Will input data quality be sufficient?
The model inherits all defects of the input: different coordinate systems, overlaps and gaps in contours, outdated drawing revisions. Before work, we audit the array — bring geometry to a unified coordinate system and units, verify room topology against measurements.
At output we obtain the share of rooms suitable for generation: it shows where a variant is produced immediately and where manual refinement is needed.
How are regulatory constraints accounted for?
Checkable requirements — evacuation routes, fire gaps, minimum areas, insolation — live not in the model but in a separate rules reference above generation. A variant violating a rule is discarded before being shown to the designer, not after expert review. When the norms edition changes, the reference is updated — retraining is not required.
How does this integrate into the current process?
The generator does not replace the established workflow but connects to it: exchange through open formats, revision and version support, export into the environment where the designer already works. The result arrives as a variant for checking and refinement, not as a final document.
Who is responsible for the result?
We separate responsibility explicitly: we are responsible for the correctness of rules, reproducibility of generation and data integrity; the design organization — for the adopted decision and signature. Each variant preserves history: input data, rule version, run parameters. From it, one can see why exactly this result was obtained and what needs to change to get another.
Let's discuss the task on your input data
To make the task assessment rely on your data, not on average assumptions, we start with a review of input data.
Send what you already have: models or IFC exchange files, layouts and site plan, current regulations and technical assignment, examples of adopted decisions on past objects.
If part of the data is closed, say so immediately — we will find a replacement and mark assumptions directly in the plan.
- Data review — check completeness of models, unified units of measurement, correctness of attributes and relationships between elements.
- Objective function — fix what we optimize: configuration, insolation, material consumption or several criteria with weights.
- Rules into checkable conditions — convert norms and your internal requirements into constraints that the system applies automatically.
- Integration scheme — at what stage the generative loop connects to the current process, where variants are stored and who makes the decision.
- Implementation plan — stages with the result of each: pilot object, validation on historical projects, expansion to typical scenarios.
- Work order and roles — what we do, what is required from architects and engineers, in what form and when we hand over the result.
- Task assessment — we return with team composition, timelines, risks and assumptions, not with a single number without explanation.
Describe the task in free form and attach materials — even drafts are fine. We will return with an assessment and work plan.
