←
How to talk to coding agentsCH. 02 / 07

The equation

The simplest frame is an equation. Whatever a coding agent gives you falls out of two things multiplied together: the agent itself, and what you hand it.

AGENTINPUTOUTPUT
()()OUTPUT
FIG. 2.1The output equation, expanded into its four levers.

That gives you four levers. There exist inputs that produce great outputs — the job is finding them.

TOOLUse a tool that was built for this.

Most people are still defaulting to whatever editor they had before agents were a thing, and bolting AI on. That's leaving the biggest, easiest win on the table.

The frontier here isn't subtle: Cursor, Claude Code, and Codex are significantly better than VSCode (with stock Copilot) or Antigravity. The difference can feel like swapping a junior for a senior engineer.

You don't have to commit to one forever. Try a new coding agent for a few weeks. If your day-to-day doesn't get noticeably easier, go back.

MODELPick the smartest model the work warrants.

Calibrate to the stakes of the task, not your defaults. A rough guide, as of mid-2026 (the specifics shift every few months):

Fast and cost-friendlySonnet 4.6 · Composer 2.5
Taste — writing, docs, PRs, UI/UX, animationsOpus 4.8
Problem solving, backend, gnarly debuggingGPT-5.5
Anything tricky, ambiguous, or multi-step+ Thinking on

Models also have distinct styles: how they structure code, what explanations they reach for, where they cut corners under ambiguity. If you're newer to AI coding, you'll attune faster by staying with one model for a while and learning its tics. Hopping between models before you have a feel for any of them slows you down.

Avoid "Auto" mode. Pick the model yourself, and keep bumping it to the latest one. A few reasons. First, Auto is optimized for the platform's margin, not your output — Cursor reaches for a cheaper model (Composer) unless you say otherwise, and if you're not cost-sensitive you can usually do better. Second, choosing yourself tunes your eye for each model's style. Third, your results get more consistent, so you actually learn which model to reach for when.

Thinking effort is another dial, and an increasingly important one to get right. Most tools expose four rungs: low, medium, high, xhigh. Default to high (or medium, if more cost-sensitive) and try dialing it down or up when the model lets you down by overthinking or underthinking.

LowTrivial edits, format fixes, one-line changes
MediumWell-specced work where the model is mostly executing
HighUnderspecced problems — planning through constraints, tradeoffs, real decisions. Also a good default.
xHighThe genuinely hard stuff: novel design, gnarly bugs, long-horizon plans
PROMPTBe specific. Show the model what good looks like.

Prompting is a skill. Some patterns that help:

  • Concrete over abstract. "Make this faster" gives the model nothing. "First paint is 2.4s, target under 1s, profile and start with the biggest wins" gives it a job.
  • Anchor on examples. "Match the style of components/PostCard.tsx" beats "make it look nice." Models are great at imitation, mediocre at taste.
  • Say what good looks like. Constraints, success criteria, what to avoid. The agent steers toward whatever you write down.

What consistently doesn't:

  • "Be careful." It's not careful. Constraints work; vibes don't.
  • "Think step by step." The model already does, and modern thinking modes do it better than any prompt incantation.
  • Politeness padding. Doesn't hurt, doesn't help. Save the keystrokes.

If you find yourself rewriting the same prompt for the fifth time, stop. The lever you actually need is the next one.

CONTEXTLoad what the agent needs to see.

Most "the model is dumb today" moments are actually "the model can't see the thing it needs." The prompt is the verb; context is the noun. Get the noun right and the verb almost takes care of itself.

Things to load:

  • Skills and project rules. A CLAUDE.md or .cursorrules that captures your project's patterns, conventions, and the things you're tired of correcting.
  • Reference material. The design doc, the API spec, the related PR. Drop them into the chat. Don't make the agent guess at what's already written down.
  • Screenshots. For UI work, an image of the current state plus a sketch of the target is worth ten paragraphs.
  • MCPs. Wire the agent into your actual systems — repo, dashboards, design tokens, internal docs. Same as giving a junior engineer access to the stack instead of describing it from memory.

Loading the right context is the strongest pull available on any of the four levers. It's also the most boring one, which is why it's underused.