I get an ugly feeling watching AI move through our industry: like I have seen this film before, and I know how it ends.

For almost two decades, computational design and BIM made almost exactly the promise AI makes today. Turn the manual, expert judgement inside engineering and design into logic a machine can run. Automate the tedious parts. Free your best people for the work that matters. Operationalize your expertise. Tools like Grasshopper and Dynamo, and the wider world of code-driven design, let engineers and architects take workflows that lived in their heads and codify them, so a machine could execute in seconds what used to take days. Everyone could build their own tools. Conferences filled up, and volumes upon volumes were written on the subject. It was going to unlock the next era of productivity.

It did not. And the reasons it did not are the reasons AI is about to disappoint the same industry in the same way, only worse.

The Productivity That Never Came

Start with the uncomfortable scoreboard. For all the parametric modeling, all the BIM mandates, all the digital transformation strategies of the last twenty years, construction labour productivity has grown around one percent a year, against about 2.8 percent for the world economy and 3.6 percent for manufacturing. In the United States, McKinsey found construction productivity had barely moved since 1945, a period in which manufacturing, retail, and agriculture grew theirs by as much as fifteen hundred percent. Construction sits near the very bottom of every digitisation index there is.

Two decades of the most sophisticated design technology any built-environment generation has ever had, and the needle on the thing that matters did not move. That is not an accident, and it is not only about site logistics or contracts. It is partly about what those design tools really were, and what everyone quietly assumed they were.

What computational design really was

Grasshopper and Dynamo were built as visual programming environments: a way for people who do not write code to assemble executable logic by wiring boxes together. That was their genius and their curse. The genius is obvious. You could give an engineer who had never opened a code editor the power to automate real work. The curse is subtler, and the industry never reckoned with it. Along with the abstraction came an assumption that the thing you produced this way was as good as software, and that automation was the same as efficiency.

It was neither. A visual script that automates a workflow on one engineer's machine is not software in any sense a software engineer would recognize. It is not tested. It is not verifiable. It has no version control anyone else can read, no continuous integration, no way to be reviewed, hardened, deployed, and maintained by a team. It cannot scale the way software scales, because it was never engineering in the first place. It was a personal macro dressed up as a system.

For an industry desperate to look modern, decades behind others in technology and efficiency, that distinction was inconvenient, so it was ignored. Automation got counted as progress. And because every one of these tools lived on one person's desktop, inside one software package, the mess it created was at least contained. When that engineer left, their scripts left with them, and the firm quietly went back to doing the work by hand. The productivity gain was real for one person for a while, and it evaporated at the level of the organisation. Individual efficiency did not become operational efficiency. It almost never does.

That is the whole story of computational design's productivity impact, and it is worth holding in your head, because AI is running the exact same play, and the industry is making the exact same assumption, at a scale computational design could never reach.

The same mistake, minus the friction

Here is the one thing that limited the damage last time: computational design was hard. Grasshopper and Dynamo have a real learning curve. Only a small fraction of the world's AEC professionals ever learned what computational design even is, let alone became fluent in it. Adoption was narrow, and that narrowness was, in hindsight, a kind of accidental containment. The blast radius was small because the barrier to entry was high.

AI has removed the barrier entirely, and in doing so it has removed the containment.

The promise now is intoxicating and available to everyone. You no longer need to learn a visual programming language, and you are no longer confined to what a handful of industry software packages will let you build. You can simply imagine a tool, describe it to whatever model is on your favorite platform, and half an hour later you are holding something that runs. No barrier, no learning curve, no limits. To a leadership team under pressure to "do something about AI," this looks like the answer to a prayer. Give everyone a license, tell them to go and build, and watch a thousand efficiencies bloom.

It will not play out that way, and we already have the receipts.

Vibe coding is not software engineering

The industry has a name for describing what you want and running with whatever the model produces: vibe coding. It is a wonderful way to explore an idea or throw together a prototype. It is a catastrophe as a way to build software an organisation depends on, and the evidence is now overwhelming.

