W3D10Sb
Can you steer an AI into shipping one feature that actually runs in a stranger's browser β and prove which lines you fixed yourself?
Shipped Feature
βΆ Enter ProjectContext
It's 10:01 PM, Global Game Jam 2025, submission closes at 10:55 PM. Your team has a playable game with a working boss fight. Your designer wrote victory-screen copy and has PNG files. Your artist is done. But the code isn't built yet, and the codebase was written by your predecessor (500-line GameState.ts, boss-death hook buried at line 342, UI mounts at MainUI.svelte:67). You have 54 minutes. You will spec it tight, generate code with AI, test it, review it, and push.
Mission
Produce a working victory screen that triggers when the boss dies, integrates into MainUI without breaking GameState, and ships in one merged PR with a recorded demo and documented spec.
Finish Line
A live public URL plus the prompt-and-fix log that got it there.
Deliverables
Shipped Feature
lessonOne small feature that actually runs in the browser, built by steering an AI codegen tool, with the working prompt and the fix log kept beside it.
Team Roles
Builder
Code partner. You translate spec into shipped code.
- Posts to PR draft: (a) exact AI prompt pasted, (b) full AI response captured (screenshot or code block), (c) which lines you edited and why (e.g., 'Line 34: changed setState to dispatch because GameState is immutable here'). Verification: teacher can reproduce the AI output by pasting your prompt into Claude.
- Runs the feature locally and posts: (a) commit hash, (b) 30-second local video showing boss dies β victory screen appears β copy reads correctly. Verification: teacher watches video and sees three events happen in sequence.
- Posts code-review comment with: (a) acknowledgement of reviewer's architectural concern (e.g., 'Yes, we dispatch instead of mutate'), (b) fix commit hash if needed, or (c) explanation with a code line reference if concern is already handled. Verification: reviewer clicks the commit hash and sees the fix live.
Product Owner
Specification & taste. You lock scope and judge fit.
- Posts to PR description before any code is written: (a) one-sentence feature spec ('Victory screen appears center-of-screen when boss health β€ 0'), (b) exactly 5 acceptance criteria (e.g., 'Screen appears within 500ms of boss death', 'Text is designer's copy (headline + 2 lines)', 'Player can dismiss it (click button or press Esc)', 'No game state is mutated', 'Score persists if player replays'). Verification: teacher reads the PR and counts 5 criteria listed.
- Posts sign-off comment after code review: 'Approved' (all 5 criteria met by the shipped code) OR 'Rejected: criterion [X] unmet because [reason].' Includes one screenshot reference to the merged feature (e.g., 'Headline reads "Victory" in 32px Roboto, β'). Verification: teacher reads the comment and sees a clear yes/no + screenshot evidence.
- At hour 78 (12 minutes before cutoff), if velocity is slipping, posts to Slack: 'Cutting [specific criterion, e.g., score persistence]. Reason: [e.g., data-sync complexity blocked Builder]. Ship without it.' Owns the decision visibly. Verification: cut is named and posted in writing.
Code Reviewer
Quality gate. You unblock or block.
- Reads PR diff before any demo and posts one specific concern on a code line, formatted as: 'Line [N]: [observation]. This [mutates global state / has no error handling / assumes async callback]. [Fix: use dispatch() / wrap in try-catch / await before render]. Or explain why current code is safe.' Verification: comment is on a specific line number and proposes a concrete action.
- Runs the demo video the Builder posts and replies: 'Tested on [timestamp in video]. Clicked boss β health bar empty β screen appeared in [~estimate]ms. Text is: [quote headline]. No console errors observed.' If demo fails: 'Tested: clicked boss, game froze for 2s, no victory screen appeared. Expected: instant screen with readable text.' Verification: teacher watches the timestamp in the video and sees the event happen or not.
- Posts final approval comment: 'Approved for merge. [Observed behavior]. [Risk resolution, e.g., Line 34 fix confirmed / Error boundary added / Timing within spec].' Verification: comment includes one specific observation + one risk outcome.
Designer
Copy and visuals. You make it feel like a win.
- Posts to PR description before code review: victory-screen copy as two lines: Headline (3β5 words, max 12 characters): 'YOU WIN' or 'VICTORY'. Body (max 15 words, one sentence): 'You defeated the boss. The world is safe now.' Verification: teacher counts words and verifies both lines are posted in the PR.
- Watches the final demo video and posts: 'Approved' (or) 'Redo: [element] needs [specific fix], e.g., 'Headline font needs to be white (currently gray), or 'Image asset #4 is pixelated on playback.' Verification: comment names the element, current state, and required fix; or one-word approval is posted.
Exemplars
- Devin β the first AI software engineer
Cognition AI
Landmark deployed autonomous agent (shell + editor + browser, long-horizon planning) demoed end-to-end β the bar a JARVIS capstone showcase aims at.