---
title: "From Prompts to an AI Engineering Team: How My Coding Setup Evolved"
date: 2026-06-25T00:00:00.000Z
description: "How my AI coding setup grew from one-off prompts to a team of 16 agents with shared skills, plugins, and a learning loop, and what it did to output."
tags: [AI coding agents, Claude Code, agent skills, AI workflow, multi-agent systems, build in public, developer productivity, AI agents, prompt engineering, software development]
canonical: https://vatsalshah.ca/blog/from-prompts-to-an-ai-engineering-team
---
## Introduction

A year ago, my AI coding tool was a chat window. I typed what I wanted, and every session I re-explained the same things. Today it is a team of agents with shared skills and a fixed review process, and it keeps a memory of its own mistakes.

This is the story of how that setup changed, step by step, with the real dates. I am writing it because the jump from a single prompt to a team of agents did not happen at once. It happened in clear stages, and each stage is something you can copy.

![Monthly commits across all repositories over the last 12 months, with the AI setup milestones marked](/images/blog/ai-setup-impact.png)

**What you'll learn:**
- The five stages my AI setup went through, from one-off prompts to a team of agents
- The difference between a skill, a command, a hook, and an agent, and when each one earns its place
- Why a separate reviewer agent catches what the builder misses
- What the change did to output, with an honest read on the numbers

## Phase 1: typing the same thing every time

For a long time I used AI coding tools the way most people do. I opened a chat and typed what I wanted. Every session I re-explained the same things, e.g. how we name files and how we write tests. The tool kept no memory of any of it, so I repeated myself constantly. It was helpful, but it started over every time.

## Phase 2: writing the rules down

The first real change was simple. In early 2025 I started writing the rules down in files that the tool reads on its own. Later I added one main instruction file for the whole project. Now the conventions lived in the repository instead of in my head, and I stopped re-explaining them.

This is the step most people skip, and it is the one with the best return for the least effort. If you want the idea behind it, I wrote about it in [context engineering versus prompt engineering](/blog/context-engineering-vs-prompt-engineering-2025-guide).

## Phase 3: turning rules into skills and plugins

The rule files worked, but they were just text that always loaded. The next step was turning them into skills. A skill is a small, focused unit that the tool loads only when it is relevant, e.g. one skill for writing tests and one for reviewing a pull request. I also moved the shared skills into their own place, so more than one project could use the same ones. I explained what skills are in [Claude Skills and new AI agent capabilities](/blog/claude-skills-new-ai-agent-capabilities).

## Phase 4: a team of agents, each with one job

Then I stopped treating it as one assistant and set it up as a team. I gave it a group of named agents, and each one has a single job. One plans the work. One reviews the code. One writes the tests. One checks for security problems. There is a lead agent that I talk to, and it hands work to the others.

They follow a fixed order. Nothing gets written until the plan is agreed. After code is written, it has to pass review and tests before it can become a pull request. I also added a learning loop. When something goes wrong, the lesson gets written back into the agents, so they do not repeat it. The whole team is saved in version control, which means it is real infrastructure and not notes in a chat. The general idea behind running many agents together is in [AI agent orchestration and multi-agent systems](/blog/ai-agent-orchestration-multi-agent-systems-2025).

## Phase 5: one setup across every project

The last step was scale. I had a good setup in one project, but I work across many. So I built a shared setup, a set of skills and plugins that I write once and sync into every project and into the editors I use. Now every project starts with the same team and the same rules, instead of me rebuilding it each time.

## Why a team of agents, and not just skills, commands, and hooks

A fair question I get is this. Claude already has skills, commands, and hooks. Could the same thing be done with those instead of a team of agents? The honest answer is that all of them matter, and I use all of them. They do different jobs, so it is not one instead of the other.

Here is how I think about each one.

- A skill is a piece of knowledge or a procedure that the tool loads when it is relevant, e.g. how we write tests, or how we name files. It teaches the model how to do a thing well.
- A command is a starting point that I trigger, e.g. one command to plan a feature, one to review a change. It is the button I press to begin a piece of work.
- A hook is a rule that the system runs on its own when something happens, e.g. block a commit that contains a secret. The model does not decide this. The system enforces it every time.
- An agent is a separate worker with its own context and one job, e.g. one agent plans, one reviews, one writes tests, one checks for security.

So what does an agent give you that a skill or a command does not? Two things.

The first is a separate context. When one agent writes the code and a different agent reviews it, the reviewer does not share the writer's assumptions. It reads the change with fresh eyes. A skill or a command runs inside the same context as the work, so it tends to agree with the reasoning that produced the work. You do not get a real second opinion when one context grades its own homework. A separate agent gives you that second opinion.

The second is parallel work. Many agents can run at the same time, each on its own piece. That is part of how a small team moved at the pace the chart shows.

The agents are not a replacement for skills, commands, and hooks. They use them. A reviewer agent runs a review command and follows the review skills. A safety agent relies on the hooks. The agents are the layer that turns a set of good tools into a process, where work is planned, then built, then reviewed by someone other than the builder, then tested, before it becomes a pull request.

To make it concrete, here is the actual team. One lead I talk to, and a set of specialists, each with a single job.

