Die Ausgangslage
Die Softwareentwicklung verändert sich derzeit mit hoher Geschwindigkeit.
Mit Hilfe von Agentic Coding, zum Beispiel mit Claude Code, lassen sich heute Funktionen in kurzer Zeit entwickeln, für die früher Stunden oder Tage notwendig waren.
Im Dialog lassen sich schnell verschiedene Lösungsansätze ausprobieren, weil der Aufwand, sie zunächst einmal zu implementieren, drastisch gesunken ist.
AI Coding senkt außerdem die Eintrittshürde für Softwareentwicklung erheblich. Phänomene wie Vibe Coding zeigen das deutlich. Wenn Software zunehmend auf Zuruf erzeugt werden kann, wird der einzelne Code immer mehr zur Commodity.
Das ist eine enorme Chance, Softwareentwicklung insgesamt effizienter zu gestalten – und sei es allein dadurch, dass viele immer wiederkehrende Tasks bequem und „intelligent" delegiert werden können. Jeder, der schon einmal mit Java oder C# gearbeitet und komplexere Datenstrukturen angelegt hat, weiß, wovon ich rede.
Aber diese Einfachheit der Codeproduktion erzeugt auch eine gefährliche Illusion:
Wenn Code immer schneller und günstiger erzeugt werden kann, wird Qualität automatisch ebenfalls günstiger.
Das ist aus vielen Gründen nicht der Fall.
KI als Werkzeug im Entwicklungsprozess
Für mich beschränkt sich AI Coding nicht auf die Erzeugung von Code.
Ich nutze KI inzwischen an unterschiedlichen Stellen meiner Arbeit: um Anforderungen zu analysieren, Lösungswege durchzuspielen, Code zu entwickeln und zu überarbeiten, Tests vorzubereiten, Fehler zu untersuchen oder Dokumentation zu erstellen.
Dabei ist nicht jeder Einsatz automatisch sinnvoll. Manches funktioniert erstaunlich gut, manches kostet am Ende mehr Zeit als es spart. Und manchmal ist ein kleines Python-Skript schlicht die bessere Lösung.
Die interessante Frage ist deshalb nicht, wo man überall KI einsetzen kann. Interessanter ist, wo sie tatsächlich Arbeit abnimmt oder neue Arbeitsweisen ermöglicht – und was notwendig ist, damit man sich auf das Ergebnis verlassen kann.
Denn KI nimmt uns die Verantwortung für das Ergebnis nicht ab. Ob eine Anforderung richtig verstanden wurde, ein Geschäftsprozess tatsächlich so funktioniert wie angenommen oder ein Randfall später zum Problem wird, muss weiterhin überprüft werden. Das Gleiche gilt für Regressionen, Sicherheitsanforderungen und Architekturentscheidungen.
Besonders interessant wird es, wenn dieselbe KI den Code schreibt und anschließend beurteilen soll, ob sie ihre Aufgabe richtig erledigt hat. Natürlich kann sie dabei Fehler finden. Aber eine unabhängige Prüfung ist das noch nicht – wir haben zunächst dieselbe Maschine ein zweites Mal gefragt.
Code lässt sich heute sehr viel einfacher erzeugen. Die Frage, ob wir ihm vertrauen können, ist dadurch nicht einfacher geworden.
Was bedeutet das für die Qualitätssicherung?
Wenn Code schneller und in größeren Mengen erzeugt werden kann, wird die Frage wichtiger, was eigentlich das richtige Ergebnis ist und wie wir das feststellen.
Damit verschiebt sich auch die Arbeit in der QA. Testfälle abarbeiten und Regressionen manuell durchklicken war noch nie die ganze Aufgabe und wird künftig einen noch kleineren Teil davon ausmachen.
Wichtiger wird die Arbeit davor: Anforderungen und Geschäftsprozesse verstehen, Risiken erkennen, sinnvolle Qualitätskriterien festlegen und entscheiden, wie und auf welcher Ebene geprüft werden soll.
QA beschäftigt sich damit nicht erst mit der fertigen Anwendung, sondern früher mit Anforderungen, Architektur und Schnittstellen. Dazu kommt die Frage, wie Ergebnisse aus KI-gestützter Entwicklung überprüft werden können.
Die Rolle der QA wird dadurch nicht kleiner. Sie verschiebt sich stärker zur Gestaltung und Absicherung des Entwicklungsprozesses.
Die Rückkehr von Cucumber und Gherkin?
Gherkin könnte durch KI wieder interessanter werden.
Die fachlich lesbare und gleichzeitig strukturierte Beschreibung eignet sich als kontrollierbare Zwischenschicht zwischen Anforderung und technischer Umsetzung. Der bisher erhebliche Aufwand für Szenarien, Step Definitions und deren Pflege lässt sich mit KI deutlich reduzieren.
Anforderung → Gherkin-Szenario → ausführbarer Test
Aus Anforderungen können Szenarien vorgeschlagen und daraus Step Definitions und Testcode erzeugt werden. Der Mensch kann dabei auf einer Ebene prüfen, auf der die fachliche Aussage noch verständlich ist, bevor daraus technische Testartefakte entstehen.
Entscheidend ist nicht, mit KI möglichst viel Gherkin zu produzieren. Interessant ist, dass eine Technik, die in vielen Projekten an ihrem Pflegeaufwand gescheitert ist, als überprüfbare Schnittstelle zwischen Fachlichkeit und Automatisierung wieder nützlich werden kann.
Und was bedeutet das für die Testautomatisierung?
Wenn sich Software schneller ändert, muss auch das Feedback über ihre Qualität mit dieser Geschwindigkeit mithalten können. Alles anschließend von Hand zu überprüfen, funktioniert dann noch weniger als bisher.
Testautomatisierung wird deshalb nicht weniger wichtig, weil eine KI inzwischen auch Tests schreiben kann. Sie wird wichtiger.
KI kann Tests entwickeln, Varianten erzeugen, vorhandene Tests analysieren oder bei der Untersuchung von Fehlern helfen. Ein von einer KI erzeugter Test ist aber nicht automatisch ein guter Test. Wenn Code und Test aus derselben Interpretation einer Anforderung entstehen, können im schlimmsten Fall auch beide denselben Fehler enthalten.
Die Aufgabe besteht deshalb nicht darin, möglichst viele Tests automatisch erzeugen zu lassen. Es geht darum, ein Testsystem aufzubauen, das möglichst früh belastbare Aussagen über die Software liefert.
TDD als Leitplanke für AI Coding
Gebe ich einem Coding Agent nur eine Story, lasse ich ihm erheblichen Interpretationsspielraum. Fehlende Details werden ergänzt, Annahmen getroffen und manchmal entsteht eine plausible Lösung für ein Problem, das so gar nicht gestellt wurde.
Besser ist es, vor der Implementierung überprüfbare Leitplanken aufzubauen:
Story → Akzeptanzkriterien → optional Gherkin → Tests → Implementierung
Der Agent kann innerhalb dieser Grenzen Code erzeugen, Tests ausführen und seine Implementierung korrigieren. Die Tests definieren dabei einen Teil des Lösungsraums, den er nicht stillschweigend verschieben darf.
TDD bekommt damit beim AI Coding eine zusätzliche Funktion: Tests steuern nicht nur die Entwicklung, sondern begrenzen auch typische Ungenauigkeiten und Eigenmächtigkeiten eines Coding Agents.
Agenten brauchen Grenzen
Mit agentischen Systemen verändert sich die Situation noch einmal. Ein Chatbot liefert eine Antwort. Ein Agent kann handeln.
Er kann Dateien verändern, Tests starten, Systeme bedienen, APIs aufrufen oder über MCP auf Werkzeuge und Infrastruktur zugreifen.
Damit werden Berechtigungen, Kontext, Isolation, Nachvollziehbarkeit und kontrollierte Freigaben Teil der Architektur. Je mehr ein Agent selbständig tun darf, desto genauer muss festgelegt sein, was er tun darf und wie sein Ergebnis überprüft wird.
Die Wahl eines Tools ist dabei erst der Anfang. Claude Code, OpenAI, Gemini, lokale Modelle, RAG oder MCP lösen diese Fragen nicht von selbst.
Eine funktionierende API macht noch kein produktionsreifes AI-System.
Mein Ansatz
Ich verbinde klassische Softwareentwicklung und Quality Engineering mit AI-assisted Engineering.
Dazu gehören AI-assisted Development und QA, agentische Workflows, MCP-basierte Toolintegration, RAG, moderne Testautomatisierung sowie eigene Werkzeuge und experimentelle QA-/AI-Workbenches.
Dabei geht es mir nicht darum, möglichst viel Arbeit an KI abzugeben. Ich möchte die Aufgaben automatisieren, bei denen es tatsächlich einen Nutzen bringt, und die Ergebnisse kontrollierbar halten.
Dazu gehört für mich auch Training und Coaching. Entwickler, Tester, Fachbereiche und Projektverantwortliche müssen verstehen, was diese Systeme gut können, wo ihre Grenzen liegen und wie sich ihre Ergebnisse sinnvoll überprüfen lassen. Nicht als Sammlung von Prompt-Tricks, sondern anhand konkreter Arbeitsabläufe und Probleme.
Je einfacher Software mit KI erzeugt werden kann, desto wichtiger wird unabhängige Qualitätssicherung.