In brief: Agents write and change code faster than any team can review it, which moves the bottleneck downstream into review, testing and release rather than removing it — and makes the Implementer’s job less about producing code than about controlling what reaches production. This briefing is for engineering, operations and data leads, and for the non-technical leaders who fund and answer for their work. The controlling questions are the same four in every firm: what can the agent reach, under whose identity does it act, is the change reversible, and who owns the outage at 3am.
The Implementer is the first role in this Path whose agents can change something that customers touch. That single fact changes every question: not what the agent produces, but what it may reach, under whose identity, and how fast a wrong move can be undone.
Elif Demir has a prototype and a promise to keep. She works at Bruns & Lehmann — the firm this Path follows, a family-owned Mittelstand manufacturer of dosing pumps in northern Germany, around 420 people, customers across Europe.
The advisory board has funded the service troubleshooting system designed in the Creator briefing. A customer’s plant technician describes a fault at 3am. The system proposes safe next steps. And when it is unsure, it stops and says so.
Elif is the engineering lead who has to make that real. The prototype clicks; nothing behind it exists. The pump specifications live in three places and disagree in two of them. The service history sits in a system bought in 2014. And the promise that the thing will stop when unsure — the one line in Luca’s design that everyone nodded at — is the hardest part of the build, because a system that never says “I don’t know” is considerably easier to write than one that knows when it doesn’t.
She has agents, and they are genuinely fast. That is the problem this briefing is about.
What an Implementer actually holds
The Compass groups the delivery roles of a transformation as Transformers — people, not the neural-network architecture; the difference is exactly the accountability gap this series works. The Implementer builds and integrates: engineers, operations and data teams who turn a decision into something that runs.
What the role holds is not typing. It is architecture — the choices that are expensive to reverse later. Security decisions. The authority to approve a change to production. And the answer to the question every other role asks eventually: when this breaks at 3am, who is called, and what can they do about it?
Where this role starts and stops
The stale picture here is the narrowest of the six: Implementers are the people who write the code. Leaders holding that picture hand over a requirement, wait, and then ask why the result is not what they had in mind. The boundaries on either side of the build are where that goes wrong.
- Deciding what to build is not this role. Direction belongs to the Owner, and the brief belongs to the Creator. An Implementer handed an ambiguous requirement will resolve the ambiguity, because code cannot be ambiguous — and that resolution is a product decision, made by whoever was nearest the keyboard. Vague briefs do not stay vague. They get decided quietly.
- Architecture and security decisions are this role. Organisations often look for a separate security function to carry that risk. The choices that matter — what connects to what, which identity runs where, what can be undone — are made during the build, by the people building.
- Unit and integration tests are this role. Engineers write them as they build, the pipeline runs them on every change, and agents now draft most of them. No quality function produces them, which surprises leaders who assume all testing sits in one place.
- End-to-end tests are shared, and the split is the whole point. The Tester decides which customer journeys are worth protecting. The Implementer builds the automation that runs them. Ask either one alone and you get half of something.
- Whether it goes live is not this role. The Implementer decides how a change can reach production and how quickly it can be pulled back. Whether it should go is the Tester’s gate, and where real risk remains, the Owner’s to accept.
- Running it afterwards is not this role. That belongs to the Maintainer, and the hand-over is a real event with a real artefact. The familiar failure is that no hand-over happens at all, and the person who built the thing is called at 3am for the next three years.
At Bruns & Lehmann’s size, Implementer, Tester and Maintainer are frequently the same two or three people. That is not a problem in itself. It becomes one when nobody says which hat is being worn, because a person approving their own work is not a second opinion. It is the first one, stated twice.
What agents change for this role
Producing code stopped being the constraint. Agents draft, refactor, write tests, generate configuration and explain unfamiliar systems, and they do it at a speed no team can match by hand.
What follows is the pattern every honest account reports. Dropbox’s engineering leadership, describing an internal agent platform that now produces roughly one pull request in twelve, found that acceleration did not remove the work — it moved it downstream into review queues, testing, validation, release coordination and operations, while engineers remained accountable for intent, architecture, quality and release (Dropbox Tech, May 2026 — self-reported). Zalando’s engineers put it more bluntly after two and a half years: AI amplifies good practices and bad ones alike, and teams that let changes grow large found them stalling in review until working habits adjusted (Zalando Engineering, August 2026 — self-reported).
The role’s failure mode follows directly: an action reaches production without a change authority, and cannot easily be undone. Not because anyone was reckless, but because the volume of small, plausible changes outgrew the attention available to check them.
There is a second failure mode that matters more to a non-technical leader than it sounds. The measure of the work quietly changes. Lines produced, tickets closed and pull requests merged all go up; whether the system got better is a different question, and an organisation that starts celebrating the first will stop asking the second.
Where the Implementer’s agents differ from everyone else’s
Every other role in this Path can start with material handed over by hand. This one cannot. An Implementer’s agents work on systems: repositories, pipelines, databases, environments. They need credentials to be useful, which means the access question is not a wall to work around but the design itself.
That inverts the usual order. The Creator explores first and involves engineering later. Here, engineering is involved from the first hour — because the person who would normally be asked to harden the arrangement is the person building it. The discipline that replaces “start small and ask later” is narrower: give the agent the smallest identity that does the job, in the least consequential environment that proves the point, and make every action it takes visible and reversible before letting it near anything customers touch.
The Implementer’s orchestra
Elif’s agents have separated purposes, and every one of them is defined as much by what it may reach as by what it does:
- A code and configuration assistant — drafts and refactors against the repository, works in a branch, and touches nothing outside it.
- A test generator — writes cases from the specification and the interview findings, including the ones nobody wants to write: the 3am path, the ambiguous symptom, the pump model that is no longer sold.
- A documentation and runbook agent — keeps the operating instructions current as the system changes, which is the difference between a system the Maintainer can run and one only Elif understands.
- A dependency and security reviewer — reads what the build pulls in, flags what is unmaintained, out of date or newly vulnerable.
- A deployment-readiness checker — verifies that what is about to ship has passed what it must, against a list a person wrote and can change.
What is deliberately not on this list is an agent that deploys to production on its own judgement. Not because the technology cannot, but because the question “who decided this change should go live” must have a human answer — and in a regulated or safety-adjacent context, a documented one. The pattern worth copying is the order: automation prepares, an agent proposes, a person decides, automation executes what the person approved.
Cost note: five agents means five briefs, five sets of permissions and five things to re-verify when the model, the codebase or the policy changes — and the review load they create lands on the same engineers who were the bottleneck before.
Oversight is a design, not a queue
The instinct when agents start changing systems is to route everything through human approval. It reliably produces the worst of both worlds: the throughput of manual work and the attention of nobody, because a person approving forty changes an hour is not reviewing them.
Zalando built the alternative and published the numbers. Their approval bot rates every change low, medium or high risk against rules derived from the company’s own incident history; roughly a third of changes are auto-approved and lead time to merge fell by 20–40%, while the risky ones get the scrutiny freed up by not pretending to scrutinise the rest (Zalando Engineering, August 2026).
The principle travels to firms with no platform team at all: sort changes by what they can break, not by who made them. A copy fix and a change to how the system decides it is unsure are not the same event and should not pass through the same gate.
European regulation points the same way. The AI Act’s human-oversight duty for high-risk systems is that a person must be able to understand the system, intervene in it and stop it (Article 14) — not that a human must approve every individual action before it takes effect. Whether a given system is high-risk is a question for your own counsel; the design principle is worth borrowing regardless.
Identity is the hard part
Ask a leader what an agent can do and they will describe its purpose. Ask what it can reach and the conversation changes, because an agent inherits whatever its identity is allowed to do, including things nobody intended when the identity was created.
This is the question to ask before any agent touches a system, and it has four parts: which identity does it act under, what can that identity reach, who granted it, and how would we know if it used more than it needed? “It runs under a service account” is the beginning of the answer. Security practitioners have a name for the gap between what a system needs and what it was granted — excessive agency — and it sits in OWASP’s top risks for applications built on language models (OWASP GenAI Security Project).
Large engineering organisations are building for the harder version of this problem, where agents act on behalf of people and hand work to each other: Zalando describes an identity broker intended to capture the delegation chain, so that an action can be traced back through the agent to the person whose authority it borrowed. Adyen lists agentic workflows for integrity risk — anti-money-laundering, know-your-customer, customer risk reviews — as an active research initiative rather than a deployed system (Adyen — research-stage, and worth reading as a signal of where regulated engineering is looking, not as a result).
Neither is a template for a 420-person manufacturer. Both make the same point: the question is not what the agent does, it is whose authority it is spending.
Building the promise: a system that knows when it does not know
Luca’s design says the system stops when it is unsure. Elif has to build that, and it is worth understanding what it costs, because this is where a leader’s expectations usually miss.
A system that always answers is straightforward. A system that recognises the edge of its own competence needs the boundary defined by people: which faults are in scope, which symptoms are ambiguous enough to hand over, which pump models are too old for the documentation to be trusted, and what happens to a case once it stops. None of that is a model setting. It is a set of decisions made by the engineer, the service lead and eventually the Tester who has to prove the stopping works.
Elif’s estimate to the board is two weeks longer than the version that always answers. That two weeks is the difference between a tool that helps a technician at 3am and one that confidently tells them to open the wrong valve.
The questions that travel
Four questions a non-technical leader can ask about any agent working on systems, and the answers to listen for.
- What can it reach, and under whose identity? A good answer names the identity and its limits: “its own account, read-only on service history, write access only to a branch.” “It uses our standard access” is not an answer.
- Is this change reversible, and how fast? Minutes, with a documented step, is an answer. “We would restore from backup” means the answer is hours and somebody’s weekend.
- Who approved this reaching production, and how is that recorded? If the honest answer is that the pipeline approved it, the change authority has moved and nobody decided to move it.
- What happens at 3am, and who is called? If the answer is Elif’s name and only Elif’s name, you have a pilot with a person attached, not a system.
If the Implementer is on your team
Most readers of this briefing do not write code, and lead people who do. The job is not to review the work; it is to make sure the controls exist and are used. Three checks.
- Ask about reach before you ask about speed. Delivery numbers are easy to produce and easy to celebrate. What the agents may touch, under whose identity, is the question that decides how bad a bad week can get.
- Ask what got harder. If agents doubled the output and nothing downstream was strengthened, the queue moved to review and testing and someone is quietly absorbing it. That person will tell you if asked directly.
- Watch for the metric swap. When the reported measure becomes changes shipped rather than problems solved, the organisation has started optimising for the thing it can count.
Leading people who work with agents — the checks, the warning signs, the review cadence, for all six roles — is covered in its own briefing later in this Path.
What Elif hands over
The system goes live in September. What she hands to the Tester is not just working software: it is a list of the cases where the system should stop, the evidence that it does, and the runbook for when it does not. What she hands the Maintainer is a system with a named owner, a documented way to switch it off, and an identity whose reach someone can still explain in six months.
That is the Implementer’s version of the series’ claim. Agents made building faster than reviewing, which does not remove the engineering job so much as sharpen it: what reaches production, under whose authority, and how quickly it can be undone. Those decisions were always the work. They are simply no longer buried under the typing.
Related reading
- The AI-Enabled Teams Path — all fourteen briefings in reading order; previous: the Creator, who designed this system; next: the Tester, who has to prove it stops when it should.
- One Agent, a Suite, or an Agentic Workflow? — the three shapes, and why an orchestra is a suite until it starts acting unattended.
- Delegate, Automate, or Keep Human: The Agent Handoff Map — assigning authority level by level, which is the whole of this role’s discipline.