Introduction - the AI paradox

A few months ago, Anthropic released a piece of research on the impact of AI on labor markets. It maps, occupation by occupation, how much of each job’s work today’s models could already perform, against how much AI is actually being used.

For physical construction work, theoretical coverage is low, which makes sense. That part of the story belongs to robotics. But architecture and engineering is one of the largest wedges of theoretical coverage on the entire chart, in the same league as law and finance.

That makes sense, because designing a building is information work: drawings, documents, calculations, models, specifications, coordination. And observed adoption in that wedge is close to zero.

The gap is hard to miss. Nowhere in the economy is the distance between what AI could do and what AI is doing wider than in the industry that designs the physical world. And this is becoming increasingly important as the current infrastructure boom, housing shortage, and general pressure on construction costs are all putting more pressure on the industry.

The easy explanation is that construction is old, slow, and allergic to technology, and that it will catch up last, like it always does. I don’t think this explanation is accurate. The gap isn’t really new, and it isn’t really about AI. It is the latest photograph of a forty-year pattern: wave after wave of software transformed other industries, but kept bouncing back on AEC. AutoCAD and Revit digitized drawings and building models, project management software digitized workflows, but the core operations of the industry are still mostly manual.

So before trying to understand how AI is going to change the industry, it’s worth taking a step back and understanding why, for forty years, the productivity of cognitive labour in the industry has stagnated.

It’s a mix of information silos, un-repeatable work, inability to systematize/standardize most processes, and a few other things. The easiest way to understand all of this is to simply look at what people do at each step of the design of a building.

Follow the representations

So beyond all of the hermetic language, what do architects, engineers, developers, and other stakeholders actually do during the design phase?

If you abstract it away enough, it’s quite simple: it’s starting from the idea of a building and what it should do, then finding where to build it, and then building detailed instructions of how to build it on the specific piece of land you have chosen.

What guides this process is a digital representation of the building, which gets more and more detailed over time. Every stakeholder is responsible for a specific part of the process, adding constraints on what the building should be like, until it gets to one sealed answer. Each set of constraints kills a few more options.

So design isn’t really creation in the blank-page sense. It’s closer to the progressive elimination of possibilities under a growing pile of constraints, until one answer is left standing.

To understand the process, you just need to look at how the (digital) representation of the building evolves over time, and how different stakeholders iterate on it.

Over the course of pre-construction, the representation takes four forms:

• It starts as intent: an idea in someone’s head, a budget.
• It becomes 2D: the first drawings, the first time the building is something you can point at.
• It then becomes 3D: a model that every discipline writes its decisions into, until you reach a very detailed description of the building.
• At the very end it is deliberately flattened back into 2D: the building gets converted into blueprints that are then handed to the municipalities and the general contractor.‍

Intent

A building starts with an owner who wants something and an architect whose job is to find out what that want actually looks like. What the developer wants is really a set of upstream constraints. Some are functional (what the building must do, for whom, roughly where), some are financial (the ROI equation that makes the project exist at all). Together they turn it into a structured list of every space the building needs, its size, its adjacencies, how it must perform, etc.

Then the intent collides with one specific piece of land, which has constraints of its own: soil conditions, connection to the grid, local regulations, etc. Every piece of land is different. Out of this it is decided if the project is feasible or not. If the owner approves, they move to the next step.

2D / schematic design

In schematic design (2D), the architect draws massing, floor plans, elevations and engineers (structural, MEP, etc.) start weighing in. This represents about 15% of the design fee, and decides the building’s character. The owner guides the main decisions.

3D / design development

Here, the representation of the building starts to thicken. Every discipline stops advising and starts designing:

• The structural engineer decides what the structure/skeleton of the house is going to be like: where beams and columns go, how large they need to be. Everything downstream bends around that.
• Mechanical, electrical, and plumbing (MEP) engineers figure out how heating, cooling, power and water equipment needs to work in the specific building, and how all the ducts, wires, and pipes will be routed.

Week over week, every discipline writes its decisions into the model: structure, systems, fire, etc. The architect’s model becomes the reference everyone works against, which makes the architect’s real job coordination between the different models authored by separate firms.

This shared 3D model is called BIM (Building Information Modeling).

Documentation

Then, once the building is fully coordinated, that rich model is flattened into 2D plans again. This is the construction documentation phase (roughly 40% of the design fee).

Its goal is twofold:

