generative design and dynamo blog by weeklydynamo Newsletter Source

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....

 AI Can Now Build App Features. Revit Add-in Development Is Changing with It. We have entered a new phase of software development. AI is no longer only suggesting snippets, writing helper functions, or completing boilerplate.   It is increasingly capable of planning, building, testing, and revising actual application features. That shift matters for every software domain.   But in AEC, it matters in a very specific way: **it changes who can build internal tools, and how fast they can do it.** And if that is true for web apps, it is increasingly true for Revit add-ins as well. For many years, custom add-in development in Revit followed a familiar pattern.   A problem emerged inside a design firm, construction company, or engineering organization.   The team documented the request, aligned requirements, secured budget, and then asked an external software company or specialized vendor to build the tool. That model still exists.   But t...

Why AI in AEC Stalls: The Real Problem Is Not the Model, but the Workflow Data Structure Everyone says AI is coming to AEC. And yet, in real projects, fully working AI workflows are still rare. Why? Most people first suspect the model. They say the AI is not accurate enough. The LLM is unstable. The vision model is weak. The output hallucinates. The prediction is unreliable. Those concerns are not meaningless. But in practice, the failure point often appears much earlier. AI in AEC usually does not stall first at the model layer. It stalls at the workflow layer. More specifically, it stalls where data, rules, geometry logic, naming systems, and execution structure have not been organized into a form that AI can actually read, trust, and use. That is the real bottleneck. The wrong diagnosis: blaming the model too early AEC teams often assume that poor AI results come from weak AI. But in many cases, the model is not the first bottleneck. The workflow is. The project may already contain...

  Why AI in AEC Stalls: The Problem Is Not No Data. The Problem Is Unstructured Data. One of the most common explanations for slow AI adoption in AEC is simple: “We do not have enough data.” That sounds reasonable.   But in many real projects, it is not the real problem. In practice, the issue is often not the absence of data.   It is the absence of **usable structure** . The industry is already full of information: - BIM models - CAD files - schedules - room data - quantity tables - parameter sets - specification documents - issue logs - emails - reports - images - field records So the problem is rarely total emptiness. The real problem is that these sources are disconnected, inconsistent, and difficult to turn into one reliable automation process. That is where many AI initiatives begin to stall. The illusion of “not enough data” When teams say they do not have enough data, what they often mean is something more specific: - the data is inconsistent across proj...