You built an app in Rork, it works, and then you think, "just one more small feature." For me it was adding a monthly chart to a simple budget app — a request that ended with half of yesterday's code rewritten and a full rollback to the previous morning. If you've used Rork for more than a few weeks, you've probably hit some version of this: a polite request that leaves the working parts of your app in shambles.
The frustrating thing is that this isn't really a Rork limitation. It's a communication gap. When we ask an AI to extend an existing codebase, we tend to describe what we want added and forget to describe what we don't want touched. The rest of this post walks through the five moves that changed my hit rate from "maybe half the time" to "almost always" — all built from real mistakes.
Three ways Rork's AI goes off the rails during feature addition
Before fixes, it helps to name the failure modes clearly. In my experience, botched feature additions fall into three buckets.
The first is silent rewrites of existing code. You ask for a chart, and suddenly your input form has been swapped for a different library, with different props, different styling, and a behavior you never approved.
The second is invisible file restructuring. The logic that lived in screens/HomeScreen.tsx has been quietly moved under components/Dashboard/. The app may still run, but your next prompt will land in a file that no longer matches the map in your head.
The third is collateral damage in unrelated screens. You ask to tweak the settings page color, and the home screen header has also shifted. This one is the hardest to predict and the most disorienting when it happens.
All three share the same root cause: the model's picture of "what currently exists" is vague, so it makes plausible but unwelcome changes. When we share context with another human and skip the preconditions, conversations drift. The same pattern plays out with AI — the more precise the preconditions, the steadier the result.
Give the target a precise "street address"
The single highest-impact fix is to name the exact file path and function you want the change to land in. Instead of "add a chart to the home screen," write "add a monthly aggregation chart directly below the renderSummary function in screens/HomeScreen.tsx."
Just adding the filename helps. But when you also quote the existing component names, variable names, and state slices, the AI is pulled toward reading the current code rather than reinventing it.
✅ A prompt that tends to work
"In screens/HomeScreen.tsx, directly below the `renderTransactionList`
component, add a new component called `MonthlyChart`. It should receive
the existing `transactions` state (managed in App.tsx) via props and
display a monthly aggregation. Do not modify the `renderTransactionList`
component or the `transactions` state logic in any way."This prompt tells the AI where (file path), what (the new component's name), how (derive from existing state via props), and what not to do (don't change the existing logic). With all four present, the generation stays aligned with what you actually had in mind.
A small note on why this works: long-context models are remarkably good at locating named entities, and notably weaker when faced with vague pronouns like "it," "that part," or "there." Spelling out names is effectively a retrieval hint.
The same principle applies to smaller edits. If you want to change the color of a single button, don't write "make the save button blue." Write "in components/SaveButton.tsx, change the backgroundColor on line 12 from #E55 to #3B82F6." That level of precision feels tedious until you notice that the prompt took ten seconds to write and the generation was correct on the first try.
Make "don't touch existing code" an explicit constraint
The previous example hid this inside the prose, but it's worth writing out as a standalone constraints block. I now append one to every feature-addition prompt:
[Strict constraints]
- Do not modify any existing screens, components, functions, or state
management logic
- All new files, functions, and state required by the new feature must
be added as new additions
- Leave existing import statements untouched; put any new imports at
the top of new files only
- Existing routes (Stack.Screen entries in App.tsx) may be added to,
but not removed or renamedTwo small things that surprised me about this block. First, it's more reliable when phrased as "do not modify X" than as "keep X as it is" — negatively-framed instructions cut through more cleanly. Second, putting the block at the end of the prompt works better than at the top. The model seems to weight the constraints more when they're the last thing it reads before generating.
With this block appended, the model treats "don't delete or rewrite anything that's already there" as a first-class instruction. Explicit prohibitions are a well-known prompt-engineering technique, and they carry extra weight when the tool is actually writing to your files, as Rork does.
If you want to go deeper on this pattern, you might find my earlier piece Stopping Rork from Rewriting Your Existing Code useful — it goes through more edge cases that this constraints block helps with.
One feature per prompt — break additions into sprints
This is operational rather than textual, but it matters a lot. Composite asks like "add a chart, a CSV export, and a monthly reminder notification" almost never land cleanly in a single prompt.
A small confession. I once asked for all three of those at once in an allowance-tracking app. The chart worked, the notifications never fired, the CSV export generated code that wouldn't compile, and I ended up rolling back all three. That was my most expensive lesson on "keep it atomic."
My current rhythm:
- Ask for the category-aggregation chart, and only that
- Preview and actually exercise it (this step is the one people skip)
- If it's good, ask for the CSV export in the next sprint
- Verify again, then ask for the monthly reminder notification
There's a second reason to go one at a time: when something does go wrong, you know exactly which prompt caused it. With a composite request, the AI might have implemented the chart correctly but broken state elsewhere while wiring up the notification — and now you can't tell which piece introduced the regression without reading every file that changed. One prompt per feature keeps the diff small and the cause obvious.
You don't ship three features in a day this way, but the wall-clock time is consistently shorter. Nothing eats a weekend faster than rolling back three features at once. For solo indie development, the slower rhythm is actually the sustainable one.
How to check for unintended damage after each addition
When the AI says "done," treat that as a starting point, not a conclusion. I verify three things by hand before moving on.
Walk the full navigation: Tap through tabs, buttons, and the back gesture on screens unrelated to the new feature. If Rork touched navigation config, this is where you'll notice.
Inspect state flow: Confirm that the existing state (say transactions or userSettings) is still readable and writable from the new feature. Reads often survive while writes break silently — a surprisingly common pattern.
Read the console: Open Rork's preview developer console and scan for any new red or yellow messages. Warnings that weren't there yesterday are the most reliable predictor of tomorrow's crash.
One more check I've added to my routine: compare the file tree before and after. Rork's sidebar makes this easy — a new file you don't recognize is a signal, not just information. Sometimes the AI decides that your new feature needs its own folder and quietly creates one. That's fine if you approve of it, but it's worth a look rather than a default acceptance.
Those three checks, done every time, will prevent almost every "it worked yesterday, it's broken today" incident. The verification feels slow in the moment, but skipping it is how a single feature turns into three days of debugging.
The next step: describe what exists before you add to it
The biggest improvement to my feature additions came from a habit that sits before the prompt: writing down, in my own words, what the project currently looks like. "This screen uses these files, holds this state, and routes through here." The AI can only work with preconditions you share — and the act of writing them down reliably uncovers which ones you'd forgotten.
If there's one feature you want to add to your project today, try writing down where it should live — which file, which function, which line — in a single sentence before you open Rork. That one sentence will probably save you an hour later.