97% Bundle-Reduktion: Warum AI-Agents menschliche Expertise brauchen

Ein AI-Agent hat das Blog-System für diese Seite gebaut. Er hat die Libraries ausgesucht. Die Content-Pipeline aufgesetzt. Den Markdown-Loader geschrieben, den Rendering-Layer, das Routing. Der Code war sauber, gut strukturiert und folgte jeder Best Practice für einen React-Blog.

Er hat dabei auch eine tickende Zeitbombe mitgeliefert.

Kein Bug. Kein Crash. Etwas Schlimmeres — eine Architektur, die heute einwandfrei läuft und im Laufe der Zeit unbemerkt verfällt. Genau die Art von Problem, das kein Agent je melden wird, weil der Code nach allen Metriken, die dem Agent wichtig sind, korrekt ist.

Ein Mensch hat es entdeckt. Nicht weil Menschen besser Code schreiben als Agents — das tun sie nicht. Sondern weil Menschen etwas mitbringen, das Agents fehlt: die Erfahrung, Systemen beim langsamen Sterben zugeschaut zu haben.

Was der Agent gebaut hat

Das Blog-System nutzte import.meta.glob, um Markdown-Dateien zur Build-Zeit zu laden, und react-markdown, um sie im Browser zu rendern. Das ist der Standardansatz. Jedes React-Blog-Tutorial zeigt genau das. Es ist das erste Ergebnis bei Stack Overflow. Es ist das, wonach ein Agent greift, der auf Millionen Codebases trainiert wurde.

Und es funktioniert. Bei drei Posts fügt das Blog-System dem JavaScript-Bundle etwa 220 kB hinzu. Auf jeder modernen Verbindung unsichtbar. Alle Tests grün. Lighthouse grün. Der Agent shippt es, meldet Erfolg, geht weiter.

Was der Agent nicht sieht: Diese 220 kB werden bei sechs Posts zu 440 kB. Bei dreißig Posts zu 2 MB. Bei hundert Posts lädt jeder Besucher ein Megabyte Markdown-Content herunter, den er nie lesen wird — plus einen vollständigen Markdown-Compiler zum Parsen. Obwohl das Ergebnis bei jedem Seitenaufruf, für jeden Besucher, für immer gleich ist.

Die Architektur ist korrekt. Die Entwicklungsrichtung ist katastrophal. Und nichts in der Feedback-Schleife — keine Tests, kein Linting, kein Type Checking, kein Code-Review — würde das jemals auffangen.

Warum der Mensch es gefunden hat

Ich kenne dieses Muster. Nicht diesen exakten Code, aber genau diese Form von Problem. Ein System, das bei kleiner Last einwandfrei läuft und linear abbaut. Eine Abhängigkeit, die am Anfang unsichtbar ist und später dominiert. Eine Architektur, die niemand hinterfragt, weil sie rechtzeitig geliefert wurde.

Ich war schon der Typ, der um 2 Uhr nachts ein 4-MB-Bundle debuggt und es auf eine „vernünftige” Entscheidung zurückführt, die jemand vor achtzehn Monaten getroffen hat — und der nicht mehr im Team ist. Ich habe zugesehen, wie Performance-Budgets Woche für Woche um 10 kB schrumpften, bis irgendwann jemand bemerkt, dass der Lighthouse-Score auf Orange steht und der Fix bedeutet, die halbe Frontend-Schicht neu zu schreiben.

Diese Mustererkennung kann man nicht in einen Prompt schreiben. Es ist keine Regel, die man in einer CLAUDE.md-Datei festhalten kann. Es ist Narbengewebe aus Jahren, in denen man Systeme in der Praxis gebaut und am Laufen gehalten hat.

Als ich mir die Blog-Architektur angesehen habe, habe ich keinen Bug gesehen. Ich habe eine Entwicklungsrichtung gesehen. Und ich habe eine Frage gestellt, die der Agent nie stellen würde: „Was passiert, wenn wir tausend Posts haben?”

