Where AI stops
“AI will do all of this soon — why buy software now?” We won't start by dismissing that question. A great deal really is being automated. But it's worth being precise about how far it has come, and where it stops.
Published August 10, 2026·Last checked · August 2026
Key points
- Products that create walls, floors, roofs and openings in Revit from plain language are already on sale — rebar is not mentioned anywhere on those product pages
- AI adoption in construction sits at 45% in office/admin and 20% in design — and inside design, what is automated today is making geometry
- The Revit API does support rebar creation. The question is what that API requires the caller to already know
- There is no argument for lap length, development length, cover, or splice location — the caller has to decide those and pass them in
- So a prompt, an MCP server and a Dynamo graph all hit the same wall. What got automated is execution, not judgment
1First — AI really has come this far
Starting from denial gets you nowhere. Even first-order generation — making the data itself — has begun to shift. There is a real product to point at.
“Upload building photos, PDFs, or sketches, and let Claude create native walls, floors, roofs, doors, and windows directly in Revit.”
“Tell Claude ‘add a third floor with six windows’ — and watch it happen.”
— bundled MCP server, Revit 2025–2027.
A Revit model appears from a sentence. That is not marketing; it is a product you can buy. And yet on the same page the vendor writes: “REVIEW & REFINE — Verify dimensions and element placement against field measurements before advancing the model into documentation.”
What the product creates is masses, walls, floors, roofs and openings. Rebar and structural detailing are not mentioned anywhere on the page.
Adoption numbers need to be read together with the question that was asked. Especially here.
| Survey | Figure | How to read it |
|---|---|---|
| AGC of America + Sage 2026 Construction Hiring and Business Outlook Nov 4 – Dec 15, 2025 · 49 states · n=951 | “61% use AI or plan to increase investment” Office/admin 45% · estimating 23% · design/preconstruction 20% · HR 16% | 61% is not an adoption rate — it is “using or planning” combined. The number that matters is design at 20%, less than half of office/admin's 45% |
| Autodesk 2026 State of Design & Make: AI Pulse Statista Plus Research · Jan–Feb 2026 · n=2,500 | “Use at least one AI tool” — nearly 100% “Early adopters” 19% (n=469) | The first figure asks “do you use a tool that contains AI,” which measures vendors shipping AI features. The meaningful number is 19% — those who integrated it into a real workflow |
AI is genuinely arriving. But where it has landed is office and admin — and inside design, what is automated is making geometry.
2The Revit API does support rebar creation
Let's be precise. The Revit API has the Autodesk.Revit.DB.Structure.Rebar class, and Rebar.CreateFromCurves / CreateFromCurvesAndShape create rebar. The Autodesk developer guide has a dedicated Reinforcement section. So this is not a case of “the API can't do rebar.”
Then why does nobody sell rebar-from-plain-language yet? The answer becomes obvious once you look at what that API demands of the caller.
3The API signature is the list of things AI does not decide for you
These are the arguments Rebar.CreateFromCurvesAndShape requires, verbatim from Autodesk's API documentation.
| Argument | What the docs say | What it means in practice |
|---|---|---|
| rebarShape | “A RebarShape element that defines the shape of the rebar” | How the bar is bent — already decided |
| barType | “defines bar diameter, bend radius and material” | Diameter · bend radius · material |
| startHook / endHook | “defines the hook for the start of the bar”, or null | Hook type — 90° or 135° |
| curves | “An array of curves that define the shape of the rebar curves” | The path the bar runs along |
| startHookOrient / endHookOrient | Right or Left | Which way the hook faces |
| hookRotationAngleAtStart / AtEnd | “The out of plane hook rotation angle” | Out-of-plane rotation |
| host | “The element to which the rebar belongs” | Which member it belongs to |
Now look at what is not on that list. There is no argument that computes lap length. None that derives development length. None that judges cover, and none that decides where the splice goes.
The API executes: “place a bar of this shape, with these hooks, along this path.”
What the path and the hooks should be is something the caller has to know already.
4So prompts, MCP and Dynamo all hit the same wall
There are many routes into Revit but only one destination. Plain-language prompts, MCP servers, Dynamo graphs, C# add-ins — all of them reach the model through the Revit API. And the values required at that point are the same no matter who supplies them.
Dynamo is no exception. Its own documentation describes Dynamo nodes as wrappers around Revit elements, and states that “the Dynamo integrator chooses which Host API to expose as nodes.” What you can do in Dynamo lives inside what the Revit API allows.
Change the tool and the question survives: “is the hook on this bar 90° or 135°?” No amount of prompt craft produces that value if nobody knows it.
5Why “rebar this whole building” doesn't work in one shot
Picture actually asking an AI to do it. It starts asking back — concrete strength? bar diameter? spacing? lapped or mechanical splices? which development-length code?
And the person who can answer those questions already knows rebar detailing. If you can answer, you could do it without AI; if you can't, AI doesn't help.
Sources
This article is a summary compiled from published material. It is not a legal interpretation and does not constitute advice. Regulation changes frequently, so please check the original documents and the latest notices from the responsible authority before relying on it in practice.