Wie ich entscheide, ob KI-Output mein Vertrauen verdient

Vom Prompting zur Überwachung

Das erste Mal, dass mir das wirklich klar wurde, war bei der Überprüfung deutscher Übersetzungen eines benutzerdefinierten, von Gemini angetriebenen Plugins, das ich entwickelt hatte für Christian Pure. Die Admin-Tabelle sah normal aus. Die Zeilen waren gefüllt. Die Aufträge waren als abgeschlossen markiert. Aus der Ferne sah es so aus, als hätte das System die Arbeit erledigt.

Dann öffnete ich ein paar Beiträge und fand Englisch in Feldern, die eigentlich Deutsch enthalten sollten. Der Fehler war nicht subtil. Es war keine Frage des Geschmacks, des Sprachflusses oder der Formulierung. Der Workflow hatte unfertige Arbeit als fertig markiert, und die Benutzeroberfläche hatte diesen Fehler unauffällig aussehen lassen.

Dieser Fehler hat meine Sichtweise auf KI-gestützte Arbeit verändert. Ein ausgefülltes Feld ist keine Übersetzung. Ein gerenderter Bildschirm ist kein Produkt. Eine kohärente Antwort ist nicht dasselbe wie eine korrekte Antwort. KI ist sehr gut darin, Artefakte zu produzieren, die wie Fortschritt aussehen: übersetzt wirkende Zeilen, plausibler Code, aufgeräumte Bildschirme, polierte Zusammenfassungen. Wenn ich müde bin oder schnell arbeite, kann diese Ähnlichkeit ausreichen, um mich für einen Moment zu täuschen.

Da hörte ich auf, Prompting als den Kern der Fähigkeit zu betrachten. Prompting ist immer noch wichtig, aber die wichtigere Arbeit ist die Überwachung: zu entscheiden, was Erfolg bedeutet, bevor die Generierung beginnt, das Modell im realen System zu verankern und Prüfungen zu erstellen, die fließende Fehler sichtbar machen, bevor sie die Nutzer erreichen.

Manchmal nennt man diese umgebende Schicht ein Harness (Gerüst). Ich hatte dieses Wort nicht im Kopf, als ich den Christian Pure-Workflow erstellte, aber genau das ist daraus geworden. Gemini generierte die Übersetzungen. Ein theologisches Glossar schränkte Schlüsselbegriffe ein. Prüfungen nach der Übersetzung suchten nach englischen Überbleibseln. API-Protokolle und Ausgabenlimits machten es einfacher, Fehler zu erkennen. Die Admin-Überprüfung hielt die Ausgabe von der Produktion fern, bis jemand sie überprüfen konnte.

Der Großteil meiner KI-Arbeit findet in dieser unordentlichen Mitte zwischen Produkt, Design und Implementierung statt. Ich habe an einer Gute-Nacht-App für Kinder mit Kaufprozessen und mehrsprachigem Audio gearbeitet, an einem WordPress-Übersetzungssystem, das Tausende von Beiträgen abdeckt, und an einem Raumvisualisierer, bei dem räumliche Fehler das Versprechen des Produkts brechen. Bei dieser Art von Arbeit ist es ein schwaches Signal, wenn etwas fertig aussieht. Ich muss wissen, welche Source of Truth das Modell verwendet hat, welche Einschränkungen es beibehalten hat, was sich im Diff geändert hat, welche Prüfungen bestanden wurden und wie ein Fehler aussehen würde, wenn das Modell falsch läge.

Die Aufgabe geht tiefer als die sichtbare Ausgabe

Für Christian Pure war die Aufgabe größer als nur Text in einer anderen Sprache zu generieren. Die eigentliche Aufgabe bestand darin, einer großen mehrsprachigen Website zu helfen, sich kohärent anzufühlen, ohne die Verwaltung in permanente Aufräumarbeit zu verwandeln. Wenn eine deutsche Seite immer noch englische Überbleibsel enthält, hat das System eine nicht-leere Ausgabe produziert, aber keine übersetzte Seite.