• Telling the builders what to do. The drawings become a complete, unambiguous set of instructions for every element of the building. These are used by the contractors downstream, who perform the physical work.
• Getting the building approved. Before anybody can build, a local government authority (the municipality) has to review the design and confirm it complies with building codes and zoning law. That review happens on drawings, not models, because 2D drawings are the legal format of the industry. They are what the reviewer is authorized to approve and what a contract can attach to.

At the end of the documentation phase, the architect of record (the licensed architect whose name is legally on the project) applies a seal, which carries professional liability. Then the documents are sent over to general contractors (GCs).

Drawing interpretation

When GCs receive the document set, they try to answer a different set of questions: can I build it, what risk am I underwriting, is there anything missing, how much is it going to cost me, who am I going to work with? To do this, a few things:

• They re-quantify the entire building from scratch, counting every door and every square foot of drywall, essentially double-checking everything that was sent to them to catch errors.
• Then they carve the job into trade packages and send those to subcontractors, who bid back against it.
• On a win, the contractor locks every trade’s scope, price, and schedule into contracts.

Only then does anyone break ground.

As we explained above, the space of possible buildings shrinks: at feasibility almost anything is still possible, by the permit there is exactly one fully specified, legally sealed proposition.

Six cognitive operations

Once you look at things from the perspective of “how the representation of the building evolves over time”, what happens becomes easier to see. Every task that happens during the process is some combination of six cognitive operations, performed on a variety of formats and software.

Three happen inside a representation:

• Interpretation. For instance, reading a drawing set and understanding what a specific part of the building is.
• Generation. Authoring new content within a representation: modeling a wall, routing a duct through a ceiling, authoring a new detail, etc.
• Verification. Checking a representation against a rule. Does this stair comply with code? Do these two sheets contradict each other?

Three happen across representations:

• Normalization. Forcing a pile of heterogeneous things into one comparable shape. This is what a GC does when leveling thirty different subcontractor bids onto something he can compare.
• Reconciliation. Forcing different representations to agree. The architect’s model just changed - what does that do to the structural model?
• Translation. Turning one representation into another. Turning a brief into a massing, converting a 3D model into 2D, converting a set of drawings into a bill of quantities.

The entire industry is essentially sequences of these operations, on the formats we just walked through. So the industry is not merely producing documents, it’s constantly operating on the meaning of these representations.

What forty years of software did was help create and store the representations. But the operations themselves - every interpret, every reconcile, every translate - are mostly done by humans.

So the automation question in AEC is mainly about whether machines could perform these operations. And they can’t, really.

Why operations stayed human

Deterministic software works when the world is stable and explicit. It needs repeatable patterns, something that holds long enough to write a rule against. And it needs machine-readable meaning to operate on. AEC supplies neither.

First, no standardization means no structural repeatability. Every site is different, every jurisdiction is different, every owner is different, every project team is different, every firm has its own standards. Drawings vary by firm, models vary by author, specs vary by project, bids arrive in incompatible formats, and the assumptions are buried in notes, exclusions, and conventions. Every project re-specifies itself, because every project is custom.

This especially kills the across operations: you can’t write rules to normalize or reconcile things that never take the same shape twice.

Second, no machine-readable meaning means no interpretation. The formats are legible to trained humans and opaque to machines. A senior engineer can find his way through a thousand-sheet document set. Machines can’t follow it. Even BIM doesn’t fully solve this.

There have been attempts at standardization - most notably IFC, an open schema for describing a building. But a shared file format doesn’t create shared conventions, structure, or meaning.

Digital does not mean computable. A PDF is digital. A BIM model is digital. But software can only automate an operation if it can reliably understand what it’s operating on. AutoCAD digitized the drawing and Revit digitized the building model, but neither automated the operations. And if every interpret, normalize, or translate still runs through a human mind, on unstandardized material, meaningful productivity gains are close to impossible. This is what coordinating a building is: thousands of sheets, references, a dozen models that all have to agree with each other - held together by people.

Why operations are fragmented

If you step back and look at the whole process, another obvious reaction is that it looks badly designed. A single building passes through dozens of separate parties - architect, structural engineer, MEP, consultants, general contractor, subcontractor - each working in their own silo, in their own software, on their own slice of the problem. Every boundary between them is a handoff, and every handoff loses information. Nobody truly holds the whole picture.

