It started with rebuilding the same screen three times
Early in 2026, I was wiring up a navigation flow with Expo Router inside a Rork Max project. The generated code refused to behave the way I expected, and I spent more than an hour pushing the same change back and forth. The cause turned out to be embarrassingly simple: the AI had handed me Expo Router v2 idioms, while my project was already on v3.
What that morning made clear is that Rork's AI tends to pick whatever pattern is "most common" in its training data. If you don't tell it which library version you're on, it will often default to one or two generations behind the current API.
Expo SDK and React Native both ship breaking changes every six months or so. Without explicit version hints, the time you spend fixing "code that doesn't actually run" can quickly outgrow the time you spend building new features.
My grandfathers were temple carpenters in Japan, and one of them used to say that maintaining your tools is half the job. The longer I work with AI code generation, the more that line resonates. The minutes I invest in shaping the prompt determine the speed of the next several hours of development.
Why the AI keeps reaching for old APIs
Training data is full of legacy patterns mixed with modern ones.
Expo Router is a clean example. Stack Overflow answers and personal blogs from a year or two ago are still saturated with v2-era idioms — for instance, passing an object directly to href. A generalist code AI like Rork Max has very little to work with beyond the hints you supply in the prompt.
Code generators also tend to optimize for "syntactically valid", "type-safe", and "has worked in some past codebase". They don't necessarily reward the latest best practice, and they don't always know that a given pattern is now deprecated.
In my experience, when I leave the AI to its own devices, the defaults usually look like this:
- Mix of React Navigation v6 and Expo Router v3 — usually leans toward React Navigation
- React Native 0.74 vs 0.76 (New Architecture) — leans toward 0.74-style code
- Reanimated v2 vs v3 — leans toward v2 patterns of
useSharedValue - Stripe SDK v0.x vs v1.x — leans toward older
confirmPaymentargument shapes
The tricky part is that several of these compile cleanly. They look correct in the editor and only fail at runtime, often on a real device.
Worse, when you ship a small app on the side and your testing budget is "five minutes between dinner and bedtime," you can land an old API in main without noticing. I've shipped builds where every screen passed in the simulator and only the iOS deep-link path was broken — and the AI had quietly used a deprecated Linking.addEventListener signature that React Native silently warns about rather than errors on.
The basic shape of my version-pinned prompt
To prevent these silent regressions, I always paste a project-environment block at the top of any prompt that asks Rork to generate a new screen or feature.
[Project Environment]
- Expo SDK 54
- Expo Router v3
- React Native 0.76 (New Architecture: enabled)
- TypeScript 5.4 (strict: true)
- Reanimated 3.10
- TanStack Query v5
- Supabase JS Client v2.45
[Coding Conventions]
- Use Expo Router Stack/Tabs for navigation. Do NOT use React Navigation directly.
- Use async/await for asynchronous code. Avoid .then chains.
- Use StyleSheet.create. Do NOT use NativeWind, styled-components, or Tamagui.
[Request]
When the user taps a profile picture, present it full-screen.
Implement pinch-zoom using Reanimated v3's useSharedValue and withSpring.Splitting the prompt into "environment", "conventions", and "request" makes a real difference. The AI seems to internalize the pinned versions and aligns its output accordingly.
The "DO NOT" lines are particularly powerful. Saying "DO NOT use React Navigation directly" sharply reduces the chance of getting React Navigation imports sneaking back into an Expo Router project.
One small habit that helps: write the "DO NOT" list first, then the "DO" list. When I started doing this, I was surprised how often the AI would honor a negative constraint that I'd buried in the middle of the prompt before but ignored when it was at the top. The position matters as much as the wording.
Turning it into a reusable file
Typing this out every time gets old quickly, so I keep a prompts/_environment.md at the root of every project.
# Project Environment (for AI prompts)
## Stack
- Expo SDK: 54.x
- React Native: 0.76.x (New Architecture: enabled)
- TypeScript: 5.4 (strict, noUncheckedIndexedAccess)
## Routing
- Expo Router v3 (Stack / Tabs)
- DO NOT use React Navigation directly
## State / Data
- TanStack Query v5
- Zustand v4 (NOT Recoil, NOT Redux)
- Supabase JS Client v2.45
## Styling
- StyleSheet.create
- DO NOT use NativeWind, styled-components, or Tamagui
## Animation
- Reanimated v3 (useSharedValue, useAnimatedStyle, withSpring)
- DO NOT use Animated.Value (legacy API)
## Forms
- react-hook-form v7 + zod v3
## Last verified: 2026-05-08Whenever I open a new conversation in Rork Max, I paste this whole file in before the first request. Rork Max retains conversation context, so a single up-front paste tends to keep the AI on the right rails for the rest of the session.
If I notice the model drifting back to older idioms midway through a long conversation, pasting the environment block again restores the behavior. I don't have a rigorous explanation for why this works so well, but it does in practice.
When a dependency is bumped, I update this file. It feels mundane, but the steady payoff is that the time I spend asking the AI to rewrite outdated code drops to nearly zero.
I also keep a tiny git pre-commit hook that fails the commit if the Last verified date in this file is older than 60 days. That sounds excessive, but it forces me to either revisit the dependencies or knowingly extend the date — both are better than silently letting the file rot. Reanimated and Expo Router in particular tend to ship API refinements between minor versions, and a quarterly check is the lightest discipline I've found that catches them.
Three things to pin alongside versions
Beyond the environment, there are three other categories I include in my prompts.
The first is "what not to do" at the code level: no any types, no empty useEffect dependency arrays as a workaround, no Math.random() as an id. Closing those doors up front keeps the generated code closer to what I would actually write by hand.
The second is error-handling policy. I tell the AI things like "network errors are caught in TanStack Query's onError and surfaced via Toast." Without this, generated code tends toward swallowed errors inside try/catch blocks or quick-and-dirty alert() calls.
The third is UI tone and copy. Spelling out "buttons use polite imperative phrasing" and "error messages name both cause and remedy" saves a surprising amount of post-edit time on the generated screens.
In short, the prompt I send is always built from three layers: environment, what-not-to-do, and policy. Anchoring on those makes the output far more predictable.
For related angles, I've written a piece on tracking deprecated APIs early in Expo upgrades, and a broader guide to prompt design for Rork.
What to do when outdated code still slips in
Even with all of this, a long conversation will occasionally drift back into old patterns. My recovery checklist:
First, look for TypeScript errors. Then run something like expo install --check to confirm the dependency tree itself is consistent with the SDK version.
After that, I push to TestFlight and run on a real device at least once. The Rork Companion preview catches a lot, but device-only issues — deep links, in-app purchases, push registration — usually don't surface until you're on actual hardware.
When I do find an issue, I tell the AI exactly which version it should be targeting and what the modern API looks like: "this part is using the v2 API; refactor it to use xxx from v3." A vague "please fix it" tends to make the model rewrite the wrong piece, so being explicit about the version and the API name pays off.
What to do next
If you don't have a prompts/_environment.md in your project yet, give yourself five minutes to create one. List your Expo SDK version, the libraries you actually use with their major versions, and three things you absolutely never want generated. That's enough.
The next time you ask Rork to build something, paste the file in first. The accuracy of the generated code shifts noticeably. I was skeptical at first, but it has become a habit I genuinely rely on every day.
The slightly bigger picture, for me, is that prompts are starting to feel like a project artifact in their own right — something that lives next to the code, gets reviewed, and travels with the repo. Treating them that way changes how the AI behaves, and it also changes how I think about my own conventions. Writing the "DO NOT" list once forces you to articulate the implicit standards you've been carrying in your head, and I've found that's a useful exercise even outside the AI context.
Thanks for reading. If you've been wrestling with version mismatches in AI-generated code, I hope this saves you some of the hours it cost me.