With AI, making AEC software is easy, but making it safe, supportable and accountable is another matter entirely. AEC Magazine spoke with Igor Tsinman, CEO of AMC Bridge, about the opportunities, risks and responsibilities of AI-driven software development
Inside most large AEC firms there is now a layer of software nobody commissioned. AI coding tools have let architects, engineers, and estimators build working applications in days. The result is a growing estate of vibe-coded utilities with no documentation, no named owner, and in some cases write access to live project models.
This follow a familiar patten. A decade ago, Dynamo and Grasshopper bred the same culture of personal scripts, but now the volume and speed are new, and so is the proximity to production data, client information, and contractual output.
Igor Tsinman, CEO of AMC Bridge, has spent twenty-five years building software for the CAD vendors and integrating their systems for the firms that depend on them, which gives him an unusually clear view of the distance between a prototype that works and an application a business can rely on. We asked him what that estate looks like from the inside, what it really costs to own code rather than write it, and where liability lands when a home brew tool fails.
Discover what’s new in technology for architecture, engineering and construction — read the latest edition of AEC Magazine
👉 Subscribe FREE here
AEC Magazine: AI has set off an explosion of software development inside AEC firms, much of it by people who have never written code before. From where AMC Bridge sits, building software for CAD and engineering developers and integrating systems for large AEC firms, what are you seeing, and how does this wave compare with the earlier shifts to the web and the cloud?
Igor Tsinman: What we are seeing is that people who face the business problem can now test an idea of the solution themselves. They might develop a working prototype without waiting for a conventional software project to be scoped, funded, and staffed. That makes it practically possible to revisit suboptimal workflows companies may have lived with for years because a custom application seemed too expensive or took too long to justify.
Comparisons with the web and cloud are useful, although the effect is different. Cloud/Web technologies changed application accessibility, architecture, deployment, and infrastructure. AI reaches directly into the development process. It helps people get from a problem to something they can evaluate much faster, and it brings more subject-matter experts into that process. It’s not scientific, but our impression is that the adoption of AI technology is much faster than it was for the web and cloud.
This arrives at a time when AEC enterprises need more access to 3D, BIM, and engineering information. That information is increasingly used in construction planning, quality control, procurement, field operations, and other activities outside the original authoring environment. The demand has been there for some time. The effort and specialized knowledge required to build the applications that provide such access have been major constraints.
AI-assisted software development reduces that effort considerably for routine programming and general application logic. As a result, we should expect many more prototypes and internally developed tools. That is generally healthy because firms can explore problems that previously received little attention.
The note of caution, though, is that the transition from a useful experiment to a production-ready enterprise-wide application would require professional help. Before a newly minted application handles live information, modifies a model, or produces an output that other people rely on, it needs to be carefully tested, verified, and secured. Its performance and ability to handle the user load have to be carefully examined. Its maintainability and upgradability must be confirmed. In other words, this part of the application development cycle stays pretty much the same as it is now. Ignoring this part may lead to serious issues down the line. This was true prior to AI-assisted coding, and it remains true today.
AEC Magazine: With AI driving the cost of code towards zero, apps on demand make it economic to solve problems that never justified a commercial product or a developer’s time. Where do you see the biggest opportunities for AEC firms, and how should they decide what to build themselves, what to keep buying, and what to blend?
Igor Tsinman: The biggest opportunities are in the gaps between the systems AEC firms already use. Most firms have capable applications for design, coordination, document management, and project delivery. The friction appears when information moves between them, when a company needs to apply its own checks, or when model data has to support a workflow the original product was never designed to handle.
AI is making these focused applications more economical, particularly where the work involves routine logic and integration. Many of them would never attract a commercial software vendor or justify a conventional development project.
The 80/20 rule remains a useful guide. An established product may cover 80 percent of the requirement, and companies should take full advantage of that. The remaining 20 percent is often where the firm’s own way of working lives: how it checks information, handles exceptions, coordinates disciplines, or applies knowledge gained from previous projects.
That is where a tailored application can also make sense. I would build it on the strongest available foundation, whether that is commercial software, a platform, a database, an API, an SDK, or a specialised engineering component.
In our experience, the best approach is the “blended approach”: buy the proven capabilities already available and build the workflow that is specific to the business. The firm still needs to define and validate the results and decide who is responsible for bringing the application to a production-ready state and maintaining it.
AEC Magazine: Claude Code and Copilot have pushed the cost of a line of code towards zero, but not the cost of an application. Where does the cost of software now sit, and what do AEC firms most underestimate when they move from writing tools to owning them?
Igor Tsinman: Producing routine code is becoming a much smaller part of the overall investment. Most of the cost sits in understanding the workflow, deciding what should be automated, connecting the application to existing systems, and proving that it works reliably with real project information.
Our internal research suggests that AI can reduce coding time by 70–80 percent for routine operations and general logic. The improvement is much smaller in advanced geometry and specialised data, especially in 3D data processing. Those tasks still require mathematical knowledge, experience with engineering systems, and careful verification. Generated code can also contain assumptions that take considerable effort to identify and correct.
What firms often underestimate is the difference between getting a tool to work with a selected set of examples and supporting it across multiple projects. Real data introduces different model structures, incomplete information, unsupported objects, and changing APIs. The application has to handle those conditions predictably.
Then the firm has to own what it has created. Who is responsible for the source code and credentials? Who validates an update? Can someone else maintain the application if the original author leaves?
AI can make the first working version much less expensive. Once the tool becomes part of a production workflow, the firm has to take responsibility for its integration, security, validation, support, and maintenance.
In our experience, the best approach is the “blended approach”: buy the proven capabilities already available and build the workflow that is specific to the business. The firm still needs to define and validate the results and decide who is responsible for bringing the application to a production-ready state and maintaining it.
AEC Magazine: At a recent Boston event on AI in construction, large firms admitted they already have tonnes of vibe-coded applications and no idea what to do with them. What does that estate look like when you get inside a firm, and what should a design IT director do first?
Igor Tsinman: When you look inside, the vibe-coded apps are only the newest layer. Underneath are years of macros, plug-ins, Dynamo and Grasshopper scripts, spreadsheet automation and small project databases. What AI changes is the volume and speed. Tools can now appear in days, sometimes without the documentation or review expected of a supported application. To get the situation under control, an organisation should consider a comprehensive approach rather than a one-off action. That approach should include an amnesty, an audit, and, in some cases, a temporary freeze.
I think it is important to allow people to experiment freely but safely. An organisation needs a secure sandbox where vibe-coded applications can be created and tested. Amnesty should be treated as a discovery process. Some of these tools may be worth scaling, and the people who created them are an invaluable asset to the organisation.
Any application considered ready for production use should undergo a careful audit to confirm it does what it is supposed to do without adversely affecting safety, existing applications and workflows, or network stability. The audit should also identify what data the application can access, whether it can modify production information, which external services it uses, and who understands and supports it.
A broader example comes from our work with a leading research and engineering organisation, where we connect CAD, simulation, Product Lifecycle Management (PLM), Enterprise Resource Planning (ERP), manufacturing, and test systems through a governed digital thread with end-to-end traceability. The project was different in scope, but the same principle applies: organisations need visibility into connected systems, data flows, and ownership.
Having proper processes and release gates in place separates personal experiments from operational dependencies. Experiments can remain in a sandbox. Some tools should be retired. Anything supporting shared project work needs a named owner, company-controlled source code, known dependencies, documentation, and a code review.
Then there’s the freeze. If there is no process in place to audit vibe-coded applications, I would introduce a temporary freeze on releasing them for wider use outside the sandbox. This should apply particularly to applications that write to live project data or send company or client information to external services. The goal is not to stop experimentation. It is to prevent an unverified experiment from becoming an operational dependency before the organisation understands the risk.
AEC Magazine: You describe vibe coding as a proof-of-concept machine that needs an adult in the room. What does hardening a prototype for production actually involve, and how should a firm decide which ones earn that investment? If applications can be generated on demand, and the models writing them are superseded every few months, why not treat most of them as disposable?
Igor Tsinman: We partially addressed this in the previous question. Many prototypes should and will remain disposable. If a tool is used to test an idea or complete a one-time, low-risk task, there may be no reason to turn it into a maintained application.
The approach changes when the tool is reusable, shared inside of the organisation, connected to production systems, or relied on for project delivery. Before investing further, the firm needs to decide what it expects the application to do, how important that function is, and what happens if the application produces the wrong result or stops working.
Preparing it for production means reviewing the generated code and its dependencies, securing access to data and systems, testing it with representative project information, and establishing a repeatable deployment and recovery process. Someone also needs to own future changes and support.
The old principle of “do no harm” still stands. The “adult in the room” needs both software judgment and an understanding of the production context. An assumption about units, coordinates, tolerances, object types, or model versions can produce a result that appears reasonable and is still wrong. The verification process should include the ability to challenge the generated output and decide whether it is suitable for operational use.
The decision whether a POC can be discarded or should become an application to own and maintain should be based, among other things, on the value of the workflow, the number of people depending on it, the information it can access, the systems it can interact with, and the consequences of failure in production.
AEC Magazine: Dynamo and Grasshopper bred a culture in which scripts became personal property, a form of job protection. How do firms stop that repeating with AI-built tools without smothering the kind of experimentation that saw one large practice’s regional office quietly prove Blender could handle work it had always done in Revit? And who owns a tool when its author leaves?
Igor Tsinman: Scripts can become “personal property” or more precisely “personal productivity tools” when the work remains local and sometimes informal. The tool may sit outside the company’s normal development process, with its value and operation understood only by the person who created it. AI-built tools can develop the same dependency much faster.
So, make the work visible, encourage experimentation and the exchange of ideas. Give people a legitimate space to experiment, as mentioned earlier, and recognise tool-building in roles and reviews.
What firms need is a clear point at which an experiment becomes a company application. That happens when it’s shared, reused across projects, connected to production data or built into a repeatable process. At that point, the code, configuration, and dependencies move into company repositories, credentials go into a secure store, and the tool gets a named business owner and technical owner.
The creator should keep the credit and stay involved. Recognition and ownership serve different purposes. The individual deserves credit; the company needs accountability and continuity.
Legal ownership depends on the applicable employment and contractual arrangements. From an operational perspective, the firm still needs access to the code, configuration, dependencies, and knowledge required to maintain the tool.
AI can make the first working version much less expensive. Once the tool becomes part of a production workflow, the firm has to take responsibility for its integration, security, validation, support, and maintenance.
AEC Magazine: Buy, build or blend? Many US contractors have accumulated dozens of disconnected software tools and are now considering building their own applications on platforms such as Autodesk and Bentley. But with Autodesk introducing metered APIs, charging for data access and moving from Revit towards Forma, does building on these platforms simply replace licence fees with usage charges and vendor lock-in? Is the smarter approach to buy specialist tools, build your own, or blend the two while retaining control of your data?
Igor Tsinman: Build can exchange a software license for platform charges if the firm does not examine the commercial model and architecture before it starts. API pricing, data-transfer costs, service limits, and changes to the platform roadmap all become part of the application’s long-term economics.
That does not make platform development the wrong choice. It means the platform has to be treated as a strategic dependency. The firm should understand where its data is stored, how it can retrieve that data, which parts of the application are tied to the platform, and what a future change would require.
This is where blend fits. Companies can use established software, platforms, and engineering components for capabilities already available in the market, then concentrate custom development on the workflows specific to their business. That remains the most practical approach in many of the situations we see.
Again, the 80/20 rule applies. Rebuilding the common 80 percent adds cost and maintenance without creating much business value. The remaining 20 percent may be worth owning because it captures how the company works, handles exceptions, or serves its customers.
“Buy the foundation, build the workflow” describes the approach well. The firm still needs to evaluate the foundation carefully. Its pricing, data access, technical constraints, and direction become part of every application built on top of it.
A good example is the interface AMC Bridge developed for eTakeoff Bridge, connecting Autodesk Navisworks with Sage through bidirectional data exchange. Rather than replacing either product, the integration brought 3D model information into the estimator’s existing workflow, illustrating the value of building the workflow around proven products.
AEC Magazine: Autodesk’s first official Revit MCP server launched in June as a read-only tech preview. At the time, community MCP servers on GitHub were already being used to create and edit elements, while Foster + Partners wrote its own rather than wait. How should a firm decide which MCP server may write to a production model? Your talk at NXT BLD 2026 was MCP-first (watch the presentation), so is MCP the integration layer for the next decade, or a sticking plaster on APIs never designed to be driven this way?
Igor Tsinman: I would allow an MCP server to write to a production model only when the firm knows who maintains it, understands what it can do, and can restrict it to a clearly defined set of operations. Anything with broad or poorly understood write access should remain in the sandbox.
For production use, proposed changes should be visible and authorised. The system needs to validate the request, verify the result, record what changed, and provide a tested recovery path. The firm should also understand what model information reaches the AI client and how that information is handled.
MCP is likely to remain useful as a common way for agents to find and access disconnected systems. I would not make the MCP server itself the foundation of a ten-year integration strategy. That foundation should be the project data and a controlled set of operations with clear permissions and audit records.
If the underlying API has limitations, MCP does not remove them. It gives the agent a more consistent way to reach the API. Firms still need to engineer the safeguards around it.
Our MCP Connector for Autodesk Platform Services and Procore explores this approach in practice, using MCP to orchestrate controlled workflows across BIM and construction-management systems rather than replacing the underlying platform APIs.
AEC Magazine: Common data environments record which person changed a model and when, but none was designed to record what an agent, an MCP server, or a one-off script did to it. When a claim lands, potentially 15 years after completion under the Building Safety Act, and someone asks where a particular script was used, what should a firm be able to produce? Is that the firm’s problem to solve, or the platform vendor’s?
Igor Tsinman: We briefly touched on “write-access restrictions.” In short, I am not sure that we are at the point where we can trust an AI agent in the approval process. An AI agent could help people make these decisions, but I would be very hesitant to allow it to do so independently.
In any case, a firm should be able to show which automated tool was used, where it was used, who authorized it, which version was running, and what project information it read or changed. The record should also show the result, any approval, and whether the action was later corrected or reversed.
Having such logging capabilities should, in the future, allow for a more automated change-management process, including agent involvement.
I do not think that changes made by AI agents and changes made through conventional scripts belong in the same category. The main difference is that scripts are deterministic, while AI agents are not. We have a long history of using systems where script-coded rules are applied in real time to make changes or drive processes. There is a well-defined process for developing, testing, and maintaining such infrastructure. I think it will remain in place.
In summary, platform vendors need to provide reliable identity, versioning, and audit capabilities. The enterprise still has to control which tools are permitted to edit data and make decisions, preserve the relevant records, and understand how automation is being used in project delivery.
AEC Magazine: Every EULA disclaims liability, and at Autodesk University Andrew Anagnost told a room of large customers that Autodesk wants to be their partner, not their competitor, adding: “we don’t really want your liability”. That leaves the risk of home brew code squarely with the firm. Could demonstrable control of code be evidenced to PI insurers and reflected in premiums, and when AMC Bridge hardens a client’s tool, how much of that liability will you carry?
Igor Tsinman: Demonstrable control should give an insurer a clearer picture of the risk. A firm should be able to show which internally developed applications are used in professional work, who owns them, how they are tested and released, and how changes and incidents are recorded. Whether that evidence affects premiums or policy terms is for the insurer and broker to decide.
When AMC Bridge hardens a client’s tool, we stand behind the engineering work we agree to perform. That may include improving the architecture, reviewing the code and dependencies, adding security and deployment controls, and testing the application against agreed requirements.
Our responsibility has to match the scope we control. The client defines the business purpose, supplies the domain knowledge and data, approves the requirements, and controls how the application is used after delivery. We cannot assume responsibility for later modifications, uses outside the agreed scope, or the behaviour of third-party platforms we do not control.
The division of responsibility should be explicit before the work begins. Professional engineering can reduce avoidable technical risk and provide evidence that the application was developed responsibly. It cannot remove every risk associated with the business process or transfer ownership of those risks entirely to the software provider.
AEC Magazine: Firms increasingly regard their project data, and ultimately the client brief, as the one asset they will not hand to a software vendor. A number of large firms want to train their own LLMs on models locally. One US practice is pricing six-figure AI servers for every project team. You have pointed out that self-hosting brings the liability back in-house, so what does running AI and code locally actually demand of a firm, and who is accountable when it fails?
Igor Tsinman: Running AI locally gives the firm more control over where project information is stored and which systems can access it. It also means the firm becomes responsible for operating the environment: infrastructure, security, model and dependency versions, updates, monitoring, and incident response.
We should also be precise about what “running our own AI” means. A firm may be hosting an existing model, adapting it, or connecting it to internal project data. Each approach creates different technical and operational requirements. Buying the hardware is only a visible part of the investment. The continuing cost is the expertise needed to secure, maintain, and validate the system.
Keeping the model inside the firm does not guarantee that its output is correct. It can still work from incomplete information, misunderstand a request, generate unsuitable code, or invoke an engineering tool incorrectly.
The enterprise remains accountable for deciding where the system may be used, what authority it receives, and how its output is reviewed. IT and security can operate the environment, while technical and business owners define the approved use and acceptance criteria.
A system that retrieves information carries a different level of risk from one that writes code or changes a production model. The closer it gets to acting on project information, the stronger the validation, oversight, and evidence need to be.
AEC Magazine: Manufacturing learned change control, configuration management, and release discipline the hard way through PLM, while most AEC firms have never had to manage code at all. If you were writing the code governance policy for a 500-person firm tomorrow, what would be in it, and would it differ between a contractor, where precision is non-negotiable, and a practice happy to take geometry shortcuts?
Igor Tsinman: I would keep the policy short and make the controls depend on how the application is used. If every script needs formal approval, people will work around the process, and the firm will lose visibility into what is being created.
The policy should define where experimentation is allowed, what company or client information may be used, and which systems cannot be connected without approval. It should also establish when a personal tool becomes a company application. Once a tool is shared, reused across projects, connected to controlled data, or relied on for an important decision, it needs a named business owner and technical owner. The source code, credentials, dependencies, and deployment information should be held by the company.
The level of review should follow the consequences of failure. A tool that modifies a production model, calculates quantities, supports fabrication, or contributes to contractual or regulatory information needs controlled testing, releases, logging, and recovery. A limited design experiment can use a lighter process. That is why we talked earlier about keeping experimentation within the sandboxes and applying rigorous audit procedures to the applications to be used in production, especially mission-critical applications.
The firm also needs an inventory of the applications people rely on and a process for retiring them. An API may change, a dependency may lose support, or the original author may leave. A useful application can become a risk if no one remains responsible for it.
I would use the same underlying policy for a contractor and design practice. The required assurance would depend on the purpose of the output. For example, approximate geometry may be acceptable during early design exploration. Once that geometry is used for coordination, quantities, fabrication, construction, or compliance, the acceptance criteria should become much more rigorous.
