R&D transformation with AI agents, one codebase at a time.
Most R&D orgs add agents to a team shape designed for people typing every line. Throughput jumps in one team, stalls in the next, and the org chart stays where it was. The R&D Operating Model, a module of the Agentic SDLC Programme, redesigns the org around how the work runs now: a delivery setup built per codebase first, small pods on top, and a central team that carries every improvement to all of them. It works from about 15 engineers to about 500, on modern code, legacy code, or the usual mix of both.
Build the setup first, per codebase
Every codebase climbs the same four readiness levels before a team commits to more throughput on it.
- Level 1PrimedAgents can find their way around: context, written conventions, a dependency map, workflow tooling.
- Level 2VerifiableAgents can check their own work: a green pipeline, fast regression tests, characterisation tests on the paths that carry the revenue.
- Level 3ProducibleSpecs flow from the tracker to the agents, a second model reviews, and review depth follows how much a change can break.Teams commit to throughput from here
- Level 4CompoundingLessons from each run turn into reusable skills, and you can see which ones actually get reused.
A team commits to throughput once its codebase reaches level 3. Earlier than that, the number would measure the setup and say little about the team. The levels describe a codebase; the L0-L4 maturity model describes the org as a whole, and a single org usually has codebases at several levels.
Pods of three to five, one central team, a lab inside it
- Spec leadDecides what gets built and writes it down.
- Builders · 2-4Run the agents.
- Review leadNamed. Owns what merges.
Work runs in pods of three to five people. Where a mistake would be expensive, the pod gets verification built in. Pods have no managers.
One small platform team owns the shared setup: agent tooling, the pipeline and its gates, the skills library, review routing and the spec pipeline. It stays small, and grows when the legacy share is high, because legacy codebases need more setup work.
- Lab · exploreOne person runs rough, fast experiments with new models and agent capabilities against your own delivery process, and throws most of them away.
- Lab · hardenAnother hardens the winners into skills and tooling.
Because the lab sits in the central team, one good result reaches the whole org.
Convert the roles you have
- QAVerification engineers who build the test tooling
- Product managersSpec leads who own the spec queue
- ManagersA few people leads, plus review leads and AI champions
Where the org needs to get smaller, attrition and hiring freezes do it, without rounds of layoffs, and the pod model is never announced together with job cuts. Juniors stay protected. They are your senior engineers in a few years.
Kanban, capped by review
- Idea
- Spec
- Plan review
- Implementation
- Verification
- Merge
Scrum ceremonies give way to a flow. The spec is the unit of work, and it is ready only when it carries acceptance tests. Work moves from idea to spec, to a second model reviewing the plan, to implementation, verification and merge.
Work in progress is capped by how much your reviewers can actually review, because that is where agent-speed work piles up. Standups and sprint planning go. The demo stays, and so does a monthly retro, which writes its findings back into the skills.
Measured per team
Each team is read on complexity-adjusted velocity against a baseline locked before anything changes, next to quality and cost. A few operating signals sit beside that: how much human work each use case still needs, which skills get reused, and the readiness level of each codebase.
Individual performance stays out of the numbers. Ticket counts are never the target.
Legacy, modern, or both
On modern code the setup is the base from day one, and pods can reach level 2 or 3 within weeks. A tested monolith first gets its tests to level 2, then pods move onto it. Deep legacy, decades old with little testing, starts with a quarter spent only on the setup: characterisation tests, regression runs brought from days towards hours, and the knowledge of key maintainers written down. None of it gets a big-bang rewrite. Legacy code with no strategic future stays at level 1 and gets maintained.
For a mixed estate the order is:
- 1The most ready codebase firstAs the template.
- 2Greenfield work on top of it
- 3Then the tested estates
- 4Deep legacy lastWith its characterisation work started early and in parallel.
Willing teams go first. Moving the legacy core itself onto new technology is a separate engagement, Legacy Migration.
A fixed fee by R&D head-count
- About 15-50 engineersCHF 50-80k
- 50-150 engineersCHF 80-150k
- 150-500 engineersfrom CHF 150k, quoted per org
How sure I am, and what is public
This is the setup I would build for any R&D org today. Parts of it rest on practitioner reports more than on controlled studies. Careful measurements of per-engineer gains come in well below the vendor headlines, and review is the bottleneck that keeps moving. The sizing gets calibrated in each engagement.
The tooling is public. Flow-Next, the open-source workflow I build and use in engagements, ships the pieces this setup depends on.
- 8.2Product owners and business analysts can run their part of a spec through a plain-language interview without an engineer driving.
- 8.3The review panel can run one reviewer at a time on local models or rate-limited providers.
- 8.5A review focus can be set per task.
- 8.5.2The model you name for implementation is the model that runs it.
Common questions
What does it cost?
The R&D Operating Model is a fixed fee by R&D head-count: about 15-50 engineers CHF 50-80k; 50-150 engineers CHF 80-150k; 150-500 engineers from CHF 150k, quoted per org. Prices exclude VAT. Most orgs start with the SDLC Diagnostic (CHF 15-25k), which also scores where each codebase sits on the readiness levels.
How does this relate to the Code Factory Build?
Both are modules of the Agentic SDLC Programme. The Code Factory Build sets up the factory with one lead team. The R&D Operating Model redesigns the org around it across every codebase: pods, the central team, roles and flow. Group Rollout then carries the result to the other companies in a group.
Does it work for a team of 20?
Yes. At that size the central team is a part-time role held by builders, and the lab is two hats worn by the same people. The model holds up to about 500 engineers, grouped into product lines.
Will people lose their jobs?
The plan converts roles. Where headcount needs to come down, attrition and hiring freezes carry it, juniors are protected, and the new team shape is never tied to a layoff announcement.
Do our teams have to switch tools?
No. A team on Cursor keeps Cursor; a team on Claude Code keeps that. The readiness levels, the pod shape and the review rules are what get shared.
How do you measure whether it worked?
Per team, against a baseline locked before the change: complexity-adjusted velocity, quality and cost, read together. A throughput gain bought with escaped defects counts as a loss.
Start with one call, then a diagnostic or a scoping.
We go through where your R&D org stands, which codebases are ready, and whether the programme or a single module is the right first step.