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.
Top comments (1)
The "looks nearly identical on screen" part is where I would add one step before the rewrite prompt. Write down the input rules the prototype has today: which fields are required, what the email and phone fields accept, max lengths, what happens on a duplicate signup. Screens survive a rewrite well, but those rules are easy for an agent to re-infer slightly differently, and nobody notices until a real user gets rejected or a bad row gets through.