DEV Community: Majid Allahverdi

The AI Context Engineering Playbook: 15 Ways to Stop Burning Tokens and Get More From Your AI Tools

Majid Allahverdi — Mon, 22 Jun 2026 17:02:07 +0000

Last month I hit my GitHub Copilot Plus limit twice in one day.

I wasn't doing anything extraordinary. I was jumping between three projects, a telehealth platform, an AI voice receptionist product, and client work. Normal sessions. Normal questions. Limit hit by noon.

My first instinct was to upgrade my plan.

Then I stopped and asked the real question: why am I burning through tokens this fast?

The answer wasn't my plan tier. It was how I was feeding context to the AI.

I've been building software for years, and I've optimized databases, APIs, and cloud infrastructure. But I was treating AI context like an unlimited resource, just dumping everything in and hoping for the best.

That changes with Context Engineering.

What Is Context Engineering?

Context Engineering is the discipline of controlling what enters an AI model's context window , and what doesn't.

Most developers think about what to ask the AI. Context engineering is about what the AI sees before you ask.

The goal:

Remove irrelevant information
Prioritize relevant information
Improve response quality
Lower token consumption

Think of it as memory management for AI.

Why Developers Waste So Many Tokens (Without Realizing It)

Here's what a typical AI coding session actually looks like:

The AI spends more tokens processing context than solving your problem.

I call this Context Debt , the AI equivalent of technical debt. It accumulates quietly until suddenly you're hitting your limit at noon on a Tuesday.

The 15 Fixes

1. Plan Before You Code

The most expensive token pattern is trial-and-error coding with AI.

What most developers do:

What you should do:

I now spend 5 minutes writing a plain-English plan first and asking the AI to review it before writing a single line.

The token savings from avoiding one bad iteration pays for the planning cost ten times over.

2. Keep Your `claude.md` and `AGENTS.md` Small

I've seen developers create instruction files like this:

Every line of that file gets loaded into context on every request. You're paying for it every time.

Your instruction file should point to information, not contain all of it.

3. Use CodeGraph Instead of Loading Entire Repos

The problem:

You ask about one function
AI reads 500 files to answer

The solution:

CodeGraph indexes your repository and lets the AI retrieve only semantically relevant files , not everything.

Potential reduction: 30–70% less context per request.

4. Use Context7 Instead of Pasting Documentation

Raise your hand if you've done this:

[Pastes 40 pages of Next.js docs]
"Here's the documentation, now help me fix this routing issue"

Context7 MCP solves this. Instead of pasting entire docs, it fetches only the relevant section at the moment you need it.

Potential reduction: 50–95% on documentation-heavy sessions.

5. Compress Logs Before Sending Them

Logs are the silent token killer. I learned this the hard way debugging a failed API integration.

Tools like RTK can summarize logs before they hit your context window.

Potential reduction: 80–99%.

6. Reduce Verbose AI Responses

Every word the AI writes today becomes part of your context tomorrow.

Long responses → bigger context → slower next response → more tokens used → repeat.

Ask for concise output explicitly:

Some tools like Caveman Mode enforce this automatically.

7. Use Session Handoffs

Long sessions degrade. Not just in token cost , in quality too. The AI starts losing the thread.

My workflow now:

A fresh session with a clean summary outperforms a bloated long session every time.

8. Understand Prompt Caching (And Use It)

Modern AI systems cache the beginning of your context so they don't reprocess it every time.

Here's how it works:

The key: keep your system prompt and project instructions stable. Every time you change them, you invalidate the cache and pay full price again.

If you're building on the Anthropic API directly, prompt caching can reduce costs by up to 90% on repeated calls with the same context.

9. Learn Prefix Matching

This is the mechanism behind prompt caching that most developers don't know about.

AI systems cache context based on matching prefixes , meaning the beginning of your prompt must be identical between requests to get cache benefits.

Small edits to the top of your prompt destroy your cache. Put dynamic content at the end, not the beginning.

10. Monitor Context Usage Like Infrastructure

You monitor CPU. You monitor memory. You monitor database query times.

Do you monitor token consumption? Most developers don't , until they hit a limit.

Tools like Token Dashboard give you visibility into where tokens are actually going. You cannot optimize what you do not measure.

11. Audit Your MCP Servers

