Then, two months later, Garry Tan changed his mind:

The MCP critics correctly identified the problem (bloated, auto-converted MCP servers) but in my opinion they incorrectly blamed the protocol! I’ve shipped an MCP server, a CLI, and 30+ agent skills. Here’s when each approach actually wins.

CLI Wins When You Have a Terminal

On pure performance, CLI + Skills beats MCP on every measured dimension for developers and agents with terminal access.

I use gh CLI for everything GitHub-related, not the GitHub MCP server. Claude Code defaults to gh too.

# CLI: 1 tool call, shell filters the result, ~1,400 tokens
gh issue list --limit 5 --json title,state | jq '.[] | .title'

# MCP: model loads 93 tool schemas (~55K tokens), picks one,
# gets the full response in context, then reasons over it

ScaleKit benchmarked this across 75 runs using Claude Sonnet 4. CLI used 4–32x fewer tokens per operation. CLI hit 100% success rate; MCP hit 72%. At 10,000 operations per month, CLI costs ~$3.20 vs MCP’s ~$55.20.

The pipe architecture is why. Intermediate JSON never enters the context window. The shell does the filtering, not the model. jq, grep, awk, head are context-window-efficient filters with no MCP equivalent.

The context window tax compounds. GitHub’s MCP server exposed 93 tools at the time of that benchmark, roughly 55,000 tokens of schemas before the first message. (They’ve since cut the defaults to 52, but it’s still a lot.) Stack a few MCP servers and you can lose 72% of a 200K context window to schemas alone.

Every major coding agent (Claude Code, Codex, Cursor, Aider, OpenHands) uses bash as its foundation because models trained on billions of bash examples. Zero MCP schemas in training data. Even Anthropic conceded: their code execution approach reduces 150K tokens down to 2K, a 98.7% reduction.

The Context Window Complaint Is Outdated

A lot of the "MCP eats my context window" complaints haven't caught up with the fixes. Claude Code now defers MCP tool schemas by default and loads them on demand. Cursor does the same, reporting a 46.9% reduction in total agent tokens. Anthropic's API, OpenAI, and Cloudflare have shipped similar approaches. If you're using Claude Code or Cursor, you already have tool search. If you're building on the raw API, you need to opt in (defer_loading: true per tool). The ScaleKit benchmarks above don't mention tool search and tested against GitHub's hosted MCP server directly, so they likely reflect the pre-tool-search experience. The gap is narrowing fast for coding agents with tool search enabled, but the full context tax still hits API builders and Claude Desktop users who haven't opted in.

CLI has a cost most people don’t talk about, though: you’re giving the agent a shell, and the security surface is the entire operating system.

But Why Not Just APIs?

MCP’s auth IS OAuth 2.1, the same standard REST uses. OpenAPI has described APIs for machines since 2015. You can auto-generate MCP servers from OpenAPI specs. Every agent can call REST APIs with requests or curl. No special client libraries needed. MCP adds JSON-RPC, session management, and SSE complexity on top of plain HTTP.

All true. So if MCP generation from OpenAPI is mechanical, why not let each client auto-generate what they need? Because auto-generated servers are what got us into the 93-tool, 55K-token mess. Curation requires human judgment about what an agent needs vs. what an API exposes.

Several SaaS companies with excellent REST APIs (Linear, Stripe, Slack, Figma, GitHub, Notion, Sentry) built hand-curated MCP servers anyway. REST can do the job technically. What it doesn’t give you: frictionless distribution, non-developer access, and centralized control over what each agent can see.

With a REST API, every consumer gets the same endpoints. With an MCP server, you can scope tools per token. An on-call bot gets get_dag_runs and get_task_logs. A CI agent gets trigger_dag_run. An analyst gets read-only tools. Same server, different tool sets based on who’s connecting.

REST APIs also carry versioning overhead: v1/v2, deprecation cycles, migration guides, client library updates. MCP tools describe themselves at runtime. The model reads the schema dynamically, so the server can evolve without the same breaking-change coordination.

