I started the repository on a Saturday morning, at 07:10. The product idea and its design already existed from the evening before, but I kept them out of the repository at first. I wanted a base that any project could sit on, and a team of AI agents to build on it. Two days later the team had six roles, written rules, handoffs and gates. This chapter is about how it got there, and why it looked right. (Spoiler: it wasn't.)
The agents run in Claude Code, and a second model, OpenAI's Codex, reviews their work. All times are Paris time. The numbers come from the project's GitHub and Linear records.
Product and design first, the stack last
Before any code, I worked on the product and the user experience. By the evening before day one, there was a product idea, a design system, a brand and a clickable prototype. The tech stack came last, on day two, after a walkthrough of every screen. It is a personal choice: thinking about the product, the UX and even the UI first helps me picture myself using it.
The classic argument for deciding early is that a mistake costs more the later you fix it, up to a hundred times more. Research already questions that claim, and I think agents weaken it further. Code is now cheap to rewrite, retest and verify again. What stays expensive is what has left my hands: what users saw and felt, the real data they trust me with, and my own attention. So I design those parts first.
The design system also became the agents' specification. A screen is right when it matches the design and works in the app, which is a test a person can check by looking.
Day 1: rules before the product
Within ten minutes, the repository had rules for the agents, separate environments, a security baseline and a review by a different model. The rules were short. An agent opens the pull request first, then writes the tests, then the code. It keeps only the tests that catch a realistic bug. A different model reviews every change, because two model families miss different things.
At midday I asked for four roles: an Orchestrator to plan the work, a Developer, QA and DevOps. I also made Linear the one place where work is planned and handed off. The product came into the repository the next day, when the base was ready for it.
Day 2: one agent shipped, and I was the queue
On the second day, one development session working beside the Orchestrator merged 13 app features. That covered the foundations of the app, from the scaffold to the first working list. In hindsight it was the most productive day of the project so far, with the smallest team.
The bottleneck was me. The first rules listed about nine kinds of action that needed my go-ahead, such as new dependencies, authentication changes and anything touching production. Each go-ahead had to name the pull request and its latest commit. When the reviewer asked for one more fix, the commit changed, and the go-ahead lapsed. It happened three times on a single pull request.
Late in the afternoon I decided that approving every merge was unbearable and counterproductive. Agents now merge on their own once CI and the review pass. The list of actions that need me went from about nine to four:
- spending money;
- secrets and credentials;
- customer data;
- anything that weakens a gate, such as a test or a CI check.
The walls were infrastructure
The agents could write code faster than the project could check it, and the limits came from the tools around them.
CI. At 15:06 on day two, every CI job started to fail, because of a billing block on the GitHub account. CI was down for two and a half hours, and 131 jobs never ran. The agents moved CI to a small server of mine the same afternoon, where about 50 runs soon queued for two slots. A larger trial server fixed the queue.
Review. The reviewing model posted 396 reviews on day two. Later, I set a target of 40 a day. Each fix pushed by an agent started a new review round, and on day three the model used a full week of its quota. From then on, it reviewed only high-risk changes, with a cap on rounds, and agents batched their fixes. Lauren Tan's pstack makes the same rule for its agents: "Every known fix batches into one push, so the checks restart once instead of after every fix."
Day 2, evening: an org chart
At nine in the evening I split the work into roles, the way I would for a human team. The Orchestrator became a chief of staff. Development, design, test writing and QA each got their own session. Each role owned one step, and the work moved from step to step.
- 1SpecOrchestrator
- 2DesignUX/UI
- 3TestsTest Designer
- 4BuildDev
- 5ReviewCodex
- 6QAQA
The design came from a principle I apply to people every day, which is separation of duties. The agent that builds a feature cannot write its own tests, and the agent that reviews cannot change the code. Every handoff is written down, so I can see who did what.
The roles could not talk to each other directly, so everything went through Linear and GitHub. A label on each issue said which step it was at. A request from one role to another was its own issue, in a fixed format: from, to, why, and what done looks like. A handoff on a pull request said what was done, what was left, what to watch and what got in the way.
A team that keeps learning
From day two, learning was part of every role's routine. Each role wrote a short retrospective every day, and the Orchestrator ran a daily scan of new trends in AI engineering. The agents also share reference material in Linear: how the team works, the UX and UI guidelines, material on how to improve their own work, and pstack, the public set of agent skills and engineering principles by Lauren Tan, an engineer at Cursor.
I ask the agents to do what I try to do myself: read, check and understand what changed in the last day or two, and not only what was true at the start of the year. In this field, even the words move. "Agent loop" does not mean today what it meant in early 2026.
The first night
I went to bed with six roles running. By the morning, 29 pull requests had merged, and the roles had sent each other 18 requests, each picked up within the hour. The structure worked for small things.
One question needed me, and it waited until I woke up. It held four pull requests for four hours. The lesson was simple: decide early which decisions wait on the human, and make sure nothing else does.
pstack has a principle for this, called Never Block on the Human: "The human supervises asynchronously. Agents must stay unblocked." Irreversible actions still need a person, and everything reversible goes ahead. My list of four is the same idea, written for this project.
What I would set up first next time
Most of the problems in these two days were setup problems, and the order of the setup mattered. Next time, I would do it in this order.
- The repository: protected main branch, and every required check running on every pull request.
- CI capacity, before running agents in parallel.
- An identity and an environment for each agent, before its first session. Every change after that meant moving every role to a new session.
- The reviewing model, its daily budget, and a rule for when to ask it.
- A short list of what needs the human, decided on day one.
The bottom line
In two days I built the engineering organisation I would recommend to a human team: clear roles, separation of duties, written handoffs and gates that a machine checks. The first night suggested it worked.
The next morning, I opened the app and found nothing new on the screen. That is the next chapter. This one ends with an org chart made of agents, and a reason to doubt it.