What Your AI Coding Tool Can (and Can’t) Do For You - March 2026, Claude and GH Copilot Edition

There’s a distinction that doesn’t get made often enough, and it’s costing teams time, money, and a slow erosion of trust in their tools.

Engineering agents is the discipline of building AI agents — writing the code, designing the architecture, hooking up the tools, deciding what an agent can and cannot do. It’s what this blog mostly lives in. Embabel, MCP servers, tool definitions, memory strategies, bounded autonomy. Code over promises.

Engineering with agents is different. It’s the discipline of working alongside AI agents as a software engineer — using them as collaborators in your daily development practice. Writing better prompts. Verifying AI output. Building the harness of constraints that stops an agent doing something expensive and irreversible at 3am. Progressing from “I use Copilot for autocomplete” to “I have a multi-agent pipeline that writes, reviews, tests, and integrates code while I sleep.”

Both disciplines matter. But they require different skills, different tools, and — critically — different mental models.

If you show up to engineering with agents using only the skills of someone who has never thought seriously about what an agent is, you’ll get autocomplete with delusions of grandeur. And if you try to engineer agents without understanding how to collaborate with them day-to-day, you’ll build systems that nobody — including you — trusts to run.

This article is squarely about the second discipline: engineering with agents, and what the tools you already use can actually do to support your progression.

What follows is a capability assessment mapped across six levels of AI collaboration literacy — from “I know AI exists” to “I run autonomous agent teams across my organisation.” The two tools under the microscope are Claude Code (Anthropic’s terminal-native agentic coding assistant) and GitHub Copilot (the full suite: inline suggestions, agent mode, coding agent, CLI).

Where relevant, we describe what any AI coding tool would need to support at each level; a generic requirement that’s useful both for practitioners evaluating future tools and for vendors looking honestly at their roadmap.

This assessment reflects the capability landscape as of March 2026. Both tools ship frequently; gaps marked here may close.

At the base level, the requirement is simply a working interface and enough transparency to know what model you’re talking to. Both tools clear this bar. Claude Code gives you /model to see the current model and /cost to track your spend; Copilot shows the model in VS Code, though its CLI is less forthcoming. No meaningful gaps here.

The more important observation is that Level 0 is primarily a mindset, not a tool capability. The question is whether you’ve started asking why the AI said what it said — not just whether you liked the output.

Level 1 is where practitioners start to develop deliberate habits: translating intent into prompts, curating context consciously, and developing an awareness of what the context window costs.

Both tools support natural language interaction well — Claude Code via the terminal with multi-turn conversation, Copilot via the chat panel, inline suggestions, and agent mode. That part is table stakes.

The gap that matters is context engineering. Claude Code supports a layered context system: CLAUDE.md files at the global, project, and directory levels, supplemented by skills and AGENTS.md. This means you can encode context that is always true, context that is true for this repository, and context that is true for this corner of the codebase — and the agent reads the right layers automatically.

Copilot offers a single .github/copilot-instructions.md file at the project level. It works. But a single flat file versus a layered, composable system is the difference between “I told the AI what I want once” and “the AI always knows where it is and what matters here.” One is a hope. The other is an architecture.

Cost and token visibility tell a similar story. Claude Code’s /cost command and Analytics API give you per-session visibility. Copilot’s usage metrics live at the org level in an admin dashboard — useful for governance, but not for the individual practitioner developing the habit of token consciousness.

Level 2 is about trust — specifically, building the automated infrastructure that lets you verify AI output systematically rather than eyeballing it.

Code execution is supported by both tools. Claude Code’s Bash tool runs any command; Copilot’s agent mode runs terminal commands in VS Code. That’s the easy part.

The important gap is lifecycle hooks. Claude Code supports PreToolUse, PostToolUse, and FileChanged hooks with allow, deny, and ask control flow. This means you can intercept what the agent is about to do before it does it — warn, block, or prompt for confirmation based on what tool is being called or what file is being touched. Copilot has no equivalent. Its workaround is GitHub Actions, which enforces checks at PR time. That’s not nothing — PR gates are real gates — but they fire after the agent has already acted, not during.

Code review is one area where Copilot has a genuine native strength: @copilot as a PR reviewer on GitHub is turnkey and fits naturally into the workflows most teams already use. Claude Code’s review capability is built through a custom code-reviewer agent, which is more powerful but requires more setup.

Permission control is more nuanced with Claude Code — fine-grained allow/deny lists per tool, path patterns, and domain restrictions. Copilot’s .copilotignore handles content exclusions but doesn’t reach to per-tool permission control.

Level 3 is where you stop using an AI tool and start building a development environment that includes AI as a first-class component. This is the level where the gap between the two tools becomes significant.

The core concept here is the harness: a set of living documents and enforcement mechanisms that declare what the AI can and cannot do, what it knows about your project, and how it should behave across sessions. Claude Code supports this through HARNESS.md combined with hooks and CI integration — PreToolUse hooks warn during development, CI blocks at the pipeline. There is no equivalent concept in Copilot. Its closest analogue is .github/copilot-instructions.md serving as advisory context, with GitHub Actions as the enforcement mechanism downstream.

