Concept Exploration
Roblox AI Editor Assistant
A mode-based, project-aware assistant concept that would help creators learn, fix, build faster, and safely.
Self-initiated, unvalidated concept, not affiliated with Roblox. This is a written product exercise: no prototype was built, no designs were produced, and no user research was conducted. Examples below illustrate intended behaviour, not a working system.
Context & problem
The problem
One-size AI either over-explains for experts or under-explains for beginners, causing context-switching and unsafe code. The assistant can't tell whether someone wants to understand what they're writing or just wants it written.
Who it's for
- Beginners
- Syntax, and “where does this go?”
- Intermediates
- Patterns and debugging
- Pros
- Scaffolds, refactors, speed
- Educators
- Policy and explainability
Mode strategy
Explicit, switchable modes reduce prompt-wrestling and align tone and safeguards to intent. The user states what kind of help they want instead of encoding it into a prompt.
Teach
Beginner- Line-by-line explanations with Roblox APIs
- Stepper: Plan → Insert → Explain → Test
- Guardrails on by default
Debug
Intermediate- Summarize error logs + stack traces
- Minimal, safe patches with diffs
- One-click rollback + add assertions
Generate
Pro- Scaffold modules & patterns, fast
- Permission prompts for risky ops
- Attach tests and run in sandbox
Worked example: Debug mode
Debug mode ingests stack traces and proposes surgical patches with a diff preview, an explanation, and optional test stubs. Nothing is applied without review, and every apply is reversible.
Illustrative example — not a screenshot
Error log
[PathfindingService] Path blocked near waypoint 17
Script: EnemyAI.lua line 84
Stack:
EnemyAI.lua:84 moveToNextWaypoint()
EnemyAI.lua:42 patrol()
Proposed patch
A pathfinding failure becomes a parameterized repath with a guard check — the smallest change that fixes the reported error, rather than a rewrite the creator would have to re-read.
How it would work
The assistant reads filenames and the open script rather than uploading a whole project, and blocks risky APIs before a suggestion is ever drafted. Static checks and sandbox runs raise quality without slowing down pros.
How I prioritized
MoSCoW, the same framework used in my Discord PRD. The through-line: anything that changes a creator's code has to be reviewable before it lands.
- Explicit, switchable modes: the core bet of the concept
- Guardrails and risk badges on by default, not opt-in
- An explanation attached to every suggestion
- Diff preview with one-click rollback before anything is applied
- Error-log ingestion for the Debug path
- Sandbox test execution
- Generated test stubs alongside a patch
- An autonomous agent that edits files without review
- Raw project upload by default
- Free-form chat with no mode selected
What I cut, and why
Autonomous edit mode
Unreviewed changes inside a beginner's project is the worst failure mode this product could have. Every suggestion stays behind a diff and an explicit apply.
One adaptive mode instead of three
It sounds simpler, but it puts the burden on the user to phrase prompts precisely. Explicit modes trade a small selection cost for predictable tone and safeguards.
Raw code upload by default
Filenames and the open script cover most context at a fraction of the privacy surface. Full upload becomes opt-in, not the default.
What I'd measure
No usability studies were run, so there are no results to report. These are the measures the concept was designed against, what I would instrument first if it were built.
First-insert compile rate
The clearest signal that Teach mode produced something usable rather than something plausible.
Time from blank script to working feature
The concept's core promise. If this doesn't move, the modes aren't earning their complexity.
Rollback rate after apply
A safety signal. Rising rollbacks mean suggestions look more correct than they are.
Mode-switch frequency
Tests the central assumption. If nobody switches, explicit modes are friction rather than clarity.
What I'd validate first
The concept rests on one assumption: that creators would rather pick a mode than phrase a better prompt. That is the first thing I would test, and these are the questions I can't answer from the desk.
- Do beginners understand what a mode is, or does the picker read as a settings menu?
- Is the right default Teach for everyone, or should it follow account age or project complexity?
- Do permission prompts get read, or clicked through like a cookie banner?
- Does a diff preview help a beginner who can't yet read a diff?