What Neither Solves

“Just use CLI + an API backend with auth and logging.” Sure, you could. But now you also need per-token tool scoping and a schema agents can discover. You’ve just rebuilt MCP, except yours doesn’t plug into Claude Desktop, Cursor, or ChatGPT without custom integration.

Distribution

CLI means downloading a binary, installing dependencies, managing PATH, dealing with platform differences, and handling version skew. REST is better but each consumer still writes their own integration code: auth, endpoint mapping, response parsing. Agent Skills have the same problem. Skill paths vary across skill.sh, Claude Code, and Cursor, and the MCP community is exploring using MCP itself as the distribution channel for skills. (More on Skills & its distribution in a separate post soon.)

Subscribe now

MCP: URL + token. Done. The server updates once and every MCP-compatible client (Claude Desktop, Cursor, ChatGPT, Codex, and hundreds more) gets the new version instantly. No binary downloads, no deps, no path resolution, no upgrades on the consumer side. The integration math shifts from M×N (every consumer × every API) to M+N (one server + any number of clients). Anthropic’s MCP Connector takes this further: API-to-API, no client code at all.

It’s also convenient from Claude Code, Cursor etc to know when a MCP server is down or needs authentication.

MCP has a rough edge here, though: try connecting to two Slack workspaces or two Snowflake accounts from the same client. Both server instances expose identically-named tools (send_message, query), and most clients (Claude Code, Cursor) route calls to the wrong instance or suppress one entirely. The spec says clients should prefix tool names to disambiguate, but nobody does it well yet. CLI tools handle multi-instance naturally.

Non-Terminal Consumers and Non-Developers

Some consumers don’t have a terminal at all. A large marketplace company runs an on-call bot that queries their data platform for incident triage. Read-only, no human in the loop, no terminal. It needs HTTP transport with authentication. Claude Desktop users want to check their pipeline runs without installing a CLI. Mobile apps and internal AI products need server-side access. Server-side MCP doesn’t care about machine paths or local config. It works the same whether the consumer is a desktop app, a mobile client, or another service.

Then there are the people who interact with data platforms but aren’t developers. An analyst checking if a pipeline ran, a PM tracking data freshness, an SRE who touches the system once a month and doesn’t want to install a CLI and learn its flags. Server-side MCP gives them access through tools they already use (Claude Desktop, ChatGPT, internal chatbots) without asking them to open a terminal.

Skills need a local environment. They reference files on disk, run scripts relative to a working directory, and assume a terminal. Not an option for a Slack bot, a mobile app, or a non-technical user.

Access Control and Security

Any system with coarse role models has this problem: the API’s permissions don’t match what you’d give an agent. You end up with roles that are either too restrictive (can read but can’t trigger operations) or too permissive (can trigger operations but also read secrets and credentials).

CLI-based agents add another dimension to this. You’re giving the agent a shell, and the security surface is the entire operating system. When Anthropic’s Claude Code source leaked via npm, security researchers at Adversa found that deny rules silently stopped working when a shell command contained more than 50 subcommands. A developer who configured “never run rm“ would see it blocked normally, but 50 no-op commands before the dangerous one bypassed the check entirely. Anthropic patched it, but the broader pattern is that CLI permission models are hard to get right because the set of possible commands is unbounded.

MCP servers have their own security risks. Tool responses are untrusted text that the model interprets, and a compromised server can embed instructions that hijack the agent’s behavior (prompt injection). Neither approach is inherently safe. The difference is the attack surface: CLI agents can do anything the shell allows; MCP servers expose a fixed set of operations.

The fix for the role-model problem is a filtering proxy: expose the safe operational endpoints, hide the ones where secrets live. For enterprises, this is where MCP earns its keep. The security boundary lives on your infrastructure instead of on every developer’s laptop. Scoped tokens per team or role. Audit logs showing which agent called which tool and when. You can update access policies without pushing changes to every client. Enterprises already have API gateways (Kong, Apigee) for REST, and those work too. MCP’s advantage is combining the gateway function with distribution and non-terminal consumer access in one layer, instead of running three separate systems.

