Teamkommunikation und KI in der schnellen Entwicklung

Die entscheidende Feedbackschleife beim Setup eines Softwareentwicklungsprojekts besteht nicht zwischen dem Entwickler und der Test-Suite. Sie besteht zwischen der Person, die ein Feature schreibt (Analyst, Entwickler, Tester), und der Person, die es nutzen wird. Alles andere – Unit-Tests, Integrationstests, Code-Reviews, CI-Pipelines – existiert nur, um innerhalb dieser Schleife zu approximieren und zu übersetzen, wenn direkter Kontakt nicht möglich oder nicht schnell genug ist oder – was bei Enterprise-Systemen immer der Fall ist – die semantische Distanz zwischen dem Bedürfnis des künftigen Nutzers und dem Code/Daten/Outputs so groß und der Kontext so gewaltig oder spezifisch ist, dass niemand dies allein bewältigen könnte. Einer der heikelsten Momente der heutigen „KI-Revolution“ (die ich lieber als rasante Evolution eines LLM-basierten Ökosystems bezeichne) ist das Versprechen, selbst in diesem Sprung einen Sprung zu machen, wo Argumente fast ausschließlich trivial oder spezifisch sind – in einem solchen Fall spielt die Semantik nur eine schwache einschränkende Rolle. Ich möchte lediglich Ihre Aufmerksamkeit auf die Probleme lenken, die sich hinter diesen Annahmen verbergen. Meiner Meinung nach bleibt das Spiel dasselbe; einige Regeln ändern sich, aber im Kern des Geschäfts der „Übersetzung von Bedürfnissen in Software“ bleibt bestehen: „Es gibt kein Verständnis rein über den ‚Vibe‘.“ Ich würde Curt in vielen Detailfragen widersprechen, aber ich denke, er hat die wichtigste Botschaft gut auf den Punkt gebracht:

Die Invariante der zwei Fragen

Wenn ein Testingenieur fragt: „Wie soll ich dieses Feature testen?“, ist die Frage strukturell identisch mit: „Was ist die Kernfunktionalität (oder die nicht-funktionale Anforderung – schreckliche Wortwahl, aber gebräuchlich) und warum ist sie für den Kunden bzw. die Mission wichtig?“ Dies sind keine zwei Fragen – es ist dieselbe Frage, ausgedrückt aus zwei verschiedenen Positionen im Prozess. Ein Test, der sich nicht aus einer klaren Antwort auf die zweite Frage ableiten lässt, ist kein nützlicher Test. Vorsicht vor dem V-Modell! Eine Feature-Beschreibung, die nicht in einen Test umgemünzt werden kann, ist keine brauchbare Spezifikation.

Dies ist keine Beobachtung über das Testen. Es ist eine Beobachtung über Kommunikation. Die Funktion des „Test Design Review“ – in jeder Methodik – besteht darin, Fehlausrichtungen im gemeinsamen mentalen Modell des Systems aufzudecken, bevor diese Fehlausrichtungen in Code oder Testdaten kodiert werden. In der Sprache des Testens unterscheiden wir klar zwischen Validierungs- und Verifizierungszielen, selbst in der Praxis; besonders im Gespräch mit jenen, die den „KISS“-Ansatz (Keep it Simple, Stupid) lieben, erfassen wir diese Nuance oft nicht. Wenn ein Testingenieur keinen Test für eine Anforderung formulieren kann, ist dieses Scheitern der Formulierung ein Signal: Die Anforderung enthält eine verborgene Annahme, eine Mehrdeutigkeit oder einen Widerspruch. Der Testdesign-Prozess ist ein strukturiertes Protokoll, um diese verborgenen Eigenschaften aus natürlichsprachlichen Beschreibungen zu extrahieren.

Fehler sind leicht zu korrigieren. Konzeptuelle Probleme nicht.

Ein Fehler (Error) ist eine lokale Abweichung: eine falsche Berechnung, ein fehlender Null-Check, ein Off-by-one-Fehler. Statische Analysen, automatisierte Tests und Linter finden Fehler zuverlässig. Die Kosten für deren Entdeckung sinken seit Jahrzehnten und werden weiter sinken. LLM-gestützte Codegenerierung wird dies sogar noch beschleunigen – die syntaktische Qualität von generiertem Code ist im Allgemeinen hoch, und gängige Fehlermuster sind in den Trainingsdaten gut repräsentiert.

Ein konzeptuelles Problem hingegen ist eine Abweichung im Modell des Systems: ein Feature, das eine falsche Interpretation einer Anforderung korrekt implementiert; eine Datenstruktur, die ein Domänenkonzept präzise abbildet, das sich jedoch als das falsche Konzept herausstellt; ein Integrationsmuster, das zwei Dienste kohärent nach einem Vertrag verbindet, der so nie wirklich vereinbart wurde. Statische Analysen können dies nicht erkennen. Automatisierte Tests können dies ebenfalls nicht erkennen, es sei denn, die Tests wurden gegen eine korrekte Spezifikation geschrieben – und wenn die Spezifikation falsch war, sind auch die Tests falsch, und sie werden „bestanden“ liefern.

