„Mit KI sind wir viel schneller” – diesen Satz hört man oft. Ob er stimmt, weiß meist niemand so genau. Gerade in Unternehmen, in denen Software sorgfältig entstehen muss, reicht ein Gefühl nicht aus. Bei der Einführung von KI in den Entwicklerteams eines Unternehmens der Gesundheitsbranche haben wir deshalb von Anfang an gemessen. Dieser Artikel beschreibt, wie.
Die Ausgangslage
Die Entwicklung war in Scrum-Teams organisiert, jedes mit bis zu zehn Entwicklerinnen und Entwicklern. Die Branche bringt besondere Anforderungen mit: Software muss nachvollziehbar entstehen, Daten sind sensibel, und Fehler sind teuer. KI-Werkzeuge einfach freizugeben und zu hoffen, dass es schon gut geht, kam nicht infrage.
Die Werkzeuge: bewusst gemischt
Eingesetzt wurden mehrere Arten von Werkzeugen:
- Claude Code als KI-Assistent, der direkt im Code arbeitet, Änderungen vorschlägt und umsetzt,
- Gemini als weiteres Sprachmodell,
- lokale KI-Modelle, die im eigenen Haus laufen.
Die lokalen Modelle haben einen einfachen Grund: Nicht jede Aufgabe darf ein Werkzeug außerhalb des Unternehmens sehen. Wo sensible Inhalte im Spiel sind, bleibt die Verarbeitung im eigenen Netz. Welches Werkzeug wofür eingesetzt werden darf, war deshalb Teil der Regeln – nicht eine Frage des persönlichen Geschmacks.
Die wichtigste Regel: messen statt schätzen
Der Kern der Einführung war eine Vergleichsgröße. Für Aufgaben, die mit KI-Unterstützung umgesetzt wurden, gab es vorab eine Abschätzung von Senior-Entwicklern: Wie lange würde das ohne KI dauern? Gemessen wurden dann zwei Dinge:
- Die tatsächlich benötigte Zeit – verglichen mit der Abschätzung.
- Die Codequalität – denn schneller ist nur dann besser, wenn das Ergebnis nicht schlechter wird.
Beides gehört zusammen. Wer nur die Zeit misst, belohnt schnellen, aber schlechten Code. Wer nur die Qualität betrachtet, sieht nicht, ob sich der Aufwand lohnt.
Worauf man beim Messen achten sollte
Aus dieser Erfahrung lassen sich ein paar Hinweise für alle ableiten, die Ähnliches vorhaben:
- Vorher festlegen, was gemessen wird. Wer erst im Nachhinein nach passenden Zahlen sucht, findet immer welche.
- Abschätzungen von erfahrenen Leuten einholen. Je besser die Abschätzung, desto aussagekräftiger der Vergleich. Senior-Entwickler kennen die Codebasis und ihre Tücken.
- Qualität greifbar machen. Für die Codequalität bieten sich zum Beispiel Befunde aus Code-Reviews, Testabdeckung, Ergebnisse statischer Analysen oder später gefundene Fehler an. Wichtig ist, dieselben Maßstäbe für Arbeit mit und ohne KI anzulegen.
- Über mehrere Sprints messen. In den ersten Wochen verzerren Neugier und Lernaufwand das Bild. Ein verlässliches Ergebnis zeigt sich erst über einen längeren Zeitraum.
- Gleiches mit Gleichem vergleichen. Eine Fehlerbehebung in vertrautem Code ist etwas anderes als ein neues Modul. Aufgaben sollten nach Art getrennt betrachtet werden.
Und das Ergebnis?
Die konkreten Ergebnisse aus diesem Projekt bleiben vertraulich. Der eigentliche Gewinn der Methode ist aber unabhängig davon: Sie ersetzt Meinungen durch Zahlen. Das Team weiß, wo KI wirklich hilft und wo nicht, und die Geschäftsführung kann ihre Entscheidungen auf eine belastbare Grundlage stellen.
Wer KI im eigenen Entwicklerteam einführen will, findet die Grundregeln für den Start im Artikel KI im Entwicklerteam einführen: fünf Regeln für den Start. Wie ich Unternehmen dabei begleite, steht unter KI-Einführung.