WeeklyDynamo: Generative Design and Dynamo for AEC

At Autodesk University 2025 I had about three minutes. The segment sits at 27:30 inside Sol Amour's session Exploring the Dynamo Product Road Map and Vision for the Future , which runs 46:30 in total, and the subject was water treatment plant layout generated with Generative Design. Three minutes is a reasonable amount of time to demonstrate that something works. It is nowhere near enough time to show another engineer how to rebuild it. This month the same material had to become a twelve-hour course, delivered over two days to practising engineers at a public-sector training academy. Expanding a three-minute demo by a factor of two hundred and forty sounded absurd when I first wrote the number down, and then I built the curriculum and discovered that the ratio was never the interesting part. A demo and a course are not the same content played at different speeds. They are largely different content, and the portions that survive the translation are not the portions I would have ...

  Part 9 of a series — a Dynamo tunnel geometry that was already finished, a 39-sheet Excel workbook it had never been wired to, the web viewer built to referee the two, and the Revit add-in at the end of it. When the work stopped, it had left 149 GB of snapshots on a desktop drive. The obvious next task was to delete them. This post is about what happened when I tried to establish that deleting them was safe — which turned out to be a longer job than the deletion, and ended with a different answer than the one I started with.

 Part 7 of a series — a Dynamo tunnel geometry that was already finished, a 39-sheet Excel workbook it had never been wired to, the web viewer built to referee the two, and the Revit add-in at the end of it. Over eleven days, on a single tunnel section, the transcript logged 106 turns from my side to an AI coding assistant. It wrote thousands of lines of Python and JavaScript in response. But when I went back and read the whole thing, what surprised me was not the code. It was that only 17 of those 106 turns actually asked for a shape. The other 89 were corrections, rejections, questions, requests to see the screen, one long apology for having said the wrong thing — and five that I never typed at all, which section 2 accounts for. The honest count of instructions I actually sent is 101.

  Part 6 of a series — a Dynamo tunnel geometry that was already finished, a 39-sheet Excel workbook it had never been wired to, the web viewer built to referee the two, and the Revit add-in at the end of it. For six weeks the web viewer said the geometry was fine. Then the same polylines went into a Revit add-in and three of the bands would not build at all. This is the last stretch: an add-in, thirteen versions in one afternoon, and a root cause that only appeared once I stopped looking at screenshots.

  Part 5 of a series — a Dynamo tunnel geometry that was already finished, a 39-sheet Excel workbook it had never been wired to, the web viewer built to referee the two, and the Revit add-in at the end of it. By the middle of the project the instructions stopped sounding like design work. They stopped being "build the tunnel section" and became "this part, this property, this authority." That shift is what let a pixel-level gate exist at all — and the gate then spent most of its life proving that its own failures were not what they looked like.

  Part 4 of a series — a Dynamo tunnel geometry that was already finished, a 39-sheet Excel workbook it had never been wired to, the web viewer built to referee the two, and the Revit add-in at the end of it. Two AI agents worked this job, and the division of labour between them flipped twice. What made the arrangement work had nothing to do with which one was "the implementer".

  Part 3 of a series — a Dynamo tunnel geometry that was already finished, a 39-sheet Excel workbook it had never been wired to, the web viewer built to referee the two, and the Revit add-in at the end of it. Every drawing carries two kinds of line that look nearly identical to a machine and completely different to a person. One is the edge of real concrete. The other is a graphic whose only job is to say how big that concrete is.

  Part 2 of a series — a Dynamo tunnel geometry that was already finished, a 39-sheet Excel workbook it had never been wired to, the web viewer built to referee the two, and the Revit add-in at the end of it. Somewhere in the original graph there is a code block that reads 725+625; . The author did not write 1350 , and that choice tells you everything: 725 and 625 were two separate real dimensions, and they were trying to leave a trail.

  Part 1 of a series — a Dynamo tunnel geometry that was already finished, a 39-sheet Excel workbook it had never been wired to, the web viewer built to referee the two, and the Revit add-in at the end of it. A working Dynamo graph already existed. It produced the full 3D geometry of a Korean road tunnel project (NATM), 892 m of it, and it ran without errors. The problem was that nothing inside it knew where its numbers came from.

