Part II. The team: people and agents
Learning when AI writes the first draft
Juniors, confidence and verification
Three weeks without writing a line
At the Sprint Review, Celia, the designer, asked why the class filter took so long to load. Aitana had made that change. She opened the code to explain it and went quiet. She had generated it with AI, she had tested it, it worked, and she did not know why it was written that way.
Later, in private, she told Olga that she had gone three weeks without writing a line of code from scratch. She asked, skimmed the result, tested it and delivered. She was moving very fast. And she had the feeling she was learning less than during her internship.
If you don't write, you don't learn to review
Reviewing well requires knowing how to write. You spot a mistake because you know how it would be done right. Someone who has never written a slow query cannot see a slow query.
That is why AI creates a learning problem, and it hits people who are starting out the hardest. A developer with ten years in the trade uses AI to go faster at what they already know how to do. A junior uses it to do what they don't know yet, and skips exactly the part where the learning happens.
It is not only about juniors. Jeff Gothelf, in Product Management and AI (Sense & Respond Press, 2026, chapter 5), cites a study by Sarah Baldeo, a researcher at Middlesex University, published in April 2026 in the journal Technology, Mind, and Behavior, in which almost two thousand adults carried out work tasks with AI.
Those who accepted what the AI proposed without questioning it ended up with less confidence in their own judgement. Those who corrected it, challenged it or rejected it ended up with more confidence than those who did not use it. The variable was not the tool: it was the attitude with which it was used.
Your draft first
The most useful rule I know is simple:
Your draft first, then the AI. Three lines of your own before you ask for anything. Then compare.
The draft does not need to be good. It needs to exist. When the AI responds, the comparison is what teaches you: where you agree, where you don't, and whether you were about to accept something that was wrong.
In a team, the rule applies in Product Backlog refinement and in the code. In refinement, each person writes their own idea of the acceptance criteria before asking the AI for them. In the code, whoever is starting out writes the first version of a small function before generating the rest.
Review, the place where learning happens
Code review between people goes back to being what it was in the best teams: the place where learning happens, not a formality before going to production. Aitana and Germán started reviewing together once a week, with her code in front of them, and Germán asked "why this way?" before saying anything else.
Two things you should not demand:
- Speed without verification. If what gets rewarded is delivering a lot, a lot gets delivered without being checked.
- "Using AI" as a performance target. It will be used for everything, even for things that would be done better without it.
And one worth remembering: reviewing is more tiring than writing. A team that spends the day reviewing generated code needs to share that load and put a limit on it, as we saw in chapter 4.
In short
If you don't write, you don't learn to review. Accepting without questioning erodes judgement; arguing with the AI strengthens it. Your draft first, then the AI, and review between people as the place where learning happens.
Try it this week
For one week, in refinement, each person writes their acceptance criteria before asking the AI for them. At the end of the week, compare: what would you have let through if you had accepted the first thing that came out?
There are more ideas for sharing the load in How to work with agents without burning out the team (in Spanish).