You carefully adjusted the layout, tweaked the font sizes, and got everything looking just right — then asked Rork AI to add one small feature, and poof. Your customizations were gone.
If you've hit this wall, you're in good company. It's one of the most common frustrations for developers new to Rork. The good news is that once you understand why it happens, a few changes to how you write prompts make a big difference. This article covers the root cause, practical workarounds, and what to do when the damage is already done.
Why AI Additional Prompts "Reset" Your Code
Every time you send a prompt to Rork AI, it doesn't just append your request to the existing code — it regenerates the target component based on what it thinks the best implementation looks like, given your instruction.
Think of it less like a text editor and more like a sculptor who remolds the clay from scratch each time, rather than carving a small notch. The result often aligns with Rork's default style conventions, which means your hand-tuned values get smoothed over.
The situations where overwrites happen most often:
- Adding a new UI element (button, card, modal) to an existing screen
- Asking for layout changes (e.g., "convert this list to a grid")
- Combining a bug fix request with a new feature in a single prompt
- Vague instructions like "improve this screen" or "fix this component"
This isn't a bug — it's a fundamental behavior of generative AI. Knowing this, you can work with it instead of against it.
How to Write Prompts That Protect Your Changes
The most effective defense is making your prompt explicit about what should not change.
Prone to overwriting:
Add a push notification button to the home screen.
With this prompt, Rork reads it as: "Optimize and regenerate the home screen with a notification button included." Everything gets rebuilt from its idea of "correct."
Safer version:
Do NOT change any existing styles, layout, or logic in HomeScreen.tsx.
Add a single notification icon button (TouchableOpacity) to the top-right of the header only.
Touch nothing else in the file.
Three rules that help:
- Name the file or component explicitly ("Don't change HomeScreen.tsx")
- Scope each request to a single change (resist bundling multiple requests)
- End with a boundary statement ("Touch nothing else in the file")
The last one sounds redundant, but in practice it acts as a strong signal that keeps the AI more conservative.
The "Protection Comment" Strategy
When prompt-level constraints aren't enough, embedding comments directly in your code can help preserve custom work.
// ===== CUSTOM: manually tuned — DO NOT MODIFY =====
const customStyles = {
headerContainer: {
paddingTop: 48, // accounts for dynamic island on newer iPhones
backgroundColor: '#1A1A2E',
},
titleText: {
fontSize: 22, // confirmed with designer
letterSpacing: -0.5,
fontWeight: '700' as const,
},
};
// ===== CUSTOM END =====This kind of comment signals to Rork AI that this block was intentionally tuned and should be left alone. It's not a guarantee, but in my experience it noticeably reduces how often AI touches those sections.
As a bonus, the comments serve as documentation. If a regeneration does overwrite your values, you'll know exactly what to restore.
What to Do When Your Changes Are Already Gone
Overwrites happen even with good habits. Here's how to recover quickly.
Option 1: Use Rork's version history
Rork tracks project history, accessible from the version indicator at the top of the editor (or the History icon). Before any major request, it's worth treating your current state as a checkpoint to return to if things go wrong.
Option 2: Re-apply with a precise prompt
If you remember what was overwritten, ask for it back immediately:
The recent change modified headerContainer's paddingTop.
Please set it back to 48 and backgroundColor back to #1A1A2E.
Do not change anything else in the file.
This is why keeping a quick note of important custom values — in Notion, a sticky note, anywhere — pays off disproportionately when something goes wrong.
Option 3: Rork Max direct editing
If you're using Rork Max, you can edit code directly without going through AI generation. For protecting specific, already-finalized sections, direct edits bypass the overwrite problem entirely.
Habits That Reduce Overwrites Over Time
Beyond prompt tactics, a few development habits make a real difference long-term.
Keep each prompt to one change at a time. Compound instructions like "add a button, fix the spacing, and change the font" multiply the surface area for accidental overwrites. One request → one response → verify → then move on.
Separate styles into their own files. Moving style definitions into a styles.ts or theme.ts file means that when Rork regenerates a screen component, your style file often survives untouched. Not foolproof, but it reduces the blast radius.
Snapshot important states. Copying a finished component's code into a notes file takes under a minute and has saved me hours of re-work. The Rork version history helps too, but having your own copy of a "known good" state is a useful safety net.
For another common Rork AI issue — when it keeps looping on the same error — see Rork AI Loop Troubleshooting Guide.
The One Thing to Try Right Now
The fastest improvement you can make is adding this line to your next prompt:
Keep all existing styles and logic intact. Only add [X]. Touch nothing else.
That single constraint reduces overwrite incidents significantly in most cases. Try it on your next Rork session and see how it changes the AI's behavior.
If you're also dealing with build errors on top of this, the complete guide to app build troubleshooting covers the most common cases in detail.