The 3-people locked in the room — an experimentation

At Doctolib, we are going all-in on AI. Dozens of specialized agents already in production, engineering leaders committing code much more frequently than a year ago, and a clear bet: AI is how we will create more value for health professionals, close the loop on user feedback in minutes, and launch more specialties and countries — faster.

Going all-in is not just plugging agents into our existing way of working. It forces us to rethink the team itself: where the bottlenecks now sit, what a good review looks like, how knowledge spreads, how people grow. Writing code from scratch is no longer the bottleneck — designing the scaffolding around agents is.

The experiment below is one of the ways we are stress-testing that shift.

Disclaimer

As an individual, I currently — and I insist on currently, because the world is changing fast enough that this sentence may not survive the year — don’t trust the “one-man team” piloting a fleet of agents. My personal growth has always come from the exchanges with people: learning from their experience, learning from debate (often in opposition…), and co-designing.

This bias has a strong influence on the way I’m trying to reshape our ways of working. We are putting collaboration between humans back at the heart of the process, not at its periphery.

This article isn’t a manifesto. It’s a way to structure the experiment we are about to run, the assumptions behind it, and the things we expect to learn.

Where we are coming from

For the past months, our default approach has been what I would call AI augmentation: take the existing way of working, identify the “human” time that no longer brings value, and automate it. It works. It also breaks in interesting ways once you scale it across a team.

A few symptoms have become impossible to ignore:

• The PR explosion: When a single developer iterates with an agent, code lands in pull requests at a rate that no review process was designed for. Quality reviews become the bottleneck, or worse — they become rubber stamps.
• The information firehose: The volume of context the team needs to share has grown faster than our ability to share it. Synchronous meetings multiply to keep everyone up to date, and the ones who skip them end up siloed.
• Losing the feel of production: The code looks good in the PR. It passes tests. It ships. And then, weeks later, an edge case nobody had the context to catch shows up in production. Stability and maintainability quietly erode.
• People growth stalls: When one person can do five times more alone, the sharing loop breaks. Pairing becomes a tax instead of a multiplier. The whole team doesn’t accelerate — one person does, and the others slowly fall behind.

Each of these is a different face of the same problem: we are still doing async work, individually, with agents glued on top. The agents got faster. The collaboration around them didn’t.

So we wanted to flip the question. Instead of asking how do we automate more of the current process?, we asked how should the process change now that agents exist?

The hypothesis

The hypothesis behind the experiment is simple to state and uncomfortable to test:

Move parallelism of implementation from people to agents. Move people back from async to synchronous, collaborative work.

Concretely: during the week of 2026–05–18, three of us in my team will lock ourselves in the same (virtual) room for the whole week. One Senior, one Staff, one EM/Lead Architect. Same Google Meet, screens shared, all day, every day.

The agents do the parallel work. The humans do the thinking, the design, the reviews, the rule-writing — together, in real time.

What we expect to gain

I’ll group the expected impacts into three buckets, because that’s how we’ve been framing the trade-offs.

Delivery quality

• Three brains thinking together: Same level of engagement on the same problem at the same time. Design, implementation strategy, validation — all of it benefits.
• Spec-Driven Development (SDD): Dedicated time to research and write specifications, then delegate implementation to the agents while retaining the responsibility of setting the rules and the tests that constrain them. The humans own the contract; the agents fulfill it.
• Triple review: When three people have shared the full context of how a piece of work was scoped, designed, and tested, the review is not a context recovery exercise — it’s an actual review.

People growth through permanent sharing

• The hackathon effect: There is something about being in the same room, with the same objective, that turns work into a game. And people who enjoy their work produce better work. It’s not a sophisticated insight, but it’s a real one.
• Reduced review risk: Three reviewers, all aware of the requirements and concerns. We stop relying on “the one person who happened to be in the meeting”.

Process design for the agent itself