Dieser Unterschied zeigt sich überall. Ein Modell kann ein Feld ausfüllen, einen Bildschirm rendern oder eine strukturierte Antwort zurückgeben und dabei den Sinn der Arbeit verfehlen. Die tiefere Frage ist, ob das Artefakt die Aufgabe erfüllt hat, auf die es ankommt. Hat die Übersetzung die Bedeutung bewahrt? Hat der Code den Fehler behoben, der das eigentliche Problem verursacht hat? Hat das Design die reale Umgebung des Nutzers unterstützt und nicht nur den sauberen Demo-Pfad?

Nach dem Übersetzungsfehler begann ich, KI-Ausgaben als nicht vertrauenswürdige Zwischenarbeit zu behandeln. Für das Plugin bedeutete das explizite Prüfungen auf unübersetzte englische Zeichenfolgen, eine strengere Überprüfung abgeschlossener Zeilen und eine genauere Überwachung des API-Verhaltens. Der Workflow war nicht länger eine Anfrage nach Übersetzung, sondern wurde zu einem System, in dem schlechte Übersetzungen einen Ort hatten, an dem sie auftauchen konnten.

Dasselbe Muster zeigt sich beim Code. Ein Modell kann Flutter-Code generieren, der kompiliert, während es den RevenueCat-Sonderfall ignoriert, der den Kauf-Bug verursacht hat. Es kann einen sauberen Implementierungsplan erstellen, der die eigentliche Einschränkung übersieht. Es kann einen Bildschirm bauen, der im normalen Entwicklungspfad gut aussieht und dann auf einem älteren Android-Gerät oder beim Audio-Verhalten auf dem Sperrbildschirm fehlschlägt. Bevor ich der Ausgabe vertraue, formuliere ich die Aufgabe in einfacher Sprache neu und prüfe, ob das Artefakt diese Aufgabe gelöst hat, einschließlich der unschönen Teile.

Beschränkungen müssen explizit sein

Viele KI-generierte Arbeiten scheitern, weil die sichtbare Anfrage einfacher ist als die tatsächliche Einschränkung, die darunter liegt. Das Modell kann die Anweisung erfüllen und gleichzeitig den Freigabeprozess, Design-Tokens, die Kostenobergrenze, Inhaltsregeln, Geräteeinschränkungen, die Architektur oder den Wartungsaufwand verletzen.

Das Übersetzungs-Plugin hat mich das auf die harte Tour gelehrt. Die erste Version hatte zu wenig Instrumentierung rund um Fehler, Wiederholungsversuche und Ratenbegrenzungen. Es stieß an die API-Limits von Gemini, schlug stillschweigend fehl, versuchte es zu aggressiv erneut und verbrannte ungefähr $250, bevor ich es bemerkte. Es gab keinen dramatischen Absturz. Die Ausgabe sah auf den ersten Blick immer noch normal genug aus. Das System versuchte es weiter, schlug fehl und stellte Rechnungen aus.

Die Lektion war praktischer Natur. Ich hatte dem Modell ein saubereres Problem übergeben, als ich tatsächlich hatte. Das reale Problem umfasste Übersetzungsqualität unter Kostenlimits, Ratenbegrenzungen, theologische Terminologieregeln, Anforderungen an die Admin-Überprüfung und Fehlermodi, die sichtbar sein mussten. Als ich das verstanden hatte, änderte ich die Art und Weise, wie ich nicht-triviale KI-Aufgaben formuliere.

Bevor die Generierung beginnt, versuche ich vier Dinge aufzuschreiben: was unverändert bleiben muss, welche Source of Truth das Modell verwenden soll, welche Fehlermuster Aufmerksamkeit verdienen und wie ich vor der Produktion erkenne, ob etwas nicht stimmt. Für Christian Pure bedeutete das festgeschriebene Glossarbegriffe, sprachspezifische Vermeidungslisten und Prüfungen auf unübersetztes Englisch, nachdem das Modell die Ausgabe zurückgegeben hatte. Das Modell war immer noch nützlich und arbeitete endlich innerhalb der realen Form des Problems.

