Codegenerierung ist kein Engpass mehr. Ein Agent liefert an einem Vormittag mehr Änderungen, als ein Team an einem Tag sorgfältig durchsieht – und die Verantwortung für das Ergebnis bleibt vollständig beim Menschen. Der Engpass ist von der Erzeugung zur Beurteilung gewandert. Dieser Leitfaden beschreibt, wie ein belastbarer Review-Prozess für Agenten-Output aussieht und welche Prüfschritte aus einem Prototyp eine abnahmefähige Lieferung machen.
Dieser Artikel ist ein vertiefender Fachbeitrag aus unserem Content-Cluster. Entdecken Sie die vollständige Übersicht auf unserer Hauptseite:Moderne Webentwicklung & Software-Engineering →
- Der Engpass hat die Seite gewechselt: Nicht das Schreiben von Code ist knapp, sondern die Fähigkeit, ihn zu beurteilen. Wer Agenten einsetzt, ohne die Prüfkapazität mitzuplanen, verlagert Arbeit nur nach hinten – dorthin, wo Fehler am teuersten sind.
- Beim Review fehlt die Absicht: Wer eigenen Code prüft, vergleicht Ausführung mit Absicht. Bei Agenten-Output ist die Absicht nicht im Kopf des Prüfers. Deshalb funktionieren die gewohnten Review-Gewohnheiten nicht mehr – es braucht eine eigene Mechanik.
- Prüfbarkeit ist eine Vertragsfrage: Ein Prototyp ohne definierte Prüfstrecke ist nicht abnehmbar, weil niemand sagen kann, wann er fertig ist. Quality Gates sind damit kein technisches Detail, sondern die Grundlage jeder sauberen Festpreis-Abnahme.
Die Frage nach dem Merge
Ein Agent öffnet einen Branch mit vierhundert geänderten Zeilen. Die Tests sind grün, der Build läuft, die Beschreibung klingt plausibel. Niemand im Team hat eine dieser Zeilen geschrieben. Die Frage, wer jetzt mit welcher Methode entscheidet, ob das zusammengeführt wird, ist die zentrale Qualitätsfrage der Softwareentwicklung 2026.
1. Das Reviewer-Nadelöhr
Es gibt eine Zahl, die in Diskussionen über Entwicklungsproduktivität selten auftaucht, obwohl sie alles entscheidet: wie viel Code ein Mensch pro Tag sorgfältig prüfen kann. Die Erfahrungswerte aus der Review-Praxis liegen bei einigen hundert Zeilen, bevor die Aufmerksamkeit messbar nachlässt – und diese Zahl ist über Jahrzehnte stabil geblieben, weil sie an menschlicher Konzentration hängt und nicht an Werkzeugen.
Auf der anderen Seite steht ein KI-Coding-Assistent, der diese Menge in Minuten produziert. Damit ist die Rechnung, die hinter den meisten Produktivitätsversprechen steht, unvollständig. Sie misst die Erzeugung und unterschlägt die Beurteilung. Wer beides zusammenrechnet, stellt fest: Der Engpass ist nicht verschwunden, er ist gewandert.
Das ist keine Kritik an den Werkzeugen. Agenten wie Cursor, Claude Code oder Antigravity leisten in der Erzeugung Erstaunliches, und die Architekturfrage dahinter haben wir im Beitrag zu Multi-Agenten-Systemen in der Softwareentwicklung ausführlich behandelt. Es ist eine Kritik an der Bilanz, die daraus gezogen wird. Denn drei Dinge gelten unverändert:
Die Haftung wandert nicht mit
Wer die Software ausliefert, verantwortet sie. Kein Kunde, kein Auditor und kein Gericht interessiert sich dafür, welches Werkzeug eine fehlerhafte Zeile erzeugt hat. Die Verantwortung bleibt vollständig beim liefernden Unternehmen – der Erzeuger hat sie nie übernommen.
Review-Ermüdung ist real
Wer zwanzig plausibel aussehende Branches hintereinander durchsieht, prüft den einundzwanzigsten anders als den ersten. Plausibilität ist genau die Eigenschaft, in der generierter Code besonders stark ist – und genau die, die menschliche Wachsamkeit senkt.
Verschobene Kosten sind höhere Kosten
Ein Fehler, der im Review auffällt, kostet Minuten. Derselbe Fehler im Betrieb kostet Analyse, Hotfix, Kommunikation und Vertrauen. Ungeprüfter Agenten-Output spart nichts, er verschiebt Aufwand in die teuerste Phase – ein Muster, das aus der Diskussion um technische Schulden seit Jahrzehnten bekannt ist.
Was dagegen gelöst ist – und das ist der Fortschritt der letzten beiden Jahre –, ist die syntaktische Ebene. Ob der Code kompiliert, ob Typen passen, ob Formatierungsregeln eingehalten sind: Das prüfen Werkzeuge zuverlässiger als jeder Mensch, und es ist kein sinnvoller Gegenstand eines Reviews mehr. Übrig bleibt die Ebene, auf der Werkzeuge prinzipiell nicht urteilen können: ob der Code das Richtige tut.
2. Warum fremder Code anders geprüft wird
Wenn ein Entwickler eigenen Code noch einmal durchliest, macht er unbemerkt etwas sehr Spezifisches: Er vergleicht das Geschriebene mit einer Absicht, die er selbst hat. Er weiß, welches Problem er lösen wollte, welche drei Ansätze er verworfen hat und warum an einer Stelle bewusst eine unelegante Lösung steht. Der Text auf dem Bildschirm ist nur die halbe Information; die andere Hälfte liegt im Kopf.
Genau diese Hälfte fehlt beim Review von Agenten-Output. Der Prüfer hat den Code vor sich, aber nicht die Absicht dahinter – und der Erzeuger kann sie zwar auf Nachfrage plausibel beschreiben, aber er kann nicht dafür einstehen. Ein Agent begründet jede Entscheidung überzeugend, auch eine falsche. Das ist der eigentliche Unterschied, und aus ihm folgt eine andere Prüfhaltung.
Beim klassischen Peer-Review lautet die Frage: Hat der Kollege übersehen, was ich sehe? Beim Agenten-Review lautet sie: Habe ich verstanden, was hier eigentlich passiert – und wollte ich das?
Klassisches Peer-Review vs. Agenten-Review
- Ausgangspunkt: Ein Kollege, dessen Denkweise und Stärken bekannt sind.
- Fehlerbild: Flüchtigkeit, Wissenslücken, Zeitdruck – meist lokal und erklärbar.
- Rückfrage: Liefert eine belastbare Begründung; der Autor haftet für seine Aussage.
- Umfang: Wächst mit dem Aufwand des Autors und ist dadurch natürlich begrenzt.
- Stil: Persönliche Handschrift, an der Abweichungen auffallen.
- Ausgangspunkt: Ein Erzeuger ohne Gedächtnis für die ungeschriebenen Regeln des Projekts.
- Fehlerbild: Plausible Fehlinterpretation der Aufgabe – global, konsistent durchgezogen und dadurch schwer sichtbar.
- Rückfrage: Liefert eine überzeugende Erzählung, die keine Gewähr trägt.
- Umfang: Beliebig groß, ohne dass die Größe etwas über die Schwierigkeit aussagt.
- Stil: Gleichmäßig und konventionell – Auffälligkeiten verschwinden im Durchschnitt.
Daraus lassen sich drei Fragen ableiten, die jedes Review von Agenten-Output beantworten muss. Sie sind bewusst in dieser Reihenfolge gestellt, denn die erste entscheidet, ob die anderen beiden überhaupt lohnen:
-
Löst diese Änderung das gestellte Problem?
Nicht: Ist der Code gut? Sondern: Wurde die Aufgabe richtig verstanden? Die häufigste Fehlerklasse bei Agenten-Output ist eine saubere, gut strukturierte, vollständig durchgezogene Lösung für ein leicht anderes Problem als das gestellte. Diese Prüfung braucht keinen Blick auf die Implementierung, sondern einen Vergleich zwischen Aufgabenstellung und beobachtbarem Verhalten.
-
Was verändert sie außerdem?
Agenten optimieren die gestellte Aufgabe und haben kein Gefühl dafür, welche Nebenwirkung teuer ist. Eine mitgeänderte Signatur, eine „aufgeräumte" Hilfsfunktion, ein zusätzlicher Datenbankzugriff in einer Schleife: technisch korrekt, im Kontext falsch. Diese Prüfung gilt dem Wirkungsbereich, nicht dem Diff.
-
Warum ausgerechnet so?
Wo der Code eine nicht offensichtliche Entscheidung trifft – ein Caching, ein Retry, eine eigene Implementierung statt einer vorhandenen Funktion –, muss ein Mensch diese Entscheidung nachvollziehen und verantworten können. Wo das nicht gelingt, wird nicht diskutiert, sondern vereinfacht.
3. Die Review-Mechanik
Die drei Fragen sind die Haltung. Damit sie im Alltag standhalten, brauchen sie eine Mechanik – eine feste Reihenfolge von Handgriffen, die auch am Ende eines langen Tages noch funktioniert. Die folgenden fünf sind werkzeugunabhängig und lassen sich in jedem Team einführen, unabhängig davon, welcher Agent im Einsatz ist.
Ein Agenten-Lauf, eine prüfbare Einheit
Die wichtigste Einzelmaßnahme ist zugleich die unbeliebteste: den Auftrag so klein schneiden, dass das Ergebnis in einem Zug prüfbar bleibt. Ein Agent kann drei Aufgaben gleichzeitig erledigen – aber ein Mensch kann drei vermischte Aufgaben nicht sauber beurteilen. Die Grenze setzt die Prüfbarkeit, nicht die Leistungsfähigkeit des Werkzeugs.
Blast Radius vor Zeilenzahl
Nicht die Menge der Änderungen bestimmt die Prüftiefe, sondern ihr Blast Radius. Zweihundert Zeilen in einer isolierten Komponente sind harmloser als drei Zeilen in einer zentralen Hilfsfunktion, einem Authentifizierungspfad oder einer Migration. Die Prüfreihenfolge folgt dem Wirkungsbereich, nicht der Reihenfolge im Diff.
Daten und Migrationen zuerst
Fehler in der Darstellung sind reparierbar, Fehler an den Daten oft nicht. Deshalb werden Schema-Änderungen, Löschoperationen, Berechtigungslogik und alles, was Geld oder personenbezogene Daten berührt, vor dem Rest gelesen – und zwar unabhängig davon, wie klein der betreffende Abschnitt ist.
Jede neue Abhängigkeit rechtfertigen
Sprachmodelle erfinden Paketnamen, die es nicht gibt – und Angreifer registrieren genau diese Namen, ein Muster, das als Slopsquatting bekannt ist. Jedes neu hinzugefügte Paket wird deshalb einzeln geprüft: Existiert es wirklich, wer pflegt es, und braucht das Projekt es überhaupt? Die Sicherheitsseite dieser Frage behandelt der Beitrag zur Sicherheit von KI-Agenten in Dev-Umgebungen.
Der fünfte Handgriff ist der wirksamste und kostet am wenigsten Zeit: die Gegenprobe. Bevor ein Branch zusammengeführt wird, erklärt ein Mensch in eigenen Worten, was er tut – nicht der Agent, sondern der Prüfer. Zwei bis drei Sätze genügen. Wer diese Sätze nicht formulieren kann, hat den Code nicht verstanden, und dann ist die Größe des Diffs irrelevant.
Experten-Tipp: Die Begründung gehört in den Commit, nicht in den Chat
Der wertvollste Teil eines Agenten-Laufs ist die Begründung, warum eine Lösung so aussieht – und genau dieser Teil bleibt üblicherweise im Chatfenster zurück und ist nach einer Woche verloren. Wer ihn in die Commit-Nachricht übernimmt, macht die Entscheidung für alle späteren Leser nachvollziehbar. Das ist derselbe Grund, aus dem Architekturentscheidungen dokumentiert werden: Nicht der Code ist schwer zu rekonstruieren, sondern die verworfene Alternative.
4. Tests als Spezifikation, nicht als Selbstbestätigung
Agenten schreiben bereitwillig Tests, und sie schreiben sie schnell. Das Ergebnis sieht aus wie Qualitätssicherung, hat aber einen strukturellen Konstruktionsfehler: Diese Tests prüfen den Code gegen die Interpretation der Aufgabe, aus der der Code entstanden ist. Hat der Agent die Aufgabe falsch verstanden, sind Implementierung und Test gemeinsam falsch – und die Suite ist trotzdem grün.
Damit ist nicht gesagt, dass generierte Tests wertlos wären. Als Regressionsnetz sind sie nützlich: Sie halten fest, wie sich das System heute verhält, und schlagen an, wenn eine spätere Änderung dieses Verhalten kippt. Nur beantworten sie nicht die Frage, ob das festgehaltene Verhalten richtig ist. Diese Unterscheidung entscheidet darüber, wem man welche Tests überlässt.
Der Mensch schreibt die Akzeptanzfälle
Was fachlich gelten soll, wird unabhängig vom Agenten formuliert – idealerweise bevor er beauftragt wird. Damit wird der Test zur Spezifikation und nicht zum Echo. Das ist die Testebene, an der ein Fachbereich mitreden kann und muss.
Der Agent schreibt die Abdeckung in der Breite
Randfälle, Null-Werte, leere Listen, Fehlerpfade: Hier ist die Ermüdungsfreiheit der Maschine ein echter Vorteil, und die Kosten eines übersehenen Falls sind gering. Diese Tests sind Ergänzung, nie Nachweis.
Mutation Testing prüft die Prüfer
Mutation Testing baut absichtlich kleine Fehler ein und beobachtet, ob die Suite anschlägt. Es beantwortet die Frage, die eine grüne Anzeige offenlässt: ob überhaupt etwas gemessen wird. Ein gelegentlicher Lauf auf den kritischen Modulen genügt, um Scheinsicherheit aufzudecken.
Die Pyramide bleibt gültig
Viele schnelle Unit-Tests, weniger Integrationstests, wenige E2E-Tests auf den Pfaden, die Umsatz oder Vertrauen tragen. Agenten neigen dazu, jede Ebene gleichzeitig zu bedienen – das Ergebnis ist eine langsame, brüchige Suite, die niemand mehr abwartet.
Ein Wort zur Verlässlichkeit: Ein Flaky Test ist in dieser Konstellation gefährlicher als in klassischen Projekten. Wer gewohnt ist, rote Läufe mit einem zweiten Versuch zu beantworten, verliert genau die Warnfunktion, auf der das gesamte Prüfgebäude ruht. Ein instabiler Test wird deshalb repariert oder entfernt – aber nicht ignoriert. Wie sich E2E-Tests mit Playwright stabil halten lassen, ist im Detail Thema unseres Beitrags zum Website-Monitoring mit GitHub Actions und Playwright.
5. Der zweite Agent als Reviewer
Die naheliegende Antwort auf zu viel Agenten-Output ist ein weiterer Agent, der ihn prüft. Das funktioniert besser, als Skeptiker erwarten – und schlechter, als die Werkzeughersteller nahelegen. Beide Hälften dieses Satzes sind wichtig, denn die Grenze verläuft nicht bei der Qualität des Modells, sondern bei der Art des Fehlers.
Ein automatisierter Reviewer ist unermüdlich, konsistent und breit. Er findet vergessene Fehlerbehandlungen, unbenutzte Variablen, fehlende Berechtigungsprüfungen und Abweichungen von Projektkonventionen – zuverlässig auch im zwanzigsten Branch des Tages. Als Vorfilter, der die menschliche Aufmerksamkeit auf die verbleibenden Stellen konzentriert, ist er ausgesprochen wertvoll.
Was er nicht kann, hängt nicht an seiner Leistungsfähigkeit:
Prüfer und Erzeuger teilen Trainingsdaten und damit systematische Neigungen. Ein Muster, das der eine für richtig hält, hält der andere selten für falsch. Das ist derselbe Effekt, der bei LLM-as-a-Judge-Verfahren die Kalibrierung gegen menschliche Urteile nötig macht.
Ob ein Rabatt kaufmännisch vertretbar, eine Frist regulatorisch zulässig oder ein Datenfeld überhaupt erhebbar ist, steht nicht im Repository. Genau dort liegen die teuren Fehler.
Vorgelegter Code wird eher bestätigt als abgelehnt, besonders wenn er sauber aussieht. Ein Review, das fast nie etwas findet, ist kein gutes Zeichen – sondern ein Anlass, das Prüfsetup zu hinterfragen.
Eine Freigabe durch ein Modell ist keine Freigabe. Sie ist ein Hinweis. Die Unterschrift bleibt beim Menschen, und mit ihr die Pflicht, verstanden zu haben, was freigegeben wird.
Daraus folgt eine einfache Arbeitsteilung, die sich in der Praxis bewährt: Der Agent filtert, der Mensch entscheidet. Alles, was Daten verändert, Geld bewegt oder nach außen sichtbar ist, braucht eine menschliche Freigabe – und zwar eine, bei der jemand die drei Fragen aus Kapitel 2 tatsächlich beantwortet hat. Alles andere darf ein Werkzeug vorsortieren.
6. Quality Gates als Reihenfolge, nicht als Sammlung
Die meisten Teams haben ihre Prüfwerkzeuge längst beisammen: Linter, Typprüfung, Tests, Sicherheits-Scans, Audits. Was oft fehlt, ist die Reihenfolge – und die entscheidet über den Nutzen. Ein Quality Gate soll die Fehlerklasse abfangen, die es am billigsten abfängt, und es soll das tun, bevor teurere Stufen Rechenzeit und Wartezeit verbrauchen.
Statische Prüfung. Formatierung, Linting, Typprüfung – Sekunden, keine Diskussion, kein menschlicher Blick nötig. Alles, was hier abgefangen wird, gehört nie in ein Review.
Schnelle Tests. Unit-Ebene, wenige Minuten. Ziel ist nicht Vollständigkeit, sondern ein frühes, verlässliches Signal, dass die Kernlogik intakt geblieben ist.
Build und Vorschau-Umgebung. Erst wenn gebaut wurde, existiert etwas Prüfbares. Eine Vorschau-Umgebung pro Änderung ist der Unterschied zwischen „sieht im Diff gut aus" und „funktioniert".
E2E gegen die Vorschau. Die Pfade, deren Ausfall wehtut – Anmeldung, Formularversand, Kaufabschluss. Wenige, stabile, aussagekräftige Tests statt einer breiten, brüchigen Suite.
Menschliche Freigabe. Erst hier, wenn alles Maschinelle grün ist, lohnt sich die knappste Ressource: die Aufmerksamkeit eines Menschen für die drei Fragen, die keine Maschine beantwortet.
Auslieferung mit Rückweg. Ein Deploy ohne geübten Rollback ist eine Wette. Der Rückweg muss nicht elegant sein, aber er muss unter Druck funktionieren – und jemand muss ihn schon einmal gegangen sein.
Diese Website folgt genau diesem Muster, und zwar ohne kommerzielle Werkzeuge. Der Push auf den Hauptbranch löst einen GitHub-Actions-Workflow aus, der das Projekt baut, das Ergebnis auf den Zielserver überträgt und anschließend den CDN-Cache leert. Zusätzlich laufen automatisierte Prüfungen im Build selbst – etwa eine Kontrolle, die literale Markdown-Syntax im gerenderten HTML findet und den Build abbricht, nachdem genau dieser Fehler einmal auf mehreren Seiten sichtbar geworden war. Ergänzt wird das durch einen wöchentlichen technischen Audit der ausgelieferten Seiten. Die Werkzeugebene dazu – Playwright-Skripte, YAML-Workflows, Performance-Budgets – ist ausführlich im Beitrag zum Website-Monitoring mit GitHub Actions beschrieben und soll hier nicht wiederholt werden.
Der Punkt dieses Beispiels ist ein anderer: Kein einzelnes Gate darin ist bemerkenswert. Bemerkenswert ist, dass jedes von ihnen aus einem konkreten Fehler entstanden ist, der einmal durchgerutscht war. So entsteht eine belastbare Prüfstrecke – nicht durch Vollständigkeit am Anfang, sondern dadurch, dass jeder Vorfall genau ein Gate hinterlässt.
7. Vom Quality Gate zum Abnahmekriterium
Bis hierhin war alles eine interne Angelegenheit. Der interessantere Teil beginnt, wenn Software für jemand anderen gebaut wird – denn dann wird aus der Prüffrage eine Vertragsfrage. Ein Prototyp, den ein Agent in wenigen Tagen erzeugt hat, ist beeindruckend. Abnehmbar ist er erst, wenn beide Seiten vorher wissen, woran sie erkennen, dass er fertig ist.
In der klassischen Welt beantwortete das ein Pflichtenheft. Sein Problem ist bekannt: Es entsteht zu einem Zeitpunkt, an dem niemand das System kennt, das darin beschrieben wird. Wir arbeiten deshalb mit einem funktionierenden Prototyp der Kernabläufe statt mit einem Dokument. Damit dieser Ansatz vertraglich trägt, muss an die Stelle der ausführlichen Beschreibung eine überprüfbare Bedingung treten – eine Definition of Done, die nicht davon abhängt, wer oder was den Code geschrieben hat.
Die Frage „hat ein Mensch das getippt?" ist für die Abnahme irrelevant. Die Frage „welche Prüfungen hat es bestanden, und wer steht dafür ein?" ist die einzige, die zählt.
Für ein Festpreis-Angebot bewährt sich eine kurze, harte Liste – keine Absichtserklärung, sondern Bedingungen, deren Erfüllung sich zeigen lässt:
Quick-Check: Was in die Abnahme gehört
Der letzte Punkt der Liste ist der ungewöhnlichste und in der Praxis der wichtigste. Ein Prototyp, dessen Grenzen ausdrücklich benannt sind, schützt beide Seiten: Der Auftraggeber trifft seine nächste Investitionsentscheidung auf einer belastbaren Grundlage, und der Dienstleister wird nicht an Erwartungen gemessen, die nie Gegenstand der Vereinbarung waren. Wer diesen Weg für KI-Systeme statt für klassische Anwendungen gehen will, findet die passenden Messgrößen im Beitrag zu Evals und Qualitätssicherung von KI-Output; die Prüfstrecke bleibt dieselbe, nur die Metrik ändert sich. Einen Überblick über unsere Festpreis-Leistungen gibt die Seite Leistungen & Pakete.
Fazit
Die Entwicklungswerkzeuge des Jahres 2026 haben eine alte Wahrheit sichtbar gemacht, statt sie aufzuheben: Software wird nicht dadurch gut, dass sie geschrieben wird, sondern dadurch, dass jemand für sie einsteht. Solange das Schreiben teuer war, ließ sich diese Unterscheidung ignorieren – der Autor war ohnehin da und kannte seinen Code. Jetzt, wo das Schreiben billig geworden ist, tritt sie offen zutage.
Die Konsequenz ist keine Rückkehr zur Handarbeit. Sie besteht darin, die Prüfkapazität genauso ernst zu nehmen wie die Erzeugungskapazität: Aufträge klein genug schneiden, dass sie beurteilbar bleiben. Tests unabhängig von dem formulieren, was sie prüfen sollen. Die Reihenfolge der Quality Gates nach den Kosten ihrer Fehlerklassen bauen. Und die Freigabe bei einem Menschen belassen, der sie in eigenen Worten begründen kann.
Wer das tut, kann Agenten in vollem Umfang einsetzen, ohne die Kontrolle abzugeben. Wer es lässt, produziert schneller – aber niemand im Team kann noch sagen, was das System eigentlich tut. Der Unterschied zeigt sich nicht in der ersten Woche. Er zeigt sich in dem Moment, in dem etwas kaputtgeht.
Haben Sie Fragen zur Qualitätssicherung von KI-generiertem Code?
Kostenlose Erstberatung vereinbarenUnsere Expertise vor Ort
Wir sind Ihr digitaler Partner – regional verankert und überregional erfolgreich.
Haben Sie eine Vision?
Lassen Sie uns gemeinsam prüfen, wie wir Ihre Idee zum Fliegen bringen.
Jetzt kostenloses Strategiegespräch buchenErweitertes Fachglossar
Blast Radius
Der Wirkungsbereich einer Änderung – also alles, was von ihr betroffen sein kann, nicht nur das, was sichtbar geändert wurde. Beim Review von Agenten-Output ist er die wichtigste Priorisierungsgröße: Eine Zeile in einer zentralen Hilfsfunktion verdient mehr Aufmerksamkeit als hundert Zeilen in einer isolierten Komponente.
Mutation Testing
Ein Prüfverfahren, das absichtlich kleine Fehler in den Produktivcode einbaut und beobachtet, ob die Testsuite darauf anschlägt. Es beantwortet die Frage, die eine grüne Testsuite offenlässt: ob die Tests überhaupt etwas messen oder nur mitlaufen.
Quality Gate
Eine automatisierte Prüfschwelle in der Auslieferungskette, die eine Änderung nur passieren lässt, wenn definierte Bedingungen erfüllt sind. Entscheidend ist die Reihenfolge: Jedes Gate soll die Fehlerklasse abfangen, die es am billigsten abfängt.
Flaky Test
Ein Test, der bei unverändertem Code mal bestanden und mal fehlgeschlagen ist – meist durch Zeitabhängigkeiten oder geteilten Zustand. Flaky Tests sind gefährlicher als fehlende Tests, weil sie dem Team beibringen, rote Läufe zu ignorieren.
Slopsquatting
Das Registrieren von Paketnamen, die Sprachmodelle häufig erfinden, um Schadcode über halluzinierte Abhängigkeiten zu verbreiten. Der Angriff nutzt nicht einen Tippfehler des Entwicklers aus, sondern einen wiederholbaren Fehler des Modells.
Definition of Done
Eine vorab vereinbarte Liste von Bedingungen, die erfüllt sein müssen, damit eine Arbeit als abgeschlossen gilt. In Projekten mit KI-Beteiligung ersetzt sie die Frage, wer den Code geschrieben hat, durch die Frage, welche Prüfungen er bestanden hat.