Testing of AI-generated code has found that roughly 45 percent of it ships with a vulnerability from the OWASP Top 10, a figure that has not improved across successive model generations despite every vendor claim to the contrary. One security project attributed thirty-five separate CVEs in a single month of 2026 directly to AI coding tools, up from six at the start of the year, and estimated the true number was many times higher. Studies of large enterprises found AI-assisted developers shipping commits three to four times faster while introducing security findings at ten times the rate. Analysis of over two hundred million lines of changed code found duplicated, copy-pasted code overtaking refactored code for the first time on record, with cloned code carrying substantially more defects. And the maintainability problem is the quietest and most damaging of all: vibe-coded systems tend to become, at six to twelve months, a black box that no one, including the people who prompted them into existence, can safely change, because the tool that wrote them kept no memory of why it made the choices it did. The only remaining option is a rewrite.

None of this means the models are bad. The models are extraordinary. It means that producing working code and engineering production software are different activities, and the gap between them is exactly where real systems fail. Production software is not code that runs once. It is code that handles real data, enforces permissions, keeps an audit trail, survives review, and can be maintained by a team over years. Vibe coding optimises for the first thirty minutes. Everything that makes software safe to depend on lives in the years after.

Worse Than Grasshopper, By design

So picture what a firm gets when it hands every employee a model and tells them to build. Not one automated workflow, but hundreds of little applications, each built by a different person to a different standard, on a possibly different stack, sharing no design system, running on no common infrastructure, evaluated against nothing, governed by no one. Each is a silo. Each is somebody's private black box. And unlike the Grasshopper era, these are not politely confined to a desktop inside one software package. They are loose in the organization, touching real project data, wired into real systems.

This is measurably worse than the computational design sprawl that came before it, and for a structural reason. Every tool you build adds to the surface you then have to maintain, secure, and understand, and with vibe coding that surface expands faster than any organization can keep up with. The maintenance burden that quietly killed computational design's returns is back, unbounded this time, and pointed at data that matters. Surveys already put the average large enterprise at well over a dozen AI tools and agents, a large share of them operating in isolation, each holding its own version of the truth. One company disclosed it had accumulated more than nine hundred agents in under a year, because everyone had gone off and built their own.

The Negligence at the Centre of the Strategy

The part that most worries me is that this is not an accident befalling careless firms. It is the stated strategy of thoughtful ones. Leadership has been persuaded that building software is now a prompt away, and so the plan, in board rooms across the industry, is to buy everyone a ChatGPT licence and instruct them to automate their own jobs. No platform. No evaluation harness. No guardrails. No one asking whether a tool that reviews submittals reviews them correctly, or what happens to the project data it touches, or who maintains it when its author moves on.

Building products that wrap AI is a different discipline again, harder than conventional software, not easier, because you are now also responsible for the behaviour of a non-deterministic component. If a firm was not doing serious software engineering or AI engineering before, deciding that it will now have its staff build and depend on AI tools, and that everything will simply be fine, is not ambition. It is negligence. The bill for it will arrive the same way computational design's did, only larger, and it will arrive as fragmented data, fragmented knowledge, and fragmented intelligence spread across a sprawl of unmaintainable tools that no one can govern, reconcile, or trust.

We will have spent the AI era making our data and our expertise less usable, not more, and calling it transformation.

The Only Way This Works

The way out is not a secret. Every industry that got value from software instead of chaos learned the same lesson, and gave it a name: platform engineering. You do not get reliability, security, and scale by having everyone build whatever they like however they like. You get it by building shared infrastructure once, and letting people build on top of it along paved paths. A common foundation. Shared components and design systems. A managed set of models. Evaluation built in, so you can prove a workflow works on your own data before you trust it. Guardrails and provenance, so every output can be checked and every action governed. The individual still moves fast. The difference is that their speed now compounds into something the organisation owns, instead of scattering into another silo.

This is the lesson computational design left lying on the ground for anyone willing to pick it up. Tools that individuals build for themselves do not become an organisation's capability, no matter how clever they are, unless they are built on a platform that makes them consistent, safe, maintainable, and shared. Automation was never the same as efficiency. A prototype was never the same as a product. And a thousand disconnected tools were never the same as a system.

The AEC industry has watched this film once and learned nothing from it. We have one more chance to read the ending before we buy the ticket again. I would like to believe we will take it, though our record on this is not encouraging, which is rather the point.