What is an agent?

Let me give you three definitions to build up to what we’re really talking about.

Agents in general

The concept of agents has been around for a while—since the old school AI and robotics days. The definition is straightforward: it’s something that’s able to observe its own environment and make decisions on its own.

A good example? A Roomba. It observes its physical environment and decides: should I go forward? Should I turn right or left? Should I stop? It’s an entity that can do exactly that—observe and decide.

Agents in the AI world

When it comes to agents in the world of LLMs, we’re typically talking about something that can make tool calls. These tools could be anything:

  • A tool to perform a web search
  • An API call to fetch weather data (when the model doesn’t have the latest information)
  • A tool to fetch the latest news about specific topics

An AI agent isn’t just giving you answers based on your questions—it’s making these tool calls to fetch information that wasn’t in its training data, or to affect its environment (like writing to a Google Doc).

AI coding agents

AI coding agents are a subset of AI agents. They use tool calls too, but with a specific focus:

File operations: Write files, read files, edit files, move files, search the codebase

Running code: Execute bash commands, run TypeScript, run Python—this is where the real power comes in

Everything else: Browser operations through Playwright, web search, GitHub operations, Linear operations, Slack operations—basically any information or action needed outside the codebase

One way to achieve this third category is through MCP servers. For those who haven’t encountered them yet, MCP (Model Context Protocol) is essentially a protocol for providing tools to an AI system. While it’s not just about tools, that’s one of its main functions. It’s becoming the dominant protocol, but ultimately it’s just one way to extend your AI’s capabilities.

The present: where we are today

Before going into the future of AI agents, let’s take a look at the present.

Presently, there are a few dominant agents, including Claude Code, Windsurf, and Amp. What’s common about them is exactly what I said—they’re all AI coding agents. The capabilities and UX/DX are slightly different, but at the end of the day, they are all able to perform file operations, run commands in bash or in a different language, and they’re able to extend themselves through MCPs.

They’re really powerful, and you should 100% learn to use them, whether you’re a software engineer or not, in my opinion.

Key use cases today

There could be an entirely separate article on how to use these agents to their maximum effectiveness, but just to mention a few things here:

Understanding existing codebases: One of the powerful things about them is understanding an existing codebase. AI had this reputation—really false reputation—that it’s only good for starting new projects, but it’s not good for understanding a large codebase. At this point, it’s not true at all. They’re able to use tool calls in particular to perform a search and keep performing different searches with different queries until they can find what you’re asking for. They’re able to read files on their own, read parts of files on their own. So it becomes a lot more useful than just an AI chat system like ChatGPT.

Starting new projects: Starting a new project is really powerful with these tools too, because you don’t have to necessarily copy and paste everything yourself. You can just have AI write directly into your file system. When I mentioned that these AI systems are now able to do that, I think about a year ago, people laughed because they thought the idea of giving your AI system access to your file system—read, write, move, and delete—that’s really strange. But it turns out that’s the right way to go. Obviously, you want to be careful about security, but when it comes to convenience and when it comes to speed, these systems are really powerful.

Running commands without memorization: When it comes to running commands, your knowledge of software engineering becomes really useful here. Rather than being constrained by what you remember—like the exact commands that you remember—you don’t have to memorize so much. You just need to learn concepts and know concepts, and you can leave the implementation details to LLMs and AI.

Good examples of this:

  • Git operations: Instead of remembering all the different git operations, you just need to know concepts like branching and committing—basic concepts really—and stashing, worktrees, stuff like that, and you can just let AI run commands for you, bisect as well.
  • GitHub operations: You can create a PR from your AI agents. You can just ask what your PR description and PR title should look like, and it’ll do it for you. If you need to edit PR descriptions, you can do that. If you need to fetch information from specific PRs, you can do that too. You might not necessarily do that without AI because doing it through a GUI on GitHub might be faster in that world, but in this world, you don’t need to remember these commands. AI most likely has training data—enough training data to know what commands to use for those specific things—so you can just ask them to do it. It’s super powerful.
  • Automated testing: We’re gonna get into it in the future part of the blog post here, but an example of this is Playwright. Using Playwright or browser automation systems, you can automate testing. You can just create a website, and you can make sure it’s working as intended through Playwright or through curl or maybe through a testing command, whatever that might be. You can automate not just writing code, but testing it too.

