Stell dir einen Montag im Entwicklungsteam vor: Eine Kollegin zeigt eine Funktion, die sie mit Claude Code gebaut hat. Ein Kollege lässt Codex bereits Tests ergänzen. Jemand anderes fragt, welche Werkzeuge überhaupt erlaubt sind. Die Demos machen Lust auf mehr. Nur eine Frage bleibt an dir als Teamverantwortlichem hängen: Wie wird daraus eine Arbeitsweise, auf die sich das ganze Team verlassen kann?
Die Antwort beginnt weder mit einem zusätzlichen Kontrollmeeting noch mit dem Auftrag, jetzt bitte alle doppelt so schnell zu arbeiten. Du musst auch nicht der beste Prompt-Schreiber im Raum werden. Deine Aufgabe ist, Bedingungen zu schaffen, unter denen Menschen mit Agenten gute Ergebnisse liefern können: klare Ziele, passende Freiheiten und eine faire Vorstellung davon, was gute Arbeit ausmacht.
Die Lizenz ist gekauft. Die Arbeitsweise fehlt.
Ein Coding-Agent kann innerhalb seiner eingerichteten Zugriffe Dateien bearbeiten, Werkzeuge ausführen und an einer Aufgabe weiterarbeiten. Damit greift er unmittelbar in den Entwicklungsablauf ein. Die Entscheidung für ein Werkzeug berührt deshalb auch die Zusammenarbeit: Wer formuliert den Auftrag? Wer beantwortet fachliche Rückfragen? Wer beurteilt das Ergebnis?
Der DORA-Report 2025 beschreibt KI als Verstärker vorhandener organisatorischer Stärken und Schwächen. Meine praktische Schlussfolgerung daraus: Wenn ein Team schon vor dem Agenten auf Entscheidungen warten musste, löst eine zusätzliche Lizenz diese Wartezeit nicht.
Es lohnt sich deshalb, vor dem nächsten Toolvergleich eine konkrete Frage zu stellen: Welche Arbeit soll für unser Team oder unsere Nutzer spürbar leichter werden? Vielleicht ist es die lang aufgeschobene Testabdeckung. Vielleicht eine interne Funktion, für die bisher immer die Zeit fehlte. Dieser Nutzen ist ein besserer Ausgangspunkt als eine pauschale Vorgabe zum KI-Anteil im Code.
Ein Beispiel: Der Export fürs Kundenportal
Nehmen wir einen einfachen Fall: Kunden sollen ihre abgeschlossenen Vorgänge als Datei exportieren können. Der Support stellt diese Dateien bislang manuell zusammen. Ein Agent kann den Download-Button, die Verarbeitung auf dem Server und Tests vorbereiten. Das klingt nach einer guten Pilotaufgabe, weil der Nutzen konkret und das Ergebnis vorführbar ist.
Doch eine fertige Datei beantwortet nicht, welche Vorgänge ein Kunde sehen darf, ob interne Notizen dazugehören und was bei großen Datenmengen geschehen soll. Diese Fragen gehören zum Auftrag. Dafür braucht es nicht zwangsläufig eine Führungskraft, aber eine erreichbare Person mit der passenden Entscheidungsbefugnis.
Für den Pilot könnte die Vereinbarung lauten: Der Fachverantwortliche bestimmt Inhalt und Sichtbarkeit des Exports. Eine Entwicklerin betreut die Umsetzung. Für Berechtigungen gibt es eine technische Gegenprüfung. Die Veröffentlichung folgt dem bestehenden Freigabeweg. Wer mehrere dieser Rollen übernimmt, wird ebenfalls benannt. So weiß das Team, wen es fragen muss, ohne für jede Kleinigkeit die Leitung einzuschalten.
Freiheit braucht einen klaren Auftrag
Beim Export könnte der erste Auftrag bewusst klein bleiben: Nur abgeschlossene Vorgänge des angemeldeten Kunden, ein festgelegter Satz an Feldern, zunächst in einer Vorschau mit künstlichen Testdaten. Keine neue Abrechnung, keine Änderung der Anmeldung, keine Veröffentlichung. Innerhalb dieses Rahmens darf das Team den Agenten selbstständig einsetzen.
Das ist vom Groben zum Feinen, nicht Mikromanagement. Zuerst wird das gewünschte Nutzerergebnis festgelegt. Dann zerlegt das Team die Arbeit gemeinsam mit dem Agenten in kleine, überprüfbare Schritte. Der Agent darf dabei technische Vorschläge machen und Unklarheiten aufdecken. Fachliche Spielregeln werden nicht stillschweigend an ihn weitergereicht.
Für die Zusammenarbeit reichen anfangs drei verständliche Kategorien:
- Im vereinbarten Rahmen selbstständig bearbeiten. Zum Beispiel die Vorschau umsetzen und Tests mit freigegebenen Testdaten ergänzen.
- Vor einer Erweiterung rückfragen. Zum Beispiel, wenn der Agent einen zusätzlichen Dienst, neue Datenfelder oder eine Änderung am Berechtigungsmodell vorschlägt.
- Nur nach ausdrücklicher Freigabe ausführen. Zum Beispiel Änderungen an produktiven Daten, kostenpflichtige Bestellungen oder eine Veröffentlichung außerhalb des vereinbarten Ablaufs.
Wichtig: Eine Anweisung im Chat ist keine technische Zugriffssperre. Die tatsächlichen Rechte, erlaubten Werkzeuge und Umgebungen müssen zu diesen Regeln passen. Was das für eure Systeme bedeutet, stimmt das Team mit den zuständigen technischen und organisatorischen Verantwortlichen ab.
Prüfe nach Risiko, nicht nach Zeilenanzahl
Du musst als Führungskraft keinen zeilenweisen Code-Review übernehmen. Umgekehrt macht ein grüner Testlauf die fachliche Prüfung nicht überflüssig. Beim Export ist die entscheidende Frage nicht, wie elegant der Agent den Download gebaut hat, sondern ob Kunde A ausschließlich die erlaubten Daten von Kunde A erhält.
Das Team sollte diesen Fall automatisiert prüfen und den Ablauf einmal am tatsächlichen Nutzerweg zeigen. Zu große Dateien, fehlende Berechtigungen und technische Fehler gehören ebenfalls in die Prüfung. Wie tief der zusätzliche Code-Review gehen muss, hängt von der Änderung ab: Ein Text am Button verlangt eine andere Aufmerksamkeit als die Regel, welche Kundendaten ausgegeben werden.
Dein Beitrag ist, diese Prüfzeit einzuplanen und Zuständigkeiten zu klären. Wenn jede kleine Änderung bei derselben erfahrenen Person landet, wird sie zum Engpass. Dann helfen kleinere Arbeitspakete, geteiltes Wissen und gezieltere Prüfungen mehr als weitere parallel gestartete Agenten.
Mach Können im Team teilbar
Ein Team gewinnt wenig, wenn nur eine Person weiß, wie man den Agenten sinnvoll einsetzt. Bitte deshalb nicht bloß um die nächste beeindruckende Demo, sondern um den Weg dorthin: Wie wurde der Auftrag eingegrenzt? Wo musste jemand nachsteuern? Was wurde verworfen? Auch der Umweg gehört zur Geschichte.
Eine kurze gemeinsame Durchsicht einer realen Aufgabe kann dafür reichen. Bewährte Regeln und Entscheidungen wandern anschließend in die Projektdokumentation. Das Team muss nicht sämtliche Chats archivieren, sondern das Wissen, das die nächste Person für ihre Arbeit benötigt.
Gerade bei Junioren wäre es schade, KI entweder zu verbieten oder sie nur am fertigen Ergebnis zu messen. Lass sie den Nutzerablauf erklären, einen Fehlerfall vorhersagen und gemeinsam mit einem erfahrenen Kollegen prüfen, ob ihre Erklärung trägt. Der Agent kann beim Lernen helfen; Raum für Fragen und Rückmeldung muss das Team schaffen.
Dazu gehört eine offene Ansage über das Ziel des Einsatzes. Wer befürchten muss, dass jeder gemeldete Zeitgewinn sofort zur nächsten Leistungsvorgabe wird, hat wenig Anlass, ehrlich über gelungene Experimente und Schwierigkeiten zu sprechen. Klärt, ob ihr zuerst den Support entlasten, mehr testen oder bislang liegen gebliebene Funktionen umsetzen wollt.
Schneller gebaut ist erst halb gemessen
Beim Kundenportal ist die Zahl der erzeugten Codezeilen ziemlich uninteressant. Spannender ist, ob Kunden ihren Export selbst erhalten und beim Support tatsächlich Arbeit entfällt. Dafür würde ich vier Fragen festhalten:
- Kommt das Ergebnis früher beim Nutzer an? Betrachte die Zeit vom geklärten Auftrag bis zur nutzbaren Funktion, einschließlich Wartezeit und Prüfung.
- Wie viel Nacharbeit entsteht? Erfasse Korrekturen und Fehler nach der ersten Umsetzung, nicht nur die Geschwindigkeit der Demo.
- Was kostet der gesamte Ablauf? Berücksichtige Werkzeugkosten, menschliche Arbeitszeit, Unterstützung und Betrieb.
- Wird der gewünschte Nutzen erreicht? Im Beispiel: erfolgreiche Exporte und weniger manuelle Supportanfragen, nicht bloß Klicks auf den neuen Button.
Vergleiche ähnliche Aufgaben und notiere Unterschiede. Eine neue Exportfunktion und die Reparatur einer historisch gewachsenen Abrechnung sind keine faire Vergleichsgruppe. Ein kleiner Pilot liefert Orientierung, aber keinen wissenschaftlichen Beweis für einen festen Produktivitätsfaktor.
Wie schwierig solche Messungen sind, erläutert METR in seinem Update vom Februar 2026: Die Auswahl teilnehmender Entwickler und Aufgaben sowie parallele Agentenarbeit erschwerten die Interpretation der Ergebnisse. Meine Empfehlung für die Führungspraxis lautet deshalb: Schaut auf euren tatsächlichen Ablauf, statt eine externe Prozentzahl zum Leistungsziel für alle zu machen.
Ein Pilot, nach dem du etwas entscheiden kannst
Für den Einstieg würde ich einen überschaubaren Zeitraum wählen, beispielsweise vier Wochen. Das ist ein Arbeitsrahmen, kein Liefer- oder Erfolgsversprechen. Ein möglicher Ablauf für den Export:
- Ausgangslage und Auftrag klären. Den bisherigen Supportaufwand verstehen, erlaubte Daten festlegen, Verantwortliche benennen und einen kleinen ersten Umfang vereinbaren.
- Einen vollständigen Nutzerweg bauen. In einer sicheren Vorschau vom Exportwunsch bis zur Datei kommen. Offene Entscheidungen sofort klären, statt nebenbei weitere Funktionen anzufangen.
- Gemeinsam prüfen und Wissen verteilen. Berechtigungen und Fehlerfälle testen, den Ablauf mit einer zweiten Person nachvollziehen und die wichtigen Entscheidungen dokumentieren.
- Ergebnis bewerten und nächsten Schritt wählen. Wenn eine begrenzte Veröffentlichung freigegeben wurde, erste Nutzung beobachten. Andernfalls mit repräsentativen Nutzern in der Vorschau prüfen und den noch fehlenden Betriebsnachweis offen benennen.
Danach entscheidet ihr: ausweiten, den Ablauf ändern oder zunächst eine Voraussetzung verbessern. Auch „Das Werkzeug hilft, aber unsere Rückfragen bleiben drei Tage liegen“ ist ein brauchbares Ergebnis. Ihr wisst dann, an welcher Stelle Führung tatsächlich etwas bewegen kann.
Was ich aus der Arbeit mit Agenten mitnehme
Bei Entwicklerherz setze ich Coding-Agenten beim Aufbau und bei der Weiterentwicklung eigener Plattformen ein: von der Ideenzerlegung über Oberflächen und Funktionen bis zu Tests und Wartung. Mich begeistert daran, wie schnell sich eine Idee in etwas verwandeln kann, das man wirklich ausprobieren und verbessern kann.
Meine Erfahrung aus dieser Produktarbeit ist aber keine pauschale Produktivitätszusage für ein fremdes Team. Übertragbar ist die Arbeitsweise: Das gewünschte Ergebnis greifbar machen, überschaubare Aufträge formulieren, am laufenden Produkt lernen und wichtige Entscheidungen festhalten. Führung schafft dafür den Rahmen und sorgt dafür, dass die gewonnene Zeit an der richtigen Stelle ankommt.
Der Fortschritt ist nicht, dass im Team mehr Agenten laufen. Der Fortschritt ist, dass das Team etwas Wertvolles verlässlich hinbekommt, das vorher liegen blieb.
Du möchtest das für dein Team konkretisieren? Im eintägigen Entwicklerherz-Workshop „KI-Agenten im Entwicklungsteam: Führen, entscheiden und Ergebnisse verantworten“ erarbeitet ihr einen ersten Einsatzplan mit Zuständigkeiten, Freigaberegeln und Erfolgskriterien. Auf Deutsch, live online oder inhouse; Termin und Preis auf Anfrage. Führungsworkshop anfragen.