Probabilistische Technik und der 24/7-Mitarbeiter

• Die Softwareentwicklung vollzieht stillschweigend den Übergang von deterministischen zu probabilistischen Systemen, und im Zeitalter von AI-Agenten, die über Nacht Code generieren, reviewen und mergen, verändern sich die Rolle von Entwicklerinnen und Entwicklern sowie Organisationsstrukturen grundlegend
• Innerhalb AI-nativer Teams verschieben sich Rollen nach oben und differenzieren sich zugleich nach unten, wobei das Risiko besteht, dass einfache Tätigkeiten zur Verwaltung von Agenten-Outputs als neue Niedriglohnjobs verfestigt werden
• Da die Kosten der Codegenerierung gegen null tendieren, explodiert die Menge produzierten Codes wie im Jevons-Paradoxon, doch die zentrale Herausforderung ist die Asymmetrie, dass Generierung billiger geworden ist, Verifikation aber nicht
• Weil Junior Engineers von Beginn an mit Hilfe von AI ausgefeilten Code erzeugen, ist die Trainingskrise bei Debugging, Urteilsvermögen und Handwerkskunst bereits Realität
• Da das aktuelle Modell das schwächste Modell ist, das künftig genutzt werden wird, müssen Organisationen Systeme aufbauen, die nicht auf die Fähigkeiten von heute, sondern auf noch nicht veröffentlichte Modelle der Zukunft vorbereitet sind

---

Der Übergang zur probabilistischen Technik

• Die Softwarebranche war jahrzehntelang auf einem deterministischen Vertrag aufgebaut — man schrieb Code, testete ihn, brachte ihn heraus und hatte die Gewissheit, dass er funktioniert
• Dieser Vertrag zerbricht, und unter Top-Operatoren AI-nativer Unternehmen verwandelt sich die Codebasis in etwas, von dem man glaubt, dass es funktioniert — ohne dass sich die exakte Wahrscheinlichkeit noch angeben lässt
• Auslöser war die Erfahrung beim Aufbau des Side-Projects Compound Loop — eines Systems, das mehrere Frontier-Modelle gegeneinander antreten lässt, um autonom Code zu schreiben, zu reviewen und zu mergen
  • Wenn man das System vor dem Schlafengehen auf ein echtes Problem ansetzt, triagiert man morgens einen Stack von PRs, die in der Nacht zuvor noch nicht existierten
  • Einige sind hervorragend, einige fehlerhaft, und einige machen Fragen sichtbar, die man gar nicht gestellt hatte
• Zum ersten Mal in der Geschichte der Wissensarbeit nimmt die Person, die Feierabend macht, nicht die einzige Kopie des Gehirns mit nach Hause
• Das 9-9-6-Konzept ist faktisch tot; ein 24/7-Mitarbeiter ist nicht jemand, der rund um die Uhr arbeitet, sondern jemand, dessen Agenten in massivem Parallelbetrieb arbeiten
• 2026 liegt der Engpass in den meisten Teams weiterhin nicht beim Tippen, sondern bei der Koordination, und die organisatorische Neuaufstellung steckt noch in den Anfängen

Die Ausdifferenzierung von Rollen — Aufstieg und Abstieg zugleich

• Innerhalb AI-nativer Teams zeigt sich ein viel komplexeres Muster als die saubere Erzählung, dass „alle ein Level aufsteigen“
• Aufwärtsbewegung: Die besten Engineers werden zu wirkungsvolleren PMs, die besten PMs zu Systemarchitekten, und die besten Architekten beschäftigen sich zunehmend mit Distribution, Wachstum und Marktstruktur
  • Für diese Gruppe ist dies das Arbeitsumfeld mit dem historisch höchsten Leverage
• Abwärtsdifferenzierung: Gleichzeitig werden nicht viele Engineers zu Architekten, sondern zu Spec-Autoren, Reviewern und Agenten-Babysittern
  • Sie übersetzen Absichten in maschinenlesbare Prompts und bewerten die Arbeit von Maschinen anhand von Standards, die sie selbst nicht vollständig beherrschen
  • Ein Teil davon ist wichtige Arbeit, ein anderer Teil ist Dateneingabe der 2026er-Version, nur in neue Begriffe verpackt
