Free concept playground · no account

AI Coding Dojo

Watch the coding agent's plan, diffs, and blast radius live.

AI Coding Dojo

AvailableFree

Give a scripted coding agent a task and watch its plan, its proposed diffs, and the blast radius across the repo — every file it wants to touch, and which ones are risky — before anything merges.

Plan

  1. Read auth/login.ts and middleware/index.ts to find the request path
  2. Add a token-bucket limiter in middleware/rateLimit.ts
  3. Wire the limiter into the login route
  4. Add a unit test covering the 429 path

Proposed diffs (4)

  • middleware/rateLimit.ts+480routine
  • auth/login.ts+62risky
  • middleware/index.ts+30routine
  • test/rateLimit.test.ts+240routine
3/ 5 blast radiusModerate
Files
4
Lines +/-
+81/−2
Risky
1
The blast-radius mapliteral, file-by-file

“The agent edited my code” becomes a literal map: 4 files in the queue, 1 of them risky, reaching a blast radius of 3/5. That’s a diff you can approve line-by-line, not a black box.

  • auth/login.ts+6/−2 — touches security- or schema-sensitive code; read this one closely.

Approve diff-by-diff — a couple of files need a careful read.

Was this playground useful?

AI Coding Dojo

Give a scripted coding agent a real task — add a rate limiter, fix a null-pointer crash, rename a database column — and watch it work in the open: its plan, its proposed diffs, and the blast radius across the repo. Instead of "the agent edited my code" landing as a vague worry, you get a literal, file-by-file map: every file it wants to touch, how many lines change, and which files are risky (auth, migrations, models). The moat is the blast-radius view — you decide before anything merges. Runs entirely in your browser (0 uploads, works offline).

How to use it

  1. Pick one of the three seeded tasks — rate limiter, null-crash fix, or column rename.
  2. Read the agent's plan first: what it intends to do, step by step, before it writes a line.
  3. Scan the proposed diffs — each file with its +added / −removed count and a risky or routine tag.
  4. Check the blast-radius gauge (1–5) and the risky-file count, then open the X-ray for the file-by-file map and the merge verdict.

What this clears up (the fundamentals)

  • Plan before edit — a good agent reads and plans before it touches anything. Seeing the plan first is how you catch a wrong approach while it is still cheap to redirect.
  • Diff review is the real interface — you approve or reject diffs, not vibes. A change is only as safe as the smallest diff you actually read.
  • Blast radius is countable — "how much did it change?" has an answer: files touched, lines added and removed, and how far the change reaches. A rename that hits a migration, a model, and auth is a 5, not a 1.
  • Risky files deserve a second read — auth, schema migrations, and models can fail quietly. Flagging them turns "looks fine" into "read these three closely."

Where it's used

A top-of-funnel AI-engineering discipline check — the fastest way to feel why agentic coding needs plan-first tasking and diff-review discipline, not blind auto-apply. It's a miatz build-lab concept playable: play the seeded version here, then learn to build the trace panel, the diff queue, and the blast-radius heat-map yourself against a live agent.

FAQ

Is this a real AI writing code?

No — this is a seeded, scripted demo. The three tasks, plans, and diffs are baked into the engine so the lesson (plan → diffs → blast radius) is stable and 100% offline. The live version, where you bring your own key and run a real agent against a sandboxed repo, is a separate mode.

What makes a file "risky"?

Files where a small change can fail quietly or widely: authentication, database migrations, and ORM models. The dojo tags them so your eye goes to the diffs that most need a careful read before merge.

How is the blast radius calculated?

Each seeded task carries a fixed 1–5 blast radius plus its own diffs. The engine sums the diffs — files touched, lines added, lines removed, risky-file count — and pairs that with the radius to produce a merge verdict. It is a deterministic rubric: no model call, no randomness.

What would I approve, and what would I reject?

That is exactly the debate the tool is built to start. A contained fix with zero risky files is usually a safe merge; a wide rename touching a migration, a model, and auth is the kind of diff you approve one file at a time — or send back.

Is anything uploaded?

No. The seeded tasks are scored entirely in your browser — nothing is transmitted, stored, or logged. Turn off your Wi-Fi and it still works.

Limits

This is a seeded teaching demo with three fixed tasks and hand-set diffs — a fast, honest illustration of plan-first tasking and blast-radius review, not a real code review of your repo. It does not run a model, open a sandbox, or read your files. Live BYOK inference against a real sandboxed repo — with a cost meter and an eval gate — is a separate future mode. The discipline it teaches (read the plan, review every diff, count the blast radius) is exactly the real practice.

Related

Part of the Demystify Playgrounds. Explore the rest from the Playgrounds home.

Bookmark this page (Ctrl+D, or ⌘D on Mac) — it works offline the next time you need it.

Ninety playgrounds. Zero setup.

Every concept here is playable free, no account — and inside the program you learn to rebuild the machinery yourself.