MCP servers are powerful , they connect your AI to GitHub, Slack, Google Calendar, internal APIs, and more.

But every connected tool adds to your context overhead, whether you use it in that session or not.

Do a quarterly audit. Remove what you don't use regularly. The tools you connect "just in case" are costing you on every request.

12. Stop Documentation Inflation

This one is sneaky because it feels productive.

You create claude.md. Then you add more. Then AGENTS.md. Then project-rules.md. Each one grows over time because adding feels safer than removing.

The best instruction files are short, focused, structured, and easy to cache. Review them monthly and cut ruthlessly.

13. Use Model Tiering

Not every task needs your most powerful (and expensive) model. I use a simple rule:

Using a high-reasoning model to write a README is like hiring a senior architect to sweep the floor. Technically works. Expensive mistake.

14. Retrieve Context, Don't Dump It

This is the mindset shift that matters most.

Most developers think: "I'll give the AI everything so it doesn't miss anything."

Context engineering says: "I'll give the AI exactly what it needs for this specific task."

Tools like CodeGraph, Context7, and RAG systems are built around this principle. The shift from dumping to retrieving is where most of your gains will come from.

15. Treat Token Consumption as an Infrastructure Cost

I track cloud costs, API costs, and infrastructure expenses across my projects. AI token consumption belongs in that same category.

Engineering teams that treat tokens like infrastructure will:

Spend less on AI subscriptions
Get better and more consistent outputs
Scale their AI usage without linear cost growth

The teams that don't will keep hitting limits and blaming their plan tier.

The Full Picture

Here's how all 15 techniques map to the problem they solve:

Recommended Tool Stack

Category	Tool
Repository search	CodeGraph
Documentation retrieval	Context7 MCP
Log compression	RTK
Concise responses	Caveman Mode
Token monitoring	Token Dashboard
Context management	Claude Code
Planning	Plan Mode
Session optimization	Session Handoff

Final Thought

Most developers focus on prompt engineering , how to ask the AI better questions.

The next competitive advantage is context engineering , what the AI sees before you ask.

I hit my Copilot limit twice in one day because I was treating a limited resource like it was unlimited. Once I started managing context deliberately, my sessions got longer, my answers got better, and I stopped upgrading plans as the solution to a problem that wasn't about the plan.

The goal isn't to use more AI. It's to get more value from every token.

I'm MJ , Cofounder and Full-Stack Engineer at BeepLife, building healthcare technology in Toronto. I write about what I'm actually learning building with AI.

Found this useful? Follow me here or connect on LinkedIn and X.