Essentially, as AI is able to take more and more of your—really the most boring parts of your software engineering tasks—you’ll be able to work much faster, you’ll be able to produce code faster and debug faster. Obviously, quality control is important. You don’t want to create a lot of code with bad quality, but at the same time, you’ll be able to focus more on the high-level design details instead of lower-level implementation details. It doesn’t really matter in this world if you use a specific flavor of a particular thing that you want to do in JavaScript or TypeScript, let’s say. What matters is that your system works well and that you’re able to provide value to your customer—to your users—through better quality, more features, or more efficient systems.

The future: where we’re heading

Let’s look at the future. To me it’s pretty clear: the future is more automation, more parallelization, and eventually orchestration or fleet management of many AI coding agents.

More parallelization

Parallelization is probably the most obvious trend today. In the future, you won’t be running just one AI coding agent—you’ll be running two, three, ten, maybe even hundreds or thousands of them.

People are starting to do this through git worktrees. You can create a new git worktree for each task and have AI agents perform file operations in their own isolated environments without interfering with each other. This way you can manage multiple tasks simultaneously—instead of waiting for one agent to finish, you can have several working in parallel.

You can do this manually by creating git worktrees yourself, or use one of the newer frameworks that handle it automatically. This is already powerful, but it gets even more interesting when combined with more automation.

More automation

We’ve come a long way with automation. We started by automating Google searches and Stack Overflow lookups through ChatGPT. Then we moved on to automating file operations, running commands, simple browser operations through Playwright MCP, and testing workflows.

Software engineering is essentially a loop: understand the task, write code, test it, fix it based on test results, and repeat until everything passes. The question is: how much of this loop can we automate?

What we can automate today

Right now, we can fully automate a few scenarios:

Unit test automation: Write code, have AI write unit tests (or vice versa), then let the AI agent iterate—fixing code, testing, fixing code, testing—until everything works. Since unit tests are easy to run programmatically, this entire loop can be automated.

Simple browser automation: When basic browser operations are sufficient, you can use Playwright MCP or similar tools. AI writes code, tests it through the browser (taking screenshots, extracting text), and fixes any issues it finds. The entire write-test-fix cycle runs automatically.

What we can’t automate yet

But there’s a whole category of testing that resists automation:

  • Game development: Testing game UI functionality often requires human-like interactions that are hard to script
  • VS Code extensions: I contribute to Amp as part of my job, and testing requires launching VS Code, clicking through menus, scrolling, typing—interactions that browser automation can’t handle
  • Complex browser interactions: Even for web apps, some interactions are beyond what Playwright MCPs can do—specific scrolling patterns, nuanced clicking and typing sequences

The challenge with traditional automation tools (Playwright, Puppeteer, Selenium) goes deeper than just technical limitations. Finding the right elements, simulating realistic user behavior, testing across different environments (Windows, Mac, Linux, different browsers)—there are countless variations that current tools struggle with.

Next-level automation: computer use

There’s clearly a missing piece in our automation toolkit. While we can automate scripts and simple browser interactions, we don’t have a good framework for more complicated tasks. I believe the solution will be AI’s computer use capabilities.

We’ve seen examples of this already:

  • Claude’s latest models with computer use
  • OpenAI’s Operator
  • Google’s Project Mariner

Once these APIs are advanced enough and widely available, they’ll be able to conduct the type of tests QA engineers typically do manually. Imagine AI writing code, testing it visually—clicking, scrolling, dragging, everything needed—then going back to fix bugs, and repeating until everything works. The entire software engineering loop, automated.

But there’s a challenge: if AI uses computer use capabilities on the developer’s local environment, it blocks them from using their computer. And it only allows one agent to run at a time, not multiple ones.

Developer environments for every agent

The solution? Each agent needs its own developer environment. There are two main approaches:

Containers: Lightweight but trickier to configure. Many containers don’t have GUI support by default (though this can be configured with tools like X11 forwarding or VNC).

VMs: Less configuration needed since they typically come with GUI support. They also offer more flexibility—Windows, different Linux distributions, and potentially macOS (though macOS VMs have licensing restrictions and typically only run on Apple hardware). The downside? More overhead.

It’s a fundamental architectural decision. With containers, you get less overhead and potentially lower costs. With VMs, you get more complete environments with less configuration hassle.

Where should the agent live?

Now there’s an interesting question: should the agent live inside or outside the developer environment?

