WeeklyDynamo: Generative Design and Dynamo for AEC

 Research Log [2026 08 16]: Diagnosing and Automating a Phone-to-PC Remote Control Link for an LLM Agent 1. Objective Driving an LLM agent on a desktop machine from a phone is useful for a specific reason. The agent operates on the real files that exist only on that machine, including models, scripts, and drawings, so work started at the desk can be continued while away from it. A cloud session cannot do this, because the files are not there. The link had been in use for about a month and it stopped working one morning. This log documents the diagnosis, the three separate causes that were found underneath the failure, and the configuration that now survives a reboot. It also documents six errors in my own diagnostic reasoning, because those errors consumed roughly five hours and are more generally useful than the fix itself. 2. Summary of Work The failure had three independent causes that happened to coincide. A refresh token had expired on a thirty-day clock, an autostar...

 Over the past year I built five different 3D viewers for AEC work - routing, structural review, tunnel sections, a Revit perspective tool, a spreadsheet-to-3D viewer. Before I trusted my own instincts about how to build them, I did two things: I profiled all five on the same GPU, and I studied how 32 other AEC 3D tools - Autodesk Forma, Speckle, TestFit, xeokit, Bentley iTwin, and more - solve the same problem. This post is both halves: what the industry chose, and then what my own measurements showed. The short version is that rendering is a commodity, and the interesting decisions are everywhere else. Part 1 - What 32 AEC viewers actually chose I expected a mess of proprietary engines. Instead the choices collapse into six patterns, and the deciding question is never "which renderer is best" - it is "what is our actual moat."

  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 8 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. On 14 July the AI stopped guessing and wrote a list of things it could not decide. Seven questions, thirteen evidence crops, one document. The answers came back the same night, and one of them — a single sentence about a block of concrete nobody had bothered to name — collapsed three other questions and cleared a month of round trips before dawn.

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

Why useful AI work needs roles, result gates, and governed memory - especially for AEC/BIM automation. 0. Opening - Why One Assistant Was Not Enough Most AI workflows still begin with a single assistant. Ask a question. Get an answer. Copy the result somewhere else. Start again next time. For simple tasks, this is enough. If I need a short summary, a draft email, a quick explanation, or a small code snippet, one assistant can be extremely useful. But the moment the work becomes continuous, the single-assistant model starts to break. In my case, the work does not live inside one prompt. It crosses multiple layers: AEC automation projects Revit and Dynamo workflows Python scripts Generative Design experiments AI model training notes research papers blog articles YouTube and LinkedIn content presentation decks project-specific standards client-facing deliverables long-term knowledge management A single assistant can answer well in the moment. But it usually does not...

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