
# Closing the Loop

I don't want to test. I don't want to run the app and click around. I don't want to verify that the code compiles. I don't even want to review the code myself. I want my robot to do all of that and then prove to me that it works.

That's the goal. Automate every step of the feedback loop so the only thing left for me as a human is looking at the proof and deciding: is this correct?

## Why Automation Matters

AI agents can generate a lot of code quickly. But without feedback, they'll happily produce code that doesn't compile, fails edge cases, or ignores your standards.

> [!IMPORTANT]
> The agent doesn't know it's wrong unless something tells it.

If I need to tell all errors to the robot, then I am the bottleneck. Every time I need to manually test, manually review, or manually point out issues, I'm slowing the whole process down.

Every time you find yourself doing something again and again, you should ask yourself: "can I delegate this to the robot?". The answer is most definitely: "yes!". The robot is very good at performing repetitive tasks and generating its own feedback.

Compilation fails? The agent sees the error and fixes it. Tests fail? Same thing. Linter complains? It knows immediately. But also think about testing through the browser. Checking if the deployment succeeded when it created a PR on GitHub. This is what I mean by closing the loop.

## The Feedback Stack

There are different gates that need to pass before I consider it worthwhile to really put my own time into it.

**Compilation** is the first gate. If it doesn't compile, nothing else matters. This is mostly out of the box and most agents will automatically do this.

**Static analysis and linting** catch style issues, potential bugs, and deviations from project standards. This should already be part of your build setup.

**Tests** are where the real proof lives. I'm pushing harder and harder for 100% test coverage. This is where you need to nudge the agent into doing this. Make it part of your project's documentation or AGENTS.md.

By driving it to 100% coverage you are sure that all code is covered and thought of. Make sure it doesn't write nonsense tests. Review it and put it in your description.

