· 13 min read

Agentic Coding Is a Different Skill

AI Agents Claude Code Gemini CLI Developer Productivity MCP

I spent the last several months running Claude Code and Gemini CLI against real codebases. The playbook that came out of that is free and open source at github.com/vmishra/ai-coding-playbook. This post is the executive summary — the handful of ideas that earned their place in the book after months of trial and error.

The moment the shape of the problem became clear

Three hours into a debugging session, my agent started inventing function names. Not hallucinating generic helpers. It was citing specific methods in our codebase that didn’t exist. A function we had built together an hour earlier was suddenly unfamiliar. I asked it to re-read the file and it agreed to, then continued citing the wrong name.

The model hadn’t gotten dumber. The context window had gotten dirtier.

That was the week I stopped thinking of agentic coding as “a faster way to code” and started thinking of it as a new skill. Not an autocomplete on steroids. Not a marginal improvement. Something different, where a lot of my previous instincts were working against me.

The rest of this post is what that shift looks like in practice — the mental model, the habits, and the primitives that make agents work on real codebases instead of in demos.

Intelligence isn’t the bottleneck. Context is.

Hold this picture in your head for a second:

┌──────────────────────────────────────────────────────────────┐
│                      The Context Window                      │
│                                                              │
│   [ system prompt ][ your brief ][ files the agent read ]    │
│   [ tool results ][ the agent's own plans and notes ]        │
│   [ intermediate outputs ][ your follow-up messages ]        │
│                                                              │
│                  Everything the model sees                   │
└──────────────────────────────────────────────────────────────┘

The model has exactly one input: this window. It has no memory of prior sessions unless you give it one. It cannot “just know” anything about your codebase that isn’t either in the window or fetchable by a tool.

This single fact explains almost everything that goes wrong in a session:

  • “The agent forgot what we decided earlier.” It didn’t forget. The decision got crowded out by later content.
  • “It keeps making the same mistake.” The correction is in the window, but it’s buried under thirty file reads.
  • “It invented a function that doesn’t exist.” The real function is in a file the agent never opened. From the model’s perspective, inventing was the only option.

Every technique that actually works is, at the root, a technique for controlling what’s in the window, for how long, at what position. Internalize that, and the rest is details.

This is the argument Chapter 1 builds on, and it’s the reason Part IV of the book — the context-economics part — is what most people actually want first.

Briefing, not prompting

Prompting a chat model is a single-turn transaction. You type a question, it answers, you judge.

Briefing an agent is a multi-turn commitment. You describe an outcome, the agent reads, plans, edits, runs, observes, iterates, and you supervise and redirect. The input isn’t a prompt; it’s a working agreement the agent will return to across dozens of turns.

Every brief that works has the same four parts:

  1. Outcome. What “done” looks like, concretely, in terms the model can verify.
  2. Scope. What to touch, and explicitly what not to.
  3. Constraints. Non-goals. Conventions. Things out of bounds.
  4. Verification. How you’ll know it’s actually done.

A bad brief:

The API is too slow on the users endpoint, make it faster.

A good one:

Outcome: GET /users/:id p95 under 100ms in our staging benchmark. Scope: src/routes/users/get.ts, src/lib/db/users.ts if needed. Tests allowed in src/__tests__/routes/users/. Constraints: Don’t add caching — that’s a separate project and involves a product decision. Don’t change the response shape. Keep the existing transaction boundary. Verification: Run pnpm bench -- users-get. Show p50/p95/p99. If the only improvement you can find is caching, stop and tell me.

Same task. Radically different trajectory. The good brief is the entire difference between a 30-minute focused session and a 3-hour drift.

The full treatment, with a dozen worked examples and the anti-patterns to watch for, is in Chapter 3.

The four symptoms of context rot

Sessions don’t die because the model gets tired. They die because the context degrades faster than the session produces useful work. The symptoms are specific and predictable. Learn to spot them early, because they’re your cue to stop — not push through.

Repetition. The agent suggests a change it already made. Proposes an approach you already rejected.

Confident invention. Function names that don’t exist. Import paths that are wrong. The model’s priors leaking through because the real data got crowded out.

Drift. You asked for one fix. The diff touches seven files. The original brief’s boundaries have faded.

Hedging. “This should work.” “Usually this pattern…” The model is noticing its own uncertainty without being able to locate the thing it’s uncertain about.

When you see two of these in the same session, stop. Compact, or better, start fresh. A new session with your memory files loaded is not a cost — it’s a feature. The agent gets the best conditions for the new task, with nothing leaking in from the last one.

The most expensive thing you can do at this moment is keep going and “just give it more context.” You don’t need more signal. You need less noise. Chapter 9 is the full framework.

Memory: durable context without re-briefing

The model has no persistent state. Every new session starts with an empty window. If you don’t do something about that, you’ll re-explain your codebase, your conventions, and your constraints every single time.

Both CLIs solve this the same way: specific files that load automatically at session start.

For Gemini CLI, that’s GEMINI.md — user-global at ~/.gemini/GEMINI.md, project at ./GEMINI.md, and nested directory overrides. For Claude Code, it’s CLAUDE.md, plus .claude/rules/*.md with paths: globs for path-scoped rules.

What belongs in these files:

  • Build, test, and run commands with their real names — pnpm test -- path/filter, not “run the tests.”
  • Three sentences of architecture. Entry point, routing, persistence. No more.
  • Conventions the model won’t infer on its own — indent width, error handling patterns, naming across layers.
  • Non-goals — the things you don’t want the agent to do without asking.
  • Pointers — “for anything about billing, start from billing/README.md.”

What doesn’t belong: secrets, bulk documentation, contradictory rules, transient state like “working on X this week.”

The heuristic that’s served me well: target under 200 lines. Memory files that stay small are load-bearing. Memory files at 2,000 lines are dead weight the model pays for every single turn. When yours starts creeping up, break detail out into separate files and link them with @import.

Chapter 4 has the full hierarchy, starter templates for both CLIs, and the mistakes everyone makes on their first pass.

The four primitives that matter

Once you have memory, you compose. Four primitives, each with a distinct sweet spot. Using the wrong one for a given capability is the source of most “my workflow is a mess” pain.

Slash commands are named prompts you invoke with /name. They’re best for workflows you run yourself: /research <topic>, /commit that inspects the staged diff and proposes a conventional-commit message, /review with your team’s checklist baked in. Written in TOML for Gemini, Markdown with YAML frontmatter for Claude. Chapter 5.

Skills are capabilities the agent decides when to use. A skill is a directory with SKILL.md — the description loads up-front so the agent knows it exists; the body loads lazily when it’s actually relevant. Good for “when the user asks for a PR description, produce it in our format.” Chapter 6.

MCP servers expose tools to the agent: search_issues, query_bigquery, create_branch. The Model Context Protocol is the USB of agentic coding — one protocol, many servers, many clients. Anthropic introduced it; Google adopted it across Gemini CLI and the Agent Development Kit. Every server you connect contributes its tool descriptions to every single turn, so connect deliberately — the single most common MCP mistake is wiring up everything “just in case” and watching context costs explode. Chapter 7.

Hooks are scripts the runtime executes on specific events — before a tool runs, after a file changes, when the session ends. They’re where policy lives: block rm -rf, auto-format on edit, log every tool call for audit. Claude Code and Gemini CLI have closely similar hook models with slightly different event names but the same output protocol. Chapter 8.

The decision rule: a command that keeps growing “if” conditions wants to become a skill. A skill that must always fire wants to be a hook. A hook that handles rich domain logic wants to be a real tool exposed via MCP. Each primitive has a sweet spot. The book has working examples of every shape, and the assets directory ships drop-in versions you can copy into ~/.claude/ or ~/.gemini/ today.

Where the money actually goes

At individual-developer scale, an agentic CLI costs $20–$200 a month. Not a problem.

At team scale — 50, 100, 500 engineers running agents daily — it stops being a rounding error. The difference between a disciplined team and an undisciplined one is five figures a month, and it isn’t about “which model.” It’s about context discipline.

Here’s where tokens actually go, in rough order of size:

  1. File reads. A single 1,000-line source file is 3–8k tokens. Do that twenty times in a session and you have 100k+ tokens of file content crowding out everything else.
  2. Tool descriptions. Every MCP server, every skill, every command contributes to every turn’s header.
  3. Intermediate reasoning. Modern models produce substantial thinking that gets appended to context.
  4. Tool output. Verbose git log, jest output, shell output.
  5. Memory files. Loaded every session. A bloated CLAUDE.md is a recurring tax.
  6. Your prompts and the model’s replies. Usually the smallest slice.

Notice what’s not on the list: the actual code changes. Writing a file is cheap. Reading files is expensive. That asymmetry is the core economic insight of agentic coding, and almost every optimization is an application of it.

The seven levers that matter, in decreasing impact:

  1. Explore first, read narrowly. “Use Grep to find the three files relevant to X, then read only those in full” saves ~70% vs “understand the auth system.”
  2. Offload reads to subagents. A subagent that reads 40 files and returns a 500-token summary pulls ~60k tokens out of your primary context.
  3. Use prompt caching. Keep stable stuff at the top, volatile stuff at the bottom. Don’t edit CLAUDE.md mid-session — you invalidate the cache for everything after.
  4. Compact at the right moment — not when you hit the limit, when your signal-to-noise drops. Often just after a heavy exploration phase.
  5. Route to cheaper models for cheap work. Gemini Flash and Claude Haiku are 80–90% cheaper and completely fine for summarization, rote formatting, and unfamiliar-directory exploration.
  6. Scope MCP tool exposure. A server you use once a week shouldn’t load every session. Use per-project .mcp.json.
  7. Trim memory files. Target under 200 lines and use @import for detail.

Worked math from real sessions: a typical “add a new endpoint with tests” task on an undisciplined run burns around 190k input tokens. The same task with discipline — trimmed memory, scoped MCP, subagent-delegated exploration, compaction between phases, Flash for summarization — runs at around 70k primary plus 30k on the subagent at cheap-tier pricing. Roughly 3× reduction, same output quality.

Chapter 10 is the one most teams want first. It’s the economics chapter.

Subagents: the biggest single lever

A subagent is a second instance of the agent, spawned with a narrow task, running in its own context window. When it finishes, it returns a summary.

Two benefits: context isolation (heavy reads happen elsewhere, your primary stays sharp) and parallelism (several subagents work simultaneously on independent pieces).

Two risks: they still cost tokens (you just moved the cost off your screen), and parallelism magnifies briefing errors — four subagents can solve the wrong problem fast.

The discipline is the same one that makes delegation work with humans: give them a scoped goal, trust them to execute, verify the output. And critically, tell them what not to return — otherwise you get the full transcript back and the whole point of the subagent evaporates.

Chapter 11 is the full patterns library.

The wider ecosystem the book covers

The playbook devotes chapters to things that matter but aren’t strictly about the CLI:

  • Research as a first-class activity. Web search and fetch, /research as a habit, durable research docs vs ephemeral lookups. Chapter 12.
  • Tool connectivity. Three auth shapes for wiring agents into Google Cloud, BigQuery, Firebase, and internal APIs, with principle-of-least-privilege patterns. Chapter 13.
  • IDE integration. VS Code and JetBrains extensions, Firebase Studio (which replaced Project IDX in April 2025), and Cloud Workstations for team-scoped remote environments. Chapter 14.
  • Test generation. The failure mode of AI-generated tests is tests that pass while the feature is broken. Chapter 16 is about avoiding that specifically.
  • UI generation. Stitch from Google Labs with its agent-friendly DESIGN.md export, the newly launched Claude Design, v0 for production React, and Figma Dev Mode MCP for teams where Figma is source of truth. Chapter 17.
  • Local models. Qwen3-Coder, Gemma 4, DeepSeek. Ollama and vLLM. When local beats hosted. Chapter 18.
  • Google Antigravity. The agentic IDE with dual Editor and Mission Control views, up to 5 parallel agents. Chapter 19.
  • Agent SDKs. Google ADK for Python multi-agent systems on Vertex, and the Claude Agent SDK for TypeScript and Python. When the CLI isn’t enough. Chapter 20.

Six end-to-end playbooks

The book closes with six worked examples you can steal directly: triaging a vague bug report without skipping to a fix, a multi-file migration with subagent fan-out gated by pattern approval, a feature from spec to shipped with plan-before-edit, on-call triage that’s explicitly read-only, research-driven decisions that produce committable ADRs, and PR triage across eight open PRs in ninety seconds.

Each one applies the same disciplines from the earlier chapters. If you’ve read Parts I–V, they feel obvious. If you haven’t, they’re the short path to seeing the whole system in motion. Chapter 21.

What I wish I’d known on day one

Three things, if I could go back.

Sessions should end at task boundaries. Not at the end of the day. When a task is done, close the session. Open a new one for the next task. I resisted this for months and paid for every minute of resistance.

Plan before edit, every time. Gemini’s --plan and Claude’s --permission-mode plan are the single most useful flags for non-trivial work. Read the plan, push back, approve, then let the agent edit. It turns the session into a series of tiny reviewable steps instead of one giant “it did a thing” at the end.

Write the spec in a file before you paste it. The four-part brief — outcome, scope, constraints, verification — committed to specs/ in the repo. It forces clarity before the agent starts working, which is vastly cheaper than redirecting a drifting agent forty turns in.

None of these are clever. All of them took me longer to adopt than they should have.

Going deeper

This post compressed months of habits into around 2,800 words. The source material has real depth, and it’s free:

  • The full book: github.com/vmishra/ai-coding-playbook — 21 chapters, both Gemini CLI and Claude Code, primary sources throughout.
  • The assets: assets/ — runnable slash commands, skills, hook scripts, MCP configs, and settings starters you can drop into ~/.claude/ or ~/.gemini/ right now.
  • The annotated table of contents: docs/TABLE_OF_CONTENTS.md.

The book is MIT-licensed. Fork it, remix it, build a course on top of it, translate it — just don’t claim you wrote it.

If you try something from it on a real codebase and it does (or doesn’t) work the way a chapter claimed, please open a field-report issue. That’s the best feedback loop the book has, and it’s how the next version stays honest.

I’m Vikas Mishra, an engineer at Google. The views here and in the playbook are mine, not my employer’s.