Das Gespräch, das es gefixt hat

So sieht Agentic Engineering in der Realität aus. Nicht „Mensch schreibt Prompt, Agent schreibt Code.” Ein Gespräch, bei dem jede Seite einbringt, worin sie wirklich gut ist.

Ich: „Dieses Eager Loading skaliert nicht. Warum wird Markdown zur Laufzeit geparst? Der Content ist statisch.”

Das ist die Absicht. Drei Sätze. Keine Implementierungsdetails. Kein Code. Nur jemand, der ein Problem erkannt und in Worte gefasst hat.

Agent: Plant die Lösung — ein Build-Time-Script, das Markdown zu HTML vorrendert, einen schlanken Metadaten-Index generiert und alles als statisches JSON ausliefert. Content wird on demand geladen, nicht ins Bundle eingebaut.

Das ist die Umsetzung. Der Agent hat die Architektur entworfen, das Build-Script geschrieben, den Data-Layer von synchron auf async umgebaut, Pagination hinzugefügt, den Sitemap-Generator aktualisiert und die Runtime-Abhängigkeiten entfernt — alles aus einem einzigen richtungsweisenden Prompt.

Ich: „Das bedeutet, rohes Markdown liegt als statische Dateien offen. Jeder kann es einfach abrufen.”

Das ist Urteilsvermögen. Der Agent hat das nicht angesprochen, weil er nicht nach Sicherheit oder Content-Exposition gefragt wurde. Er hat das Performance-Problem gelöst. Ich habe den Nebeneffekt bemerkt und es angesprochen.

Agent: Passt den Ansatz an — zur Build-Zeit zu HTML vorrendern, als JSON statt als rohes Markdown ausliefern. Keine Quelldateien mehr offen zugänglich.

Das Ergebnis:

	Vorher	Nachher
BlogPost-Chunk	161 kB (48,9 kB gzip)	4,97 kB (1,73 kB gzip)
Runtime-Abhängigkeiten	react-markdown, remark-gfm, micromark	Keine
Content-Laden	Alle Posts ins JS eingebaut	Ein Fetch pro Post
Skaliert auf 1000 Posts?	Nein	Ja

97% Reduktion. Nicht durch eine clevere Optimierung. Durch einen Menschen, der die richtige Frage stellt — und einen Agent, der die richtige Antwort umsetzt.

Was der Agent nicht kann

Der Agent schreibt besseren Code als ich. Schneller, konsistenter, weniger Tippfehler, breiteres API-Wissen. Hätte ich das genaue Refactoring beschrieben — „ersetze import.meta.glob durch ein Build-Script, nutze marked für die HTML-Konvertierung, liefere als statisches JSON” — hätte der Agent es perfekt gebaut.

Aber ich hätte das nie beschreiben müssen, wenn der Agent das Problem gesehen hätte. Und er hat es nicht gesehen, weil er Folgendes nicht kann:

Aus Erfahrung in die Zukunft denken. Der Agent bewertet Code gegen bekannte Muster. Er simuliert nicht den Zustand einer Codebase mit hundertmal mehr Content und fragt: „Funktioniert das noch?”

Architektonische Reibung spüren. Ein erfahrener Engineer sieht Eager-geladenen Content in einem JavaScript-Bundle und merkt, dass etwas nicht stimmt. Dieses Gefühl kommt vom Debuggen von Production-Incidents — nicht vom Pattern-Matching auf Trainingsdaten.

Die eigenen Defaults hinterfragen. Der Agent hat react-markdown gewählt, weil es die häufigste Lösung ist. Popularität ist ein starkes Signal in Trainingsdaten. Aber beliebt heißt nicht richtig, und „am häufigsten” bedeutet oft „am bequemsten für ein Tutorial” — nicht „am besten für Production.”