**Browser testing** takes it further. The agent can use [playwright](https://playwright.dev) or [rodney](https://github.com/simonw/rodney) to control a browser, navigate to pages, take screenshots, and verify that the UI looks right. This catches so many errors before I need to lift a finger.

**Showboat documents** are my recent find and really nice. A [showboat](https://github.com/simonw/showboat) document is an executable markdown file that runs code, captures output, and produces a readable proof of the work. I let the robot build a showboat document to prove to me that the functionality works. Thanks to [Simon Willison](https://simonwillison.net) for creating showboat and rodney.

This is just during the development phase (although the showboat and browser tests can span to deployment). When I create a PR, it is automatically deployed to a test environment, we can continue there:

**Monitor deployments** to verify that the PR will be deployed correctly. Using [showboat](https://github.com/simonw/showboat) again to prove that it works on test. 

**Monitor the PR** for feedback from automatic tools, or team members.

If during any of these steps an issue pops-up, the robot can fix it without me intervening. I do have to figure out how to **Monitor the PR** automatically. Right now I nudge the robot when I see that there is feedback on the PR.

## Code Review Without Me

Even with all that automation, the agent might still miss things. Subtle logic errors, forgotten edge cases, or code that works but violates the project's conventions. That's where I bring in a [reviewer agent](/blog/the-reviewer/). Another model, or the same model, but a fresh session. Its only job is to check if the code is complete, correct and according to our standards. The result of the review is passed to the coding agent to fix the code and resubmit. This cycle runs automatically until the reviewer gives a pass.

I wrote about this in detail in [The Reviewer](/blog/the-reviewer/). 

## What's Left for Me?

I want to get to a stage where I can focus on what really matters: The functionality. Code has become commodity and I should not need to worry about it. When the robot is done, I get:
- Code that compiles and passes linting
- A full test suite that passes
- Screenshots of the UI in action
- A showboat document proving the functionality works
- A code review that's already been addressed

My job is to look at all of this and decide: does this solve the problem? Is the approach sound? That's a much better use of my time than copy pasting errors to the robot. 

## Lean In

When the agent keeps getting something wrong, the temptation is to just fix it yourself. Don't. Instead, figure out why it's failing and automate the check. Can you write a test for it? A reviewer instruction?

Every time you manually correct the agent, you're doing a one-time fix. Every time you automate the feedback, you're fixing it forever.

## Become the Architect

Coding is cheap, the agent can do a lot of work, but all goes to waste if we hold its hand and guide it every step. We must put some effort such that the robot can verify its own work. This pays for itself on the very next task. And the one after that. The compound effect is enormous.

I spent my time crafting the OpenSpec proposal and reviewing the end result. The robot handles the rest. I have become [The Architect](/blog/the-ai-coding-ladder/#level-6-the-architect).

Close the loop. Then let the robot run.


Why I automate every step of the development process so the only thing left for me is reviewing the proof

Closing the Loop


Lately I was thinking about [MCPs](https://modelcontextprotocol.io) and what they are useful for. I stopped using them in my coding agents. But do they still have a purpose? For some time I didn't know, but when I started to think more about security and how to lock down agents, I think I found the answer.

# Development

When it came out, many developers hurried to put them in the Agent config. This led to context bloat and it is clear now that the Models we use can work very well without MCP. A [skill](https://agentskills.io) with a script works very well. For development, I think MCP is mostly nonsense. Your agent has bash access, so it can use all the CLI tools you have installed. These work very well. 

# Use of MCP

MCPs do serve a purpose when you want to lock down the agent that you are running. For instance, that email agent that should only be able to read mail and attach labels to them. You want to restrict the agent to only use the read mail, and the label mail tool. 

# The reasoning 

The moment you give an agent bash access, it can do anything. It can read files, write files, run commands, install tools, etc. In that case, use skills. If you want to restrict the agent to only use certain tools, you have to give it access to those tools and not give it bash access. This is mostly useful if you want to create an agent in an application.

MCP is actually a way to restrict what the agent can do. Use it to create a more secure agent, not to give it more power.


Use CLI tools over MCP for dev, but MCP has it place

MCP to restrict agents


# Your AI Skills Need a Package Manager

Every time I start a new project, I have to do some mumbo jumbo to get the correct skills available for my project and client. Copying skills from one project to another, or installing them globally. It's a mess. I want to be able to manage my skills and agents like I manage my code dependencies. 

I play around with different coding agents and I need to do this whole copy-paste-install process every time. Forgetting to copy a skill, and then wondering why the behavior of this new coding agent is different.

[skills.sh](https://skills.sh) is a nice tool to install skills. But there is no management. I have to remember which skills I need to install, and updating only works on global skills. So I decided to build dependency management for agents.

Enter [agentdeps](https://www.npmjs.com/package/agentdeps).

**Agentdeps** allows you to create an `agents.yaml` file in your repo. This file contains the skills and agents you want to use. You can commit this file, just like your pom.xml or requirements.txt, and everyone working with the repo will have the same skills and agents. When you change the file, everyone can update their environment with a single command.

### Adding skills and agents to your repo

With the `add` command you can interactively add skills and agents to your project (or globally). You can select the ones you want and it will create an `agents.yaml` file in your repo. If there is already an `agents.yaml` file, it will update it with the new skills and agents you selected.
 
```
npx agentdeps add vercel-labs/agent-skills
```

Choose your skill (or all):
<img src="/images/installing_skills.png" alt="Select skills" style="max-width: 600px;" />

### Updating

Did the config change, or did you just clone a repo with an `agents.yaml` file? Run `install`.

```
npx agentdeps install
```

### Configuration

On first run, **agentdeps** will ask for some configuration. Mainly, which cloning mechanism to use (https/ssh), and how to install skills and agents (symlink or copy). You can change this configuration at any time. Just run `npx agentdeps config` and it will ask you the configuration questions again.

***We've been managing code dependencies for decades. Why are we still manually wrangling our AI skills? Give [agentdeps](https://www.npmjs.com/package/agentdeps) a try and let me know what you think.***


I built a package manager for AI agent skills. Here's why.

Jeroen Gordijn

Latest Articles

Closing the Loop

MCP to restrict agents

Your AI Skills Need a Package Manager

Ready to Develop Faster with AI?