Engineering im Zeitalter der LLMs

• Ein Text, der anderthalb Jahre Überlegungen bei Reindeer dazu zusammenfasst, wie man im Zeitalter der LLMs Produkte und Entwicklungsorganisationen aufbauen sollte; alle Einsichten beginnen mit der Erkenntnis, dass menschlicher Kontext die knappste Ressource ist
• Die Produktionsmenge von Inhalten ist explosionsartig gestiegen, aber die menschliche Konsumgeschwindigkeit bleibt gleich; diese Lücke ist der neue Engpass — der Teufelskreis, in dem slop slop füttert (slop feeds slop), muss unterbrochen werden
• Strukturelle Entscheidungen wie Modellierung und API-Design bleiben weiterhin menschliches Terrain, und es braucht Menschen, die zu von LLMs erzeugten Ergebnissen "Nein" sagen
• Mit Code-Reviews allein kann man LLMs nicht schlagen, daher braucht es automatisch und regelbasiert aufgebaute Verteidigungsschichten wie Linter, LLM-Judges und kleine PRs
• Die Kernkompetenz von Entwickler:innen ist nicht tiefes technisches Wissen, sondern Context Switching und die Größe des eigenen Kontextfensters; angepasste Entwickler:innen werden superproduktiv, nicht angepasste werden für das Team zu einem net negative

---

Menschlicher Kontext ist eine knappe Ressource

• Eine Wahrheit, die sich in 25 Jahren Branche nicht verändert hat — die teuerste Ressource ist menschlicher Kontext; auch Menschen haben wie LLMs ein begrenztes Kontextfenster und eine Attention-Mask
• Die aktuelle Veränderung ist, dass von allen Seiten LLM-Slop hereinströmt — das Verhältnis zwischen Produktionsgeschwindigkeit und menschlicher Konsumgeschwindigkeit ist der neue Engpass
• Das Problem ist: Slop füttert Slop
  • Von LLMs aufgeblähte Code-Kommentare, langatmige PR-Beschreibungen, Dokumentation, die statt Ergebnissen nur die Historie ausbreitet
  • Das nächste LLM liest das und führt es auf dieselbe Weise fort, während sein Kontext mit Rauschen gefüllt ist
• Textinhalte in Organisationen sollten komprimiert sein und nur das enthalten, was aus Code und dessen Verhalten nicht klar hervorgeht

Bereiche, in denen Menschen nicht ersetzbar sind

• Modellierung ist Aufgabe von Menschen
  • Die CUJ (Critical User Journey) in API-Flows zu übersetzen und festzulegen, was Komponenten sind und wo ihre jeweiligen Zuständigkeiten und Grenzen liegen
  • Weil LLMs schnell Code ausspucken, verbreitet sich auch schlechte Modellierung schnell und erzeugt verzerrte Abhängigkeiten, die sich später nicht mehr korrigieren lassen
  • Je billiger die Ausführung wird, desto größer wird der Anteil menschlicher Entscheidungen über Struktur am Endwert
  • Modellierung ist die Wahrheit einer realen Organisation und sollte lebendig und an einer Stelle zugänglich sein
• API-Definitionen brauchen strenge menschliche Disziplin
  • LLMs neigen dazu, immer wieder Felder hinzuzufügen, die für eine bestimmte Aufgabe praktisch sind; jedes einzelne verschmutzt die API dauerhaft
  • Eine API ist ein public contract und kein Scratchpad — es braucht Menschen, die "Nein" sagen

Verteidigung im großen Maßstab gegen Slop

• Menschliche Code-Reviews können LLMs nicht schlagen — das skaliert nicht und endet schließlich darin, dass alle mit geschlossenen Augen freigeben
• Reindeer ist deshalb bei automatisch erzwungenen Schichten gelandet
  • Linter: absolute logische Regeln wie verbotene Abhängigkeiten zwischen Services oder Architekturgrenzen
  • LLM-Judges: Dinge, die schwer zu codieren sind, aber vom Modell geprüft werden können, z. B. implizite Verträge
• Sobald jedoch APIs berührt oder Modellierungsänderungen vorgenommen werden, ist echtes menschliches Review Pflicht
• Die Regel für den Alltag lautet: "Wirf einander keinen Slop zu"
  • Kleine PRs, wenn nötig auch gestapelte (stacked) PRs
  • Man muss der Versuchung widerstehen, einen 2.000-Zeilen-Slop-PR hinzuwerfen, ebenso wie der Wahrscheinlichkeit, dass Reviewer ihn blind freigeben
  • PRs sind die Basiseinheit von Aufmerksamkeit — wenn sie das menschliche Kontextfenster überschreiten, werden sie zwar freigegeben, aber nicht gelesen

Padded rooms — Bereiche, in denen LLMs frei laufen können

• Mit dieser Struktur lassen sich Bereiche identifizieren, in denen LLMs frei herumlaufen können: "padded rooms"
  • Bereiche ohne Einfluss auf die Modellierung und ohne langfristige Abhängigkeiten
  • Selbst wenn dort Slop entsteht, lässt er sich leicht ersetzen und breitet sich nicht über die gesamte Codebase aus
  • Das kann den Großteil des Firmen-Codes ausmachen, trägt aber keine Last (load bearing)
• Hier liegt auch die Antwort auf Kunden-Customization
  • Customization muss zu 100 % in padded rooms leben
  • Sobald sie in den Kern durchsickert, reißt der Kern auf und mit jedem neuen Kunden entsteht Risiko
  • Padded rooms sind die Infrastruktur, die es erlaubt, Kund:innen schnell "Ja" zu sagen, ohne dafür architektonisch zu bezahlen

