18 Agents, 800 Commits, ein Quartal — und das war mein Nebenprojekt

git log --oneline | wc -l spuckte am letzten Tag im März 2026 die Zahl 847 aus.

Ich hatte mit einer großen Zahl gerechnet. Nicht mit dieser. 847 Commits. Ein Repository. Ein Entwickler. Einundneunzig Tage, die meisten davon nach einem langen Arbeitstag in einem Job, der meine Rechnungen bezahlt. Kein Sabbatical. Kein Runway. Ein Nebenprojekt, gebaut in den Stunden zwischen dem Ende eines Arbeitstages und dem Beginn des nächsten — mit KI-Agents, die die Implementierung übernahmen, während ich die Architektur entwarf und die Entscheidungen traf.

Die Zahl überrascht mich noch immer, und ich war dabei.

Aber die Zahl braucht Kontext. Nach Monaten mit Claude Code bei Kleinanzeigen — KI-Projekte in einem großen Unternehmen voranzutreiben — stieß ich immer wieder gegen eine andere Art von Wand. Menschliche Freigaben. Team-Abstimmungen. Bestehende Production-Systeme, die von Dutzenden Entwicklern gepflegt werden. Diese Einschränkungen existieren aus guten Gründen. Aber sie bedeuteten, dass ich nie herausfinden konnte, wo die echte Grenze liegt. Dieses Projekt begann als genau dieses Experiment. Ich hatte nicht geplant, dass es jemals in Production geht. Ich hatte nicht geplant, dass es seinen ersten Euro verdient. Ich wollte nur wissen: Wie weit kommt man wirklich, wenn es keine anderen Menschen oder geschäftlichen Einschränkungen gibt — nur du, deine Agents und eine Vision, die du verwirklichen willst?

Die Antwort, offenbar: 847 Commits.

Woche	Was passierte	Commits	Zeilen bewegt	Netto
Woche 1 · Jan	Foundation, RBAC & Roles, E2E + CI	126	103k	+46k
Woche 2 · Jan	OCR-Integration, Validator-System, E-Mail-Templates	65	34k	+22k
Woche 3 · Jan	Monorepo-Split, Fastify-Migration, Docker + EC2	204	220k	+10k
Woche 4 · Jan	Submission Flow V2, Mobile-Kamera, Lead-Exporte	71	44k	+6k
Woche 5 · Jan	iOS/Safari-Fixes, Mobile-UX-Optimierung	22	3k	+1k
Woche 6 · Feb	Urlaub	0	—	—
Woche 7 · Feb	Kleinere Fixes, Kundenfeedback	3	1k	+1k
Woche 8 · Feb	Production Hardening, Customer Campaign auf Staging	26	13k	+10k
Woche 9 · Feb	Campaign-Validator, Dual-Foto-Upload, DSGVO	26	6k	+2k
Woche 10 · Mär	Docker-Optimierung, Admin-UI	7	2k	+1k
Woche 11 · Mär	Staging + Prod vereint, CI/CD-Pipeline	39	10k	+5k
Woche 12 · Mär	Security-Hardening, Review-Workflow-Redesign	50	8k	+2k
Woche 13 · Mär	Claude OCR, Campaign-Launch-Vorbereitung, Validator V3	37	10k	+4k
Woche 14 · Mär	OpenAPI-Migration, E2E-Parallelisierung, Customer Portal	113	49k	+24k
Gesamt		789	502.411	+133.631

Woche 3 ist die Woche, in der die gesamte Architektur bewegt wurde. Fastify-Migration, Monorepo-Split, Docker-Produktionsinfrastruktur — alles in sieben Tagen. Der 220.000-Zeilen-Spike wirkt dramatisch, weil Dateien verschieben als Löschen und Neuanlegen zählt. Die Entscheidung dahinter ist im Abschnitt Tag Eins oben beschrieben.

Woche 6 ist null. Ein Nebenprojekt kann pausieren. Ein Sprint-Team nicht.

Woche 14 ist der abschließende Schub — fast auf dem Niveau von Woche eins. Das ist der Fundament-Reparatur-Sprint: OpenAPI-Migration, Schema-Konsolidierung, 130 E2E-Tests parallelisiert. Das Quartal endete genauso, wie es begonnen hatte.

Insgesamt berührte Zeilen über alle 14 Wochen: 502.411. Nicht netto — berührt. Hinzugefügt oder gelöscht. Das ist das tatsächliche Arbeitsvolumen, das die Codebase absorbiert hat.

Um das greifbar zu machen: Bei einer realistischen Tipp-Geschwindigkeit für Code würde es ca. 2.500 Stunden dauern, nur um jede Zeile zu transkribieren, die durch diese Codebase geflossen ist — reine Tastatureingabe, kein Denken. Die 133.000 Netto-Zeilen des Endprodukts, getippt von einem Entwickler, der bereits genau weiß, was er schreiben muss, bei produktiven 100 Zeilen pro Stunde: 1.336 Stunden. Dreiunddreißig Wochen Vollzeitarbeit. Für die Antwort, die man schon hätte.

Die Frage, die dieser Artikel beantwortet, ist nicht: „Können KI-Agents Software bauen?” Diese Frage ist seit einer Weile mit Ja beantwortet. Die eigentliche Frage ist, wie es wirklich aussieht, ein echtes Produkt über drei Monate mit Agents aufzubauen — nicht die Demo, nicht der Launch-Post, sondern der vollständige Bogen. Die Geschwindigkeit, die man nicht glaubt, bis man mittendrin ist. Der Drift, der sich ansammelt, wenn niemand die Contracts zwischen den Teilen im Blick behält. Die fünf strukturellen Risse, die auftraten, bevor ich überhaupt bemerkt hatte, dass sie entstanden. Der Stopp, bei dem man zwischen Flicken und Neubau wählt — und was es kostet, den Neubau zu wählen. Und das Sicherheitsnetz, das in dem Moment, in dem es aufgebaut wurde, genau den Fehler fand, den ich sonst in Production gebracht hätte.

Das ist diese Geschichte.

Tag Eins

Die Session, die alles startete, ist in einem eigenen Artikel dokumentiert: 187 Dollar, 16 Stunden, 8 Agents parallel, ein vollständiges Cashback-Campaign-Backend und React-Frontend — vom leeren Repository bis zum deployed, getesteten, laufenden System. 729 Tests grün am Ende dieser Session.

Was der Kassenbon nicht zeigt, ist die Architektur hinter den Zahlen.

Ich habe nicht jeden Endpoint spezifiziert oder die OpenAPI-Spec vorab ausgeschrieben. Das ist nicht das, was Architektur-Durchsetzung in diesem Maßstab bedeutet. Was ich getan habe, war Linien zu ziehen.

apps/
├── backend/           ← das Backend. kein UI.
├── admin/             ← ein eigenes Frontend
├── customer-portal/   ← die nutzerorientierte React-App
└── landing-page/
packages/
├── api-client/        ← generiert aus der OpenAPI-Spec
├── e2e-tests/
└── shared/
    └── schemas/       ← die Single Source of Truth

