At Kubecon Europe recently, Linux kernel maintainer Greg Kroah-Hartman said something that surprised me. After more than a year of AI-based pull requests and security reports that were worthless, living up to their nickname of “slop,” suddenly in the last month or so Kroah-Hartman discovered that those reports had become useful. At the time he didn’t know why, but guessed it was the result of improved tools and a deeper understanding of how to use them.

Since then, of course, we’ve learned about Anthropic’s Claude Mythos and seen the resulting scramble across closed-source and open-source projects to patch the significant bugs and issues Mythos has unveiled. The fixes and updates needed by large projects can be managed by their equally large teams, with corporate input as well as volunteers from around the world. But how do smaller projects deal with the rise in reported critical vulnerabilities, when they’re usually run by one or two people, often working in their spare time?

It’s a crisis of developer productivity. We need code that’s fixed and we need it now, but we don’t have enough skilled developers to deliver those fixes in the limited time available.

Can agents solve the problem?

Agent harnesses have become increasingly powerful tools, providing frameworks for orchestrating and managing teams of agents. General purpose tools like OpenClaw have proven to be particularly popular, though they can be expensive to run, with operations using up a substantial number of tokens across models and services. However, like most general purpose AI applications based on large language models (LLMs), inaccuracies and hallucinations can affect outputs.

Even so, an approach like this that’s grounded both in a defined methodology and in a significant corpus of data could help us meet the sudden demand for increased developer productivity — using the structured nature of code and APIs as grounding and the combinations of skills that go into building a modern software development team and addressing the various aspects of the software development life cycle.

What’s needed is a way to take advantage of those tools to build on techniques like spec-driven development and agent harnesses to provide developers with their own team of agents. Soon, agents may provide that force multiplier needed to keep ahead of AI red teams and at the same time help clear out large amount of technical debt.

Here comes the Squad

One interesting example of this approach is Squad, an open-source project from Brady Gaster, Principal PM Architect in the CoreAI Apps and Agents team at Microsoft. Squad builds an agent harness around GitHub Copilot, orchestrating a team of agents to work on your code with you. Designed to be installed with a single CLI call, Squad creates agents to handle application development: a developer lead, a front-end developer, a back-end developer, and a test engineer. Other roles, like documentation, can also be managed by Squad.

The intent is to replicate the structure of a team building a web application, using natural language inputs to define the task, with the agent harness then coordinating Squad’s agents to build and test the necessary code. Gaster has made some interesting decisions as part of the tool’s architecture, such as requiring a separate agent to fix issues detected by another agent’s tests.

This approach is designed to prevent an agent from looping around the same set of statistically generated outputs. Instead, a new agent offers a new context window and a new set of seeds, allowing it to generate different solutions to the same inputs. Only then will Squad generate a pull request for human review. You the developer are still in the loop, but you’re the senior developer and architect to Squad’s team of junior engineers.

Another interesting architectural decision was to ignore the convention of having agent-to-agent chats as a tool for synchronizing decisions. Experience inside Microsoft has shown this approach to be fragile. As a result, Squad treats agents as a set of asynchronous distributed computing tasks, using external persistent storage to hold details of architectural and other decisions. The shared storage, based on a strict format that can be accessed by different generations of the Squad agents, ensures that decisions can be passed between projects and that context is preserved between sessions.

Having a defined source of context also ensures that when any member of your team clones your application repository, their Squad agents have access to the same “memory” and can start working as soon as the Squad CLI is loaded or launched from Visual Studio Code or GitHub Copilot. It’s an efficient approach that saves time and ensures that everyone on the project and using Squad has the same starting point.

Getting started with Squad

To get started with Squad, you need to have an up-to-date Node.js installation on your development machine, along with a Git repository to store code and the Markdown documents used by Squad to store its context. With those in place, a single call to npm installs the Squad CLI, ready for use.

You set up the Squad environment with its init command. You can run Squad from its CLI or from inside Visual Studio Code and GitHub Copilot, where it’s available as an agent. You can also use Squad from the GitHub Copilot CLI, which gives you an interactive view of how the various Squad agents work.

Squad’s CLI works well for basic projects but using Squad as part of Copilot also gives access to additional resources, including Model Context Protocol (MCP) servers, which can help with more complex application developments as well as providing more useful grounding for specific Squad agents. However, there’s enough flexibility here to fit Squad into your existing toolchain, allowing you to make it part of your workflow, rather than vice versa.

There is a third way to use Squad: working with the Squad SDK to build your own automation framework around the Squad tooling. Here you’ll use TypeScript to manage agent creation, as well as writing your own routers and coordination services. The Squad SDK is a powerful tool that can be used as part of more formal development processes, for example integrating into a CI/CD pipeline to help triage a high volume of pull requests. As all three ways of working with Squad use the same back end, they all share the same memories, so will respond to inputs in similar ways.

Using Squad to write and fix code

I used Squad from the Copilot CLI, building a basic Node Express application, with a web front end. What was perhaps most interesting about the process was that the Squad harness allowed its role-based agents to work in parallel: an agent building back-end code to support service APIs could run at the same time as an agent that was building a React-based user interface. The initial squad of agents that Squad generated included an architect as well as front-end and back-end developers.

Squad’s output was, at least in my test applications, clear and easy to understand, ready to be used as the basis for a more complex application. It was delivered quickly, using a test-driven approach to ensure that code performed as intended, with no obvious bugs. By taking a formal approach to software development, Squad can reduce risks and explain its actions to a human user. It can also be used to document the code it delivers, using another specialized agent to deliver documentation.

There’s plenty of human supervision in the process, though there’s also the option of handing over control of repetitive tasks to Squad. After some time, you can build up enough trust that you don’t need to approve every new file or directory. A squad works in the context of your Git repository, but if you want more security you can choose to run your squad inside a dev container, keeping it in an isolated environment.

Here comes the artificial junior developer

We’re still at the very beginning of the process of using AI-based tooling as part of our development workflows, but the available tools are starting to mature very quickly — both as models improve and as we learn how to build the long workflows needed to implement agent-based applications.

Squad’s approach to development mixes well-understood software development methodologies with the team structure necessary to deliver applications. For now, as Squad is alpha code, it’s something to experiment with in limited, well-understood use cases.

But as our understanding of how to use AI-powered development tools grows, it’s easy to see how AI coding might evolve to become something like Squad — a way of harnessing agents to behave like a pocket development team that keeps a human in the loop as development lead to a team of artificial junior developers. And maybe we’ll be able to keep up with Claude Mythos and its descendants.