From Prompts to an AI Engineering Team: How My Coding Setup Evolved

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.

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.

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.

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.

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.

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.

Further Reading

• Rewriting a live web app from Angular to React in 7 weeks
• Context engineering versus prompt engineering
• Designing a product AI agents can use
• Production-ready AI agent architecture