Ich sah dasselbe Problem in Halo. Ich bat Claude Code um Hilfe bei einem spezifischen Android-Audiofokus-Bug im Zusammenhang mit dem Verhalten auf dem Sperrbildschirm. Der Plan, den es zurückgab, war ehrgeizig und in sich stimmig, doch er weitete einen schmalen Fix zu einem breiten Architekturprojekt aus. Das ist eine spezifische Art von KI-Drift: Das Modell löst eine sauberere Version des Problems, indem es den Umfang erweitert. Wenn aus einer kleinen Reparatur ein großes Redesign wird, betrachte ich das jetzt als Warnsignal.

Die Ausgabe muss zum System gehören

Einer der am leichtesten zu übersehenden Fehler ist Arbeit, die so aussieht, als würde sie dazugehören, während sie vom eigentlichen System getrennt bleibt. Die Namen fühlen sich richtig an. Die Form der Komponente ist vertraut. Der Text klingt passend. Dann überprüft man das Ergebnis und stellt fest, dass es die echten Tokens, Dateien, APIs, Komponenten oder Entscheidungen ignoriert hat, die bereits im Produkt vorhanden sind.

Langweilige Setup-Dateien und Projektkonventionen sind aus diesem Grund wichtig. In Halo gibt eine CLAUDE.md-Datei dem Modell Regeln vor, die es respektieren muss: Projektstruktur, Programmierkonventionen, Architekturnotizen und Bereiche, in denen beiläufige Umschreibungen gefährlich sind. Diese Art von Kontext wird niemals eine beeindruckende Demo abgeben, aber sie verringert die Wahrscheinlichkeit, dass das Modell plausiblen Außenseiter-Code produziert, der der App nur ähnelt.

Ich vermeide es auch, Prosa-Zusammenfassungen von Codeänderungen zu vertrauen. Ich möchte den Diff. Ich möchte sehen, welche Dateien sich geändert haben, welche Imports hinzugekommen sind, ob das Modell mehr berührt hat, als die Aufgabe erforderte, und ob die Lösung in das bestehende Muster passt. Für Flutter-Arbeiten verwende ich Claude Code-Hooks, um Prüfungen wie dart analyze, dart format und flutter test rund um Bearbeitungen auszuführen, mit GitHub Actions als weiteres Tor, bevor Änderungen übernommen werden. Diese Prüfungen ersetzen nicht das Urteilsvermögen. Sie verhindern, dass grundlegende Fehler alles davon aufzehren.

Das ist der praktische Unterschied zwischen der beiläufigen Nutzung von KI und der ernsthaften Überwachung von KI. Ich gestalte die Umgebung rund um die Ausgabe: die Quelldateien, auf die sie verweisen kann, die Einschränkungen, die sie beibehalten muss, die Prüfungen, die sie bestehen muss, und den Überprüfungspfad, den sie durchläuft, bevor ich ihr vertraue.

Die Herkunft ist am wichtigsten, wenn der Text gut klingt

KI ist nützlich, weil sie Lücken füllen kann. Dieselbe Fähigkeit macht sie gefährlich, wenn die Arbeit auf Wahrheit angewiesen ist. Plausibles Material und fundiertes Material kommen oft im selben selbstbewussten Tonfall daher, was bedeutet, dass der Text genau dann am überzeugendsten wirken kann, wenn er am meisten überprüft werden muss.

Darauf stieß ich beim Entwerfen einer Halo-Fallstudie. Der erste Durchgang hatte eine gute Struktur und enthielt echte Details aus unserem Gesprächsverlauf. Einige der am besten klingenden Abschnitte hatten jedoch keine Beweise hinter sich: eine Namensgeschichte, eine Entscheidung zum Kunststil, ein Migrationsmoment. Das Modell hatte fehlende Informationen mit einer plausiblen Erzählung geglättet. Es las sich gut, und Teile davon waren nicht wahr.

