For the past couple of years, AI coding tools have been competing over one thing: who can write the most code.
We've gone from basic autocomplete to generating entire applications from a handful of prompts. Every new release seems to promise faster development, larger codebases, and less human intervention.
And while that's impressive, I think we've reached a point where generating code is no longer the biggest challenge.
The bigger question is whether we can actually trust what these tools produce.
Recently, GitHub, Microsoft, and Cursor have introduced new tools that seem to acknowledge this problem. Instead of focusing exclusively on code generation, they're putting more emphasis on agent coordination, code review, automated testing, and permissions.
It's an interesting shift, particularly for developers who are responsible for maintaining the software long after the AI has finished writing it.
Here's what's changing.
GitHub Wants Copilot to Manage and Review AI Development
GitHub recently announced a major expansion of Copilot, including a redesigned desktop application and a new feature called Copilot Projects.
The concept behind Projects is straightforward.
Instead of assigning individual coding tasks to one agent, developers can give Copilot a larger objective and let multiple agents coordinate the work.
Projects can span multiple repositories and incorporate additional context from things like design mockups, Slack conversations, and meeting notes.
GitHub describes it as a way to organize agents, context, and results in one place. Copilot handles the coordination and returns work, including pull requests, for developers to review.
Copilot Projects is currently in public preview.
I can see the appeal here.
As someone who spends a fair amount of time managing software projects, I know that writing the code is often the easy part. Understanding requirements, coordinating dependencies, and making sure changes don't break other parts of the application can take considerably more effort.
But introducing more agents into a project doesn't automatically eliminate those challenges.
In fact, it could make them worse if the agents aren't properly coordinated.
That's why I found GitHub's improvements to code review more interesting than the project management features.
Multiple AI Agents Reviewing the Same Pull Request
GitHub introduced a new Max review level for Copilot code review.
Instead of relying on a single model to review a pull request, Max uses several independent review agents running models from different providers.
Their findings are then consolidated by another agent, which attempts to resolve disagreements and verify the results before producing a final review.
It's essentially an automated review team.
GitHub also made Copilot approvals generally available. When enabled, Copilot can approve pull requests, and those approvals can count toward a repository's required approvals.
That's a significant amount of responsibility to hand over to an AI system.
I like the idea of multiple models reviewing the same code. Different models may catch different issues, and that's potentially useful for complicated changes.
But multiple AI agents agreeing with one another doesn't necessarily mean they're correct.
If the underlying assumptions are wrong, several agents could easily arrive at the same incorrect conclusion.
Permissions Are Becoming Just as Important
GitHub also introduced assisted permissions for Copilot, now generally available in Copilot CLI, the desktop app, and VS Code.
When Copilot wants to execute a command, access a file path, or open a URL, another model evaluates the request.
Requests classified as clearly safe can proceed automatically. Others still require developer approval.
Enterprise administrators can also configure which permission modes developers are allowed to use.
This might sound less exciting than running ten coding agents at once, but from a CTO perspective, these are the kinds of features I want to see.
Giving an AI agent access to your development environment shouldn't mean giving it permission to do whatever it wants.
And if we're going to automate more of the software development process, we need better control over what agents can access and execute.
That doesn't guarantee secure behavior, but it's certainly a step in the right direction.
Microsoft's Scope Takes a Different Approach to Agent Testing
Microsoft recently open-sourced Scope, an evaluation platform designed to measure how well AI coding agents interact with software.
What's interesting here is that Microsoft isn't necessarily trying to determine which AI model writes the best code.
Instead, Scope approaches the problem from another angle.
What happens when AI agents become users of our software?
Think about it.
AI agents increasingly interact with APIs, SDKs, command-line tools, and documentation in much the same way human developers do.
But just because an API is easy for a human developer to understand doesn't mean an AI agent will use it correctly.
An agent might choose the wrong endpoint, misunderstand documentation, or fail to properly handle an error response.
And we might incorrectly attribute those failures to the AI model rather than the software or documentation itself.
Scope attempts to make those problems measurable.
Developers can define representative tasks, configure agents to perform them, and evaluate the results against specific success criteria.
It supports repeatable experiments so teams can modify documentation, tools, or integrations and see whether those changes improve agent performance.
The platform works with existing coding agents, including GitHub Copilot and Claude Code.
You can explore the Scope documentation and evaluation framework here.
I actually like this approach quite a bit.
We've spent decades improving developer experience. Better documentation, predictable APIs, and useful error messages all make developers more productive.
Now we're beginning to see a similar concern emerge for AI agents.
Microsoft calls this Developer Agent Experience, or DevAx.
The distinction worth making is that Scope isn't necessarily a traditional code review tool. It's primarily concerned with evaluating whether agents can successfully accomplish defined tasks using your software.
But I think the broader lesson applies to AI development in general.
If we want to trust an agent's output, we need a reliable way to measure what successful behavior looks like.
And that starts with defining success before the agent begins working.
Cursor Is Moving AI Agents Outside the Editor
Cursor is approaching the problem from yet another direction.
The company recently released its Agent SDK, which allows developers to create and deploy custom AI agents that operate outside the traditional code editor.
These agents can respond to events such as pull requests, CI pipeline activity, Slack messages, webhooks, and scheduled tasks.
Essentially, Cursor is making it possible to integrate AI agents directly into a team's development workflows.
For example, a company could create an agent that automatically reviews incoming pull requests against internal engineering guidelines.
Or an agent that examines failed CI runs and helps investigate what went wrong.
Cursor even describes an internal example where an agent checks pull requests against a knowledge base of lessons learned from previous development work.
That's a pretty practical use case.
One of the challenges with AI-assisted development is that the agent often lacks the institutional knowledge that experienced developers accumulate over time.
Things like why a particular architectural decision was made, which dependencies have caused problems in the past, or why a certain implementation pattern should be avoided.
Having a system that can check changes against those decisions could be useful.
The Agent SDK also includes evaluation and event-replay tools, allowing developers to test how their agents respond to specific events before deploying them.
But there's a trade-off.
Once you move agents outside the editor and allow them to operate automatically, you're essentially adding another piece of infrastructure to your development process.
Now you need to think about logging, permissions, failure handling, and monitoring.
You also need to consider what happens when an agent makes the wrong decision.
It's one thing for an AI assistant to suggest a questionable code change while you're sitting in front of the editor.
It's another thing for an automated agent to make that decision as part of a larger workflow.
And that's where I think developers need to be particularly careful.
My Take: More AI Doesn't Automatically Mean More Trust
I think these announcements represent an important change in how the industry is approaching AI-assisted development.
For a while, the conversation seemed almost entirely focused on how quickly an AI agent could build something.
Generate an application in five minutes. Build a SaaS product over the weekend. Replace an entire development team with a collection of agents.
We've all seen the demos.
And some of them are genuinely impressive.
But I recently reviewed a fully vibe-coded application, and that experience reinforced something I've been thinking about for a while.
Generating an application and engineering reliable software are two very different things.
An AI agent can produce thousands of lines of code, and the application might even appear to work perfectly.
But that doesn't tell you much about its maintainability, security, performance, or ability to handle unexpected behavior.
Those problems don't disappear just because the code was generated quickly or by a "better" model.
And the more code these tools produce, the more difficult it becomes for developers to properly evaluate everything.
That's why I find the current shift toward verification interesting.
GitHub is investing in multi-agent reviews and permission controls. Microsoft is building tools to evaluate agent behavior. Cursor is making agents part of automated workflows, with testing and evaluation built into the development process.
Each tackles a different part of the problem.
But I don't think any of them completely solve the underlying issue just yet.
Who Reviews the Reviewer?
There's a fundamental problem with using AI to verify AI-generated code.
At some point, we're relying on another probabilistic system to tell us whether the first probabilistic system did its job correctly.
That might improve our chances of catching errors, particularly when independent models approach a problem differently.
But it's not the same thing as proving correctness.
A code review can miss a bug. An automated test can pass while overlooking an important edge case. An agent can complete a task successfully while making architectural decisions that cause problems later.
None of these limitations are unique to AI.
Human developers make the same mistakes.
The difference is that AI can generate questionable code at a much greater rate, often without the same level of understanding or accountability.
And I think that's the real challenge facing engineering teams.
It's not enough to generate code faster these days.
We need to improve our ability to evaluate it at roughly the same pace.
That means better automated tests, clearer requirements, more effective code review, sensible permission boundaries, and better visibility into what agents are actually doing.
It also means knowing when a human developer needs to step in.
I don't think every pull request needs to be manually inspected line by line forever.
But I also don't think we should assume that adding another AI reviewer makes a change production-ready.
Especially when dealing with authentication, payments, user data, or other critical systems.