Papan Sarkar

Posted on Nov 1 Originally published at papansarkar.com

Use AI Coding Agents Like a Pro: Fewer Tokens, Better Code

#agents #ai #coding #productivity

Most developers who complain that coding agents are expensive and sloppy are making the same mistake: they treat the agent like a chat window and let one session grow all day. In the 2025 Stack Overflow survey, 66% of developers named "AI solutions that are almost right, but not quite" as their top frustration. In my experience, "almost right" and "expensive" usually have the same root cause: too much of the wrong context.

This post is the workflow I use across Claude Code, OpenAI Codex, Cursor and GitHub Copilot. It is tool-agnostic on purpose. If you want the VS Code setup walkthrough, I covered that in Using AI Agents in VS Code. This one is about habits.

TL;DR

Context is the budget, not the prompt. Every turn re-sends the whole conversation, so a bloated session costs more and gets dumber at the same time.
One task per session. Clear between unrelated tasks. After two failed corrections, start over with a better prompt.
Keep your instruction file short. AGENTS.md / CLAUDE.md should hold only what the agent can't figure out from the code.
Give the agent a check it can run. Tests, a build, a linter. Without one, you are the test suite.
Push noisy work out of the main context. Subagents, filtered command output, CLI tools instead of piles of MCP servers.
Match the model and reasoning effort to the task. The biggest model on every typo fix is how bills explode.

Why context is the whole game

Three pieces of research explain almost every agent failure I see.

Performance drops as context grows. Chroma tested 18 models and found that "performance grows increasingly unreliable as input length grows," even on simple retrieval tasks (Chroma, Context Rot). In one test, models did much better on focused prompts of about 300 tokens than on the full 113k-token version (Chroma).

Position matters. The "Lost in the Middle" paper showed models use information at the start and end of a long context better than information buried in the middle (Liu et al., TACL). Your carefully written rule from 90 minutes ago is now in the middle.

Tokens are an attention budget. Anthropic's engineering team frames good context engineering as finding "the smallest possible set of high-signal tokens" that gets the result you want (Anthropic, Effective context engineering). Their Claude Code docs put it bluntly: the context window "is the most important resource to manage" (Claude Code best practices).

The cost side follows directly. Claude Code "sends your full conversation with every request," so a one-line question in a session open all day still pays for the whole history (Claude Code costs). Prompt caching softens this, since cache reads bill at a fraction of the normal input price (Anthropic prompt caching), but the cache has a lifetime. Come back after a break and you pay to reprocess everything.

Simple arithmetic: asking the same question in a fresh 20k-token session versus a stale 150k-token session is 7.5x the input tokens, and the stale session is more likely to answer wrong.

Do agents actually make you faster?

Short answer: yes for most people now, but not automatically. Here is the honest picture.

METR's randomised trial found experienced open-source developers took 19% longer with early-2025 AI tools, while believing they were 20% faster (METR, July 2025).
METR's follow-up says that result is now outdated and speedups "seem likely," but its new data is too biased by developers refusing to work without AI to give a reliable number (METR, February 2026).
Google's DORA 2025 report calls AI "an amplifier" of a team's existing strengths and weaknesses (DORA 2025). Throughput went up, but delivery instability kept rising (InfoQ on DORA 2025).
Trust is still low: 46% of developers distrust AI accuracy and only 33% trust it (Stack Overflow 2025).

My read: the gap between "agent made me slower" and "agent made me faster" is mostly workflow. The habits below are what close it.

Habit 1: Keep the instruction file short and boring

Every agent now reads a project instruction file: CLAUDE.md for Claude Code, AGENTS.md for Codex, Cursor and many others, .github/copilot-instructions.md for Copilot. AGENTS.md has become the shared format, now stewarded by the Agentic AI Foundation under the Linux Foundation (agents.md), and Copilot reads AGENTS.md and CLAUDE.md as well (GitHub Docs).

This file loads on every session, so every line is a recurring tax. All the vendors say the same thing:

Anthropic: "Aim to keep CLAUDE.md under 200 lines," and "Bloated CLAUDE.md files cause Claude to ignore your actual instructions!" (Claude Code costs, best practices)
OpenAI: "A short, accurate AGENTS.md is more useful than a long file full of vague rules" (Codex best practices).
Cursor: "Start simple. Add rules only when you notice Agent making the same mistake repeatedly" (Cursor rules).