To an outsider, this looks like a recipe for exactly the failures it produces: things fall between the cracks, assumptions don’t match, errors slip through. So why does it work this way?

The answer is liability.

Remember that decisions in this process are sequential and irreversible, and mistakes become physical. An error not caught upstream percolates downstream and turns into rework, delays, claims, litigation - sometimes injury or death. Someone has to be accountable for every one of those decisions. And you can only hold someone accountable for a decision if you can point to exactly what they were responsible for.

That’s what fragmentation buys: the division of liability. Each party is contractually responsible for their piece and only their piece. The boundaries between stakeholders are not just organizational, they’re legal firewalls.

This means that a drawing set is not just a way of telling someone what to build, it’s a record of what the architect is willing to stand behind. A bid is not just a price, it’s what the subcontractor assumes they’re responsible for. A permit set is an object that can be reviewed, stamped, approved, rejected, and litigated.

So the loss of context and information between each handoff is the cost to pay for the distribution of liability. The goal is not maximum information flow, it’s controlledinformation flow across responsibility boundaries.

This is also why “one source of truth” is so much harder than it sounds. A genuinely shared model implies shared context, shared authorship, and sooner or later, shared liability. This industry is architected to prevent that.

One more structural fact to lock all of this in place. The architects, engineers, consultants, the contractor, and the subs are all assembled for this building, on this land, under this contract structure. When it’s done, the coalition disbands, and everyone reshuffles into new configurations on new projects with different partners. There is no persistent organization spanning the process. Two consequences follow:

• First, nothing is learned at the system level. Each firm keeps its own slice of experience, and the integrated knowledge evaporates at handover.
• Second, nothing can be standardized across projects, because the thing you’d standardize - the coalition, the conventions - is rebuilt from scratch every time.

So the silos aren’t a collaboration failure waiting for the right platform. Fragmentation is how the industry allocates risks, and the temporary coalition is how it absorbs project-specific complexity.

Why good tools die anyway

Suppose, despite all of this, someone builds a tool that genuinely works. It will usually still face massive adoption resistance. The technical problem and adoption problem are separate. And the adoption problem is the result of the same structural features we just explained.

AEC firms don’t adopt tools in a vacuum. They adopt them inside thin margins, temporary project teams, fragmented responsibility, and near-zero tolerance for error. In that context, a new tool sounds less like a productivity gain and more like a new failure mode. If it produces a wrong answer, who owns the mistake? If it changes a workflow, who guarantees the rest of the coalition adapts to it? If it needs clean data, who cleans it? If it makes a recommendation, who stamps it? So even genuinely good tools pile up in the implementation graveyard.

This reveals what buyers actually want. AEC buyers, very often, do not want tools. They want outcomes - more precisely, accountable outcomes, delivered by someone whose name is legally attached to them. They don’t necessarily want software that helps them perform a risky task. They want someone to take the task off their desk and stand behind the result. This risk moves off their desk, that’s the product.

This changes the business model for anyone with a technical edge. In most software markets, the obvious move (before AI) was to sell the tool. In AEC, the better move was almost always to wrap a specific outcome around it. If you build a better structural engineering engine, maybe the clever move was not to sell it to structural engineers, but build a firm around it and use the software as internal leverage. The market rewards risk transfer more than tool adoption.

Conclusion: the AI test

So the AEC industry is not necessarily backward: it’s hyper-rational within the set of constraints it’s operating in. Fragmentation divides liability, conservatism guards against irreversible decisions, outcome-buying moves risk off the buyer’s desk, and temporary coalitions absorb the specifics of each project. Every one of these structures makes sense, and together they made the industry illegible to software, which demands stable patterns and explicit meaning in an industry that structurally cannot supply it.

This brings us to AI, which doesn’t require the world to be formatted in advance to make sense of it. We’re seeing progress made recently on interpretation and generation of the core AEC data formats. In theory, this means that most of the cognitive operations we described above could be now performed by machines. This is what the “theoretical exposure” in Anthropic’s chart is really measuring.

But if the last forty years taught us that the binding constraint of technology adoption in AEC was never purely technical, the question is not whether AI can help interpret drawings, but what the optimal way is to distribute the technology in the industry. Who owns mistakes when a probabilistic answer becomes concrete, steel, cost, and liability?

In Part 2, we’ll take a look at how companies are navigating this set of constraints.

Find the LinkedIn post here and Substack article here.