Picture a Monday with your development team. One colleague demonstrates a feature she built with Claude Code. Another already uses Codex to add tests. Someone else asks which tools are actually approved. The demos make you want to do more. But as the team lead, you are left with a question: how does this become a way of working the whole team can rely on?
The answer starts neither with another oversight meeting nor with telling everyone to work twice as fast. You do not have to become the best prompt writer in the room, either. Your job is to create conditions in which people can deliver good results with agents: clear goals, appropriate autonomy and a fair understanding of what good work looks like.
The licenses are bought. The working agreement is missing.
Within its configured permissions, a coding agent can edit files, run tools and continue working on a task. That puts it directly inside the development process. Choosing a tool therefore affects collaboration too: who defines the task, who answers business questions and who judges the result?
The 2025 DORA Report describes AI as an amplifier of existing organizational strengths and weaknesses. My practical conclusion: if your team was already waiting for decisions before agents arrived, another license will not remove that wait.
Before comparing the next set of tools, ask something specific: Which work should become noticeably easier for our team or our users? It might be overdue test coverage or an internal feature that never made it to the top of the queue. That benefit is a better starting point than a blanket target for the share of AI-generated code.
A concrete example: exporting from a customer portal
Take a straightforward case: customers should be able to export their completed cases to a file. Support currently assembles those files manually. An agent can prepare the download button, server-side processing and tests. This sounds like a useful pilot because the benefit is tangible and the result can be demonstrated.
But a completed file does not answer which cases a customer may see, whether internal notes belong in the export or what should happen with large datasets. Those questions belong in the brief. They do not necessarily need a manager, but they do need an available person with authority to decide.
For this pilot, the agreement might be: the business owner decides the export's contents and visibility. A developer owns implementation. Access controls receive a technical second check. Release follows the existing approval process. If one person fills several roles, make that explicit too. The team then knows whom to ask without escalating every detail to management.
Autonomy needs a clear brief
The first export task can deliberately stay small: completed cases belonging to the signed-in customer, a defined set of fields and an initial preview using synthetic test data. No new billing, no changes to sign-in, no release. Within that boundary, the team may work independently with the agent.
This is moving from the broad goal to the details, not micromanagement. First agree on the intended user outcome. Then the team and agent break the work into small, checkable steps. The agent can propose technical approaches and expose ambiguities. Business rules are not silently delegated to it.
Three understandable categories are enough to start:
- Work independently within the agreed scope. For example, implement the preview and add tests using approved test data.
- Ask before expanding the scope. For example, when the agent proposes an additional service, new data fields or changes to the access model.
- Act only after explicit approval. For example, changes to production data, paid purchases or publication outside the agreed workflow.
One important distinction: an instruction in a chat is not a technical access restriction. Actual permissions, allowed tools and environments must match these rules. The team should coordinate the implications for your systems with the relevant technical and organizational owners.
Review according to risk, not line count
As a manager, you do not have to perform a line-by-line code review. Equally, passing tests do not replace checking the intended behavior. In the export example, the crucial question is not how elegantly the agent built the download, but whether customer A receives only customer A's permitted data.
The team should automate that check and demonstrate the actual user journey. Oversized files, missing permissions and technical failures belong in the checks too. The depth of additional code review depends on the change: button copy deserves different scrutiny from the rule deciding which customer data is released.
Your contribution is to make time for those checks and clarify ownership. If every small change lands with the same experienced colleague, that person becomes a bottleneck. Smaller tasks, shared knowledge and more targeted checks will help more than starting additional agents in parallel.
Make expertise shareable
A team gains little if only one person knows how to work effectively with the agent. Ask for more than the next impressive demo: how was the task bounded, where did someone intervene and what was discarded? The detour belongs in the story too.
A short joint walkthrough of a real task can be enough. Useful rules and decisions then go into the project documentation. The team does not need to archive every chat. It needs to preserve the knowledge the next person will need.
For junior developers in particular, both banning AI and judging them only by the finished result would miss an opportunity. Ask them to explain the user journey, predict a failure case and check their reasoning with an experienced colleague. An agent can support learning; the team must provide space for questions and feedback.
That also calls for an honest statement about the purpose of adoption. If every reported time saving immediately becomes the next performance target, people have little reason to speak openly about successes and difficulties. Agree whether the first goal is to reduce support work, improve testing or tackle features that have been waiting.
Faster implementation is only half the measurement
In our customer portal, the number of generated lines is not especially interesting. What matters is whether customers can get their own exports and whether support work actually falls. I would keep track of four questions:
- Does the result reach the user sooner? Look at time from a clarified brief to a usable feature, including waiting and review.
- How much rework follows? Include corrections and failures after the initial implementation, not just the speed of the demo.
- What does the full workflow cost? Include tools, human working time, assistance and operations.
- Does it achieve the intended benefit? Here that means successful exports and fewer manual support requests, not merely clicks on the new button.
Compare similar tasks and record the differences. A new export feature and a fix to a long-established billing system are not a fair comparison. A small pilot provides direction, not scientific proof of a fixed productivity multiplier.
METR's February 2026 update explains some of the difficulty: selection of participating developers and tasks, as well as parallel agent work, complicated interpretation of its results. My recommendation for managers is therefore to examine your actual workflow rather than turn an external percentage into a performance target for everyone.
A pilot that leaves you able to decide
I would start with a manageable period, such as four weeks. That is a working timeframe, not a delivery or success guarantee. For the export, the sequence could look like this:
- Clarify the starting point and the brief. Understand current support effort, define permitted data, name owners and agree on a small initial scope.
- Build one complete user journey. Get from the export request to the file in a safe preview. Resolve open decisions promptly instead of starting more features on the side.
- Check together and share the knowledge. Test permissions and failure cases, walk through the behavior with a second person and document important decisions.
- Assess the result and choose the next step. If a limited release has been approved, observe early use. Otherwise, test with representative users in the preview and explicitly note the production evidence still missing.
You can then decide to expand, adjust the workflow or improve a prerequisite first. “The tool helps, but our questions sit unanswered for three days” is a useful result too. It tells you where leadership can make a real difference.
What I take from working with agents
At Entwicklerherz, I use coding agents to build and maintain my own platforms: from breaking down ideas to interfaces, features, tests and ongoing maintenance. What excites me is how quickly an idea can become something you can actually try and improve.
My experience building those products is not a blanket productivity promise for someone else's team. What can transfer is the approach: make the intended outcome tangible, define manageable tasks, learn from the running product and record important decisions. Leadership creates the conditions and makes sure any time gained goes where it matters.
Progress is not having more agents running. It is the team reliably delivering something valuable that used to remain out of reach.
Want to make this concrete for your team? The one-day Entwicklerherz workshop “AI agents in the development team: Lead, decide and own the results” helps you prepare an initial adoption plan with responsibilities, approval rules and success criteria. Delivered in German, live online or in-house; dates and pricing on request. Ask about the leadership workshop.