Why Your Vibe-Coded App Breaks Every Time You Add a Feature (and the Fix)

Every feature request you send makes the agent add code. Where it adds that code is decided by the agent, in the moment, based on what it can see in the file it is editing. Without a fixed structure, the fastest place to add a feature is inside whatever is already there: a view that also holds state, a screen that also calls the network, a shared object that every screen reads and writes.

Each of those shortcuts works on the day it is written. The cost comes later. When you change the shared object for feature seven, screens two and four, which read it in ways nobody documented, change behaviour. The agent did not touch them, so it did not test them. You find the bug, you ask for a fix, the fix is another shortcut, and two more screens depend on it.

Each added feature can cause bugs in unrelated parts of the app, and each rushed fix can introduce more. The problem compounds even when the agent follows every request.

The important word is following. The agent did what you asked. Nothing told it how to add a feature so that the next feature stays cheap.

People ask at what size this starts: five screens, ten, fifteen. The size does not predict it. What predicts it is how long the app has to keep changing.

A demo app that shows a component library, with no backend and no updates after it ships, can be built any way at all. It will never get feature seven. A product with real users gets feedback from every one of them, and you will have your own ideas every week. If you are going to keep adding features for months after release, the shortcuts compound, and the month the app becomes unmaintainable is the month you had the most users.

So the question to ask before the first prompt is not "how many screens" but "will I still be adding features to this in six months". If yes, the structure has to exist before the agent writes the first feature, because migrating later means rebuilding.

There are two things that keep an agent-built project manageable over time. Neither is a better model.

1. An architecture the agent is required to follow. A fixed answer to "where does this go": where state lives, where actions that change it live, where side effects such as network calls live, how a screen reads state and never writes it directly. When every feature is built from the same few block types, a change in one block cannot silently change another, because the dependencies are explicit.

Modaal ships this as Duet, its own architecture framework, built from the parts of established iOS and Android architectures that survived a decade of large apps. Each feature's logic is written once and rendered in SwiftUI on iPhone and Jetpack Compose on Android; the agent is taught the rules of the framework and works inside them, so feature twelve is built the same way as feature one. The Duet page has the block types and the rules.

There is a second version of the same failure that hits Claude Code users specifically: the codebase outgrows the context window, you clear the session, and the agent forgets how the app is structured, so feature ten is built to a different plan than feature one. Building iOS apps with Claude Code covers that side; an architecture on disk is the fix for both, because it is what the agent re-reads after every clear.

2. Tests that run on every change. An architecture makes a project testable; the tests are what turn that into a signal. In a Modaal project, integration tests run continuously. When the agent's change to feature seven breaks screen two, the agent gets that signal before you do and fixes it while the change is still small. Without the tests, the same bug surfaces when you tap screen two next week, with three more changes stacked on top of it.

A good architecture keeps the project manageable over time, so adding features does not have to increase complexity or break unrelated screens.

None of this requires Modaal. It requires you to take over the role Modaal plays. Concretely:

Pick an architecture and write it into the project rules file so the agent reads it on every session. Tell it which architecture, which block types, and where each kind of code goes. Ask it to restate the rules back to you before it starts a feature.

Tell the agent to write tests for each feature and to run the whole suite after every change, not only the tests for the new feature. Check that it did. Agents skip this step when nothing forces them.

Review each feature against the rules, not only against "does it work". A feature that works and breaks the structure is the shortcut that costs you later.

Decide the platform question now. If you want iOS and Android with native UI on each, there is no cross-platform framework that gives you an established architecture and native idiom on both. React Native, Flutter and Kotlin Multiplatform give you one codebase that looks the same on both platforms and native on neither; switching later is a rewrite. Native vs cross-platform lays out the trade.

This is a lot of supervision for a person who came to vibe coding to avoid supervision. That is the trade: do the structural work yourself in Claude Code, or use a tool that has already done it and lets your agent work inside it.

Modaal runs on your Mac, on the Claude, Cursor or Codex subscription you already pay for; it does not charge for tokens. What it adds on top of the agent is the workflow a mobile agency runs: requirements, information flow, UX map, screens, and then code inside the architecture above, with the tests running. The project is on your disk, in Xcode and Android Studio, from the first feature.

What it does not add: for a two-screen app with no backend, no login and no plan to update it, Modaal will not give you much beyond what Claude Code already does. In that case, a lighter tool may do the job. Use the lightest tool that fits, and pick the structured one when the app has to keep changing.