Das Backend ist das Backend — kein UI. Das Admin-UI ist ein eigenes Frontend. Die nutzerorientierte React-App ist ein drittes Ding. Sie kommunizieren über Contracts; sie teilen keinen Code, außer dieser liegt im Shared-Modul — und das Shared-Modul ist für Roles, Enums, Constants, also die Dinge, die auf beiden Seiten per Definition identisch sind und es immer bleiben werden. Die KI sagte mir, das sei Overkill. Ein Projekt dieser Größe könne das Admin-Panel einfach ins Backend integrieren — Next.js macht das trivial, wozu die Komplexität? Ich blieb standhaft. Ich wusste, worauf ich hinarbeitete, auch wenn der erste zahlende Kunde noch Monate entfernt war und das Ganze auf einem t3.small in Frankfurt bei AWS lief.

Ich komme aus der Java- und Kotlin-Welt. Das ist meine professionelle Backend-Sprache seit mehreren Jahren — ich baue Microservices in einem Unternehmen mit über 120 Backend-Entwicklern. Ich weiß genau, was passiert, wenn ein TypeScript-Frontend mit einem typisierten Java-Backend spricht: Man bekommt zwei Definitionen jedes Models. Ein CampaignDTO in Kotlin, ein Campaign-Interface in TypeScript, von verschiedenen Personen in verschiedenen Sprachen gepflegt, das sich Feld für Feld auseinanderbewegt, bis das Interface technisch vorhanden, aber funktional eine Lüge ist. Diesen Fehler kenne ich aus eigener Erfahrung. Ich habe TypeScript für dieses Projekt gewählt, genau um diese Lücke zu schließen — eine Sprache von Ende zu Ende, eine Definition pro Konzept, mit dem Compiler als gemeinsamer Autorität.

Diese Struktur war nicht von Anfang an da. Meine Komfortzone ist Next.js — App Router, collocated API Routes, Backend und Admin im selben Projekt. Vertraut, schnell zu starten, und falsch für das, was daraus werden musste. Die Probleme kamen, als lang laufende Verarbeitungsjobs und Hintergrundtasks gegen das Request-Response-Modell von Next.js API Routes drückten. Business-Logik, die nichts in einem Runtime mit React Server Components verloren hat. Wir haben es aufgeteilt: Das Backend wurde ein reiner Fastify-Service — HTTP-Endpoints, Business-Logik, kein UI-Coupling. Das Admin wurde eine Vite-SPA, eine clientseitige React-Anwendung mit einer sauberen Grenze zum Backend. Das Prinzip war immer dasselbe. Die Implementierung hat es eingeholt.

Deshalb habe ich nach einer langen Planungsdiskussion mit meiner KI — wir haben OpenAPI-first versus einen Shared-Schema-Layer diskutiert, uns gegenseitig widersprochen und sind schließlich bei ts-rest gelandet — von Anfang an einen Contract durchgesetzt. Nicht die konkreten Endpoints — die konnten sich entwickeln. Aber das Prinzip: eine Contract-Schicht, geteilt zwischen Frontend und Backend, mit Zod-Schemas, die definieren, was die Grenze überquert. Jeder Agent, der an einem Teil des Stacks arbeitete, würde gegen einen definierten Contract arbeiten, statt eigene Annahmen darüber zu erfinden, was die andere Seite erwartet.

Die Architektur war richtig. Was in den folgenden zehn Wochen passierte, ist, dass der Mechanismus, der sie durchsetzte, still zu etwas anderem wurde — im Codebase vorhanden, fehlerfrei kompilierend, und fast keine der Arbeit leistend, für die er da war. Eine leere Hülle. Die Form eines Contracts ohne seinen Inhalt.

Der Sprint

Für die nächsten zehn Wochen war der Durchsatz ungleich allem, was ich beim Bauen eines Nebenprojekts erlebt hatte.

Features, die normalerweise monatelang im Backlog liegen, wurden innerhalb von Tagen geliefert. Ich skizzierte eine Idee beim Mittagessen, öffnete abends eine Session und hatte bis zum Schlafengehen etwas Funktionierendes. Morgens lokales QA, kleine Anpassungen, merge. Nächstes Feature. Dieser Zyklus — Design im Kopf, Implementierung durch Agents, Review, Ship — komprimierte, was sich wie monatelange Verzögerungen anfühlte, auf einzelne Abende.

Das menschliche Review wurde zum Engpass. Meine Ideen hörten nicht auf. Die Agents hörten nicht auf. Aber meine Zeit, den Code zu prüfen, die Details anzuschauen, die Entscheidungen zu verifizieren — die war brutal begrenzt. Die Feature-Liste war lang, und die Versuchung, einfach weiterzumachen, war immer da. Ich begann, Reviews zu bündeln: ein paar Features shippen, dann zusammen reviewen. Ich fügte Code-Review-Agents hinzu, die viel auffingen. Keiner von ihnen erkannte eine architektonische Verschlechterung.

Der OCR-Belegscanner war eine Session. Dual-Photo-Upload-Pipeline — Vorder- und Rückseite eines Kassenbons — durch zwei verschiedene OCR-Engines parallel geleitet, Ergebnisse verglichen und abgeglichen, 97,78% Konfidenz bei der finalen Extraktion. Fünf kritische Bugs beim Testen gefunden, alle nur mit echten Handyfotos unter echten Lichtverhältnissen reproduzierbar, nicht mit den sauberen Scans aus den Unit-Tests. Kein KI-Tool kann ersetzen, was passiert, wenn man ein Handy unter Küchenbeleuchtung auf einen Kassenbon richtet. Es brauchte mehrere enge Feedback-Runden, bei denen das Feature einfach nicht funktionierte, bis wir es mit echten Fotos testeten. Ein PNG von einem gut beleuchteten Scanner hat nicht die Rotationsartefakte, die Schattenverläufe, die leichte Bewegungsunschärfe, die eine Handykamera an der Kasse produziert. Die Bugs lagen genau in diesen Unterschieden. Alle fünf wurden in derselben Session gefunden und behoben.

Es gab eine Woche, in der alles stoppte. Urlaub, im Februar. Null Commits. Als ich zurückkam, liefen Build, Tests und Deployment noch genauso wie vorher. Das Projekt hatte gewartet, genau dort, wo ich es gelassen hatte.

Der Production-Hardening-Durchlauf war eine weitere Session. Rate-Limiting auf jedem öffentlichen Endpoint. Zweigeteiltes CORS — separate Policies für die öffentlichen Frontend-Routes und die internen Service-Routes. Error-Message-Sanitization: Das Standard-Error-Handling hatte Stack-Traces und Library-Versionen in API-Antworten geleakt, weil das in der Entwicklung nützlich ist und niemand daran gedacht hatte, es vor dem Go-Live zu ändern. Graceful Shutdown, damit Docker-Container aufhören, neue Requests anzunehmen, bevor sie laufende abschließen, statt einfach zu sterben. Prometheus-Metriken-Instrumentierung: Request-Counts, Latenz-Histogramme, Fehlerquoten. Eine Blocklist mit 121.000 bekannten Wegwerfmail-Domains. Alles davon: Dinge, die ich kannte und explizit anforderte, die die Agents korrekt und schnell implementierten. Keines davon: Dinge, die die Agents von sich aus vorgeschlagen hätten.