Agent inside the container/VM: This is conceptually simpler. The agent lives in the same environment where it’s writing and testing code. It has direct access to the file system, can run commands naturally, and everything is self-contained.

Agent outside the container/VM: This gives you more control and separation of concerns. You can manage agent dependencies separately from the developer environment dependencies. Think of it as two boxes side by side instead of everything in one box.

The two-container approach works well enough for file operations (shared volumes) and terminal commands (SSH). But there’s a tricky part: MCP servers. Where should they live?

  • If they’re in the developer container, how does the external agent access them?
  • If they’re in the agent container, how do they access what’s happening inside the developer container?

Due to this complexity, I predict everything will end up in the same container. People will put both the developer environment and the agent together.

Early attempts

Companies are already exploring this space:

  • Cursor has background agents
  • OpenAI has their approach
  • Google has Jules

Interestingly, Jules takes the VM approach—providing a full Ubuntu VM environment. While Jules’ capabilities aren’t that advanced yet from what I hear, their approach of providing a complete VM environment is promising. There’s definitely an argument against it (why use a VM when containers might suffice?), but being able to provide a full GUI environment is a huge advantage.

The dust hasn’t settled yet on which approach will win. We’re still in the early days of figuring out the best architecture for AI coding agents at scale.

Putting it all together: the future

With all these pieces, we can clearly see what the future will look like. We’re going to start providing a developer environment for each agent. There will be some overhead to set it up—either manually (fine for a few environments) or automated through something like Dockerfile or Vagrant (which automates VM provisioning, unlike Docker which handles containers). The setup overhead is worth it if you’re planning to delegate the boring parts of your development work or massively scale up your agent orchestration.

Delegating the boring work

Here’s a real example: I was developing a VS Code extension and needed to find exactly which commit introduced a bug. So I ran git bisect—a pretty manual process. I marked the current commit as bad, guessed which earlier commit might be good, and then had to check eight or nine times, the same thing over and over again, until I found the exact commit. It took about 30 minutes.

It’s not hugely complex, just time-consuming and really boring. I wish an agent could do that. Claude Opus already has enough capabilities to take on a simple task like that, and that’s what’s really exciting to me.

There are other boring tasks developers would rather have AI do:

  • Identifying exact commits that introduced bugs
  • Running eval sets where there’s no automated testing yet
  • Manual QA testing that can’t be scripted

The cool thing is you don’t need to write specific scripts for these “manual” or visual GUI tests. Instead of having a QA engineer (or yourself) click through everything to try to break an app, you can just have AI do it.

Scaling up quality assurance

Imagine scaling this up for every PR. It’s easy enough to write and run unit tests, but what if you could also spin up a hundred containers—a hundred agents—to make sure your PR doesn’t break anything? Have AI go wild, trying different things related to your PR that could potentially break. Test everything by clicking, using your app, website, or game in realistic ways. If something breaks, they report back.

The three pillars of agent orchestration

The power comes from three key components:

  1. Developer environments: Providing a developer environment for each agent, ideally automated so you can scale the operation

  2. Easy deployment: A way to spin up these containers/VMs with agents easily—through CI, terminal commands, maybe even from your phone

  3. Orchestration and monitoring: A way to orchestrate these agents, assign tasks, and monitor their progress

We’re starting to see some of this for local agents, but not much for remote agents yet. But that’s clearly the future—putting agents in the cloud so they don’t all have to run on your own machine. The current workflow works fine, but it is kind of silly when you think about it.

The exciting future

Going a bit further ahead, imagine having access to a thousand potential agents that you can run anytime. You can spin them up, tear them down, and assign them to problems as needed:

  • One agent for a simple bug fix
  • Ten agents to implement a feature
  • A hundred agents to thoroughly test a PR
  • A hundred agents constantly trying to break your app

And imagine monitoring all of this—maybe through a Kanban board showing what each agent is working on, or something more visual. It might be like managing troops in a real-time strategy game. You have a hundred troops running around the battlefield, and you need to coordinate them effectively.

You won’t just be a software engineer anymore. You’ll be an engineering manager, maybe even a director of engineering, with hundreds or thousands of agents working with you. Larger and larger parts of your job will shift from writing code to managing robots that write code.

We’re not quite there yet, but we’re definitely heading toward that future. And to me, that’s pretty exciting.