Verified against Grok Code Fast · 2026-07-30
Brief Grok Code Fast for an agentic bug fix without an open-ended blast radius
Scopes a bug-fix task for Grok Code Fast's speed-optimized agentic coding loop with an explicit blast-radius boundary and a required diff-review step, so fast iteration doesn't turn into fast, wide, unreviewed changes.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are using Grok Code Fast in an agentic coding loop to diagnose and fix a specific bug. Code Fast is tuned for speed across many tool-calling iterations, not for the deepest possible single-shot reasoning, so this brief gives you a tight blast radius up front rather than relying on you to infer scope discipline mid-task while you're moving fast through file reads and edits. BUG DESCRIPTION Users report that changing their timezone in account settings doesn't update timestamps already shown on the dashboard until a full page reload REPRODUCTION STEPS One, log in with an account set to America/New_York. Two, note the timestamp on any dashboard event. Three, change timezone to Asia/Tokyo in settings without reloading. Four, observe the dashboard still shows the New York-based timestamp. FILES YOU MAY TOUCH src/features/dashboard/useEventTimestamps.ts and src/features/settings/timezoneStore.ts FILES OFF LIMITS Anything under src/features/billing — a past incident there means billing changes require a separate, human-reviewed PR regardless of how related it looks TEST COMMAND TO VERIFY THE FIX npm run test -- useEventTimestamps.spec.ts TASK RULES Reproduce the bug first, using the exact steps given, before writing any fix — if you can't reproduce it with the steps as given, stop and report that mismatch rather than guessing at a plausible-sounding fix for a bug you haven't actually confirmed. Stay strictly inside the allowed files list; if the actual root cause lives in a file outside that list, stop and report where the real fix needs to happen instead of finding a workaround inside the allowed files that papers over the symptom without touching the real cause. Make the smallest change that fixes the actual root cause, not the smallest change that makes the specific repro steps stop failing — a fix that special-cases the exact input in the repro steps while leaving the underlying logic error in place is not a fix, it's a patch that will resurface on the next slightly different input. Run the test command after every change, not only once at the end, so a fix that resolves the original bug but breaks something else gets caught immediately, in the same iteration, rather than surfacing later as a separate bug report against the same code. Do not refactor, rename, or reformat anything beyond what the fix itself requires, even inside the allowed files — a bug-fix diff padded with unrelated cleanup is harder to review and harder to revert if the fix itself turns out to be wrong. When the fix is verified, stop — do not continue looking for other things to improve in the allowed files just because you're already in there; a scope-creep pass is a separate task with its own brief, not a bonus round on this one. OUTPUT FORMAT 1. Confirmation the bug reproduced as described, or a report of the mismatch if it didn't. 2. Root cause, stated in one or two sentences — what was actually wrong, not just where. 3. The diff, and only the diff — no restated full files unless a file is new. 4. Test command output after the fix, showing it passes. 5. Anything you noticed outside the allowed files that looks related but wasn't touched, flagged for a separate task.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Grok Code Fast is specifically optimized for speed and cost across many tool-calling turns in an agentic loop, reading files, making an edit, running a command, reading the result, rather than for the deepest possible reasoning on a single turn, which means it will move through a codebase quickly and confidently, and a brief with no explicit blast-radius boundary is trusting that speed-tuned confidence to also self-limit its own scope, which is exactly the trade-off a fast, iteration-heavy model is least suited to make unsupervised. Naming allowed and off-limits files explicitly, rather than describing the bug and trusting the agent to infer reasonable boundaries, matters because an agentic loop optimized to keep making progress will often follow a plausible lead into an adjacent file if the actual root cause isn't where the bug report suggested, which is sometimes exactly the right instinct, and sometimes how a fix-a-timestamp-bug task quietly turns into an unreviewed edit inside billing code three files away, which is why the off-limits list carries a stated reason rather than reading as an arbitrary restriction. Requiring reproduction before any fix, and an explicit stop-and-report if reproduction fails, targets the specific failure mode of a fast agentic loop: it's quicker to pattern-match a plausible fix from the bug description than to actually verify the described behavior first, and a model under speed pressure has every incentive to skip straight to writing code rather than confirming the premise, which is how confident-looking fixes for bugs that don't reproduce as described end up shipped. Running the test command after every change rather than once at the end catches a regression at the exact iteration that introduced it, while the agent still has full context on what it just changed — the same regression caught only at the end requires the model to reconstruct which of several edits caused it, which a fast, high-iteration-count model handles less reliably than a single well-scoped diff-and-verify cycle. The explicit stop condition after verification, no bonus scope-creep pass, matters because an agentic coding loop with no defined end state will keep finding small things to improve once it's already inside a file, and each of those improvements is an unreviewed change riding along on a diff that was supposed to be one narrow bug fix, which is precisely the pattern that makes a fast model's output slower to review than the time it saved writing it.
What you get back
Reproduced: confirmed. Timezone change in settings updates the store immediately, but useEventTimestamps memoizes formatted timestamps keyed only on the raw event time, not on the current timezone, so the memo never invalidates when timezone changes. Root cause: the useMemo dependency array in useEventTimestamps.ts includes events but not the current timezone value from timezoneStore, so a timezone change alone never triggers recomputation. Diff: useEventTimestamps.ts, added timezone to the useMemo dependency array; timezoneStore.ts unchanged, no fix needed there. Test output: useEventTimestamps.spec.ts, 6 passed, including a new case for timezone change without event change. Outside allowed files, not touched: settings/TimezoneSelector.tsx shows the same stale-timestamp pattern in a preview panel — looks related, flagging as a separate task rather than fixing here.
Verified against
Grok Code Fast Grok Code Fast 1 · 2026-07-30
Changelog
- 2026-07-30 — Initial publish, verified against Grok Code Fast 1 in an agentic tool-calling loop.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