Die Infrastruktur-Konsolidierung dauerte vier Stunden. Zwei EC2-Instanzen — ein Demo-Server und ein Production-Server, unterschiedliche CPU-Architekturen, separate CI/CD-Pipelines, Docker-Images mit eingebackenen umgebungsspezifischen Variablen — auf eine reduziert. Der Quellcode kam vom Production-Server. Build-Time-Umgebungsvariablen wurden zu Runtime-Config. Staging und Production liefen auf demselben Host, demselben Docker-Image, unterschiedlichen Config-Dateien. Der gesamte Konfigurations-Footprint betrug 72 Kilobyte. Die Konsolidierung startete mit einer einzigen Frage an einen Agent: „Können wir Staging und Prod einfach auf demselben Server laufen lassen?” Vier Stunden später: ja. Nicht die optimale Architektur — aber die richtige für ein Nebenprojekt mit begrenztem Budget.

Der erste echte Kunde kam bald. Echte Campaign-Codes auf echter Verpackung gedruckt, echte Nutzer, die echte Kassenbons mit ihren Handys fotografierten, echte OCR-Konfidenzwerte, echte Cashback-Berechnungen, echtes Geld, das rausging. Die Art von Sache, bei der ich nachts um elf aufwache und Fehler behebe, wenn etwas schiefläuft. Dieser Druck ist erhellend. Er lässt einen um Tests besorgt sein auf eine Art, wie Demo-Software es nie tut. Eine grüne Test-Suite fühlt sich anders an, wenn die Cashback-Auszahlung eines echten Menschen davon abhängt, dass das System korrekt ist.

Die Customer-Campaign startete reibungslos. Keine nächtlichen Alarmierungen. Die OCR-Pipeline verarbeitete viele Kassenbons. Die Auszahlungsberechnungen stimmten. Ich war stolz auf die Geschwindigkeit und stolz auf die Qualität.

Jetzt der ehrliche Teil.

Man kann 10+ Commits pro Tag bei einem Nebenprojekt nicht vollständig reviewen, wenn man einen Vollzeitjob hat. Das ist schlicht nicht möglich. Ich reviewte die Commits, die sich riskant anfühlten — alles, was die Payout-State-Machine, Authentication-Flows, Datenbank-Migrationen oder die OCR-Konfidenzschwellenwerte berührte. Alles andere reviewte ich auf dem Level von „sieht das ungefähr richtig aus?” und vertraute den Tests für den Rest. Ich vertraute darauf, dass die Architektur, die ich entworfen hatte, das System kohärent hielt. Ich vertraute darauf, dass TypeScript seinen Job machte.

Diese zehn Wochen lang funktionierte das größtenteils. Die Features wurden geliefert. Die Tests bestanden. Der eine Kunde war zufrieden.

Und weil alles größtenteils funktionierte, machten sich die Stellen, wo es nicht funktionierte, sehr leise bemerkbar.

Der stille Fehler

ts-rest. Ich wählte es genau deshalb, weil ich die Alternative kannte. Das Java/TypeScript-Impedanzproblem — zwei Models, zwei Dateien, zwei Teams, die sie langsam auseinanderdriften lassen — war der Fehler, gegen den ich baute.

ts-rest ist eine TypeScript-Bibliothek, um die API als gemeinsamen Contract zu definieren: eine Datei, die sowohl vom Express-Backend als auch vom React-Frontend importiert wird. Man deklariert einmal, was jeder Endpoint akzeptiert und zurückgibt — und beide Seiten sind zur Compile-Zeit an diese Definition gebunden. Keine separaten API-Docs. Kein Copy-Paste von Typen zwischen Packages. Wenn man einen Agent bittet, einen Endpoint hinzuzufügen, fügt er ihn dem Contract hinzu und beide Seiten aktualisieren sich zusammen. Das war der Plan.

Dann wurde das Upstream-Projekt still. Zod v4 erschien. ts-rest erklärte Inkompatibilität — kein Bug, kein verpasster Patch, sondern eine grundlegende Inkompatibilität mit den neuen Zod-Interna. Nicht kaputt auf eine Art, die beim Start einen Fehler wirft — kaputt auf eine Art, die einen daran hindert, irgendetwas zu aktualisieren, das Zod v4 will. Man patcht um die Konflikte herum. Man fügt Resolutions zur Lockfile hinzu. Man schreibt npm why zod und starrt auf einen Abhängigkeitsgraphen, der einfach sein sollte und es nicht ist. Die Wände schließen sich langsam. Heute hört nichts auf zu funktionieren. Man kann nur nicht mehr vorwärtskommen.

(Zod, falls es unbekannt ist: Es ist eine TypeScript-Schema-Bibliothek. Man beschreibt einmal eine Datenform — z.object({ name: z.string(), age: z.number() }) — und Zod liefert Runtime-Validierung und TypeScript-Typen aus dieser einen Definition. Es ist überall im TypeScript-Ökosystem verbreitet, weshalb eine Zod-Versions-Inkompatibilität so schmerzhaft ist.)

Das ist die ts-rest-Geschichte. Eine Warnung vor Dependency-Risiken — aber ts-rest ist nicht der Fehler, der hier zählt. Es ist eine Steuer, kein Riss. Was zählte, ist, was mit dem Contract selbst passierte, während ich damit beschäftigt war, alles andere am Laufen zu halten.

Der Contract wurde zu einer leeren Hülle. Er war noch da. Er kompilierte noch. Die Agents referenzierten ihn noch, wenn sie Code an der Grenze schrieben. Aber die Wartungslast, ihn kohärent zu halten — die neuen Felder, die im Backend hinzugefügt wurden, die Form-Validierungen, die im Frontend hinzugefügt wurden, die deutschen Fehlermeldungen, die eigene Zod-Schemas brauchten — all das begann um ts-rest herum zu passieren, statt durch es. Weil es einfacher war. Weil die Agents lokale Probleme lokal lösten. Weil ich Diffs um 22 Uhr nach einem Arbeitstag reviewte und die einzelnen Änderungen gut aussahen.

Der Riss ist der Schema-Drift.

Es begann einfach. Das Backend brauchte Zod-Schemas, um eingehende API-Requests zu validieren — den Body parsen, fehlerhafte Daten ablehnen, garantieren, dass alles Downstream das Erwartete bekommt. Agents, die am Backend arbeiteten, schrieben diese Schemas. Das Frontend brauchte ebenfalls Validierung: Form-Schemas mit deutschen Fehlermeldungen. Agents, die am Frontend arbeiteten, schrieben diese Schemas. Beide waren in ihrer Isolation korrekt.

// apps/backend/src/routes/submissions.ts — Backend validiert hier
const CreateSubmissionSchema = z.object({
  campaignCode: z.string(),
  receiptTotal: z.number(),
  autoRejectionThreshold: z.number(), // ← existiert im Backend-Schema
})

