Die Komplexitätsspirale bei KI-Agenten: Warum 90 % Testabdeckung erforderlich sind

Ich programmiere seit einem Jahr mit KI. Nicht nur Prompting – ich baue echte Software. Zwei Open-Source-Projekte: GStack, das KI-Coding-Agenten verbessert, und GBrain, das alles, was du liest und schreibst, in eine durchsuchbare Wissensdatenbank für deine KI verwandelt. Zusammen rund 970.000 Codezeilen und 665 Testdateien. So gut wie alles geschrieben von Claude Code und Codex auf meine Anweisung hin (meistens 15 gleichzeitige Conductor-Sitzungen).

Letzte Woche habe ich innerhalb von 72 Stunden vierzehn Pull Requests gemerged. Knapp 29.000 Zeilen neuen Codes. Jedes Release war besser getestet als das vorherige.

Das soll angeblich unmöglich sein. Geschwindigkeit und Qualität sollen sich gegenseitig ausschließen. Schnell ausliefern, Dinge kaputt machen. Langsam vorgehen, richtig ausliefern. Such dir eins aus.

Du musst dich nicht mehr entscheiden. Der Schlüssel liegt bei 90 % Testabdeckung – und KI-Agenten haben es kostenlos gemacht, dorthin zu gelangen. Fünfzig Jahre lang kostete dieses Maß an Verifizierung zu viel menschliche Willenskraft, um es aufrechtzuerhalten. Jetzt schreibt der Agent die Tests zusammen mit dem Code. Das Ergebnis nenne ich die Komplexitätsratsche: ein System, das nur besser, niemals schlechter werden kann.