• Reusable assets: Every rule, every skill, every CLAUDE.md snippet we write this week is a durable asset that the next week (and the next team) benefits from. We are not just shipping features — we are building the agent experience.
• Shifting the bottleneck: From manual reviews to test strategy. Test cases are cheaper to maintain than thorough manual reviews at agent-driven scale. This also supports our north-star: “CEO will deploy in production”.
• Increased delivery capacity: If our assumptions hold, the bottlenecks we lift should free up capacity. We plan to reinvest that capacity into Agent Experience (AX) work.
• Better time-to-market: In the worst case, we expect to deliver three dev weeks of work in one calendar week. Currently, one week of implementation takes nearly two weeks to reach production because of meetings and waiting on synchronization. The locked room removes that delay by construction.

And the open questions

I don’t want to pretend we’ve thought of everything. Two questions are still genuinely open:

• What is the impact on the team’s mental load, especially when working on complex design points all day, every day, for a full week?
• How do we handle external dependencies — the moments we need help from outside the room?

We’ll come back to these in the retrospective.

The setup

What we plan to ship

We have lined up a backlog worth 7.5 dev weeks of work to feed the experiment.

Some of these need a real research phase; others are well-scoped enough to attack head-on. The mix matters — it lets us test the loop on both ends of the spectrum.

The rules of the locked room

We’ve kept them stupidly short on purpose:

• As few meetings as possible.
• Everyone in the same (virtual) room, all day.
• Keep agents busy as much as possible.
• All screens shared, all the time, to make discussion and sharing free.

Week organization

The week is structured as a funnel: scope → design → implement → review.

Day 1 — Scoping and Research:Two iteration loops on the five subjects, sequentially. Initial questions, foundational approach, agents working in background to challenge the framings.

Tools:
- raw reference docs
- Graphify to build a Graph RAG per topic
- OpenSpec opsx:explore
- Google Meet transcripts piped through Gemini to capture decisions.

Output: Technical Scoping

Day 2 — Design and Specs: We break the scoping down into tasks. Each task follows the same template:

# Task name
## Short description
## Context
## Implementation details
### Chunk 1 — …
### Chunk N — …

We also define the initial rules the agents will play by.

Tools:
- OpenSpec opsx:propose → opsx:continue
- Claude rules
- Honcho to share memory across the three of us.

Output: detailed tasks, proposal.md, design.md, spec.md

Day 3–4 — Implementation and tests: This is where the loop gets tight: implement, review, add tests, enrich the rules. Then loop. We define contextual skills that two or three of us can share, layering knowledge into the agent rather than into a single person’s head. Cycles involve checking the code, discussing it, correcting it, adding tests, and packaging the resulting skill.

Tools:
- OpenSpec opsx:apply, CLAUDE.md
- Honcho
- a shared skill catalog through solo.io's agentregistry.

Output: Set of Pull Requests

Day 5 — Review and ready to deploy: Final review pass, functional validation, OpenSpec opsx:verify → opsx:archive. The end of the loop is also the beginning of the asset library for next week.

Known biases

I owe the experiment more candor than enthusiasm here. A few things are stacked in our favor:

• No external dependencies left: We pre-solved them. No mid-week blockers from outside the room.
• The room is loaded: One Senior, one Staff, one EM/Lead Architect. We have the full quorum to make decisions without escalating, and we have enough seniority to design well. The experiment does not, on its own, prove that any three people in a room would produce the same outcome.
• Agent Experience (AX) is not yet ready: We don’t have the body of rules, skills, and CLAUDE.md files we wish we had. Part of the week's value is precisely that — building those assets — but it also means the early cycles will be slower than the late ones.
• The team dynamic is strong: People work well together, with clear responsibilities and clear decision boundaries. We are unlikely to deadlock on opinions, which is itself a confounding variable when reading the results.

These biases don’t invalidate the experiment. They define what the experiment can and cannot prove. The honest framing is: this is the best-case configuration for the hypothesis. If it doesn’t work here, the hypothesis is probably wrong. If it does, we still have a lot to learn before we can generalize it.

What I’m actually trying to learn

If I strip the framing down to its core, I’m trying to answer one question:

When agents handle the parallelism, does putting the humans back into deep synchronous collaboration produce more than the same humans working asynchronously with the same agents?

I think it does. I think the review bottleneck, the context decay, the silent erosion of code quality, the slow loss of growth opportunities — all of them are byproducts of a process that was designed for humans coordinating with humans, not humans coordinating with agents.

But thinking it isn’t enough. So we are going to lock the door for a week and find out. I’ll write the retrospective once we open it.