Which One When

Justin Poehnelt calls it the abstraction tax: every layer between the agent’s intent and the API loses fidelity. The question is whether the accessibility gain justifies the loss. His framing: “MCP and CLIs aren’t competing. They’re different answers to the same question: how much fidelity are you willing to trade for accessibility?”

For simple API surfaces, 5–8 curated tools cover the main use cases without severe fidelity loss. For complex APIs with hundreds of endpoints, the tax is much steeper and CLI or direct REST makes more sense.

MCP the protocol is fine. MCP servers built by auto-converting 80 REST endpoints into 80 MCP tools are what poison the context window and confuse the model. Garry Tan landed on this too: “light and purpose-built and engineered.”

Here’s how I think about it:

• CLI + Skills for developers and agents with terminal access. 4–32x fewer tokens, pipe architecture, bash is already in the model weights.

• Server-side MCP for everyone who doesn’t have a terminal or doesn’t want one: non-developers (analysts, PMs, SREs), non-terminal agents and bots, mobile apps, and enterprises that need a central control plane with scoped tokens and audit logs.

These are layers, not competitors. Skills teach agents how to think about a domain. CLI and server-side MCP are two ways to give agents tool access, optimized for different consumers.

Aaron Ott put it well: MCP is the transport, skills are the instructions. The future is probably both flowing through the same pipe.

Build for both. CLI + Skills where you have terminal access, server-side MCP where you don’t. And whatever you do, don’t auto-convert your entire API into MCP. Curate ruthlessly.

Next up: why Skills are the most powerful layer in this stack, and how to build them without the distribution headaches. Subscribe if you want the details.

Today, it happened again. Shortly after midnight UTC on March 31, someone with access to the axios npm account published axios@1.14.1. It looked normal. It resolved as latest. It contained a remote access trojan.

The malicious version injected a fake dependency called plain-crypto-js with a postinstall script that downloaded platform-specific RAT payloads: a binary on macOS, a PowerShell script on Windows, a Python dropper on Linux. It phoned home to a C2 server, set up persistence, then deleted its own traces and swapped is package.json with a clean decoy.

Socket flagged the malicious dependency within six minutes, but the compromised axios versions stayed live for about three hours before npm pulled them. Anyone who ran `npm install` with an unpinned axios dependency during that window got owned.

This keeps happening. event-stream. ua-parser-js. colors and faker. Now litellm and axios in the same week. The playbook is the same every time: compromise a maintainer account (or CI pipeline), publish a malicious version, race against detection. The window is small, usually hours, but the blast radius is huge because package managers resolve to latest by default, immediately.

One of the fix: don’t install packages published less than N days ago.

Native support

npm (v11.10+)

# ~/.npmrc
min-release-age=7

One line. npm won’t resolve any version published less than 7 days ago. Covers npm install, npm add, and npx. Value is in days.

pnpm (v10.16+)

# pnpm-workspace.yaml
minimumReleaseAge: 10080  # minutes (= 7 days)

Same behavior. Value is in minutes.

Bun (v1.3+)

# ~/.bunfig.toml
[install]
minimumReleaseAge = 604800

Value is in seconds. 604800 = 7 days.

uv (v0.9.17+)

# ~/.config/uv/uv.toml
exclude-newer = "7 days"

Accepts relative durations (7 days, 1 week, P7D) and absolute timestamps. Covers uv pip install, uv add, uv sync, and uv run --with.

pip (v26.0+)

pip install --uploaded-prior-to 2026-03-24 requests

Absolute timestamps only, no relative durations. If you use uv for Python, its config already covers this.

Yarn (v4.10+)

# .yarnrc.yml
npmMinimalAgeGate: 10080  # minutes (= 7 days)

Yarn Classic (v1) has no support. Use npm or pnpm instead.

Deno (v2.6+)

deno update --minimum-dependency-age P7D

