Hello!

The coding agent series has finally reached its finale!

As 2026 unfolds, Claude Code, Cursor 3, and GitHub Copilot Coding Agent have all evolved beyond simple code completion or chat-style assistance into development workflows built on multiple agents. In this article we survey the latest developments in AI coding agents, covering Claude Code's Auto Memory and Subagents, Cursor 3's Agents Window, GitHub Copilot's Coding Agent, and how to read SWE-bench results.

In Part 1, we surveyed the sprawling landscape of AI coding agents as of December 2025, organizing more than 20 tools — commercial and open source alike — into four categories: CLI-based, IDE-integrated, AI-native IDE, and autonomous.

In Part 2, we compared Claude Code, Codex CLI, and Aider in depth, and distilled the structural challenges shared by today's coding agents — context window limits, memory loss between sessions, and the gap between benchmarks and the real world — into what we called Claude Code's "four structural problems."

And at the end of Part 2, we promised that the finale would cover Microsoft's Amplifier and take a close look at its approach to solving these challenges.

Well... about that.

Introduction: This Is Not the Article We Promised

Let us be honest with you.

In just the few months since Part 2 was written, the landscape around coding agents has changed completely.

The challenges we framed in Part 2 as "Claude Code's four structural problems" are, thanks to Claude Code's own evolution, being addressed at a rapid pace.

We did not see this coming.

A story that was supposed to be about an "external solution" called Amplifier has instead been overtaken by Anthropic tackling the problems from the inside. And in just a few months, at that.

So this article departs substantially from the original plan, and is organized as follows.

• First, we look at how the four challenges raised in Part 2 are being addressed
• Next, we survey how competitors like Cursor and GitHub Copilot have evolved
• Then, we reassess where Amplifier stands today
• Finally, we revisit how to read benchmarks, and consider the reality that the developer's role is changing

To readers who were looking forward to what Part 2 promised, we apologize — but we concluded that as of May 2026, what really matters is not "how Amplifier solves these challenges" but the fact that the industry as a whole is entering its next stage.

With that, let's dive in!

Series Overview (Recap)

3-1. How Claude Code Is Addressing the Challenges from Part 2

Let's revisit the "four structural problems" we outlined in Part 2.

Let's take them one at a time.

3-1-1. Addressing Memory Loss: Auto Memory

In Part 2, we described Claude Code's memory-loss problem as "an engineer who forgets everything from yesterday, every single day."

One of Anthropic's answers to this is Auto Memory (v2.1.59 and later).

The official documentation explains that Auto Memory is a feature that has Claude Code automatically "take notes" while it works. Debugging patterns, build commands, architectural decisions, user preferences — this kind of information accumulates in a per-project auto memory directory.MEMORY.md serves as its index, and at session start the first 200 lines or 25KB are loaded.

Note that auto memory is machine-local, and is designed to be shared across worktrees and subdirectories within the same Git repository.

GitHub issues and community reports also describe an experimental behavior (sometimes called Auto Dream) that automatically organizes and consolidates accumulated memory. Since the official documentation does not treat this as a stable feature, we will refrain from going into detail here.

The takeaway: Against the "CLAUDE.md is manually maintained" dilemma we pointed out in Part 2, machinery for accumulating memory automatically is taking shape. We would not go as far as "memory loss is fully solved," but it is clear that features aimed at persistent memory are maturing rapidly.

3-1-2. Addressing Context Overflow: Summarization and Compaction

In Part 2, we wrote that the 200K-token limit is reached after roughly 50 tool uses.

In response, Claude Code now has summarization and compaction machinery in place.

The official documentation notes that for Skills in particular, recent skill invocations are re-attached within certain bounds even after compaction. Each skill is retained with a budget of its first 5,000 tokens, up to 25,000 tokens in total.

There is also the /compact command, which lets you run compaction whenever you choose.

The takeaway: The internal compaction pipeline is not officially spelled out in detail, but it is clear that machinery for compressing context while retaining important information is falling into place. The "limit after roughly 50 uses" situation described in Part 2 is heading in the right direction.

3-1-3. Addressing the Single-Agent Problem: Subagents

In Part 2, we described the single-agent problem as "one agent doing everything, from design to debugging."

Claude Code's answer here is a feature called Subagents.

The official documentation describes Subagents as a mechanism for invoking specialized agents that run independently of the main Claude Code session. Each has its own context window and can focus on a specific task without polluting the main session's context.

