ConclusiveEXP-01iones labUpdated on 20 September 2026
Skills & MCP: equipping eight developers and measuring what changes
The questionDoes shared AI tooling (skills and MCP servers) genuinely improve a team’s productivity and quality, or only that of a few developers who are already convinced?
Verdict
The gain is real and measurable on standard tasks, provided you strictly frame what the agents may do. Without a shared catalogue, everyone reinvents their own rules and quality diverges.
DecisionAdopted for the whole team, with a versioned skills catalogue and MCP servers read-only by default.
- Status
- Conclusive
- Duration
- 8 weeks
- Team
- 8 developers, 1 technical lead
- Stack
- Cursor
- Claude Code
- MCP
- Redmine
- Postgres
- Playwright
- Git
−32%time on standard tasksCRUD, tests, migrations, across 140 tickets
−18%review comments per PRincluding −41% on style and structure
+9%time on complex tasksfirst 4 weeks, then back to balance
23skills in the catalogueafter 8 weeks, 6 removed
01
Context
Every developer on the team already used a coding assistant, each in their own way: personal prompts, rules tucked away in a corner of the repository, different tools. The result: visible individual gains, but impossible to generalise, and code reviews where the same style discrepancies kept appearing from one developer to the next. The lab framed the question differently: what happens when tooling is shared, versioned and measured?
02
What we tested
We built two components and deployed them to the eight developers of a BUILD team on two real client projects, for eight weeks.
- A catalogue of skills versioned in a shared repository: code conventions, migration templates, review procedure, test generation, ticket writing, each documented and reviewed by the lead.
- Five MCP servers connected to our tools: Redmine (reading tickets), Postgres (schema and read-only queries), Playwright (end-to-end tests), project documentation, and Git.
- Two measurement periods: four weeks without the catalogue (everyone with their own tools), four weeks with it, on tickets of comparable complexity classified in advance.
We measured the time spent per ticket (as logged in Redmine) and the number and nature of review comments per pull request, and collected the team’s feelings each week on a simple scale.
03
Results
- −32%
- time on standard tasks
- −18%
- review comments per PR
- +9%
- time on complex tasks (first 4 weeks)
- 7 / 8
- developers who want to keep the tooling
On standard tasks, the gain is clear and consistent. A CRUD screen, a migration, a series of tests: a third less time, and above all a narrowing gap between developers. The developers who were least comfortable with AI at the start are the ones who progressed the most, because the catalogue gave them a framework.
On complex tasks, we lost time at first. In the first four weeks, architecture tickets and subtle fixes took 9% longer: the team tried to get the agent to do what they should have done themselves, then reviewed everything. The gap closed when we explicitly documented the cases in which not to use the agent.
- Review comments on style and structure dropped by 41%. Comments on business logic did not move: the tooling standardises the form, not the substance.
- The read-only Postgres MCP server was the most used: understanding a schema without opening an SQL client saves everyone time.
- Six skills out of twenty-three were removed from the catalogue: too generic, or contradicting a project convention. A catalogue stays alive if it is pruned.
- An attempt at a write-enabled MCP server on Redmine was abandoned after two tickets were modified by mistake. Read-only by default, no exceptions.
“Before, the agent did what I asked. With the catalogue, it does what the team decided. It is less spectacular and a lot more useful.”
04
What we conclude
A team’s AI tooling is not a sum of individual tools, it is a shared convention. The gain comes less from the power of the models than from everyone giving them the same rules, the same access and the same limits. It is a technical lead’s job, not a prompt job.
The adoption cost is real: about three lead-days to build the catalogue, and half a day per developer. It is paid back in under a month on a team of eight. We did, however, see no gain on what makes a senior developer valuable: understanding the need, choosing the architecture, spotting the edge case.
05
What’s next
- The skills catalogue is deployed across all our BUILD and RUN teams, with a monthly review and removal of unused skills.
- MCP servers are read-only by default; any opening to write access goes through a decision by the lead and an isolated branch.
- This protocol now serves as our basis for supporting clients who want to equip their own teams.