Flag-based, applies to deno update and deno outdated.

Cargo, Go, and Gem

No native support yet.

• Cargo has no native cooldown support. The third-party cargo-cooldown wrapper exists. Pin exact versions and review before updating.

• Go modules are immutable once fetched by proxy.golang.org, which prevents after-the-fact tampering. But there’s no publish-age filter. Pin exact versions in go.mod.

• Gem has gem.coop enforcing a 48-hour delay, but rubygems.org has no equivalent. Pin in Gemfile.lock.

The AI agent angle

Coding agents (Claude Code, Cursor, Copilot) make this worse. A human might notice something odd about an install. An agent won’t — it’ll resolve to latest, run postinstall scripts, and keep going.

I added a Claude Code PreToolUse hook that does two things:

1. Blocks package managers without native cooldown (pip, cargo, go, gem) and suggests safe alternatives

2. Blocks attempts to bypass native configs (passing --min-release-age=0, --exclude-newer, editing .npmrc, etc.)

When the agent tries pip install some-package, it gets:

BLOCKED by package quarantine: pip — no native date-gate

Policy: all packages must be published 7+ days ago to protect against
supply-chain attacks (compromised maintainer accounts publishing malicious
versions of legitimate packages).

Use 'uv pip install' instead (protected by exclude-newer="7 days"
in ~/.config/uv/uv.toml).

To override: ask the user to either install it manually from their
terminal, or prefix the command with QUARANTINE_BYPASS=1.

Safe patterns pass through: pip install -r requirements.txt, npm ci, bare pnpm install (lockfile-only). The hook only applies to agent tool calls; your terminal is unrestricted.

The hook is a bash script wired up in settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/skills/package-quarantine/scripts/quarantine-hook.sh"
          }
        ]
      }
    ]
  }
}

Package managers with native protection (npm, pnpm, bun, uv) don’t need hook enforcement, they already enforce cooldown before resolving.

5-minute setup

If you only use JavaScript and Python:

# npm
echo "min-release-age=7" >> ~/.npmrc

# pnpm (add to pnpm-workspace.yaml)
# minimumReleaseAge: 10080

# bun
mkdir -p ~/.config && cat >> ~/.bunfig.toml << 'EOF'
[install]
minimumReleaseAge = 604800
EOF

# uv (Python)
mkdir -p ~/.config/uv && cat >> ~/.config/uv/uv.toml << 'EOF'
exclude-newer = "7 days"
EOF

Static files. No cron jobs, no shell profile changes. Lockfile workflows (npm ci, pnpm install, bun install with no arguments) still work — they don’t resolve new versions.

The tradeoff

You can’t install a package published today. When you need something new, a security patch, a dependency for a fresh project, you override:

# npm: one-time override
npm install --min-release-age=0 new-package@1.0.0

# uv: one-time override (use current timestamp)
uv pip install --exclude-newer="$(date -u +%Y-%m-%dT%H:%M:%SZ)" new-package

That’s the right default. You make a conscious choice to trust a specific new release. Everything else waits.

Most supply-chain attacks are caught within 24-72 hours. A 7-day window handles everything except long-game attacks where malicious code sits dormant for weeks. Those need different defenses (dependency auditing, SBOMs, provenance verification).

What this doesn’t cover

• Malicious code in packages older than 7 days

• Registry infrastructure compromises

• Git dependencies or direct URL installs

• Typosquats that survive more than 7 days undetected

This is one layer. Pair it with pnpm’s strictDepBuilds and lockfile review. But cooldown gives you the most coveragPe for the least effort.

Axios attack details: StepSecurity, Socket. LiteLLM attack details: Sonatype, Trend Micro.

I haven’t written a single line of code by hand in four months. But I’d still call it my best 6 months ever and I took six weeks of paternity leave in the middle of it.

This didn’t happen overnight. I’ve been coding through AI agents for a couple of years now. I started by writing Cursor rules & Slash commands for our open source Airflow team at Astronomer and sharing them across the engineering org so everyone could use the same patterns.

