DEV Community: Aleksey Suvorov

I asked an AI agent to test my framework. It found the bugs I couldn't see, then built me a debugger.

Aleksey Suvorov — Mon, 05 Oct 2026 03:55:02 +0000

This is part 3. Part 1 is about converting vibe-coded MVPs. Part 2 is the origin story.

My first TypeScript project was a mess

UECA-React was my first real TypeScript work. A year or so after the first version, I looked at it critically. It worked, but it was functionality piled in a heap. Bindings, low-level MobX plumbing, things that should never leak into a business application. My teammates couldn't follow it, and I started hitting bugs I couldn't fix without restructuring. So I rewrote it into proper classes. That was version 2.

It was better, but I still had a problem: the only person who really understood the failure modes was me.

"Can you cover this with tests?"

By then I was using Claude Code with Opus 5. I had a few integration tests, written by hand, but little time for more. So I asked the agent to cover the framework with tests.

It read the code, wrote documentation of how it works, noticed my test style, and started writing tests the same way: tiny UECA applications, with an application component at the root and test components plugged in.

And it started finding bugs. A lot of them. The framework worked in normal situations. In abnormal ones, bindings didn't fire, events were skipped. A framework like this is a complicated state machine, and one human brain can't cover all its transitions. The agent fixed what it found, and the fixing produced new ideas.

Coverage is now above 90%. This is what became version 3.0: mistakes that used to be logged and dropped now throw and reach a single error handler, and React.StrictMode is supported.

The debugger I always wanted

I had known for years that a visual trace viewer could be built, but never had the time. The agent saw my tracing system, improved it to carry more useful information, and built the viewer: component tree, message bus traffic, bindings, with stop and playback.

I didn't write a line of it. It comes straight out of the architecture, because everything in a UECA app is the same kind of component, so everything can be traced the same way.

Even if an AI writes the whole application, you can open the viewer and see whether the architecture is right: components created when they shouldn't be, messages flying where you didn't expect.

A plot twist

I first asked the agent to write the viewer in plain React, deliberately. Then I had it rewrite the viewer in UECA-React, the framework the viewer inspects. I measured both versions. The UECA one was faster.

Does architecture still matter?

Honestly, I don't know. Future models may write raw low-level React from scratch, and nobody will be able to check it by eye or care. We are already at the point where reading all the generated code isn't realistic.

But if there's a chance to take a step toward a better architecture, I think it's worth taking. Same shape everywhere, predictable behavior, an agent that can't drift because the pattern leaves no room to. That's the bet UECA-React makes.

Try it

npm: https://www.npmjs.com/package/ueca-react
Architecture and ideas, explained in an app built with UECA-React itself: https://nekutuzov.github.io/ueca-react-website-public/

Do you let agents write most of your code? What's the thing that breaks first?

How a struggling React project and an old Delphi habit led me to build a framework

Aleksey Suvorov — Mon, 05 Oct 2026 03:46:03 +0000

This is part 2. Part 1 shows how to turn a vibe-coded MVP into something an AI agent can keep extending. Here is where UECA-React came from.

A project in trouble

In 2022 my company was rewriting a legacy web app: .NET Core on the server, React with Blueprint.js and MobX on the client. We are a small team. No dedicated designer, no business analyst.

I was on other projects and watched from the side. After a year of work, the code looked like a pile of low-level React with props drilled everywhere, and every developer had their own idea of how to build a layout. I could see it wasn't going to fly. I was worried the project would be shut down and the team cut.

So I decided to help.

The Delphi habit

I'm not a web developer by background. I grew up on Delphi, which I first saw in 1995. What struck me then was how clear frontend development could be: a component has properties, events and a visual part, and you build applications from them.

Even in Delphi I never wrote low-level code. I built reusable building blocks first and assembled applications from them. One more idea came from my old report-writer IDE: a message bus. A component shouldn't know who answers it, only that someone will. Picture a loud party where someone shouts "turn the music down!" The shouter doesn't know who is at the stereo, but the music gets quieter.

I spent a few months learning JavaScript, TypeScript, HTML and CSS properly. Then it clicked: with TypeScript's literal types you can generate things like onChange events for every property automatically. A component could be a black box with state, events, methods, children and a view, and every component could look the same.

Rails

I wrote the first version and showed it to the team. Developers are conservative, and they were wary. But the pattern leaves little room for improvisation. You write it the way the documentation says, like riding on rails.

After a couple of screens, the speed difference was obvious. Within a few months the team was rewriting those tangled screens on their own. The project was saved, and so were the jobs. Everyone still works there.

The name and the first AI help

The name, Unified Encapsulated Component Architecture, came from ChatGPT, which also helped me write the first documentation. I had designed the pattern with machine-generated code in mind before ChatGPT even existed. When models got good enough, the idea simply worked. I wrapped MUI components with Copilot, then moved to Claude Code.

What's next

The most surprising chapter was version 3.0, when an AI agent found bugs in my own code, wrote the tests, and built the framework's trace viewer. That's the next post.

In the meantime:

npm: https://www.npmjs.com/package/ueca-react
Architecture and ideas, explained in an app built with UECA-React itself: https://nekutuzov.github.io/ueca-react-website-public/

Your vibe-coded MVP works. Now make it something an AI agent can keep building.

Aleksey Suvorov — Mon, 05 Oct 2026 03:31:45 +0000

You asked an AI for an app and got a working prototype: one HTML file, some dashboard, maybe a 3D model you can spin around. It's impressive.

Then you ask for the next feature, and the agent breaks two old ones.

This is the usual end of a vibe-coded MVP. Everything lives in one pile, with no real architecture. As the code grows, the agent's context fills up, it gets confused, and every change becomes a gamble. A human can't easily make sense of it either.

The fix: give the prototype a skeleton

I built UECA-React, a React framework designed for AI agents. Every component has exactly the same shape: a struct (props, events, methods, children, lifecycle), a model hook, and a functional component. At every level of the app, top or bottom, the structure is identical.

That uniformity is what helps the agent. It doesn't need your whole codebase in its head, because once it has seen one component, it has seen the pattern.

How to convert an MVP

Install the agent skills that ship inside the package:

   npm install ueca-react
   npx ueca-react-skills

Give your agent the prototype and say:

Rewrite this app using UECA-React.

Keep developing from there.

In my experience the rewrite looks nearly identical on screen, but underneath you now have a real project: components composed into screens, a barebone app structure to build on, and a message bus that abstracts the API, so the agent works only with components and their interactions.

From that point, adding features is incremental. No rabbit holes, no collateral damage.

And you can see what it built

Add <UECA.TraceViewerButton /> to your app root to open a live view of the component tree, the message bus, and every binding. Even if an agent wrote all the code, you can check the architecture without reading it.

Try it

npm: https://www.npmjs.com/package/ueca-react
Architecture and ideas, explained in an app built with UECA-React itself: https://nekutuzov.github.io/ueca-react-website-public/

I'll share the origin story in the next post: how a legacy-app rescue and an old Delphi habit led to this framework.

Have a vibe-coded prototype stuck at "works, but can't grow"? Tell me in the comments what it is.