Vibe Coding hat verändert, wer eine funktionsfähig wirkende Anwendung erstellen kann. Ein Prompt kann Bildschirme generieren, eine API anbinden und einen plausiblen Ablauf zusammenstellen, bevor ein traditionelles Entwicklungsteam seine erste Designprüfung abgeschlossen hat.

Diese Geschwindigkeit schafft ein neues Problem bei Einstellung und Auslieferung: Eine Demo ist kein starker Beleg mehr dafür, dass Software gut ist. Arbeitgeber werden zunehmend eine schwierigere Frage stellen: Kann sich dieses mit KI erstellte System korrekt verhalten, wenn Eingaben fehlerhaft sind, Abhängigkeiten ausfallen, Nutzer Aktionen wiederholen und sich das zugrunde liegende Modell ändert?

Die Antwort wird aus einer Qualitätsmesslatte hervorgehen, die weniger nach visueller Ausarbeitung und mehr nach disziplinierter Softwareverifikation aussieht. Diejenigen, die herausstechen, werden nicht bloß zeigen, was ein KI-Programmierwerkzeug erzeugt hat. Sie werden zeigen, wie sie es getestet haben, was es nicht sicher leisten kann und woher sie wissen, dass eine Änderung nichts anderes beschädigt hat.

Ein Benchmark ist ein Beleg, keine Ranglistenpunktzahl

Open-Source-Benchmarks für Programmieragenten bieten nützliche Ausgangspunkte, messen jedoch unterschiedliche Fähigkeiten. SWE-bench verwendet reale GitHub-Issues und Repository-Snapshots und ist daher für Wartungsarbeiten relevant. Terminal-Bench testet die Interaktion mit der Kommandozeile. Andere aufgeführte Benchmarks, darunter SlopCodeBench und ProgramBench, zielen auf andere Aspekte generierten Codes und des Agentenverhaltens ab.

Diese Benchmarks können dabei helfen, Werkzeuge zu vergleichen oder eine Ausgangsbasis festzulegen, doch Arbeitgeber sollten vorsichtig damit sein, einen einzelnen Wert als Beweis für Produktionsreife zu betrachten. Ein Modell, das Repository-Issues löst, kann dennoch unsichere Autorisierungslogik erzeugen. Ein Agent, der Terminalaufgaben abschließt, kann möglicherweise den Zustand über einen langen Ablauf hinweg nicht bewahren. Eine ausgefeilte Webanwendung kann eine Happy-Path-Demo bestehen und dennoch Wiederholungsversuche oder doppelte Zahlungen falsch behandeln.

Ein glaubwürdiges Portfolio oder internes Review sollte daher auch ein aufgabenspezifisches Evaluationsset enthalten. Dieses Set könnte repräsentative Fehlerberichte, normale Nutzerabläufe, fehlerhafte Eingaben, Berechtigungsgrenzen, Ausfälle von Abhängigkeiten und zuvor behobene Regressionen enthalten. Für jeden Fall sollte ein eindeutig erwartetes Ergebnis festgelegt sein, nicht bloß ein Screenshot, der richtig aussieht.

Das minimale Testpaket für mit KI erstellte Software

Für eine kleine Anwendung lässt sich ein nützliches Qualitätspaket ohne ein aufwendiges Forschungslabor zusammenstellen:

  • Abnahmetests: Überprüfen das für Nutzer sichtbare Verhalten der wichtigsten Abläufe, einschließlich erfolgreicher und erfolgloser Ergebnisse.
  • Unit- und Integrationstests: Prüfen Geschäftsregeln isoliert und bestätigen, dass Datenbanken, APIs, Warteschlangen und Authentifizierung wie vorgesehen zusammenspielen.
  • Negativtests: Senden fehlende, fehlerhafte, übergroße, doppelte und nicht autorisierte Eingaben. KI-generierter Code wirkt oft auf dem im Prompt gezeigten Pfad am stärksten, daher sind die nicht angeforderten Pfade wichtig.
  • Regressionstests: Machen aus jedem entdeckten Fehler einen dauerhaften Test. Eine grüne Demo nach einer Behebung reicht nicht aus, wenn derselbe Fehler bei der nächsten generierten Änderung zurückkehren kann.
  • Sicherheitsprüfungen: Testen Zugriffskontrollen, den Umgang mit Geheimnissen, Schutzmaßnahmen gegen Injection, Schwachstellen in Abhängigkeiten sowie die Frage, ob nicht vertrauenswürdige Inhalte Tool-Aufrufe oder privilegierte Aktionen beeinflussen können.
  • Betriebsprüfungen: Überprüfen Timeouts, Wiederholungsversuche, Idempotenz, Protokollierung, Warnmeldungen und ein sicheres Verhalten, wenn eine Abhängigkeit nicht verfügbar ist.