Custom agent definitions are another substantial gap. Claude Code lets you define specialised agents in .claude/agents/*.md with YAML frontmatter specifying per-agent tool lists and model selection. A spec-writing agent gets different tools and a different model than a code-review agent. Copilot has no equivalent — agents are differentiated through prompt engineering within a single chat interface.

Parallel agent isolation, where multiple agents work safely on different branches of a codebase simultaneously, is built into Claude Code through git worktrees — the --worktree flag and isolation: worktree in agent definitions handle this automatically. In Copilot, you’d manage separate worktrees manually and run separate chat sessions yourself.

Model routing — the ability to choose the right model tier for the right task — is supported in Claude Code through the model: field in agent definitions and the MODEL_ROUTING.md pattern. Copilot uses a single model per session, with no routing mechanism inside the tool.

Compound learning is the last significant gap at this level. Claude Code supports AGENTS.md for curated project knowledge, REFLECTION_LOG.md for agent-proposed learning, and auto-memory — mechanisms for accumulating what the agent has learned about your project across sessions. Copilot has no cross-session learning mechanism. When the session ends, it forgets.

MCP tool extension is partially supported by both tools, but differently. Claude Code integrates MCP servers via .mcp.json with autonomous tool discovery; Copilot’s Extensions provide tool access, but they’re chat-invoked rather than available to the agent autonomously.

At Level 4, specifications become the source of truth and the agent pipeline is a first-class engineering artifact — with safety gates, orchestration, and programmatic access.

Multi-agent orchestration is fully supported in Claude Code: an orchestrator dispatches a spec-writer, then a TDD agent, then implementers, then a code reviewer, then an integration agent, each with scoped tools and bounded responsibility. Copilot has no equivalent; individual coding agent tasks can be assigned, but there is no pipeline definition or dependency management between multiple agent roles.

Safety gates are similarly absent from Copilot’s current architecture. Claude Code supports plan approval gates — the orchestrator pauses for human review before proceeding — and MAX_REVIEW_CYCLES as a guardrail against runaway loops. Copilot’s workaround is branch protection rules at merge time, which is a gate, but not a gate inside the autonomous workflow.

Async cloud execution is an area of genuine parity. Claude Code supports headless mode and the Agent SDK; Copilot’s Coding Agent handles the “assign an issue, get a PR” workflow natively, and for teams already living in GitHub this is a meaningful capability that maps naturally onto existing practice.

Programmatic integration tells a more differentiated story. Claude Code offers a headless CLI (claude -p), a Python SDK, and a TypeScript SDK — the full agent loop is accessible programmatically. Copilot’s CLI handles command suggestions, but there’s no SDK that exposes the full agentic workflow to external scripts or CI pipelines.

Scheduled autonomous tasks are supported in Claude Code via the /schedule command and desktop and cloud task scheduling. Copilot has no equivalent; the workaround is GitHub Actions on a cron schedule, which executes workflow steps but doesn’t invoke the agent directly.

At Level 5, AI collaboration becomes an engineering discipline with the same governance requirements as any other platform capability — telemetry, standards, distribution, audit.

OpenTelemetry export is a clean differentiator here. Claude Code’s native OTel export integrates with Grafana, Datadog, and Honeycomb, correlating AI telemetry with the rest of your observability stack. Copilot has no OTel export; the Copilot Metrics API provides org-level analytics on acceptance rates, active users, and language breakdown, which is useful for adoption tracking but disconnected from infrastructure observability.

Usage analytics are reasonably strong in both tools. Claude Code provides daily aggregates with per-user token usage and cost estimates via the Analytics API. Copilot’s Metrics API covers adoption signals. Claude Code is more granular on cost; Copilot is more naturally surfaced for GitHub-native org reporting.

Agent team coordination — multiple agent sessions sharing state, communicating, and managing dependencies — is in experimental support in Claude Code through Agent Teams (team lead, teammates, shared task list, peer messaging). Copilot has no multi-session coordination mechanism.

Reusable harness templates — the ability to package and distribute organisational AI standards as installable artifacts — are supported in Claude Code through its plugin system, which bundles skills, agents, hooks, and templates together. Copilot’s workaround is GitHub template repos containing .github/copilot-instructions.md, which gets you the instructions file but none of the enforcement, hooks, or agent definitions.

Both tools serve Levels 0 to 2 well. If you’re in the early stages of building an AI collaboration practice, either tool will get you started. Copilot’s deep GitHub integration — PR review, coding agent, metrics — is a genuine strength for teams whose world is already organised around GitHub. The async coding agent in particular is worth taking seriously: assign an issue, get a PR, stay in your existing workflow.

Claude Code’s strength is its agentic infrastructure: hooks, custom agents, plugins, orchestration, OTel. The higher levels — L3 through L5 — require capabilities that are currently unique to Claude Code’s architecture.

It’s important to point out that these are capabilities, not permanent advantages. Any tool that adds persistent layered context files, programmable lifecycle hooks, custom agent definitions, and standard telemetry export can serve this full progression. The vendors are watching the same curve the practitioners are.

This is a capability assessment, not a product ranking. The framework’s levels are tool-agnostic; the capabilities required at each level are not.

The most important level in this assessment isn’t the one where your current tool excels. It’s the one where it has gaps — because that’s where your progression will hit a ceiling. Whether that ceiling requires workarounds, tool evolution, or a tool change, you want to know about it before you arrive at it.

Plan for it before you reach it.

Don’t agree with the assessment here, please reach out! I’m always keen to hear from the lived experience of software engineers pushing the limits of these tools, so please feel free to reach out to me here or on LinkedIn.

Russ Miles is a software engineering thought leader, keynote speaker, and the Festival Director of Eastbourne LitFest. Engineering Agents is his hands-on practitioner blog: code over promises, always.

Found this useful? Hit the subscribe button — and if you’re building something interesting in the agent space, get in touch. This blog actively wants more voices in it.