For more than a decade, choosing a framework has been the opening move of every front-end project. React, Angular, Vue, Svelte, Next.js: these technologies were never just tools. They shaped product architecture, structured hiring, organized teams, and framed testing practices.
Today, the arrival of AI agents is shaking up that certainty. Not because frameworks have become useless, but because they were designed to meet the needs of human developers. Once part of the code is produced by agents, the constraints change in nature.
The question is no longer just: which framework should we choose?
It becomes: what information, rules and guardrails does an agent need to build a reliable interface?
Frameworks were built for people, not browsers
Building a complex application without shared conventions is a headache. A team has to agree on how to break down an interface, manage state, move data around, handle navigation and reuse components.
Frameworks provide common answers to these problems. They reduce cognitive load, speed up onboarding for new developers, and spare every team from reinventing its own architecture. This standardization makes perfect sense when code is written, reviewed, and maintained by humans.
The browser, however, knows nothing about React components, Vue templates or Angular decorators. Whatever the technology, the source code is transformed, bundled, optimized and sometimes shipped with a runtime, so that at the end of the chain, the Web platform only ever interprets HTML, CSS and JavaScript.
A framework is therefore nothing more than an abstraction between the developer’s intent and the standards the browser executes. If an agent can go straight from intent to a compliant implementation, that abstraction deserves to be questioned.
Under the hood: hard decisions, not convenience
Describing frameworks as simple comfort tools would be reductive, though. They settle many technical decisions: DOM updates, component lifecycle, state management, routing, code loading, server-side rendering, hydration, error handling, style isolation.
Depending on the problem, they adopt different strategies. Angular emulates style encapsulation by default, Svelte scopes styles at compile time, and Web Components-based solutions rely on the Shadow DOM. React and Vue use a virtual DOM, not to isolate styles, but to orchestrate interface updates when state changes.
An agent writing native JavaScript doesn’t have to reinvent all these mechanisms: the Shadow DOM, for instance, is already a browser API. It does, however, must decide when to use it and organize everything around it: lifecycle, events, accessibility, customization, integration with the rest of the application.
The same logic applies to every function a framework usually handles. The agent can rely on Web standards, use specialized libraries, or generate a custom solution. But the decisions don’t disappear; they move into the specifications, the architecture rules and the validation pipeline of the software factory.
Beware the framework you didn’t mean to build
The real risk is replacing a recognized framework with a pile of specific mechanisms, unintentionally creating an internal framework that is less documented and less proven than the ones it claims to replace. Code generation lowers the cost of implementation, not the cost of poor architecture choices.
Frameworks can therefore lose their centrality without losing their value. They remain in coherent sets of technical decisions, proven at scale. The point is not to rule them out on principle, but to check whether their abstractions are justified by the product’s actual needs, or whether native standards are enough.
In short, AI doesn’t eliminate the decisions frameworks to take care of. It lets us choose more freely where those decisions should live. In an agent-assisted software factory, the choice between a framework and native JavaScript should rest on concrete criteria: functional complexity, performance, SEO, maintainability, compatibility, lifespan, and integration with existing systems.
Agents don’t think like developers
A developer must memorize and mentally manipulate the structure of a project. An agent faces different limits: the amount of context it can access the reliability of its sources, the ambiguity of its instructions, and its ability to verify the consequences of its changes.
It can browse a repository, query documentation, analyze dependencies, and check its output against formalized rules. So, it doesn’t necessarily need a project to follow the conventions of a popular framework to work effectively.
That doesn’t mean it can work without architecture. Quite the opposite. It needs an explicit environment: component responsibilities, technical constraints, expected behaviors, and acceptance criteria. Everything must be accessible and verifiable.
That’s the difference: for a human team, this structure is often embodied by the framework and its conventions. For an agent, it can just as well be described through contracts, metadata, executable rules, and tests.
Value thus shifts from the choice of tool to the quality of the context provided.
Inside an AI-ready software factory
Picture an organization with a Design System that is independent of any front-end technology. Its components wouldn’t be defined as React or Vue components, but as interface objects described by:
- their appearance and variants;
- their properties and states;
- their behavior;
- their accessibility rules;
- their design tokens;
- their conditions of use.
User journeys would be designed in Figma, data exchanges described by API contracts, and non-functional requirements built into the validation pipeline. Starting from a user story, a front-end agent could then consult the mockup, identify the Design System elements, retrieve the necessary specifications, and produce the interface in the technology best suited to the project.
That implementation could use React, Vue, or another framework to fit into an existing product. But it could just as well be built in native HTML, CSS and JavaScript, if the needs don’t justify an extra dependency.
In this model, the Design System is no longer just a visual library. It becomes a source of truth that both teams and machines can use.
MCP: handing agents the keys to the enterprise
This approach assumes that an agent can access the company’s various information sources through a standardized protocol, the Model Context Protocol (MCP). MCP servers can expose, in a uniform way, Figma mockups, the component catalog, product documentation, API contracts, the code repository, or testing tools.
MCP is neither a front-end framework nor an application architecture. It doesn’t dictate how the interface should be built: it makes it easier for the agent to access the resources and tools it needs.
The distinction matters: frameworks provide conventions for building applications, while MCP servers give agents standardized access to the company’s context sources and tools.
As a result, the agent doesn’t work from a single isolated prompt. It operates in an environment where authoritative sources are identified, rules can be consulted, and output can be evaluated automatically.
From foundation to option
In such an organization, the framework stops being the foundation around which the product is designed. It becomes an implementation option, chosen according to the project’s constraints. The same specification could lead to several solutions:
- React, to integrate with an existing application;
- Web Components, to distribute reusable elements;
- native JavaScript, for a lightweight interface;
- a server-side rendering solution, to meet SEO or performance constraints;
- a specific technology, for a device or an embedded environment.
The choice doesn’t disappear it becomes more pragmatic. It no longer rests on a team’s preferences or the trends of the moment, but on the weight of the code sent to the browser, the expected compatibility, the frequency of updates, the product’s lifespan, and its integration with the information system.
The framework loses its status as a technical identity and goes back to what it probably always should have been: one means among others of meeting a need.
Could AI send everyone back to native?
Frameworks took hold because they simplified problems that were hard to handle manually: interface composition, reactivity, routing, state synchronization, cross-browser compatibility.
Meanwhile, the Web platform has made considerable progress. JavaScript modules, Custom Elements, Shadow DOM, modern CSS features: it now natively covers needs that used to require specialized libraries. Still, the main obstacle remains the human cost: writing and maintaining a specific implementation takes time, rigor and expertise that is rarely evenly spread across a team.
Agents can change that trade-off. If they can generate the code, check its compatibility and maintain reliable documentation, systematically reaching for a framework becomes less obvious.
Native can then offer several advantages: fewer dependencies, more direct control over the shipped code, potentially lighter bundles, and a lifespan better aligned with that of Web standards.
Native is no free pass to simplicity
Generating native JavaScript doesn’t guarantee simpler software, though. Without architecture principles, piling up specific code can, as mentioned earlier, gradually build an implicit internal framework, less documented and less proven than the solutions it replaces.
The goal is therefore not to rule out frameworks on principle, but to avoid choosing them by reflex. Every abstraction must prove its value considering the product’s complexity, performance, maintainability, and operations.
Your code is no longer your strategic asset
Code generation is becoming commonplace. Quickly producing a component or a page will soon no longer be a lasting competitive advantage. The difference will lie elsewhere: in a company’s ability to formalize its knowledge.
In practice, this means turning its visual identity into usable tokens, describing its components independently of their implementation, making its architecture rules explicit, exposing reliable API contracts, automating security, performance and accessibility checks, and comparing the output against design and product intent.
A powerful but poorly contextualized agent will quickly produce a mediocre result. Conversely, a well-structured environment makes implementations more consistent, whatever technology is chosen.
The strategic asset is no longer just the source code. It is the body of knowledge that makes it possible to generate, evaluate, and evolve that code.
After Developer Experience comes Agent Experience
Teams have invested heavily in Developer Experience: local tooling, documentation, conventions, faster builds, reusable components. That effort now needs to be complemented by thinking about Agent Experience.
An agent must be able to determine, without ambiguity, which sources are reliable, which files it is allowed to modify and how to validate its work. Errors must come back to it in a usable form, so it can fix them without multiplying interpretations.
This shift isn’t about optimizing a machine’s comfort. Above all, it forces organizations to make explicit knowledge that was previously scattered across people, documents and tools. And what improves the agent’s experience ends up benefiting human teams too: clearer documentation, better-defined contracts, more systematic validation.
Choose your framework last, not first
AI agents are changing the way we design and build front-end applications. They make it possible to start from a product intent, a Figma mockup, and a technology-agnostic Design System to generate code, run tests, check accessibility and measure performance.
This shift calls into question the place of JavaScript frameworks in architecture decisions. React, Angular and Vue bring component models, state management mechanisms, conventions and ecosystems that structure front-end development today. With agents, some of these abstractions can be generated on demand, tailored to the application’s needs, or replaced by more specific implementations.
Choosing a framework can now come after defining the expected software, its constraints and the mechanisms it needs to function.
This shift also moves the demands placed on software engineering. The quality of specifications, interface contracts, standards and validation systems directly determines agents’ ability to produce reliable code and keep it evolving.
An organization must therefore be able to describe precisely how its applications are expected to behave, give agents the context they need to build them, and have the means to verify every change, regardless of the technologies used.
Are you asking yourself these questions in your own projects? Our teams are already helping organizations build AI-ready software factories, from architecture choices to setting up context that agents can use. Talk to our Software Engineering experts to discuss it.
By Frédéric Lepault, Fullstack Tech Lead.
Frédéric Lepault is an experienced software engineering professional at CBTW, with a strong technical background in Java/Spring, Angular, DevOps, Oracle and Agile/Scrum environments. His profile reflects hands-on expertise across software development, cloud and modern delivery practices, combined with experience working in complex IT project environments.
