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 the center of gravity is shifting.

What is changing now is not only the speed of coding.  

It is the **development process itself**.

The rise of agentic coding tools such as Google Antigravity and Claude Code suggests that internal teams can increasingly build, test, and iterate application features on their own. Google introduced Antigravity alongside Gemini 3 as an agentic development platform where agents can plan and execute end-to-end software tasks across the editor, terminal, and browser. Anthropic describes Claude Code as a terminal-native coding tool that can build features from descriptions, debug issues, and navigate large codebases. More recently, Anthropic has also expanded autonomous behavior in Claude Code with features like auto mode and computer control previews. :contentReference[oaicite:2]{index=2}

This is not a small tooling upgrade.

It is the beginning of a structural change in how AEC organizations may produce software.

The old model: tool requests moved outward

Traditionally, internal software demand in AEC moved through an externalization path.

A practitioner identified a repetitive task.  

A BIM team or innovation lead translated that pain into a requirement.  

A development vendor estimated the scope.  

Then a project began.

That process had obvious strengths:

- formal responsibility

- stronger software engineering discipline

- clearer delivery ownership

- support for larger deployment projects

But it also had recurring constraints:

- long lead times

- requirement translation loss

- high communication overhead

- low iteration speed

- expensive changes after specification freeze

- distance between real workflow pain and implementation logic

In practice, many good automation ideas died not because they lacked value, but because the cost and process of turning them into software was too heavy.

This was especially true for narrow but high-value tools:

- room data validators

- parameter mapping utilities

- quantity support add-ins

- layout review assistants

- family QA tools

- batch processing utilities

- IFC data correction workflows

- project-specific model health checks

These tools matter.  

But they often sit in the uncomfortable zone between “too specific for a big software company” and “too technical for a non-developer team.”

That is exactly the zone AI coding is beginning to unlock.

The new model: development moves inward

The most important shift is not that AI writes code faster.

The more important shift is that **development is moving inward**.

What used to require a formal vendor relationship can increasingly begin inside:

- a BIM automation team

- an internal R&D group

- a digital delivery task force

- a computational design unit

- an innovation lab

- or even a technically strong practice team

This does not mean every architect or engineer suddenly becomes a production-grade software engineer.

It means the threshold for turning domain knowledge into working software has dropped sharply.

That threshold used to be blocked by:

- API complexity

- framework setup

- UI scaffolding

- debugging overhead

- installer and packaging friction

- codebase navigation

- testing burden

Now, a meaningful part of that burden can be offloaded to agentic tools.

That changes the economics.

The internal question is no longer only:

“Can we afford to commission this tool externally?”

It increasingly becomes:

“Can we prototype, validate, and maybe even ship the first version ourselves?”

Why this matters specifically for Revit add-ins

Revit add-ins are not abstract software experiments.  

They sit inside production workflows.

Technically, Revit add-ins still follow a defined application structure: external commands and external applications are registered through `.addin` manifest files, and the assembly and class structure must conform to the Revit API integration model. :contentReference[oaicite:3]{index=3}

In other words, the target architecture has not disappeared.

A Revit add-in is still a real software artifact.  

It still needs:

- proper command structure

- manifest registration

- assembly handling

- version alignment

- transaction safety

- UI behavior decisions

- distribution logic

- maintenance

But what has changed is this:

**AI now helps generate a much larger portion of that artifact.**

That means the bottleneck is shifting away from syntax production and toward:

- workflow decomposition

- API intent definition

- data structure clarity

- edge-case handling

- verification

- deployment governance

This is why Revit add-in development is a particularly interesting test case for the AI era.

The technical target is still strict.  

But the path toward that target is becoming more accessible.

The real shift: from writing code to directing software production

The deeper change is cognitive.

Before, building an add-in required someone to:

- understand the problem

- understand the Revit API

- design the code structure

- manually implement the logic

- manually debug the flow

- manually build supporting UI and packaging

Now, more of that middle layer can be delegated.

Tools like Claude Code and Antigravity suggest a new working model:

- the human defines intent

- the AI proposes structure

- the AI implements a draft

- the AI runs checks or tool actions

- the human verifies workflow fit

- the AI revises rapidly

- the team moves from idea to usable internal tool faster than before

That means the practitioner’s role changes.

The high-value human skill is less about typing every line and more about:

- defining the true problem

- separating deterministic rules from fuzzy judgment

- structuring domain context

- verifying whether the output is safe in practice

- understanding where the AI is wrong

- turning tacit workflow knowledge into explicit logic

This is why I do not think the future belongs to “AI replacing developers.”

I think the future belongs to organizations that learn how to **direct software production intelligently**.