Skills.sh Is the npm Moment for AI Agents (And Most Developers Haven't Noticed)

Majid Allahverdi — Tue, 16 Jun 2026 15:40:40 +0000

I started building AI agents about two years ago. Not toy demos, actual production features inside a health-tech product. And every single project started the same way.

Write the tool-calling wrapper. Handle the edge cases in structured output. Figure out how the agent should read a PDF without hallucinating page numbers. Build the retry logic. Wire up the logging.

Same boilerplate. Every time. From scratch.

The frustrating part is that every developer building agents is doing this too. Quietly. In their own repo. And nobody shares it.

That is the real infrastructure problem in the agent space right now. Not the model. The model is fine. The problem is everything in between the model and a working agent.

Skills.sh is trying to solve that. And after spending time with it, I think it has a real shot.

What is the "agent infrastructure gap"?

When npm launched, developers were already writing JavaScript. The language was not the bottleneck. The bottleneck was that every team was reinventing the same utilities and then never sharing them. npm gave the ecosystem a way to publish, discover, and install reusable logic.

Agent development is in that same phase right now. The LLMs are capable enough. Claude, GPT-4, Gemini, they can all do the work. But the procedural knowledge layer, the "how to actually do this specific thing correctly," lives inside private codebases, personal notes, and Slack messages.

How do you reliably parse a multi-page PDF inside an agent? How do you get consistent structured output from a chain of tool calls? How do you write a SKILL.md that actually teaches the agent something useful instead of being ignored?

Everyone figures this out on their own. Nobody publishes it in a way other agents can consume.

What Skills.sh actually is

Skills.sh is an open ecosystem from Vercel for discovering, installing, and sharing reusable capabilities for AI agents.

A skill is a SKILL.md file. It is a markdown document with a small YAML frontmatter block at the top:

---
name: my-skill
description: What this skill does and when to use it
---

# My Skill

Instructions for the agent to follow when this skill is activated.

## When to use
Describe the scenarios clearly.

## Steps
1. First, do this
2. Then, do that

That is it. Plain text. Version controlled. Shareable.

To install a skill into your agent, you run one command:

npx skills add anthropics/skills

The CLI detects which coding agent you are using, and places the skill where that agent can find it. Claude Code, Cursor, GitHub Copilot, Windsurf, Codex, Gemini, VS Code, Cline. Over 38 agents supported. One skill works across all of them.

The project is open source (MIT license) on GitHub at vercel-labs/skills. The underlying specification was originally developed by Anthropic and released as an open standard in late 2025. Skills.sh is the directory and leaderboard built on top of that spec.

The numbers tell you this is already real

I always check adoption numbers before deciding whether something is worth writing about. Early-adopter hype without traction is noise.

Skills.sh currently shows over 91,000 total installs on the leaderboard. The top skill, find-skills from Vercel Labs, has 1.4 million installs. Anthropic's frontend-design skill has 391,000. Microsoft published a full suite of Azure skills that together have over 4.5 million installs.

Look at who is publishing: Vercel, Anthropic, Microsoft, Supabase, Firebase, shadcn, Expo, Better Auth, Convex, Sentry, Firecrawl. These are production teams shipping and maintaining skills. Not weekend projects.

The community side is growing too. Matt Pocock published TypeScript skills. Independent developers have published skills for debugging workflows, code review, TDD, and marketing automation. The long tail is filling in fast.

This is not early-adopter hype. This is an ecosystem that has already moved past the "will it survive?" question.

What actually changes architecturally

Here is the shift that I think matters most, and it is not about the tooling.

The traditional approach to building agents is monolithic. You decide upfront what your agent can do, you build all of that in, and you ship it. If it needs a new capability, you go back into the codebase.

Skills push you toward a composable model. Your agent starts minimal. It has a core set of instructions. Then it picks up capabilities based on what the project actually needs.

Working on a Next.js project? Add vercel-labs/next-skills. Need the agent to understand your Azure infrastructure? Add microsoft/azure-skills. Want consistent TDD practices across your codebase? Add mattpocock/skills.

The agent does not know about these capabilities until you install them. And when you switch projects, you install different skills. The agent adapts.

I have been using Claude Code in my own projects, and this model changes how I think about agent setup. Instead of a long system prompt trying to encode everything, I have a small core instruction set and a set of skills that load in for specific contexts. It is cleaner. It is easier to maintain. And it is shareable, so the next project I start does not begin from zero.

There is also a security dimension worth noting. Skills.sh runs routine audits on published skills and flags anything suspicious. The audits page shows ratings for every skill. In an ecosystem where anyone can publish, that matters.

A practical example: reading documents inside an agent

One of the most painful things in early agent work is document handling. You want the agent to read a PDF and extract specific information. Sounds simple. In practice, agents hallucinate page numbers, misread tables, and lose track of multi-page structures constantly.

Anthropic published a pdf skill with 99,000 installs. It gives the agent a structured approach for reading and extracting from PDF documents. Install it once, and every project where you use that agent gets consistent document handling.

Same thing for frontend work. The frontend-design skill from Anthropic's team encodes design system constraints, typography rules, and component patterns. Instead of writing a long prompt that says "please use 14px font and no gradients," the skill handles it. And it is versioned, so when the guidelines update, you pull the latest version.

This is what I mean by procedural knowledge. Not what the agent can do in theory. How it actually does specific things in practice.

How to try it right now

If you are already using Claude Code, Cursor, Copilot, or any of the other supported agents, you can try this in under two minutes.

npx skills add anthropics/skills

That installs Anthropic's official skill collection including frontend-design, pdf, skill-creator, and others. The CLI will detect your agent and place them correctly.

If you want to browse first, go to skills.sh and filter by topic or agent. The leaderboard shows install counts so you can see what the community actually uses rather than just what gets promoted.

One more thing: if you build something useful and want to share it, publishing a skill is as simple as pushing a SKILL.md file to a public GitHub repo. The ecosystem is open. The spec is public. You do not need permission to contribute.

The npm moment for agent behaviour happened quietly. I would rather know about it earlier than later.