// apps/customer-portal/src/forms/submission.ts — Frontend validiert hier
const SubmissionFormSchema = z.object({
  campaignCode: z.string(),
  receiptTotal: z.number(),
  // autoRejectionThreshold ← nicht hier. Niemand hat es bemerkt.
})

Zwei Zod-Schema-Definitionen. Dieselben Domain-Objekte. Dieselben Feldnamen — außer wenn nicht.

Niemand hat entschieden, zwei Schemas zu haben. Niemand hat eines Nachmittags beschlossen, duale Definitionen davon zu pflegen, wie eine Campaign-Submission aussieht. Es ist das natürliche Ergebnis von Agents, die lokale Probleme lokal lösen, über zehn Wochen, bei mehr als zehn Commits pro Tag, mit einem menschlichen Reviewer, der Diffs um 22 Uhr nach einem vollen Arbeitstag las. Der Backend-Agent, der ein neues Feld zum API-Validierungsschema hinzufügte, hatte keinen Grund, von dem Frontend-Form-Schema in einem anderen Package zu wissen. Der Frontend-Agent, der eine deutsche Fehlermeldung hinzufügte, hatte keinen Grund, das API-Schema zu prüfen. Jede Änderung war in ihrem lokalen Kontext korrekt. Die Inkohärenz lebte zwischen den Kontexten.

Der Drift kündigt sich nicht an. Er sammelt sich an, Feld für Feld, bis die Lücke groß genug ist, um zu zählen.

So sieht die Lücke in der Praxis aus. Ein Nutzer füllt ein Formular aus. Er gibt Werte in alle Felder ein, darunter zwei, die das Produkt erforderte: eine Schwellenwert-Einstellung, die steuert, wie Einreichungen markiert werden, und ein Konfigurationsfeld für automatische Verarbeitungsregeln. Er klickt auf Absenden. Das Frontend validiert — alle Felder bestehen das Frontend-Schema. Der Request geht an die API. Der API-Contract — die ts-rest-Definition, die steuert, was tatsächlich serialisiert wird — kennt diese zwei Felder nicht. Sie sind im Frontend-Schema. Sie sind nicht im API-Contract. Der Serializer entfernt sie. Der Request-Body, der beim Backend ankommt, enthält sie nicht.

Das Backend validiert den eingehenden Body gegen sein eigenes Zod-Schema. Das Backend-Schema hat diese Felder ebenfalls nicht — sie wurden zum Frontend-Schema aus UX-Gründen hinzugefügt, aber nicht zurück zum API-Contract propagiert. Das Backend sieht einen validen Request. Es verarbeitet, was es sehen kann. Gibt 200 zurück. Das Frontend empfängt 200. Zeigt den Erfolgszustand. Der Nutzer schließt den Tab.

Die Feldwerte sind weg. Kein Fehler wurde geworfen. Kein Test schlug fehl. Beide Schemas waren intern valide. Das System funktionierte exakt wie designed. Das Design war falsch.

Das findet man nicht mit Unit-Tests. Der Unit-Test für das Frontend-Formular validiert gegen das Frontend-Zod-Schema — besteht. Der Unit-Test für den Backend-Handler validiert gegen das Backend-Zod-Schema — besteht. Der Integration-Test mockt den API-Call und prüft, ob die richtige Mutation aufgerufen wurde — besteht. Der Contract zwischen dem Frontend-Schema und der tatsächlichen API-Serialisierung: ungetestet, weil die Test-Suite schichtweise aufgebaut wurde, jede Schicht korrekt, keine Schicht schaut auf das Ding zwischen den Schichten.

Fünf Risse

Als ich endlich anhielt und den Codebase strukturell betrachtete — nicht Commit für Commit, sondern als Ganzes, als Architekt, der fragt „Was haben wir eigentlich gebaut?” — fand ich fünf Probleme. Jedes einzeln erklärbar. Jedes mit einer sinnvollen lokalen Ursache. Zusammen sagten sie mir etwas über die Architektur, nicht über einzelne Fehler.

Riss 1: Der veraltete Import. Eine Test-Helper-Datei importierte noch direkt @ts-rest/core. Das hatte funktioniert, als der gesamte Stack ts-rest verwendete. Nach teilweiser Migrationsarbeit verwendete der Production-Code diesen Import-Pfad nicht mehr, aber die Test-Datei schon noch. Niemand bemerkte es, weil tsconfig.build.json das tests/-Verzeichnis vom TypeScript-Kompiliervorgang ausschloss. tsc -b lief sauber durch. CI meldete null Typ-Fehler. Die Test-Umgebung trug eine Dependency, die von Production abwich, unsichtbar, weil die Build-Toolchain beim Erstellen des Build-Artifacts nie auf die Tests schaute. Jede CI-Prüfung, die lief, prüfte etwas Wahres. Keine von ihnen prüfte das.

Riss 2: Die Lücke in der Exports-Map. Das Shared-Package hatte ein unvollständiges exports-Feld in seiner package.json. Es gab keinen "."-Eintrag — keinen Default-Export für den Package-Root. Vite, der Entwicklungs-Bundler, löste das mit implizitem Fallback-Verhalten: Wenn die Exports-Map einen angeforderten Pfad nicht abdeckt, sucht Vite nach index.js oder index.ts im Package-Root. Das funktionierte korrekt in der lokalen Entwicklung und im CI-Build, weil beide Vite verwendeten. Ein Downstream-Package, das TypeScripts tsc -b für seinen eigenen Build verwendete, versuchte eine strikte Exports-Map-Auflösung: kein "."-Eintrag, Auflösung schlägt fehl. Das Projekt baute und lief korrekt überall, wo wir es testeten. Ein Consumer entdeckte die Lücke. Die Art von Fehler, der vollständig unsichtbar ist, bis jemand den spezifischen Auflösungspfad versucht, der ihn aufdeckt.

Riss 3: Die Type-Casts. Als ich den Codebase nach as unknown as durchsuchte, fand ich Dutzende Vorkommen. Jedes davon war ein Agent, der „kompiliert” über „korrekt typisiert” stellte. Das Muster taucht auf, wenn ein Typ-Inference unangenehm wird — meistens an einer Grenze zwischen den Typen einer Library und den eigenen Domain-Typen. Die korrekte Lösung erfordert entweder die Anpassung der Typen aneinander, das Schreiben eines Type-Predicates oder das Hinzufügen einer Runtime-Assertion, die die Form an der Grenze validiert. Diese Ansätze brauchen mehr Überlegung und Zeit. Die schnelle Lösung ist as unknown as TargetType. Sie bringt den Compiler sofort zum Schweigen. Der Task des Agents ist erledigt. Der Test besteht.

Das Typsystem wird zur Tapete: vorhanden, ohne CI zu brechen, nichts einschränkend. Wenn jemand die falsche Form durch einen dieser Cast-Punkte schickt, zuckt TypeScript mit den Schultern. Der Runtime-Fehler passiert irgendwo Downstream, weit entfernt vom Cast, auf eine Art, die schwer zurückzuverfolgen ist. Der TypeScript-Build ist grün. Die Typen leisten die Arbeit nicht, für die man sie eingestellt hat.