Diese Asymmetrie – Fehler sind auffindbar, konzeptuelle Probleme nicht – ist die beständige strukturelle Herausforderung der Softwarequalität. Sie verringert sich nicht durch besseres Tooling. Sie verschärft sich. Schnellere Lieferzyklen verkürzen die Zeit für jene Kommunikation, die konzeptuelle Probleme aufdecken würde, bevor sie kodiert werden. KI-gestützte Coding-Tools erhöhen den Durchsatz der Codegenerierung, ohne die Präzision des Anforderungsverständnisses zu erhöhen. Das Verhältnis von konzeptuellem Risiko zu Fehlerrisiko steigt.

KI als Verstärker – nicht als Spezifikations-Validator

LLM-basierte Coding- und Dokumentationstools sind auf ihrem aktuellen Leistungsniveau hochwertige Verstärker dessen, was bereits im Prompt-Kontext vorhanden ist. Sie sind exzellent darin, syntaktisch korrekten, stilistisch angemessenen Code zu generieren, der der im Prompt ausgedrückten Absicht entspricht. Sie sind schlechte Validatoren dafür, ob die im Prompt ausgedrückte Absicht mit der Absicht im Kopf des Kunden übereinstimmt.

Dies ist keine Kritik – es ist eine Beschreibung des Arbeitsbereichs des Werkzeugs und dessen, was sie im Prinzip sind. Ein wenig Verständnis der Mathematik hinter Transformern und dem Trainingsprozess würde die falschen Erwartungen korrigieren, die so oft in solche Tools hineinprojiziert werden. Aber das ist ein Thema für einen anderen Post. Ein Signalverstärker verstärkt Signal und Rauschen gleichermaßen. Wenn der Input für ein LLM-Coding-Tool eine konzeptuell falsche Spezifikation enthält, wird der Output eine größere, verfeinerte und besser formatierte Version der konzeptuell falschen Spezifikation sein. Die Erkennungsrate für Implementierungsfehler wird hoch sein. Die Erkennungsrate für konzeptuelle Fehler wird niedrig oder gleich null sein. Die Rolle des Testingenieurs in diesem Umfeld besteht nicht darin, mit dem Tool bei der Fehlererkennung zu konkurrieren. Sie besteht darin, die Disziplin aufrechtzuerhalten und zu fragen: „Spiegelt diese Spezifikation korrekt wider, was der Kunde braucht?“ – die Frage, die das Tool nicht beantworten kann.

Kurze Feedbackschleifen als Qualitätsinfrastruktur

Die praktische Implikation für die Teamkommunikation lautet: Die Feedbackschleife zwischen „Was bauen wir und warum“ und „Wie werden wir es verifizieren“ muss kürzer gehalten werden als die Schleife zwischen „Code schreiben“ und „Deployment“. In einem Sprint-basierten Team, das KI-Coding-Tools nutzt, bedeutet dies, dass das Test-Analyse-Meeting (oder ein entsprechender Austausch) bereits bei der Story-Definition stattfindet, nicht erst nach Abschluss des Codes. Der Entwickler, der Testingenieur und der Product Owner befinden sich im selben Raum (physisch oder virtuell), wenn das Akzeptanzkriterium geschrieben wird, denn das ist der Moment, in dem das konzeptuelle Modell noch zu minimalen Kosten korrigiert werden kann.

Dieses Argument ist nicht philosophisch. Es ist ökonomisch. Die Kosten für die Korrektur eines konzeptuellen Problems, das erst während des Abnahmetests entdeckt wird, sind um eine Größenordnung höher als die Kosten für die Korrektur während der Story-Definition. In einem Team, das große Mengen an Code via LLM-Tools erzeugt, steigt das Codevolumen pro Einheit Kommunikationseinsatz – was bedeutet, dass die Kosten pro Defekt bei konzeptuellen Problemen proportional steigen. Das Kommunikationsinvestment skaliert nicht mit dem Codevolumen. Das Testinvestment muss es jedoch. Das ist eine Warnung, die denjenigen, die sich bei allen Projektergebnissen die Hände schmutzig machen, bereits wohlbekannt ist, aber für das höhere Management nicht unbedingt vollständig nachvollziehbar sein muss. Ich bin stolz darauf, mit einem Bein in den „dreckigen, schlammigen Wassern“ der realen Auslieferung zu stehen und mit dem anderen Kontakt zu den Visionen zu halten. Aber ohne die Erdung der Entscheidungen in der realen Welt werden die Dinge mit jeder Technologie, die forciert wird, im Chaos enden.