In practice, you write agent definitions in Markdown inside the .claude/agents/ directory. For example:

• code-reviewer.md: a subagent dedicated to code review
• test-writer.md: a subagent specialized in generating test code
• db-migrator.md: a database migration specialist

The main Claude Code session looks at the nature of the task, invokes the appropriate subagent, and receives only the results.

On top of that, an experimental feature called Agent Teams has appeared (enabled via the CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 environment variable). This is a more ambitious mechanism in which multiple subagents cooperate as a team.

That said, Agent Teams is officially positioned as experimental, and it is disabled by default. Given known limitations around session resumption, task coordination, and shutdown handling, the realistic starting point today is research and evaluation rather than wiring it unconditionally into a production development flow.

3-1-4. Addressing Single-Track Trial and Error: Worktrees Integration

In Part 2, we pointed out that there was no way to explore approaches in parallel.

Claude Code's answer here is Git Worktrees integration.

Claude Code documents a workflow that uses Git worktrees to split work across multiple branches. Because subagents can work in their own independent worktrees, you can try multiple approaches in parallel without conflicts.

This answers the need we hinted at in Part 2: trying multiple solutions to the same problem side by side.

3-1-5. Summary: Not "Solved," but Actively Being Addressed

As we have seen, the challenges raised in Part 2 have not vanished entirely.

But with Auto Memory, Subagents, Worktrees, Skills, and Agent Teams landing in Claude Code itself, it is a fact that **many of the challenges that once could only be patched with external tools are now being addressed from inside the product**.

3-1-6. Other Notable Additions (for Reference)

While we are at it, here are the main features Claude Code has added since the start of 2026.

• Plugins / Skills / Hooks: a major boost to extensibility
• MCP integration: connections to external tools (Model Context Protocol)
• Custom Themes: customizable via the /theme command
• Vim Mode: v/V for visual mode
• VS Code extension (beta): January 2026, native integration
• Push Notifications: mobile notifications via Remote Control

Compared with the "minimal, terminal-only CLI" image Claude Code had around Part 2, it has gained so much functionality that it is practically a different product.

3-2. The Competition Isn't Standing Still: Cursor 3 and GitHub Copilot

Claude Code was not the only one evolving.

Cursor and GitHub Copilot, both touched on in Part 2, have gone through major transformations of their own over these past few months.

3-2-1. Cursor 3: Toward an Agent-Centric Interface

On April 2, 2026, Cursor released Cursor 3.

The official blog post carried a rather provocative message from CEO Michael Truell to accompany the release.

We are entering the third era of software development. The first era was editing files by hand. The second era was working in pairs with AI agents. And the third era is one in which autonomously operating fleets of agents continuously ship improvements.

In Cursor 3, the interface for operating this "fleet" — the "Agents Window" — takes center stage.

Key officially documented features:

• Agents Window: an agent-centric interface
• Local / Cloud Agents: run agents both locally and in the cloud
• Composer 2: Cursor's own frontier coding model
• Integrated browser: preview work in progress inside the editor
• Marketplace Plugins: extensibility through plugins

Cursor 3's message is a shift from "pair programming" to "orchestrating a small engineering team."

The "Cursor = AI-native IDE" category we used in Part 2 is already becoming an outdated lens. Cursor is now aiming to be a workspace for operating fleets of agents.

3-2-2. GitHub Copilot: From Coding Agent to Cloud Agent

GitHub Copilot, too, is no longer a "code completion tool."

Copilot's evolution in chronological order:

• September 2025: Coding Agent reaches GA (assign it a GitHub issue and Copilot autonomously analyzes, implements, and opens a PR)
• January 2026: Copilot Memory (agentic memory) enters public preview (automatically infers and stores useful information about the repository)
• 2026: Agent Skills, Custom Agents, multi-model support (GPT, Claude, Gemini)

Of particular note is Coding Agent (now also called Cloud Agent).

Assign Copilot to an issue on GitHub, and it executes the following fully asynchronously:

1. Analyzes the issue and the repository context
2. Drafts an implementation plan
3. Makes code changes on a separate branch
4. Runs the tests
5. Opens a PR with a summary attached

The developer simply assigns the issue and comes back later to review the PR. The world of "autonomous agents" we hinted at in Part 2 is already being woven into the development workflow on GitHub.

3-2-3. In Short, the Whole Industry Is Moving

