cd /news/ai-agents/use-ai-coding-agents-like-a-pro-fewe… · home › topics › ai-agents › article
[ARTICLE · art-161957] src=dev.to ↗ pub= topic=ai-agents verified=true sentiment=↑ positive

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

A developer has outlined a tool-agnostic workflow for keeping AI coding agents like Claude Code, OpenAI Codex, Cursor and GitHub Copilot cheap and accurate by aggressively managing context. The approach draws on Chroma's context-rot research, the "Lost in the Middle" paper and Anthropic's context-engineering guidance to argue that bloated sessions both multiply token costs and degrade output quality, citing a 7.5x input-token gap between a fresh 20k-token session and a stale 150k-token one. The workflow centers on lean, recurring project instruction files such as AGENTS.md, CLAUDE.md and Copilot instructions, pruning any line whose removal wouldn't cause a mistake.

by read9 min views7 publishedNov 1, 2026

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.

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.

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

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

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:

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:


## 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.

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:

/clear costs nothing, while /compact reads the whole conversation to summarise it, so it is itself a large request (/compact Focus on the API changes and the failing test keeps what matters instead of a generic summary. 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.

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.

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:

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:

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 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.

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).

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).

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

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.

Originally published at papansarkar.com.

── more in #ai-agents 4 stories · sorted by recency
── more on @claude code 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/use-ai-coding-agents…] indexed:0 read:9min 2026-11-01 · —