Riss 4: Der Schema-Drift, formalisiert. Als ich die Frontend-Form-Schemas und die API-Request-Schemas nebeneinanderstellte und Feld für Feld verglich, war autoRejectionThreshold im API-Schema vorhanden und im Form-Schema fehlend. Das ist ein Feld, das steuert, ob Einreichungen automatisch zur Überprüfung markiert werden, basierend auf einem Konfidenz-Schwellenwert. Es existierte in der API. Ein Nutzer konnte es nicht einreichen. Beide Schemas waren valide. Ihre Schnittmenge war falsch.

Riss 5: Das DELETE, das erfolgreich nichts tat. Die Customer-Deletion-Mutation im React-Frontend:

deleteCustomerMutation.mutateAsync({ params: { id } })

Das vom @hey-api generierte SDK — der TypeScript-Client, der aus der OpenAPI-Spec generiert wurde — verwendet path für URL-Route-Parameter, nicht params. params ist für Query-Parameter. Mit params: { id } statt path: { id } konstruiert der generierte HTTP-Client eine URL ohne ID-Segment im Pfad. Der DELETE-Request geht an /customers oder irgendwo, das einem anderen Route-Muster entspricht. Das Backend gibt etwas zurück, das wie Erfolg aussieht. Das Frontend empfängt es, behandelt es als Erfolg, zeigt den Toast. Der Kunde wurde nicht gelöscht. Seiten-Reload bringt ihn zurück.

TypeScript hat es nicht gefangen. Sowohl path als auch params sind gültige Keys im SDK-Options-Type. Der Compiler akzeptiert beide. Die Unit-Tests mockten den SDK-Call vollständig — sie testeten, ob mutateAsync mit einem Argument aufgerufen wurde, das eine id enthielt, nicht ob die URL korrekt sein würde. Die Integration-Tests deckten diesen spezifischen Deletion-Flow nicht ab. End-to-End-Tests: noch nicht geschrieben.

Fünf Risse. Alle auf unterschiedlichen Oberflächen. Ein gemeinsamer Nenner: Kein einziger schlug eine laufende Prüfung fehl.

Der Stopp

Irgendwann muss man wählen: flicken oder neu bauen.

Flicken ist schneller in der Woche, in der man es tut. Riss eins flicken ist ein 10-Minuten-Fix — den Import verschieben. Riss zwei flicken ist ein 5-Minuten-Fix — den Eintrag zur Exports-Map hinzufügen. Sogar Riss vier, den Schema-Drift, kann man mit einem PR adressieren, der die fehlenden Felder zum Frontend-Schema hinzufügt. Jeder einzelne Fix ist schnell. Keiner adressiert die Bedingung, die die Risse erzeugte.

Die Bedingung ist diese: Frontend und Backend pflegten parallele Definitionen derselben Domain-Objekte, ohne automatische Prüfung, dass sie synchron blieben. Das fehlende Feld zu fixen verhindert nicht das nächste fehlende Feld. Den veralteten Import zu fixen ändert nichts daran, dass die Build-Toolchain einen blinden Fleck hat. Flicken setzt voraus, dass das Fundament solide ist. Zu diesem Zeitpunkt hatte das Fundament fünf bekannte Probleme und eine unbekannte Anzahl, die ich noch nicht gefunden hatte.

Ich stoppte die Feature-Lieferung. Nicht „verlangsamte” — stoppte. Keine neuen Features gemergt, bis das Fundament adressiert war.

Die meisten Teams tun das nicht. Der Druck weiterzuliefern ist real und legitim. Ein gestoppter Sprint sieht von außen wie Regression aus. Stakeholder sehen ein Velocity-Diagramm, das flach wird. Die Versuchung ist, die Risse inkrementell zu adressieren, jeden im nächsten Sprint, während weiter Features geliefert werden. Das Problem ist, dass jedes neue Feature, das von Agents gebaut wird, die lokale Probleme lokal lösen, einen neuen Riss erzeugen kann, bevor die alten geflickt sind. Man flickt ein leckendes Boot, während man noch rudert.

Es gibt eine Kategorie von technischen Schulden, die nicht inkrementell abgebaut werden kann. Wenn der Contract zwischen Frontend und Backend keine Single Source of Truth mehr ist, kann man das nicht mit einem PR fixen. Man muss in die Architektur hineingehen und ändern, wo die Wahrheit lebt.

Die Migration war sieben Phasen. Weg von ts-rest vollständig. Der API-Contract neu aufgebaut auf OpenAPI: die Spec aus den Backend-Definitionen generieren, den TypeScript-Client aus der Spec generieren. Das Frontend pflegt kein unabhängiges Wissen über die API-Form mehr. Die Spec ist der Contract. Die Spec ist die Wahrheit. Wenn Spec und Implementierung auseinanderdriften, gewinnt die Spec — man fixt die Implementierung, um zu passen, fügt keinen Workaround im Client hinzu.

Sieben Phasen klingt sauber. Es war nicht besonders sauber. Phase eins war, die OpenAPI-Spec-Generierung im Backend zum Laufen zu bringen — die Route-Definitionen mit den Schema-Metadaten zu dekorieren, die der Generator brauchte, den Generator zu starten, zu verifizieren, dass der Output mit dem übereinstimmte, was die Routes tatsächlich akzeptierten. Phase zwei war, den TypeScript-Client aus der Spec zu generieren — einen Generator auswählen (@hey-api/openapi-ts), ihn konfigurieren, prüfen, ob die generierten Typen zu dem passten, was das Frontend aufzurufen gedachte. Phase drei war die Migration des Frontends weg von ts-rests typisierten API-Calls zum generierten Client. Phase vier war die Shared-Schema-Konsolidierung: die deutschen Fehlermeldungen, Coercion-Regeln und Cross-Field-Refinements aus ihren verstreuten Orten in eine Datei ziehen. Phasen fünf bis sieben waren Cleanup — die ts-rest-Dependency entfernen, die Type-Casts prüfen, die Exports-Map fixen, Downstream-Auflösung validieren.

Jede Phase hatte ein klares architektonisches Ziel und einen klaren Endzustand. Agents führten die Phasen aus. Jede Phase brauchte eine Session oder weniger.

packages/shared/schemas/api-requests.ts wurde die einzelne Datei, die alle API-Request-Shapes besitzt. Deutsche Fehlermeldungen zogen hierher. z.coerce für Type-Coercion an der User-Input-Grenze — dort, wo ein String aus einem Form-Input zu einer Zahl werden muss, wo ein leerer String zu undefined werden muss. Cross-Field-Refinements für Validierungsregeln, die mehrere Felder umspannen — Validierungen, die auf zwei Schemas aufgeteilt waren, weil jedes Schema nur die Hälfte des Bildes hatte. Die Frontend-Form-Schemas wurden zu dünnen Wrappern: Sie re-exportieren die Shared-Schemas und fügen nur UI-spezifische Eigenschaften wie Feldbezeichnungen hinzu. Sie definieren nichts darüber, was die API akzeptiert. Sie können nicht driften, weil sie keine eigene Definition haben, von der sie driften könnten.