Line up the moves by Anthropic, Cursor, and GitHub, and the direction of travel is quite clear.

They are all looking in much the same direction: rather than pushing a single agent harder, give agents memory, divide the roles, run them in parallel, and have a human review at the end. The major tools are converging on this shape all at once.

The OSS ecosystem is following suit: OpenHands, Cline, Aider, and others are each implementing parallel execution, specialized agents, and persistent memory in their own ways.OpenHands has passed 72,000 stars, making it one of the most closely watched OSS coding agents.

3-3. So, What Was Amplifier After All?

Which brings us back to the research project published on Microsoft's GitHub, Amplifier, which this series had planned to feature.

Frankly, as of this writing, Amplifier's position has become rather awkward.

3-3-1. Amplifier's Original Appeal

Amplifier was originally attractive for its positioning: complementing Claude Code's structural weaknesses from the outside.

• A roster of specialized agents
• A knowledge-graph-style approach to persistent memory
• A microkernel design (with a swappable orchestrator)

These were exactly the kind of answers the four challenges from Part 2 called for.

3-3-2. But the Commercial Tools Caught Up

As we have seen, however, most of the solutions Amplifier proposed have begun shipping as core features of the commercial tools — Claude Code, Cursor, and GitHub Copilot.

• Specialized agents → Claude Code Subagents, Copilot Custom Agents
• Persistent memory → Auto Memory, Copilot Memory
• Parallel execution → Worktrees integration, Copilot Coding Agent
• Extensibility → Plugins / Skills / Hooks, MCP integration

With the commercial tools having advanced this far, it is getting hard to find things that only Amplifier can do.

3-3-3. What Amplifier's Own Developer Says

In fact, Amplifier's developer, Brian Krabach, said as much from the very beginning.

Krabach's Medium article puts it this way

"This is not a launch post for Microsoft release." "research-stage development environment" "Claude today, something else tomorrow. The value is the knowledge, patterns, and automation — not any specific model."

In other words, Amplifier was positioned from the start as "a research framework independent of any specific model or tool".

The fair reading of the current situation is that the commercial tools simply evolved too fast, and as a result Amplifier's "research framework" character has come to the fore.

3-3-4. Where Amplifier Still Makes Sense

Does that mean Amplifier no longer has value? Not necessarily. It remains an option worth considering in cases like these.

That said, community reception has not been uniformly positive. "Good ideas, but still research-stage for practical use" is probably the assessment closest to reality.

3-3-5. Amplifier's Real Role

Even so, we believe Amplifier has an important role to play.

Namely, the role of "a research platform that tries out ideas before the commercial tools adopt them".

Indeed, many of the concepts Amplifier proposed — combinations of specialized agents, approaches to persistent memory, microkernel design — have been absorbed into commercial tools in one form or another. You could say this OSS research project has played a healthy role in signaling where the industry was headed.

In other words, Amplifier is not "a Claude Code alternative" — the framing that fits best may be "a proving ground that signals where Claude Code is headed next".

3-4. How to Read Benchmarks (Revisited)

In Part 2, we noted that models scoring above 70% on the traditional SWE-bench Verified drop to around 23% on SWE-bench Pro.

As of May 2026, this issue remains just as important.

3-4-1. Key Benchmark Numbers as of May 2026

Here are the figures we could confirm from official sources.

Claude Opus 4.7's 87.6% on SWE-bench Verified is a very high number. Taken at face value, it suggests there is hardly a practical problem left.

3-4-2. But the Memorization Concern Remains

However, SWE-bench-style evaluations carry known memorization / contamination concerns.

Anthropic's Project Glasswing announcement and OpenAI's GPT-5.5 announcement both flag this point when presenting evaluation results.

Indeed, on the stricter benchmark (SWE-bench Pro), scores drop substantially:

• Claude Mythos Preview: Verified 93.9% → Pro 77.8%
• Claude Opus 4.7: Verified 87.6% → Pro 64.3%
• GPT-5.5: Pro 58.6%

Real-world work also adds constraints that public OSS benchmarks do not have, so equivalent performance on private commercial codebases is not guaranteed.

In short, public benchmark numbers are useful reference points, but they do not guarantee performance on your own codebase.

3-4-3. What to Trust

Benchmark numbers can inform tool selection, but there is no way to know true performance other than measuring on your own codebase, with your own tasks.

Practical advice comes down to something like this:

