Common Pitfalls
When Roflow builds the wrong thing, it's almost always because of how the request was framed — and every one of those situations is easy to avoid and easy to back out of.
Roflow is capable, but it isn't a mind reader. It works from what you tell it and what it can see in your project. This page walks through the mistakes that most often send it off course, why each one trips it up, and — just as importantly — how to recover. None of these are permanent: Roflow snapshots your workspace after every step, so a wrong turn is always a checkpoint away from being undone.
Every pitfall below has a recovery, and most share the same one: edit your earlier message or restore a checkpoint and try again with a clearer request. You never have to start a whole project over because one prompt missed. See Recovering from any wrong turn.
The request is too vague
What it looks like: "Add a shop." "Make it more fun." "Fix the movement." Roflow builds something, but not the thing you pictured — a shop in the wrong place, selling the wrong items, wired up in a way you didn't intend.
Why it goes wrong: A short request leaves Roflow to fill in every decision you didn't make — what the shop sells, where its UI goes, which currency it uses, how it connects to the rest of the game. It picks reasonable defaults, but "reasonable" and "what you had in mind" often differ.
How to avoid it: Say what you want, where it should live, and how it should behave. "Add a coin shop UI in the top-right that sells three speed upgrades, paid for with the Coins currency" gives Roflow a target it can actually hit. If you're not sure your wording is clear, click the sparkle Improve prompt button — Roflow rewrites your draft into a stronger version and shows you a before/after you can Accept or Cancel.
How to recover: Don't start over — just reply with the correction ("the shop should be top-right, not center, and sell speed not health"). Roflow keeps the context of your game across the task and revises.
A clear, specific request is the one thing that most improves your results. It's worth spending a sentence or two more up front. See Getting Great Results for how to phrase requests.
The request is too big
What it looks like: "Build me a full tycoon with a shop, pets, a rebirth system, daily rewards, saving, and a leaderboard." Roflow starts strong, but by the end some systems are half-wired, others don't quite talk to each other, and the whole thing is hard to review.
Why it goes wrong: The more a single request tries to do, the more places a small misunderstanding can compound, and the harder it is for you to check the result before moving on. A giant diff is difficult to review carefully, so mistakes slip through.
How to avoid it: Build in stages. Ask for the core loop first, get it working, then layer on one system at a time — shop, then saving, then rebirths. Each smaller request is easier to describe, easier to review, and easier to test before you commit to the next. If you do want to tackle something large, start in Plan mode so Roflow lays out the whole approach for you to approve before it writes anything, or use /deep-planning for a feature that would normally need a design doc.
How to recover: If a sprawling task has drifted, press Cancel, then restore to the last point things were working (see below) and re-approach it one piece at a time.
If you're beginning a game, the starter pills — Tycoon, Simulator, RNG Collector, Obby Escape — hand you a complete, playable loop to build on, rather than something you have to assemble system by system. See Building in Stages.
Roflow is missing context
What it looks like: You ask Roflow to change "the shop," but your game has three shop-related files and it edits the wrong one — or it rebuilds something you already have because it didn't know it existed.
Why it goes wrong: Roflow works from what it can see. If you don't point it at the specific file, folder, error, or image you mean, it has to guess where to work and what you're referring to.
How to avoid it: Give it the context directly in the composer:
| To point Roflow at… | Do this |
|---|---|
| A specific file or folder | Type @ (or click Add Context) and choose File or Folder. |
| The current errors and warnings | Type @ and choose Problems. |
| Terminal output | Type @ and choose Terminal. |
| A web page for reference | Type @ and paste a URL for Roflow to fetch. |
| A mockup, screenshot, or reference image | Click + (Add Files & Images), or paste a PNG/JPEG/WebP straight into the composer. |
| A line of code you're looking at | Select it in the editor and use Add to Roflow Agent (Ctrl/Cmd+'). |
How to recover: If Roflow touched the wrong thing, reject the change (or restore the checkpoint), then resend the request with the exact file or folder attached via @.
A screenshot or mockup of the UI you want often communicates more than a paragraph. The default Balanced model can look at images you attach. See Talking to Roflow for every way to add context.
You didn't introduce your existing game
What it looks like: You bring Roflow into a game you've already built, ask for a new system, and it adds code that doesn't match your folders, your naming, or the way you split server and client work.
Why it goes wrong: On a fresh session Roflow doesn't yet know your project's structure and conventions. Without that, new work can fight the architecture you already have instead of slotting into it.
How to avoid it: On an existing game, run /init first. Roflow inspects the project, asks a few game-specific questions, and learns your setup — then it respects your existing layout, naming, and server/client split when it adds anything new. After setup it keeps a plain, editable ROFLOW.md file describing your game, and future tasks load it automatically so you don't re-explain your project each time.
How to recover: If Roflow has already added something that doesn't fit, restore the checkpoint, run /init, and ask again. See Existing Projects.
You're describing a bug instead of showing it
What it looks like: "The coins are broken, please fix." Roflow makes a plausible guess, changes something, and the bug is still there.
Why it goes wrong: "Broken" could be a dozen things. Without the actual error text or clear steps to reproduce it, Roflow is diagnosing blind and may fix a problem you don't have.
How to avoid it: Hand over the evidence, not just a description. Attach the live diagnostics with @ Problems, paste the exact error line (including the script name and stack trace), or attach a screenshot of what looks wrong. Then say what you did, what you expected, and what actually happened. And fix one problem at a time — bundling several unrelated bugs into one message makes the result harder to review and more likely to introduce a new issue.
How to recover: If a fix didn't land, don't pile on another vague follow-up — restore to before it and re-report the issue with the exact error attached. See Fixing Issues.
You expected Roflow to see a game it can't
What it looks like: You ask Roflow to "playtest it and tell me what's wrong," but Roblox Studio isn't connected. Roflow can edit your files but can't actually run or look at the game.
Why it goes wrong: Roflow tests and inspects your game through Studio. Without the Studio Bridge connected, there's no running game to playtest, no live console to read, and no viewport to screenshot.
How to avoid it: Open your game in Studio and connect the Roflow Studio Bridge plugin before asking for anything that needs a live game — a playtest, a screenshot, or verification that a fix worked. When Studio is connected, Roflow checks its own work by running a short playtest and reading the console before calling a task done.
How to recover: To Roflow's credit, it won't pretend. If Studio isn't connected it flags that as the blocker rather than claiming it verified a running game — so if you see that message, connect Studio and ask it to continue. See Connection Problems.
Without Studio, Roflow will still write and change code and run local commands — it just can't do live visual or playtest verification, and it says so. Take that as your cue to connect Studio, not as a finished, tested result.
You edited a script inside Studio
What it looks like: You tweak a script by hand inside Roblox Studio, then Roflow makes an edit and your Studio change disappears.
Why it goes wrong: For scripts, your local files in Roflow are the source of truth. When Roflow (or you) edits a local file, that edit is what gets synced into Studio — so a hand-edit made only inside Studio can be overwritten. Roflow shows a non-blocking warning when this happens, but the overwrite still goes through.
How to avoid it: Make script changes in Roflow, not directly in Studio, and let Roflow sync them out. Keep Studio for the things it's best at — running the game, building visually, and publishing.
How to recover: If a Studio-side edit was overwritten, restore the change in Roflow (checkpoints and Studio's own Edit > Undo both help), then re-apply it as a local file edit so it sticks.
You expected bespoke, hand-crafted art
What it looks like: You ask for an elaborate, highly detailed custom environment and get a solid, functional layout instead of a sculpted showpiece.
Why it goes wrong: Roflow's world-building favors playable and performance-conscious results — organized layouts, valid spawns, sensible collisions and lighting, reasonable part counts. It's built to give you a game you can actually play, not to hand-sculpt bespoke high-detail scenery.
How to avoid it: Lean on Roflow for the functional skeleton — baseplates, spawn areas, obby courses, tycoon plots, paths, lighting presets — and treat detailed art passes as something you polish in Studio afterward. Describe the layout and gameplay you want more than the fine art direction.
How to recover: If a scene isn't detailed enough, keep the working layout and refine it in Studio, or ask Roflow for specific, concrete additions ("add a fenced perimeter and three prop clusters near spawn") rather than open-ended artistry. See World Building.
You loosened auto-approve too far
What it looks like: With auto-approve turned up, Roflow rattles through a series of changes without stopping, and by the time you look up it's gone further than you wanted.
Why it goes wrong: Auto-approve pre-authorizes categories of actions so Roflow won't pause for each one. That's great for prototyping, but it also means changes happen without a per-step review from you.
How to avoid it: Match auto-approve to the risk. Loosen it while prototyping or grinding through tedious work; tighten it back up for anything delicate. Set a sensible Max Requests cap so Roflow checks back in after a set number of actions, and remember that even with "safe commands" enabled, a command judged destructive still stops to ask.
How to recover: This is exactly what checkpoints are for — Roflow snapshots after every step, so you can compare what changed and restore to before the run. See the auto-approve section of Talking to Roflow.
Auto-approve doesn't remove your safety net — checkpoints still capture every step. But for anything you'd want to review carefully, turn it down so you see each change before it applies.
The conversation drifted or got too long
What it looks like: After a long back-and-forth, Roflow starts feeling less sharp, or a task has wandered away from what you originally asked for.
Why it goes wrong: Very long conversations accumulate a lot of history. Roflow automatically summarizes when a conversation gets long so it can keep going without forgetting earlier decisions — but if a single task has genuinely lost the thread, the cleanest fix is often to reset the framing.
How to avoid it: Keep individual tasks focused. Start a new task for a genuinely new goal rather than tacking it onto an unrelated conversation, and use /smol to condense a long thread when you want to keep going within the same task.
How to recover: Edit the message where things went off course and resend it, or restore a checkpoint from when the work was on track and pick up from there.
You picked the wrong model for the job
What it looks like: A tricky bug or a complex system keeps not landing on the Fast model, or a trivial one-line tweak burns through more usage than it needed to on Max.
Why it goes wrong: The model picker offers three tiers — Fast (quick edits, low usage), Balanced (the all-round default that can also read images), and Max (most capable, for complex reasoning and debugging). Higher tiers produce stronger results on hard problems but draw down more of your monthly usage.
How to avoid it: Match the tier to the task. Reach for Max when you're stuck on a genuinely hard bug or a complex feature; drop to Fast for small, well-defined edits to save usage. Balanced is a fine default for everyday work.
How to recover: If a task is going in circles, switch to a higher tier (or to Plan mode so you can agree on the approach first) and try the request again. See Usage for how tiers draw on your allowance.
Recovering from any wrong turn
Whatever the pitfall, the way out is the same handful of tools. Roflow is built so you can always get back to a good state:
- Reject the change. If a proposed edit or command isn't right, click Reject and it never happens. Then reply with what to do differently.
- Edit an earlier message. Click one of your own messages, edit it, and resend. Restore Chat rolls the conversation back to that point while keeping your files as they are; Restore All rolls back both the conversation and your workspace so you can try a completely different direction from a clean start.
- Restore a checkpoint. Roflow snapshots your workspace after each step. Open an earlier point, Compare to see exactly what changed, and Restore — choosing to reset just the code, just the conversation, or both.
- Let Roflow stop you. If it hits its consecutive-mistake limit or an auto-approval cap, Roflow pauses and asks for guidance rather than running away unattended. That pause is a feature — respond to steer it back, or restore and re-approach.
Because every step is a checkpoint, trying a bold request is safe: if it doesn't pan out, restore and you're exactly where you were. The freedom to undo is what makes it worth being ambitious.
Where to go next
- Getting Great Results — how to phrase a request so Roflow builds what you meant.
- Building in Stages — why one system at a time beats everything at once.
- Talking to Roflow — context, approvals, auto-approve, and checkpoints in depth.
- Planning Your Game — Plan mode and
/deep-planningfor anything ambitious. - Existing Projects — bringing Roflow into a game you already have with
/init. - Fixing Issues and AI Issues — when a build or a fix won't cooperate.