Dieser Fehler hat verändert, wie ich KI-gestütztes Schreiben und Recherchieren überprüfe. Ich frage, woher eine Behauptung stammt, bevor ich entscheide, ob sie gut klingt. Kam sie aus meinen Notizen, einem Transkript, einem Repo, einer Quelle oder dem Versuch des Modells, die Geschichte flüssiger zu machen? Wenn ein Modell mir Marktzahlen, Keyword-Daten oder eine selbstbewusste strategische Behauptung liefert, möchte ich eine nachvollziehbare Quelle. Wenn es keine liefern kann, behandle ich die Behauptung als Schlussfolgerung.

Das gilt auch für Code. Wenn ein Modell auf eine API, ein Paketverhalten oder eine Projektmethode verweist, möchte ich wissen, ob diese existiert. „Fühlt sich an, als sollte es existieren“ ist ein schlechter Grund, irgendetwas zu vertrauen. Plausibilität ist keine Herkunft, und bei polierten Ausgaben ist die Herkunft oft am wichtigsten.

Gute Demos verbergen Schwachstellen

Saubere Prompts lassen KI besser aussehen, als sie ist. Saubere Screenshots, saubere Eingaben, saubere Tests und saubere Demos tun dasselbe. Die reale Nutzung ist chaotischer. Benutzer sind vage. Inhalte fehlen. Geräte sind klein. APIs fallen aus. Berechtigungen werden seltsam. Alte Zustände verweilen an Orten, an die niemand gedacht hat, sie zu überprüfen.

Das Room-Styler-Projekt machte dies offensichtlich. Einige generierte Layouts waren nicht auf dramatische Weise kaputt. Sie hatten Möbel, Stil und genug Feinschliff, um einem flüchtigen Blick standzuhalten. Das Problem war die Produktbeurteilung: Der Maßstab stimmte nicht, Gästezimmer wirkten unrealistisch, und einige Layouts sahen akzeptabel aus, bis man bemerkte, dass sie die Laufwege blockierten. Nichts stürzte ab. Die Ausgabe war einfach auf eine Weise falsch, die bei einer allgemeinen visuellen Überprüfung übersehen werden würde.

Das hat meine Denkweise über vorhersehbare KI-Fehler verändert. Wenn ein System nach einem Muster versagt, versuche ich, nicht jeden Fall als neues Ärgernis zu behandeln. Ich frage, welche Leitplanke fehlt. Muss der Prompt expliziter sein? Sollte es einen zweiten Durchgang geben? Sollte das System auf blockierte Türen, nicht unterstützte Behauptungen, unübersetzte Zeichenfolgen, Kostenspitzen oder einen erweiterten Umfang prüfen? Ich erwarte nicht, dass KI perfekt wird. Ich erwarte jedoch, dass mein Workflow nicht mehr zweimal vom selben Fehler überrascht wird.

Die Überprüfungen sollten den Risiken folgen, die Benutzer tatsächlich spüren. Ein Raumlayout, das Laufwege blockiert, zerstört das Vertrauen in das Tool. Ein Kauf-Bug betrifft Geld. Ein falsch übersetzter religiöser Begriff verändert die Bedeutung. Diese Fehler gehören in unterschiedliche Risikokategorien, und der Überprüfungsprozess sollte sie unterschiedlich behandeln.

Fehler müssen sichtbar sein

Stilles Versagen ist der Teil, der mich am meisten beunruhigt. Herkömmliche Software kann ebenfalls still versagen, aber ihre Fehlermodi sind oft leichter zu lokalisieren, weil das System deterministischer ist. KI-Systeme sind schwieriger, weil die Ausgabe flüssig und wohlgeformt bleiben kann, selbst wenn die zugrunde liegende Operation fehlgeschlagen ist. Das Format bleibt sauber, der Ton bleibt ruhig und die Oberfläche bleibt überzeugend.

Bevor ich einem KI-Workflow vertraue, möchte ich wissen, wie ich bemerke, wenn er kaputtgeht. Für das Übersetzungs-Plugin bedeutet das, API-Aufrufe und Kosten zu protokollieren, das Wiederholungsverhalten zu überprüfen, die Ausgaben zu deckeln und Ausgaben zu markieren, die anscheinend noch Englisch enthalten. Erkennung kommt vor Wiederherstellung. Wenn ich den Fehler nicht sehen kann, kann ich ihn nicht rechtzeitig beheben.

