Team Developer · für Softwarehäuser & Tech-Teams
Coding Agents wie Claude Code übernehmen einen großen Teil von Implementierung, Tests und Dokumentation. Dadurch werden Stunden frei, aber geliefert wird erst mehr, wenn jemand die Arbeit neu verteilt. Team Developer simuliert Ihr Team vor und nach der KI. Sie sehen, was die KI übernimmt, was als Review zurückkommt, wer zum neuen Engpass wird und welche Übernahmen aus freien Stunden echte Lieferleistung machen.
Der Kernbefund
Die KI vervielfacht die Code-Produktion. Deshalb wandert der Engpass von den Entwicklern zu dem, der spezifiziert und abnimmt.
Im Rechenbeispiel ist das der Requirements Engineer. Mehr Entwickler einzustellen würde die Liefermenge nicht erhöhen. Entscheidend ist, wohin der Engpass in Ihrem Team wandert und wer ihn mittragen kann.
Implementierung, Tests, Dokumentation und Pipelines gehen an die KI.
20 % der Arbeit, die die KI übernimmt, landen als Review und Integration wieder beim Team.
Die Liefermenge hängt jetzt davon ab, wie schnell Stories geschrieben, verfeinert und abgenommen werden.
Ein Team, drei Zustände
Ein fiktives Softwareteam mit neun Personen arbeitet mit Coding Agents bei 70 % KI-Adoption. Wechseln Sie zwischen den drei Zuständen und sehen Sie, wie sich Arbeit, Reserve und Liefermenge für jede Person verändern.
In jedem Zustand stehen 1.280 h je Monat zur Verfügung. Wertbeitrag 4.500 € je Story, Personalkosten 90.400 € je Monat.
Stunden je Monat. Die beiden Testerinnen arbeiten mit halber Stelle (80 h) und sonst im Vertrieb. In Zustand C bleiben bewusst 10 % der Kapazität jeder Person ungeplant.
Was Sie bekommen
Team Developer funktioniert für jedes Team und jedes Szenario. Sie beschreiben Ihr Team: Rollen, Verfügbarkeit, Fähigkeiten, bisherige Aufgaben, Berechtigungen, Wünsche und Kosten. Dann legen Sie Szenarien fest, und der Service rechnet die Folgen durch.
Für jede Aufgabe: welchen Anteil die KI übernehmen kann, wie die Aufgabe danach aussieht und wie viel als Review und Integration zurückkommt.
Beispiel: Aus „Manuelle Regressionstests der UI vor Releases“ wird „Die automatisierte Regressionssuite pflegen“.
Die übrigen Stunden gehen optimiert an Personen, die passen und die nötige Berechtigung haben. Niemand wird dabei überlastet.
Beispiel: Nur 5 Aufgaben wechseln die Zuständigkeit. Alles andere bleibt, wo es ist.
Die Person, deren zusätzliche Stunde am meisten wert wäre. Dazu die Aufgaben, die ihre Zeit füllen, und wer sie übernehmen könnte.
Beispiel: der Requirements Engineer bei 100 % Auslastung, kein Entwickler.
Lernzeit für die übernehmende Person, Anleitung durch den bisherigen Zuständigen und das, was vorher nachgewiesen sein muss.
Beispiel: Carla übernimmt „Backlog mit den Entwicklern verfeinern“ mit 64 h Lernen und 2 h Anleitung.
Eine künftige Rolle für jede Person und die Fähigkeiten, die sie dafür braucht. Sortiert danach, wie viele zugeteilte Stunden davon abhängen.
Beispiel: Fullstack Developer → AI-augmented Product Engineer.
Liefermenge, Personal- und Werkzeugkosten für jedes Szenario. Dazu, welche kleineren Teams die Arbeit noch abdecken würden.
Beispiel: 93 Teamkombinationen geprüft auf Abdeckung, Kapazität und Ergebnis.
Das durchgerechnete Beispiel
Das Team: Lead Developer, Frontend Developer, zwei Fullstack Developer, DevOps Engineer, Project Manager, Requirements Engineer und zwei Testerinnen (Tester) mit halber Stelle aus dem Vertrieb. Heute liefert das Team 24 Stories im Monat.
Fiktives Modell · alle Mengen, Fähigkeiten, Zeiten und Preise sind gesetzte Annahmen, keine gemessenen BetriebsdatenDie größten verbleibenden Aufgaben, zuerst mit unveränderten Zuständigkeiten (B), dann nach der Neuverteilung (C). Die Neuverteilung bestraft jeden Rollenwechsel und verschiebt nur, was den Engpass entlastet.
In Zustand B hat David mit Abstand am meisten Zeit frei: 108 h im Monat. Features, Tests und Dokumentation lassen sich am stärksten automatisieren. Hanna und Ines geben zusammen 54 h im Monat an den Vertrieb zurück.
| Aufgabe | KI-Anteil | B · zuständig | C · verteilt |
|---|---|---|---|
| Features end to end umsetzen (API und UI) | 39 % | Carla 52 h, David 16 h | David 87 h, Carla 9 h |
| REST-APIs und Fachlogik entwerfen und umsetzen | 39 % | Carla 39 h | Carla 55 h |
| Anforderungen in Workshops und Interviews erheben | 11 % | Gustav 36 h | Gustav 50 h |
| Stakeholder-Kommunikation und Steering-Meetings | 8 % | Frida 37 h | Frida 37 h |
| UI-Komponenten und Seiten nach Designs umsetzen | 39 % | Ben 34 h | Ben 48 h |
| User Stories, Akzeptanzkriterien und Spezifikationen schreiben | 31 % | Gustav 33 h | Gustav 47 h |
| Bugs über den ganzen Stack analysieren und beheben | 34 % | Carla 32 h | Carla 21 h, Emil 24 h |
| Manuelle Regressionstests der UI vor Releases | 48 % | Hanna 29 h | Hanna 35 h, David 6 h |
| Backlog mit den Entwicklern verfeinern | 22 % | Gustav 19 h | Carla 23 h, Frida 4 h |
| Systemarchitektur entwerfen und technische Entscheidungen treffen | 17 % | Anna 27 h | Anna 27 h |
| Infrastructure as Code bereitstellen und betreiben | 34 % | Emil 27 h | Emil 27 h |
Der Engpass
160 h verfügbar, 144 h planbar. Vier Aufgaben füllen seine Zeit:
Bei dieser Last erreicht das Team 33,8 Stories im Monat. Die 128 h Reserve des Teams heben seine Grenze nicht auf.
Für jede Option: wie viele Stunden im Monat sie vom Engpass nimmt und wie viel einmaliger Lernaufwand bei der übernehmenden Person anfällt.
| Übernahme | Entlastung | Lernaufwand |
|---|---|---|
| Frida übernimmt „Anforderungen in Workshops und Interviews erheben“ | 50 h/Monat | 12 h |
| Hanna übernimmt „User Stories, Akzeptanzkriterien und Spezifikationen schreiben“ | 47 h/Monat | 116 h |
| Hanna übernimmt „Abnahmetests definieren und gelieferte Features validieren“ | 24 h/Monat | 80 h |
| Ben übernimmt „Prozess- und Datenmodellierung, UI-Mock-ups“ | 20 h/Monat | 60 h |
Zwei, weil beide den Engpass entlasten. Mehr auf einmal würde die Anleitung überfordern, die Gustav dafür geben muss.
Noch offen: Story erklären und Fragen beantworten · zu große Story schneiden · Backlog für den nächsten Sprint bereithalten.
Arbeitsprobe: einen Geschäftsprozess als BPMN-Modell abbilden. Gustav prüft ihn gegen alle drei Anforderungen.
Vom Vorschlag zur Zuordnung. Aufzeichnungen bisheriger Arbeit enthalten keine Nachweise für Aufgaben, die jemand nie ausgeführt hat. Eine Übernahme gilt erst, wenn sie belegt ist:
Jede Aufgabe hat drei beobachtbare Anforderungen, an denen eine Übernahme geprüft wird.
In früheren Arbeitsergebnissen nach Belegen suchen. Jede Anforderung gilt als gefunden, geprüft oder offen.
Ein vorbereiteter Fall, bewertet vom bisherigen Zuständigen.
Schrittweise übergeben und den tatsächlichen Aufwand je Fall nachmessen.
Die Fähigkeiten sind danach sortiert, wie viele zugeteilte Stunden im Monat von ihnen abhängen. Die sechs wichtigsten sind alle neu, und alle lassen sich in Wochen lernen.
93 Teamkombinationen wurden auf Aufgabenabdeckung, Kapazitätsgrenzen und Ergebnis geprüft. Anna ist in allen dabei, weil nur sie die Merge-Freigabe hat.
Im Zielmodell bleiben alle neun. Die neunte Person bringt 3,0 Stories im Monat mehr, das sind 8.950 € Ergebnis nach ihren Personalkosten.
| Team | Stories / Monat | Ergebnis / Monat |
|---|---|---|
| 9 Personen | 33,8 | +60.350 € |
| 8 Personen (ohne Ines) | 30,8 | +51.400 € |
| 7 Personen (ohne Hanna und Ines) | 28,0 | +43.350 € |
| 6 Personen (ohne Ben, Hanna und Ines) | 22,8 | +30.500 € |
Wie gerechnet wird
Das Fachwissen steckt in einem editierbaren Katalog aus Rollen, Aufgabenprototypen, Fähigkeiten und künftigen Rollen. Jede Annahme lässt sich ändern, und der Service zeigt, was daraus folgt.
Jede Rolle hat typische Aufgaben mit Zeitanteilen, die zusammen eins ergeben. Jede Aufgabe hält ihr KI-Potenzial fest und wie sie aussieht, wenn die KI ihren Teil macht. Dazu kommt, ob sie mit der Liefermenge wächst, wie viel Anleitung eine Übernahme braucht, welche Berechtigung nötig ist und welche drei Anforderungen sie hat.
Die KI-Stunden ergeben sich aus Bedarf, KI-Potenzial und Adoption. 20 % davon kommen als Review und Integration zum Team zurück.
Die Passung verbindet semantische Ähnlichkeit von Profil und Aufgabe (Embedding-Modell bge-m3), die Abdeckung der nötigen Fähigkeiten und Erfahrung. Gewünschte Aufgaben bekommen einen Bonus. Eine fehlende Berechtigung, eine abgelehnte Aufgabe oder zu geringe Passung sperren eine Zuordnung.
Ein lineares Programm verteilt die menschlichen Stunden auf die berechtigten Personen. Es maximiert die Passung und bestraft jeden Rollenwechsel und jede unversorgte Stunde. 10 % der Kapazität bleiben ungeplant. Die Reserve wird nicht künstlich gefüllt.
Die Dualwerte der Kapazitätsbedingungen zeigen, wessen zusätzliche Stunde am meisten wert wäre. Der Service nennt dazu die Aufgaben, die die Zeit dieser Person füllen, und wer sie übernehmen könnte.
Jede rollenfremde Zuteilung wird als Übernahme ausgewiesen: von wem an wen, Stunden je Monat, fehlende Fähigkeiten, Lern- und Anleitungsaufwand, belegte oder offene Anforderungen und eine vorgeschlagene Arbeitsprobe.
Worauf die Annahmen beruhen Der Katalog aus Rollen, Aufgabenprototypen und Fähigkeiten ist keine Vermutung darüber, was KI könnte. Er kommt aus drei Jahren Mitarbeit in echten Entwicklungsprojekten und aus der Beobachtung, wie sich Aufgabenbeschreibungen bei den Kunden verändert haben, die wir unterstützt haben. Worauf unsere Erkenntnisse beruhen →
Ehrlich gerechnet
Ein Modell, das nur Vorteile zeigt, taugt nicht als Entscheidungsgrundlage. Diese Grenzen gehören zum Ergebnis. Über sie sollten Sie sprechen, bevor Sie handeln.
Im Beispiel kommen 98 h im Monat als Review zurück.
Bleibt die Menge bei 24 Stories, sinkt das Ergebnis um 1.350 € im Monat, die Kosten der Werkzeuge. Der Gewinn setzt voraus, dass die zusätzliche Liefermenge auch gebraucht wird.
12 Aufgaben haben nur eine berechtigte Person: fünf nur Emil, vier nur Frida, zwei nur Anna, eine nur Ben. Ohne Vertretung ist der Plan fragil.
Der Engpass wandert zur Spezifikation. Zusätzliche Entwickler erhöhen die Liefermenge nicht.
1.760 h Lernen stehen 44.100 € Mehrergebnis im Monat gegenüber. Die Minderleistung während der Einarbeitung ist nicht beziffert.
Ein Szenario zeigt den eingeschwungenen Zustand. Ein Messkreis, der den tatsächlichen Aufwand je Aufgabe erfasst und den Plan korrigiert, fehlt noch.
Kommt Ihnen das bekannt vor?
Fragen
Frei gewordene Stunden werden nicht zu Output, solange alle dieselben Zuständigkeiten behalten.
Personalentscheidungen, ohne zu wissen, wo der Engpass jetzt liegt.
Merge-Freigabe, Produktionszugang und Secrets begrenzen, wer welche Aufgabe übernehmen kann.
Werkzeugkosten, Lernzeit und Mehrleistung stehen selten in derselben Rechnung.
Was Team Developer zeigt
Vor KI, nach KI mit unveränderten Rollen und nach der Neuverteilung. Die ehrliche Zwischenstufe wird sichtbar, nicht versteckt.
Wer die Liefermenge begrenzt, welche Aufgaben seine Zeit füllen und welche Übernahmen ihn entlasten.
Aufgaben mit formaler Berechtigung gehen nur an Personen, die sie haben. Aufgaben mit nur einer berechtigten Person werden markiert.
Wertbeitrag minus Personal- und Werkzeugkosten, dazu der einmalige Lernaufwand, für jede Teamvariante.
Fragen
Die Unsicherheit wächst, wenn niemand sagt, welche Aufgaben sich ändern und welche bleiben.
„Lern mal KI“ ist kein Plan. Es sagt nicht, welche Fähigkeiten Ihre konkreten Aufgaben künftig brauchen.
Neuverteilungen, die übergehen, was jemand machen möchte oder ablehnt, halten selten.
Ein Titel sagt wenig darüber, was jemand wirklich übernehmen kann.
Was Team Developer zeigt
Für jede Aufgabe der KI-Anteil und eine Beschreibung der Arbeit, die bei Menschen bleibt.
Eine vorgeschlagene Rolle für jede Person und die nötigen Fähigkeiten mit Lern- und Coaching-Stunden.
Aufgaben, die jemand lernen möchte, bekommen einen Bonus. Aufgaben, die jemand ablehnt, werden ihm nie zugeteilt.
Beobachtbare Anforderungen, Belege aus bisheriger Arbeit und eine Arbeitsprobe, bevor eine Übernahme gilt.
Über uns
Bei AKENI.AI beschäftigt uns eine Frage: Wie verändert KI die Arbeit von Teams, Aufgabe für Aufgabe und Fähigkeit für Fähigkeit, und was bedeutet das für die Menschen, die sie machen?
Unser Kernteam unter Leitung von Gründer Nils Keßler konzentriert sich auf konzeptionelle Arbeit und Projektmanagement. Wir arbeiten mit einem Netzwerk aus Data Scientists, Machine-Learning-Engineers und Beraterinnen und Beratern für Personalentwicklung. Dabei verbinden wir KI-basierte Werkzeuge mit statistischen Methoden und klassischem Machine Learning.
Team Developer wendet das auf Softwareteams an. Sie bekommen ein Modell Ihres eigenen Teams, das Sie hinterfragen, ändern und neu rechnen können. Die Entscheidungen trifft es nicht für Sie.
In einem kostenlosen Erstgespräch sprechen wir über Ihr Team und seine Aufstellung. Wir zeigen Ihnen auch, welche Angaben die Simulation braucht.
Kontakt
Kein Vertriebsgespräch. Sie sprechen direkt mit dem Gründer über Ihr Team, Ihre Szenarien und darüber, ob die Simulation zu Ihrer Situation passt.
Häufige Fragen
