You don’t need to believe AI thinks to anthropomorphize it. Handing it our tools is enough. GitHub, the pull request, code review, Scrum, the sprint, the standup, everything that organizes the work of a development team was designed to coordinate humans, and since agents started writing code, we’ve been handing all of it to them as is.
The frontend team I work in, at GoodBarber, started out adapting that way, then realized fairly quickly it was a mistake and changed course. What I take from it, personally, is that the tooling has to be redefined for machines, not adapted from ours.
Our tools are tools for humans
The standup exists so that people working side by side don’t each drift off in their own direction. The sprint bounds time because we always overestimate what we’ll ship in two weeks. The pull request keeps a record of a choice its author will have forgotten in a month, and code review puts a second pair of eyes where the first no longer sees anything.
None of these tools is about code. They compensate for the flaws of people, and they were tuned, over twenty-five years, to the speed at which people work. A Medium post titled “Built for Humans”, published in June 2026, says it in one sentence: these processes were calibrated on us.
Anthropomorphism, at industry scale
When AI coding agents arrived, we built nothing for them. An agent opens a branch, pushes commits, writes its pull request, answers the reviewer’s comments, and nobody found that strange.
A study from NAIST, published on February 19, 2026, on 33,596 pull requests opened by five agents, shows how far it has gone: depending on how the agent writes its description, humans answer it faster or slower and accept its code more or less often. We are grading a machine’s manners on a form written for colleagues.
In the other direction, a session at Stanford on April 30, 2026 proposed managing agents with Scrum and Kanban, standups included, to give them the memory and coordination they lack.
In July 2026, Kyle Galbraith of Depot wrote that GitHub is the wrong shape for this new world. His subject was infrastructure. I replied that the problem looked wider to me: Scrum, PRs, sprints all coordinate humans, and we keep anthropomorphizing AI by handing it our rituals.
Anthropomorphizing, here, means giving the machine a process designed for someone who forgets and gets tired, without having checked what that process was protecting us from.
Do pull requests work for AI agents?
Yes, they work, and that’s the trap. An agent knows how to open a PR, describe it and answer a comment. The ritual accepts it without blinking, so we keep the ritual and try to adapt inside it.
That’s what we did at GoodBarber. Before agents, the pull request was already our bottleneck. Code waited for a reviewer longer than it had taken to write. With agents, the number of pull requests exploded, our reading capacity stayed the same, and review delays started being counted in weeks. We spent our days reading code written by a machine, never catching up with the queue.
The Faros AI report of April 2026, on 22,000 developers, counts 67.4% more pull requests to handle per developer per day, so there is nothing local about it.
Reading all that code, I understood that review rested on an assumption we had never had to state: the author will be there tomorrow. They will remember why they made that choice, and they will own the bug if there is one. The whole conversation around a PR rests on that. An agent closes its session and its context is gone.
A January 2026 study of 33,707 agent-authored pull requests, picked up by Addy Osmani, sees it in the data: agents merge small, well-scoped changes fast, and disappear the moment they get subjective feedback.
The pull request assumes an author who will come back. The agent doesn’t come back.
We didn’t manage to adapt review. We removed it. In the spring of 2026 it stopped being mandatory on more and more pull requests, starting with the changes we knew how to undo, the line I described in my piece on the net. As of September 2026, it only remains on changes rated critical, the ones whose release is risky. Everything else goes through a pull request loop between agents, and ships without a human having read the diff.
The first weeks were stressful, I won’t pretend otherwise. But the productivity gain is such that we can afford to handle the misses, provided we assessed beforehand that the risk stayed contained.
Scrum went the same way, only more abruptly. A two-week sprint is tuned to one person’s throughput, and once execution moves to agents, the sprint is empty long before it ends. The “Built for Humans” post tells it as a scene: two weeks of work finished by Tuesday. What limits the team now is what it can specify and verify, and Scrum has no tool to measure that.
At the September 2026 rentrée, we used the calendar to drop our human-designed methods all at once. We’re trying other ways of working right now, and I don’t have a method to recommend yet.
What a tool for machines needs
What’s missing is the tooling that comes next. Bryan Finster published in July 2026 the experiment that gave me my diagnostic. He had agents run the same tasks with and without our disciplines: TDD, pair programming, separating author and reviewer. His result: refactoring improves the code, writing the test first changes nothing. “Refactoring is the mechanism. Test-first ordering is the ceremony.”
The mechanism serves the machine. The ceremony served the human who had to force himself to think before writing. The ceremony is the human part of the tool, and it’s exactly what we hand the agent when we anthropomorphize.
From there, we can say what a tool designed for a machine looks like, because we already know its properties in the negative.
It asks nobody to be present while the machine works, whereas a ritual rests entirely on presence.
It draws the line between what the agent executes and what it proposes on the reversibility of the mistake, not on how confident the model sounds.
It gives the agent a written context it reads before starting, in place of a meeting where someone recites it.
And it verifies at the machine’s production speed, not at a human’s reading speed.
We had to design such a tool, on a small scale, because we had no choice. When AI writes code for someone who isn’t a developer, inside our product, that person has no pull request, no sprint, no reviewer. There was no ritual to lend it.
What we wrote looks like none of our meetings: a line drawn on reversibility, and an access surface declared up front and checked server-side, a choice my CTO Dominique has written about. It’s not much, but it’s designed for the machine, and it was easier to find there than in my own team, where we had a ritual within reach.
The tooling has to be rebuilt
My position is that the next generation of development tools has to be defined for machines, not adapted from ours. A faster pull request or an automated standup keep the human shape, and the human shape is the problem.
We’ll need tools that carry context so nobody has to remember it, that bound damage rather than time, and that verify at the pace the machine produces. I don’t know yet what they will look like. I’m wary of those who already do, they usually sell one.
It’s the same conclusion I reached about frameworks: when producing gets cheap, what holds value is what remains underneath, and for a team that’s the tooling.
If you’re adapting your team to AI, look at what you’re handing it. If it’s a pull request, a sprint and a standup, you’re not adapting to AI. You’re teaching it to pretend to be one of your colleagues.
Our tools compensate for our flaws. Before handing one to a machine, ask whether it has the flaw.
Mathieu Poli — Head of Frontend Engineering @ GoodBarber. I teach and write about frontend engineering, product design, and AI, and everything that happens when the three meet.
X: @hellomathieup · LinkedIn: hellomathieup
Cover photo by nikohoshi on Unsplash.
Top comments (0)