Just Talk To It

Stop overthinking prompts. Treat your agent like a teammate you can interrupt, redirect, and ask for options. If the model is strong and the feedback loop is tight, "just talk to it" beats elaborate plan documents and orchestration theatre.

The temptation to craft elaborate prompts is real. Describe the feature, specify file structure, outline edge cases, define error handling. The prompt becomes longer than the code it produces. And half the time, the agent does something slightly different because the important constraint was buried in paragraph three.

Compare that to starting with "build me a form that validates email and password" and letting the agent ask clarifying questions. Five minutes of conversation often produces better code than forty-five minutes of monologue. The agent asks about validation rules you hadn't considered. It suggests patterns you didn't know existed. The conversation surfaces requirements that elaborate prompts bury.

The difference isn't prompt quality. It's interaction bandwidth. Dialogue beats specification.

Stop optimising prompts. Start optimising interaction bandwidth: rapid iteration, frequent check-ins, small reversible changes, tight deploy cycles. The agent isn't a "code generator." It's a high-throughput implementer. Quality depends on your ability to control blast radius and keep the loop tight between intent, change, and verification.

Blast Radius Is Your Unit of Work

Blast radius = expected scope of a change (files touched, time, risk). Throw many small bombs or one big one. Multiple big bombs at once destroys your ability to reason, review, and recover.

Blast radius gets out of control fast. Ask an agent to "refactor the authentication system" and three hours later it's touched seventeen files, renamed functions that other services depend on, introduced subtle bugs that tests don't catch. The changes can't be reviewed meaningfully because the blast radius is too large. The only option is to revert and start over with smaller, scoped requests.

If progress time or touched files exceed your mental estimate, interrupt immediately and ask for a status update. Keeps the agent aligned. Prevents it from "solving the wrong problem correctly."

Useful control prompts (short, human language):

• "What's the status and what files have you changed so far?"
• "Give me a few options before making changes."
• "Stop and summarise the likely blast radius."

Surprisingly similar to managing humans. Best senior engineers are interruptible, communicative, predictable about scope. Agent management maps to engineering management - expectations, scoping, feedback cadence - not "prompt wizardry."

Parallel Agents Without Worktrees

High-output pattern: multiple agents in parallel in the same repo, relying on atomic commits and git hygiene.

Argument against git worktrees: operational friction. One dev server, one evolving state, quick click-through testing. Branch-per-change is slower when validation is "run the app and poke it."

Two requirements:

1. Agent must commit only files it edited (otherwise parallel work self-sabotages)
2. You need intuition for when "one more change" spills into a new blast radius

Prefer CLIs Over MCPs

Strongest tactical argument: many MCPs are "a CLI wrapped in tokens." If the model can call gh or any known CLI, it discovers usage via --help and you avoid injecting large tool descriptions into context.

Every token describing tools is a token not spent reasoning about your code. MCP definitions are recurring fixed cost. CLI usage is often in world knowledge already.

Heuristic:

• Stable, discoverable (--help), commonly known tool? Prefer CLI.
• MCP only when it closes a loop you can't close with CLI + logs (e.g. direct browser/devtools integration).

Prompting Style for Strong Agents

With stronger agents, prompts naturally get shorter. 1-2 sentences plus a screenshot can outperform long spec dumps. Agent locates code via visual strings and UI cues.

Two high-leverage modifiers:

• "Read all code that could be related."
• "Create possible hypotheses and test them."

Not magic words. Explicit instructions to allocate time to discovery and avoid the first plausible fix.

Schedule Refactor Days

Agent-written code drifts toward duplication and "good enough" unless you deliberately refactor. Productive rhythm:

• Fast feature iteration
• Dedicated "refactor days" driven by tooling (duplication detection, dead code, lint rules, deprecations, slow tests)

Agent-written code drifts toward duplication and "good enough" unless you deliberately refactor. After months of heavy agent use, codebases accumulate multiple implementations of the same logic. None wrong. Each good enough for its feature. Collectively, a maintenance burden.

The fix is scheduling: declare "refactor Fridays" - no new features, just cleanup. Consolidate duplication, remove dead code, fix lint rules, address deprecations. The agents do most of the refactoring work. You just decide what good looks like.

Flips a common fear ("AI creates slop") into an operating model: slop is a scheduling problem, not inevitability.

Automation by Randall Munroe, CC BY-NC 2.5, via xkcd.

Comparison Table

Summary

• Change control beats prompt cleverness. Control how much changes at once.
• Use blast radius as your unit. Small, isolatable diffs beat large speculative changes.
• Prefer CLI over MCP. Avoid context tax.
• Short prompts + screenshots beat long specs. Strong agents can read and discover.
• Schedule refactor days. Slop is a scheduling problem.

What's Next

Next time you reach for an elaborate agent harness, ask whether a simple conversation would achieve the same result faster. Usually yes - if the model is strong enough and you're willing to steer.