Das entspricht weitgehend der QA-Engineering-Denkweise, die in Stack Overflows Darstellung eines agentischen Softwareentwicklungslebenszyklus beschrieben wird. Der wichtige Wandel ist kultureller Art: Qualitätssicherung ist keine abschließende Prüfung, nachdem eine KI den Code geschrieben hat. Sie ist die Struktur, die schnelle Generierung sicher genug für den Einsatz macht.

Die Orchestrierung testen, nicht nur die Ausgabe

Wenn Software einen KI-Agenten umfasst, sind gewöhnliche Anwendungstests notwendig, aber nicht ausreichend. Das System kann scheitern, weil das Modell eine Anfrage missverstanden hat, aber auch, weil die umgebende Orchestrierung den Kontext verloren, ein Tool zweimal aufgerufen, eine fehlerhafte strukturierte Ausgabe akzeptiert oder nie beendet wurde.

Die im Digest empfohlenen Regressionstestbereiche vor der Bereitstellung sind eine praktische Checkliste: Kontextverlust, Tool-Idempotenz, Prompt-Injection, strukturierte Ausgabe, Nichtbeendigung, Grounding beim Abruf und Wiederherstellung des Zustands. Dabei handelt es sich um testbare technische Eigenschaften.

Beispielsweise kann ein Test dieselbe Anfrage zweimal ausführen und bestätigen, dass der zweite Versuch keine doppelte Bestellung erzeugt. Ein anderer kann einen Agenten mitten in einem Ablauf unterbrechen, ihn neu starten und überprüfen, dass er aus einem gültigen Zustand fortfährt, anstatt eine nicht rückgängig zu machende Aktion zu wiederholen. Ein Retrieval-Test kann verlangen, dass das System nur Informationen aus einer genehmigten Quellenmenge zitiert oder zurückgibt. Ein Test für strukturierte Ausgaben kann eine ungültige Antwort liefern und bestätigen, dass die Anwendung sie sicher zurückweist, statt sie stillschweigend als gültige Daten zu behandeln.

Lang laufende Systeme und Multi-Agenten-Systeme benötigen besonders eindeutige Fehlerprotokolle. Forschende arbeiten an der automatisierten Zuordnung von Fehlern, weil es schwierig sein kann festzustellen, welcher Agent einen Fehler verursacht hat und an welcher Stelle einer langen Interaktionskette dies geschah. In der Praxis sollten Teams Tool-Aufrufe, Eingaben, Ausgaben, Modellversionen, Zeitstempel, Zustandsübergänge und endgültige Entscheidungen in einem datenschutzbewussten Prüfprotokoll bewahren. Ohne diese Belege zeigt dir ein roter Test zwar, dass etwas fehlgeschlagen ist, aber nicht, wo du mit der Behebung beginnen solltest.

Reproduzierbarkeit wird zu einem Karrierevorteil

KI-generierter Code ist variabel. Eine erneute Ausführung kann eine andere Implementierung erzeugen; eine Modellaktualisierung kann das Verhalten ändern; ein Ausfall des Anbieters kann Routing oder Latenz verändern. Arbeitgeber werden daher Kandidaten schätzen, die Evaluierungen wiederholbar machen können.

Das bedeutet, nach Möglichkeit Modell-Snapshots festzuschreiben, Prompts und Konfiguration aufzuzeichnen, die Zufälligkeit zu kontrollieren, wenn die Plattform dies zulässt, und mehrere Durchläufe für Aufgaben auszuführen, deren Ergebnisse variieren. Der Digest verweist ausdrücklich auf festgeschriebene Snapshots, eine niedrige oder, sofern verfügbar, null Temperatur sowie CI/CD-Gates mit Konfidenzgrenzen als nützliche Schutzmaßnahmen.

Ein praxisnaher Bericht sollte mindestens drei Ergebnisse unterscheiden:

  1. Erfolgsquote: wie viele Fälle erfolgreich waren.
  2. Konsistenz: wie oft derselbe Fall bei wiederholten Durchläufen erfolgreich ist.
  3. Schweregrad: ob Fehler kosmetischer Natur oder lediglich lästig sind, Daten beschädigen, sicherheitsrelevant sind oder eine unsichere externe Aktion auslösen können.

Ein System, das 19 von 20 Formatierungsprüfungen mit geringem Risiko besteht, ist nicht unbedingt besser als eines, das 18 von 20 Fällen besteht, aber niemals eine Autorisierungsgrenze überschreitet. Der Qualitätsmaßstab muss Fehler nach ihren Folgen gewichten.

