Die Frage klingt zunächst akademisch, hat aber unmittelbare Folgen für die Projektorganisation: Ist ein KI-Assistent ein Werkzeug, das jemand bedient – oder ein Mitglied des Teams, mit dem man zusammenarbeitet? In der Folge einer Fachsendung zu Softwarearchitektur gehen Avraham Poupko und Ralf D. Müller genau dieser Unterscheidung nach. Parallel dazu liefern Angaben aus der Entwicklungspraxis bei Google einen nüchternen Blick darauf, wie weit die Eigenständigkeit solcher Systeme tatsächlich reicht.

Werkzeug oder Kollege: Warum die Unterscheidung praktisch ist

Ein Werkzeug wird eingesetzt, kontrolliert und bei Bedarf weggelegt. Die Verantwortung für das Ergebnis liegt eindeutig bei der Person, die es führt. Ein Teammitglied dagegen bringt eigene Beiträge ein, wird in Abstimmungen einbezogen und beeinflusst, wie Aufgaben verteilt werden. Zwischen diesen beiden Bildern liegt ein erheblicher Unterschied in der Erwartungshaltung.

Für Entwicklungsteams ist das keine Begriffsklauberei. Wer KI als Kollegen beschreibt, verschiebt implizit auch die Zurechnung von Fehlern, die Gestaltung von Code-Reviews – also der gegenseitigen Durchsicht von Quelltext vor der Übernahme – und die Frage, wer am Ende für eine Entscheidung geradesteht. Wer bei der Werkzeugmetapher bleibt, behält klare Zuständigkeiten, muss aber erklären, warum die Interaktion mit solchen Systemen zunehmend dialogisch verläuft.

Was die Zahlen aus der Praxis andeuten

Einen Realitätsabgleich liefern Aussagen des Google-Ingenieurs Haydn Belfield. Demnach wird bei Deepmind inzwischen über 75 Prozent des Produktionscodes von KI geschrieben. Gleichzeitig erfordern 88 Prozent der Änderungen weiterhin menschliche Steuerung. Beide Zahlen gehören zusammen: Ein hoher Generierungsanteil ist nicht gleichbedeutend mit Autonomie.

Belfield sieht zudem keine messbare Beschleunigung der KI-Forschung durch KI selbst. Ein hausintern verwendeter Indikator, der General Capability Index, zeige ein gleichmäßiges Wachstum ohne Temposprung. Eine sich selbst verbessernde KI bleibe vorerst Zukunftsmusik.

Die beiden Quellen betrachten unterschiedliche Ebenen und widersprechen sich nicht. Die eine stellt die konzeptionelle Frage nach der Rolle im Team, die andere liefert Messgrößen aus einem konkreten Entwicklungsumfeld. In der Zusammenschau ergibt sich ein Bild, das weder die Euphorie noch die Abwehrhaltung trägt: Die Beteiligung von KI an der Codeproduktion ist hoch, die Führung bleibt bei Menschen.

Konsequenzen für die Zusammenarbeit

Wenn der überwiegende Teil der Änderungen menschliche Steuerung braucht, verschiebt sich der Schwerpunkt der Arbeit. Weniger Zeit fließt in das Schreiben einzelner Zeilen, mehr Zeit in Spezifikation, Prüfung und Einordnung. Für Teams heißt das konkret:

  • Review bleibt Pflicht, nicht Kür. Generierter Code durchläuft dieselben Prüfschritte wie handgeschriebener – inklusive Tests, Architekturabgleich und Sicherheitsbetrachtung.
  • Verantwortung bleibt personengebunden. Ein Assistenzsystem kann nicht haften. Wer etwas freigibt, trägt die Verantwortung für die Freigabe.
  • Aufgabenbeschreibung gewinnt an Gewicht. Je präziser Anforderungen und Randbedingungen formuliert sind, desto brauchbarer fallen die Beiträge aus.
  • Erfahrungsaufbau braucht Aufmerksamkeit. Wenn Routineaufgaben wegfallen, müssen Teams bewusst dafür sorgen, dass weniger erfahrene Mitglieder weiterhin Verständnis für das Gesamtsystem aufbauen.

Die Metapher mit Augenmaß wählen

Die Kollegen-Metapher hat einen Nutzen: Sie beschreibt, dass die Zusammenarbeit iterativ verläuft, dass Rückfragen gestellt und Vorschläge verworfen werden. Sie hat aber auch eine Nebenwirkung. Wer ein System als Kollegen behandelt, neigt dazu, ihm Vertrauen entgegenzubringen, das auf sozialer Erfahrung beruht – nicht auf technischer Prüfung.

Praktikabel ist deshalb eine Zwischenposition: die Interaktionsform eines Gegenübers, die Rechenschaftspflicht eines Werkzeugs. Beiträge werden diskutiert, aber nicht geglaubt. Jede Übernahme wird begründet. Diese Haltung lässt sich in Teamregeln und Definitionen of Done – also verbindlichen Kriterien dafür, wann eine Aufgabe als abgeschlossen gilt – festhalten.

Erwartungsmanagement gegenüber Auftraggebern

Für Unternehmen, die Softwareprojekte vergeben, ist die nüchterne Lesart die belastbarere. Ein hoher KI-Anteil an der Codeerzeugung rechtfertigt nicht automatisch die Annahme, Projekte würden proportional schneller oder günstiger. Die Angaben aus dem Entwicklungsumfeld von Deepmind deuten darauf hin, dass der Aufwand sich verlagert statt verschwindet.

Sinnvoll ist deshalb, in Angeboten und Projektplänen transparent zu machen, wo KI-Unterstützung eingesetzt wird, welche Prüfschritte vorgesehen sind und wer welche Freigaben erteilt. Das schafft Nachvollziehbarkeit und vermeidet Diskussionen darüber, ob ein Fehler dem System oder dem Dienstleister zuzurechnen ist – die Antwort lautet in beiden Fällen: dem Dienstleister.

Einordnung

Für Web- und Softwareprojekte verändert sich damit weniger die Verantwortungsfrage als der Arbeitsalltag: Qualitätssicherung, Architekturentscheidungen und klare Anforderungen werden zum eigentlichen Engpass, während Codeerzeugung an Gewicht verliert. Teams sollten festlegen, welche Aufgaben mit KI-Unterstützung bearbeitet werden dürfen und welche Prüfschritte verbindlich bleiben. Wer das schriftlich regelt, behält die Kontrolle über Qualität und Haftung – unabhängig davon, ob man das System am Ende Werkzeug oder Kollegen nennt.

Quellen