• Treat benchmarks as an upper bound (real environments will score lower)
• Actually trial several tools on 3–5 of your own representative tasks
• Evaluate not just the success rate but the failure behavior (does it run away, or stop gracefully?)
• Check against your security and data-handling requirements

Even as benchmark scores climb, "usable or not in practice" remains a separate question — that has not fundamentally changed since Parts 1 and 2 back in December 2025.

3-5. The Developer's Role Is Already Changing

Putting all of this together, one large structural shift comes into view.

It is that the developer's role is shifting from "coder" to "agent orchestrator".

3-5-1. From Writing Code to Commanding Agents

Cursor 3's "fleets of agents," GitHub Copilot's Coding Agent, Claude Code's Subagents + Worktrees — what they share is a move toward a way of working where humans run multiple agents in parallel, then review and integrate the results.

For some developers, running several agents at once is already becoming an everyday reality.

3-5-2. What This Means

This shift carries several implications.

First, task decomposition skills matter more than ever.

To run agents in parallel, you must break tasks down into units that can execute in parallel. This is work that tests design, decomposition, and integration skills more than the ability to write the implementation itself.

Second, the review burden has grown.

Compared with human-written code, agent-written code is more often "plausible at a glance, but subtly off." If five PRs arrive in parallel, you have five PRs' worth of reviewing to do.

Third, your sense of cost changes.

Cursor 3's Cloud Agent, GitHub Copilot's Coding Agent, Claude Code's Subagents — all of these cost more as parallelism increases. Buying speed with money is becoming an everyday choice on development teams.

3-5-3. What Still Hasn't Changed

At the same time, what does not change has also come into focus.

• Benchmark numbers and real-world usability are separate questions
• You cannot select a tool without measuring on your own codebase
• Running agents unsupervised remains high-risk
• Security and privacy requirements remain preconditions for tool selection

However far the tools evolve, deciding what to build is still a human's job. So, ultimately, is judging whether the code an agent wrote is correct.

"Less time writing code, more time thinking" — as of May 2026, that is probably the shared experience of most developers working with AI coding agents.

Part 3 Summary

This article changed course from the originally planned Amplifier deep-dive to a survey of the coding-agent industry as of May 2026.

Key points

• Against the "four structural problems of Claude Code" raised in Part 2, Claude Code's own evolution (Auto Memory, Subagents, Worktrees integration) means responses are well underway
• Cursor 3 champions "fleets of agents," GitHub Copilot took Coding Agent to GA in 2025, and the industry as a whole is entering the era of agent orchestration
• Amplifier is best positioned not as "a Claude Code alternative" but as "a research platform that prefigures where the commercial tools are headed" — that is the realistic framing
• SWE-bench-style benchmarks carry memorization concerns, so measuring on your own codebase is essential
• The developer's role is shifting from "coder" to "agent orchestrator"

Looking Back on the Series

That brings our three-part series to a close. We hope you enjoyed it.

At the time of Part 1 (December 2025), the situation was "more than 20 tools, and no idea which to choose."

In Part 2 (January 2026), we mapped the essential limits of the tools and brought the structural challenges into relief.

And in Part 3 (May 2026), we confirmed that responses to those challenges are arriving far faster than we imagined, and that the whole industry is moving into its next stage.

When we wrote Part 1, we never expected the landscape of this field to change this much in just five months.

In all likelihood, the "latest developments" of May 2026 described here will themselves be stale within six months. That is how fast this field moves.

Still, the essential points that emerged over these three articles are unlikely to change any time soon.

• Deciding what to build is still up to humans
• Evaluating the code agents write is still up to humans
• Your own measurements are more trustworthy than benchmark numbers
• Tools will keep multiplying, but the essential selection criteria — your code, your requirements, your operations — stay the same

Now that we find ourselves in command of fleets of agents, deciding what to command feels like a more important part of the developer's job than ever before.

Considering AI Coding Agents for Your Organization?

When adopting coding agents in an enterprise, the question is not simply "which tool is smartest." You need to evaluate success rates on your own codebase, review burden, security requirements, permission design, usage costs, and how to stop things when they go wrong.

Drawing on hands-on experience with AI agents and LLMs, Qualiteg supports everything from tool selection and PoC design to integration into internal development processes and operational guidelines.

For consultations and inquiries, please reach out here.

Thank you for staying with us through all three parts!
See you next time!