KI schreibt Code schneller,
als wir ihn überprüfen können.

Der Entwickler besitzt die Architektur und die Entscheidungshoheit. Die KI schreibt Code, führt aus, generiert Artefakte. Was der Mensch entschieden hat, kann die KI nicht mehr umwerfen — nur neue Entscheidungen können das ändern.

"AI-driven development doesn't eliminate the need for developer expertise; just the opposite. The developers who'll thrive aren't the ones who prompt the fastest. They're the ones who think the clearest about what they're building and why."— Addy Osmani, Agentic Engineering (2026)

Andrew Stellman hat ~21.000 Zeilen Python in ~75 Stunden gebaut — mit der Regel, dass die KI allen Code schreibt. Was ihn produktiv gemacht hat, war nicht Vertrauen in die KI. Es war zu wissen, wann sie falsch lag. Erfahrung ist der Multiplikator. Die KI verstärkt sie, sie kann sie nicht ersetzen.

Specs beschreiben beobachtbares Verhalten — keine Implementierungsdetails. Tests verweisen auf die Spec, nicht auf den Code. Spec-Coverage ist das relevante Maß: Wie viel des vereinbarten Verhaltens ist durch Tests abgesichert? Code-Coverage sagt nichts darüber aus, ob das Richtige gebaut wurde.

"Write tests that measure your product's functions, not how it performs them. Behavioral contracts grant us the freedom to rebuild and reimplement."— Drew Breunig, 10 Lessons for Agentic Coding (2026)

Breunig hat das an whenwords gezeigt: 750 YAML Conformance-Tests, sprachunabhängig. Jede Implementierung in jeder Sprache wird gegen dieselben Tests validiert. Wenn Code billig ist, sollten Tests das Verhalten beschreiben — nicht die Implementierung. Das gibt die Freiheit, Code wegzuwerfen und neu zu bauen, ohne Tests anzufassen.

Code speichert das Wie. Tests beschreiben das Was. Das Warum geht verloren — wenn man es nicht aktiv dokumentiert. In der nächsten Session optimiert die KI eine undokumentierte Entscheidung weg. Nicht böswillig. Sie hält es für besser.

Stellman zeigt das am Gson-Bug: Ein Sicherheitsproblem, das jahrelang existierte, weil kein Requirement je formuliert hatte: "Duplicate Keys müssen abgelehnt werden, wenn der erste Wert null ist." Rund 50% aller Sicherheitsprobleme sind solche Design-Fehler — für Code-Analyse unsichtbar. Nur wer den Intent kennt, kann seine Verletzung erkennen.

Agenten bekommen kleine, abgeschlossene Aufgaben. Ein Agent, eine Session, ein commitbares Ergebnis. Was die KI weiß, bestimmt ihre Qualität. Je enger der Fokus, desto besser das Ergebnis.

Große Batches scheitern an Kontextlimits, erzeugen Diffs die niemand reviewen kann (auch die KI nicht!), und machen Fehlersuche unmöglich. Stellman hat seinen Quality Playbook in 10 unabhängige Phasen mit je eigenem Kontext zerlegt — und es hat besser funktioniert als eine einzige Mega-Session. Zero Context Carryover ist kein Verlust, wenn der Kontext externalisiert ist.

Jeder automatisierbare Schritt, der nicht von einem LLM erledigt werden muss, sollte deterministisch von einem Programm erledigt werden. Deterministisch: testbar, reproduzierbar, funktioniert wenn das Token-Budget erschöpft ist.

Karpathys March of Nines: Jeder LLM-Schritt hat eine Zuverlässigkeits-Obergrenze unter 100%. Kaskadiert man Schritte, multiplizieren sich diese Grenzen. Stellman hat es gemessen: 48% → 79% Zuverlässigkeit durch das Herauslösen eines einzigen Validators aus dem LLM in einen 10-Zeilen-Ausdruck.

Wenn man eine KI anweist, ein Quality Gate aufzurufen, wird sie es irgendwann vergessen. Ein Prompt ist eine Empfehlung, kein Vertrag. CI-Pipelines vergessen nicht. Schema-Validatoren vergessen nicht. Nur externe Erzwingung ist verlässlich. Quality Gates müssen um die KI herum gebaut werden, nicht in sie hinein.

Deming, 1950: Qualität wird in den Prozess eingebaut, nicht hinterher hineingeprüft. Traditionelles Quality Engineering — Requirements-Tracing, funktionale Tests, Verifikation gegen Intent — wurde nicht aufgegeben weil es schlecht war. Es galt als zu teuer. KI macht es billig genug für jedes Projekt.

"With a solid test suite, an AI agent can iterate in a loop until tests pass, giving you high confidence in the result. Without tests, it'll cheerfully declare 'done' on broken code."— Addy Osmani, Agentic Engineering (2026)

Generative KI generiert gerne. Sie schätzt Komplexität zu hoch ein, patcht lieber als neu zu denken, stapelt Fixes auf Fixes. Stellman: "I can't think of a single time in the whole project when one of the AIs stepped back and said, 'Tear this out and rethink the approach.'" Der Mensch muss das einfordern.

Drei Runden Debugging sind oft langsamer als ein frischer Anlauf mit besserer Spec. KI-Output ist billig. Einen schlechten Ansatz zu reparieren ist es nicht. Fail Fast ist kein Aufgeben. Es ist ein Neustart mit besserer Spec — nicht mehr Patches auf schlechten Code.

Wenn ein Artefakt nicht den Erwartungen entspricht, ist der Prozess schuld — nicht das Artefakt. Deming: "A bad system will beat a good person every time." Man korrigiert den Prozess, nicht die einzelne Ausgabe.

Jede Iteration endet damit: Zeit und Tokens in die nächste investieren. Erkenntnisse aus Agent-Logs und Git-History fließen in AGENTS.md, Skills, Scripts und Regeln.

Ohne Compound macht die KI bei jedem Durchlauf dieselben Fehler, kennt dieselben Lösungen nicht, verbraucht Tokens für bereits gelöste Probleme. Mit Compound wird die KI selbst besser — nicht nur der Output.

"To spend more time on the hard stuff, minimize the time you spend on easy things. Distill learnings into skills, build loops, automate code reviews, and let your tools compound."— Drew Breunig, 10 Lessons for Agentic Coding (2026)

Every Inc. hat das als Open-Source-Plugin implementiert. Am Ende jeder Aufgabe extrahiert ein Skill die Erkenntnisse, legt sie in docs/solutions/ ab — automatisch indexiert für die nächste Session. Details →