Your agents aren’t your bottleneck. Your collaboration is.

This article was originally written in Dutch.

‍

Building solo with AI, I already knew. In the months before the hackathon I’d put together a handful of products: some step by step, others fully agentic. An accounting application. An energy monitor that replaces a fistful of separate apps. It works, and you get used to it faster than you’d think. You settle into a rhythm: you set the direction, the agent does the work, you correct.

Last week’s hackathon was something else. Not one person with their agents, but a whole team of people who each also had a set of agents. Bigger, more complex, and with far less time. The organizer, incidentally, was on the other side of the world — us being in the same room was pleasant, not a requirement. Our project: a digital gym manager, so that employees of other companies in our building can use our gym.

And right away it ran into the thing most teams scaling AI are going to hit. Not the technology. The collaboration.

Can everyone now do everything?

We started with the classic roles: a Product Owner, a designer, a senior developer, a junior. Familiar ground. Except each of us also had a collection of agents that can, in principle, do everything — backend, frontend, design, copy. The division of labor that used to follow from who could do what suddenly no longer held. If everyone can do everything (or their agents can), how do you carve the work into useful pieces?

That turned out to be the hardest question of the day. We picked two lines of attack. Two people built along the flow: onboarding and generating a personal workout plan. The other two tried to stand up the framework, backend and frontend. The integration didn’t come together: too little time, and two halves that didn’t fit. Continuous integration — merging early and often — is exactly the practice that should have caught this. Only we hadn’t set it up, and with agents producing in an hour what used to take a day, that kind of omission punishes you faster than ever.

A familiar ending, you’ll think. But the reason why is new.

Typing speed was our brake — and it’s gone

A team used to have a natural brake: typing speed. Nobody produced code faster than they could type, and that pace gave you just enough time to keep up, to align, to catch each other. Pairing worked because two people moved at roughly the same speed.

That brake is gone. When two developers with different levels of experience tried to pair, it didn’t work. One lets his agents loose at high speed; the other would rather keep an overview of what exactly is taking shape. That’s not a difference in ability but in need: one is content with “it works”, the other wants to understand what works. It’s just that the agents produce faster than you can discuss it together. And what the experienced developer did barely translates into words: his steering has become intuition, running on years of experience. There’s no shared rhythm left in which you synchronize by default. One walks in seven-league boots; the other prefers smaller steps.

Other teams saw the same. And the teams that did manage all had one thing in common: they’d introduced a new point of synchronization before they set off.

Roles blur, domains don’t

The most surprising part was in the roles. We’d expected the boundaries to blur — and they did, but not the way we thought.

Our designer started in Claude Design and worked from there toward code. The Product Owner delivered not a specification on paper, but a specification in code: a running microservice that showed what he meant. Neither of them had the technical knowledge that used to be required — and yet there stood something alive. The lack of knowledge no longer held them back. That’s the gain.

And immediately the trap. Because they don’t trust that code themselves — and the seniors certainly don’t. “Nice for the demo, but we’d never just push this to production” was a recurring sigh. That’s not technical grumbling: it exposes that speed and trust have become two different things. The developers know better where the risks sit, where an assumption pinches, where it will topple later. The gap between “it works in the demo” and “it can be trusted” hasn’t shrunk — it’s shifted to people who can’t always see it. And it doesn’t close with yet another agent, but with more human-in-the-loop: someone who judges, signs off, takes responsibility. What exactly it takes to get such a demo to production is a story of its own — I’ll come back to that in a later post.

And the barrier to entry? It didn’t drop, it rose — and that’s the uncomfortable part. We hope AI makes the work more accessible, that those with less experience catch up faster. What you see as the pace climbs is the opposite: whoever still has to build up an overview falls further behind the harder the agents run. That’s not a matter of ability but of pace — the system removed the run-up that less experienced people need to grow into it. The threshold shifts from “can you build it” to “can you keep up with it and judge it” — and the second is harder, not easier. Under pressure, moreover, everyone crawled back into their own domain and their own language. That hasn’t changed: the tools are new, the reflex is old.

What the teams who did ship something did differently

Not every team stalled. And the difference wasn’t in better models or faster agents. It was in how they organized the work.

One team went for the critical path first: they got the end-to-end flow working as a bare MVP, and only then built it out. Another team first defined a decent interface between the parts, and only then split into two subteams — so that the two halves were guaranteed to fit. Exactly what our team struggled with. Yet another team chose mob programming: together around one screen, one stream, no divergence. That team shipped something that worked, even with deliberately cheaper AI models — but that’s material for a next post.