• Diese ausdifferenzierten Rollen dürften zu geringerer Bezahlung, niedrigerer Wertschätzung und in vielen Fällen zu Karriere-Sackgassen führen
• Die Gehaltslücke zwischen dem obersten Drittel, das Agentenflotten effektiv betreibt, und der mittleren Schicht, die Outputs verwaltet, dürfte größer werden als die Gehaltslücke zwischen Engineers und Vertrieb im vorherigen Zeitalter
• In der AI-Infrastruktur bleiben Kernel-Performance, Compiler-Design und Hardware-Abstraktion weiterhin verteidigungsfähige Burggräben — auf der untersten Ebene des System Engineering ist nach wie vor hohe deterministische Präzision erforderlich

Das Jevons-Paradoxon — Code-Version

• 1865 beobachtete der Ökonom William Stanley Jevons, dass effizientere Dampfmaschinen den Kohleverbrauch nicht senkten, sondern erhöhten — Effizienz erweiterte den Bereich dessen, wofür es sich lohnt, eine Maschine einzusetzen
• Da die Grenzkosten des Code-Schreibens gegen null tendieren, erlebt Software gerade dasselbe — man schreibt nicht weniger, sondern viel mehr und veröffentlicht viel mehr
• Unternehmen, die glauben, dass Skalierungsgesetze unbegrenzt gelten, bauen entsprechend auf — und sie werden die Gewinner einer Potenzgesetzverteilung sein
• Was in der Praxis bereits passiert:
  • Agenten eröffnen PRs, reviewen gegenseitig ihre Arbeit und schließen sie, ohne dass ein Mensch die Tastatur berührt
  • Selbstheilende Test-Suites schreiben sich bei Änderungen am zugrunde liegenden Code selbst um
  • Autonome Experiment-Loop-Systeme führen 100 Hypothesen aus, messen und verwerfen sie, während ein Team früher vielleicht drei geschafft hätte
  • Dokumentation wird beim Merge automatisch aktualisiert und nutzt sich selbst verbessernde AI-Skills
• Teams, die sich agentenzentriert restrukturiert haben, erreichen im Vergleich zum Vorjahr 3x, 5x oder 10x Output, und die Kurve flacht nicht ab, sondern steigt weiter
• Die zweite Lehre von Jevons: Wenn das Angebot explodiert, wird Selektion zur Kernaufgabe
  • Operatoren, die Agentenflotten auf die richtigen Probleme ansetzen, wertvolle Dinge aus dem Output herausfiltern und Ergebnisse in etwas Konsistentes integrieren, leisten derzeit die Arbeit mit dem höchsten Leverage in der Softwareentwicklung
  • Der Wert der Arbeit wird nicht mehr durch Produktionsaufwand bestimmt, sondern durch Richtungsgebung, Selektion und Kohärenz

Von deterministischer zu probabilistischer Technik

• Deterministische Technik war der Vertrag, der den größten Teil der Softwaregeschichte geprägt hat — wenn man Code schreibt, testet und reviewt, lässt sich sein Verhalten innerhalb eines gut verstandenen Rahmens erfassen, und Bugs sind reproduzierbar
• Probabilistische Technik ist in Frontier-Teams bereits angekommen — ein Großteil der Codebasis wird von probabilistischen Systemen erzeugt, unter Zeitdruck reviewed und in ein Ganzes integriert, das kein einzelner Mensch entworfen hat
• Die zentrale Asymmetrie: Generierung ist billiger geworden, Verifikation nicht
  • Ein Agent kann in einer Minute einen PR mit 500 Zeilen erzeugen, aber um subtile Bugs wie Concurrency-Probleme, Fehlinterpretationen der Spec oder vom Intent abweichende Implementierungen zu finden, braucht ein Senior Engineer mehr als eine Stunde
  • Reviews skalieren langsamer als Generierung und in Bezug auf die Output-Menge schlechter als linear — je mehr der Codebasis von Agenten geschrieben wird, desto mehr Kontext wird benötigt, um einzelne Teile zu beurteilen