When Anthropic launched Agent skills in December 2025, I moved to those since they were a clear superset and a standard. I have spent hundreds of hours since then iterating on skills, hooks, CLIs and MCP + integrations building the tooling that lets my agents work the way I would. Four months ago I stopped writing code by hand altogether.

What Actually Shipped

Here's some of what I shipped in last few months, all through AI coding agents:

Apache Airflow Registry: I built an official, community-governed catalog for all of the Airflow integrations. Drove internal feedback, authored the proposal, built the tooling, backfilled 1.5 years of data for all providers. The registry includes versioned APIs exposing every Operator, Hook, and parameter designed for AI agents to consume.

Astronomer Agents repo: open-source agent skills platform for Data Engineers across the world. 30+ PRs: multi-database support across Snowflake, BigQuery, Postgres, and Redshift. An agent-first CLI with direct Airflow REST API access and a MCP server for Airflow. Warehouse schema discovery delivering 3.5x faster queries.

150+ PRs across apache/airflow, airflow-site, Astronomer Agents repo, and various internal repos. Fixed N+1 queries in the scheduler, eliminated eager loading, bulk DELETE for XCom cleanup.

Airflow website modernization: the ancient docsy theme (6 years old!) had no dark mode, broken syntax highlighting, and poor search. I implemented full dark mode, fixed code blocks, added Cmd+K search using Pagefind, updated archived docs. This is the first thing every new Airflow user sees, so this was on my list for some time and I was incredibly happy to finally do it.

AIP-99: making Airflow the first AI-native orchestrator with my friend Pavan. Existing Airflow hooks for GCS, S3, Snowflake, and others become AI agent tools via Pydantic AI. No other production-grade orchestrator has native LLM/agent primitives at this level.

An Impact Analysis Agent that helps ensure breaking changes don’t make it to Airflow releases. This has been critical in our usage at Astronomer, details on this Engineering blog post.

Half of these I wouldn't have even started without agents: not enough hours in the day alongside everything else and especially wouldn’t have spent any time on frontend projects :)

What a Day Actually Looks Like

Here’s a real Friday — March 20, 2026:

• 27 Claude Code sessions across 6 repositories

• Created an incident triage skill from a live P1 customer incident

• Updated my slack skill to do better searches

• Ported a CLI command from Python to Go

• Fixed a registry UI bug — found it, investigated, PR merged same hour

• Reviewed 15 PRs across apache/airflow and internal repos

• Caught a docs PR where a find-and-replace had corrupted 20 files

• Prepared slides for upcoming presentation

• Reviewed and authored Google Docs using workspace skills

• 50+ Slack messages across 12 channels

Not a single line typed into an editor.

I’m not “telling AI to write code.” I’m directing agents across repos, tools, and communication channels. All day.

How It Actually Works

People hear “I don’t write code” and assume I’m prompting Claude or Cursor. That’s not what’s happening.

Skills are the new programming language. A skill is a markdown file that tells an agent what to do, what tools to use, and what patterns to follow. I have skills for PR review, incident triage, meeting notes, daily summaries, and blog writing. Each one encodes my judgment — “review like I would review.” Writing a good skill requires the same thinking as writing good code. The skill IS the code.

My stack:

• Claude Code: I don’t open a code editor anymore. I do use Cursor at times, but only for using Agents, not for writing code.

• Skills: markdown instructions, composable. Contains tons of references & scripts called from main SKILL.md file.

• Hooks: guardrails. Block posts containing AI slop words. Require confirmation before publishing.

• MCP servers & CLIs: GitHub, Slack, Google Calendar, Gmail, Google Docs, Todoist. Agents read and write to real systems.

• Subagents: For things requiring context isolation and/or restricted permissions

• Agent teams: multiple agents working in parallel across different parts of the codebase for larger tasks.

• Personal CRM: an Obsidian vault where agents write meeting notes, daily journals, and cross-link people.