(Dies ist der siebte Teil einer Serie über das Bauen mit KI: 1 2 3 4 5 6

Software war früher spröde

Fünfzig Jahre lang war die gesamte Disziplin des Software-Engineerings um eine Idee herum organisiert: Fehler verhindern, denn Fehler sind katastrophal.

Man musste den Code beim ersten Mal richtig hinbekommen. Einen Randfall übersehen und die Produktion stürzt ab. Eine schlechte Datenbankmigration ausliefern und Kunden Daten verlieren. Eine Funktion schreiben, die etwas Subtiles tut, und wenn die eine Person, die sie versteht, kündigt, weiß niemand, warum sie funktioniert. Das gesamte System hing davon ab, dass Menschen sorgfältig sind, und Menschen sind nicht sorgfältig. Also bauten wir aufwändige Prozesse – Code-Reviews, Staging-Umgebungen, QA-Teams, Release-Züge – alle darauf ausgelegt, Fehler abzufangen, bevor sie die Nutzer erreichten.

Es hat irgendwie funktioniert. Aber es war langsam. Und es bedeutete, dass die Komplexität jedes Softwaresystems eine harte Obergrenze hatte: die Anzahl der Dinge, die ein Team gleichzeitig im Kopf behalten konnte.

Jetzt ist Software geschmeidig

Ich meine nicht schlampig. Ich meine widerstandsfähig auf eine Weise, die vorher nicht möglich war.

Wenn ich sage „die Modelle sind da", meine ich, dass KI-Coding-Agenten – Claude, GPT, Codex und das Ökosystem, das um sie herum wächst – jetzt Code lesen, Kontext verstehen, Fehler diagnostizieren und Korrekturen schreiben können. Nicht perfekt. Aber gut genug, dass sich das Fehlermodell für Software geändert hat.

Die Migration bricht? Der Agent liest die Fehlermeldung, versteht die Datenbankschema-Historie über 45 Versionen hinweg, schreibt die Korrektur, schreibt den Test. Der Dateisync hängt bei einer Million Symlinks? Der Agent diagnostiziert das Parser-Timeout, begrenzt es auf 30 Sekunden, liefert die Korrektur mit Tests aus. Eine Extraktions-Pipeline hat einen Attributionsfehler? Eine modellübergreifende Evaluierung fängt es, der Prompt wird iteriert, die Durchsetzung wird auf Datenbankebene hinzugefügt.

Bei den meisten Fehlern auf Codeebene – Logikfehler, Parsing-Fehler, kaputte Randfälle – können Agenten diese jetzt im nächsten Durchlauf diagnostizieren und beheben. Das ist wirklich neu. Die Fehler, die katastrophal bleiben, sind diejenigen, die den Zustand zerstören: schlechte Migrationen auf Produktionsdaten, Sicherheitslücken, die vor der Erkennung ausgenutzt werden, Datenschutzlecks, die nicht rückgängig gemacht werden können. Die Ratsche hilft auch hier (gute Tests fangen die meisten davon vor der Produktion ab), aber die wirkliche Veränderung ist, dass die überwältigende Mehrheit der Fehler in einer Codebasis von der reparierbaren Sorte ist.

Das ist ein Phasenwechsel dafür, wie Software gebaut wird. Aber es funktioniert nur, wenn man die Ratsche hat.

Die Agent-Komplexitätsratsche

Eine Ratsche ist ein Mechanismus, der Bewegung nur in eine Richtung erlaubt. Ein Steckschlüssel dreht eine Schraube vorwärts und verhindert, dass sie sich zurückdreht. Das ist die Metapher.

In agentencodierter Software fügt jede Codierungssitzung mit einem KI-Agenten der Codebasis drei Dinge hinzu:

1. Tests, die kodieren, was „richtig" bedeutet – automatisierte Prüfungen, die jedes Mal laufen, wenn jemand den Code ändert, und laut scheitern, wenn die Änderung etwas kaputt macht
2. Dokumentation, die festhält, warum Entscheidungen getroffen wurden – nicht nur, was der Code tut, sondern die Begründung und Abwägungen dahinter
3. Evaluierungsergebnisse, die Qualitätsschwellen festlegen – strukturierte Bewertungen der Ausgabequalität mit Punktzahlen, damit du weißt, ob die nächste Version besser oder schlechter ist

Wenn der Agent das nächste Mal an der Codebasis arbeitet, lädt er alle drei in sein Kontextfenster (den Text, den die KI sehen und durchdenken kann). Er kann nicht unter die Testsuite fallen – die Tests würden scheitern. Er kann die Dokumentation nicht ignorieren – sie ist direkt im Kontext. Er kann keine Qualität unter der Evaluierungsbasislinie ausliefern – die Punktzahlen sind aufgezeichnet.

Die Qualitätsuntergrenze steigt mit jedem Durchlauf. Bewegung nur vorwärts. Das ist die Ratsche.

Wie das in der Praxis aussieht

Ich mache das konkret. GBrain ist ein Wissenssystem, das ich baue – es gibt KI-Agenten ein Langzeitgedächtnis, indem es die Notizen, Meetings, Gespräche und Recherchen einer Person speichert, indiziert und durchsucht. Stell es dir als ein zweites Gehirn vor, das dein KI-Assistent tatsächlich lesen kann.

Eine seiner Funktionen ist die epistemologische Extraktion: Es liest Tausende von Seiten und extrahiert, wer was glaubt, mit welcher Sicherheit, im Zeitverlauf. „Garry glaubt, dass Bitcoin 300.000 $ erreichen wird (Sicherheit: 0,45)." „Jared glaubt, dass dieses Startup starke Kundenbindung hat (Sicherheit: 0,80)." So in etwa, aber über 28.000 Seiten hinweg.

Der erste Extraktionsdurchlauf zog 100.720 Behauptungen. Ich habe eine modellübergreifende Evaluierung verwendet, um die Qualität zu bewerten – ich ließ GPT-5.5 und Claude beide die Ausgabe unabhängig bewerten. Insgesamt: 6,8 von 10.

Das größte Problem? Etwas, das ich Halterverwechslung nenne. Nimm die Behauptung „KI wird bis 2027 80 % der Softwareentwickler ersetzen." Wer vertritt diese Überzeugung? Ist es die Person, die es geschrieben hat? Ist es jemand, den sie zitieren? Oder ist es die Analyse-Engine des Systems, die es aus einem Podcast-Transkript abgeleitet hat? Version 1 hat diese Unterscheidung in 35 % der Fälle falsch gemacht. Das ist wichtig – wenn du ein System baust, das verfolgt, was Menschen glauben, musst du wissen, WER es glaubt.

Also wurden die Evaluierungsergebnisse dokumentiert. Sechs spezifische Fehlermodi wurden identifiziert. Der Prompt von Version 2 adressierte alle sechs. Die Gewichtungsrundung (die Sicherheitswerte) wurde auf Datenbankebene durchgesetzt – keine falsche Präzision mehr wie 0,74, wenn 0,75 die ehrliche Antwort ist. Siebzehn Tests haben den Vertrag festgeschrieben.

Jetzt kann keine zukünftige Version der Extraktion ausgeliefert werden, ohne dass diese 17 Tests bestanden werden. Niemand muss sich merken, warum Gewichtungsrundung wichtig ist oder was Halterverwechslung ist. Die Tests erinnern sich.

Die Qualitätsuntergrenze ist dauerhaft gestiegen. Das ist ein Umdrehen der Ratsche.

Warum die meisten Vibecode-Projekte sterben

„Vibecoding" ist Andrej Karpathys Begriff für das Programmieren mit KI, indem man in natürlicher Sprache beschreibt, was man will, und das Modell den Code generieren lässt. Es ist mächtig und so baue ich. Aber nach dem, was ich in YC-Bewerbungen und Open-Source-Repos gesehen habe, beginnen die meisten Vibecode-Projekte, die Tests auslassen, auseinanderzufallen, sobald sie eine moderate Komplexität erreichen – ein paar tausend Zeilen, eine Handvoll interagierender Funktionen.

Sie überspringen die Ratsche. Keine Tests, keine Doks, keine Evals. Der Agent fügt Komplexität hinzu, aber nichts verhindert Regression. Jede neue Funktion hat die Chance, eine alte zu brechen, und ohne Tests erfährst du es erst, wenn ein Benutzer es meldet. Bei Version 0.5 ist die Codebasis ein Spukhaus, in dem jede Änderung etwas Unerwartetes kaputt macht. Dann schreibt der Entwickler einen Blogbeitrag darüber, dass KI-Coding nicht funktioniert.

KI-Coding funktioniert einwandfrei. Sie haben nur die Ratsche nicht gebaut.

Man könnte argumentieren, dass die Art von Person, die Tests schreibt, auch die Art ist, die von vornherein gute Architektur schreibt. Fair. Aber der Ratschemechanismus dreht sich nicht um die Person – es geht darum, was beim nächsten Durchlauf passiert. Wenn ein neuer Mitwirkender einen PR öffnet, oder wenn sich eine Modellversion ändert, oder wenn du um 2 Uhr morgens programmierst und dein Urteilsvermögen beeinträchtigt ist, fangen die Tests Regressionen ab, unabhängig davon, wer sie geschrieben hat. Die Ratsche funktioniert auch dann, wenn der Mensch nicht in Bestform ist. Das ist der Punkt.

Ohne Tests ist Verbesserung ein verrauschter Prozess – Agenten versuchen, Dinge besser zu machen, aber ohne Regressionssignale sind gute Änderungen und schlechte Änderungen gleichermaßen unsichtbar. Mit einer dichten Testsuite erhältst du eine Ratsche auf der getesteten Oberfläche: Die Qualität kann nur für die Verhaltensweisen steigen, die du kodiert hast. Das ist der größte Teil des Systems, nicht alles. Aber es reicht aus, um Vorwärtsbewegung mit hoher Geschwindigkeit aufrechtzuerhalten.

Tests als institutionelles Gedächtnis

In traditionellen Softwareunterbeiten lebt das institutionelle Gedächtnis in Menschen. Der Senior Engineer, der weiß, warum diese Caching-Ebene existiert. Der Architekt, der sich an die Migration erinnert, die fast die Datenbank zerstört hätte. Der Tech Lead, der den seltsamen Randfall im Abrechnungssystem erklären kann.

Menschen gehen. Sie gehen in Rente, sie werden abgeworben, sie brennen aus. Wenn sie gehen, geht das Wissen mit ihnen. Jedes Softwareunternehmen hat die Erfahrung gemacht, eine kritische Datei zu öffnen und einen Kommentar zu finden, der sagt // DAS NICHT ÄNDERN – frag Dave, und Dave ist vor drei Jahren gegangen.

Das Kontextfenster des Agenten kündigt nicht. Es wird nicht abgeworben. Es vergisst nicht. Wenn die Testsuite kodiert „Gewichtungsrundung muss 0,05-Schritte verwenden" und die Dokumentation erklärt „weil die modellübergreifende Evaluierung gezeigt hat, dass falsche Präzision das Vertrauen in die Sicherheitswerte untergräbt", dann ist dieses Wissen dauerhaft. Jeder Agent, jedes Modell, jederzeit kann diesen Kontext laden und die Einschränkung verstehen.

Tests sind institutionelles Gedächtnis, das die Mitarbeiterfluktuation überlebt. Für ein Ein-Personen-Projekt sind sie noch kritischer – sie sind das einzige institutionelle Gedächtnis, das du hast.

Alles, was nutzbar ist, ist testbar

Die Ratsche funktioniert nicht nur für traditionellen Code. Sie funktioniert für alles, was ein Computer beobachten kann.

Denk an die Schichten eines modernen Systems. Das Betriebssystem gibt dir Prozessbäume, Dateisystemzustand, Netzwerk-Sockets, Cron-Jobs. Das Terminal gibt dir jeden Tastendruck, jede Ausgabezeile, jede interaktive Eingabeaufforderung. Der Browser gibt dir gerenderte Seiten, Schaltflächenzustände, Navigationsevents. APIs geben dir strukturierte Antworten, die du parsen und validieren kannst. Und KI-Agenten geben dir beobachtbares Verhalten – was sie sagen, welche Werkzeuge sie aufrufen, in welcher Reihenfolge sie Dinge tun, ob sie fragen, bevor sie handeln.

All das ist nutzbar. Und wenn du es nutzen kannst, kannst du es beobachten. Wenn du es beobachten kannst, kannst du Behauptungen darüber aufstellen. Wenn du Behauptungen darüber aufstellen kannst, kannst du es ratschen.

Das ist eine viel größere Oberfläche als traditionelle Unit-Tests. Lass es mich dir zeigen.

GStack ist mein Open-Source-Coding-Agent-Framework – 93.000 GitHub-Sterne, 701.000 Codezeilen, 46 Skills. Eine seiner Kernfunktionen ist die interaktive Planüberprüfung: Du bittest ihn, deine Architektur zu überprüfen, und er geht Abschnitt für Abschnitt durch den Plan, stellt Fragen, prüft Randfälle, hinterfragt deine Annahmen. Wie ein Engineering Manager, der den Code tatsächlich liest.

Das Problem: Claude Code hat manchmal den gesamten interaktiven Teil übersprungen. Es las die Plan-Datei, spuckte alle Ergebnisse auf einmal aus und beendete sich – ohne dem Benutzer eine einzige Frage zu stellen. Der ganze Sinn der Überprüfung ist der Hin-und-her-Dialog. Das zu überspringen macht den Zweck zunichte.

Wie testet man das überhaupt? Du kannst nicht per Unit-Test prüfen „hat die KI ein Gespräch geführt". Kein traditionelles Test-Framework deckt das ab.

Also habe ich Buns TTY-Funktionalität verwendet, um eine Test-Harness zu bauen (PR #1354), die buchstäblich Claude Code in einem Pseudo-Terminal startet, ihm ein bestimmtes Repo-Szenario füttert, den Review-Skill auslöst und die Terminalausgabe in Echtzeit beobachtet. Der Test beobachtet, ob der Agent eine interaktive Frage abfeuert, bevor er fertig ist. Wenn er Ergebnisse ausspuckt und sich ohne Nachfragen beendet, schlägt der Test fehl.

Das testet keinen Code. Das testet, ob ein KI-Agent einen Verhaltensvertrag einhält. Auf TTY-Ebene. Indem man ihm buchstäblich bei der Arbeit zusieht.

Die Reaktion der Ratsche bestand aus drei Schichten:

1. STOP-Gates in den Skill-Anweisungen – explizite Regeln, die besagen „du MUSST den Benutzer fragen, bevor du mit dem nächsten Abschnitt fortfährst", mit Anti-Rationalisierungs-Klauseln, die den spezifischen Fehlermodus benennen, damit das Modell sich nicht herausreden kann, es zu überspringen
2. Anti-Abkürzungs-Klausel – „die Plan-Datei ist die AUSGABE der interaktiven Überprüfung, kein Ersatz dafür." Ein Satz, der genau die Gesetzeslücke schließt, die das Modell immer wieder ausgenutzt hat.
3. Gate-Ebene-Boden-Tests – die TTY-Harness-Tests, die Claude Code in kontrollierten Szenarien starten und fehlschlagen, wenn der Agent nicht mindestens eine interaktive Frage stellt

Jetzt, wenn Anthropic eine neue Modellversion ausliefert oder wenn ich einen Skill-Prompt ändere, fängt die Testsuite jede Regression im interaktiven Vertrag ab. Der Agent kann nicht stillschweigend aufhören, Fragen zu stellen. Der Test beobachtet das Terminal und prüft es.

Oder nimm PR #880, der ein neues OpenClaw-Plugin ausgeliefert hat. Der Test prüft nicht nur, ob der Code kompiliert. Er baut das Plugin aus dem Quellcode, startet eine echte OpenClaw-Instanz in einem isolierten Profil, installiert das Plugin über die CLI, führt plugins inspect aus, um zu überprüfen, ob die Laufzeit es geladen hat, setzt den Konfigurationsslot, validiert die Konfiguration und führt plugins doctor aus, um null Diagnosen zu bestätigen. Eine vollständige End-to-End-Rundreise über zwei separate Programme. 359 Zeilen Testcode. Die Art von Test, die ein Mensch fast nie von Hand schreiben würde, weil der Aufbau zu mühsam ist. Claude hat es in etwa fünf Minuten geschrieben. Das ist die Mühewand, die in Echtzeit verschwindet.

Das Prinzip verallgemeinert sich. Du kannst auf Betriebssystemebene testen: Hat die Migration die richtigen Tabellen erstellt, hat der Cron-Job ausgelöst, lebt der Prozess noch? Auf Browser-Ebene: Hat die Seite gerendert, hat der Agent das Formular richtig ausgefüllt. Auf API-Ebene: Hat das Modell gültiges JSON mit dem richtigen Schema zurückgegeben. Auf Verhaltensebene: Hat der Agent das Protokoll befolgt, hat er vor dem Löschen gefragt, hat er aufgehört, als ihm gesagt wurde, er solle aufhören.

Der gesamte Stack ist testbar. Die Ratsche gilt für alles. Die meisten Leute haben das noch nicht realisiert, weil sie immer noch über Testabdeckung nachdenken als „hat meine Funktion die richtige Zahl zurückgegeben". Die wahre Testoberfläche ist alles, was der Computer sehen kann.

Die 90 %-Zahl

Was bringt dir eine Testabdeckung von 90 % eigentlich?

Capers Jones hat über 10.000 Softwareprojekte untersucht und die Defektentfernungseffizienz (DRE) gemessen – den Prozentsatz der Fehler, die abgefangen werden, bevor sie die Benutzer erreichen. Seine Daten aus Applied Software Measurement zeigen eine nichtlineare Kurve: Unter 70 % Abdeckung liegt die DRE bei etwa 65-75 %. Bei 85-95 % Abdeckung springt die DRE auf 92-97 %. Die Beziehung ist nicht linear. Es gibt einen Knick in der Kurve bei etwa 85 %, wo die Fehlerdurchbrüche stark abfallen.

Die Luftfahrtindustrie hat das vor Jahrzehnten herausgefunden. DO-178C, der FAA-Standard für flugkritische Software, erfordert modifizierte Bedingungs-/Entscheidungsabdeckung (MC/DC) für Systeme der Stufe A – solche, bei denen ein Fehler einen Flugzeugabsturz bedeutet. Die Zweigabdeckung allein übersieht 10-20 % der Fehler. MC/DC, das strenger ist als die Zeilenabdeckung, erreicht >99 % DRE. Sie schreiben das nicht vor, weil Bürokraten Papierkram mögen. Sie schreiben es vor, weil die Daten zeigten, dass unter bestimmten Abdeckungsschwellen kritische Fehler mit Raten entkommen, die mit dem Nicht-Töten von Menschen nicht vereinbar sind.

Der Analogie zur Zuverlässigkeitstechnik ist sauber. Fabriken verwenden ein System namens Six Sigma, um die Qualität zu messen. Die Idee: Zähle, wie viele Fehler du pro Million produzierter Einheiten bekommst, und drücke das dann als „Sigma-Stufe" aus – höheres Sigma bedeutet weniger Fehler. Ein 3-Sigma-Prozess produziert etwa 67.000 Fehler pro Million (ziemlich schlecht). Ein 4-Sigma-Prozess produziert etwa 6.200 (zehnmal besser). Ein 5-Sigma-Prozess produziert 233 (nochmal 27x besser). Der Sprung von 4 auf 5 Sigma ist keine inkrementelle Verbesserung. Es ist ein Phasenwechsel.

Die Testabdeckung folgt derselben Kurve. Von 70 % auf 90 % Abdeckung zu gehen, ist nicht 30 % besser. Es ist eine Größenordnung weniger Durchbrüche. Die Fehler, die bei 70 % durchschlüpfen, verstecken sich in den 30 % des ungetesteten Codes. Bei 90 % schrumpfen die Verstecke auf 10 % und die meisten gefährlichen Pfade sind abgesichert.

Nun, ich sollte ehrlich sein, was die Forschung auch zeigt. Mockus, Nagappan und Dinh-Trong haben Windows Vista untersucht und festgestellt, dass der Aufwand, 90 %+ zu erreichen, zwar mit weniger Fehlern nach der Veröffentlichung korreliert, aber stark ansteigt. Die letzten 20 % der Abdeckung erfordern unverhältnismäßig mehr Arbeit als die ersten 70 %. Das ist seit Jahrzehnten so. Deshalb hören die meisten Teams bei 70-80 % auf und nennen es gut genug.

Aber etwas hat sich geändert: KI-Coding-Agenten kennen keine Mühe.

Sie langweilen sich nicht, wenn sie den vierzehnten Randfalltest schreiben. Sie machen am Freitag um 17 Uhr keine Abstriche. Sie sehen sich einen kniffligen Integrationstest an und denken nicht „das mache ich später". Die Mühekurs, die menschliche Teams bei 70 % gestoppt hat, gilt nicht für Agenten. Du kannst Claude bitten, Tests für jeden Randfall in einem Modul zu schreiben, und es wird es fröhlich, gründlich, um 2 Uhr morgens tun, ohne sich zu beschweren. Die brutalen letzten 20 %, die 90 % Abdeckung für menschliche Teams unpraktikabel gemacht haben, sind genau die Art von Arbeit, die KI-Agenten am besten können.

Das ist der wahre Durchbruch. Es ist nicht, dass KI dich schneller Code schreiben lässt. Viele Leute haben das bemerkt. Es ist, dass KI dich verifizieren lässt auf einem Niveau, das vorher zu teuer war, um es aufrechtzuerhalten. Die 90 %-Schwelle, die die Daten als magisch bezeichnen? Früher hat sie zu viel menschliche Willenskraft gekostet, um sie zu erreichen. Jetzt ist sie kostenlos.

Das ist die entscheidende Unterscheidung. Bei der Ratsche geht es nicht um Zeilenabdeckung als Eitelkeitsmetrik. Es geht um Tests, die Verhaltensverträge kodieren – den Halterverwechslungstest, den Gewichtungsrundungstest, das interaktive Review-Gate. Jeder Test schreibt eine bestimmte gelernte Lektion fest. Die Abdeckung ist der Proxy, der dir sagt, wie viel des Systemverhaltens unter Vertrag steht. Bei 90 % löst fast jede Verhaltensänderung ein Testsignal aus. Der Agent besteht entweder (sicher auszuliefern) oder bricht einen Test (sofort erkannt).

Die restlichen 10 % sind Integrationspunkte, Infrastrukturverkabelung und Randfälle, die wirklich schwer zu testen sind. Das ist in Ordnung. Die 90 % sind das, was Chaos in eine Ratsche verwandelt.

90 % zu erreichen, war früher eine heldenhafte Anstrengung. Jetzt ist es ein Dienstag. Das ist die Spielveränderung.

Proof of Concept

Ich habe beide Projekte allein gestartet. Sie sind nicht mehr Solo.

GStack hat jetzt 37 Mitwirkende. v1.30 enthielt 21 Community-PRs in einem einzigen Release. GBrain hat 25 Mitwirkende. v0.31.1.1 landete 22 Community-Fixes in einem PR – Auth-Flow, Schema-Bootstrapping, Sync, Datenschutz.

Die Ratsche ist das, was dies sicher macht. Jeder externe PR muss die bestehende Testsuite bestehen. Ein neuer Mitwirkender muss nicht das gesamte System verstehen. Er muss die Tests bestehen lassen.

Die GBrain-Releases der letzten Woche erzählen die Geschichte:

• v0.31.0: eine neue Fakten-Tabelle für Echtzeitgedächtnis, plus eine Traumkonsolidierungsphase, die Kurzzeiterinnerungen in Langzeitwissen befördert
• v0.31.1: 25 CLI-Befehle behoben, die stillschweigend zu einer leeren lokalen Datenbank statt zum tatsächlichen Gehirn des Benutzers routeten
• v0.31.1.1: zweiundzwanzig von der Community gemeldete Fixes in einem PR
• v0.31.2: einen Code-Sync behoben, der bei großen Repos mit Symlinks ewig hing, indem ein 30-Sekunden-Timeout hinzugefügt wurde

Jedes Release wurde mit mehr Tests ausgeliefert als das vorherige. Der Agent schreibt die Tests zusammen mit dem Code. Die Abdeckung rutscht nicht, weil die Mühe, sie aufrechtzuerhalten, keine menschliche Last mehr ist.

Die neue Komplexitätsobergrenze

Die Komplexitätsobergrenze für Software ist gerade viel höher geworden.

Früher war sie durch die Fähigkeit eines Teams begrenzt, das System im Kopf zu behalten. Jetzt ist sie durch eine Person plus Agenten begrenzt, die die gesamte Codebasis, Schema-Historie, Testsuite und Dokumentation in den Kontext laden können.

Das ist eine viel größere Zahl. Und sie wächst weiter, je größer die Kontextfenster werden und je besser die Modelle darin werden, über Code nachzudenken.

Jedes Softwareunternehmen, das dieses Modell nicht übernimmt – Agenten plus Geschmack plus eine Testsuite, die nur steigt – liefert bereits langsamer und mit geringerer Qualität aus als eine Person, die es hat.

Die Werkzeuge sind da. Der Code ist offen. Tests sind die Ratsche. 90 % Abdeckung, jeder PR, keine Ausnahmen.

Fünfzig Jahre lang war 90 % Abdeckung ein Luxus, der der Luftfahrt und Medizintechnik vorbehalten war – Teams mit dem Budget, menschliche Stunden gegen die Mühewand zu werfen. KI-Agenten haben diese Wand eingerissen. Die Abdeckungsschwelle, die Software zuverlässig macht, ist nicht länger teuer. Sie ist nur eine Einstellung. Die Frage ist nicht, ob du dir 90 % leisten kannst. Es ist, ob du es dir leisten kannst, es nicht zu tun.

Die Ratsche, die Skills und das gesamte Wissenssystem sind Open Source und kostenlos auf GitHub. Geh und baue.

Meine MIT-lizenzierten Open-Source-Projekte:

• GStack – macht Claude Code dramatisch besser. 93K Sterne. Kostenlos.
• GBrain – dein zweites Gehirn für KI-Agenten. 14K Sterne. Kostenlos.

Die AI Explainer-Serie:

1. Fat Skills, Fat Code, Thin Harness – die Architektur
2. Resolvers – die Routing-Tabelle für Intelligenz
3. The LOC Controversy – was 600K Zeilen tatsächlich produziert haben
4. Naked Models Are Stupider – das Modell ist der Motor, nicht das Auto
5. The Skillify Manifesto – jeder Workflow wird zu einem testbaren Skill
6. Meta-Meta-Prompting – sich verstärkende Skills erzeugen emergente Fähigkeiten
7. The Agent Complexity Ratchet – du bist hier

https://x.com/garrytan/status/2054055071017538028

https://x.com/garrytan/status/2042925773300908103

https://x.com/garrytan/status/2044479509874020852

https://x.com/garrytan/status/2045404377226285538

https://x.com/garrytan/status/2045798603059548364

https://x.com/garrytan/status/2046876981711769720

https://x.com/garrytan/status/2053127519872614419

https://x.com/karpathy/status/1886192184808149383