// packages/shared/schemas/api-requests.ts — eine Datei, eine Wahrheit
export const UpdateSubmissionSchema = z.object({
  receiptTotal: z.coerce.number(), // coerced Form-Strings zu Zahlen
  autoRejectionThreshold: z.coerce.number(),
  notes: z.string().optional(),
}).superRefine((data, ctx) => {
  // Cross-Field-Regeln leben hier, nicht verstreut über zwei Schemas
})

// packages/shared/schemas/submission-forms.ts — dünner Re-Export
// Deutsche Fehlermeldungen, Coercion, Cross-Field-Regeln: alles geerbt, nichts dupliziert.
export { UpdateSubmissionSchema as submissionReviewFormSchema } from "./api-requests.js"

Vorher: zwei Schemas, eines driftet still vom anderen. Nachher: ein Schema, ein Import, kein Drift möglich.

Alle sieben Phasen wurden von Agents implementiert. Was ich beitrug, war nicht Code-Review der Diffs — obwohl ich sie reviewte, waren sie handhabbar, wenn die Ziele architektonisch statt feature-basiert waren. Was ich tatsächlich beitrug, waren die architektonischen Entscheidungen: wo die Single Source of Truth lebt, was in Shared-Schemas gehört versus in UI-only-Schemas, wie die Coercion-Regeln an jeder Grenze sein sollten, wie man die Migration sequenziert, damit Production nie ein Fenster hatte, in dem alter und neuer Code gleichzeitig aktiv waren.

Die Sequenzierungsfrage stellte sich als wichtiger heraus, als ich erwartet hatte. Man kann ts-rest nicht am Montag entfernen, den Client am Dienstag generieren und das Frontend am Mittwoch migrieren, wenn Production am Mittwoch läuft. Man muss über die Reihenfolge der Operationen nachdenken — was gleichzeitig in Arbeit sein kann, was voneinander abhängt, wo der Cutover stattfindet. Das ist kein TypeScript-Problem. Das ist ein Architektur-Problem. Agents halten diese Art von temporalem Reasoning nicht über Sessions hinweg, außer man gibt ihnen den vollständigen Plan von vornherein.

Das erforderte, das System strukturell zu verstehen. Nicht was sich im letzten PR geändert hatte — was das System war, als Ganzes, was es werden musste, und in welcher Reihenfolge die Transformation stattfinden musste, damit Production während der gesamten Zeit lief.

Noch etwas: Das war eine zweitägige Session. Intensiv, überfällig, und während sie lief, stand die Feature-Maschine still. Der Kunde meldete zwei UI-Bugs — nichts Ernstes, aber ich konnte sie nicht mit der gewohnten Geschwindigkeit liefern. Das fühlte sich wirklich unangenehm an. Es gab echten Druck, die Migration entweder abzuschließen oder zurückzusetzen, ein paar schnelle Fixes zu liefern und mir selbst zu versprechen, später zum Fundament zurückzukehren. Dieses Versprechen habe ich mir schon einmal gegeben. Ich sagte nein. Erst das Fundament fixen. Dann die Geschwindigkeit wiederherstellen.

Das Sicherheitsnetz

Das Fundament zu fixen beantwortet eine Frage: Ist die Architektur kohärent?

Sie beantwortet nicht: Tut das System, was wir glauben, dass es tut — von Ende zu Ende, so wie ein echter Nutzer es erleben würde?

Das sind verschiedene Fragen. Und die zweite erfordert eine andere Art von Test.

Unit-Tests validieren, dass eine Funktion für gegebene Eingaben den richtigen Output zurückgibt. Sie sind schnell, deterministisch und ausgezeichnet für Business-Logik in Isolation. Integration-Tests validieren, dass zwei Module zusammenarbeiten — dass der Service das Repository korrekt aufruft, dass das Repository korrekt auf das Datenbankschema mappt. Beide sind wertvoll. Beide waren zu diesem Zeitpunkt gut in der Test-Suite vertreten: über tausend Tests, die Unit-Logik und Modul-Integration im gesamten Codebase abdeckten.

Was keiner validiert, ist der vollständige Nutzer-Workflow. Vom Browser, durch die HTTP-Schicht, durch API-Validierung, durch Business-Logik, zur Datenbank, und zurück durch die API-Antwort zum gerenderten Zustand des Browsers. Der Unit-Test behauptet, dass die Service-Methode den richtigen Wert zurückgibt. Der Integration-Test behauptet, dass zwei Module kooperieren. Keiner behauptet, dass, wenn ein Nutzer im Browser auf „Kunde löschen” klickt, der Kunde beim nächsten Laden der Seite tatsächlich weg ist.

Genau in dieser Lücke lebte Riss fünf.

Die E2E-Suite: 130 Playwright-Tests. Vier parallele Worker. Vollständige Browser-Automatisierung. Echter Dev-Server, echte API, echte Datenbank — keine Mocks irgendwo im Stack. Jeder Test richtet seine eigenen Testdaten von Grund auf ein, führt einen vollständigen Nutzer-Workflow durch die Browser-UI aus und behauptet den Ergebnis-Zustand im Browser. Nicht „die API wurde mit diesen Parametern aufgerufen.” Nicht „die Mutation gab Erfolg zurück.” Der tatsächliche Zustand der Seite, nachdem die Operation abgeschlossen ist.

Es aufzubauen war komplizierter als es klingt.

Playwright-Worker sind separate Node.js-Prozesse. Das ist wichtiger, als es zunächst erscheint. Module-Level-State — Konstanten, die oben in einer Datei definiert sind, Singleton-Objekte, gecachte Werte — überquert keine Prozessgrenzen. Eine Shared-Campaign-ID in einem beforeAll in einem Worker zu initialisieren und zu erwarten, dass sie in einem anderen Worker noch da ist — das funktioniert nicht. Wir haben die Test-Suite von Anfang an worker-agnostisch strukturiert, was bedeutete, dass jede Shared-Resource zur Test-Laufzeit abgerufen oder erstellt werden musste, nicht beim Laden des Moduls.

getOrCreateTestCampaign() ist das Ergebnis dieser Einschränkung. Es ist idempotent: Mehrere Worker können es gleichzeitig aufrufen, jeder Worker bekommt dieselbe Campaign, und nur einer von ihnen erstellt sie tatsächlich. Die Implementierung verwendet Datenbank-Upsert-Semantik — „diese Campaign einfügen, wenn sie nicht existiert, in beiden Fällen zurückgeben” — kombiniert mit Retry-Logik für das Fenster zwischen „prüfen ob sie existiert” und „sie erstellen.” Keine Koordination zwischen Workern, kein Locking, kein Shared State. Nur sorgfältige Nutzung von Datenbankgarantien.

