DEV Community

Aleksey Suvorov
Aleksey Suvorov

Posted on AI-assisted

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

#react #ai #webdev #typescript

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

  1. Install the agent skills that ship inside the package: 
   npm install ueca-react
   npx ueca-react-skills
Enter fullscreen mode Exit fullscreen mode
  1. Give your agent the prototype and say:

Rewrite this app using UECA-React.

  1. 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

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 (2)

Collapse
 
elijahbrown profile image
Elijah Brown • • Edited

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.

Collapse
 
nekutuzov profile image
Aleksey Suvorov • • Edited

Thanks, Elijah, you’ve put your finger on the step I left out of the article. The way I actually rewrite an app starts exactly there. Every step is done by an agent, and the developer reviews and approves in between:

  1. Document the old app. An agent writes the documentation as Markdown files: every screen, its fields, what’s required, the formats and the business rules. Most rules it can infer from the code; the developer fills in the business context the code can’t show. It can also write and run tests, fix simple oversights it finds, and write up the bigger problems with possible solutions. From those files an agent then generates an LLM wiki, and everything after this step reads the wiki rather than the raw files. The wiki is optional, but I’d recommend one for any documentation you hand an agent.

  2. Plan. A second agent reads the wiki together with the old code and writes an implementation plan for the UECA-React app.

  3. Build. A third agent follows the plan: it creates the project and the code, writes tests, fixes what they find, and writes the release notes.

That documentation is the knowledge base everything after it is built on, and it’s exactly where your input rules belong: written down before anyone re-infers them, then checked by tests on the new app. It also means the old app has to work. A prototype that does the right things with a messy structure is a fine starting point; one whose behaviour nobody trusts isn’t.

UECA’s own documentation is built the same way and ships with the package: the original Markdown in docs/raw, the generated wiki in docs/wiki. The rewrite process itself isn’t in the migration guide yet, so I’ll add it there.