Schleichende Degradierung erkennen. Das System funktioniert heute. Der Agent hat keinen Mechanismus, um „funktioniert heute, bricht in sechs Monaten” zu bewerten. Er optimiert für die Gegenwart, nicht für die Richtung.

Was der Mensch nicht kann (effizient)

Die andere Seite ist genauso wichtig. Ich habe das Problem entdeckt — aber ich hätte es nicht in der Zeit gefixt, in der der Agent es getan hat.

Das Refactoring hat sechs Dateien berührt, ein neues Build-Script eingeführt, synchrone APIs auf async umgebaut, Pagination hinzugefügt, den Sitemap-Generator auf das neue Index-Format umgestellt und zwei Runtime-Abhängigkeiten entfernt. Der Agent hat das in einer Session erledigt. Mich hätte es einen ganzen Tag gekostet — nicht weil es schwer ist, sondern weil das mechanische Durcharbeiten von Dateien, das Verstehen von Schnittstellen, konsistente Änderungen über mehrere Module und alles testen genau das ist, worin Agents glänzen.

Die Aufteilung war klar:

• Ich: „Das skaliert nicht” → „Was ist mit offenen Quelldateien?” → „Füg einen CI-Check für die Bundle-Größe hinzu”
• Agent: Architektur planen → Build-Script implementieren → Data-Layer umbauen → Komponenten aktualisieren → Abhängigkeiten entfernen → Build verifizieren

Drei menschliche Inputs. Hunderte geänderter Zeilen durch den Agent. Das ist der Hebel von Agentic Engineering — Expertise nicht ersetzen, sondern vervielfachen.

Die Lektion, die niemand hören will

Es gibt eine verführerische Erzählung rund um AI-Agents: Sie machen Expertise überflüssig. Jeder kann alles bauen. Einfach beschreiben, was man will.

Das Blog-System beweist das Gegenteil. Ein Agent ohne menschliche Begleitung hätte eine Architektur ausgeliefert, die ein Jahr lang funktioniert und danach zur Krise wird. Nicht weil der Agent schlecht ist — sondern weil er exzellent darin ist, das zu bauen, worum man ihn bittet, und nicht dazu in der Lage ist zu hinterfragen, ob das, worum man ihn bittet, überhaupt richtig ist.

Die Agents haben den Blog gebaut. Ein Mensch hat ihn vor sich selbst gerettet.

Das ist kein Versagen der KI. Das ist der ganze Sinn der Zusammenarbeit zwischen Mensch und Agent. Der Mensch bringt die Absicht, das Urteilsvermögen, die Erfahrung, die Mustererkennung aus einem Jahrzehnt, in dem er Systeme wachsen und scheitern gesehen hat. Der Agent bringt die Geschwindigkeit, die Präzision, die Wissensbreite, die Ausdauer.

Keiner reicht allein. Zusammen haben sie ein Problem bei drei Posts entdeckt, das bei dreihundert Posts ein schmerzhaftes Refactoring geworden wäre. Sie haben es in einer Stunde gefixt statt in einer Woche. Und sie haben einen CI-Check hinterlassen — ein Bundle-Size-Budget, das den Deploy stoppt, wenn das JavaScript insgesamt 150 kB gzipped überschreitet — damit das System seine eigene Entwicklungsrichtung jetzt automatisch im Blick hat.

Dieser letzte Punkt ist wichtig. Der Mensch hat erkannt, dass eine Leitplanke nötig ist. Der Agent hat sie gebaut. Und jetzt schützt sich das System selbst, ohne dass sich einer von beiden daran erinnern muss.

Das ist architektonische Weiterentwicklung. Menschliche Absicht, Agent-Umsetzung, dauerhafter Schutz. Die Art von Ergebnis, die nur entsteht, wenn Expertise auf Fähigkeit trifft. (Dieselbe Lücke — AI führt aus, Menschen müssen steuern — taucht auch in Perfectionism Meets Agentic Migration auf.)