• Ab einer bestimmten Größenordnung produziert das System mehr, als Menschen verlässlich bewerten können, und Korrektheit wird probabilistisch
• Konkrete Beispiele: Race Conditions, die den Test-Suite neun von zehn Mal bestehen; Features, die in Staging perfekt wirken, aber bei unerwarteten Prompt-Verteilungen scheitern; Migrationen, die stillschweigend eine von 10.000 Zeilen beschädigen und erst drei Wochen später entdeckt werden
• Proximal und Modular haben gemeinsame Forschung zu Basis-Aufgabentests für Frontier-Agentensysteme veröffentlicht, und die dokumentierten Fehlermuster entsprechen diesem Phänomen direkt
• Der Fehlermodus ist nicht der dramatische Zusammenbruch, sondern langsame, stille Degradation — mehr Generierung, schlechtere Review-Qualität, Anhäufung unsichtbarer Defekte und eine schleichende Erosion des Vertrauens, bis Kunden, Audits oder Produktionsvorfälle das Problem offenlegen
• Werkzeuge, die dieses Problem wirklich lösen, existieren noch nicht — kulturelle Reaktionen wie kleine Merges, strikte Gates, gnadenlose Skepsis gegenüber poliertem Output, Observability und Rollback-Disziplin helfen, aber Kultur skaliert ab einer bestimmten Teamgröße nicht mehr
• Wer dieses Problem löst, wird das Betriebssystem ernsthafter Softwareentwicklung der nächsten zehn Jahre definieren

Unterschiede in der Transformationsgeschwindigkeit nach Branche

• Der Übergang von deterministischer zu probabilistischer Technik verläuft nicht gleichmäßig, sondern ist nach Branche und Risikoprofil geschichtet

• Deterministische Schicht

  • Avionik, Medizinprodukte, Finanzhandelsinfrastruktur, nukleare Steuerungssysteme, Kerne von Zahlungsnetzwerken und andere stark regulierte Hochrisiko-Domänen
  • Agentenunterstützung wird dort vorsichtig hinter formaler Verifikation, umfangreicher Simulation und menschlichen Sign-off-Ketten eingeführt
  • Das ist kein Mangel an Vorstellungskraft, sondern eine korrekte Einschätzung des Risikoniveaus

• Probabilistische Schicht

  • Consumer-Software, interne Tools, Marketing-Systeme, die meisten SaaS-Angebote, Content-Infrastruktur sowie experimentelle und frühe Produkte
  • Die Kosten von Bugs liegen dort auf dem Niveau von Rollback, Entschuldigung und Hotfix, im Gegenzug gewinnt man eine Iterationsgeschwindigkeit, mit der die deterministische Welt strukturell nicht mithalten kann
  • Probabilistische Teams können pro Quartal 10x mehr lernen als deterministische Wettbewerber

• Convergence Zone

  • Mit klügeren Modellen und besseren Harnesses verschiebt sich die Frontier dessen, was „probabilistisch noch sicher genug“ ist, fortlaufend
  • Probabilistische Methoden dringen von unten mit 10 % nach oben in Domänen ein, die heute noch deterministisch wirken, etwa Teile von Versicherung, Gesundheitswesen und Enterprise-Infrastruktur
  • Führende Teams der probabilistischen Technik bauen deterministische Guardrails wieder auf — Formprüfungen, verifizierte kritische Pfade und hybride Systeme, in denen probabilistische Generierung durch deterministische Verifikation begrenzt wird
• Gewinner der nächsten zehn Jahre werden die Teams sein, die wissen, in welcher Schicht sie sich befinden, der Versuchung widerstehen, sich als etwas anderes auszugeben, und die Grenzen innerhalb ihres eigenen Stacks präzise festlegen

Die Agentic Fleet

