Team Developer · for software companies & tech teams
Coding agents like Claude Code take over a large share of implementation, tests and documentation. Hours get freed, but nothing is delivered faster until someone reassigns the work. Team Developer simulates your team before and after AI. It shows what the agents take over, what comes back as review, who becomes the new bottleneck, and which task takeovers turn freed hours into delivered work.
The key finding
AI multiplies code production. The bottleneck therefore moves from the developers to whoever specifies and accepts the work.
In our worked example that person is the requirements engineer. Hiring more developers would not increase what the team delivers. You need to know where the bottleneck moves in your team, and who can help carry it.
Implementation, tests, documentation and pipelines shift to AI.
20% of the work AI takes over returns as human review and integration.
Delivery now depends on how fast stories are defined, refined and accepted.
Three states of one team
A fictional nine-person software team working with coding agents at 70% adoption. Switch between the three states to see how the work, reserve and output change for each person.
1,280 h available per month in every state. €4,500 value contribution per story, €90,400 staff cost per month.
Hours per month. Two testers work half-time (80 h) and otherwise work in sales. In state C, 10% of each person's capacity stays unplanned on purpose.
What you get
Team Developer works for any team and any scenario. You describe your team: roles, availability, skills, past tasks, permissions, willingness and cost. Then you define scenarios, and the service calculates the consequences.
For every task: the share AI can take over, what the task looks like afterwards, and how much comes back as review and integration.
Example: “Manual regression testing of the UI before releases” becomes “Maintain the automated regression suite”.
An optimised assignment of the remaining hours to the people who fit and are allowed to do the work, without overloading anyone.
Example: only 5 tasks change owner. Everything else stays where it is.
The person whose extra hour would be worth the most, the tasks that fill their time, and who could take those tasks over.
Example: the requirements engineer at 100% utilisation, not a developer.
Learning hours for the person taking over, guidance hours from the previous owner, and what has to be proven before a takeover counts.
Example: Carla takes over “Refine the backlog with developers” with 64 h learning, 2 h guidance.
A future role for every person, plus the skills they need for it. Skills are ranked by how many assigned hours depend on them.
Example: Fullstack Developer → AI-augmented Product Engineer.
Delivered output, staff cost and tool cost for each scenario. It also shows which smaller teams could still cover the work.
Example: 93 team combinations checked for coverage, capacity and result.
The worked example
The team: a Lead Developer, a Frontend Developer, two Fullstack Developers, a DevOps Engineer, a Project Manager, a Requirements Engineer and two half-time Testers from sales. Today the team delivers 24 stories per month.
Fictional model · all quantities, skills, times and prices are set assumptions, not measured dataThese are the largest remaining human tasks, first with responsibilities unchanged (B) and then after redistribution (C). The redistribution penalises every change of role. It only moves work that relieves the bottleneck.
In state B, David has the most free time by far: 108 h a month. Features, tests and documentation are the most automatable work. Hanna and Ines together hand 54 h a month back to sales.
| Task | AI share | B · owner | C · distributed |
|---|---|---|---|
| Implement features end to end (API and UI) | 39% | Carla 52 h, David 16 h | David 87 h, Carla 9 h |
| Design and implement REST APIs and business logic | 39% | Carla 39 h | Carla 55 h |
| Elicit requirements in workshops and interviews | 11% | Gustav 36 h | Gustav 50 h |
| Stakeholder communication and steering meetings | 8% | Frida 37 h | Frida 37 h |
| Implement UI components and pages from designs | 39% | Ben 34 h | Ben 48 h |
| Write user stories, acceptance criteria and specifications | 31% | Gustav 33 h | Gustav 47 h |
| Analyse and fix bugs across the stack | 34% | Carla 32 h | Carla 21 h, Emil 24 h |
| Manual regression testing of the UI before releases | 48% | Hanna 29 h | Hanna 35 h, David 6 h |
| Refine the backlog with developers | 22% | Gustav 19 h | Carla 23 h, Frida 4 h |
| Design system architecture and make technical decisions | 17% | Anna 27 h | Anna 27 h |
| Provision and operate infrastructure as code | 34% | Emil 27 h | Emil 27 h |
The bottleneck
160 h available, 144 h plannable. Four tasks fill his time:
At this load the team reaches 33.8 stories per month. The team's 128 h of reserve cannot lift Gustav's limit.
Each option shows how many hours per month it takes off the bottleneck, and the one-off learning effort for the person taking over.
| Takeover | Relief | Learning |
|---|---|---|
| Frida takes over “Elicit requirements in workshops and interviews” | 50 h/month | 12 h |
| Hanna takes over “Write user stories, acceptance criteria and specifications” | 47 h/month | 116 h |
| Hanna takes over “Define acceptance tests and validate delivered features” | 24 h/month | 80 h |
| Ben takes over “Process and data modelling, UI mock-ups” | 20 h/month | 60 h |
The pilot has two takeovers because both relieve the bottleneck. Starting more at once would overload the guidance Gustav has to give.
Still open: explain a story and answer questions · split a story that is too large · keep the backlog ready for the next sprint.
Work sample: model one business process in BPMN. Gustav checks it against all three requirements.
From suggestion to assignment. Records of past work contain no evidence for tasks someone has never done. A takeover only counts once it has been proven:
Every task has three observable requirements that a takeover must meet.
Search earlier work results for evidence. Each requirement is marked found, tested or open.
A prepared case, assessed by the previous owner of the task.
Hand over step by step and measure the actual effort per case.
Skills are ranked by the number of assigned hours per month that depend on them. The six most important skills are all new, and all can be learned in weeks.
93 team combinations were checked for task coverage, capacity limits and result. Anna appears in every one, because she is the only person with merge approval.
In the target model all nine stay. The ninth person adds 3.0 stories per month, which is €8,950 of result after her staff cost.
| Team | Stories / month | Result / month |
|---|---|---|
| 9 people | 33.8 | +€60,350 |
| 8 people (without Ines) | 30.8 | +€51,400 |
| 7 people (without Hanna and Ines) | 28.0 | +€43,350 |
| 6 people (without Ben, Hanna and Ines) | 22.8 | +€30,500 |
How it is calculated
The domain knowledge lives in an editable catalog of roles, task prototypes, skills and future roles. Every assumption can be adjusted, and the service shows what each change leads to.
Each role has typical tasks with time shares that add up to one. Every task records its AI potential and what it looks like once AI does its part. It also records whether it grows with delivery volume, how much guidance a takeover needs, the formal permission it requires, and three observable requirements.
AI hours come from demand, AI potential and adoption. 20% of those hours come back as human review and integration.
The fit combines semantic similarity of profile and task (embedding model bge-m3), skill coverage and experience. People get a bonus for tasks they want. A missing permission, a refused task or too little fit blocks an assignment.
A linear programme assigns the human hours to eligible people. It maximises fit and penalises every change of role and every uncovered hour. 10% of capacity stays unplanned. The reserve is not filled artificially.
The dual values of the capacity constraints show whose extra hour would be worth the most. The service then lists the tasks that fill that person's time and who could take them over.
Every assignment outside a person's role is listed as a takeover. Each one shows from whom and to whom, hours per month, missing skills, learning and guidance cost, evidence found or open, and a suggested work sample.
Where the assumptions come from The catalog of roles, task prototypes and skills is not a guess at what AI might do. It comes from three years inside real development projects and from how job descriptions changed at the clients we supported. What our insights are based on →
Honest by design
A model that only shows upside is not worth using. These limitations are part of the result, and they are the points to discuss before you act.
98 h per month come back as review in the example.
If output stays at 24 stories, the result drops by €1,350 per month, which is the cost of the tools. The gain depends on the extra output actually being wanted.
12 tasks have only one eligible person: five only Emil, four only Frida, two only Anna, one only Ben. Without deputies the plan is fragile.
The bottleneck moves to specification. Hiring developers does not raise the output.
1,760 h of learning stand against €44,100 more result per month. The reduced output during onboarding is not quantified.
A scenario shows the end state. A measurement loop that records the actual effort per task and corrects the plan is not built yet.
Do you recognise this?
Questions
Freed hours don't turn into output as long as everyone keeps the same responsibilities.
Headcount decisions made without knowing where the constraint now sits.
Merge approval, production access and secrets limit who can take over which task.
Tool cost, learning time and extra output rarely end up in the same calculation.
What Team Developer shows
Before AI, after AI with unchanged roles, and after redistribution. The honest middle state is visible, not hidden.
Who limits delivery, which tasks fill their time, and which takeovers would relieve them.
Tasks that need a formal permission only go to people who have it. Tasks with a single eligible person are flagged.
Value contribution minus staff cost and tool cost, plus the one-off learning effort, for every team variant.
Questions
Uncertainty grows when nobody says which tasks change and which stay.
“Learn AI” is not a plan. It doesn't say which skills your actual tasks will need.
Reassignments that ignore what people want to do, or refuse to do, rarely hold.
Job titles say little about what someone can really take over.
What Team Developer shows
For every task: the AI share and a description of the work that remains for people.
A suggested role for every person, and the skills it needs with their learning and coaching hours.
Tasks someone wants to learn get a bonus. Tasks someone refuses are never assigned to them.
Observable requirements, evidence from past work, and a work sample before any takeover becomes real.
About us
At AKENI.AI we work on one question: how AI changes the work of teams, task by task and skill by skill, and what that means for the people doing it.
Our core team is led by founder Nils Keßler and focuses on conceptual work and project management. We work with a network of data scientists, machine learning engineers and workforce development consultants. We combine AI-based tools with statistical methods and classical machine learning.
Team Developer applies this to software teams. It gives you a model of your own team that you can question, change and recalculate. It does not replace your decisions.
In a free first conversation we'll talk about your team and its setup. We'll also show you which information the simulation needs.
Get in touch
No sales call. You speak directly with the founder about your team, your scenarios and whether the simulation fits your situation.
FAQ