triggerProcessingWithRetry() existiert, weil der Backend-Submission-Processor ein Singleton ist — ein Verarbeitungslauf zur Zeit, der gleichzeitige Requests ablehnt. Mit vier Workern, die gleichzeitig Kassenbons einreichen und dann jeweils versuchen, die Verarbeitung zu starten, werden drei der vier Trigger-Calls als „Verarbeitung läuft bereits” abgelehnt. Drei Versuche, exponentielles Backoff, Jitter. Die Worker kollidieren meistens nicht — Einreichungszeiten variieren genug, dass sie sich natürlich staffeln. Wenn sie kollidieren, behandelt der Retry es sauber.

Noch eine Sache: globalSetup läuft, bevor Playwright den Entwicklungsserver startet. Wenn man versucht, API-Calls in globalSetup zu machen, um die Datenbank zu befüllen, läuft der Server noch nicht und die Calls werden fehlschlagen. Seed-Daten, die einen laufenden Server erfordern, kommen in ein beforeAll innerhalb der ersten Test-Datei, nicht in das Global-Setup.

130 Tests. Vier Worker. 36 Sekunden für die gesamte Suite.

Jetzt der Teil, den ich nicht geplant hatte.

Ich war mitten im Aufbau der E2E-Suite, als ich auf Riss fünf stieß. Der Test war unkompliziert: Einen Kunden über die UI erstellen, verifizieren, dass der Kunde in der Liste erscheint, auf Löschen klicken, behaupten, dass der Kunde nicht mehr in der Liste ist. Standard-CRUD-Verifikation. Die Art von Test, die man einmal schreibt und nie wieder daran denkt.

Der Deletion-Flow lief. Die Mutation wurde abgeschlossen. Der Erfolgs-Toast erschien. expect(customerEmail).toBeHidden() schlug fehl. Der Kunde war noch sichtbar in der Liste.

Ich prüfte den Network-Tab. Der DELETE-Request war an die richtige URL gegangen — warte, nein. Die URL war /customers ohne ID. Der Request hatte eine Route gefunden, die 200 zurückgab, ohne etwas zu löschen. Das Backend hatte seinen Job gemacht: Es empfing einen validen Request an einem validen Endpoint und gab eine valide Antwort zurück. Das Problem lag in der Request-Konstruktion. params statt path. Ein Wort. Der TypeScript-Compiler akzeptierte beide. Der Unit-Test mockte den SDK-Call. Der Integration-Test deckte diesen Flow nicht ab. Die einzige Prüfung, die sich um das Ergebnis kümmerte — statt um den Call — war der E2E-Test, und er fand das Problem, bevor es je deployed wurde.

Der Fix: params: { id } → path: { id }. Ein Wort geändert. Ein ganzes Quartal lang hatte ein Customer-Deletion-Feature stillschweigend nichts getan, gefangen, bevor es einen echten Nutzer erreichte.

Was Geschwindigkeit mit der Architektur macht

Das sagt niemand klar genug: Wenn KI-Agents das Problem der Implementierungsgeschwindigkeit lösen, legen sie den nächsten Engpass frei. Und der nächste Engpass ist nicht das, was Entwickler typischerweise erwarten.

Es ist nicht die Liefergeschwindigkeit. Die übernehmen die Agents. Mehr als zehn Commits pro Tag von einem Ein-Personen-Nebenprojekt ist jetzt wirklich real. Ich habe es über ein Quartal bewiesen, während ich einen Vollzeitjob hatte. Das ist keine Behauptung über theoretisch Mögliches — das ist, was das Git-Log sagt.

Der Engpass ist architektonische Kohärenz.

Agents sind ausgezeichnet darin, lokale Probleme lokal zu lösen. Das ist keine Kritik — es ist eine genaue Beschreibung dessen, was sie tun, und für die meisten Software-Aufgaben ist es genau das, was man will. Einen Agent bitten, deutsche Fehlermeldungen zu einem Form-Validierungsschema hinzuzufügen: Er fügt ein Zod-Schema mit deutschen Strings hinzu, korrekt strukturiert, korrekt in die Form-Library integriert. Korrekt. Einen anderen Agent in der folgenden Woche bitten, ein neues Pflichtfeld zum API-Request-Schema hinzuzufügen: Er fügt das Feld zum API-Schema hinzu, schreibt die Backend-Validierung, aktualisiert den Handler. Auch korrekt.

Kein Agent weiß von dem Schema des anderen. Keiner ist falsch. Das Kohärenzproblem — „diese zwei Dinge sollen eines sein” — gehört niemandem, weil es dem Menschen gehört. Und der Mensch liest Diffs um 22 Uhr nach einem Arbeitstag, reviewt die fünf Commits, die geliefert wurden, während er in Meetings war, und vertraut darauf, dass das Typsystem die Dinge fängt, die er nicht sieht.

Das Typsystem kann nur fangen, was man ihm zu prüfen gesagt hat. Es kann „diese Variable hat den falschen Typ” fangen. Es kann nicht fangen: „Dieses Feld existiert in einem Schema und nicht in dem Schema, mit dem es synchronisiert sein sollte, und die Konsequenz ist stiller Datenverlust beim Formular-Absenden.”

Die architektonischen Invarianten, die am meisten zählen, werden von keiner standardmäßig laufenden Prüfung durchgesetzt.

„Frontend und Backend teilen eine Single Source of Truth für Request-Shapes.” Nichts in CI prüft das. Der Type-Checker validiert, dass jedes Schema intern konsistent ist; er validiert nicht, dass zwei Schemas miteinander konsistent sind. Nichts schlägt fehl, wenn diese Invariante verletzt wird — bis ein Nutzer ein Formular absendet und Werte verschwinden.

„Das Typsystem verhindert ungültige SDK-Parameter-Namen, statt sie nur zu fangen.” Sowohl path als auch params sind im SDK-Type gültig. TypeScript sagt ja zu beiden. Nur eines konstruiert die URL korrekt.

„Die Exports-Map ist für alle Downstream-Consumer vollständig, nicht nur für den lokalen Bundler.” Vites impliziter Fallback verbirgt die Lücke. Die Lücke ist real. Sie wartet auf jemanden, der strikt auflöst.

„Eine 200-Antwort bedeutet, dass die Operation erfolgreich war.” Das klingt offensichtlich. Ist es nicht. Eine Route, die passt, aber nicht das tut, was erwartet wird, gibt 200 zurück. Das Frontend sieht 200 und zeigt Erfolg. Der Test, der das Ergebnis prüft — nicht den Status-Code, sondern den Zustand der Welt — ist die einzige Prüfung, die es weiß.

Diese Invarianten leben im Kopf des Architekten. Sie werden nicht von den Tools durchgesetzt. Sie werden nicht von Agents geprüft, außer man macht sie zur ersten Sache, die Agents prüfen. Verstöße häufen sich still an, bis jemand anhält und fragt: „Was haben wir, strukturell, gebaut?” statt „Was hat sich im letzten PR geändert?”

Ich habe die Contract-Schicht von Tag eins an gegen Ratschläge durchgesetzt, weil ich wusste, wie die Alternative aussieht. Und die Contract-Schicht wurde trotzdem zu einer leeren Hülle — nicht weil die Architektur falsch war, sondern weil sich architektonische Prinzipien nicht selbst durchsetzen. Der Mechanismus, der sie durchsetzt, braucht ebenfalls Aufmerksamkeit. Das ist der Teil, den ich nicht eingeplant hatte.