• Die „Fabrikschicht“ ist keine passende Metapher — Fabrikarbeiter waren das System, das automatisiert wurde, aber die heutigen Akteure sind etwas anderes
• Die passendere Metapher ist eine Agentic Fleet — nur dass die in „Flotte“ implizierte Ordnung, Hierarchie und Zuverlässigkeit ein Niveau beschreibt, das die Realität noch nicht erreicht hat
  • Tatsächlich betreiben die meisten Operatoren eher einen Schwarm fragiler Auftragnehmer als eine gut trainierte Marine
  • Agenten haben ungleichmäßige Fähigkeiten, verhalten sich probabilistisch, liegen gelegentlich selbstsicher falsch und verursachen in großem Maßstab hohe Kosten
  • Die Orchestrierungsschicht bricht, Context Windows explodieren und die Inference-Kosten tauchen auf Rechnungen auf, die man dem Vorstand nur ungern zeigt
• Trotzdem bleibt das Flottenkonzept nützlich: Komposition (unterschiedliche Agenten für unterschiedliche Aufgaben), Koordination (Handoffs, Abhängigkeiten, Eskalationen), Kommandostruktur (Missionen festlegen, Rules of Engagement, Ergebnis-Reviews) und Schichtbetrieb (sie arbeiten innerhalb der Anweisungen weiter, während der Kommandant schläft, und berichten morgens)
• Eine gute Flotte definiert sich nicht über Output-Menge, sondern über die Konsistenz des Produzierten
• Die neue Arbeitsform:
  • Morgens triagieren und mergen
  • Tagsüber menschliche Arbeit mit hohem Leverage — Kundengespräche, Strategie, Produktentscheidungen und das Schreiben von Specs, die nächtliche Runs antreiben
  • Nachmittags reviewen und neu ausrichten, sobald die ersten Agenten zurückkommen
  • Und am Tagesende etwas tun, was die vorige Generation nicht tat — Handoff — Arbeit in die Queue stellen und der Agentenflotte Specs für nächtliche Versuche übergeben; manches wird falsch sein, manches brillant, und nur Menschen können den Unterschied beurteilen

Für Modelle bauen, die noch nicht veröffentlicht sind

• Ein Punkt, der in den letzten Jahren immer wieder betont wurde: Das Modell, das man heute nutzt, ist das dümmste Modell, das man künftig nutzen wird
• Das bedeutet jedoch nicht, dass das Fähigkeitswachstum reibungslos verlaufen wird — Kosten, Latenz, Zuverlässigkeit und Skalierungsgrenzen können die Kurve kompliziert machen
• Dennoch ist die Richtungswette durch Beobachtungen auf der Infrastrukturebene gut gestützt: Frontier-Fähigkeiten werden das heutige Niveau in den nächsten 6 bis 12 Monaten deutlich übertreffen, und die Lücke zwischen dem besten Modell heute und dem besten Modell in einem Jahr dürfte größer sein als die Lücke zwischen letztem und diesem Jahr
• Die strategische Implikation: Organisationen müssen nicht für die aktuellen Modelle, sondern für die Nutzung von Modellen, die sie noch nicht haben, Fähigkeiten aufbauen
  • Wie man Specs schreibt, Review-Kultur, Observability-Verdrahtung, Betrieb von Agentenflotten und Trainingsrituale zum Kompetenzerhalt bei Juniors — all das ist kein Gerüst für 2026, sondern Scaffolding für 2027 bis 2028
• Unternehmen, die dieses Scaffolding jetzt aufbauen, können den nächsten Fähigkeitssprung als Leverage absorbieren; Unternehmen, die warten, bis die Tools reif sind, verbringen ihr erstes Jahr damit, das zu lernen, was Early Mover bereits wissen
• Es braucht die Bereitschaft, über das hinaus in Specs, Reviews und operative Disziplin zu investieren, was die aktuellen Modelle verlangen
• Irrelevanz kündigt sich in dieser Ära nicht selbst an — sie kommt als schleichende Unfähigkeit, Teams zu folgen, die vor einem Jahr noch nicht sichtbar besser waren

Die Muskeln, die wir verlieren werden