A long-form project note about translating a pathfinding concept into a Dynamo and Generative Design workflow, including CAD geometry, Revit Generic Model caching, Data.Remember, scalar GD outputs, and the failures that shaped the final structure. From Concept to Dynamo: The Trial-and-Error Behind a Generative Design Workflow Building the concept is one task. Moving it into a real .dyn workflow is another. A few days ago I published Automation Lab: Runnable Pathfinding Experiment . That post introduced a small browser-based experiment: place start points, end points, and obstacles on a canvas, then generate route options around blocked areas. On the web, the idea is easy to understand. A point is a point. An obstacle is a drawn shape. A route is a line. The coordinate system is controlled, the geometry types are clean, and every object is created by the application itself. That makes the browser experiment useful as a concept layer. It can show the intent quickly: generate a ro...

Generative design is often described as a way for software or AI to create design options automatically. In practice, the more important point is not automation itself. The real value comes from defining design variables, evaluation criteria, and a search strategy so that many alternatives can be generated, compared, and improved. For AEC workflows, this matters because design decisions are rarely based on a single criterion. A building option may need to balance area efficiency, daylight, cost, constructability, code constraints, structural logic, and documentation requirements. Generative design tools help explore that decision space, but each tool is built around a different workflow and level of control. The Basic Structure of Generative Design Most generative design workflows can be understood through three components: a generator, an evaluator, and a solver. Component Role Generator Creates design alternatives from input variables and constraints. Evaluator Measur...

From Generative Design Optimization to Quantity Takeoff Automation: Building a Scalable AEC Process System In many AEC workflows, Generative Design optimization and Quantity Takeoff automation are treated as separate topics. One belongs to the front end of design exploration.   The other belongs to the back end of documentation, estimation, or reporting. But in real projects, especially repetitive and high-complexity projects, that separation is too artificial. The real opportunity is not to optimize a layout in isolation, and not to extract quantities only after the design is already fixed. The deeper opportunity is to build a connected system where: - spatial logic - room classification - layout rules - object libraries - placement automation - parameter logic - quantity extraction are designed as one continuous workflow. That is the difference between isolated automation and scalable process architecture. The real problem: many AEC automations stop at one layer This is a re...

Generative Design in AEC Can Become a Synthetic Data Factory For years, Generative Design in AEC has been introduced through a familiar promise: generate many options quickly, compare them, and select the best one. That promise is still valid.   But I think it is too small. The bigger opportunity is not just that Generative Design can make alternatives. It is that Generative Design can produce **structured, high-purity, logically consistent data** at scale. And once we see that clearly, a new role emerges: **Generative Design can become a Synthetic Data Factory.** That changes everything. Because one of the biggest bottlenecks in AI for AEC is not model architecture. It is not GPU access. It is not even the lack of interest from the industry. The bottleneck is data. More specifically, it is the lack of domain-specific, logically clean, reusable training data that reflects real engineering intent. That is where Generative Design becomes far more valuable than most current narra...

A Digital Twin Is Not a 3D Model.  It Is an Operational Information Structure. The phrase “digital twin” is often reduced too quickly. A 3D model.   A dashboard.   A sensor-connected building view.   A more advanced BIM environment. Those descriptions are not entirely wrong.   But they are too weak. In AEC, a digital twin becomes meaningful only when it supports operational continuity across the lifecycle of an asset. That means its value does not come from visualization alone. It comes from whether information can move, remain usable, and return to decision-making after the design model is complete. That is why I think a digital twin should be understood less as a visual object and more as an operational information structure. This distinction matters. Because once the discussion focuses too much on the 3D model, teams often overestimate delivery maturity. A model may look complete. A platform may look integrated. A dashboard may look modern...

WeeklyDynamo Notes:  What I’m Tracking in AEC Automation, BIM, and AI Lately, I have been thinking less about isolated tools and more about how the AEC workflow itself is changing. That shift matters. For a long time, many conversations in our field were separated into categories: - BIM - automation - Generative Design - digital twin - AI - quantity takeoff - data management Each topic had its own language, its own examples, and often its own audience. But in real projects, they do not exist as separate islands. They increasingly behave as parts of one connected system. That is what I have been trying to track through WeeklyDynamo. This blog is not only a place to post isolated technical notes. It is also where I want to document the structural changes happening across AEC workflows: how decisions are made, how information moves, where automation creates leverage, and where AI actually fits. So for this note, I want to briefly organize the themes I have been following most closely....