Dominic Jainy stands at the forefront of a major shift in how we conceive of software architecture in this era of autonomous agents. As an expert who has watched the industry oscillate between high-level abstractions and low-level code, he brings a unique perspective on why the “wildly prolific” AI agents of 2026 need more than just raw processing power—they need a structured ecosystem. Jainy’s work focuses on reviving the philosophy of component-based development, drawing parallels between the 1994 “Componentware” revolution and today’s generative UI trends. He argues that by providing agents with observable, governable building blocks rather than just blank canvases, we can finally bridge the gap between rapid automation and enterprise-grade reliability.
In this discussion, we explore the evolution of component architecture, the specific mechanics of the XMLUI framework, and the critical importance of semantic tracing for AI-driven systems. Jainy delves into the risks of “bespoke” agent code and explains how standardized components allow hybrid teams to maintain security and policy enforcement without stifling innovation.
Looking back at the history of software reuse, you’ve noted a significant shift where development moved away from domain experts toward specialized coders. How has this transition impacted our ability to build and maintain complex systems today?
The evolution of software reuse has been a bit of a rollercoaster, especially when you look at the legacy of the 1994 “Componentware” era. Back then, Visual Basic essentially flipped the script by creating a two-tier architecture where code-savvy component builders provided the blocks, and domain-savvy systems thinkers wired them together. This allowed people who understood the business logic—the “domain experts”—to build solutions without needing to be master programmers. However, when the web took over, we largely abandoned that model for specialized frameworks like React, which, despite its merits, requires specialized coders for both production and consumption. This has created a bottleneck where modern solution builders can’t easily tap into a component ecosystem without deep technical overhead. Today, as we see agents becoming the primary builders, we are realizing that forcing them to write low-level code from scratch is inefficient and prone to errors that a managed, component-based layer would simply abolish.
You’ve mentioned that XMLUI harks back to the Visual Basic model by using concise semantic markup. How does this declarative approach change the way an AI agent interacts with a user interface compared to writing traditional React or CSS?
When an agent writes declarative markup in a framework like XMLUI, the entire conversation between the human and the machine shifts toward intent rather than implementation. In a traditional React environment, an agent has to worry about dependency arrays, naming cleanup functions, and managing complex state logic, which are all places where “hallucinations” or bugs can hide. With semantic XML markup, the agent simply refers to a catalog of trusted components, such as a “Stack” or a “Table,” and the runtime handles the heavy lifting. For instance, using lifecycle hooks like “onMount” and “onUnmount” in this managed environment means there is nothing for the agent to forget or misconfigure. We like to say that this is to React what Java was to C++—a way to provide a managed layer that prevents a whole class of vulnerabilities while still allowing developers to pierce the abstraction when it is absolutely necessary.
One of the most striking features you’ve discussed is “semantic tracing.” Could you explain how wrapping React components in this way allows an AI to “reason” about what is happening on a screen?
Semantic tracing is the key to moving beyond the “black box” nature of modern web interfaces, particularly when those interfaces are being navigated or built by AI. By using the “aria-label” property as a component’s accessible name, we can record traces that are actually readable and logical, like “Volume, slider, 53” instead of just a generic coordinate click. This is incredibly powerful for UI elements like a canvas; normally, a browser just sees a rectangle of pixels, but our wrapper allows the trace to record that a user clicked “Q2” on a “Revenue by Quarter” bar chart. When an agent receives a bug report saying “the chart did something weird,” a UI built from these traceable components can provide a precise history of API calls, handler timings, and data changes. This consistency allows the next agent in the chain to understand exactly what happened without having to invent its own idiosyncratic conventions for instrumentation.
Beyond the user interface, you talk about the “iceberg” of code—the risky work involving security and protocols. Why is it dangerous to let an agent write a bespoke SFTP client or encryption logic from scratch, even if it seems to work initially?
The real world is incredibly messy, and bespoke code written by an agent in an afternoon simply cannot account for the decades of edge cases that a dedicated component has absorbed. Companies like /n software have been building components for protocols like SSH, SSL, and SFTP since the 1990s, and those parts have connected to thousands of different counterparties over the years. When a vulnerability is discovered in a standard protocol, a maintained component delivers a fix to every user immediately, whereas a custom-coded agent solution might remain vulnerable indefinitely. Furthermore, a component-based approach allows the runtime to enforce organizational policies—such as requiring host-key verification or checking a partner list—before the code even runs. If an agent builds a finance app that attempts to send a 48 KB invoice batch to an unregistered host, the component can block the action and report exactly why, rather than failing silently or insecurely.
When we think about the future of hybrid teams where humans and agents work together, how does a shared vocabulary of components improve the governance and safety of the apps being produced?
Governance in an agent-centric world requires us to move beyond simple logging and toward a system where we can validate how parts are configured before they are even deployed. When we use a component architecture, every app built by an agent is made of known, observable parts that follow a shared vocabulary, which makes reviewing and maintaining those apps much easier for human supervisors. We can see a trace that shows a user selected 12 rows in a “Pending Invoices” table and clicked “Send,” and we can verify that the SFTP component successfully verified the host-key before encountering a “permission denied” error on the remote side. This level of clarity ensures that the apps reflect the experience and judgment of domain experts rather than the raw, unguided output of a language model. It essentially provides a safety net that allows agents to be prolific without being reckless, ensuring that every deployment is trusted, observable, and governable.
What is your forecast for the evolution of component-based systems as AI agents become the primary developers of enterprise software?
I believe we are heading toward a “Great Standardization” where the value of bespoke, hand-crafted code will diminish in favor of robust, pre-certified component ecosystems. By the end of 2026, we will likely see the web’s own component standards being reconsidered to better serve agentic builders who need a structured contract between the component and the container. We will move away from agents writing thousands of lines of integration code and toward agents “orchestrating” sophisticated, high-level modules that come with built-in security, accessibility, and tracing. This shift will empower domain experts to once again take the lead in solution building, using AI as the “wiring” mechanism to create complex, secure applications at a speed that was previously unthinkable, all while maintaining a rigorous level of institutional control.