I kept my own part small and manageable. I worked with a single agent — my tokens were nearly out, too — chose a microservice and stubbed it first in Python. Then I added elements step by step. My attention went to the substance: is what we’re building correct. That’s how you stay the boss of your agent — you don’t let it dream up a whole system in one leap, because then it makes it irreversibly too complicated.

The senior developer did almost the opposite. He steered a whole platoon of agents at once and watched not the substance but the system dynamics: are they not drifting apart, is there no sprawl, does the whole stay manageable. Two completely different ways to stay in charge — one by keeping the scope small, the other by policing the swarm. What they share is where the human value sat: not in the typing, but in the judging. Is the direction right, is the scope still surveyable, are we not building something no one can maintain later.

Five things we learned

1. Carving up the work is the hardest question of the day. If everyone can do everything — or their agents can — the question isn’t who can build it, but how you carve it into useful pieces that fit together later.
2. Typing speed was our brake and our point of synchronization — and it’s gone. There’s no shared rhythm left in which you synchronize by default; alignment now has to be organized explicitly.
3. Roles blur, domains don’t. Product Owner and designer deliver working code, but they don’t trust that code themselves. The risk assessment stays human work.
4. The barrier to entry goes up, not down. It shifts from “can you build it” to “can you keep up with it and judge it” — and the second is harder, not easier.
5. Staying in charge can be done in more than one way — keeping the scope small or policing the swarm — but always by judging, never by typing.

Collaboration is now the real work

If I boil it all down to one insight: your agents aren’t your bottleneck. Your collaboration is.

The building, the agents can handle. What they can’t handle is the alignment: who does which piece, where the pieces meet, when you stop and ask a human for help. Those used to be implicit agreements you barely had to voice, because typing speed kept you synchronized on its own. Now you have to make them explicit. What used to happen by itself, you now have to organize.

Concretely that means a few things, and they’re less exciting than the technology underneath:

1. Intent before implementation. Agree on what you’re building and where the boundaries lie before an agent writes a single line. A short, shared spec is the new interface between people and between human and machine.
2. Shared rules. Set down which agreements apply — architectural boundaries, what you may and may not install, how you deliver code — so you don’t have to repeat them in every prompt. A kind of handbook for your agents.
3. A backlog that chops the work into connectable pieces. Not “build the app”, but bounded chunks with a clear edge, so that two halves fit together later.
4. Escalation over improvisation. A lost junior asks a question. A lost agent invents something. Agree that an agent stops and hands it to a human the moment it gets stuck, instead of creatively building around the problem.

In practice this needn’t be heavy. Set down the role and boundaries of your agents — for example in an AGENTS.md. Decide the intent of a task before code appears, and put it somewhere everyone can reach, for example a /specs folder. And collect the rules the code must satisfy in one place, for example a /policies folder. A few markdown files are often enough. Call it overhead if you like. But it’s precisely the point of synchronization we lost when typing speed fell away. Not bureaucracy — the new brake.

And don’t reduce it to documents. The point of a spec isn’t the file, it’s the conversation it forces: briefly deciding together what you’re building before four agents run off in four directions. The same goes for the rituals we already had. Pairing and mob programming were long considered expensive — two or three people on one task. Now that typing speed has fallen away as the point of synchronization, they become cheap: they may well be the simplest way to get people back on one rhythm, and to get the senior to share his intuition out loud with those who have less experience. Not process for its own sake — the conversation for the sake of alignment.

The bottom line

It stays human work. Scaling AI in a team is not “putting people in a room and starting the sprint”. The agents take over the typing, but that’s exactly what floats the real work to the surface: choosing direction, keeping scope small, aligning, judging what you dare to trust. That is and stays human.

The good news: a team can discover this perfectly well on its own. You don’t need to buy an expensive framework for it — although, as I write this, there’s already one waiting. SAFe just released “AI-Native SAFe”, announced as the operating model for the AI-native organization, complete with the promise of a “return on AI”. Maybe you’ll need that someday. But don’t start there.

Start with three questions:

1. What is our point of synchronization now that typing speed has fallen away? If the answer is “no idea”, integration becomes your biggest risk.
2. Where does our human value still sit? If everyone can build anything, judging — direction, scope, risk — becomes the scarce good. Are you organizing for that?
3. Does our way of working raise the barrier to entry instead of lowering it? When pace becomes the measure, you lose exactly the people you’ll need tomorrow.

And then do the cheapest and most underrated thing there is: build together with your agents for a day, and hold an honest retro afterwards. That day teaches you more about your own team than any diagram.

‍