When I read McKinsey's Rewiring software delivery for the agentic era, I did not see a distant vision of the future. I recognised our own way of building the 3R Platform.
McKinsey opens with a product owner reviewing what AI agents completed overnight. Requirements have been refined, architectural choices checked, code written and tested, and the open decisions are ready for human judgement. No one worked late. The agents carried out the execution.
The paper cites threefold to fivefold productivity improvements and a reduction of about sixty per cent in average team size in early implementations. We do not have a controlled baseline that would allow us to claim such figures for 3R. Yet we fully recognise the mechanism underneath. Our development speed does not come from a single, better coding assistant. It comes from a development model designed around collaboration between people and agents.
For us, agentic software development is not an experiment alongside building the platform. It is how we build the platform.
A ticket becomes an executable work package
Our development cycle does not begin with a loose prompt to build a feature. A request first becomes a clearly scoped GitHub ticket containing the desired outcome, acceptance criteria, expected impact and the evidence that will later show whether the problem has actually been solved.
That difference may seem small, but it determines almost everything that follows. An agent can only work autonomously when the input is sufficiently clear and structured. A vague idea produces code more quickly, but not necessarily the right code. A good work package gives the agent a problem to solve, boundaries within which it may act and a testable end point.
From there, an orchestration layer takes over. Depending on the task, it is sent to Codex Cloud, a temporary development worker in AWS or an agent on a local machine. Several tasks can run concurrently in separate work threads. The workers read the same repository instructions, locate the relevant code and each work on their own branch. They run the appropriate checks, record their changes and open a draft pull request.
For us, this is the practical equivalent of McKinsey's agentic factory. A person no longer has to write every line of code or coordinate every technical handover manually. The system turns a clear product question into a first, verifiable solution.
The chain does not stop when the code has been written
A coding agent opening a pull request does not yet amount to an agentic development model. Without the rest of the chain, all you get is uncertainty produced more quickly.
At 3R, implementation is therefore only one step. The agent first runs fast technical checks. GitHub Actions then takes over the heavier verification. Depending on the change, the solution goes through focused or complete tests, including browser tests across the platform's different roles and checks for database security and tenant isolation.
For visible changes, we also create a slowed-down screen recording. This allows us to inspect a new user flow while other tests are still running. We do not have to wait until the end of the technical cycle to judge whether the solution feels understandable in practice.
At the same time, an independent agent examines the code. It checks not only whether the change appears technically valid, but also whether it introduces side effects, security risks or scenarios that are not fully covered. Findings go back to the same development worker. Only after the corrections does the complete relevant test suite run again against the final version.
This is an important difference from conventional AI-assisted programming. We do not use an agent that writes code and then approves its own result. Implementation, testing, independent review and human judgement are separate responsibilities within one continuous chain.
People do not disappear, their work shifts
McKinsey describes how human roles move from producing artefacts to designing and improving the system that produces them. That is exactly what we are experiencing while building 3R.
The bottleneck is increasingly no longer the ability to write a component, database function or test. The real questions sit before and after that work. We need to establish which problem we are solving, whether the solution fits the product direction, which exceptions matter and which risks remain acceptable. Something that is technically correct must also be genuinely good enough to become part of the product.
Those decisions remain with us. Agents may analyse a ticket, write code and tests, propose an initial selection of regression tests and process findings. They may not decide for themselves that their work is ready to be merged. Every pull request remains a draft until Johan or Vincent has explicitly approved the current version. If an agent changes anything afterwards, that approval becomes invalid and the final review starts again.
That is not a brake on autonomy. It is what makes autonomy usable. Agents have considerable freedom within the work package, while product direction, high-impact architectural choices and final acceptance remain human responsibilities.
Speed requires more discipline, not less
The temptation in AI development is to focus mainly on the volume of code produced. That is the least interesting measure. Agents can also build the wrong solution remarkably quickly.
The faster the execution, the more important the quality of the surrounding system becomes. That is why our repository contains more than application code. It also contains instructions for development agents, task-specific procedures, testing contracts, security rules, decision criteria and recovery procedures. That knowledge is maintained alongside the product.
When something goes wrong, we do not merely repair that single error. We also examine why the development system allowed it. The cause may be missing context, an ambiguous acceptance criterion, an unsafe assumption, a missing test or an unclear handover between implementation and control. The correction then belongs not only in the code, but also in the instructions, test suite or procedure used by the next agent.
This connects directly with McKinsey's case for a knowledge infrastructure. In our practice, the repository is not merely where the source code lives. It is also the shared memory of the development team, both human and digital. New agents do not have to learn from scratch how 3R is built. They receive the current rules, patterns and lessons when they begin a task.
The handovers themselves have become software
Traditional software development contains many human handovers. Someone writes an analysis, a developer interprets it, a tester reconstructs the intent and a product owner later tries to determine whether the result is correct. Meaning can be lost at every transition.
In our agentic development chain, those handovers are designed explicitly. The ticket contains the problem and acceptance criteria. The development worker delivers code, test results and a draft pull request. The test environment ties its evidence to the precise code version. The independent review agent reports concrete findings. The screen recording shows what the user will actually see. In the end, the human receives one verifiable decision package rather than a folder full of separate technical artefacts.
Even orchestration has become a separate role. An agent tracks which task belongs to which ticket, which code version was tested, whether the independent review has been completed and whether the human approval is still valid. It can follow up work and return corrections to the same context, but it does not quietly write the missing code itself or approve anything on our behalf.
This may be the greatest shift. We are not only automating programming work. We are also designing collaboration, evidence and decision points as parts of the development system.
What we are still learning
Our approach is not a finished factory. It is a product under development in its own right.
We are learning how best to divide tasks without losing coherence. We are working out which checks belong locally, in the cloud or in GitHub Actions. We have adapted the testing infrastructure so several agents can work safely in parallel without disrupting one another's environments. We keep refining when an agent may proceed independently and when an architectural or data-related choice requires human alignment first.
The costs of autonomy are also becoming more visible. Deploying more agents does not automatically produce more progress. Poor orchestration causes duplicate work, competing changes and unnecessary testing cycles. A fast implementation based on the wrong product assumption still costs time. Agentic software development does not remove the need for product discipline. It merely punishes its absence more quickly.
That is precisely why I find the McKinsey paper so recognisable. The authors do not argue that organisations should simply deploy more agents. They argue that the entire development structure must be redesigned. Requirements, knowledge, architecture, testing, control and human roles have to work as one system.
The real advantage lies in the development model
The 3R Platform is being built by a small core team surrounded by a growing digital development team. This allows us to work on product functionality, data protection, tests, documentation and operational tooling at the same time, without first building a conventional team structure for every specialism.
The value lies in more than speed. We are building an institutional memory in which every correction can improve the system. We can show changes early, test them broadly and have them reviewed with purpose. Human attention can move to the places where it adds most value: product direction, user understanding, architecture and final responsibility.
That makes the way we build 3R at least as interesting to me as the features inside the platform. We advise organisations to redesign work around people and digital colleagues. In developing our own product, we experience every day what that actually demands.
Agentic software development is therefore not merely a technology we use to try to build 3R faster. It is a new operating model that we are discovering, delimiting and improving ourselves. The code is its visible result. The real innovation lies in the system that produces that code.