●GPT-6.1 SOL — Added to Rork's model menu (09-29) with Low, Medium and High effort; included on Pro and Max●SONNET 5.5 — Claude Sonnet 5.5 is selectable: strong at UI design and faster than Sonnet 5 (09-28)●SONNET 4.5 — Retires on the Claude API on 11/30, 26 days left. If your app calls it, check the migration target●SDK 58 — Moves to React Native 0.88. R8 is now on by default in Android release builds, and iOS prebuild generates a SceneDelegate●OBSERVE — EAS Observe now records native crashes too (SDK 57.0.21 or later, 10/07)●NEW — My App Open Ad Only Showed When the App…●GPT-6.1 SOL — Added to Rork's model menu (09-29) with Low, Medium and High effort; included on Pro and Max●SONNET 5.5 — Claude Sonnet 5.5 is selectable: strong at UI design and faster than Sonnet 5 (09-28)●SONNET 4.5 — Retires on the Claude API on 11/30, 26 days left. If your app calls it, check the migration target●SDK 58 — Moves to React Native 0.88. R8 is now on by default in Android release builds, and iOS prebuild generates a SceneDelegate●OBSERVE — EAS Observe now records native crashes too (SDK 57.0.21 or later, 10/07)●NEW — My App Open Ad Only Showed When the App…
Where to Stop Letting Rork Fix Your Bugs: A Triage Routine for the 30% That Need You
Most bugs you hand Rork get fixed in a couple of regenerations. A stubborn minority loop forever, each fix spawning a new symptom. Here is the triage routine I use to split what to delegate from what to take over by hand, with retreat lines, regression guards, and a decision log.
I meant to tweak one setting, and somehow I had run nine regenerations by the end of the night. The culprit was a wallpaper app I keep in production: on certain devices, the thumbnail grid would occasionally render completely blank.
When I described the symptom to Rork's chat, the first fix looked plausible. But when I checked it against a production build, scrolling broke on a different list. I asked Rork to fix that, and the original blank screen came back. Fix and regression, back and forth, well past midnight.
The next morning I realized what had gone wrong: I had unconsciously assumed I could just keep asking until it was fixed. Rork's bug fixing really is strong. In my own experience, roughly 70% of the bugs I hand it get resolved with almost no manual work. The trouble is the remaining 30%. Approach that minority with the same posture and you end up in last night's loop.
As an indie developer running several apps in parallel, how fast I can spot that 30% and switch to hands-on work decides the productivity of my whole day. Below is the triage routine I built out of that late night: how to decide whether to keep delegating a bug to the AI or take it over yourself, including retreat lines, regression guards, and a decision log.
Where the self-healing 70% splits from the 30% that needs you
The first thing to internalize is that Rork has a clear bias toward certain kinds of bugs.
It is strong on bugs that reproduce reliably and have a single, contained cause. "Tapping this button always crashes," "the spacing breaks only on this screen" — these usually resolve in one regeneration round. Rork narrows down the location from the symptom description and returns a fix that tidies the surrounding code too.
It struggles with bugs that appear only probabilistically, bugs with several interacting causes, and bugs whose behavior differs between production and preview. Last night's blank screen was a race between image-cache eviction and rendering — exactly the probabilistic, compound kind. Because the reproduction condition cannot be pinned down in words, Rork attacks a different "likely cause" each time, and I was stepping through those ad-hoc fixes one by one.
Leave this judgment to instinct and you will keep telling yourself "just one more prompt." So before I dive in, I always run three filters.
Narrow triage down to three axes
When I meet a new bug, before I even open Rork's chat, I check three things out loud.
1. Does the symptom reproduce deterministically?
If the same action reproduces it 100% of the time, hand it to Rork. Attach the reproduction steps as a bullet list and the fix quality rises further. The moment words like "sometimes" or "only on certain devices" appear, the odds of self-healing drop sharply. For probabilistic bugs, pinning down the reproduction condition on the human side is faster.
2. Is the fix local or wide-reaching?
A fix confined to one screen or one component keeps the regeneration blast radius small. But areas that ripple across the whole app — the ad (AdMob) initialization order, the purchase-state check — risk the regenerator "tidying" unrelated files. For wide-reaching bugs, do not hand the whole thing to Rork; set the boundary yourself, then ask for a scoped change.
3. Is failure recoverable?
A layout glitch is undoable. But a build right before store review, or the receipt-verification logic for purchases, is territory where a mistake reaches users who already shipped. In unrecoverable places, insert one round of human review before adopting any AI suggestion.
Running just these three axes shows that last night's blank screen was "probabilistic, wide-reaching, low-risk," and that I should have spent the time investigating the reproduction condition from the start.
✦
Thank you for reading this far.
Continue Reading
What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.
WHAT YOU'LL LEARN
✦A triage table that classifies a bug by reproducibility, blast radius, and failure cost, so you decide in seconds whether to keep delegating or take over
✦A retreat line (the 3-regeneration rule) and the concrete trigger for switching from prompting to hands-on debugging
✦A Jest regression guard that protects manual fixes from being overwritten, plus a decision-log format that makes handoffs to the AI reproducible
Secure payment via Stripe · Cancel anytime
✦
Unlock This Article
Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.
Decide your retreat line before you keep delegating
Even for a bug you triaged as "delegate," do not regenerate without limit. I set a three-round rule.
If a bug is not fixed after three regeneration rounds, that is the signal it belongs to the 30% Rork is weak at. Instead of asking a fourth time, I stop and move to isolating the symptom by hand.
Putting the retreat line into words curbs the temptation to chase. The decision rests on a prior agreement rather than momentum. Concretely, after each regeneration I jot down three things:
Which round this is
What I asked it to fix
Whether a new symptom appeared as a result
If, by the third round, the "new symptom" column has two or more entries, I delegate no further. Growing symptoms are evidence the fix is not reaching the cause.
A regression guard for when you take over by hand
Switching to hands-on work brings a new worry: even after I fix something manually, will the next unrelated request to Rork overwrite it during regeneration?
I stop that physically, with a test. For every bug I fix by hand, I add one regression test that detects its return before moving on. For the blank screen, that is a small test confirming the thumbnail data builder never returns an empty array.
// thumbnails.test.ts — a regression guard that detects the blank-screen returnimport { buildThumbnailRows } from "./thumbnails";describe("buildThumbnailRows", () => { it("never returns an empty array even with broken image metadata", () => { const input = [ { id: "a", uri: "file://ok.jpg", width: 1080, height: 1920 }, { id: "b", uri: "", width: 0, height: 0 }, // corrupt data ]; const rows = buildThumbnailRows(input, { columns: 2 }); expect(rows.length).toBeGreaterThan(0); expect(rows.flat().every((cell) => cell.uri !== undefined)).toBe(true); });});
As long as this test passes, even if Rork regenerates the builder, the blank-screen condition will not come back. If a regeneration ever breaks it, the test goes red and I notice before push. My recommendation is to put the breakwater that protects your hand-fixed 30% in tests, not in your attention.
Write the test that reproduces the error first, then fix it. The moment you go hands-on is exactly when that order pays off.
Keep handoffs in a record: the case for a decision log
Keep triaging and you meet the same kinds of bugs again and again. Deciding from scratch each time wastes the late nights you already spent.
So for every bug I take over by hand, I keep a short decision log. The format is fixed, and the only thing I optimize for is being able to search it later.
date: 2026-06-17symptom: thumbnail grid renders blank probabilistically on certain devicesclass: probabilistic / wide-reaching / low-riskrounds delegated to Rork: 3 (stopped at retreat line)cause: race between image-cache eviction and renderingmanual fix: empty-array guard in the builder + regression testnext-time rule: isolate probabilistic rendering bugs by hand from the start
Once these accumulate, a new bug gets an instant read: "this is the same family as the old blank screen." If I do ask Rork again, pasting the cause and the fix skips the wasted regeneration rounds. The decision log is a handoff to my future self and, at the same time, briefing material for the AI.
Shipping several apps to both the App Store and Google Play, the same family of bug recurring in a different app is not rare. With the log, a one-time solution becomes reusable across the portfolio.
Sharpen the 70% you delegate with how you ask
For a bug you decided to delegate, how you phrase the request raises the success rate of a single round. When I hand one to Rork, I never write only the symptom; I always assemble four elements.
[Symptom] Switching the language on the settings screen leaves the list ordered in the previous language[Repro steps] 1) Open settings 2) Switch language to English 3) Return to the list screen[Expected] The list re-sorts in the new language immediately after the switch[In-scope to touch] Only the list screen and its hooks. Do not touch ad or purchase initialization
That last line, "in-scope to touch," is the single sentence that constrains the regeneration blast radius. Because Rork tends to tidy the area around a request, declaring up front what it should not touch prevents a lot of unrelated-file reshuffling. Adding the expected behavior in one line also helps: it gives Rork a criterion for judging whether the fix worked.
Conversely, a bug you cannot describe with these four one-liners usually sits on the probabilistic or compound 30% side. The act of shaping the request doubles as the final triage check.
Your next step
Pick one bug you are carrying right now and, before prompting Rork, classify it on the three axes — reproducibility, blast radius, failure cost. If it lands on probabilistic, wide-reaching, or unrecoverable, that one is worth isolating by hand from the start. Deciding what to delegate is not distrust of the AI; it is preparation that lets the AI focus on the 70% where it is strongest.
Share
Thank You for Reading
Rork Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.