Qualität & Belege
Die versteckten Kosten von „Die KI sagt, es funktioniert“
Wenn ein KI-Werkzeug eine Änderung erklärt, klingt die Erklärung häufig bereits wie eine Abnahme. Es beschreibt den behobenen Fehler, nennt die betroffenen Dateien und schließt mit einem beruhigenden Satz. Für die Person, die eine Veröffentlichung verantwortet, bleibt dennoch eine andere Frage offen: Was wurde tatsächlich beobachtet? Die versteckten Kosten entstehen dort, wo diese Frage erst nach der Übergabe gestellt wird und jemand die vermeintlich abgeschlossene Arbeit erneut rekonstruieren muss.
Bereit ist nicht bestanden
Ein Prüfplan kann sinnvoll und vollständig sein, ohne dass eine einzige Prüfung gelaufen ist. Vielleicht fehlt eine Laufzeitumgebung, vielleicht ein Browser, vielleicht die Berechtigung für einen Dienst. Das sind wichtige Informationen für die Planung. Sie sind aber keine positive Aussage über die Qualität der Änderung. Eine Freigabe wird unsicher, wenn diese Zustände in einer gemeinsamen grünen Zusammenfassung verschwinden.
In meinem Open-Source-Projekt project-check-nix geht es deshalb um ausdrücklich deklarierte Prüfkommandos und nachvollziehbare Ergebnisse. Ein Plan zeigt Voraussetzungen, führt aber noch keine Prüfungen aus. „Bereit“ bedeutet nicht „bestanden“. Auch blockierte Prüfungen zählen nicht als Erfolg. Das Werkzeug ist dabei weder eine Sandbox noch eine Grenze für Netzwerkzugriffe; es organisiert Nachweise, nicht sämtliche Risiken ihrer Ausführung.
Keine Funde können auch keine Abdeckung bedeuten
Ein leerer Bericht lässt mindestens zwei Lesarten zu: Es wurde nichts gefunden, oder es wurde nichts Verwertbares untersucht. Für eine Entscheidung sind diese Fälle grundverschieden. Ein fehlgeschlagener Parser kann denselben leeren Ergebnissatz hinterlassen wie eine erfolgreiche Prüfung ohne Befund. Wer nur die Anzahl der Funde zeigt, verschweigt die Voraussetzung, unter der diese Zahl überhaupt etwas aussagt.
project-check-nix behandelt fehlende Abdeckung oder fehlgeschlagene Auswertung nicht einfach als bestandene Prüfung ohne Funde. Die allgemeine Lehre ist kein Anspruch auf Fehlerfreiheit. Sie lautet: Auch die Verlässlichkeit der Messung gehört zum Ergebnis. Lassen Sie sich bei einer Freigabe deshalb nicht nur den Befund, sondern auch Umfang, Ausführung und erkennbare Lücken der Prüfung erklären.
Eine Oberfläche muss beobachtet werden
In meinem Open-Source-Projekt visual-qa-mcp verbinde ich die Prüfung von Browseroberflächen mit Aufnahmen, automatisierten Hinweisen zur Barrierefreiheit und Bildvergleichen. Befunde behalten ihre Herkunft. Eine Einschätzung durch ein Modell wird nicht allein dadurch verifiziert, dass sie überzeugend formuliert ist. Für neue Vergleichsbilder ist eine ausdrückliche Freigabe vorgesehen, statt die aktuelle Darstellung automatisch zum richtigen Zustand zu erklären.
Das löst nicht jede Frage guter Gestaltung. Es verhindert aber eine bestimmte Verwechslung: Eine Erklärung über die Oberfläche ist noch keine Beobachtung der Oberfläche. Wenn der erforderliche Browser fehlt, werden browsergestützte Integrationstests ausdrücklich übersprungen. Eine erfolgreiche Quelltextprüfung bleibt dann nützlich, weist aber nicht nach, wie sich die Seite im Browser verhält oder ob die konkrete Darstellung richtig ist.
Nicht jede Entscheidung braucht ein Modell
Mein Open-Source-Projekt GrepQuest ist ein lokales Terminal-Lernspiel für GNU grep. Die Antworten werden durch eine deterministische Bewertungslogik beurteilt. Optional erzeugte kosmetische Inhalte entscheiden nicht über die Richtigkeit einer Antwort. Das Projekt befindet sich im Entwicklungsstadium; Schnittstellen und Formate können sich noch ändern. Es ist ein begrenztes Beispiel, kein Beweis für eine universelle Bewertungsmethode.
Gerade die Begrenzung macht das Beispiel interessant. Wenn sich ein Erfolgskriterium präzise ausdrücken lässt, muss nicht zusätzlich ein Sprachmodell darüber urteilen. Kreative Erklärung und verbindliche Bewertung können getrennt bleiben. Für Teams ist das eine nützliche Entwurfsfrage: Wo brauchen Sie tatsächlich Interpretation, und wo würde eine eindeutige, nachvollziehbare Regel die Verantwortung für die Entscheidung klarer machen?
Die Übergabe ist Teil der Arbeit
Eine gute Übergabe trennt Behauptung, ausgeführte Prüfung und offene Unsicherheit. Sie sagt nicht nur, dass etwas funktioniert, sondern unter welchen Bedingungen das beobachtet wurde. Damit kann die verantwortliche Person entscheiden, ob die vorhandenen Nachweise für die nächste Stufe reichen. Eine offene Lücke ist dabei oft hilfreicher als eine beruhigende Zusammenfassung, die verschiedene Prüfarten vermischt.
Ich würde diese Trennung als Anforderung an einen Anbieter formulieren, nicht als höflichen Wunsch an einzelne Entwicklerinnen und Entwickler. Wenn die Nachweiskette erst nachträglich zusammengesucht werden muss, bezahlt das Team mit zusätzlicher Aufmerksamkeit und unklaren Zuständigkeiten. Wie groß dieser Aufwand ist, muss im konkreten Betrieb gemessen werden. Aus den Projekten folgt keine pauschale Produktivitätszahl, wohl aber ein klarerer Maßstab für Abnahme.
Fragen an Ihr Team oder Ihren Anbieter
- Welche Prüfungen wurden tatsächlich ausgeführt, und welche waren blockiert oder wurden übersprungen?
- Welche Abdeckung liegt einem Bericht ohne Funde zugrunde, und wurde die Auswertung erfolgreich abgeschlossen?
- Welcher konkrete Nachweis verbindet die behauptete Fehlerbehebung mit einem beobachteten Ergebnis?
- Welche Befunde stammen aus festen Regeln und welche aus einer Einschätzung durch ein Modell?
- Wer darf neue visuelle Vergleichsbilder freigeben, und kann das Werkzeug seine eigene Änderung automatisch akzeptieren?
- Welche Unsicherheiten übernimmt die Person, die auf Grundlage dieser Ergebnisse eine Veröffentlichung freigibt?