Part II. The team: people and agents
An agent is not a teammate: it is capacity
The hybrid team and specs as a common language (Spec-Driven Development)
Three agents and a bug log
At ITNOVE we build our website with AI agents (in Spanish). Three of them work on their own every day. One reviews the changes that have come in overnight and looks for bugs, and it only tells me what it can prove. Another prepares an email for me every morning with what needs my attention. Another watches the marketing funnel and suggests improvements. None of them changes how the website behaves without my approval.
It works, but it didn't start out that way. When we analysed the 134 fixes we made between late August and mid-October 2026, one in four code changes fixed something from before. I found almost 70% of the bugs myself, by looking at the website, and not one was found by an automated test. The code came out fast; what failed was everything that was supposed to check it.
Meanwhile, at GymApp, Germán gave the first agent a small task: add a warning to class booking when fewer than three places are left. He wrote the task in two lines. The agent finished it in twenty minutes, touched four files and broke the place count for double classes, which nobody had mentioned to it.
What an agent is
An agent is an AI model with tools and permissions that does a multi-step task: it reads code, changes it, runs tests, queries data and tries again if something fails. It is team capacity, just like a continuous integration server. It is not a member: it is accountable for nothing.
That gives you the practical rule. You give an agent bounded work, with a clear specification and a way to check the result. You don't give it work that requires deciding value, negotiating with people or taking on a risk.
The spec, the common language
In a hybrid team, the specification (the spec) is the refined backlog item. The path is this: a user story describes the value; the spec describes precisely what has to happen, with examples and edge cases; the agent proposes the change; a person reviews it against the spec and against the Definition of Done.
Germán's task failed because there was no spec, not because of the agent. Two lines say nothing about double classes. A spec would have included examples like these:
- Given a class with 20 places and 18 bookings, when a member opens it, then they see "2 places left".
- Given a double class, the warning counts the places in each session separately.
- If the class is full, the places warning does not appear: "Class full" appears instead.
Writing that takes ten minutes. Reviewing a change without it takes much longer.
Working this way is called Spec-Driven Development (in Spanish). The usual objection is that it sounds like waterfall: first specify everything, then build. It isn't, as long as the spec is small, covers a single item and comes from what the team has learned. Chapter 7 explains why.
Permissions and boundaries
Before you give an agent work, you decide what it can touch, what it can't and where it stops to ask for permission. An agent that can change the production database without anyone seeing it is not capacity: it is a risk.
The natural boundary is the review of the change. The agent proposes; a person reads it, tests it and integrates it. On our website, no proposal from the quality agent changes how the website behaves without a "yes" from me.
Routines rather than teammates
There is a temptation to treat agents as teammates you talk to in the team chat. It works worse than treating them as routines: tasks that run at a set time, with a known input and output, that someone reviews. A quality guardian that runs every night. An agent that prepares the summary of pending work every morning. An agent that opens the change when a spec is approved.
Routines can be measured, improved and switched off. "Teammates" turn into one more conversation.
This is the biggest lesson from our bug log: the agent that adds the most value is not the one that writes the most code, but the one that checks every night what has come in and writes down what it can prove. The same day I added this book to the website, one of them found that several buttons in the chapter editor did nothing. Nobody had noticed. It fixed them and left a test so it wouldn't happen again.
In short
An agent is capacity, not a team member. You give it bounded, specified and verifiable work, within permissions decided beforehand. The spec is the common language between people and agents, and human review is the boundary.
Try it this week
Write the spec for a small item in your backlog, with three or four "given, when, then" examples, and give it to an agent. Count how many things you have to correct. Then do the same with a two-line description and compare.
To write the spec you have the Spec-Driven Development Kit (in Spanish), and to decide what your first agent will do and what it won't, the first agent canvas (in Spanish).