An AI-built prototype cannot be changed safely
A prototype generated with AI tools works in a demo, and each targeted change breaks something elsewhere.
Possible signs include tightly coupled code, unclear component boundaries and generation artefacts; inspect the implementation rather than inferring quality from how it was created.
Key facts
- Inspect whether tightly coupled code, missing tests or unclear component boundaries make changes unsafe.
- A small fix breaks an unrelated screen.
- The prototype shows a possible look without defining users and scenarios.
- Restructuring costs more up front than owners usually expect.
- The prototype remains useful as a reference.
Why it happens
Generated for a demo. It shows how the product might look.
No component structure. Each change touches everything.
The prototype answers how the product could look. Who uses it, for which tasks and with what data stays open, so there is nothing stable to measure changes against.
How it shows up
- The whole product lives in one very large file
- A small fix breaks an unrelated screen
- Type sizes and themes are inconsistent
- Primary actions are hidden and back navigation fails
- Nobody has written down who the users are
Options and trade-offs
What helps:
- Define roles and scenarios first
- Extract components and tokens
- Rebuild the key flows on that structure
- Keep the prototype as a reference
The tension: continuing on the generated prototype keeps momentum and compounds its structural problems. Restructuring costs more up front than owners usually expect.
Investors and early customers may have seen the prototype. Changes to what they saw need explaining, even when the new structure is better.
Common mistakes
- Asking the tool for more fixes on a structure that cannot hold them
- Treating the prototype’s look as a specification
- Skipping roles and scenarios because the screens already exist
- Discarding the prototype entirely and losing what it showed