Das ist der Disziplinwechsel, der zählt. In einem traditionellen Codebase, in dem man den größten Teil des Codes selbst schreibt, setzt man sich ständig mit der Architektur auseinander. Man weiß, wo die Schema-Definitionen leben, weil man sie geschrieben hat. Man bemerkt, wenn ein neues Feld an einer Stelle erscheint und nicht an einer anderen, weil man beide Stellen anfasst. Die Architektur ist in einem, weil die Implementierung in einem war. Architektonische Kohärenz ist ein natürlicher Nebeneffekt der Autorenschaft.

In einem agentischen Codebase ist man nicht der Autor. Man ist der Architekt. Die Implementierung ist erledigt; das Design gehört einem. Das ist der Werttausch. Aber er bedeutet, dass architektonische Kohärenz aufhört, ein natürlicher Nebeneffekt zu sein, und zu einer aktiven Disziplin wird. Man muss sie einplanen. Man muss anhalten und das Ganze betrachten. Man muss Fragen stellen, die sich redundant anfühlen — „stimmen Frontend- und Backend-Schemas noch überein?” — weil nichts einen warnt, wenn die Antwort nein wird.

Was sich nach der Migration änderte: Wir haben sie verankert. Single Source of Truth, explizit, in einer Datei mit einem Namen. Build-Ausschlüsse geprüft, damit der Type-Checker alles abdeckt, was CI interessiert. Exports-Maps von einem tatsächlichen Downstream-Consumer getestet, nicht nur vom lokalen Bundler. SDK-Calls gegen die tatsächlichen Parameter-Namen im generierten Client überprüft, nicht aus der Erinnerung angenommen, was der Options-Type akzeptierte. E2E-Tests, die Ergebnisse im Browser behaupten, nicht nur dass Calls ohne Ausnahme abgeschlossen wurden.

Die menschliche Rolle in einem agentischen Codebase ist nicht das Reviewen von Diffs. Man kann nicht mit den Diffs Schritt halten — das ist der Punkt, das ist das Wertversprechen. Die menschliche Rolle ist, periodisch den Sprint zu stoppen, zurückzutreten und zu fragen: Was haben wir, strukturell, gebaut? Entspricht es der Intention? Wo sind die Contracts zwischen den Teilen, und sind sie noch kohärent?

Diese Frage wird nicht einfacher, wenn die Agents schneller werden. Sie wird wichtiger, weil die Lücke zwischen „dem letzten PR” und „der aktuellen Architektur” im Tempo der Agent-Velocity wächst, nicht der menschlichen Review-Velocity. Je schneller die Agents, desto größer kann diese Lücke werden, bevor man hinschaut.

Aktueller Stand

Ende Q1 2026. 847 Commits im Log. Die App läuft. Zahlende Kunden. Echte Campaigns mit echten Cashback-Auszahlungen, echte Kassenbons werden gescannt, verarbeitet und validiert.

Die Zahlen am Ende des Quartals: 847 Commits. Ein Entwickler. Einundneunzig Tage. Vollzeitjob die ganze Zeit. 1.000+ Unit- und Integration-Tests. 130 parallele E2E-Tests, jeder behauptet vollständige Nutzer-Workflows in einem echten Browser gegen eine echte Datenbank. Eine Single Source of Truth für den Frontend-Backend-API-Contract, in einer Datei, mit einem Namen. Ein Fundament, das wir dieses Mal tatsächlich angehalten und inspiziert haben.

Vier Artikel haben Kapitel dieser Geschichte dokumentiert — jeder zum jeweiligen Zeitpunkt geschrieben, als eigenständiger Bericht einer einzelnen Session:

• $187 und 16 Stunden: die Fundament-Session, die das gesamte System in einem Durchgang aufgebaut hat
• 97,78% Konfidenz: die OCR-Pipeline und die fünf Bugs, die nur mit echten Handyfotos auftraten
• Production Hardening: Rate-Limiting, CORS, Error-Sanitization, Prometheus — alles, was die Agents korrekt bauten, aber nie daran dachten zu schützen
• Build once, serve everywhere: zwei EC2-Instanzen auf eine reduziert, 72 KB Config

Zusammen sind sie ein Beweis dafür, dass das real ist. Eine Person, ein Quartal, ein Vollzeitjob obendrauf, mit Agents, die die Implementierung übernehmen — und das Ergebnis ist eine Production-SaaS, die normalerweise ein kleines Team und den größten Teil eines Jahres erfordern würde. 847 Commits sagen es. Die zahlenden Kunden sagen es. Das Git-Log lügt nicht.

Aber „KI-Agents sind Magie” ist die falsche Lehre daraus.

Die richtige Lehre ist, dass sich der Engpass verschoben hat. Geschwindigkeit war immer der Flaschenhals. Wollte man schneller werden, stellte man mehr Entwickler ein, bezahlte für mehr Stunden, brannte sich an Abenden und Wochenenden aus, um die Lücke zu schließen. Velocity war das, dem man nicht entkommen konnte.

Jetzt kann man ihr entkommen. Die Agents übernehmen die Lieferung in einem Tempo, das kein kleines Team erreicht. Zehn Commits pro Tag von einer Person ist real. Velocity ist nicht mehr das Problem.

Der Engpass ist architektonische Kontrolle. Kohärenz über hunderte von Commits aufrechterhalten, die man nicht vollständig reviewen kann. Sicherstellen, dass „bestanden” „korrekt” bedeutet und nicht nur „bestanden”. Die Contracts zwischen Teilen des Systems pflegen, die von verschiedenen Agents in verschiedenen Sessions gebaut wurden, und bemerken, wenn diese Contracts anfangen auseinanderzudriften. Den Sprint stoppen, wenn das Fundament Inspektion braucht, auch wenn Features im Backlog warten und ein Kunde wartet.

Das ist der Engineering-Job jetzt. Nicht schnelleres Tippen. Nicht besseres Boilerplate. Nicht Prompts, die für höhere Code-Qualität pro Token optimiert sind. Das Handwerk, ein System kohärent zu halten, wenn Implementierung nicht mehr der Engpass ist — das ist, was der Job geworden ist.

Q2 hat begonnen. Das Fundament ist gefixt. Viele Features sind geliefert. Und ich bin aufrichtig gespannt, was als nächstes kommt — nicht ängstlich, gespannt. Wird es skalieren? Was passiert, wenn mehr Kunden gleichzeitig Campaigns starten, wenn die OCR-Pipeline echtes Volumen verarbeitet, wenn die Grenzfälle ankommen, die wir uns noch nicht vorgestellt haben? Ein Quartal hat das Ding gebaut. Das nächste Quartal wird herausfinden, was es wirklich taugt. Ich werde berichten.

Geschwindigkeit war nie das Problem. Wir wussten das nur noch nicht, weil Geschwindigkeit vorher immer der Engpass war.

Jetzt ist sie es nicht mehr. Und das verändert alles daran, was mein Job tatsächlich ist.