Die menschliche Prüfung sollte auf Risiken abzielen, nicht auf jede einzelne Zeile.

Der Zweck besserer Automatisierung besteht nicht darin, eine Person zu zwingen, jedes von einer KI erzeugte Token erneut zu lesen. Sie soll die menschliche Aufmerksamkeit auf die Entscheidungen lenken, die Tests nicht vollständig klären können.

Prüfer sollten sich auf Authentifizierung und Autorisierung, Datenaufbewahrung, finanzielle oder vertragliche Aktionen, Datenschutz, Migrationen, Fehlerbehebung, Berechtigungen Dritter und Änderungen konzentrieren, die selbst die Evaluierungsharness des Systems beeinflussen. Bei einem Agenten sollten sie außerdem prüfen, welche Tools er aufrufen darf, auf welche Daten jedes Tool zugreifen kann und ob vor einer irreversiblen Aktion eine Genehmigung erforderlich ist.

Sichtbare Diffs, Genehmigungsabläufe, archivierte Unterhaltungen und Audit-Logs – Funktionen, die in Slacks Beschreibung der kollaborativen KI-Programmierung hervorgehoben werden – weisen auf eine umfassendere Erwartung hin: Die Entstehungsgeschichte von Software wird wichtig sein. Ein Prüfer sollte die Anfrage verstehen, die generierte Änderung untersuchen, die Testnachweise einsehen und feststellen können, wer die Bereitstellung genehmigt hat.

Dieser Nachweis ist keine Bürokratie um ihrer selbst willen. Er macht eine beeindruckende Demo von einer kontrollierten Änderung unterscheidbar, die eine andere Person warten kann.

Was in ein Portfolio oder Bewerbungsgespräch gehört

Für Bewerber ist die überzeugendste Demonstration ein kleines System mit einer bewusst transparent dargestellten Qualitätsgeschichte. Fügen Sie das Repository, Einrichtungsanweisungen, Architekturhinweise, Testbefehle, repräsentative Testfälle, bekannte Einschränkungen und einen kurzen Fehlerbericht hinzu. Zeigen Sie ein oder zwei Fehler, die gefunden und in Regressionstests umgewandelt wurden. Erklären Sie, welches Modell oder welcher Programmieragent verwendet wurde, ohne das Tool als Urheber der technischen Entscheidungen darzustellen.

Wenn die Anwendung einen Agenten verwendet, dokumentieren Sie die Tool-Berechtigungen, das Zustandsmodell, die Wiederholungsstrategie, die Abbruchbedingung und die Punkte, an denen eine menschliche Genehmigung erforderlich ist. Wenn sie Retrieval nutzt, zeigen Sie, wie Quellen ausgewählt werden und was geschieht, wenn Belege fehlen. Wenn sie externe Dienste aufruft, demonstrieren Sie das Verhalten bei Zeitüberschreitungen und doppelten Anfragen.

Behaupten Sie nicht aufgrund einer einzigen erfolgreichen Aufzeichnung, dass das System zuverlässig ist. Eine überprüfbare Aussage klingt eher so: „In 30 aufgezeichneten Durchläufen dieser 12 Szenarien erfüllte das System in 28 Fällen die Abnahmekriterien; bei den beiden Fehlern ging es um mehrdeutige Datumsangaben, und beide sind dokumentiert.“ Die Zahl selbst ist weniger wichtig als die Methode, die Grenzen und die Ehrlichkeit darüber, was noch nicht getestet wurde.

Die neue Definition von schnell

KI senkt die Kosten für die Erstellung einer ersten Version. Sie beseitigt nicht die Kosten dafür, zu wissen, ob diese Version Vertrauen verdient. Tatsächlich kann eine schnellere Generierung die Evaluierung noch wichtiger machen, weil sich zwischen Bereitstellungen mehr ungeprüfte Änderungen ansammeln können.

Der Profi nach dem Vibe-Coding wird am Ablauf gemessen: Verhalten definieren, Code generieren oder ändern, realistische und adversariale Fälle testen, Entscheidungen mit hohem Risiko prüfen, Fehler dokumentieren und das System verbessern, ohne die Nachweise zu verlieren. Benchmarks können dabei helfen, Fähigkeiten zu vergleichen. QA-Praktiken entscheiden darüber, ob diese Fähigkeiten zu zuverlässiger Software werden.

Der Qualitätsmaßstab lautet daher nicht: „Kannst du mit KI eine App erstellen?“ Er lautet: „Kannst du nachweisen, was die App tut, erkennen, wenn sie damit aufhört, und die Grenzen so gestalten, dass aus einem Fehler kein Vorfall wird?“