Die wirtschaftliche Umkehr bei Technical Debt

• Die Trennung zwischen tragenden Bereichen und padded rooms verändert auch die Beziehung zu Technical Debt
• Früher: Wenn man während der Entwicklung ein Modellierungsproblem entdeckte, schob man es dem zukünftigen Ich zu; weil Umschreiben teuer war, schluckte man Debt während großer Arbeiten
• Heute: Die Kosten fürs Umschreiben nähern sich praktisch null
  • Die eigentliche Investition lag nicht im Tippen, sondern in der Modellierung
  • Wegwerfen, die Modellierung korrigieren und neu schreiben ist billig
  • Aufschieben wird extrem teuer — jedes LLM, das an falschem Code vorbeikommt, übernimmt ihn; Slop füttert Slop, und ein Modellierungsfehler, den man nicht sofort behebt, wird in kurzer Zeit zu mehrfach komplexerer Schuld

Der PM in dieser Zeit

• Die Rolle von PMs verändert sich — sie müssen eng mit den Verantwortlichen für Modellierung zusammenarbeiten, damit die CUJ beim Übersetzen in APIs und Komponenten nicht zerbricht
• Wenn PM und Modellierer:innen nicht synchron sind, entsteht entweder
  • ein Produkt, das technisch funktioniert, aber die CUJ nicht erfüllt, oder
  • ein sauberer CUJ, dessen Umsetzung vernünftigerweise nicht machbar ist
• Bei Reindeer bauen PMs MVPs direkt in einem separaten Repo
  • unter der Annahme, dass dieser Code niemals die Produktion berührt
  • um sich mit LLMs schnell zu bewegen und frei etwas bauen zu können, das man Kund:innen zeigen kann
  • Alles, was erfolgreich ist oder Kund:innen treffen soll, durchläuft den formalen Modellierungs- und Entwicklungsprozess
  • So lassen sich Demos schnell aufsetzen und Kund:innen validieren, bevor in den Kern investiert wird — eine Balance zwischen Testgeschwindigkeit für Ideen und chirurgischer Strenge bei allem, was ins Produkt kommt

Infrastruktur, die aus der Schleife befreit

• Der Unterschied zwischen Agenten, die man von Hand führt, und mehreren Tasks, die parallel laufen, während man schlafen geht, ist eine gute Reward Function
  • Fehlt sie, macht sich ein LLM auf eine Reise, von der es nicht zurückfindet
  • Gibt es sie, kann es selbst beurteilen, wann es nah dran und wann es weit weg ist
• In der Entwicklung übersetzt sich eine gute Reward Function in gute Tests
  • einschließlich E2E-Tests für die Plattform
  • damit LLMs von der schlechten Gewohnheit, sich auf Mocks zu verlassen, wegkommen, die nichts wirklich testen
  • Evals für LLM-basierte Outputs
  • LLM-Judges mit sauberem Kontext führen die automatische Review-Schleife aus — damit der Judge nicht derselben Halluzination verfällt wie der Agent, der den Code geschrieben hat
• Auf Organisationsebene muss diese Infrastruktur geteilt werden
  • Reindeer hat ein zentrales Skill-Marketplace-Repo, nach Kategorien gegliedert und mit allen internen Skills
  • Es wird automatisch von allen Harnesses wie Claude Code und Codex unterstützt, und für Menschen mit ähnlich tiefem unhinged Niveau auch von pi.dev
  • Neue Entwickler:innen erhalten sofort alle organisatorischen Skills, einschließlich der Skills für Onboarding und Setup

Die Entwickler:innen der Zukunft

• Die entscheidende Kompetenz von Entwickler:innen in dieser Zeit ist nicht tiefes Wissen, sondern Context Switching und die Größe des eigenen Kontextfensters bzw. der Attention-Mask
  • Wer großen Kontext halten kann, zwischen Tasks wechselt, ohne den Fokus zu verlieren, und mehrere Agenten parallel steuert, gewinnt
  • Punktuelle technische Tiefe wird weniger wichtig, weil LLMs sie auffüllen
• Eine weitere Kompetenz ist Modellierungsfähigkeit, ein gutes Verständnis von Systemarchitektur und ein Gespür dafür, worauf man in der Designphase achten muss
• Warum die neue Welt Entwickler:innen in zwei Gruppen teilt
  • Wer sich angepasst hat, wird superproduktiv
  • Wer sich nicht anpasst, ist nicht neutral, sondern für das Team ein net negative
  • LLMs sind ein Multiplier — für Menschen, die damit umgehen können, Produktivität; für Menschen, die es nicht können, hochbeschleunigter Schaden
  • In Bezug auf Vergütung fällt das Gehalt des zweiten Typs auf null — es wird keine Arbeit für sie geben
• Mit viel weniger Leuten lässt sich viel mehr erledigen, aber Wachstum ist sehr schwierig; man muss extrem selektiv sein

Zu den Token-Kosten

• Eine wiederkehrende Frage: Was passiert, wenn die Token-Kosten um das 5- bis 10-Fache steigen?
• Mit der Zeit wird diese Sorge unrealistisch
  • In der AI gibt es ein beschleunigtes mooresches Gesetz, die Qualität pro Dollar steigt weiter
  • Es gibt genügend Open Models, sodass sich kein Kartell bilden kann
• Warum Tokens billig sind — wenn Claudex plötzlich irrational teuer würde, würden alle einfach zu Qwen irgendeiner Neocloud wechseln