{"id":2653,"date":"2026-04-20T11:43:59","date_gmt":"2026-04-20T11:43:59","guid":{"rendered":"https:\/\/jamalnichols.com\/?p=2653"},"modified":"2026-05-26T11:43:19","modified_gmt":"2026-05-26T11:43:19","slug":"ai-validation","status":"publish","type":"post","link":"https:\/\/jamalnichols.com\/de\/ai-validation\/","title":{"rendered":"Wie ich entscheide, ob KI-Output mein Vertrauen verdient"},"content":{"rendered":"

Vom Prompting zur \u00dcberwachung<\/h2>\n\n\n\n

Das erste Mal, dass mir das wirklich klar wurde, war bei der \u00dcberpr\u00fcfung deutscher \u00dcbersetzungen eines benutzerdefinierten, von Gemini angetriebenen Plugins, das ich entwickelt hatte f\u00fcr Christian Pure<\/a>. Die Admin-Tabelle sah normal aus. Die Zeilen waren gef\u00fcllt. Die Auftr\u00e4ge waren als abgeschlossen markiert. Aus der Ferne sah es so aus, als h\u00e4tte das System die Arbeit erledigt.<\/p>\n\n\n\n

Dann \u00f6ffnete ich ein paar Beitr\u00e4ge 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\u00e4che hatte diesen Fehler unauff\u00e4llig aussehen lassen.<\/p>\n\n\n\n

Dieser Fehler hat meine Sichtweise auf KI-gest\u00fctzte Arbeit ver\u00e4ndert. Ein ausgef\u00fclltes Feld ist keine \u00dcbersetzung. Ein gerenderter Bildschirm ist kein Produkt. Eine koh\u00e4rente Antwort ist nicht dasselbe wie eine korrekte Antwort. KI ist sehr gut darin, Artefakte zu produzieren, die wie Fortschritt aussehen: \u00fcbersetzt wirkende Zeilen, plausibler Code, aufger\u00e4umte Bildschirme, polierte Zusammenfassungen. Wenn ich m\u00fcde bin oder schnell arbeite, kann diese \u00c4hnlichkeit ausreichen, um mich f\u00fcr einen Moment zu t\u00e4uschen.<\/p>\n\n\n\n

Da h\u00f6rte ich auf, Prompting als den Kern der F\u00e4higkeit zu betrachten. Prompting ist immer noch wichtig, aber die wichtigere Arbeit ist die \u00dcberwachung: zu entscheiden, was Erfolg bedeutet, bevor die Generierung beginnt, das Modell im realen System zu verankern und Pr\u00fcfungen zu erstellen, die flie\u00dfende Fehler sichtbar machen, bevor sie die Nutzer erreichen.<\/p>\n\n\n\n

Manchmal nennt man diese umgebende Schicht ein Harness (Ger\u00fcst). Ich hatte dieses Wort nicht im Kopf, als ich den Christian Pure-Workflow erstellte, aber genau das ist daraus geworden. Gemini generierte die \u00dcbersetzungen. Ein theologisches Glossar schr\u00e4nkte Schl\u00fcsselbegriffe ein. Pr\u00fcfungen nach der \u00dcbersetzung suchten nach englischen \u00dcberbleibseln. API-Protokolle und Ausgabenlimits machten es einfacher, Fehler zu erkennen. Die Admin-\u00dcberpr\u00fcfung hielt die Ausgabe von der Produktion fern, bis jemand sie \u00fcberpr\u00fcfen konnte.<\/p>\n\n\n\n

Der Gro\u00dfteil meiner KI-Arbeit findet in dieser unordentlichen Mitte zwischen Produkt, Design und Implementierung statt. Ich habe an einer Gute-Nacht-App f\u00fcr Kinder mit Kaufprozessen und mehrsprachigem Audio gearbeitet, an einem WordPress-\u00dcbersetzungssystem, das Tausende von Beitr\u00e4gen abdeckt, und an einem Raumvisualisierer, bei dem r\u00e4umliche 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\u00e4nkungen es beibehalten hat, was sich im Diff ge\u00e4ndert hat, welche Pr\u00fcfungen bestanden wurden und wie ein Fehler aussehen w\u00fcrde, wenn das Modell falsch l\u00e4ge.<\/p>\n\n\n\n

Die Aufgabe geht tiefer als die sichtbare Ausgabe<\/h2>\n\n\n\n

F\u00fcr Christian Pure war die Aufgabe gr\u00f6\u00dfer als nur Text in einer anderen Sprache zu generieren. Die eigentliche Aufgabe bestand darin, einer gro\u00dfen mehrsprachigen Website zu helfen, sich koh\u00e4rent anzuf\u00fchlen, ohne die Verwaltung in permanente Aufr\u00e4umarbeit zu verwandeln. Wenn eine deutsche Seite immer noch englische \u00dcberbleibsel enth\u00e4lt, hat das System eine nicht-leere Ausgabe produziert, aber keine \u00fcbersetzte Seite.<\/p>\n\n\n\n

Dieser Unterschied zeigt sich \u00fcberall. Ein Modell kann ein Feld ausf\u00fcllen, einen Bildschirm rendern oder eine strukturierte Antwort zur\u00fcckgeben und dabei den Sinn der Arbeit verfehlen. Die tiefere Frage ist, ob das Artefakt die Aufgabe erf\u00fcllt hat, auf die es ankommt. Hat die \u00dcbersetzung die Bedeutung bewahrt? Hat der Code den Fehler behoben, der das eigentliche Problem verursacht hat? Hat das Design die reale Umgebung des Nutzers unterst\u00fctzt und nicht nur den sauberen Demo-Pfad?<\/p>\n\n\n\n

Nach dem \u00dcbersetzungsfehler begann ich, KI-Ausgaben als nicht vertrauensw\u00fcrdige Zwischenarbeit zu behandeln. F\u00fcr das Plugin bedeutete das explizite Pr\u00fcfungen auf un\u00fcbersetzte englische Zeichenfolgen, eine strengere \u00dcberpr\u00fcfung abgeschlossener Zeilen und eine genauere \u00dcberwachung des API-Verhaltens. Der Workflow war nicht l\u00e4nger eine Anfrage nach \u00dcbersetzung, sondern wurde zu einem System, in dem schlechte \u00dcbersetzungen einen Ort hatten, an dem sie auftauchen konnten.<\/p>\n\n\n\n

Dasselbe Muster zeigt sich beim Code. Ein Modell kann Flutter-Code generieren, der kompiliert, w\u00e4hrend es den RevenueCat-Sonderfall ignoriert, der den Kauf-Bug verursacht hat. Es kann einen sauberen Implementierungsplan erstellen, der die eigentliche Einschr\u00e4nkung \u00fcbersieht. Es kann einen Bildschirm bauen, der im normalen Entwicklungspfad gut aussieht und dann auf einem \u00e4lteren Android-Ger\u00e4t oder beim Audio-Verhalten auf dem Sperrbildschirm fehlschl\u00e4gt. Bevor ich der Ausgabe vertraue, formuliere ich die Aufgabe in einfacher Sprache neu und pr\u00fcfe, ob das Artefakt diese Aufgabe gel\u00f6st hat, einschlie\u00dflich der unsch\u00f6nen Teile.<\/p>\n\n\n\n

Beschr\u00e4nkungen m\u00fcssen explizit sein<\/h2>\n\n\n\n

Viele KI-generierte Arbeiten scheitern, weil die sichtbare Anfrage einfacher ist als die tats\u00e4chliche Einschr\u00e4nkung, die darunter liegt. Das Modell kann die Anweisung erf\u00fcllen und gleichzeitig den Freigabeprozess, Design-Tokens, die Kostenobergrenze, Inhaltsregeln, Ger\u00e4teeinschr\u00e4nkungen, die Architektur oder den Wartungsaufwand verletzen.<\/p>\n\n\n\n

Das \u00dcbersetzungs-Plugin hat mich das auf die harte Tour gelehrt. Die erste Version hatte zu wenig Instrumentierung rund um Fehler, Wiederholungsversuche und Ratenbegrenzungen. Es stie\u00df an die API-Limits von Gemini, schlug stillschweigend fehl, versuchte es zu aggressiv erneut und verbrannte ungef\u00e4hr $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.<\/p>\n\n\n\n

Die Lektion war praktischer Natur. Ich hatte dem Modell ein saubereres Problem \u00fcbergeben, als ich tats\u00e4chlich hatte. Das reale Problem umfasste \u00dcbersetzungsqualit\u00e4t unter Kostenlimits, Ratenbegrenzungen, theologische Terminologieregeln, Anforderungen an die Admin-\u00dcberpr\u00fcfung und Fehlermodi, die sichtbar sein mussten. Als ich das verstanden hatte, \u00e4nderte ich die Art und Weise, wie ich nicht-triviale KI-Aufgaben formuliere.<\/p>\n\n\n\n

Bevor die Generierung beginnt, versuche ich vier Dinge aufzuschreiben: was unver\u00e4ndert 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\u00fcr Christian Pure bedeutete das festgeschriebene Glossarbegriffe, sprachspezifische Vermeidungslisten und Pr\u00fcfungen auf un\u00fcbersetztes Englisch, nachdem das Modell die Ausgabe zur\u00fcckgegeben hatte. Das Modell war immer noch n\u00fctzlich und arbeitete endlich innerhalb der realen Form des Problems.<\/p>\n\n\n\n

Ich sah dasselbe Problem in Halo<\/a>. 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\u00fcckgab, 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\u00f6st eine sauberere Version des Problems, indem es den Umfang erweitert. Wenn aus einer kleinen Reparatur ein gro\u00dfes Redesign wird, betrachte ich das jetzt als Warnsignal.<\/p>\n\n\n\n

Die Ausgabe muss zum System geh\u00f6ren<\/h2>\n\n\n\n

Einer der am leichtesten zu \u00fcbersehenden Fehler ist Arbeit, die so aussieht, als w\u00fcrde sie dazugeh\u00f6ren, w\u00e4hrend sie vom eigentlichen System getrennt bleibt. Die Namen f\u00fchlen sich richtig an. Die Form der Komponente ist vertraut. Der Text klingt passend. Dann \u00fcberpr\u00fcft man das Ergebnis und stellt fest, dass es die echten Tokens, Dateien, APIs, Komponenten oder Entscheidungen ignoriert hat, die bereits im Produkt vorhanden sind.<\/p>\n\n\n\n

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\u00e4ufige Umschreibungen gef\u00e4hrlich sind. Diese Art von Kontext wird niemals eine beeindruckende Demo abgeben, aber sie verringert die Wahrscheinlichkeit, dass das Modell plausiblen Au\u00dfenseiter-Code produziert, der der App nur \u00e4hnelt.<\/p>\n\n\n\n

Ich vermeide es auch, Prosa-Zusammenfassungen von Code\u00e4nderungen zu vertrauen. Ich m\u00f6chte den Diff. Ich m\u00f6chte sehen, welche Dateien sich ge\u00e4ndert haben, welche Imports hinzugekommen sind, ob das Modell mehr ber\u00fchrt hat, als die Aufgabe erforderte, und ob die L\u00f6sung in das bestehende Muster passt. F\u00fcr Flutter-Arbeiten verwende ich Claude Code-Hooks, um Pr\u00fcfungen wie dart analyze, dart format und flutter test rund um Bearbeitungen auszuf\u00fchren, mit GitHub Actions als weiteres Tor, bevor \u00c4nderungen \u00fcbernommen werden. Diese Pr\u00fcfungen ersetzen nicht das Urteilsverm\u00f6gen. Sie verhindern, dass grundlegende Fehler alles davon aufzehren.<\/p>\n\n\n\n

Das ist der praktische Unterschied zwischen der beil\u00e4ufigen Nutzung von KI und der ernsthaften \u00dcberwachung von KI. Ich gestalte die Umgebung rund um die Ausgabe: die Quelldateien, auf die sie verweisen kann, die Einschr\u00e4nkungen, die sie beibehalten muss, die Pr\u00fcfungen, die sie bestehen muss, und den \u00dcberpr\u00fcfungspfad, den sie durchl\u00e4uft, bevor ich ihr vertraue.<\/p>\n\n\n\n

Die Herkunft ist am wichtigsten, wenn der Text gut klingt<\/h2>\n\n\n\n

KI ist n\u00fctzlich, weil sie L\u00fccken f\u00fcllen kann. Dieselbe F\u00e4higkeit macht sie gef\u00e4hrlich, 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 \u00fcberzeugendsten wirken kann, wenn er am meisten \u00fcberpr\u00fcft werden muss.<\/p>\n\n\n\n

Darauf stie\u00df ich beim Entwerfen einer Halo-Fallstudie. Der erste Durchgang hatte eine gute Struktur und enthielt echte Details aus unserem Gespr\u00e4chsverlauf. 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\u00e4hlung gegl\u00e4ttet. Es las sich gut, und Teile davon waren nicht wahr.<\/p>\n\n\n\n

Dieser Fehler hat ver\u00e4ndert, wie ich KI-gest\u00fctztes Schreiben und Recherchieren \u00fcberpr\u00fcfe. 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\u00fcssiger zu machen? Wenn ein Modell mir Marktzahlen, Keyword-Daten oder eine selbstbewusste strategische Behauptung liefert, m\u00f6chte ich eine nachvollziehbare Quelle. Wenn es keine liefern kann, behandle ich die Behauptung als Schlussfolgerung.<\/p>\n\n\n\n

Das gilt auch f\u00fcr Code. Wenn ein Modell auf eine API, ein Paketverhalten oder eine Projektmethode verweist, m\u00f6chte ich wissen, ob diese existiert. \u201eF\u00fchlt sich an, als sollte es existieren\u201c ist ein schlechter Grund, irgendetwas zu vertrauen. Plausibilit\u00e4t ist keine Herkunft, und bei polierten Ausgaben ist die Herkunft oft am wichtigsten.<\/p>\n\n\n\n

Gute Demos verbergen Schwachstellen<\/h2>\n\n\n\n

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\u00e4te sind klein. APIs fallen aus. Berechtigungen werden seltsam. Alte Zust\u00e4nde verweilen an Orten, an die niemand gedacht hat, sie zu \u00fcberpr\u00fcfen.<\/p>\n\n\n\n

Das Room-Styler-Projekt machte dies offensichtlich. Einige generierte Layouts waren nicht auf dramatische Weise kaputt. Sie hatten M\u00f6bel, Stil und genug Feinschliff, um einem fl\u00fcchtigen Blick standzuhalten. Das Problem war die Produktbeurteilung: Der Ma\u00dfstab stimmte nicht, G\u00e4stezimmer wirkten unrealistisch, und einige Layouts sahen akzeptabel aus, bis man bemerkte, dass sie die Laufwege blockierten. Nichts st\u00fcrzte ab. Die Ausgabe war einfach auf eine Weise falsch, die bei einer allgemeinen visuellen \u00dcberpr\u00fcfung \u00fcbersehen werden w\u00fcrde.<\/p>\n\n\n\n

Das hat meine Denkweise \u00fcber vorhersehbare KI-Fehler ver\u00e4ndert. Wenn ein System nach einem Muster versagt, versuche ich, nicht jeden Fall als neues \u00c4rgernis zu behandeln. Ich frage, welche Leitplanke fehlt. Muss der Prompt expliziter sein? Sollte es einen zweiten Durchgang geben? Sollte das System auf blockierte T\u00fcren, nicht unterst\u00fctzte Behauptungen, un\u00fcbersetzte Zeichenfolgen, Kostenspitzen oder einen erweiterten Umfang pr\u00fcfen? Ich erwarte nicht, dass KI perfekt wird. Ich erwarte jedoch, dass mein Workflow nicht mehr zweimal vom selben Fehler \u00fcberrascht wird.<\/p>\n\n\n\n

Die \u00dcberpr\u00fcfungen sollten den Risiken folgen, die Benutzer tats\u00e4chlich sp\u00fcren. Ein Raumlayout, das Laufwege blockiert, zerst\u00f6rt das Vertrauen in das Tool. Ein Kauf-Bug betrifft Geld. Ein falsch \u00fcbersetzter religi\u00f6ser Begriff ver\u00e4ndert die Bedeutung. Diese Fehler geh\u00f6ren in unterschiedliche Risikokategorien, und der \u00dcberpr\u00fcfungsprozess sollte sie unterschiedlich behandeln.<\/p>\n\n\n\n

Fehler m\u00fcssen sichtbar sein<\/h2>\n\n\n\n

Stilles Versagen ist der Teil, der mich am meisten beunruhigt. Herk\u00f6mmliche 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\u00fcssig und wohlgeformt bleiben kann, selbst wenn die zugrunde liegende Operation fehlgeschlagen ist. Das Format bleibt sauber, der Ton bleibt ruhig und die Oberfl\u00e4che bleibt \u00fcberzeugend.<\/p>\n\n\n\n

Bevor ich einem KI-Workflow vertraue, m\u00f6chte ich wissen, wie ich bemerke, wenn er kaputtgeht. F\u00fcr das \u00dcbersetzungs-Plugin bedeutet das, API-Aufrufe und Kosten zu protokollieren, das Wiederholungsverhalten zu \u00fcberpr\u00fcfen, 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.<\/p>\n\n\n\n

F\u00fcr Halo ist das \u00c4quivalent ein mehrschichtiger \u00dcberpr\u00fcfungspfad. Statische \u00dcberpr\u00fcfungen fangen einige Probleme ab. Tests fangen andere ab. Ein fokussierter Gutachter-Durchgang ist n\u00fctzlich f\u00fcr \u00c4nderungen, die Kauflogik, Audioverhalten oder andere Hochrisikobereiche betreffen. Tests auf echten Ger\u00e4ten sind wichtig, weil sich emulator-sauberes Verhalten von benutzer-sauberem Verhalten unterscheiden kann, insbesondere auf \u00e4lterer Android-Hardware.<\/p>\n\n\n\n

Nichts davon hat den Nervenkitzel eines schnellen Prototyps. Es sind Logs, Tests, Diffs, Review-Warteschlangen, CI-Gates, Staging, Kostenobergrenzen, Retry-Inspektionen und Ger\u00e4tepr\u00fcfungen. Es ist aber auch das Ger\u00fcst, das verhindert, dass KI-Output stillschweigend zu einem Risiko wird.<\/p>\n\n\n\n

\u00dcberpr\u00fcfungen sollten mit dem Risiko skalieren<\/h2>\n\n\n\n

Ich wende nicht auf alles das gleiche Ma\u00df an Pr\u00fcfung an. Das w\u00fcrde die Arbeit langsam und m\u00fchsam machen. Wegwerf-Texte werden nur fl\u00fcchtig gepr\u00fcft. Eine kleine UI-Anpassung wird auf Passgenauigkeit und offensichtlichen Unsinn kontrolliert. Alles, was mit Geld, Nutzervertrauen, Produktionsdaten, ver\u00f6ffentlichten Behauptungen oder einem zentralen Produktablauf zu tun hat, wird viel aggressiver \u00fcberpr\u00fcft.<\/p>\n\n\n\n

Bei Output mit geringem Risiko frage ich mich meistens, ob er vern\u00fcnftig aussieht und ins System passt. Bei Arbeiten mit mittlerem Risiko f\u00fcge ich Fragen hinzu, ob die eigentliche Aufgabe gel\u00f6st, die Einschr\u00e4nkungen respektiert und die unsch\u00f6nen F\u00e4lle behandelt wurden. Bei Arbeiten mit hohem Risiko, wie RevenueCat-Kaufcode, mehrsprachigem Publishing oder allem, was echte Kunden und echtes Geld ber\u00fchrt, erwarte ich Fundierung, Fehlererkennung, Kostenbewusstsein und Wartungskosten, die ich auch im n\u00e4chsten Quartal noch akzeptieren w\u00fcrde.<\/p>\n\n\n\n

Dieser letzte Punkt ist wichtig, weil viel KI-Output nach dem ersten Arbeitsschritt stillschweigend versagt. Die Datei funktioniert, ist aber aufgebl\u00e4ht. Die Benutzeroberfl\u00e4che ist nah dran, aber die Struktur ist falsch. Die Logik bew\u00e4ltigt die Demo, wird dann aber m\u00fchsam zu erweitern. Kurzfristige Geschwindigkeit kann zu langfristigem Ballast f\u00fchren, wenn ich die erste funktionierende Antwort zu leichtfertig akzeptiere.<\/p>\n\n\n\n

Was sich f\u00fcr mich ge\u00e4ndert hat<\/h2>\n\n\n\n

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\u00fcher, weil ich gesehen habe, wie oft sie vor der Zuverl\u00e4ssigkeit eintreffen.<\/p>\n\n\n\n

Die Frage, die ich mir jetzt stelle, ist einfach: Was w\u00fcrde mich davon \u00fcberzeugen, 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\u00fcfungen, Review-Pfade, Kostenkontrollen und Praxistests. Das Modell ist immer noch wichtig, aber das Vertrauen wird im Workflow rund um das Modell verdient.<\/p>\n\n\n\n

Ein erster Entwurf ist leichter zu bekommen als fr\u00fcher. Die schwierigere Arbeit besteht darin, ein ausreichendes Ger\u00fcst um mein Urteilsverm\u00f6gen herum aufzubauen, sodass ich es wiederholen kann, wenn ich m\u00fcde bin, schnell arbeite oder auf eine Ausgabe starre, die fertiger aussieht, als sie tats\u00e4chlich ist.<\/p>\n\n\n \r\n \r\n \r\n \r\n

\r\n
<\/div>\r\n <\/div>\r\n \r\n\r\n
\r\n \r\n \r\n
\r\n
\r\n