- **COMMAND** leads. It plans the work, decides who is needed, and hands out the tasks.
- On the build side, **ARIA** owns UI and UX, **FORGE** owns the backend and APIs, **ATLAS** owns how the packages fit together, **ORACLE** owns the database, and **STONEWALL** keeps the shared server code clean.
- On quality and safety, **SENTINEL** runs review and the gates before production, **SPARTAN** is the adversarial guard against overengineering and scope creep, **AEGIS** owns security, **SCOPE** keeps a feature from quietly growing, **SYNC** runs builds and deploys, and **SCROOGE** watches the cost of running the agents themselves.
- On product and growth, **CONVERT** weighs activation and retention, **ICP** speaks for the power users, **QUILL** handles copy and onboarding, **COMPASS** ranks what to build next, and **SCOUT** does the research.

The skills hold the knowledge. e.g. the testing skill knows we keep tests next to the code and avoid brittle snapshot tests, and the translations skill knows every user-facing string has to work in all 24 languages. The agents apply that knowledge and check each other.

Here is what it looks like on one real change. Say I ask for a new screen that shows a user's billing history.

- **COMMAND** writes the plan and decides this needs the UI, the backend, and a security check.
- **ARIA** builds the screen, and **FORGE** builds the endpoint behind it.
- **SPARTAN** reads the whole change and pushes back if it added something we did not need, so the code stays small.
- **AEGIS** checks that the new endpoint cannot return another user's data.
- **SENTINEL** runs the tests and the build.
- Only after all of that passes does the change become a pull request for me to look at.

No single agent does all of this, and no agent reviews its own work. That is the real reason for a team. Not because one model cannot follow instructions, but because important work should be checked by a different set of eyes than the one that did it.

## What it did to the work

For two years my output sat at **about 450 commits a month** across all my projects. During the period when the agent team was in place, that rose to **about 1,700 a month**.

I want to be honest about why. A large part of that rise is a full web app rewrite, which was a burst of work on its own. So I am not going to claim the agents alone tripled my output. What I can say is that a small team sustained about 1,700 commits a month while running that rewrite across 12 repositories at the same time, and that pace was not possible the way I worked a year ago. If you want the rewrite story itself, it is here: [rewriting a live web app from Angular to React in 7 weeks](/blog/rewriting-angular-to-react-with-ai-agents).

There is one change I am most glad about. The old app had limited test coverage. The new one has a broad automated test suite. The setup did not only help me write more code. It helped me build the safety net the product had been missing.

## What I would tell you

- Write your conventions in files the tool reads on its own. Stop re-explaining yourself every session.
- Turn those rules into small skills, each with one job, so the tool only loads what it needs.
- Give the agents a fixed pipeline and a learning loop, so quality holds as the speed goes up.
- Once it works in one project, build it once and share it across all of them.

## Conclusion

A year ago this was a chat window where I retyped the same instructions. Now it is a team with rules and skills, and it remembers its own mistakes. The output curve is real, and so is the test suite that did not exist before.

<FAQSection
  title="Frequently Asked Questions"
  questions={[
    {
      question: "What are the five stages your setup went through?",
      answer:
        "I started with one-off prompts, then I wrote the rules down in files the tool reads on its own. After that I turned those rules into small skills, then I set up a team of agents that each have one job, and finally I built one shared setup that I sync into every project.",
    },
    {
      question: "What is the difference between a skill, a command, a hook, and an agent?",
      answer:
        "A skill is a piece of knowledge the tool loads when it is relevant. A command is a starting point I trigger to begin a piece of work. A hook is a rule the system runs on its own when something happens, like blocking a commit that contains a secret. An agent is a separate worker with its own context and one job.",
    },
    {
      question: "Why use a team of agents instead of just skills, commands, and hooks?",
      answer:
        "All of them matter, and I use all of them, so it is not one instead of the other. An agent gives you two things the others do not: a separate context, so the reviewer does not share the writer's assumptions, and parallel work, so many agents can run at the same time.",
    },
    {
      question: "Why does a separate reviewer agent catch more?",
      answer:
        "When one agent writes the code and a different agent reviews it, the reviewer reads the change with fresh eyes. A skill or a command runs inside the same context as the work, so it tends to agree with the reasoning that produced it. You do not get a real second opinion when one context grades its own homework.",
    },
    {
      question: "How is the team actually set up?",
      answer:
        "There is one lead agent I talk to, called COMMAND, which plans the work and hands out the tasks. Under it is a set of specialists that each own one area, across building the product, quality and safety, and product and growth. No single agent does everything, and no agent reviews its own work.",
    },
    {
      question: "Did the agents triple your output?",
      answer:
        "I want to be honest about this. My output rose from about 450 commits a month to about 1,700, but a large part of that rise was a full web app rewrite, which was a burst of work on its own. What I can say is that a small team sustained that pace across 12 repositories at once, which was not possible the way I worked a year ago.",
    },
    {
      question: "What did it do for testing?",
      answer:
        "The old app had limited test coverage. The new one has a broad automated test suite. The setup did not only help me write more code, it helped me build the safety net the product had been missing.",
    },
    {
      question: "Can I copy this without doing it all at once?",
      answer:
        "Yes. The jump from a single prompt to a team of agents happened in clear stages, and each stage builds on the last. You can start by writing your conventions in files the tool reads on its own, which is the step with the best return for the least effort.",
    },
  ]}
/>

## Further Reading

- [Rewriting a live web app from Angular to React in 7 weeks](/blog/rewriting-angular-to-react-with-ai-agents)
- [Context engineering versus prompt engineering](/blog/context-engineering-vs-prompt-engineering-2025-guide)
- [Designing a product AI agents can use](/blog/designing-a-product-ai-agents-can-use)
- [Production-ready AI agent architecture](/blog/production-ready-ai-agent-architecture)