The test for every line: would removing it cause a mistake? If not, cut it. Here is the shape I use for a Next.js + Node project:

# AGENTS.md

## Commands
- Install: pnpm install
- Dev: pnpm dev
- Test one file: pnpm vitest run path/to/file.test.ts
- Typecheck: pnpm tsc --noEmit
- Lint: pnpm lint

## Conventions the code won't tell you
- Server actions live in app/(actions)/, never inside components
- All DB access goes through lib/db/*.ts; no raw queries in routes
- Money is stored as integer paise, never floats

## Don't
- Don't edit files in migrations/ by hand; generate them
- Don't add dependencies without asking

## Done means
- Typecheck, lint and the relevant tests pass
- Show me the command output, not a summary of it

No "write clean code," no folder-by-folder tour, no API docs pasted in. The agent can read the code. Put workflow-specific knowledge (how to do a release, how to write a migration) in on-demand files: skills in Claude Code, "Apply Intelligently" or file-scoped rules in Cursor, task-specific markdown files referenced from AGENTS.md in Codex. Those load only when needed.

Habit 2: One task, one session

The most expensive pattern is what Anthropic calls "the kitchen sink session": you start one task, ask something unrelated, then go back (best practices). OpenAI says the same: "Keep one chat per coherent unit of work," because long single-project chats lead to "bloated context and worse results over time" (Codex best practices).

My rules:

New task, new session. In Claude Code, /clear costs nothing, while /compact reads the whole conversation to summarise it, so it is itself a large request (Claude Code costs).
Two strikes and restart. If I've corrected the agent twice on the same thing, the context is full of failed attempts. I clear and write a better first prompt that includes what I learned. Anthropic recommends exactly this (best practices).
Compact with instructions when you must keep going. /compact Focus on the API changes and the failing test keeps what matters instead of a generic summary.
Side questions go elsewhere. A quick "what does this flag do?" in the middle of a feature pollutes the context. Ask it in a separate window.

Habit 3: Plan only when the plan is worth it

Planning prevents the most expensive failure: a correct implementation of the wrong thing. Both Claude Code and Codex have a plan mode (Shift+Tab, or /plan in Codex) (Codex best practices).

But planning costs tokens too. Anthropic's rule of thumb is the best one I know: "If you could describe the diff in one sentence, skip the plan" (best practices).

Use a plan when the change touches several files, when you're unsure of the approach, or when you don't know this part of the codebase. For larger features, flip it around: have the agent interview you, write a SPEC.md, then start a fresh session to implement from the spec. The implementation session starts clean with a written contract instead of 40 turns of back-and-forth.

Habit 4: Write prompts with a "done when"

Vague prompts cause broad scanning, and scanning burns tokens. "Improve this codebase" makes the agent read everything; "add input validation to the login function in auth.ts" doesn't (Claude Code costs).

OpenAI's Codex guide recommends four parts: goal, context, constraints, and a "Done when" condition (Codex best practices). My template:

Goal: Users get logged out after a session timeout instead of a silent token refresh.
Context: Auth flow is in src/auth/. Token refresh is in src/auth/refresh.ts.
         Follow the error-handling pattern in src/auth/login.ts.
Constraints: No new dependencies. Don't change the public API of useSession().
Done when: A failing test reproduces the bug, the fix makes it pass,
           and `pnpm vitest run src/auth` plus `pnpm tsc --noEmit` are green.
           Paste the output.

Pointing to files with paths (or @file in Claude Code and Cursor) saves the agent from searching. Pointing to an existing pattern ("follow login.ts") gets you code that looks like the rest of your codebase instead of a generic tutorial.

Habit 5: Give the agent a check it can run

This is the single biggest quality lever. An agent "stops when the work looks done," and without a check it can run, you become the verification loop (best practices). With a test, build or linter, the agent runs it, reads the failure, and fixes it before you ever see the diff.

Three rules:

Ask for evidence, not claims. "Show the test output" beats "it should work now."
Run one test, not the suite. A full test run dumps thousands of lines of passing output into context. Point the agent at the relevant file.
Make the check deterministic when it matters. Claude Code hooks and Stop hooks run a script every time, unlike instructions in CLAUDE.md, which are advisory (best practices).

Habit 6: Keep noisy work out of the main context

Logs, test output, documentation pages and codebase exploration are the biggest context fillers. Three ways to keep them out:

Subagents for investigation. A subagent explores in its own context window and returns a summary, often 1,000-2,000 tokens (Anthropic, Effective context engineering). "Use a subagent to find how we handle token refresh and whether we already have OAuth utilities" keeps 30 file reads out of your implementation session. Note that subagents still cost tokens; they save context, and you can put them on a cheaper model.

Filter output before the agent sees it. Anthropic's example is a hook that greps a 10,000-line log for errors so the agent reads hundreds of tokens instead of tens of thousands (Claude Code costs). Even without hooks, you can just ask for it:

# Instead of letting the agent read the whole run:
pnpm vitest run 2>&1 | grep -E -A 5 '(FAIL|Error)' | head -80

Prefer CLI tools over stacks of MCP servers. Anthropic's own measurements show loading tool definitions and passing intermediate results through the model can be brutal: one workflow went from 150,000 tokens to 2,000 when the agent wrote code to call tools instead (Anthropic, Code execution with MCP). Claude Code now defers MCP tool definitions by default, but its docs still say CLIs like gh, aws and gcloud "are still more context-efficient than MCP servers" (Claude Code costs). Disable servers you aren't using in this task.

Habit 7: Match the model and effort to the task

Running the largest model at maximum reasoning on a rename is the fastest way to burn a budget. Prices differ a lot: on Anthropic's current list, Opus 5.5 output costs twice what Sonnet 5.5 does (Claude pricing), and Haiku 5.5 is far cheaper again (Claude pricing). Thinking tokens are billed as output tokens (Claude Code costs).

How I split it:

Task	Model tier	Reasoning effort
Rename, typo, add a log line, small CRUD endpoint	Mid or small	Low
Feature across 3-6 files with tests	Mid	Medium
Debugging a flaky race condition, architecture change	Top	High
Subagent doing file search or log summarising	Small	Low

OpenAI's Codex guidance lines up: low effort "for faster, well-scoped tasks," medium or high "for more complex changes or debugging," extra high for long, reasoning-heavy work (Codex best practices). In Claude Code, /model and /effort switch both mid-session (Claude Code costs).

Habit 8: Review with fresh eyes

An agent reviewing code it just wrote is biased toward its own reasoning. A reviewer in a fresh context sees only the diff and your criteria (best practices). I use a second session or subagent with a narrow brief: "Review this diff against SPEC.md. Report only gaps that affect correctness or stated requirements."

That last sentence matters. A reviewer asked to find problems will always find some, and chasing every nitpick leads to over-engineered code (best practices).

The token-waste cheat sheet

Symptom	Likely cause	Fix
Agent ignores a rule you wrote	Instruction file too long; rule lost in noise	Prune to essentials; move workflows to on-demand skills or rules
Usage spikes on a simple question	Session open for hours	`/clear` or a new chat per task
Same mistake after corrections	Context full of failed attempts	Restart with a better first prompt
Agent reads half the repo	Vague prompt	Name files, point to a pattern, add "done when"
Huge turns after running tests	Full test output in context	Run one file; filter to failures
Slow, pricey answers on easy tasks	Top model and max effort by default	Drop model tier and effort
"It works" but it doesn't	No runnable check	Require test or build output as evidence

When not to reach for an agent

You can't verify the result. If there's no test, no type system and no way to run it, a plausible diff is a liability.
The change is two lines you already know. Typing it is faster than writing the prompt.
The task is mostly a judgment call. Pricing logic, security boundaries, data deletion. Use the agent to explore options, then decide yourself.

The short version

Treat the agent like a strong engineer who forgets everything between sessions: short onboarding doc, one clear task, a definition of done, a test to run, and a fresh pair of eyes at the end. That is what uses fewer tokens, and it is also what produces code you can ship.

If you're planning a product and want someone who builds this way, I ship React/Next.js and Node.js products with AI in the loop for clients. Get in touch. If you're wiring LLMs into your own backend, start with my LLM integration guide.

Sources

Originally published at papansarkar.com.

DEV Community