Deine Tests teilen den blinden Fleck deines Codes. Hier ist der Ausweg.
Irgendwo in deiner Codebase gibt es eine Funktion, deren Tests grün sind und deren Verhalten falsch ist. Nicht laut falsch — leise falsch: bei Eingaben, die niemand aufgezählt hat, unter einer Lesart der Absicht, von der niemand wusste, dass sie eine Lesart war. Wer 2026 ein Engineering-Team führt, trägt diesen Verdacht täglich. Als Anthropic 400.000 Sessions seines eigenen Coding-Agenten vermaß, löste jeder menschliche Prompt rund zehn Modell-Aktionen und etwa 2.400 Wörter Output aus (Anthropic, Juni 2026) — das liest niemand alles. Die grünen Häkchen bedeuten nicht mehr, was sie einmal bedeuteten.
Der Verdacht ist richtig. Und er ist kein Versagen — nicht deins, nicht das deines Teams. Er ist eine strukturelle Eigenschaft der Art, wie Code und Tests entstehen. Und er hat eine strukturelle Korrektur.
Warum mehr Tests die Lücke nicht schließen
Nimm eine Funktion, deren Docstring sagt: convert gallons to litres. Vier Modelle, unabhängig voneinander gefragt, implementierten die US-Gallone — still. Kein Fehler, kein Kommentar, grüne Tests. Es gibt zwei Gallonen, US und imperial, fast 20 % auseinander. Und der Docstring war nicht einmal stumm dazu: litres ist britische Schreibweise — ein Entwickler, der litres statt liters schreibt, meint plausibel die imperiale Gallone. Die Modelle defaulteten trotzdem auf US. Der Defekt liegt nicht in der Arithmetik. Er sitzt in einer Frage, von der niemand wusste, dass sie offen war — und der Prior hat die Lücke nicht bloß gefüllt, er hat den einen Hinweis überfahren, den der Docstring gab.
Woher kommt so ein Helper 2026 überhaupt? Niemand schreibt convertToLitres(gallons) von Hand und lässt ein Modell den Rumpf ausfüllen. Er entsteht mitten in der Kette: Eine Story sagt, der UK-Markt will den Verbrauch in Litern, ein Agent entscheidet, dass hier eine Umrechnung hingehört, und Funktion, Docstring, Rumpf und Tests kommen in einem Durchgang — die Einheiten-Frage entschieden, still, drei Ebenen unter allem, was ein Mensch angesehen hat. Der eine menschliche Checkpoint, der bleibt, ist das PR-Review — und genau dort rutscht diese Zeile durch: Ein Kollege — in Sofia, nicht in London — sieht return gallons * 3.785, erkennt die Zahl von irgendwoher wieder und approved. Die Zeile sieht zu trivial aus, um falsch zu sein. Die Trivialität ist die Tarnung.
Ein Test kann nur eine Frage stellen, die seinem Autor eingefallen ist. Wenn Tests und Code aus derselben Lesart der Absicht entstehen — zunehmend vom selben Modell, im selben Durchgang — stimmen sie einander bauartbedingt zu. Grün heißt: konsistent mit der geteilten Lesart. Es heißt nicht: korrekt. Und mehr Tests aus dem Inneren dieser Lesart addieren Volumen, keine Prüfschärfe: Der hundertste Test weiß über die zweite Gallone exakt so viel wie der erste.
Warum eine zweite KI-Meinung es auch nicht tut
Der Reflex ist, ein weiteres Modell auf den Code zu richten. Aber ein Prüfer, der seine Meinung aus dem Code ableitet, erbt dessen blinden Fleck: Was beim Schreiben missverstanden wurde, wird beim Prüfen genauso missverstanden. Und ein Modell zu drängen, mehr wie ein Reviewer zu schlussfolgern, macht sein Verdikt unzuverlässiger — in einer Studie von 2025 über drei Frontier-Modelle ließ der Zwang zu erklärtem Verdikt samt Korrekturvorschlägen die Treffsicherheit im schlimmsten Fall von 52 % auf 11 % einbrechen (Jin & Chen, ASE 2025). Das Verdikt darf keinem Modell gehören.
Ein Standard, den der Code nicht kontaminieren kann
Eine unabhängige Prüfung braucht eine Referenz, die der Code nicht geformt hat. agetra leitet sie aus der artikulierten Absicht her — Signatur und Docstring der Funktion — ohne je den Rumpf zu lesen. Allein aus dieser Absicht schlägt es einen Standard vor: konkrete, ausführbare Eigenschaften, die das Verhalten halten muss. Der Standard wird eingefroren, dann wird der Code auf der CPU dagegen gefeuert, deterministisch — gleiche Eingaben, gleiches Verdikt, jeder Lauf. Ein Modell ist genau einmal beteiligt: um vorzuschlagen. Es richtet nie.
Zweierlei folgt daraus. Weil der Standard die Implementierung nie gesehen hat, kann er ihre Fehler nicht geerbt haben — die Kontamination, die deine eigenen Tests bauartbedingt tragen, ist gekappt. Und weil die Herleitung nichts liest außer Signatur und Docstring, ist das auch das Einzige, was deine Maschine je verlässt: eine rumpf-freie Beschreibung der Absicht. Die Implementierung bleibt lokal.
Das Verdikt kommt in drei Zuständen zurück — konform, abweichend, nicht entscheidbar — pro Verhaltens-Klausel, nicht als Score. Wo es Zähne hat, sagt es das. Wo es nicht entscheiden kann, sagt es das — statt zu raten. Und es ist mit Absicht konservativ: Eine Klausel, an der es zweifelt, wird gedroppt, nicht gefeuert — der Record gesteht eine Lücke ehrlich in seinen ausgewiesenen Grenzen ein, während ein Fehlalarm dich nur lehren würde, das Rot zu ignorieren.
Was diese Korrektur nicht kann — offen gesagt
Es wäre bequem, hier aufzuhören und den Standard „unvoreingenommen" zu nennen. Er ist nicht unvoreingenommen. Er ist anders begrenzt — und der Unterschied gehört exakt benannt, denn er ist der ehrliche Kern der Methode.
Deine Tests sind begrenzt durch die Priors dessen, der den Code schrieb — Mensch oder Modell. Ein code-blinder Standard ist begrenzt durch die Priors des Modells über den Docstring: Zeig einem Modell parses a date string, und es liest tendenziell ISO 8601, weil das die dominante Lesart ist — womöglich exakt die Annahme, unter der der Rumpf geschrieben wurde. Die Herleitung zu wiederholen und nur zu behalten, worauf unabhängige Modell-Familien sich einigen, verengt diese Flanke, schließt sie aber nicht: Konsens misst Übereinstimmung, nicht Wahrheit. Eine Lesart, die universell genug ist, dass jedes Modell sie teilt, überlebt jede Abstimmung.
Also beantwortet agetra die Frage „was war gemeint?" nicht. Nichts kann das — nicht mehr Modelle, nicht höhere Einigkeit. Stattdessen friert es ein, was angenommen wurde, und macht daraus die eine Frage, die ein Mensch tatsächlich beantworten kann: „War das gemeint?" Der Contract listet die Lesarten, auf die die Herleitung sich festgelegt hat, als benannte assumptions — las „date string" als ISO 8601 — und der Record druckt den Eingabe-Raum, der wirklich exploriert wurde. Ein geteilter Prior ist im Verdikt still; im Record steht er schriftlich. Ein Bound daran, ausgesprochen statt versteckt: Die Aufzählung selbst teilt den Prior-Blindfleck — ein Modell listet keine Lesart, die es nie als Wahl erlebt hat. Herleitung über Familien verbreitert die Union; das ist struktureller Druck, keine Garantie. Gemessen an der Gallone haben die ankernden Herleitungen ihre Lesart allerdings im Klartext benannt — the standard US gallon to litre conversion factor — das Commitment lag da, bereit zum Einfrieren.
Diese Umkehrung trägt die Methode. Mehrdeutigkeit bleibt unsichtbar — Experten zuallererst — bis eine konkrete Lesart vor ihnen liegt. Selbst das Alltagsvokabular macht mit: Europäer nennen die US-Einheiten beiläufig „das imperiale System" — dabei ist die imperiale Gallone genau die, die die USA nicht benutzen. Der Gallonen-Docstring las sich für jeden und alles, was ihn berührte, als offensichtlich; in dem Moment, in dem „nahm die US-Gallone an" dasteht, sieht jeder mit Domänenwissen den Fehler. Eine falsche Lesart wiederzuerkennen ist billig. Eine ungeschriebene zu erraten ist unmöglich. Und auch der Reviewer in Sofia hat etwas wiedererkannt — die Konstante, nicht die Lesart. Wiedererkennen schützt nur, wenn es auf die Lesart zeigt.
Dieselbe Stelle liefert ein zweites Instrument. Die Herleitung läuft mehrfach; wo die Absicht dünn ist, widersprechen sich die Läufe — und dieser Widerspruch wird selbst ausgewiesen: als Messung, wie unterspezifiziert die Absicht ist. Ein Docstring, der sich nicht stabil lesen lässt, ist kein Rauschen im Prozess. Er ist der Befund: Die Prüfung zeigt dir, wo „was wir meinten" nie aufgeschrieben wurde.
Führ den Bogen zurück zur Gallone, ohne Polster. Wenn die wiederholten Lesarten an so einem Hinweis splitten, hält die Prüfung an und erzwingt die Frage — das ist der konstruierte gute Fall. Wir haben die Herleitung auf genau diesen Docstring gefeuert, neun Läufe über drei Modell-Familien, um zu sehen, welcher Fall die Gallone wirklich ist: Keine Lesart splittete. Jede Herleitung, die ankerte, wählte die US-Gallone; die britische Schreibweise bewegte keinen der neun Läufe. Am eigenen Flaggschiff-Beispiel ist der ehrliche Zweig also der konzedierte: Das Verdikt kommt grün zurück und bleibt still. Eine Fehllesart, die jedes Modell teilt und niemand hinterfragt, wird nicht detektiert — nicht hier, nirgends. Was bleibt, ist keine Detektion, und es ist nicht nichts: nahm die US-Gallone an steht im Record, neben dem Namen, der es bestätigt hat. An dem Tag, an dem die UK-Beschwerde eintrifft, ist die Ursache ein Lookup in einem zuordenbaren Record, keine Archäologie durch ein Jahr an Diffs. Das heißt „Ausweg" hier, exakt gesagt: nicht jede falsche Lesart gefangen — jede Lesart besessen, schriftlich, mit Namen.
Was sie von dir verlangt
Wo die Prüfung nicht entscheiden kann, hält sie an und fragt — eine benannte Person, eine konkrete Frage. Die Antwort kostet Wiedererkennen, keine Autorenschaft: Du bestätigst oder korrigierst eine ausformulierte Lesart; du schreibst keine formale Spec vom leeren Blatt. Jede Antwort wird in die nächste Version der Absicht eingefroren, zugeordnet und aktenkundig. Mit der Zeit sammelt die Absicht genau die menschlichen Entscheidungen ein, die der erste Generierungs-Durchgang nie enthielt.
Auch die Lese-Last skaliert nicht wie eine Review-Queue. Enumerierte Lesarten entdeckst du nicht durch das Nachlesen grüner Reports: Sie werden dir einmal vorgelegt, wenn die Version der Absicht ratifiziert wird — die Farbe des Verdikts spielt dabei keine Rolle. Eine bestätigte Lesart bindet an diese Version und ist eingefroren — Re-Runs nutzen sie wieder, und die Frage kehrt erst zurück, wenn die Absicht sich ändert. Erzwungen wird ein Mensch nur dort, wo die wiederholten Herleitungen sich widersprechen; alles andere fährt im Record mit, aktenkundig für den Tag, an dem eine davon zählt. Und das Nicken selbst ändert sich: Ein Review-Approval verschwindet in einer Timeline; eine bestätigte Lesart trägt einen Namen.
Diese Teilung ist keine Hoffnung; so teilt sich die Arbeit bereits. In derselben 400.000-Sessions-Messung trafen Menschen rund 70 % der Planungs-Entscheidungen und das Modell rund 80 % der Ausführungs-Entscheidungen — und was einen erfolgreichen Ausgang vorhersagte, war Beherrschung der Domäne, kein Coding-Hintergrund (Anthropic, Juni 2026). Anthropics Analysten bewerten die Expertise eines Nutzers sogar teilweise danach, was er den Agenten zu verifizieren bittet.
Das ist die Arbeitsteilung, die sich zu behalten lohnt. Die Maschinen schreiben den Code und verhören den Code. Menschlich bleibt der knappe Teil — zu entscheiden, was korrekt bedeutet, eine bestätigte Lesart nach der anderen — und der Record zeigt, dass die Entscheidungen deine waren.
Warum das jetzt zählt
Ab dem 9. Dezember 2026 behandelt die EU-Produkthaftungsrichtlinie Software als Produkt, und bei hinreichend komplexen Systemen kann sich die Beweislast zum Hersteller verschieben. Wenn diese Seite der Frage auch deine ist, hat sie ihr eigenes Thema, Legally Defensible Code (ein Begleit-Dossier, in Vorbereitung). Und was ein Sorgfalts-Record Feld für Feld enthält, ist das Auditor-Dossier: KI-generierten Code auditieren →
Scope & Status
agetra ist pre-launch. Die erste Version verifiziert pure, deterministische Python-Logik — Funktionen, deren Ausgabe allein von ihren Eingaben abhängt. Die Grenze wird erkannt, nicht unterstellt: Code mit Seiteneffekten (I/O, Uhr, Zufall, globaler State) wird als out-of-scope markiert statt still mitgedeckt. Die Methode — Absicht rein, rumpf-blinder Standard raus, deterministisches Verdikt — ist nicht Python-spezifisch; das Versprechen der ersten Version ist es bewusst. Wenn „grün, aber nicht getraut" deine Codebase beschreibt — trag dich in die Waitlist ein. Der Rumpf deines Codes verlässt deine Maschine nie.
Häufige Fragen
Warum sind meine Tests grün, obwohl der Code falsch ist?
Weil Tests und Code aus derselben Lesart der Absicht geschrieben wurden — oft vom selben Modell, im selben Durchgang — und einander deshalb bauartbedingt zustimmen. Ein Test kann nur eine Frage stellen, von der sein Autor wusste, dass sie offen ist. In einem gemessenen Fall sagte der Docstring convert gallons to litres; vier Modelle implementierten still die US-Gallone, Tests grün — obwohl litres die britische Schreibweise ist und auf die imperiale Gallone deutet, fast 20 % größer. Nichts wies die Wahl aus. Grün heißt konsistent mit der geteilten Lesart — nicht korrekt.
Ist das nicht wieder nur KI, die KI prüft?
Nein — aber nicht aus dem Grund, den man erwartet, und die ehrliche Version ist stärker als die Marketing-Version. Ein Modell ist beteiligt: Es schlägt den Standard vor, einmal, aus Signatur und Docstring, ohne den Rumpf zu lesen. Weil es die Implementierung nie sieht, kann es deren Fehler nicht erben — das kann ein LLM-Code-Review von sich nicht sagen. Was es mitbringt, sind seine eigenen Priors über den Docstring: Bei parses a date string nimmt ein Modell tendenziell ISO 8601 an — womöglich dieselbe Annahme, die das rumpf-schreibende Modell traf. Herleitung über mehrere Modell-Familien und Konsens verengen das, aber Konsens misst Übereinstimmung, nicht Wahrheit; ein universeller Prior überlebt jede Abstimmung. Der Standard ist also anders begrenzt, nicht unbegrenzt: Deine Tests tragen die Priors des Code-Autors; der Standard trägt die Priors des Modells über die artikulierte Absicht. agetra versteckt den Unterschied nicht — es friert jede Lesart als benannte assumption in den Contract ein und stellt dir die eine Frage, die ein Mensch wirklich beantworten kann: War das gemeint?
Wenn der Prior des Modells die Lücke füllt — stimmt die Prüfung dem Bug dann nicht einfach zu?
Im Verdikt — ja. Die Seite oben sagt es ungepolstert: Eine Lesart, die universell genug ist, dass jede Modell-Familie sie teilt, produziert ein grünes Verdikt und keine Frage, und kein Konsens in irgendeiner Tiefe detektiert sie — denn Konsens misst Übereinstimmung, nicht Wahrheit. Was bleibt, ist das ehrliche Produkt, in drei Teilen. Wo die wiederholten Herleitungen splitten statt übereinzustimmen, hält die Prüfung an und erzwingt die Entscheidung einer benannten Person — dieses Gate fängt jede Mehrdeutigkeit, die die Familien nicht teilen. Jede Lesart, erzwungen oder nicht, steht schriftlich im Contract, mit dem Namen, der sie bestätigt hat. Und wenn die Realität später widerspricht — die Beschwerde aus dem Markt, dessen Gallone es nicht war —, ist die Ursache ein Lookup in einem zuordenbaren Record, keine Archäologie. Detektion einer universell geteilten Fehllesart wird nirgends behauptet; besessene, auffindbare Commitments schon.
Was passiert, wenn die Prüfung nicht entscheiden kann?
Sie sagt es — nicht entscheidbar ist einer ihrer drei Verdikt-Zustände, kein Ausfall, der übertüncht wird. Sie hält an, benennt, was mehrdeutig oder unlesbar war, und lässt eine benannte Person auflösen: eine konkrete, ausformulierte Lesart bestätigen oder korrigieren. Die Auflösung wird in die nächste Intent-Version eingefroren, zugeordnet und aktenkundig. Instabilität über wiederholte Herleitungen wird selbst ausgewiesen — als Messung, wie unterspezifiziert die Absicht ist. Oft ist das der erste wirklich nützliche Output: Er zeigt, wo „was wir meinten" nie aufgeschrieben wurde.
Verlässt mein Code meine Maschine?
Der Rumpf — die Implementierung — nie. Was quert, ist eine rumpf-freie Beschreibung der Absicht: Signatur und Docstring der Funktion, aus denen der Standard hergeleitet wird. Das Verdikt läuft danach lokal auf der CPU gegen die eingefrorenen Artefakte. Das beschreibt, was die Prüfung per Konstruktion liest und sendet — es ist keine pauschale Security-Garantie.
Muss ich erst formale Specs schreiben?
Nein. Die Prüfung startet mit dem, was du hast: Signaturen und Docstrings. Wo sie genug Absicht tragen, wird daraus ein Standard hergeleitet; wo sie zu dünn sind, tut die Prüfung nicht so, als ob — sie weist die Unterspezifikation aus und stellt konfirmierbare Fragen. Du antwortest durch Wiedererkennen von Lesarten, nicht durch Autorenschaft in einer Spec-Sprache. Jede Antwort schärft die aktenkundige Absicht; diese wachsende Präzision ist der Punkt, keine Voraussetzung.
Was kann es heute verifizieren?
Version eins: pure, deterministische Python-Logik — Funktionen, deren Ausgabe allein von ihren Eingaben abhängt. Die Grenze wird erkannt statt geglaubt: Code mit Seiteneffekten (I/O, Uhr, Zufall, globaler State) wird als out-of-scope markiert, nicht still mitgezählt. Die Methode ist sprachunabhängig; das Versprechen der ersten Version ist es bewusst nicht.