Why internal teams may outperform vendors in some tool categories

This is an uncomfortable but important point.

For many internal AEC tools, the most difficult part is not software engineering in the abstract.  

It is workflow intimacy.

The team closest to the pain often knows:

- which exceptions matter

- which rules are actually used

- which model states are common

- which data structures are dirty

- which buttons practitioners will ignore

- which output format is necessary

- where the real bottleneck is

That local knowledge is extremely valuable.

In the old development model, much of that knowledge had to be translated outward into requirement documents. Some of it was lost in communication. Some of it became too expensive to preserve.

With AI-assisted development, more of that domain knowledge can stay close to the source.

That is why internal teams may now outperform traditional vendor workflows in certain categories of add-ins:

- narrow-scope utilities

- project-specific automation

- repetitive QA tooling

- internal review tools

- data cleanup assistants

- parameter checking tools

- team-specific workflow panels

This does not eliminate the role of vendors.  

It changes where they are strongest.

Large enterprise products, hard integrations, security-heavy deployments, and long-term platform ownership still strongly favor mature software companies.

But the middle zone is changing rapidly.

What this means for design firms, builders, and engineering companies

I think we are moving toward a three-layer organizational pattern.

1. Internal practical builders

These are BIM leads, automation engineers, computational designers, and technical practitioners who can now build tools much more directly than before.

Their advantage:

- speed

- closeness to workflow pain

- ability to test with real users immediately

2. Internal platform teams

These teams standardize what becomes reusable:

- shared libraries

- deployment rules

- code quality baselines

- version governance

- security review

- packaging and maintenance

Their advantage:

- scale

- reliability

- internal productization

3. External specialist vendors

These remain critical for:

- enterprise architecture

- larger integrations

- mission-critical deployment

- compliance-heavy systems

- advanced product engineering

Their advantage:

- depth

- continuity

- production engineering maturity

The difference is that the pipeline between these layers is changing.

Instead of everything starting as a vendor request, many tools will start as internal experiments, become validated prototypes, and only then graduate into internal platforms or external partnerships.

That is a fundamentally different process.

The new bottleneck is not coding. It is governance.

This is where the conversation needs realism.

Just because AI can help build features does not mean organizations are automatically ready to operate software well.

As the cost of feature production drops, new bottlenecks emerge:

- who owns the tool

- who validates correctness

- who maintains version compatibility

- who tests model safety

- who documents behavior

- who approves deployment

- who handles user support

- who manages API and model drift

This is especially important for Revit add-ins, where a broken command is not just an inconvenience.  

It can corrupt workflow assumptions, waste production time, or create hidden model issues.

So the real maturity question is no longer:

“Can we make the add-in?”

It is increasingly:

“Can we operate the add-in as an internal product?”

That is a much healthier question.

What smart teams should do now

If this trend continues, AEC organizations should not only buy AI tools.  

They should redesign their internal development process.

A practical starting point looks like this:

First, identify the right tool candidates

Choose tools that are:

- repetitive

- narrow in scope

- high in internal pain

- easy to validate

- valuable even if used by one team first

Second, separate prototype speed from production safety

Let AI accelerate prototyping.  

But introduce explicit review steps before wider rollout.

Third, create an internal tool ladder

Not every script should become a platform.

Some tools remain local.

Some deserve formal productization.

Define the path clearly.

Fourth, treat domain experts as product owners

The person closest to the workflow should shape the tool.

AI amplifies good problem framing and amplifies bad framing too.

Fifth, invest in verification, not just generation

Generation is becoming cheap.

Verification is where trust will be built.

My view of the next phase

I do not think the future is simply “everyone becomes a developer.”

I think the future is:

- more people can produce software-like outcomes

- internal teams can build more of their own tools

- vendors will handle a different mix of work

- the role of technical leaders will become more architectural

- software production inside AEC will become more layered and more distributed

And in that world, the most important people may not be the ones who can type the fastest.

They may be the ones who can:

- identify valuable workflow pain

- decompose it cleanly

- structure the logic

- direct AI well

- verify the results

- and turn prototypes into reliable internal products

That is a different kind of capability.

It sits between practice, engineering, and product thinking.

Final thought

AI can now build real app features.

That is already changing software development in general.  

And in AEC, it is beginning to change Revit add-in development in particular.

The most important consequence is not only faster coding.

It is that development authority is starting to move.

From external request chains  

to internal experimentation.

From vendor-first delivery  

to hybrid internal product building.

From “Can we commission this?”  

to “Can we make, test, and own this ourselves?”

That is not just a tooling trend.

It is a process shift.

And the firms that recognize that early will not only build more tools.

They will build a different kind of internal capability.