When an AI agent builds a screen for you, the slow part is no longer writing the code. It is reviewing it. You have to read what the agent produced and decide if you trust it. The more code it writes, the more you have to read, and the more places a subtle mistake can hide.
This is where web components help the most. They let the agent write less and, more importantly, let you review less. For business applications, this fits perfectly, and I will show why with plain HTML.
Less code to review is the point
An AI agent that builds a business screen does not have to generate the internals of a date picker or a data grid. It only writes the small declarative surface: the tags, a few attributes, and a few event listeners.
Here is part of an invoice form. This is the whole thing the agent writes, and the whole thing you review:
<form-section label="Customer"> <text-field name="company" label="Company"></text-field> <text-field name="vat" label="VAT number"></text-field> </form-section> <form-section label="Invoice"> <date-field name="date" label="Invoice date"></date-field> <money-field name="amount" label="Amount" currency="CHF"></money-field> <status-badge status="open">Open</status-badge> </form-section>
Look at how little is here. A few tags and a few attributes. Whether the date field handles the Swiss date format, whether the money field validates input and shows CHF correctly, and whether the fields are reachable by keyboard, all of that sits inside the components. The agent does not write it, and you do not review it.
When you need interaction, you stay in plain DOM. No framework needed:
<money-field id="amount" currency="CHF"></money-field>
<script>
document.querySelector("#amount").addEventListener("change", (event) => {
console.log("new amount", event.target.value);
});
</script>
Attributes go in, events come out. That is the whole contract, and it is the whole review.
There is also a safety effect. A web component has a hard boundary (more on that below). The agent cannot reach inside it and quietly break its styles or behavior. So the blast radius of anything the agent does stays small. That is a big deal when you review AI output, because you can trust the parts you did not have to read.
One condition makes all of this work. The agent has to know the components exist and has to know their API. If it does not, it will happily build a worse version from scratch, and you are back to reviewing a pile of code. So a clear, documented component set, with a simple index or manifest the agent can read, is what unlocks the benefit. Give the agent the right building blocks and the right specs up front, and it will reach for them instead of reinventing them.
Why business apps make this easy
Web components get a lot of pushback, and most of it is about one thing: SEO and server-side rendering. People worry that shadow DOM hides text from search crawlers, or that a single-page app needs server rendering to show up well in Google.
For a public marketing site, that is a fair concern. But a business application is not a marketing site. It lives behind a login. A known user signs in, then works with data: customers, invoices, orders, and schedules. There is no landing page to rank and no crawler to please. The content is private by design.
So the trade-off public sites worry about simply isn’t there. You never needed search visibility in the first place. That means you can use the full power of web components, shadow DOM included, with a clear conscience. The thing that makes the agent’s benefit possible is exactly the thing that public sites give up.
What does the hard boundary give you
Shadow DOM is a real wall. Styles inside a component do not leak out, and styles from the page do not leak in. The behavior is contained. In a large app with many screens and many hands, this removes a whole class of “why did this button change color on that one page” bugs.
Here is a small component defined in plain HTML and JavaScript. It shows the boundary. The styles inside never touch the rest of the page:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<script>
class StatusBadge extends HTMLElement {
connectedCallback() {
const status = this.getAttribute("status") || "open";
const root = this.attachShadow({ mode: "open" });
root.innerHTML = `
<style>
.badge {
font: 13px sans-serif;
padding: 2px 8px;
border-radius: 10px;
color: white;
background: ${status === "paid" ? "#2e7d32" : "#c62828"};
}
</style>
<span class="badge"><slot></slot></span>
`;
}
}
customElements.define("status-badge", StatusBadge);
</script>
</head>
<body>
<status-badge status="paid">Paid</status-badge>
<status-badge status="open">Open</status-badge>
</body>
</html>
The .badge style is locked inside the shadow root. No page CSS can break it, and it cannot break the page. There is also no build step. A web component is just an HTML element, so you can load it with a script tag and use it. For an internal tool, plain HTML can be enough.
You do not have to build the set yourself
In the examples above, I used my own components, but you do not have to start from zero. Vaadin is a good example. Vaadin is built on web components. Its whole component set, the text fields, date pickers, combo boxes, the data grid, dialogs, and many more, are standard web components under the hood.
The nice part is that you can use them without Vaadin. You do not need the Vaadin Java framework or Hilla to use them. Because they are plain web components, they work in any page, in plain HTML, in React, in Angular, or in nothing at all. You install the parts you need and import them:
<script type="module"> import "@vaadin/text-field"; import "@vaadin/date-picker"; </script> <vaadin-text-field label="Company"></vaadin-text-field> <vaadin-date-picker label="Invoice date"></vaadin-date-picker>
So, for a business app, you can take a large, well-tested, well-documented set of components built by a team that has worked on this for years and just use the tags. The Swiss date format, keyboard handling, and accessibility are all already done and maintained for you. For an AI agent, this is the ideal target: a known set of strong building blocks it can point to instead of generating its own.
Keep it simple
The slow part of working with an AI agent is reviewing what it wrote. Web components shrink that work. The agent writes a small declarative surface; the hard parts stay within tested components; and the boundary keeps mistakes contained. Business apps make this easy because there is no SEO to protect, so you can use the full model. Less code to generate, less code to review, and a stable contract in between.
