Tips & best practices

A few patterns that consistently make Magic Coder work better. None of these are rules — just things that fall out of using the agent regularly.

Be specific in the first prompt

Vague prompts produce vague work. Compare:

“improve the auth code”

versus:

“in services/api/auth/, the JWT validation function ignores the iss claim — make it required, fail closed, and add a test that asserts a missing iss is rejected”

The second prompt is better not because it’s longer, but because it tells the agent what to change, where, and how to validate. Magic Coder will turn it into reads, edits, and a test run, and stop when the test passes. The first prompt will produce a survey, a list of suggestions, and probably no concrete change.

When you don’t know enough to be specific, use plan mode — let the agent investigate and propose, then approve.

Use AGENTS.md as a runbook

A good AGENTS.md saves five minutes of “what’s the build command again?” exploration on every task. See Project context. The smallest viable file — build command, test command, lint command, one paragraph of architecture, three “never do this” rules — pays for itself in a single session.

Don’t let bad runs continue

If Magic Coder is heading in the wrong direction — wrong file, wrong approach, wrong assumption — interrupt with Ctrl+C and redirect. Letting it loop on a misunderstanding for two or three rounds wastes more time than the interrupt. The agent recovers gracefully from interrupts; it doesn’t recover gracefully from sunk-cost momentum.

(Two quick Escs clear the input draft, not the running agent. Ctrl+C is the agent stop.)

Use the follow-up queue

You don’t have to wait for the agent to finish before typing your next instruction. While it’s working, just type and press Enter — the message goes into the follow-up queue and the agent picks it up after the current turn. Up arrow lets you select queued items; e to edit, d to delete. This is a real productivity boost on multi-step tasks where you can see what the agent should do next while the previous step is still running.

Match reasoning effort to the task

Default at medium. Raise to high or xhigh when the task is genuinely hard — multi-file refactors, hairy debugging, security-sensitive changes. Drop to low for routine work. See Reasoning effort.

A common pattern:

1. Start at medium.
2. If the agent stalls, makes a wrong assumption, or produces a flat answer on a hard problem, switch up: /reasoning-effort high.
3. Repeat the message. Same context, deeper thinking.

Pre-approve routine commands

Approve-and-remember the commands you’d approve every time anyway: cargo test, npm run build, pnpm install, make lint. After the first session in a repo, the prompt should be quiet enough that it only fires on novel commands. See Command permissions.

Use threads, don’t fight them

If you’ve been working a problem and switch tasks, end the thread (/exit or /clear) instead of pivoting in place. The next thread starts fresh, with no leftover context to confuse the agent. You can always resume the original thread later with --continue <uuid>.

Prefer --plan over re-running

If the first attempt at a task came out wrong, don’t just rephrase and try again. Switch to --plan, ask for a plan grounded in the same goal, and inspect what the agent thinks the shape of the change is. Often the plan reveals a misunderstanding before any code is written.

Run --automagic for known shapes only

Automagic is great for “fix this kind of bug” or “regenerate this kind of artifact” — well-shaped tasks where you trust the agent to drive. Avoid it for exploratory work, refactors you care about, or anything where small differences matter. If you wouldn’t tell a junior engineer “go do this and don’t ask me anything,” you probably don’t want automagic.

Combine flags deliberately

Some combinations are worth memorizing:

• --plan (alone) — investigate first, you stay in the loop.
• --plan --automagic --trust --query "..." — investigate and execute hands-off; the eval-runner pattern.
• --continue <uuid> --reasoning-effort high --query "..." — pick up a thread with deeper thinking for the next step.
• --allow-long-context + a wide refactor — when context window matters more than per-token speed.

Start small

If you’re new to coding agents, don’t open Magic Coder against your largest, most-loved monorepo on day one. Start in a small repo, do something easy, watch how it works. After two or three sessions you’ll have a feel for what kinds of tasks suit the agent and what kinds you’re better off doing by hand.

When you don’t trust the result

You don’t have to merge what the agent produced. The TUI shows every diff before applying it. Even after applying, the changes are local — git diff is the source of truth, and git restore undoes. Treat Magic Coder’s output the same way you’d treat a junior engineer’s PR: read it, run the tests, push back where you disagree.