generative design and dynamo blog by weeklydynamo Newsletter Source

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

AI in AEC Is Not Really Changing Modeling. It Is Changing Decision-Making. AI in AEC is shifting from model generation toward decision support, workflow logic, and information structure. The conversation around AI in AEC often jumps too quickly to one question: Can AI generate better models? That question is understandable.   It is also too narrow. In practice, the deeper shift is not happening only at the modeling layer.   It is happening in the decision-making layer that sits before modeling, between modeling, and after modeling. That is where I think the real story is. For a while, many parts of the industry were heavily focused on Generative Design. It promised structured exploration, better alternatives, and faster option testing. But recently, the buzz around Generative Design has clearly become quieter. As someone who has implemented it deeply through Dynamo, I have felt that shift directly. The reason, in my view, is not that optimization stopped mattering. T...

AI is now being inserted into almost every conversation about AEC automation. But in many cases, the question is still too vague. The industry keeps asking: “How can we use AI?” A better question would be: **Where exactly should AI sit inside the automation process?** That difference matters because automation is not a single action. It is a chain of decisions, transformations, validations, and outputs. Some parts of that chain benefit greatly from probabilistic inference. Other parts require deterministic control. If AI is placed in the wrong layer, the workflow becomes unstable. If it is placed in the right layer, it can create real leverage. This is the core issue. The value of AI in AEC does not come from making everything intelligent.   It comes from assigning intelligence to the right layer of the system. In my view, that is where the conversation needs to mature. AI should not be treated as a blanket replacement for automation.   It should be treated as one co...