• Ob AI die Gesellschaft entscheidend schichtet oder weitgehend demokratisiert — Menschen sind hervorragend darin, den Pfad des geringsten Widerstands zu optimieren
• Die Kernthese: Wer nicht selbst baut, verliert auch die Fähigkeit, Gebautes zu beurteilen
• Schon heute Realität: Junior Engineers, die von der ersten Woche an auf AI setzen, liefern schnell aus und produzieren polierten Code, können aber Bugs nicht finden, wenn das Modell auf unerwartete Weise scheitert — weil sie kein internes Modell des Systems entwickeln, das nur entsteht, wenn man sich um 2 Uhr morgens zum hundertsten Mal mit einem Stack Trace herumschlägt
• Geschmack lernt man nicht, indem man bei einem polierten Entwurf auf Genehmigen klickt; Urteilsvermögen entsteht nicht, wenn man statt einen Nachmittag mit einem schwierigen Problem zu verbringen in fünf Sekunden die plausible Antwort einer Maschine akzeptiert; und Handwerkskunst erwirbt man nicht, indem man die Arbeit anderer Agenten reviewt
• Das ist die Trainingskrise, die die meisten Organisationen noch nicht erkannt haben
  • Das Lehrlingsmodell der Softwareentwicklung (Junior liefert etwas Kleines aus → Senior reviewt → Junior verinnerlicht Geschmack über rote Korrekturen) bricht zusammen — Juniors releasen über Agenten, Seniors reviewen Agenten-Output statt menschlichen Output
  • Woher kommt dann die Handwerkskunst der nächsten Generation? Wie trainiert man Geschmack ohne Wiederholung? Wie ersetzt man Mentoring zu Dingen, die der Mentee nie selbst zuerst geschrieben hat?
• In den meisten traditionellen Organisationen sind die heutigen Senior Engineers die letzte Kohorte, die vollständig nach der alten Methodik ausgebildet wurde
• Eine ausgewogene Reaktion: absichtlich und regelmäßig etwas Wichtiges ohne Flotte auf die harte Tour selbst tun — die meisten Kolleginnen und Kollegen werden diese Muskeln nicht erhalten, und in zehn Jahren könnte genau das den Unterschied machen

Der unbequeme Teil

• Dieser Essay mündet bewusst nicht in Optimismus — so zu tun, als käme der Wandel nicht, hält ihn nicht auf
• Arbeit hat sich bereits für immer verändert, und zwar evolutionär und graduell im Takt der AI
• Menschen werden den Tag für die Arbeit zurückgewinnen, die sie wirklich braucht, und Maschinen werden die Nacht für die Arbeit zurückgewinnen, die immer schon einfache Arbeit war
• Mögliche Szenarien in den kommenden Jahren:
  • Eine Mitarbeiterschicht, die an der Review-Last erschöpft
  • Eine Schicht ausdifferenzierter Rollen, die das System braucht, aber nicht belohnt
  • Eine Junior-Generation, die nicht die Handwerkskunst entwickelt, auf der die Urteile heutiger Seniors beruhen
  • Teams, die Output-Menge mit Arbeitsqualität verwechseln und die Lücke erst erkennen, wenn Incidents auftreten
  • Eine immer weiter auseinandergehende Kluft zwischen Organisationen, die operative Muskeln für das nächste Modell aufgebaut haben, und jenen, die es nicht getan haben
• Die Kernaussage: eine Organisation für Modelle aufbauen, die man noch nicht hat; gelegentlich Schwieriges selbst bauen, um die Methode nicht zu vergessen; nachts die Flotte losschicken und gut schlafen in dem Wissen, dass Arbeit erledigt wird — aber wachsam bleiben gegenüber der Möglichkeit, dass manches, was zurückkommt, auf eine Weise falsch ist, die man nicht mehr gelernt hat zu sehen
• Der 24/7-Mitarbeiter ist kein Versprechen, sondern eine Verlagerung und eine Wette auf eine Zukunft probabilistischer Technik — eine Wette darauf, dass der Mensch im Loop scharf, ehrlich und gut genug trainiert bleibt, um im Loop zu sein, und dass die Organisation um ihn herum nicht für die Modelle von heute, sondern für noch nicht veröffentlichte Modelle gebaut ist