My typical workflow for Airflow as an example now is: I describe a feature, the agent writes it, spins up our dev environment (Breeze), runs the full E2E test suite including UI interactions, and takes screenshots and screen recordings for me to verify or use in a demo.

My agents read my email, search Slack, check my calendar, manage my todos, write meeting notes, generate daily journals, and post PR reviews. People keep asking me how I set this up while safeguarding against any prompt injections. That’s partly why I have been thinking of blogging again after years.

The job hasn’t gotten easier. It’s shifted. Less typing, more thinking. Less execution, more direction.

What’s hard

I could write only the wins. But if I’m going to be honest about this, here’s what’s actually hard.

I prototype faster than I can get buy-in. I can have a working prototype in hours. Getting five stakeholders to agree on scope takes weeks. Agents made that gap worse.

Code review is now the bottleneck. Code generation is nearly free. Review cannot scale the same way. A Google engineer told me he has five features sitting in a queue waiting for review. AI-generated PRs are flooding into Airflow’s open source repo — varying quality, same review cost per line. If I review one line, I own it for the lifecycle of the project. That hasn’t changed.

Agents fail silently. A wrong line of code throws an error. A wrong agent output looks plausible. I’ve caught agents confidently applying the wrong fix, generating tests that pass but test nothing, and making changes that look right until you read the diff carefully. The failure mode isn’t “it broke” — it’s “it looked fine and I almost shipped it.” This is why you should review the code before creating PRs — especially if it is going to be deployed in Production systems! Accountability hasn’t changed. AI is a tool, “you are still responsible for the code you write”.

Breadth vs. depth gets harder. In 4.5 effective months I was context-switching between Airflow 3.1 release management, the provider registry, impact analysis agent, a production incident investigation, dependency firefighting, a hackathon, proposal design, the agents repo, upstream PRs, and various other things. Agents let you touch everything. The discipline is knowing when to stop and go deep instead. This remains a challenge.S

What I’ve Learned

The harness matters more than the model. Models haven’t improved dramatically in the last 3 months at least. The last step change was Claude Opus 4.5. What changed is the tooling around them — skills, context injection, hooks, guardrails. A Google engineer said this in a joint session we did: “Models haven’t improved much. Harnesses are what changed.” If you’re investing in AI coding, invest in the harness.

Skills are composable. A review skill can call a search skill can call a Slack skill. This is the new “functions calling functions.” Your workflow IS your IP. The patterns encoded in your skills are very valuable. I fork every skill I write and every skill I use. I also use ton of reference file and almost always have hooks & scripts where deterministic output is needed.

Route by complexity, review across models. Agents overcomplicate architecture if you let a heavy model loose on a simple task. Haiku for expense tracking and simple reminders, Sonnet for everyday coding, Opus for deep architectural work. I also get better results by reviewing with a different model than the one that wrote the code — write with Claude, review with GPT, or vice versa.

Turn incidents into lasting defenses. A production incident took 3 days to diagnose and led to a 15,000x query speedup fix. Instead of closing the ticket and moving on, I added the failure pattern to an Impact Analysis agent’s knowledge base. The system now catches that class of issue automatically. Every incident should leave behind an agent that prevents the next one.

What “Learn to Code” Means Now

I’m not saying it’s dead. I’m saying it means something different than it did two years ago:

• Learn to write clear instructions. That’s what skills are.

• Learn to set guardrails. That’s what hooks are.

• Learn to review code you didn’t write. This was always important. Now it’s the whole job.

• Learn to debug agent failures. This is a new skill entirely.

• Learn to say “that’s wrong” to confident-sounding output.

The engineers who thrive will be the ones who can direct agents with the same precision they once applied to writing code. The ones who struggle will be the ones waiting for someone to tell them what to type.

I still call myself an engineer. I just don’t type the code anymore.

Next up: I’ll open-source some of the skill files I use daily and share how I use OpenClaw to run AI agents for my family & my personal use on WhatsApp. Subscribe if you want to see what this looks like from the inside.