Für Halo ist das Äquivalent ein mehrschichtiger Überprüfungspfad. Statische Überprüfungen fangen einige Probleme ab. Tests fangen andere ab. Ein fokussierter Gutachter-Durchgang ist nützlich für Änderungen, die Kauflogik, Audioverhalten oder andere Hochrisikobereiche betreffen. Tests auf echten Geräten sind wichtig, weil sich emulator-sauberes Verhalten von benutzer-sauberem Verhalten unterscheiden kann, insbesondere auf älterer Android-Hardware.

Nichts davon hat den Nervenkitzel eines schnellen Prototyps. Es sind Logs, Tests, Diffs, Review-Warteschlangen, CI-Gates, Staging, Kostenobergrenzen, Retry-Inspektionen und Geräteprüfungen. Es ist aber auch das Gerüst, das verhindert, dass KI-Output stillschweigend zu einem Risiko wird.

Überprüfungen sollten mit dem Risiko skalieren

Ich wende nicht auf alles das gleiche Maß an Prüfung an. Das würde die Arbeit langsam und mühsam machen. Wegwerf-Texte werden nur flüchtig geprüft. Eine kleine UI-Anpassung wird auf Passgenauigkeit und offensichtlichen Unsinn kontrolliert. Alles, was mit Geld, Nutzervertrauen, Produktionsdaten, veröffentlichten Behauptungen oder einem zentralen Produktablauf zu tun hat, wird viel aggressiver überprüft.

Bei Output mit geringem Risiko frage ich mich meistens, ob er vernünftig aussieht und ins System passt. Bei Arbeiten mit mittlerem Risiko füge ich Fragen hinzu, ob die eigentliche Aufgabe gelöst, die Einschränkungen respektiert und die unschönen Fälle behandelt wurden. Bei Arbeiten mit hohem Risiko, wie RevenueCat-Kaufcode, mehrsprachigem Publishing oder allem, was echte Kunden und echtes Geld berührt, erwarte ich Fundierung, Fehlererkennung, Kostenbewusstsein und Wartungskosten, die ich auch im nächsten Quartal noch akzeptieren würde.

Dieser letzte Punkt ist wichtig, weil viel KI-Output nach dem ersten Arbeitsschritt stillschweigend versagt. Die Datei funktioniert, ist aber aufgebläht. Die Benutzeroberfläche ist nah dran, aber die Struktur ist falsch. Die Logik bewältigt die Demo, wird dann aber mühsam zu erweitern. Kurzfristige Geschwindigkeit kann zu langfristigem Ballast führen, wenn ich die erste funktionierende Antwort zu leichtfertig akzeptiere.

Was sich für mich geändert hat

Ich mag immer noch Geschwindigkeit. Ich mag immer noch Feinschliff. Ich mag es immer noch, in Minuten statt in Stunden einen starken ersten Entwurf zu bekommen. Ich vertraue diesen Signalen jedoch weniger als früher, weil ich gesehen habe, wie oft sie vor der Zuverlässigkeit eintreffen.

Die Frage, die ich mir jetzt stelle, ist einfach: Was würde mich davon überzeugen, dass diese Ausgabe es verdient, freigegeben zu werden? Diese Frage verlagert die Arbeit weg von isolierten Prompts und hin zu Systemen: Akzeptanzkriterien, Quellenbasierung, Projektkontext, automatisierte Prüfungen, Review-Pfade, Kostenkontrollen und Praxistests. Das Modell ist immer noch wichtig, aber das Vertrauen wird im Workflow rund um das Modell verdient.

Ein erster Entwurf ist leichter zu bekommen als früher. Die schwierigere Arbeit besteht darin, ein ausreichendes Gerüst um mein Urteilsvermögen herum aufzubauen, sodass ich es wiederholen kann, wenn ich müde bin, schnell arbeite oder auf eine Ausgabe starre, die fertiger aussieht, als sie tatsächlich ist.