This is part 3. Part 1 is about converting vibe-coded MVPs. Part 2 is the origin story.
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.
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.
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.
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.
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.
Do you let agents write most of your code? What's the thing that breaks first?