The hardest part of working at scale with AI is designing human processes to keep control over what it produces.
Doctolib thus closes its account of an experiment conducted the week of May 18, 2026. The overarching idea: rather than mapping agents onto the working methods of developers, adapt those methods in a synchronous collaboration mode. Three participants — senior engineer, staff engineer, engineering manager — joined from a virtual room, with their screens shared continuously.
GraphRAG and Gemini for Technical Framing
Ahead of the experiment, Doctolib built a knowledge graph drawn from code repositories, documentation, and backlog issues. Each domain was transformed into a local graph, with the entirety then combined into a graph of graphs.
The technical framing occupied the first day. The objective was to minimize meetings. Manual note-taking was forbidden: the team had to rely on Gemini’s transcriptions. During every discussion (30 to 45 minutes per topic depending on complexity), at least one person maintained an active Claude session, with the knowledge graph open. If needed, an external participant could be invited for 10 minutes of Q&A. Claude used the graph and the summaries of the discussions to perform the scoping.
At the end of the day, 4 frames were validated. That pace stood in contrast to the every-two-weeks cadence of the classic asynchronous process.
An Hybrid Approach for Writing Definitions
On the second day, each framing was split into macro-tasks. A half-hour of human work was performed — a deliberate choice to ensure mastery of the subject. Primary rules: avoid micro-tasks, maximize functional isolation, and not reject dependencies.
Once this mapping was completed, the main convergent patterns were codified into reusable skills. Either as knowledge, or as workflows.
The next step was to assign the 13 macro-tasks to draft the definitions. The hybrid approach (writing by a human and by Claude, then reconciliation) yielded the most interesting results.
Once validated (via Google Docs collaboration), the definitions moved into OpenSpec. The outcome was a proposal, a design document, technical specifications, and a list of implementation tasks — all artifacts to be revised and then merged. By the end of the day, 12 out of 13 had, in fact, progressed (the last required a loop that spilled into Day 3).
10 Tasks on 13 Finally Moved into Production
The third and fourth days were devoted to implementation. Each participant opened a new Claude session per task, linked the knowledge graph and the relevant skills, then executed the apply. Between action-by-action supervision and the final PR review, both strategies worked, as Doctolib explained. The choice largely came down to personal style…
A Slack-based canvas helped keep the pipeline synchronized. By the end of the fourth day, 12 of the 13 implementations were validated in the development environment.
Peer review and deployment to staging were on the menu for the 5th day. Topic by topic, in order of dependencies, each PR was examined. The owner explained the changes file by file and ran a local demo. After the team’s approval, Claude performed a final verification against the original specification.
No production deployment… because it was a Friday. The following Monday, 10 of the 13 tasks finally crossed that threshold.
Three Weeks of Work Instead of Six
The backlog that was targeted equated to six weeks of work. Doctolib thus claims a “factor of acceleration of 2x” (three developers for one week equaling three weeks of work). The experiment was not free of bias, he acknowledges. Among other things, external dependencies had been excluded in advance. The team also had enough seniority to make decisions without escalation.
Among the positive takeaways, reviews did not become a bottleneck. The 23 PRs generated stayed open on average for just under 28 hours. The synchronous work assisted. It also fostered internal mastery — including a team member who hadn’t touched the company’s codebase in nine months. Doctolib notes that learning occurred at a pace traditional sprints do not permit.
Automation, Cost, Maintenance… Other Kinds of Challenges
The experiment removed some obstacles but introduced others. For example, “nothing happened automatically,” as Doctolib put it. Each transition (from the summary to the framing, from the task to the spec, etc.) depended on human action. The finding: “Our setup lacked integration and proactivity at every point.” […] We wasted a significant amount of time repeating the same orchestration prompts with the same context.
Cost remains another question. The experiment consumed 1.719 million tokens, for a bill of $1,008. Doctolib concedes not having practiced rightsizing (default models were used). Its knowledge graph, which cost $300, is not reusable. The issue becomes even more pressing given that at scale there is a risk of locking the development workflows into agentic infrastructures.
Scaling up also presents a separate challenge: keeping team synchronization. Here, decision authority was concentrated, the product manager was reachable, and external collaborators could be invited. Recreating this across multiple delivery streams that exploit the same resources is another ballgame.
Doctolib also notes the mental load associated with changing contexts. The experiment covered seven topics. A backlog focused on one or two major themes would probably have increased velocity… and well-being.
Maintenance raises additional issues. By week’s end, the knowledge graph was already partially obsolete. Likewise, the skills, based on an earlier version of the codebase, had to be rewritten mid-experiment. There was no shared rules file and no process for propagating changes.
Paths for a Next Experiment
For the next iteration, Doctolib envisions a one-month window, with a full team and two parallel delivery streams. It plans to reposition the morning meeting to the end of the day and to focus each stream on two major themes per week. This would help limit context switching and detect overlaps earlier. The week would begin on Tuesday, enabling deployment by the end of the week rather than the following Monday.
On the agent-experience front, Doctolib foresees a graph per repo, updated continuously. It intends to produce skills encoding its teams’ best practices. And to automate pipeline transitions with the aid of a remote agent in a sandbox. All while integrating a selection of models.
