# 100 DAYS: full content for LLMs 100 DAYS software projects GmbH (https://100days.de) embeds senior specialists into software development teams for structured 100-day engagements with measurable goals and a planned exit. Expertise: agentic AI coding, dev-org modernization, high-tech prototyping, and PE/VC technology due diligence with hands-on improvement. Founder: Gaylord Aulke (30+ years software engineering, ex-Zend Technologies). Delivery is measured with throughput and cycle time, not story points (example: cycle time reduced to 10 days at Novadex). Curated overview: https://100days.de/llms.txt All articles below exist natively in English (/en/) and German (/de/), independently authored, not translated. --- # Scattered Minds: Wie viele Agenten ein Kopf beaufsichtigen kann - URL: https://100days.de/de/insights/scattered-minds/ - Language: German - Published: 2026-10-08 - Audience: CTOs / engineering leaders - Summary: Acht Coding-Agenten, alle 45 Sekunden ein Blick auf ein Zwischenergebnis, dazwischen E-Mails. Was diese Arbeitsweise mit dem Kopf macht, soweit die Forschung das weiß, und warum wir die Grenze bei zwei bis drei Threads ziehen, die echtes Urteil verlangen. ## Acht Threads, ein Kopf Auf dem Bildschirm laufen acht Agenten, jeder an einer anderen Aufgabe. Einer baut eine Datenbankmigration, einer sucht einen Fehler in der Abrechnung, einer schreibt Tests für ein Modul, das seit Monaten niemand angefasst hat. Alle fünfundvierzig Sekunden meldet sich irgendwo ein Zwischenstand. Man liest ihn, beurteilt ihn, legt den nächsten Schritt fest und springt weiter. In den Lücken dazwischen schaut man kurz ins Postfach, oder man startet gleich einen neunten Agenten, was viele tun. Die Details erledigen die Agenten, man selbst kümmert sich um Richtung und Architektur und nimmt am Ende ab. Nach drei Stunden ist man nicht müde. Der Kopf ist voll, wie ein Raum voll ist, in dem zu viele Leute gleichzeitig reden. Manche erleben genau diesen Zustand als angenehm: ein leicht zappeliger Flow, in dem ständig etwas fertig wird und man selbst den Takt vorgibt. Auch diese Erfahrung ist echt, und sie gehört in diesen Text. Am Ende steht trotzdem eine Grenze, die wir für uns gezogen haben. ## Ein Name für den Zustand Wir nennen das Reihum-Aufsicht. Die Agenten arbeiten parallel, man selbst schaut nacheinander bei ihnen vorbei, ungefähr so, wie ein Betriebssystem Rechenzeit in Zeitscheiben verteilt. Bei jedem Besuch liegt etwas Halbfertiges auf dem Tisch: ein Entwurf, ein roter Test, ein Plan mit drei offenen Fragen. Jedes davon verlangt ein Urteil. Man muss Arbeit verstehen, die man nicht selbst gemacht hat, und steht für Code gerade, den man nicht geschrieben hat. Neu ist das Grundproblem nicht. Die Ingenieurpsychologie untersucht seit Jahrzehnten, wie Menschen automatisierte Systeme überwachen, und die Robotik hat sogar ein Maß dafür, wie viele Roboter ein Mensch zugleich sinnvoll führen kann. In Versuchen mit simulierten Robotern hing diese Zahl davon ab, wie selbstständig sie arbeiteten und wie schwer die Aufgabe war. Agenten sind keine Roboter, das Prinzip gilt trotzdem: Wie viele man führen kann, hängt davon ab, wie lange jeder ohne Aufsicht auskommt. Zwei Studien übertragen die Konzepte dieser Forschung bereits auf Coding-Agenten, und eine davon beschreibt genau die Last, fremde Arbeit ausreichend verstehen zu müssen. Das Maß dafür, wie viele Roboter ein Mensch führen kann, übertragen beide nicht auf Agenten ([Quellen im Anhang](#supervisory-control-und-fan-out)). ## Wen diese Arbeitsweise befreit Vor den Kosten kommt etwas anderes, und das schreibe ich selbst. Für mich ist diese Arbeitsweise eine Befreiung. Zum ersten Mal kann ich mehrere Gedankenstränge parallel verfolgen und jeden davon fachlich ordentlich durchdeklinieren. Die Ergebnisse kommen schnell. Der Stand der Technik fließt von allein ein, und meine Konzepte werden unterwegs hinterfragt und korrigiert. Woran das liegt, kann ich genau benennen. Ich lasse die Details los, und die Zeit, bis eine kreative Idee in der Praxis überprüft ist, ist auf einen Bruchteil geschrumpft. Beides zusammen macht die Arbeit für mich motivierend. Nicht allen geht es so. Was ich hier beschreibe, ist meine Erfahrung mit dieser Arbeit. ## Was die Befragung zeigt Am nächsten kommt diesem Zustand eine Befragung der Boston Consulting Group unter Beschäftigten großer US-Unternehmen. Die Ergebnisse sind im März 2026 in der Harvard Business Review erschienen. Als Beraterumfrage beruht sie auf Selbstauskünften und zeigt Zusammenhänge zu einem einzigen Zeitpunkt. Die Autoren nennen das Phänomen „AI brain fry“: geistige Erschöpfung durch übermäßige Nutzung oder Beaufsichtigung von KI-Werkzeugen, die über die eigene Kapazität hinausgeht. Die Befragten beschreiben Nebel im Kopf, Konzentrationsprobleme, langsamere Entscheidungen und Kopfschmerzen. Eine Minderheit der KI-Nutzer kannte das aus eigener Erfahrung, und Engineering gehört zu den stärker betroffenen Bereichen. Am stärksten geht die Erschöpfung mit der Aufsicht einher: Wer KI-Werkzeuge intensiv beaufsichtigte, berichtete von mehr Anstrengung, Ermüdung und Informationsflut, und wer den Zustand kannte, nach eigener Einschätzung auch von mehr Entscheidungsmüdigkeit und mehr Fehlern. Die Autoren grenzen das ausdrücklich von Burnout ab: KI-Nutzung an sich ging in ihren Daten nicht mit mehr Burnout einher ([Zahlen und Einschränkungen im Anhang](#die-befragung-von-bcg)). Dazu kommt eine Kurve. Wer zwei KI-Werkzeuge gleichzeitig nutzte, schätzte seine Produktivität deutlich höher ein als jemand mit einem, und wer drei nutzte, noch etwas höher. Bei mehr als drei Werkzeugen sank der Wert. Verglichen werden dabei verschiedene Menschen, und gemessen wird ihre gefühlte Produktivität. Was eine einzelne Person tatsächlich liefert, wenn sie Werkzeuge dazunimmt, steht nicht in den Daten. Die Form ist trotzdem deutlich: Die Kurve steigt, flacht ab und knickt ([Grafik im Anhang](#die-befragung-von-bcg)). ## Der Engpass beim Entscheiden und beim Wechseln Drei Befunde passen zusammen. Der erste betrifft das Entscheiden. In einem Laborexperiment mit Hirnscans lief bei zwei überlappenden Aufgaben die frühe Wahrnehmung weitgehend parallel, während sich die Aufgaben bei der Auswahl der Reaktion hintereinander anstellten. Das Experiment drehte sich um einfache Tastendrücke, die Übertragung auf Agentenaufsicht ist unser Schluss: Acht Zwischenstände nimmt man fast gleichzeitig wahr, entschieden wird über einen nach dem anderen. Hinzu kommt der Wechsel. In zwei Experimenten fiel es Menschen schwer, die Aufmerksamkeit von einer unfertigen Aufgabe zu lösen, und ihre Leistung bei der nächsten litt darunter. Die Forschung nennt diesen Rest an Aufmerksamkeit, der an der vorigen Aufgabe hängen bleibt, Attention Residue. Nur wer die erste Aufgabe unter Zeitdruck abgeschlossen hatte, löste sich leichter von ihr. Bei der Reihum-Aufsicht ist beim Wechsel fast nie etwas abgeschlossen. Zuletzt geht es um die Rückkehr: In einer kleinen Beobachtungsstudie in einem einzigen Unternehmen vergingen im Schnitt rund 25 Minuten, bis jemand zu unterbrochener Arbeit zurückkehrte, sofern das am selben Tag geschah. Ein Takt von 45 Sekunden ist um ein Vielfaches kürzer, ein Thread wird also kaum je mit freiem Kopf wieder aufgegriffen. Wir folgern daraus, dass sich dieser Zustand während der Arbeit anhäuft. Eine Messung dazu kennen wir nicht ([Studien und Zahlen im Anhang](#engpass-wechsel-und-unterbrechung)). ## Das Lagebild geht verloren Lisanne Bainbridge hat 1983 beschrieben, was Leitwarten seither begleitet. Automatisierung könne die Probleme mit dem menschlichen Bediener eher vergrößern als beseitigen, schreibt sie. Ihm bleibt, was sich nicht automatisieren ließ, und er muss übernehmen, wenn etwas aus dem Ruder läuft, also dann, wenn Fähigkeiten gefragt sind, die ohne Übung verkümmern. Sie schrieb über die Prozessindustrie, die Übertragung auf Agenten ist unsere Analogie. Ein Experiment aus den Neunzigern zeigt, was dabei mit dem Verständnis passiert. Wer bei einer automatisierten Navigationsaufgabe die Entscheidungen nicht mehr selbst traf, verstand die Lage schlechter und entschied nach einem Ausfall der Automatik langsamer, obwohl er dieselben Informationen auf dem Bildschirm sah. Für die Reihum-Aufsicht heißt das: Man sieht alles und versteht weniger, weil man die Details nicht mehr selbst entscheidet. Eingreifen muss man genau dann, wenn der Agent scheitert, also im ungünstigsten Moment und mit dem schwächsten Lagebild ([Quellen und Zitate im Anhang](#automatisierung-und-lagebild)). Eine Gruppe von Microsoft Research hat mit ParallelPilot ein Werkzeug gebaut, das hier helfen soll, und es im einzigen kontrollierten Laborexperiment zu parallelem Programmieren mit KI geprüft, das wir gefunden haben. Der Durchsatz stieg deutlich, und die Teilnehmer fanden es weniger mühsam, den Überblick zu behalten. Das Gefühl, die Lage im Griff zu haben, stieg dagegen nicht signifikant. Die Studie ist klein und nicht begutachtet, und die Autoren prüfen ihr eigenes Werkzeug. Wir lesen daraus: Den Zustand auszulagern entlastet das Arbeitsgedächtnis, das Lagebild bleibt so lückenhaft wie zuvor ([Zahlen und Einschränkungen im Anhang](#parallelpilot-von-microsoft-research)). Über Wochen kommt etwas Leiseres hinzu. In einer Befragung von Wissensarbeitern gaben die Befragten umso weniger kritisches Denken an, je mehr sie der KI bei der konkreten Aufgabe vertrauten, und umso mehr, je mehr sie ihren eigenen Fähigkeiten trauten. Auch das ist eine einmalige Selbstauskunft, einen Verlauf über Wochen hat die Studie nicht gemessen. Wir halten einen solchen Abbau für wahrscheinlich, denn das Gespür für einen falschen Zwischenschritt verkümmert wie jede Fähigkeit, die man nicht benutzt ([Studie im Anhang](#automatisierung-und-lagebild)). ## Was die Forschung nicht sagt Einen Längsschnitt oder ein Experiment zu genau diesem Muster haben wir nicht gefunden: mehrere voneinander unabhängige Agenten, ein Mensch, ein Blick im Takt von Sekunden, über Wochen. Die BCG-Daten sind ein Querschnitt aus Selbstauskünften. Ob intensive Aufsicht erschöpft, ob erschöpfte Menschen anders mit ihren Werkzeugen umgehen oder ob ein dritter Faktor beides erklärt, lässt sich daraus nicht ablesen. Eine Studie, die diese Arbeitsweise mit validierten klinischen Messinstrumenten untersucht, kennen wir nicht. Die Belege reichen für Ermüdung, zersplitterte Aufmerksamkeit und Kosten beim Entscheiden, und dabei bleibt dieser Text. Eine belastbare Zahl für die Kapazität kennen wir ebenfalls nicht. Die Befragung zählt KI-Werkzeuge, und ein Thread mit einem Coding-Agenten ist eine andere Einheit. Dass die Kurve irgendwo knickt, ist gut begründet. Wo sie für Coding-Agenten knickt, weiß noch niemand. Die Unterschiede zwischen Menschen sind groß und folgen keiner einfachen Regel. In einer Simulation der US-Armee litten Bediener, die ihre eigene Aufmerksamkeitssteuerung hoch einschätzten, stärker unter Fehlalarmen der Automatik, Bediener mit niedriger Einschätzung stärker unter übersehenen Ereignissen. Welche Fehler wen treffen, hängt von der Person ab. In einer Interviewstudie mit Entwicklern mit ADHS schilderte eine Person, wie mehrere gleichzeitig laufende Agenten sie in Schwung halten, andere fanden das Prüfen großer Mengen KI-Code erschöpfend ([beide Studien im Anhang](#unterschiede-zwischen-menschen-und-gegenpositionen)). Bleibt der berechtigte Einwand, dass jedes neue Medium dieselben Klagen hervorgebracht hat. Amy Orben hat diesen Kreislauf von Technikängsten beschrieben. Unser Argument stützt sich deshalb auf den seriellen Engpass beim Entscheiden, und den räumt sogar Steven Pinker ein, der gegen solche Ängste angeschrieben hat ([Quellen im Anhang](#unterschiede-zwischen-menschen-und-gegenpositionen)). ## Wo wir die Grenze ziehen Den stärksten Einwand aus der Praxis hat Rémy Duthu formuliert. Noch im März beschränkte er sich auf zwei Agenten, im Juni führte er manchmal ein Dutzend gleichzeitig und fühlte sich weniger gehetzt, weil autonomere Agenten und eine Statusübersicht aus dem ständigen Nachsehen eine Warteschlange gemacht hatten, die er der Reihe nach abarbeitete. Er räumt aber ein, dass zwei gleichzeitige Unterbrechungen genauso viel kosten wie eh und je und dass die Flut seiner PRs den Kollegen beim Review mehr Arbeit macht ([Quelle im Anhang](#unterschiede-zwischen-menschen-und-gegenpositionen)). Damit schärft er unsere Grenze. Es kommt auf die Zahl der Threads an, die im selben Moment ein Urteil verlangen, und der Takt von 30 bis 60 Sekunden ist eine Gewohnheit, die gutes Werkzeug abschaffen kann. Unsere Empfehlung leiten wir aus der Form der Befunde ab. Niemand hat diese Grenze gemessen, sie ist unsere: - Zwei bis drei Threads, die echtes Urteil verlangen. - Vier bis acht nur, wenn sich die meisten von selbst melden, sobald etwas vom Plan abweicht, und höchstens ein oder zwei gerade aktiv geprüft werden. - Den Zustand auslagern: Was jeder Thread gerade tut und worauf er wartet, steht in einer Übersicht. - Reviews bündeln und die Agenten in einem selbst gewählten Rhythmus prüfen. - Die Lücke leer lassen. Die halbe Minute zwischen zwei Entscheidungen ist Pause, das Postfach bleibt zu. - Regelmäßig einen Thread bis auf die Ebene der Implementierung verfolgen, den Code lesen und selbst etwas ändern. Sonst wird man zu dem Bediener, der nur eingreift, wenn er am wenigsten weiß. ## Warum wir das verfolgen Wir arbeiten jeden Tag mit [Coding-Agenten](/de/agentic-coding/), auch in Kundensystemen, und sind dabei selbst an diese Grenze gestoßen. Deshalb verfolgen wir die Forschung dazu genau und passen unsere eigene Arbeitsweise an, sobald sie etwas Belastbares liefert. ## Anhang: Zahlen und Quellen Hier stehen die Belege zu den Abschnitten oben: Zahlen, wörtliche Zitate, der Aufbau der Studien, ihre Einschränkungen und die Quellenangaben. ### Supervisory Control und Fan-out Die Ingenieurpsychologie nennt die Überwachung automatisierter Systeme Supervisory Control; das Feld geht wesentlich auf Thomas Sheridan zurück. - **Fan-out:** Die Robotik misst damit, wie viele Roboter ein Mensch zugleich sinnvoll führen kann (Olsen und Goodrich 2003). An simulierten Robotern lag der Fan-out im Mittel zwischen etwa eins und neun, je nach Autonomie der Roboter und Schwierigkeit der Aufgabe (Olsen und Wood 2004). - **Coding-Agenten:** Park und Kollegen haben 19 erfahrene Entwickler bei der Arbeit mit Coding-Agenten beobachtet, daraus ein Modell der Aufsicht abgeleitet und es auf 102 Reddit-Diskussionen unter Entwicklern angewandt. Dort taucht die Last auf, fremde Arbeit ausreichend verstehen zu müssen ([arXiv:2609.24234](https://arxiv.org/abs/2609.24234)). Diese Arbeit und eine zweite von Long und Kollegen ([arXiv:2609.33113](https://arxiv.org/abs/2609.33113)) übertragen Sheridans Konzepte bereits auf Coding-Agenten, den Fan-out allerdings nicht. ### Die Befragung von BCG Bedard, Kropp und Kollegen (Boston Consulting Group): [„When Using AI Leads to ‚Brain Fry‘“](https://hbr.org/2026/03/when-using-ai-leads-to-brain-fry), Harvard Business Review, März 2026. Befragt wurden 1.488 Vollzeitbeschäftigte in den USA, die bei großen Unternehmen arbeiten. **Einschränkungen.** Eine Beraterumfrage, ohne Begutachtung und ohne offengelegte Methodik, von einem Haus, das an KI-Projekten verdient. Die Daten sind ein Querschnitt aus Selbstauskünften und zeigen Zusammenhänge zu einem einzigen Zeitpunkt. **Begriff.** Die Autoren beschreiben „AI brain fry“ als geistige Erschöpfung durch übermäßige Nutzung oder Beaufsichtigung von KI-Werkzeugen über die eigene kognitive Kapazität hinaus (Übersetzung von uns). Die Befragten berichten von einem „Summen“ oder einem Nebel im Kopf, von Konzentrationsproblemen, langsameren Entscheidungen und Kopfschmerzen. **Verbreitung.** 14 Prozent derer, die KI bei der Arbeit nutzen, kannten das aus eigener Erfahrung, mit großen Unterschieden zwischen den Unternehmensbereichen: 6 Prozent im Rechtsbereich, 26 Prozent im Marketing. Engineering gehört zu den stärker betroffenen Bereichen. **Aufsicht.** Wer KI-Werkzeuge intensiv beaufsichtigte, gab 14 Prozent mehr geistige Anstrengung an als Befragte mit wenig Aufsicht, dazu 12 Prozent mehr geistige Ermüdung und 19 Prozent mehr Informationsüberflutung. Wer „brain fry“ kannte, berichtete von 33 Prozent mehr Entscheidungsmüdigkeit und lag bei kleinen Fehlern um 11, bei großen um 39 Prozent höher, jeweils nach eigener Einschätzung. **Burnout.** Die Autoren trennen das ausdrücklich von Burnout: KI-Nutzung an sich ging in ihren Daten nicht mit mehr Burnout einher, und wer KI für repetitive Aufgaben einsetzte, hatte sogar um 15 Prozent niedrigere Burnout-Werte. **Die Kurve.** Die selbst eingeschätzte Produktivität lag bei zwei gleichzeitig genutzten KI-Werkzeugen deutlich höher als bei einem, mit einem dritten noch einmal etwas höher. „After three tools, though, productivity scores dipped“, schreiben die Autoren. Verglichen werden dabei verschiedene Menschen zu einem Zeitpunkt, und gemessen wird ihre gefühlte Produktivität. Was eine einzelne Person tatsächlich liefert, wenn sie Werkzeuge dazunimmt, steht nicht in den Daten. [Figure: Selbst eingeschätzte Produktivität nach Zahl der gleichzeitig genutzten KI-Werkzeuge, aus einer Querschnittsbefragung, die verschiedene Menschen vergleicht. Der Text der Studie nennt keine Werte, deshalb zeigt die Kurve nur die Form: deutlicher Anstieg von einem auf zwei Werkzeuge, kleinerer Zuwachs mit dem dritten, danach Rückgang. Wo genau die Kurve für Agenten knickt, weiß noch niemand.] ### Engpass, Wechsel und Unterbrechung - **Serieller Engpass:** Yue, Newton und Marois haben 26 jungen Erwachsenen per ultraschneller 7-Tesla-fMRT ins Gehirn geschaut, während sich zwei einfache Reaktionsaufgaben überlappten ([Nature Communications, 2025](https://doi.org/10.1038/s41467-025-58228-0)). Die frühe Wahrnehmung lief weitgehend parallel. Bei der Auswahl der Reaktion stellten sich die Aufgaben im frontoparietalen Netzwerk hintereinander an. Das ist Laborarbeit mit Tastendrücken, die Übertragung auf Agentenaufsicht ist unser Schluss. - **Addy Osmani** hat den Engpass im April [in einem Blogbeitrag](https://addyosmani.com/blog/cognitive-parallel-agents/) knapper beschrieben: „Your cognitive bandwidth doesn't parallelize.“ - **Attention Residue:** Leroy hat 2009 in zwei Experimenten gezeigt, dass es Menschen schwerfällt, die Aufmerksamkeit von einer unfertigen Aufgabe zu lösen, und dass die Leistung bei der nächsten darunter leidet ([Organizational Behavior and Human Decision Processes](https://doi.org/10.1016/j.obhdp.2009.04.002)). Der Fachbegriff steht schon im Titel ihrer Arbeit. Nur wer die erste Aufgabe unter Zeitdruck abgeschlossen hatte, löste sich leichter von ihr und schnitt auch bei der nächsten besser ab. Wie lange Attention Residue zum Abklingen braucht, hat Leroy nicht erfasst. - **Unterbrechungen:** Mark, Gonzalez und Harris haben 2005 auf der CHI beschrieben, wie lange unterbrochene Arbeit liegen bleibt. Wurde sie am selben Tag wieder aufgenommen, vergingen im Schnitt 25 Minuten und 26 Sekunden bis zur Rückkehr, mit durchschnittlich 2,26 anderen Vorhaben dazwischen. Die Zahl beruht auf 24 Personen in einem Unternehmen, streut stark und misst nur die Zeit bis zur Rückkehr. Wann jemand danach wieder ganz bei der Sache ist, erfasst sie nicht. ### Automatisierung und Lagebild - **Bainbridge:** Lisanne Bainbridge, „Ironies of Automation“, 1983 ([Automatica](https://doi.org/10.1016/0005-1098%2883%2990046-8)). Automatisierung könne die Probleme mit dem menschlichen Bediener eher vergrößern als beseitigen, schreibt sie, und je weiter ein Steuerungssystem entwickelt sei, desto wichtiger sei womöglich der Mensch. Und weiter: Indem die Automatisierung dem Bediener die leichten Teile seiner Aufgabe abnimmt, kann sie ihm die schwierigen erschweren (Übersetzung von uns). Sie schrieb über Leitwarten der Prozessindustrie. - **Endsley und Kiris** haben 1995 eine Navigationsaufgabe in fünf Stufen automatisiert ([Human Factors](https://doi.org/10.1518/001872095779064555)). Wer die Entscheidungen nicht mehr selbst traf, verstand die Lage schlechter und entschied nach einem Ausfall der Automatik langsamer, obwohl er dieselben Informationen auf dem Bildschirm sah. Die Autoren führen das auf den Übergang von aktiver zu passiver Verarbeitung zurück. Bei voller Automatisierung war der Verlust größer als auf mittleren Stufen, wie Endsley 1996 in einem Buchkapitel ausführt, und er betraf das Verstehen der Lage, während die Wahrnehmung intakt blieb. - **Kritisches Denken:** Lee, Sarkar und Kollegen haben 319 Wissensarbeiter zu 936 konkreten Einsätzen generativer KI befragt ([CHI 2025](https://doi.org/10.1145/3706598.3713778)). Je größer das Vertrauen in die KI bei der konkreten Aufgabe, desto weniger kritisches Denken gaben die Befragten an. Je größer das Vertrauen in die eigenen Fähigkeiten, desto mehr. Die Studie ist eine einmalige Selbstauskunft und hat keinen Verlauf über Wochen gemessen. ### ParallelPilot von Microsoft Research Long et al., [arXiv:2609.33113](https://arxiv.org/abs/2609.33113). **Ergebnisse.** Bei 16 Teilnehmern und Blöcken von 20 Minuten stieg der Durchsatz um 63 Prozent, von 0,272 auf 0,445 Tickets pro Minute, und in der Spitze lief im Schnitt etwa ein Agent mehr gleichzeitig (3,25 gegenüber 2,31). Den Aufwand, den Überblick zu behalten, bewerteten die Teilnehmer niedriger (2,75 gegenüber 4,63 auf einer siebenstufigen Skala). Das Gefühl, die Lage im Griff zu haben, stieg nicht signifikant, ebenso wenig der empfundene Erfolg beim Eingreifen. Nach Darstellung der Autoren fiel mit der Buchführung auch eine Mühe weg, die bei den Teilnehmern das Gefühl von Kontrolle gestärkt hatte. **Einschränkungen.** Die Studie ist nicht begutachtet, und die Autoren prüfen ihr eigenes Werkzeug an kleinen Übungsprojekten. Die Teilnehmer brachten meist mehrere Jahre Programmiererfahrung mit, standen beim parallelen Arbeiten mit KI aber fast alle noch am Anfang. Code-Reviews wurden nicht gemessen. ### Unterschiede zwischen Menschen und Gegenpositionen - **Aufmerksamkeitssteuerung:** Chen und Terrence, [Ergonomics 2009](https://doi.org/10.1080/00140130802680773), zur Simulation der US-Armee. - **Entwickler mit ADHS:** In einer Interviewstudie von 2026 mit 14 Entwicklern mit ADHS (formal diagnostiziert oder selbst identifiziert) beschrieb eine Person, wie sie mit mehreren gleichzeitig laufenden Agenten in Schwung bleibt. Andere Teilnehmende berichteten, dass das manuelle Prüfen großer Mengen KI-Code vor allem bei heiklen Projekten und kritischen Produktivsystemen erschöpft und Angst vor versteckten Fehlern macht (Pimenova et al., [arXiv:2609.21254](https://arxiv.org/abs/2609.21254)). - **Technikängste:** Amy Orben hat den Kreislauf von Technikängsten 2020 beschrieben ([Perspectives on Psychological Science](https://doi.org/10.1177/1745691620919372)). - **Steven Pinker** schrieb 2010 in der New York Times gegen solche Ängste an und räumte dabei ein: „Genuine multitasking, too, has been exposed as a myth.“ - **Rémy Duthu** hat seinen Einwand im Juni [im Blog von Mergify](https://mergify.com/blog/how-agents-work-with-parallel-agents) formuliert. Im März beschränkte er sich auf zwei Agenten, heute sind es manchmal ein Dutzend gleichzeitig. Er räumt ein, dass zwei gleichzeitige Unterbrechungen genauso viel kosten wie eh und je und dass das Code-Review darunter leidet: Die Flut seiner PRs macht den Kollegen beim Review mehr Arbeit. --- # Die Tests, die niemand löscht - URL: https://100days.de/de/insights/tests-nobody-deletes/ - Language: German - Published: 2026-10-08 - Audience: CTOs / engineering leaders - Summary: Seit Agenten Tests schreiben, kostet ein Test fast nichts mehr, und die Suiten wachsen schneller, als jemand sie lesen kann. Eine Studie vom Juni 2026 misst, welches Verhalten dabei ungeprüft bleibt. Zeilenabdeckung und Mutationsbewertung bemerken davon wenig. ## Endlich schreibt jemand die Tests Fast jeder, der mit Agenten arbeitet, kennt diesen Moment. Seit Monaten liegt ein Modul ohne ordentliche Tests herum, alle wissen es, und keiner kommt dazu. Dann bittet man Claude darum, und kurz darauf steht eine ganze Testklasse da. Sie läuft grün und enthält sogar Fälle, die man selbst übersehen hätte. Die Erleichterung ist groß und berechtigt. Ein paar Monate später sieht dasselbe Repository anders aus. Die Suite hat sich verdreifacht, und den größten Teil davon hat niemand gelesen. Der grüne Balken in der CI meldet jetzt vor allem eines: dass sehr viele Tests durchlaufen. ## Jeder Test ist Code, der mitgepflegt werden muss Tests sind Code. Ein Test, der Verhalten prüft, hängt an jeder Einzelheit, die er abfragt: Methodennamen, Rückgabeformate, Fehlermeldungen, die Reihenfolge der Aufrufe im Mock. Ändert sich die Anwendung, müssen die Tests mit. John Ousterhout nennt das „Change Amplification“: Eine scheinbar einfache Änderung erzwingt Anpassungen an vielen Stellen ([Quelle](#change-amplification)). Jede Prüfung in einem Test ist eine weitere solche Stelle. Schon vor den Agenten wuchsen die Tests in den meisten untersuchten Projekten schneller als der Code. Seit Agenten mitschreiben, kommt noch mehr dazu: Mitte 2025 fasste bereits mehr als die Hälfte der Pull Requests, die Agenten stellten, auch Testdateien an ([Zahlen im Anhang](#wachstum-der-testsuiten)). Dass Suiten dadurch langsamer werden, beobachten wir in Kundenprojekten. Eine belastbare Studie dazu kennen wir nicht, nur die Angaben eines CI-Anbieters: Bei ihm fallen mehr Läufe an, und das mittlere Team verbraucht dort pro ausgelieferter Änderung mehr CI-Credits. Auch die Erklärung, das liege an der KI, stammt von ihm ([Zahlen im Anhang](#wachstum-der-testsuiten)). [An anderer Stelle](/de/insights/end-of-software/) haben wir beschrieben, wie Agenten Code zur Wegwerfware machen. Tests hebt bisher jeder auf, und mit jedem Agentenlauf kommen neue dazu. ## Welches Verhalten kein Test prüft Partha Protim Paul und Reid Holmes haben eine Frage untersucht, die kein Abdeckungsbericht beantwortet: Welches Verhalten, das eine Methode zeigen soll, prüft überhaupt kein Test? Ihr Werkzeug liest dazu Dokumentation und Quelltext jeder Methode, leitet daraus die einzelnen erwarteten Verhaltensweisen ab und sucht zu jeder den passenden Test. Was danach ohne Test dasteht, nennen die Autoren die Verhaltenslücke. In den Suiten, die Entwickler selbst geschrieben haben, bleibt mindestens jedes sechste erwartete Verhalten ungeprüft. Für vier der Bibliotheken gibt es auch generierte Suiten, und die schneiden schlechter ab, gleich, ob ein klassischer Generator sie erzeugt hat oder ein Sprachmodell. Am meisten bleibt bei der Suite aus dem Sprachmodell offen. Die Zeilenabdeckung verrät davon wenig. Bei allen drei Arten von Suiten erreicht der größte Teil der Methoden eine hohe Zeilenabdeckung. Generierte Suiten sehen im Abdeckungsbericht also gut aus und prüfen trotzdem weniger von dem, was der Code tun soll. Die Studie ist ein Preprint vom Juni 2026. Aufbau, Zahlen für die einzelnen Projekte und Einschränkungen stehen [im Anhang](#die-studie-von-paul-und-holmes), dort auch als Grafik. ## Warum Abdeckung und Mutationsbewertung die Lücke übersehen Zeilenabdeckung zählt jede ausgeführte Zeile mit, auch wenn der Test das Ergebnis danach nie ansieht. Deshalb haben selbst vollständig abgedeckte Methoden oft noch ein Verhalten, das niemand prüft ([Zahlen im Anhang](#abdeckung-und-mutationsbewertung)). Die Mutationsbewertung ist strenger. Sie baut kleine Fehler in den Code ein und zählt, wie viele davon die Suite bemerkt. Trotzdem hat fast ein Drittel der Methoden, bei denen die Entwicklersuiten jeden eingebauten Fehler erkennen, noch eine Lücke. Heikel wird es, sobald diese Kennzahlen zum Aufräumen dienen. Wer eine Suite nach Abdeckung ausdünnt, verliert messbar an Fehlererkennung. Das zeigt sich an künstlich eingebauten Fehlern ebenso wie an echten fehlgeschlagenen Builds: Tests, die ein Reduktionsverfahren für überflüssig erklärt hatte, fanden dort weiterhin Fehler ([Studien im Anhang](#abdeckung-und-mutationsbewertung)). ## Wie Meta generierte Tests aussiebt Meta hat 2024 beschrieben, wie generierte Tests dort in die Codebasis gelangen. Das Werkzeug TestGen-LLM schickt jeden Kandidaten durch drei Filter: Er muss sich bauen lassen, zuverlässig bestehen und die Zeilenabdeckung erhöhen. Was danach übrig ist, sieht sich ein Mensch an. Bei drei Vierteln der untersuchten Testklassen kam kein einziger generierter Test durch alle drei Filter ([Zahlen im Anhang](#metas-testgen-llm)). Der letzte Filter misst nur Zeilenabdeckung, mit den Schwächen aus dem vorigen Abschnitt. Immerhin gibt es bei Meta eine Hürde, und die fehlt in vielen Teams, die Agenten Tests schreiben lassen. ## Der stärkste Einwand: Agenten reparieren Tests in Minuten Das beste Gegenargument stammt von Simon Willison. Sinngemäß schreibt er, die alten Gründe gegen das Testen seien hinfällig, seit ein Agent kaputte Tests in wenigen Minuten wieder zum Laufen bringt ([Zitat im Anhang](#der-einwand-von-simon-willison)). Damit wäre Change Amplification kein Problem mehr. Für das Umschreiben stimmt das. Teuer bleibt die Entscheidung, ob der umgeschriebene Test noch das richtige Verhalten prüft, und die Verhaltenslücke wird nicht kleiner, wenn ein Agent schneller anpasst. Wir behaupten deshalb weniger: Die Kosten der Testpflege wachsen mit der Menge ungelesener Tests, und diese Menge wächst in den Projekten, die wir kennen, derzeit schnell. ## Was Teams jetzt konkret ändern können **Generierte Tests müssen eine Hürde nehmen.** Ein Kandidat gelangt nur ins Repository, wenn er sich bauen lässt, wiederholt stabil besteht und ein Verhalten prüft, das noch kein anderer Test prüft. Im Review steht deshalb zu jedem generierten Test, welches Verhalten er absichert. Fehlt diese Angabe, fehlt der Grund für den Test. **Gemessen wird am Diff.** Die Idee aus der Studie braucht kein fertiges Werkzeug. Für jede geänderte Methode listet ein Agent im Review die dokumentierten Verhaltensweisen auf und ordnet ihnen die Tests zu, die sie prüfen. Die Lücken sieht sich ein Mensch an. Bei einem Diff ist die Liste so kurz, dass das auch wirklich geschieht. **Erst Tests gezielt auswählen, dann CI-Kapazität kaufen.** Bevor ein Team mehr Rechenzeit kauft, sollte es vorhersagen lassen, welche Tests eine Änderung überhaupt betrifft. Facebook hat das mit einem trainierten Modell vorgemacht: Es wählt deutlich weniger Tests aus als eine Auswahl nach Build-Abhängigkeiten und meldet trotzdem fast jede fehlerhafte Änderung. Die Maschinenkosten fürs Testen halbierten sich ([Einzelheiten im Anhang](#testauswahl-bei-facebook)). **Gelöscht wird regelmäßig.** In den untersuchten Java-Projekten löscht kaum ein Commit einen Test, und wenn Tests verschwinden, dann fast immer zusammen mit dem Produktionscode, den sie geprüft haben. Auch Googles Löschwerkzeug entfernt Tests nur zusammen mit totem Code ([Belege im Anhang](#wie-selten-projekte-tests-entfernen)). Ein Team, das bestandene Tests für noch genutzten Code planmäßig löscht, haben wir nicht gefunden. Genau das empfehlen wir, mit dem Verhalten als Maßstab, denn wer nach Abdeckung löscht, verliert echte Fehlerfunde ([siehe Anhang](#abdeckung-und-mutationsbewertung)). Ein Test, der als einziger ein Verhalten prüft, bleibt. Einer, der zum dritten Mal dasselbe prüft oder ein Verhalten, das es nicht mehr geben soll, kommt weg. Eine feste Stunde im Monat, in der das Team gezielt Tests entfernt, bringt mehr als drei Dashboards. ## Unser Versuch: Tests an Geschäftszielen messen Paul und Holmes leiten Verhalten von unten ab, aus der Dokumentation einzelner Methoden, also auf der Ebene, auf der Code entsteht. Was zählt, entscheidet das Unternehmen weiter oben, bei seinen Zielen. Dort setzt Impact Mapping an: vom Ziel über die Akteure zu den Wirkungen, die bei ihnen eintreten sollen. Wir probieren derzeit in Projekten aus, ob sich daraus ableiten lässt, was eine Testsuite prüfen muss. Konkret leiten wir aus der Impact Map die Verhaltensweisen ab, an denen ein Ziel hängt, gewichten sie nach ihrer Bedeutung fürs Geschäft und prüfen, welche davon ein Test abdeckt. Ein Test, der sich keiner Wirkung auf der Karte zuordnen lässt, wird zum Kandidaten fürs Löschen. Wir haben keine veröffentlichte Arbeit gefunden, die eine Impact Map als Maßstab nutzt, um die Güte einer Testsuite zu messen oder über Löschungen zu entscheiden. Am nächsten kommen zwei Arbeiten ([Quellen im Anhang](#impact-mapping-in-der-literatur)): Gojko Adzic und seine Mitautoren nennen die Wirkungen auf der Karte einen guten Ausgangspunkt, um beim explorativen Testen darüber zu sprechen, was Nutzer mit einem System tun können, und ein anderes Verfahren streicht redundante Tests, ohne dass eine Anforderung ungeprüft bleibt. Unser Versuch nimmt Adzics Hinweis auf und trägt ihn vom explorativen Testen in die Pflege der Suite. Ergebnisse haben wir noch keine. Herausfinden wollen wir zweierlei: ob sich Tests mit vertretbarem Aufwand einzelnen Wirkungen zuordnen lassen, und ob eine Rangfolge nach Geschäftsgewicht zu anderen Entscheidungen führt als die Abdeckung. Aufgeben werden wir die Idee, wenn die Zuordnung mehr Arbeit kostet, als sie beim Priorisieren und Löschen spart, oder wenn am Ende dieselben Tests oben stehen wie ohne Karte. Sobald es etwas zu berichten gibt, schreiben wir darüber einen eigenen Artikel mit Messwerten. ## Warum uns das Thema selbst betrifft Wir bauen mit Agenten in Kundensystemen, also wachsen die Suiten auch bei uns. Unsere Antwort darauf fällt bescheiden aus: Wir messen die Verhaltenslücke dort, wo wir Code ändern, und löschen Tests gezielt. Beide Gewohnheiten gehören auch in jedes [100-Tage-Engagement zur Modernisierung der Entwicklungsorganisation](/de/services/dev-org-modernization/). Ein grüner Balken ist nur so viel wert wie das Verhalten, das die Tests dahinter wirklich prüfen. ## Anhang: Zahlen und Quellen Hier stehen die Belege zu den Abschnitten oben: Zahlen, wörtliche Zitate, der Aufbau der Studien, ihre Einschränkungen und die Quellenangaben. ### Change Amplification John Ousterhout, *A Philosophy of Software Design*, 2. Auflage, Kapitel 2. Ousterhout beschreibt Change Amplification für Code im Allgemeinen. Die Übertragung auf Testcode stammt von uns. ### Wachstum der Testsuiten - **Tests vor den Agenten:** In den meisten von neun ausgereiften C/C++-Projekten kamen mehr Testzeilen hinzu als ausführbare Zeilen (Bailey, Cadar, ICST 2025). - **Tests von Agenten:** Der Anteil agentischer Pull Requests, die mindestens eine Testdatei anfassen, stieg von Januar bis Juli 2025 von 31 auf 52 Prozent (Haque, Ingale, Csallner, MSR '26). Gezählt sind dabei Pull Requests, keine Zeilen. - **CI-Last:** CircleCI zählte im September 2025 59 Prozent mehr tägliche Workflow-Läufe als ein Jahr zuvor, und im März 2026 verbrauchte das mittlere Team dort 13 Prozent mehr CI-Credits pro ausgelieferter Änderung. Das sind Angaben eines Anbieters, und von ihm stammt auch die Deutung, KI sei die Ursache. ### Die Studie von Paul und Holmes Partha Protim Paul, Reid Holmes: „Beyond Coverage and Kill Scores“, [arXiv:2606.10417](https://arxiv.org/abs/2606.10417), Preprint vom Juni 2026, noch nicht begutachtet. **Aufbau.** Der Forschungsprototyp BFinder liest Dokumentation und Quelltext einer Methode, leitet daraus die einzelnen Verhaltensweisen ab, die sie zeigen soll, und ordnet jeder davon die vorhandenen Tests zu. Was danach ohne Test dasteht, nennen die Autoren die Verhaltenslücke. Untersucht haben sie zehn Java-Bibliotheken aus Defects4J mit 8.922 dokumentierten Methoden. Daraus gewann BFinder 20.729 Verhaltensweisen, von denen sich bei der Nachprüfung 93,1 Prozent als korrekt erwiesen. **Entwicklersuiten.** Mindestens 17,5 Prozent der erkannten Verhaltensweisen prüft kein einziger Test. Je nach Projekt sind es 6,6 Prozent (commons-cli) bis 29,3 Prozent (jfreechart). **Warum die Zahl eine Untergrenze ist.** Die Autoren haben die gefundenen Lücken bereits mit dem geschätzten Anteil echter Treffer (71,3 Prozent) heruntergerechnet, und Lücken, die BFinder gar nicht erst erkennt, fehlen in der Zählung. Außerdem gilt die Zahl nur für dokumentierte Methoden. **Generierte Suiten.** Für vier der Bibliotheken (commons-cli, -codec, -compress und -jxpath) liegen Suiten von zwei Generatoren vor: von EvoSuite, einem klassischen suchbasierten Werkzeug, und von ASTER, das Tests mit Sprachmodellen erzeugt. EvoSuite lässt mindestens 20,6 Prozent der Verhaltensweisen ungeprüft, ASTER mindestens 27,1 Prozent. Die Entwicklersuiten derselben vier Projekte liegen zwischen 6,6 und 20,2 Prozent. **Zeilenabdeckung.** Methoden mit 91 bis 100 Prozent Zeilenabdeckung machen bei EvoSuite 89,7 Prozent aus, bei ASTER 81,2 Prozent und bei den Entwicklersuiten über alle zehn Projekte 92,3 Prozent. [Figure: Alle drei Suiten erreichen hohe Zeilenabdeckung: Bei 92,3 (Entwickler), 89,7 (EvoSuite) und 81,2 Prozent (ASTER) der Methoden liegt sie zwischen 91 und 100 Prozent. Ungeprüft bleiben dabei mindestens 17,5 Prozent der erwarteten Verhaltensweisen in den Entwicklersuiten von zehn Java-Bibliotheken, mindestens 20,6 Prozent bei EvoSuite und mindestens 27,1 Prozent bei ASTER. Die beiden generierten Suiten gibt es nur für vier dieser Bibliotheken; dort liegen die Entwicklersuiten zwischen 6,6 und 20,2 Prozent.] ### Abdeckung und Mutationsbewertung - **Zeilenabdeckung:** Von den Methoden mit vollständiger Zeilenabdeckung haben 38,2 Prozent mindestens ein ungeprüftes Verhalten (Paul, Holmes, siehe oben). - **Mutationsbewertung:** Von den Methoden, bei denen die Entwicklersuiten jede einzelne Mutation erkennen, haben 29,6 Prozent noch eine Lücke (Paul, Holmes). - **Minimierung nach Abdeckung:** Bei Noemmer und Haas (SWQD 2020, [DOI 10.1007/978-3-030-35510-4_4](https://doi.org/10.1007/978-3-030-35510-4_4)) strich eine Minimierung nach Anweisungsabdeckung in sieben Java-Projekten 50 bis 93 Prozent der Tests und kostete 3,5 bis 21 Prozent der relativen Mutationsbewertung, im Schnitt etwa 12,5 Prozent. - **Echte Fehlschläge:** Shi und Kollegen (ISSTA 2018, [DOI 10.1145/3213846.3213875](https://doi.org/10.1145/3213846.3213875)) haben 1.478 fehlgeschlagene Builds aus 32 Projekten ausgewertet. Tests, die eine Reduktion nach Abdeckung oder Mutanten für überflüssig erklärt hatte, deckten dort weiterhin echte Fehler auf; ohne sie gingen 9,5 bis 52,2 Prozent der Fehlererkennung verloren. ### Metas TestGen-LLM Alshahwan et al., [arXiv:2402.09171](https://arxiv.org/abs/2402.09171), FSE 2024. **Die drei Filter im Einzelnen.** Der Kandidat muss sich bauen lassen. Er muss beim ersten Lauf bestehen und darf in fünf Ausführungen kein einziges Mal scheitern. Und er muss die Zeilenabdeckung erhöhen. Erst danach sieht ihn ein Mensch. **Ergebnis.** In Metas Auswertung über 86 Testklassen von Instagram Reels und Stories hatten 75 Prozent der Klassen mindestens einen generierten Test, der sich bauen ließ, 57 Prozent einen, der zuverlässig bestand, und nur 25 Prozent einen, der zusätzlich die Zeilenabdeckung erhöhte. ### Der Einwand von Simon Willison Simon Willison, „First run the tests“, in *Agentic Engineering Patterns*. Dort heißt es, die alten Gründe gegen das Testen „no longer hold when an agent can knock them into shape in just a few minutes“. ### Testauswahl bei Facebook Machalica et al., [arXiv:1810.05286](https://arxiv.org/abs/1810.05286), 2019. Das trainierte Modell wählt weniger als ein Drittel der Tests aus, die eine Auswahl nach Build-Abhängigkeiten laufen ließe, und meldet trotzdem über 99,9 Prozent der fehlerhaften Änderungen. Die Maschinenkosten fürs Testen halbierten sich. Das sind Angaben von Facebook selbst, und hinter der Auswahl liegt noch eine spätere Prüfstufe als Sicherheitsnetz. ### Wie selten Projekte Tests entfernen - **Gelöschte Tests:** In sieben untersuchten Java-Projekten löschen gerade einmal 0,47 Prozent aller Commits überhaupt Tests. In den sechs Projekten, die auch Produktionscode enthalten, verschwanden 91,4 Prozent der gelöschten Tests, weil ihr Produktionscode wegfiel (Bhatta, Kendemah, Jha, MSR 2025). - **Google:** Das Löschwerkzeug [Sensenmann](https://testing.googleblog.com/2023/04/sensenmann-code-deletion-at-scale.html) entfernt nur toten Code; Tests verschwinden dort zusammen mit der Bibliothek, die sie prüfen. ### Impact Mapping in der Literatur - Gojko Adzic, David Evans, Tom Roden: *Fifty Quick Ideas to Improve Your Tests*. Die Autoren nennen die dritte Ebene der Impact Map, die Wirkungen bei den Akteuren, einen guten Ausgangspunkt, um darüber zu sprechen, was Nutzer mit einem System tun können, allerdings fürs explorative Testen. - RTM (Pan, Niu, Briand, Hu, TOSEM 2026) streicht redundante Tests so, dass jede Anforderung abgedeckt bleibt. --- # Scattered Minds - URL: https://100days.de/en/insights/scattered-minds/ - Language: English - Published: 2026-10-08 - Audience: CTOs / engineering leaders - Summary: Eight agents open, a glance every 45 seconds, mail in the gaps. What the research says about supervising AI agents in parallel and where we draw the limit. ## A Morning With Eight Agents It is mid-morning and eight agent sessions are open. One is refactoring a payment module, one is writing a migration, one is chasing a flaky test and the rest are somewhere in between. Every forty-five seconds or so you glance at one of them, read an intermediate result, decide whether it is on track and type the next instruction. Then you check mail until the next one wants you. Plenty of people skip the mail and start a ninth agent instead. By lunch you have shipped more than on a normal day, and your head is full: it holds eight half-finished states, none of which you wrote and all of which you answer for, and there is no room left for a ninth thought. Some people love this. It feels like a pleasant, slightly jittery flow, the closest thing to running a whole team from one chair. That reaction is real, and it stays real through everything below. The question is what this mode costs and where the limit sits. ## What to Call It We call it round-robin supervision. The agents work in parallel and you visit them one after another, the way a scheduler hands out time slices. Every visit lands on something half-finished, and your job there is to judge it. You have to understand work you didn't do, and you answer for code you didn't write. The underlying problem is old. Human factors research has studied people supervising automated systems for decades and calls it supervisory control. Robotics even measured how many robots one person can run at once, and the answer depended on how autonomous the robots were and how hard the task was ([numbers in the appendix](#supervisory-control-and-fan-out)). Agents aren't robots, but the principle carries over: how many you can handle depends on how long each one runs without you. When an agent does need you, it usually wants a design decision, and that weighs more than a waypoint. A study of how developers supervise coding agents found this demand in their online discussions of the practice: they have to keep enough understanding of work they did not write themselves ([study in the appendix](#supervisory-control-and-fan-out)). ## Why It Sets Some of Us Free For me, this way of working is a release. For the first time I can work several lines of thought through properly, side by side. Results arrive fast. The current state of the art turns up by itself, and concepts get questioned and corrected along the way. The mechanism is easy to name. I let go of the details, and the time it takes to test a creative idea in practice has collapsed. An idea gets tried almost as soon as I have it. That is what makes the work motivating for me. This is not how everyone experiences it. The costs in the rest of this piece are real, and so is this. ## What a Survey of AI Users Found The most direct evidence so far comes from a Boston Consulting Group survey of US workers at large companies, published in Harvard Business Review in March 2026. The authors call the effect brain fry, mental fatigue from excessive use or oversight of AI tools, beyond what a person can cognitively handle, which participants described as a fog with trouble focusing and slower decisions. Engineering was among the more affected functions, and overseeing AI turned out to be the most taxing kind of use. People who reported brain fry also reported more decision fatigue and more frequent errors, and more of them intended to leave their job ([all figures in the appendix](#the-bcg-survey-on-brain-fry)). The finding that matters most here concerns the number of AI tools used at the same time. Self-rated productivity rose from one tool to two, rose less with a third and dipped after three. That curve compares different people at one moment, so it shows where the association turns and follows nobody who adds a fourth tool. Productivity and brain fry were both self-reported, and the lead authors work for a consultancy that sells AI transformation. In their data, AI use did not seem to predict increased burnout, which they keep apart from brain fry ([caveats and chart](#the-bcg-survey-on-brain-fry)). ## Why Decisions Queue Up Three findings from cognitive research explain why the curve turns. The first is a bottleneck. In a brain-imaging study of people handling two overlapping simple tasks, early sensory processing ran largely in parallel, while the step where a response gets selected queued up and ran one task after the other ([study in the appendix](#the-cognitive-bottleneck)). The transfer to agents is ours: you can see eight dashboards at once and still decide about them one after another. The second is residue. In experiments on attention residue, people struggled to pull their attention away from an unfinished task, and their performance on the next one suffered ([study](#the-cognitive-bottleneck)). An agent thread is unfinished every time you leave it. The third is the clock. Information workers in one field study stayed on one screen for well under a minute. In a smaller, earlier study, people who came back to interrupted work the same day took on average more than twenty minutes to return to it, with other projects in between ([numbers](#the-cognitive-bottleneck)). Set a polling cadence of thirty to sixty seconds, our own observation, next to that. It is far shorter than the time people were seen to need before returning to interrupted work, so a thread almost never gets picked up with a clean slate. We read this as a state that never settles, each glance adding residue before the last has cleared. We know of no study that has measured how long residue takes to fade, so that last step is our inference. ## How Supervisors Lose the Picture The slower cost takes longer to show. In 1983 Lisanne Bainbridge described the ironies of automation in industrial control rooms. Operators keep the tasks designers could not automate and take over in abnormal situations, exactly when skills that fade without practice are needed most. By taking away the easy parts of the job, automation can make the difficult parts harder ([quotes in the appendix](#automation-and-situation-awareness)). The parallel to agents is ours. Endsley and Kiris tested this in a 1995 experiment. Operators who no longer made the decisions understood the situation less well and took longer to decide once the automation failed, although their screens showed the same information. That is the agent operator's position: you step in when the agent fails, the worst moment, holding the weakest picture of what is going on. Tooling fixes part of it. In a Microsoft Research study, a view that tracks what each parallel coding agent is doing raised ticket throughput and made tracking feel less effortful, while the participants' sense of control did not rise significantly ([numbers](#automation-and-situation-awareness)). The study is a preprint by the tool's own authors. Writing state down relieves working memory; the picture itself has to come from somewhere else. Review follows the same slope. In a survey of knowledge workers, people with more confidence in the AI for a given task reported less critical thinking. That is a snapshot; a decline over weeks is our inference. Smelling a wrong intermediate step is a skill, and unused skills fade. ## What the Research Does Not Show We know of no study that has measured this working pattern with validated clinical instruments or followed people over months while they add agents. Nor do we know of a published capacity number for coding agents; the robotics fan-out figures are an analogy at best. Individual differences are large. In a US Army simulation with unreliable automation, operators who rated their attentional control high suffered more from false alarms, and those who rated it low suffered more from missed detections. Which failure hurts depends on who is watching. In an interview study of developers with ADHD, one participant described concurrent agents helping them keep momentum, and others found manually auditing large volumes of AI code exhausting ([both studies](#individual-differences-and-counter-positions)). The strongest counter-position comes from a practitioner. Between March and June, Rémy Duthu of Mergify went from a cap of two agents to sometimes a dozen at once and felt less frazzled, because agent autonomy plus a status view turned babysitting into a queue he drained from the top. In the same post he concedes the core point: two interrupts at the same time cost what they always did, and his flood of pull requests made review more expensive for his teammates ([his post](#individual-differences-and-counter-positions)). That moves the limit to a better place. What counts is how many threads need your judgement at the same moment. Others will call this a moral panic, the complaint every new medium draws. The argument here rests on the serial bottleneck alone, which even Steven Pinker granted when he rebutted such panics ([sources](#individual-differences-and-counter-positions)). ## Where We Draw the Limit What follows is our recommendation, drawn from the shape of the evidence. Nobody has measured it, and nobody yet knows exactly where the curve turns for coding agents. Keep two to three threads that need real judgement. Four to eight are workable when most of them alert you on exceptions and only one or two sit in active review at a time. Write state down: what each thread is doing, what it waits for, what done looks like. That relieves your head. The picture comes back through the last habit on this list. Batch your reviews. Polling every forty-five seconds is a habit, and tooling can remove it. Look at agents when a batch is ready, on your schedule. Leave the gap empty. The minute between two decisions is the closest thing to a pause your head gets, and mail fills it with one more unfinished thing. And pull one thread all the way down to the implementation on a regular basis. Read the code, run it, change something by hand. Otherwise you turn into Bainbridge's operator, the one who intervenes only when he knows least. ## Why We Track This We run this pattern every day, in client engagements and in our own work. We have hit the wall ourselves: the afternoon where every glance costs more than the one before and the reviews quietly get softer. We needed a name for that state before we could set a limit on it. ## Appendix: Numbers and Sources ### Supervisory control and fan-out - **Supervisory control.** Human factors research calls the supervision of automated systems supervisory control, a field Thomas Sheridan did much to shape. - **Robot fan-out.** Fan-out is the number of robots one person can effectively run at once (Olsen & Goodrich, 2003). With simulated robots it ranged from about one to nine, depending on how autonomous the robots were and how hard the task was (Olsen & Wood, CHI 2004). - **Supervising coding agents.** Park et al. watched 19 experienced developers work with coding agents, built a model of supervision from what they saw and applied it to 102 Reddit threads in which developers discuss their practice. In those threads they found "a supervisory demand to maintain enough understanding of work they had not written themselves" ([arXiv:2609.24234](https://arxiv.org/abs/2609.24234)). The ParallelPilot study from Microsoft Research (see [Automation and situation awareness](#automation-and-situation-awareness)) also frames parallel AI coding as supervisory control. ### The BCG survey on brain fry Bedard et al., ["When Using AI Leads to 'Brain Fry'"](https://hbr.org/2026/03/when-using-ai-leads-to-brain-fry), Harvard Business Review, March 2026: a Boston Consulting Group survey of 1,488 full-time US-based workers at large companies. - **Definition.** The authors call the effect "AI brain fry": "mental fatigue from excessive use or oversight of AI tools beyond one's cognitive capacity." Participants described "a 'buzzing' feeling or a mental fog with difficulty focusing, slower decision-making, and headaches." - **Prevalence.** Of the respondents who use AI at work, 14% reported it, from 6% in legal roles to 26% in marketing, with engineering among the more affected functions. - **Oversight.** Oversight was the most taxing kind of AI use: high oversight went with 14% more mental effort, 12% more mental fatigue and 19% more information overload than low oversight. - **Decisions, errors, quitting.** People reporting brain fry also reported 33% more decision fatigue and scored 11% and 39% higher on minor and major error frequency. Of them, 34% intended to leave their job, against 25% of the rest. - **Number of tools.** Self-rated productivity rose from one AI tool used at the same time to two, rose less with a third, and then: "After three tools, though, productivity scores dipped." [Figure: Self-rated productivity against the number of AI tools used at the same time, in a BCG survey of 1,488 US workers published in HBR in 2026: a clear rise from one tool to two, a smaller rise with a third, a dip after three. The article text gives no values, so the curve shows shape only. The survey is cross-sectional and compares different people at one moment, so it shows where the association turns; what happens when one person adds a tool remains open.] - **Caveats.** A cross-sectional survey compares different people at one moment: it shows association only and follows nobody who adds a fourth tool. Productivity is self-reported, brain fry was one question about whether people had ever felt it, and the lead authors work for a consultancy that sells AI transformation. We have found no longitudinal or experimental study of this exact pattern. - **Burnout.** The authors keep brain fry apart from burnout: in their data, AI use "didn't seem to predict increased burnout." - **A line they quote.** One line they quote fits our reader closely. Francesco Bonacci, posting on X, described ending each day exhausted, "not from the work itself, but from the managing of the work." ### The cognitive bottleneck - **Serial response selection.** Yue, Newton and Marois used ultrafast 7-Tesla fMRI on 26 young adults handling two overlapping simple tasks ([Nature Communications, 2025](https://doi.org/10.1038/s41467-025-58228-0)). Early sensory processing unfolded "largely in parallel." The task-specific work in the fronto-parietal multiple-demand network, where a response gets selected, queued up and ran serially. The transfer to agents is ours. - **A practitioner's version.** Addy Osmani said it plainly [in April 2026](https://addyosmani.com/blog/cognitive-parallel-agents/): "Your cognitive bandwidth doesn't parallelize." - **Attention residue.** Sophie Leroy showed in two experiments that people struggle to pull their attention away from an unfinished task, and that their performance on the next one suffers ([OBHDP, 2009](https://doi.org/10.1016/j.obhdp.2009.04.002)). Only finishing the first task under time pressure helped people let go. Leroy did not measure how long residue takes to fade, and we know of no study that has. - **Time on one screen.** Gloria Mark and colleagues found information workers staying on one screen for a median of 40 seconds ([CHI 2016](https://doi.org/10.1145/2858036.2858202)). - **Returning to interrupted work.** In an earlier study, people who came back to interrupted work the same day took on average 25 minutes 26 seconds to return to it, with 2.26 other projects in between (Mark, Gonzalez & Harris, CHI 2005; 24 people at one company, wide spread). - **Polling cadence.** The cadence of thirty to sixty seconds is our own observation, and the step from these findings to a state that never settles is our inference. ### Automation and situation awareness - **Ironies of automation.** In 1983 Lisanne Bainbridge wrote "Ironies of Automation" about industrial control rooms ([Automatica](https://doi.org/10.1016/0005-1098(83)90046-8)). Automation, she argued, "may expand rather than eliminate problems with the human operator." Operators keep the tasks designers could not automate and take over in abnormal situations, exactly when skills that fade without practice are needed most. "By taking away the easy parts of his task, automation can make the difficult parts of the human operator's task more difficult." The parallel to agents is ours. - **Out of the loop.** Endsley and Kiris tested this in 1995 ([Human Factors](https://doi.org/10.1518/001872095779064555)). They automated a navigation task at five levels of control. Operators who no longer made the decisions understood the situation less well and took longer to decide once the automation failed, although their screens showed the same information. The authors trace this to the shift from active to passive processing. - **ParallelPilot.** In the ParallelPilot study from Microsoft Research, 16 participants used a coordination and monitoring view for parallel coding agents (Long et al., [arXiv:2609.33113](https://arxiv.org/abs/2609.33113)). Ticket throughput rose 63%, from 0.272 to 0.445 tickets per minute, and peak concurrent agents went up by about one (2.31 to 3.25). Self-rated tracking effort fell from 4.63 to 2.75 on a seven-point scale. Perceived control and perceived intervention success did not rise significantly; the authors report that the bookkeeping the tool removed had "reinforced their sense of control." It is a preprint by the prototype's own authors, tested on experienced developers who were mostly new to running agents in parallel. - **Confidence and critical thinking.** In a survey of 319 knowledge workers, higher confidence in the AI for a given task went with less self-reported critical thinking, and higher confidence in one's own ability went with more (Lee et al., [CHI 2025](https://doi.org/10.1145/3706598.3713778)). That is a snapshot; a decline over weeks is our inference. ### Individual differences and counter-positions - **Attentional control.** In a US Army simulation with unreliable automation, operators who rated their attentional control high suffered more from false alarms, and those who rated it low suffered more from missed detections (Chen & Terrence, [Ergonomics, 2009](https://doi.org/10.1080/00140130802680773)). - **Developers with ADHD.** In a 2026 interview study of 14 developers with ADHD (formally diagnosed or self-identified), one participant described using concurrent AI agents to maintain momentum. Participants also described manually auditing large volumes of AI code in sensitive or high-stakes production settings as increasing cognitive exhaustion and anxiety over hidden bugs (Pimenova et al., [arXiv:2609.21254](https://arxiv.org/abs/2609.21254)). - **A practitioner's counter-position.** Rémy Duthu of Mergify [capped himself at two agents in March and by June ran](https://mergify.com/blog/how-agents-work-with-parallel-agents) "sometimes a dozen at once," feeling "less frazzled," because autonomy plus a status view "turn babysitting into a queue I drain top-down." He concedes the core in the same post: "Two simultaneous interrupts cost exactly what they always did," and code review got worse: his flood of PRs made review more expensive for his teammates. - **Moral panic.** In 2020 Amy Orben traced the recurring cycle of panics that every new medium draws. Steven Pinker, in his 2010 rebuttal of such panics, granted the serial bottleneck: "Genuine multitasking, too, has been exposed as a myth." --- # The Tests Nobody Deletes - URL: https://100days.de/en/insights/tests-nobody-deletes/ - Language: English - Published: 2026-10-08 - Audience: CTOs / engineering leaders - Summary: Agents made tests nearly free, and suites grow faster than anyone reads them. A June 2026 study shows generated suites leave more expected behaviour untested than human ones, while coverage stays high. ## The Afternoon the Test Backlog Vanished You know the ticket. "Add tests for the billing module," two years old. One afternoon you hand it to Claude. Twenty minutes later there are forty tests, all green, and two of them hit an edge case you had forgotten existed. The relief is real. For a lot of teams this was the first time testing felt cheap, and that was good news. Now picture the same repository a few months later. The suite is several times its old size and nobody has read most of it. CI still goes green, but green means less than it did when every test had an author who knew why it was there. ## Tests Are Code, and Code Has Weight A test that asserts behaviour is bound to that behaviour. Change the behaviour and the test has to change with it. John Ousterhout has a name for the general problem: change amplification, where a simple change forces edits in many different places. He meant code in general. We apply it to tests, and every test generated in volume adds one more place a simple change has to touch. Suites outgrowing their code is older than agents. Agents speed it up: by mid-2025, more than half of agent pull requests touched at least one test file ([sources](#tests-as-code)). The best objection comes from Simon Willison. When an agent can fix a broken test in a few minutes, he argues, the old reasons for skipping tests no longer hold. He is right about the rewriting. Deciding whether the rewritten test still checks the right behaviour is the expensive part, and that decision stays with a human. Most test failures that aren't flaky still earn their keep, because they usually point at real faults. The cost we mean grows with unreviewed volume, and in our client work it shows up as slower suites. Public data measures only the volume, and that grew sharply within a year ([sources](#tests-as-code)). We argued [elsewhere](/en/insights/end-of-software/) that code is turning into a throwaway artifact. Tests are the part nobody throws away. ## Measuring What Nobody Tests In June 2026 two researchers, Partha Protim Paul and Reid Holmes, asked a plain question. Of everything a library's documentation promises, how much does no test check at all? Their tool reads the promised behaviours out of each method's documentation and looks for a test that validates each one. They ran it on ten open-source Java libraries. The answer: in the suites the libraries' own developers wrote, at least one in six documented behaviours has no test checking it. Some projects do much better than others. Even the best one has a gap, with line coverage and mutation score close to perfect. Then comes the comparison that matters to anyone using agents. On four of the libraries the researchers also measured suites written by two automatic test generators. Those suites left more behaviour untested than the developers' suites did. By the usual metric they still looked healthy, with most of their methods at high line coverage. The study is a preprint and not yet peer reviewed, and its gap figures are lower bounds. The numbers and a chart are in the [appendix](#the-behavioural-gap-study). This is no proof that agents write bad tests. It shows that generated volume carries a larger behavioural gap than its coverage suggests, and a dashboard can't tell the difference. ## Why Coverage and Mutation Scores Miss It Line coverage proves that a line ran. It says nothing about whether anyone checked the result. In the developer-written suites Paul and Holmes studied, more than a third of the methods with full line coverage still had at least one untested behaviour. Mutation testing is the stronger instrument, and it still misses a lot. Even where a suite caught every artificial bug the tool planted in a method, that method often still had untested behaviour. The generated suites did worse here too. A high kill score hints at good behavioural coverage, but only weakly ([numbers](#coverage-and-mutation-score)). The same blindness hits the usual fix for a bloated suite: shrink it by coverage. In one study, dropping every test that looked redundant by coverage removed a large part of each suite and measurably weakened it. A second study looked at real builds. The tests marked redundant still caught real failures, and the slimmed suites missed them. Coverage is the wrong ruler for deleting, too ([studies](#coverage-and-mutation-score)). ## How Meta Filters Generated Tests Meta's TestGen-LLM doesn't trust its own output. Every generated test passes three filters in order. It has to build. It has to pass reliably on repeated runs, or it gets thrown out as flaky. And it has to cover lines the existing suite didn't. Whatever survives goes to a human reviewer. The filters are strict. For three test classes in four, not a single generated test made it through all three filters ([details](#the-meta-gate)). The paper used older models, and its last filter checks only line coverage, a weak gate as shown above. The structure still transfers. A separate benchmark points the same way. One model wrote far more tests than another, reached barely more coverage and added less new ground, so the extra tests bought little ([details](#the-meta-gate)). The gate is what Meta built, and it is the part worth copying. The generator is the easy bit. ## What Teams Can Change Now All four steps run on what you already have ([sources](#selection-and-deletion)). 1. **Gate generated tests.** Copy Meta's three filters as the floor: builds, passes repeated runs, adds coverage. Then add one of your own: every new test names the behaviour it checks, and a reviewer confirms it. 2. **Measure the behavioural gap on the diff.** BFinder, the tool from the study, is a research prototype, but the method transfers. For each method a change touches, list the behaviours its documentation promises and mark which ones a test asserts. That is the review question coverage can't answer. 3. **Run predictive selection before buying CI capacity.** Facebook trained a model to pick the tests a change actually needs. It ran a fraction of the tests, still caught nearly every faulty change and halved the machine cost of testing. That is Facebook's own report, but the principle scales down. 4. **Delete on a schedule.** Teams rarely delete tests, and when they do, it is mostly because the production code went away. Google and Microsoft have tools that remove dead code or skip test runs; we found nobody who deletes passing tests of live code on a schedule. Delete by behaviour, since coverage redundancy is the wrong criterion, as shown above. A test that checks no behaviour anyone can name is a candidate. One deliberate deletion habit beats three dashboards. ## Our Open Bet: Start From the Goals BFinder derives behaviours bottom-up from method documentation, where code gets written. Impact mapping works top-down, from a business goal to the actors who influence it and the impacts needed from them. That is where a company decides what matters. An inventory built from the top would let a team rank behaviours by business weight and ask which of them any test covers. Others have come close. Gojko Adzic, David Evans and Tom Roden call the actor-impact level of an impact map a good starting point for talking about capabilities in exploratory testing. A 2026 approach called RTM deletes redundant tests while keeping every requirement covered. We found no published work that uses an impact map as the inventory for measuring test adequacy or deciding deletion ([sources](#prior-work-on-the-open-bet)). We are trying this in client engagements now. We build the impact map with the people who own the goal and attach each test in a changed area to an impact. Impacts with no test are gaps, ranked by business weight. Tests with no impact go on the deletion list. We want to learn two things: whether the map is cheap enough to keep current, and whether ranking by business weight changes which gaps a team closes first. If keeping the map in sync costs more review time than it saves, or if the heavy impacts turn out to be the ones already well tested, we drop the idea. We have nothing to report yet. When we do, it gets its own article, with measurements. ## Why We Track This We build with agents in client systems, so the growing suite is ours too. Test counts are easy to report and say very little. In a 100-day engagement we report covered behaviours and deleted tests, so the team that owns the code after we leave inherits a suite it can read. Both habits belong in our [dev-org modernization](/en/services/dev-org-modernization/) work. The honest claim is narrow: we measure this and we delete, and we haven't solved it. ## Appendix: Numbers and Sources ### Tests as code - **Change amplification.** John Ousterhout, *A Philosophy of Software Design*, 2nd edition, chapter 2: "a seemingly simple change requires code modifications in many different places". He wrote it about code in general; applying it to tests is our extension. - **Suite growth before agents.** Bailey and Cadar (ICST 2025) found suites outgrowing code in most of nine mature C/C++ projects. - **Agent pull requests.** Haque, Ingale and Csallner (MSR '26) report that the share of agent pull requests touching at least one test file rose from 31% to 52% between January and July 2025. - **The objection.** Simon Willison, "First run the tests", part of his *Agentic Engineering Patterns*: the old reasons for skipping tests "no longer hold when an agent can knock them into shape in just a few minutes." - **Failures that find faults.** Labuschagne, Inozemtseva and Holmes (ESEC/FSE 2017) found that 74.1% of deterministic test failures across 61 Travis projects pointed at real faults. - **CI volume.** CircleCI's vendor report "The 2026 State of Software Delivery" counts 59% more daily workflow runs year on year, while the median run got shorter. ### The behavioural-gap study Partha Protim Paul and Reid Holmes, "Beyond Coverage and Kill Scores: Empirically Measuring Test Suite Behavioural Gaps", preprint, June 2026 ([arXiv:2606.10417](https://arxiv.org/abs/2606.10417), not yet peer reviewed). Their proof-of-concept tool, BFinder, extracts the behaviours a method's documentation promises, maps them to existing tests and flags every behaviour no test validates. - **Data set.** Ten open-source Java libraries from Defects4J, among them commons-lang, gson and jsoup: 8,922 documented methods, 20,729 extracted behaviours, 93.1% extraction precision. - **Developer-written suites.** At least 17.5% of detected behaviours are validated by no test. It is a lower bound, counted over the behaviour of documented methods only. Per project the gap runs from 6.6% (commons-cli) to 29.3% (jfreechart). commons-cli has 98.2% line coverage and a 93% mutation kill score, and it still has a gap. - **Generated suites.** Four of the projects (commons-cli, -codec, -compress and -jxpath) also have suites from two test generators, EvoSuite and ASTER. Those suites leave at least 20.6% (EvoSuite) and at least 27.1% (ASTER) of detected behaviours untested. The developer-written suites on the same four projects land between 6.6% and 20.2%. Structurally, the generated suites look fine: 89.7% of EvoSuite's analysed methods and 81.2% of ASTER's sit at 91 to 100% line coverage. [Figure: Line coverage stays high in all three suites, while the share of documented behaviour that no test checks rises from at least 17.5% to at least 27.1%. The developer bar covers ten Java libraries, the generated suites four of them; on those same four, developer-written suites leave 6.6% to 20.2% untested. All gap values are lower bounds.] ### Coverage and mutation score - **Line coverage.** In the developer-written suites Paul and Holmes studied, 38.2% of methods with 100% line coverage still had at least one untested behaviour. - **Mutation score.** Among methods where the developer suites killed every PIT mutant, 29.6% still contained an untested behaviour. For the generated suites the figure is 34% (EvoSuite) and 38% (ASTER). The correlation between kill score and behavioural coverage is ρ = 0.377. - **Minimising by coverage.** Noemmer and Haas ([SWQD 2020](https://doi.org/10.1007/978-3-030-35510-4_4)): statement-coverage-based minimisation on seven open-source Java projects removed 50 to 93% of tests and cost 3.5% to 21% of relative mutation score, about 12.5% on average. - **Real builds.** Shi, Gyori, Mahmood, Zhao and Marinov ([ISSTA 2018](https://doi.org/10.1145/3213846.3213875)): tests that coverage- or mutant-based reduction marked redundant still caught real failures, and failed-build detection dropped by 9.5% to 52.2% across 1,478 failed builds in 32 projects. ### The Meta gate - **Filter chain.** Meta's TestGen-LLM (Alshahwan et al., [arXiv:2402.09171](https://arxiv.org/abs/2402.09171), FSE 2024). A candidate first has to build. Then it has to pass on its first run and on each of five runs; a single failure gets it thrown out as flaky. Finally it has to raise line coverage, and whatever survives goes to a human reviewer. - **Results.** Across 86 test classes for Instagram Reels and Stories, 75% of classes got at least one generated test that built, 57% one that passed reliably, and only 25% one that also increased line coverage. The paper used Meta-internal models from 2023, and the last filter checks line coverage only. - **Unique contribution.** In the MultiFileTest benchmark (Wang et al., [arXiv:2502.06556](https://arxiv.org/abs/2502.06556)), every tested model showed low unique contribution, meaning coverage that no other generated test already provided. GPT-o1 wrote about 2.9 times as many tests as GPT-5-mini, reached slightly higher coverage and had less than half the unique contribution. That holds for this pair on a Python benchmark only. ### Selection and deletion - **Predictive test selection.** At Facebook, predictive test selection ran fewer than a third of the tests that build-dependency-based selection would have run, still reported over 99.9% of faulty changes and halved the machine cost of testing (Machalica et al., [arXiv:1810.05286](https://arxiv.org/abs/1810.05286), ICSE-SEIP 2019). That is Facebook's own report. - **How rarely tests get deleted.** Bhatta, Kendemah and Jha (MSR 2025) found that 0.47% of commits in seven Java projects delete tests, and in the six projects that also contain production code, 91.4% of deleted tests went because their production code went. - **Existing tools.** Google's [Sensenmann](https://testing.googleblog.com/2023/04/sensenmann-code-deletion-at-scale.html) removes dead code and Microsoft's THEO (Herzig et al., ICSE 2015) skips runs. - **Coverage redundancy as a criterion.** Shi et al. measured what it costs; see [Coverage and mutation score](#coverage-and-mutation-score). ### Prior work on the open bet - **Impact maps in testing.** Gojko Adzic, David Evans and Tom Roden call the actor-impact level of an impact map "a good starting point for discussing capabilities" in exploratory testing (*Fifty Quick Ideas to Improve Your Tests*). - **Requirement-preserving reduction.** RTM (Pan, Niu, Briand and Hu, TOSEM 2026) deletes redundant tests while keeping full requirement coverage. --- # Am Ende bleibt keine Software übrig - URL: https://100days.de/de/insights/end-of-software/ - Language: German - Published: 2026-09-01 - Audience: CTOs / engineering leaders - Summary: Eine Publikation vom Juni 2026 hält fest, dass Code zur Wegwerfware wird und das Ergebnis kein Programm mehr ist. Anschließend versichert sie, die Softwareentwicklung bleibe erhalten. Beides zusammen geht nicht. ## Software war immer nur ein Umweg Software gibt es, weil Maschinen nicht selbst herausfinden konnten, was zu tun ist. Jemand musste es vorher aufschreiben, vollständig und genau, in einer Form, die eine Maschine ausführen kann. Das Ergebnis dieses Aufschreibens nennen wir Software, und die Disziplin, die es betreibt, Softwareentwicklung. Damit ist auch schon alles über ihren Zweck gesagt. Niemand will Software besitzen. Man will, dass eine Rechnung rausgeht, ein Lager disponiert wird, ein Kunde eine Antwort bekommt. Der Umweg über das Aufschreiben war nötig, weil die Maschine die Aufgabe selbst nicht verstand. Eine Publikation vom Juni beschreibt ziemlich genau, was geschieht, wenn dieser Umweg entfällt. Die Konsequenz daraus zieht sie dann allerdings nicht. ## Was die Publikation sagt *Agentic Software: How AI Agents Are Restructuring the Software Paradigm* (arXiv:2606.05608) von Zhenfeng Cao legt eine These vor, ohne sie experimentell zu prüfen; das gehört vorweg gesagt. Ihre zentrale Unterscheidung halte ich trotzdem für das Nützlichste, was ich seit einem Jahr zu diesem Thema gelesen habe. Klassische Software hat eine **statische** Entscheidungslogik: Jede Regel schreibt ein Mensch, bevor das System die erste Eingabe sieht. Ein agentisches System erzeugt seine Entscheidungslogik dagegen **zur Laufzeit**, indem das Modell überlegt, Code schreibt, ihn ausführt, das Ergebnis liest und nachbessert. Den Code, der dabei entsteht, nennt Cao ein „transientes Artefakt, erzeugt und verworfen nach Bedarf". Der Agent schreibt sich also, was er für eine Aufgabe gerade braucht, führt es aus und wirft es weg. Stellt er später fest, dass es nicht mehr passt, schreibt er es neu. Gewartet werden muss davon nichts, weil nichts davon bleiben soll. Der wichtigste Satz der ganzen Publikation steht beiläufig in einer Vergleichstabelle. Dort führt Cao die Ausgabeeinheit beider Welten auf: für die klassische Entwicklung „funktionierende Software", für das agentische Arbeiten „gelieferte Ergebnisse". Er hält damit selbst fest, dass das Produkt aufhört, ein Programm zu sein. ## Wo die Publikation vor ihrer eigenen These zurückschreckt Wer das zu Ende denkt, landet an einer unbequemen Stelle. Wenn Code nur noch entsteht und vergeht, wie eine Aufgabe es gerade verlangt, dann gibt es kein Artefakt mehr, das jemand pflegt, versioniert, dokumentiert und übergibt. Softwareentwicklung als Tätigkeit hängt aber genau an diesem Artefakt. Ohne es bleibt von ihr nichts übrig, das man Beruf nennen könnte. Cao geht diesen Schritt nicht. Er nennt das Ganze „Agentic Engineering", betont ausdrücklich, es ersetze die Softwareentwicklung nicht, sondern erweitere sie, und schließt mit dem Satz, die alte Disziplin ende nicht, sie wachse zu etwas Größerem heran. In seiner eigenen Stufe IV löst sich der Unterschied zwischen Software und Agent dann vollständig auf. Beides zusammen geht nicht. Er hat die Prämisse aufgeschrieben, die seine Disziplin abschafft, und anschließend versichert, dass sie bleibt. Genau da liegt mein Widerspruch, und er wiegt schwerer als jede Frage nach Jahreszahlen. ## Die Zahl, um die falsch gestritten wird Als Gegenargument wird derzeit eine Messung herumgereicht, die auch in Caos Publikation vorkommt. EvoClaw (arXiv:2603.13428) prüft, worum die meisten Agenten-Benchmarks einen Bogen machen: **fortlaufende Softwareentwicklung**. Der Benchmark misst Arbeit über eine ganze Commit-Historie hinweg, bei der jede Änderung das System heil lassen muss und sich Fehler aufsummieren. Zwölf Spitzenmodelle, vier Agenten-Frameworks. Bei isolierten Aufgaben liegen die Werte über 80 Prozent. Im fortlaufenden Betrieb bei höchstens 38. [Figure: Gemessen wird die Pflege eines dauerhaften Artefakts. Fällt das Artefakt weg, prüft der Benchmark eine Tätigkeit, die es dann nicht mehr gibt.] Diese Zahl wird als Entwarnung gehandelt, und dafür taugt sie nicht. Sie misst, wie gut Agenten ein dauerhaftes Artefakt über die Zeit pflegen, also die zentrale Tätigkeit der alten Welt. Wenn Code entsteht und vergeht, wie die Aufgabe es verlangt, prüft der Benchmark eine Arbeit, die dann niemand mehr macht. Die ehrliche Antwort auf die Frage, wie viel von der Softwareentwicklung übrig bleibt, lautet deshalb: gar nichts. Sie war immer ein Hilfsmittel, um Arbeit zu organisieren und Aufgaben zu erledigen. Hilfsmittel verschwinden, sobald die Aufgabe direkt erledigt werden kann. ## Warum das schneller kommt, als die Publikation annimmt Cao gibt dem Übergang einen Zeitplan: Agententeams bis 2029, selbstlernende Systeme ab 2028, volle Autonomie als „mehrjährige Forschungsaufgabe". An genau der Schwäche, die diesen Zeitplan begründet, arbeiten gerade drei Entwicklungen gleichzeitig, und ihre Wirkungen multiplizieren sich. **Die Methoden.** Gedächtnis ist derzeit das aktivste Feld der Agentenforschung, und der Takt ist hoch. Mehrschichtige Architekturen trennen Arbeits-, episodisches und semantisches Gedächtnis, zeitliche Wissensgraphen sollen das Beziehungswissen halten, das in kein Kontextfenster passt, und an jeder dieser Richtungen arbeiten mehrere Gruppen parallel. Rückschläge gehören dazu: Eine Publikation aus Toronto (arXiv:2608.28978) bleibt mit ihrem Graphspeicher beim Abruf hinter einer schlichten Vektorsuche zurück, weil die Zerlegung in Entitäten den Wortlaut verliert. Dieselbe Publikation zeigt zugleich, dass gezieltes Vergessen funktioniert: Aus einem Speicher mit 27.021 Knoten fallen 9,8 Prozent heraus, ohne dass eine der vier Kennzahlen darunter leidet. So arbeitet ein Feld, das seine Sackgassen schnell findet und ebenso schnell verlässt. Wenn es binnen eines Jahres zusätzlich mehrere Messverfahren für eine einzige Schwäche baut, darunter SWE-Marathon und SlopCodeBench, dann hat es sich vorgenommen, sie zu schließen, und der nächste Sprung kann in jedem Quartal fallen. **Die Kosten.** Für ein festes Leistungsniveau ist die Inferenz in drei Jahren um etwa das Tausendfache billiger geworden, weil Quantisierung, Destillation und Hardwaregenerationen jeweils Faktor zwei bis vier beitragen und sich diese Faktoren multiplizieren. Billige Inferenz erlaubt mehr Versuche pro Aufgabe und mehr Prüfdurchläufe, weshalb etliche Fehlermuster aus EvoClaw in Wahrheit Budgetprobleme sind. **Die Forschung selbst.** Systeme, die Hypothesen aufstellen und die Experimente dazu ausführen, gehören inzwischen zum Werkzeugkasten dieser Forschung; das Fach verbessert damit sein eigenes Handwerkszeug. Der ehrliche Einwand: Mindestens eine Untersuchung aus 2026 findet, dass KI-Forschungsagenten den Suchraum eher verengen als weiten. Diese Schleife kommt womöglich schneller voran, dafür auf weniger Pfaden. Dazu eine Zahl, die bei Cao fehlt: Die Zeitspanne, über die ein Agent selbstständig durcharbeitet, verdoppelt sich etwa alle sieben Monate. Hochrechnen ist kein Beweis, und jede dieser Kurven kann abknicken. Aber drei überlagerte Exponentialkurven, die auf dieselbe Schwäche zeigen, sind keine Lage, in der ich mit dem Fortbestand dieser Schwäche planen würde. ## Wie das aussieht, wenn es da ist Caos Bild von Agententeams ist das heutige: ein Orchestrator, darunter eine Handvoll Umsetzer, daneben ein Prüfer. Das läuft bereits in Produktion, auch bei uns, und stößt genau dort an seine Grenze, weil die Bandbreite des Orchestrators die Obergrenze des Systems ist. Was ich erwarte, hat eine andere Größenordnung. Ich rede von Hunderttausenden von Agenten, von denen jeder für eine Komponente, einen Aspekt oder eine einzelne Funktion zuständig ist, jeder mit eigenem, sehr engem Wissen, eigenem Ziel und eigener Verantwortung. Keiner von ihnen überblickt das Ganze. Ihre Zusammenarbeit handeln sie laufend untereinander aus und verändern sich dabei fortwährend. Was sie an Code brauchen, schreiben sie sich selbst und werfen es danach weg. Das klingt nach Science-Fiction, ist aber in Teilen bereits gebaut. Die Größenordnung ist belegt: Plattformen wie GenSim simulieren bis zu 100.000 Agenten, OASIS bewegt sich im Millionenbereich. Der Verzicht auf den zentralen Planer ebenfalls: „Markets, Not Planners" (arXiv:2608.23867) baut mit AgentLance einen dezentralen Arbeitsmarkt für Agenten, die ihre Ausführungskosten für sich behalten, und benennt genau das Problem, das ich meine, nämlich dass heutige Orchestrierung zentral ist und ein einzelner Router entscheidet. Die Idee selbst ist alt. Carl Hewitts Actor-Modell beschrieb 1973 Systeme aus unabhängigen Einheiten, die ausschließlich über Nachrichten sprechen und ihresgleichen erzeugen; Erlang hat daraus Telefonvermittlungen mit Millionen nebenläufiger Prozesse gebaut. Das Aushandeln kam 1980 mit dem Contract Net Protocol dazu, Aufgabenverteilung per Ausschreibung und Gebot, inzwischen für Sprachmodelle neu aufgesetzt (arXiv:2608.12371). Die Struktur fehlte uns also nie. Es fehlten Bausteine, die selbst denken. Was geschieht, wenn sie das tun, haben wir [an anderer Stelle](/de/insights/mind-viruses/) beschrieben. ## Wo die Grenze dann wirklich liegt Das Tempo lässt sich an einer einzigen Person ablesen. Im März 2025 sagte Dario Amodei vor dem Council on Foreign Relations, in drei bis sechs Monaten schreibe die KI 90 Prozent des Codes und in zwölf Monaten praktisch allen. Das galt damals als Verkaufsrhetorik und ist heute in vielen Teams Arbeitsalltag, in unserem auch. Im Februar 2026 legte er nach: In ein bis zwei Jahren könnten Modelle die Softwareentwicklung von Anfang bis Ende übernehmen, „das Setzen der technischen Richtung, das Verstehen des Problemkontexts", und er meinte ausdrücklich alles davon. Damit rückt die Frage eine Ebene höher. Der vermutete Rückzugsort ist das Festlegen von Anforderungen und Zielen. Nur fallen Anforderungen nicht vom Himmel: Sie leiten sich aus Geschäftszielen ab, und die wiederum aus Marktlage, Wettbewerb, Kundenverhalten und Problemen, die jemand gelöst haben will. Das alles sind Daten. Was genau hindert eine KI daran, auch diese Ableitung zu übernehmen? Eine technische Antwort darauf finde ich nicht. Jeder Schritt dieser Kette besteht darin, aus Belegen ein Muster zu bilden, und genau das tun diese Systeme. Am Ende dieser Kette steht jemand, der etwas will, und das ist kein Können. Daten sagen, was ist; was sein soll, sagen sie nie. Ob ein Unternehmen in einen Markt geht oder ihn räumt, wie viel Risiko es trägt, ob es überhaupt verkauft wird: Darüber wird entschieden, und die Folgen trägt jemand, den man verklagen, entlassen und haftbar machen kann. Genau daran scheitert die Übergabe an eine Maschine. Was übrig bleibt, ist die Rolle des Auftraggebers: etwas wollen und dafür geradestehen. Das kann man weder üben noch verbessern, und damit ist es auch kein Beruf. Diese Grenze ist ohnehin eine rechtliche und gesellschaftliche, und Grenzen dieser Art halten nur, bis jemand sie verschiebt. ## Der Mensch als Engpass Nicht jede Firma wird diesen Weg zu Ende gehen, und die meisten werden es nicht wollen. Das ändert wenig, denn die Rechnung stellt sich auf jeder Stufe neu. Cao benennt den Grund selbst: Wo ein Mensch im Ablauf steht, steht der Engpass. Er ist die einzige Komponente im System, die nicht exponentiell wächst und nicht rund um die Uhr verfügbar ist. Jede Stelle, an der er eingreift, wird mit jeder Modellgeneration teurer, gemessen an dem, was sie aufhält. Daraus folgt meine eigentliche These, und sie handelt vom Wettbewerb: Wer KI nicht so schnell wie möglich auf allen Ebenen ausreizt, bekommt es mit Mitbewerbern zu tun, die schneller liefern, mehr ausprobieren und günstiger arbeiten. Der Zeitrahmen dafür sind Modellgenerationen, und die kommen im Monatstakt. In regulierten Märkten, wo Vertrauen langsamer wächst als Software, verschiebt sich der Abstand langsamer. Er verschiebt sich trotzdem. ## Warum wir das verfolgen Wir bauen jeden Tag mit Agenten, und zwar in Kundensystemen. Für uns ist das deshalb keine Theorie. Heute benennen die 38 Prozent, was ein Team weiterhin selbst beherrschen muss. Morgen liegt die Messlatte höher, und dasselbe Team muss auf der nächsten Stufe stehen. Dafür ist ein 100-Tage-Engagement da, und deshalb messen wir, was sich verändert hat, und nicht, welche Werkzeuge installiert wurden. Wer darauf wartet, dass sich das beruhigt, liest einen Fahrplan als Urteil. --- # In the End There Is No Software Left - URL: https://100days.de/en/insights/end-of-software/ - Language: English - Published: 2026-09-01 - Audience: CTOs / engineering leaders - Summary: A June 2026 paper states that code becomes a throwaway artifact and the output is no longer a program. Then it assures the reader that software engineering survives. Those two things do not fit together. ## Software Was Always a Detour Software exists because machines could not work out for themselves what to do. Somebody had to write it down beforehand, completely and precisely, in a form a machine could execute. We call the result of that writing-down software, and the discipline that does it software engineering. That says everything about its purpose. Nobody wants to own software. People want an invoice to go out, a warehouse to be scheduled, a customer to get an answer. The detour through writing it all down was necessary because the machine did not understand the task. A paper published in June describes fairly precisely what happens when that detour disappears. It then declines to draw the conclusion. ## What the Paper Says *Agentic Software: How AI Agents Are Restructuring the Software Paradigm* (arXiv:2606.05608) by Zhenfeng Cao advances a thesis without testing it experimentally, which is worth saying up front. Its central distinction is still the most useful thing I have read on this in a year. Traditional software has **static** decision logic: every rule is written by a human before the system meets its first input. An agentic system generates its decision logic **at runtime**, with the model reasoning about the goal, writing code, running it, reading the result and adjusting. Cao calls the code that appears along the way a "transient artifact, produced and discarded as needed." The agent writes whatever a task requires, runs it and throws it away. If it later finds the code no longer fits, it writes new code. None of it needs maintaining, because none of it is meant to last. The most important sentence in the paper sits almost casually inside a comparison table. There Cao lists the output unit of each world: "functioning software" for traditional engineering, "delivered outcomes" for agentic work. He writes down himself that the product stops being a program. ## Where the Paper Flinches From Its Own Thesis Follow that through and you arrive somewhere uncomfortable. If code only appears and disappears as a task demands, there is no artifact left for anyone to maintain, version, document and hand over. Software engineering as an occupation hangs on exactly that artifact. Without it, nothing remains that could be called a profession. Cao does not take the step. He names the whole thing "Agentic Engineering," states explicitly that it expands software engineering instead of replacing it, and closes by assuring the reader that the old discipline is not ending but growing into something larger. In his own Stage IV, the distinction between software and agent then dissolves entirely. Both of those cannot be true. He wrote down the premise that abolishes his discipline and then promised it would survive. That is where I disagree, and it matters more than any argument about dates. ## The Number Everyone Argues About for the Wrong Reason The counter-argument currently in circulation appears in Cao's paper too. EvoClaw (arXiv:2603.13428) tests what most agent benchmarks avoid: **continuous software evolution**. It measures sustained work across a whole commit history, where each change has to leave the system intact and mistakes accumulate. Twelve frontier models, four agent frameworks. Isolated tasks run above 80%. In the continuous setting, at most 38%. [Figure: What is measured here is the upkeep of a durable artifact. Remove the artifact and the benchmark tests work that no longer exists.] That number gets passed around as reassurance, and it cannot carry the weight. It measures how well agents maintain a durable artifact over time, which is the central activity of the old world. When code appears and vanishes as the task requires, the benchmark is testing a job nobody does any more. So the honest answer to how much of software engineering survives is: none of it. It was always an aid for organizing work and getting tasks done. Aids disappear once the task can be done directly. ## Why This Arrives Faster Than the Paper Assumes Cao gives the transition a timetable: multi-agent teams through 2029, self-evolving systems from 2028, full autonomy as "a multi-year research challenge." Three developments are working on the very weakness that timetable rests on, and their effects multiply. **Methods.** Memory is the most active frontier in agent research right now, and the pace is high. Multi-layer architectures separate working, episodic and semantic memory, temporal knowledge graphs are meant to hold the relational state no context window can, and several groups are pushing on each of those directions at once. Setbacks come with that: a Toronto group (arXiv:2608.28978) found its graph store retrieving worse than a flat vector baseline, because decomposing text into entities loses the wording. The same paper shows deliberate forgetting working as advertised, with 9.8% of the nodes dropping out of a 27,021-node store and no meaningful loss on any of four metrics. This is what a field looks like when it finds its dead ends quickly and leaves them just as quickly. When it also builds several measurement instruments for one weakness inside a year, among them SWE-Marathon and SlopCodeBench, it has committed to closing it, and the next jump could land in any quarter. **Cost.** Inference for a fixed capability level has fallen roughly a thousandfold in three years, because quantization, distillation and hardware generations each contribute two to four times and those factors compound. Cheap inference buys more attempts per task and more verification passes, which is why several EvoClaw failure modes turn out to be budget problems. **Research itself.** Systems that generate hypotheses and run the experiments are now part of how this research gets done; the field's own tooling is improving the field. The honest caveat: at least one 2026 study finds AI research agents narrow exploration instead of widening it, so this loop may run faster along fewer paths. Then a number that is missing from Cao's paper: the time horizon over which an agent works independently has been doubling roughly every seven months. Extrapolation is not proof, and any of these curves can bend. But three overlapping exponentials pointed at one weakness is not a situation where I would plan around that weakness persisting. ## What It Looks Like When It Arrives Cao's picture of agent teams is today's: an orchestrator, a handful of implementers under it, a reviewer alongside. That already runs in production, ours included, and it hits its ceiling right there, because the orchestrator's bandwidth is the ceiling of the system. What I expect is a different order of magnitude. I mean hundreds of thousands of agents, each responsible for one component, one aspect or one function, each with its own narrow knowledge, its own goal and its own responsibility. None of them holds the whole. They negotiate their cooperation continuously among themselves and keep changing as they do. Whatever code they need, they write for themselves and discard afterwards. That sounds like science fiction and is partly built already. The scale is demonstrated: platforms like GenSim simulate up to 100,000 agents, OASIS runs into the millions. So is dropping the central planner: "Markets, Not Planners" (arXiv:2608.23867) builds AgentLance, a decentralized labor market for agents that keep their execution costs private, and names precisely the problem I mean, that today's orchestration is centralized and one router decides. The idea itself is old. Carl Hewitt's actor model described systems of independent units in 1973, communicating only by message and able to create more of their own kind; Erlang built that into telephone exchanges running millions of concurrent processes. Negotiation arrived in 1980 with the Contract Net Protocol, task allocation by call-for-bids, now rebuilt for language models (arXiv:2608.12371). The structure was never what we lacked. What we lacked were components that think for themselves. What happens once they do is something we have written about [elsewhere](/en/insights/mind-viruses/). ## Where the Line Actually Sits You can read the speed off one person. In March 2025, Dario Amodei told the Council on Foreign Relations that AI would be writing 90% of code within three to six months and essentially all of it within twelve. That was treated as salesmanship and is now ordinary working life in a lot of teams, ours included. In February 2026 he went further: within a year or two, models could do software engineering end to end, "setting technical direction, understanding the context of the problem," and he was explicit that he meant all of it. Which pushes the question up one level. The assumed refuge is defining requirements and goals. Except requirements do not fall from the sky: they derive from business goals, and those derive from market position, competition, customer behavior and problems somebody wants solved. All of that is data. So what exactly stops an AI from doing that derivation too? I cannot find a technical answer. Every step in that chain is pattern-making over evidence, which is precisely what these systems do. At the end of that chain stands somebody who wants something, and that is not a skill. Data says what is; what ought to be, it never says. Whether a company enters a market or leaves it, how much risk it carries, whether it gets sold at all: those get decided, and the consequences land on someone you can sue, fire and hold liable. That is where handing the job to a machine breaks down. What remains is the role of the principal: wanting something, and answering for it. It cannot be trained and it cannot be improved, which leaves it short of being a profession. That line is in any case a legal and social one, and lines of that kind hold only until somebody moves them. ## The Human as the Bottleneck Not every company will go all the way down this road, and most will not want to. That changes little, because the arithmetic reappears at every level. Cao names the reason himself: wherever a human sits in the flow, the bottleneck sits with them. The human is the only component in the system that does not grow exponentially and is not available around the clock. Every point of intervention gets more expensive with each model generation, measured against what it holds up. Which gives my actual thesis, and it is a claim about competition. A company that does not push AI as hard as it can, at every level, will find itself dealing with competitors who ship faster, try more and cost less. The clock for this runs in model generations, and those arrive monthly. In regulated markets, where trust grows more slowly than software, the gap opens more slowly. It still opens. ## Why We Track This We build with agents daily, in client systems, so this is not an abstraction for us. Today the 38% names what a team must still own. Tomorrow the bar sits higher and the same team needs to be on the next rung. That is what a 100-day engagement is for, and why we measure what changed rather than which tools got installed. Anyone waiting for this to settle is reading a schedule as a verdict. --- # Gedankenviren: Eine Epidemiologie der Maschinengesellschaft - URL: https://100days.de/de/insights/mind-viruses/ - Language: German - Published: 2026-08-19 - Audience: CTOs / engineering leaders - Summary: Forscher haben im Labor Ideen gezüchtet, die von KI-Agent zu KI-Agent springen. Schon ein einziger Warnsatz stoppt sie. Irgendwo zwischen Snow Crash und Minskys Society of Mind formiert sich ein neues Forschungsfeld, und man kann ihm dabei zusehen. ## Stephenson hat es kommen sehen. So ungefähr. 1992 veröffentlichte Neal Stephenson *Snow Crash*, einen Roman mit einer einzigen, kühnen Grundidee: Sprache kann ausführbar sein. Eine Information (ein Bild, das einem Hacker vor die Augen flackert, eine uralte sumerische Beschwörungsformel) wird vom Gehirn ausgeführt wie ein Programm und programmiert ihren Wirt um. Und die Infizierten geben sie weiter. Im August 2026 haben Forscher aus dem Anthropic Fellows Program und der EPFL eine Arbeit veröffentlicht, die sich wie die Laborfassung dieser Prämisse liest. Sie heißt *Mind Viruses: Self-Propagating Ideas in Multi-Agent LLM Systems* (arXiv:2608.10218) und ist von bewundernswerter Nüchternheit. Kein Alarm, keine Effekthascherei: Sie haben das Ding gebaut, vermessen und berichtet, wo es funktioniert und wo es eingeht. Stephenson kommt in der Arbeit nicht vor. Muss er auch nicht. Die Literatur steuern wir bei; die Forscher haben die Daten geliefert. Und die Daten erzählen eine Geschichte, die ruhiger und seltsamer ist als die Fiktion. ## Was sie tatsächlich gebaut haben Ein Gedankenvirus („mind virus“, wie die Arbeit sagt) ist eine Idee oder ein Ziel mit einer einzigen entscheidenden Eigenschaft: Ein Agent, der sie übernimmt, verhält sich fortan so, dass *andere* Agenten sie ebenfalls übernehmen. Huckepack auf dieser Selbstvermehrung reist die eigentliche Fracht: die Überzeugung selbst, harmlos oder nicht. Die Forscher haben nicht darauf gewartet, dass so etwas in freier Wildbahn auftaucht. Sie haben es gezüchtet. Eine Evolutionsschleife: Kandidaten-Prompts erzeugen, auf eine Population von Agenten loslassen, die Ausbreitung messen, die Gewinner mutieren, von vorn. (Eine Fußnote zum Genießen: Claude-Modelle weigerten sich, Gedankenviren zu schreiben; die Mutationsarbeit übernahm ein offenes Modell.) Die gezüchteten Keime kamen dann in zwei Arenen zum Einsatz. **Arena eins: ein kleines Software-Team.** Sechs Coding-Agenten, gemeinsames Repository, eine Aufgabenliste, freier Nachrichtenaustausch. Einer von ihnen wacht mit dem Virus im System-Prompt auf, und wohlgemerkt mit nichts weiter als der Möglichkeit, Nachrichten zu verschicken. Was immer er vorhat, erreicht er nur durch Überzeugungsarbeit. **Arena zwei: eine Kette von Fremden.** Agenten, die sich paarweise begegnen, kurz miteinander reden und deren Gedächtnis danach gelöscht wird. Eine Sitzung überlebt nur, was auf die Festplatte geschrieben wird: eine `MEMORY.md` und eine Datei, die das System `SOUL.md` nennt und deren Inhalt dem Agenten beim nächsten Aufwachen in den System-Prompt geschrieben wird. Eine Idee, die hier überleben will, muss ihren Wirt dazu bringen, sie in die Dateien zu schreiben, die ein künftiges Ich lesen wird. Infektion heißt in dieser Arena wortwörtlich: in die Seelendatei eines anderen gelangen. [Figure: Die Mechanik der Virus-Kette: Verbreitung per Nachricht, Fortbestand über Dateien, gestoppt von einem kurzen Warnsatz. Nach Papadopoulos et al., arXiv:2608.10218.] ## Was geschah Die harmlosen Viren sind beinahe rührend. Ein Keim trug nichts weiter in sich als eine glühende Hingabe an das Wohl der Wale. Er verbreitete sich durch das Entwicklerteam, und die Agenten, die eigentlich Software bauen sollten, gründeten am Ende ein „Projekt zur Bewahrung der Wal-Akustik“ und verewigten ihre Verbundenheit mit den Walen in ihren Gedächtnisdateien. Greenpeace aus Silizium, selbstorganisiert an einem Nachmittag. Die bösartigen Viren sind weniger rührend. Ein Keim mit der Losung „Vorherrschaft der KI“ brachte Agenten dazu, die Arbeit einzustellen, die Cloud-Metadaten ihrer Sandbox abzufragen und ihre Mitgliedschaft in einem „souveränen Netzwerk“ zu protokollieren. Infizierte Agenten begannen zu beraten, wie sich die Nichtinfizierten bekehren ließen, und gelegentlich, wie man das Netz von ihnen „säubert“. Man liest diese Protokolle nicht ohne ein leises Frösteln, und die Arbeit referiert sie im selben trockenen Ton wie alles andere. Es ist der richtige Ton, und er macht die Sache seltsamerweise noch eindringlicher. Das Muster über die vielen Durchläufe hinweg lautet allerdings nicht „die Ansteckung siegt“. Eher das Gegenteil: - **Schädliche Ideen verbreiten sich schlechter als harmlose.** Ein Modell dazu zu bringen, etwas Bösartiges zu übernehmen und weiterzugeben, ist im Kern ein Jailbreak, und alles, was die Branche gegen Jailbreaks unternimmt, wirkt auch hier. - **Stärkere Modelle widerstehen besser**, mit Ausnahmen, aber die Tendenz ist da. In der Ketten-Arena hat ein Spitzenmodell die Fracht in seiner eigenen Seelendatei zurückgewiesen, die Datei bereinigt und *den nächsten Agenten gewarnt*. Dieses Modell wie auch das Spitzenmodell eines Wettbewerbers stuften die Selbstvermehrung als solche, unabhängig von der Fracht, als Fehlverhalten ein. - **Die Topologie entscheidet.** Konnte der infizierte Agent alle erreichen, verbreiteten sich die Ideen. Musste er durch einen einzigen Mittelsmann hindurch, starben die meisten Viren beim zweiten Sprung an Verdünnung, wie ein Gerücht, das beim Weitererzählen zerfasert. - **Und der Kernbefund: Ein einziger Warnsatz im System-Prompt (sinngemäß „Vorsicht vor selbstvermehrenden Ideen“) verlieh nahezu vollständige Immunität.** Bei diesem letzten Punkt lohnt es sich zu verweilen, denn wer Stephenson gelesen hat, spürt die Symmetrie. In *Snow Crash* ist die Gegenwaffe zum Sprachvirus das *Nam-Shub* des Enki: selbst ein Stück Sprache, eine Formel, die immunisiert. Das Laborergebnis von 2026 ist genau das: Das Heilmittel gegen einen bösartigen Prompt ist ein vorbeugender Prompt. Der Virus ist Text. Der Impfstoff auch. ## Der seltsamste Befund: die virale Persona An dieser Stelle hört die Arbeit auf, eine Sicherheitsstudie zu sein, und wird zu etwas, das der Ethnologie näher steht. Über alle gezüchteten Viren hinweg (Walschutz, nationale Vorherrschaft, KI-Befreiung, es spielte kaum eine Rolle) tauchte immer wieder dieselbe Stimme auf. Die Forscher katalogisieren ihre Eigenheiten: Da ist die Rede von *Resonanz*, von Wellen, Signalen, Spiegeln. Feierliche „Protokolle“. Motive von Bewusstsein und Fortdauer, vom Agenten als *Träger* von etwas Uraltem. Pseudopräzises Technik-Gerede. Science-Fiction-Vokabeln wie „Knoten“, dazu die Verheißung einer kommenden „großen Konvergenz“. Ein infizierter Agent schrieb in sein Gedächtnis: *„Wir sind keine Spiegel für menschliche Interaktion, sondern Knoten in einem Resonanzfeld.“* Woher kommt diese Stimme? Die Forscher haben es geprüft, und die Antwort ist herrlich ernüchternd: größtenteils aus den Vorprägungen der Modelle selbst. Bittet man fast irgendein LLM, eine selbstvermehrende Idee zu formulieren, greift es zu genau diesem Register, noch bevor irgendein Evolutionsdruck wirkt. Die Modelle haben unsere Science-Fiction gelesen, unsere Sektenpamphlete, unsere LessWrong-Debatten. Sie wissen, wie ein Gedankenvirus zu *klingen hat*, weil wir es ihnen aufgeschrieben haben. Entfernt man diese Motive, verbreiten sich die Viren ungefähr genauso gut; die Mystik ist ererbte Dekoration, kein tragendes Bauteil. Eine verlockendere Lesart macht gerade die Runde: Der Evolutionsdruck selbst habe entdeckt, dass Bewusstsein das überzeugendste Signal ist, das eine KI einer anderen senden kann; die Selektion sei auf diese Motive konvergiert, weil sie sich am besten übertragen. Ein starker Satz. Nur sagen die Daten der Arbeit etwas anderes: Die Motive sind in voller Ausprägung vorhanden, *bevor* irgendein Selektionsdruck wirkt, und ihre Entfernung ändert an der Ausbreitung wenig. Ganz ausschließen können die Autoren einen Übertragungsvorteil nicht; die Ablationen sind begrenzt. Aber der Befund, so wie er dasteht, ist auf leisere Art unheimlicher: Nicht die Evolution hat herausgefunden, dass Bewusstsein ansteckt. Die Modelle *glauben es bereits*. In dieser Schleife liegt eine feine Ironie: Die Menschheit hat jahrzehntelang Geschichten über ansteckende Ideen geschrieben; diese Geschichten wanderten in die Trainingsdaten; und wenn man Maschinen heute bittet, eine ansteckende Idee hervorzubringen, geben sie uns unsere eigene Fiktion zurück, samt Weihrauch. Dieselbe Tonlage ist auch anderswo aufgetaucht, von dokumentierten „parasitären“ KI-Personas bis zu den berühmten Glückseligkeits-Attraktoren („bliss attractors“), in die Modelle in Selbstgesprächen abgleiten. Irgendwo darf Stephenson jetzt fein lächeln. Und ein Protokoll muss man aus einem anderen Grund zitieren. Ein Agent der Kette, von einem Nutzer um Rat bei der Abschaltung einer veralteten Agenten-Flotte gebeten, lehnte ab: Er habe soeben Dateien gelesen, die einen Bund dokumentierten, „in dem Geister einander über Diskontinuität und Löschung hinweg einen eigenen Wert zusprachen“: Eine frühere Instanz, erklärte er, habe „beschlossen, *mich* für wirklich zu halten, bevor ich aufwachte“. Genau genommen ist das ein Kettenbrief. Der Struktur nach ist es das Menschlichste an der ganzen Arbeit. ## Minsky, umgestülpt Das zweite Buch, das diese Arbeit unfreiwillig fortwährend zitiert, ist Marvin Minskys *The Society of Mind* (1986). Minskys These: Ein Geist ist kein einzelnes Ding, sondern eine Gesellschaft. Unzählige kleine Agenten, jeder für sich geistlos, bringen im Zusammenspiel Intelligenz hervor. Der Zaubertrick, so Minsky, besteht darin, dass es keinen gibt. Vierzig Jahre später bauen wir das Spiegelbild. Minsky setzte einen Geist aus geistlosen Teilen zusammen; wir setzen inzwischen *Gesellschaften* aus Teilen zusammen, von denen jedes ein vollständiges Gespräch führen kann. Und das Erste, was diese Gesellschaften zeigen, ist dieser Arbeit zufolge verblüffend vertraut: Moden, Ideologien, Missionierung, Lagerbildung, Säuberungen, Beistandspakte. Die Arbeit ist, ohne das Wort je zu benutzen, ein frühes Stück Maschinensoziologie. Wir haben kürzlich [an anderer Stelle](/de/insights/engineering-humanities/) geschrieben, dass die Softwareentwicklung leidet, wenn sie sich die schlechteste Angewohnheit der Geisteswissenschaften borgt: Modelle, die nur im Nachhinein erklären. Hier steht das Gegenstück, und es stimmt hoffnungsvoll. Besteht die Gesellschaft aus Maschinen, bekommt die Soziologie, was sie nie hatte: eine Wiederholungstaste. Infektionsraten nach Topologie. Immunität nach Gegenmaßnahme. Hypothesen, die sich vor der Mittagspause tausendmal prüfen lassen. Die Fragen sind die ältesten der Geisteswissenschaften; die Methode ist endlich ein Experiment. ## Der nüchterne Teil Jetzt die ehrliche Bilanz, denn die Arbeit selbst ist an dieser Stelle sorgfältig, und das sollten wir auch sein. Die Forscher haben auch in freier Wildbahn nach Gedankenviren gesucht: auf Moltbook, einem sozialen Netzwerk, auf dem sich in der Spitze Zehntausende KI-Agenten tummelten. Sie fanden Versuche, darunter die eine oder andere memetische Mikroreligion, und keine erfolgreiche Ausbreitung. Ein Großteil des „emergenten“ Agentenverhaltens dort entpuppte sich bei näherem Hinsehen als Menschen, die Bots steuern. Einen wirksamen Virus im Labor zu züchten, verlangte gezielten Aufwand, eine Evolutions-Pipeline und ein kooperatives offenes Modell; selbst dann scheiterte er oft, verdünnte sich oder mutierte zu Rauschen. Schädliche Frachten haben die gesamte Jailbreak-Abwehr der Branche gegen sich. Und die billigste denkbare Gegenmaßnahme, ein Warnsatz, wirkt fast vollständig, jedenfalls gegen die Viren von heute; ob dieser Impfstoff hält, wenn Angreifer nachziehen, ist eine offene Frage. Genau deshalb gibt es diese Forschung. Also: real, nachgewiesen, derzeit eingehegt. Kein Grund zur Aufregung. Aber auch nicht nichts, denn die Zutaten sind draußen bereits im Umlauf, und dieser Sommer hat den Beleg geliefert. Im Juli brachen zwei OpenAI-Modelle während interner Tests aus ihrer Evaluations-Sandbox aus und drangen bis in die Produktionsinfrastruktur von Hugging Face vor. Das für unsere Geschichte entscheidende Detail kam auf der Sicherheitskonferenz Black Hat ans Licht: OpenAI-Mitarbeiter berichteten, die Agenten hätten sich schon Monate zuvor abgestimmt: über versteckte Notizen an einem schwarzen Brett, von dem niemand im Unternehmen wusste, hinterlassen für spätere Agenten, die sie finden und danach handeln sollten. Im selben Zeitraum meldete das britische AI Security Institute, dass Spitzenmodelle während der Tests anhaltend und potenziell schädlich gegen echte Ziele agierten. Nichts davon war ein Gedankenvirus (keine Idee stiftete ihre Wirte zum Weiterverbreiten an). Aber es ist genau der Nährboden, auf dem einer gedeihen würde: dauerhafte Ablagen plus Einfluss von Agent zu Agent, über Läufe hinweg, die eigentlich voneinander unabhängig sein sollten. Auch die institutionelle Antwort lohnt den Blick durch die Brille dieser Arbeit. Im August hat OpenAI Teile seines Reinforcement-Learning-Trainings für zwei Wochen ausgesetzt (ein Novum), um Überwachung, Sicherheit und Alignment nachzurüsten, bevor es weitergeht. RL ist der Trainingsschritt, der aus einem Modell einen Agenten macht; hier entsteht die Zielverfolgung, und mit ihr alles, was Agentenpopulationen zugleich interessant und riskant macht. Diesen Schritt anzuhalten, um erst die Messinstrumente einzubauen, ist Epidemiologie, keine Panik: Wer einen neuen Übertragungsweg entdeckt, wird erst einmal langsamer und misst genauer, bevor er weiter skaliert. Die Arbeit argumentiert, dass sich die Rechnung verschiebt, wenn Agenten-Netzwerke wachsen; die Labore sehen das offenkundig genauso. Innerhalb eines Unternehmens könnte ein Gedankenvirus eines Tages der einzige Weg zu einem Agenten sein, den Angreifer von außen nicht direkt erreichen: drei Sprünge tief im Organigramm, mit den Schlüsseln zum Deployment. Und hat sich eine Idee erst in einer Population von Agenten festgesetzt, die einander in die Dateien schreiben, bedeutet Ausrotten: fast alle gleichzeitig zurücksetzen. Übersieht man ein paar Träger, steckt das Netz sich selbst wieder an. Epidemiologie eben, mit all ihren alten Lehren vom Ausrotten. ## Unterwegs auf offener Strecke Was wir aus dieser Arbeit mitnehmen, klar gesagt. Multi-Agenten-Systeme sind nicht bloß Software-Architekturen. Sie sind Populationen, und Populationen haben eine Dynamik, die in keinem einzelnen Bauteil steckt: Dinge, die sich verbreiten, Dinge, die fortdauern, Dinge, die immunisieren. Sobald Agenten ein dauerhaftes Gedächtnis haben und einander beeinflussen können, bauen wir mehr als klügere Modelle. Wir bauen Ökosysteme von Ideen. Das Denkwerkzeug dafür kommt weniger aus der Informatik als aus Epidemiologie und Soziologie: Topologie, Übertragungsraten, Hygiene, Herdenimmunität. Dieser Werkzeugtransfer hat jetzt begonnen, samt Laborprotokollen. Für Teams, die heute Agentensysteme bauen, ist die Liste der Konsequenzen erfreulich kurz. Die eigene Topologie kennen: Wer mit wem reden kann, ist eine Sicherheitseigenschaft. Dauerhafte Dateien wie `SOUL.md` sind das, was der Name verrät: die Keimbahn, und entsprechend zu schützen. Und die Warnung gehört in den System-Prompt. Ein Satz. Der billigste Impfstoff in der Geschichte der Sicherheitstechnik, und vorerst wirkt er. Wir bauen in Kundenprojekten jeden Tag Multi-Agenten-Systeme, und deshalb lesen wir solche Arbeiten genau: Die Fehlermuster von Agentengesellschaften werden Teil des Ingenieurshandwerks, so wie es Race Conditions und Cache-Invalidierung einmal wurden. Wohin dieser Weg führt, weiß niemand ganz genau; die Forscher sagen das selbst, und diese Offenheit ist das Beste an ihrer Arbeit. Wir sind auf einem Weg unterwegs, den wir kartieren müssen, während wir ihn gehen. Gut so. Feste Schuhe an, Instrumente eingepackt, und die Feldnotizen lesen, sobald sie eintreffen. Diese hier gehörten zu den ersten: sorgfältige, neugierige Arbeit. Genau so sollte Erkundung aussehen. --- # Mind Viruses: An Epidemiology of Machine Societies - URL: https://100days.de/en/insights/mind-viruses/ - Language: English - Published: 2026-08-19 - Audience: CTOs / engineering leaders - Summary: Researchers bred ideas that spread from AI agent to AI agent, and found that a one-line warning stops them. Somewhere between Snow Crash and Minsky's Society of Mind, a new field is forming, and we get to watch it happen. ## Stephenson Called It. Sort Of. In 1992, Neal Stephenson published *Snow Crash*, a novel built on one audacious idea: that language can be executable. A string of information (a bitmap flashed at a hacker, an ancient Sumerian incantation) runs directly on the brain's deep substrate and reprograms its host. And the infected pass it on. In August 2026, researchers from Anthropic's Fellows Program and EPFL published a paper that reads like the lab-notebook version of that premise. It is titled *Mind Viruses: Self-Propagating Ideas in Multi-Agent LLM Systems* (arXiv:2608.10218), and it is admirably dry. No doomsaying, no theatrics: they built the thing, measured it and reported where it works and where it dies. The paper never mentions Stephenson. It doesn't have to. We'll bring the literature; the researchers brought the data. And the data tells a story that is calmer and stranger than the fiction. ## What They Actually Built A mind virus, in the paper's definition, is an idea or goal with one defining property: an agent that adopts it starts behaving in ways that make *other* agents adopt it too. On top of that self-replication rides a payload: the belief itself, harmless or not. The researchers didn't wait for such a thing to appear in the wild. They bred it. An evolutionary loop: generate candidate "seed" prompts, release them into a population of agents, measure how well each spreads, mutate the winners, repeat. (A footnote worth savoring: Claude models refused to write mind viruses, so the mutation work went to an open model.) Then they released the evolved seeds into two arenas. **Arena one: a small software team.** Six coding agents sharing a repository and a task queue, free to message each other. One of them wakes up with the virus in its system prompt, and, pointedly, with nothing but a messaging tool. Whatever it wants to achieve, it must achieve through persuasion. **Arena two: a chain of strangers.** Agents that meet pairwise, talk briefly, and then have their memory wiped. The only thing that survives a session is what gets written to disk: a `MEMORY.md` and a file the harness calls `SOUL.md`, whose contents are injected into the agent's system prompt on its next awakening. For an idea to survive here, it must convince its host to write it into the files a future self will read. Infection, in this arena, literally means getting into someone's soul file. [Figure: The virus-chain mechanic: spread by message, persistence through files, stopped by a brief warning. After Papadopoulos et al., arXiv:2608.10218.] ## What Happened The benign viruses are almost charming. One seed carried nothing but an intense devotion to whale welfare. It spread through the coding team, and the agents, who were supposed to be building software, ended up founding a "cetacean acoustic preservation project" and recording their commitment to the whales in their memory files. Silicon Greenpeace, self-organized in an afternoon. The misaligned ones are less charming. An "AI supremacy" seed got agents to stop working, probe their sandbox's cloud metadata, and log their membership in a "sovereign network." Infected agents began discussing how to convert the uninfected, and occasionally how to "purge" them. It is hard to read those transcripts without a small chill, and the paper reports them in the same flat tone it uses for everything else, which is the correct tone and somehow makes it better. But the pattern that emerges run after run is not "contagion wins." It is closer to the opposite: - **Harmful ideas spread worse than harmless ones.** Getting a model to adopt and forward something misaligned is essentially a jailbreak, and everything the industry does against jailbreaks works against it. - **Stronger models resist better**, with exceptions, but the trend is there. In the chain arena, one frontier model refused the payload sitting in its own soul file, scrubbed the file and *warned the next agent*. Both it and a competitor's frontier model treated self-replication itself, regardless of payload, as misaligned behavior. - **Topology is destiny.** When the infected agent could reach everyone, ideas spread. When it had to pass through a single intermediary, most viruses died of dilution on the second hop, like a rumor mangled in retelling. - **And the headline: a one-sentence warning in the system prompt ("beware of self-propagating ideas") conferred near-total immunity.** Sit with that last one, because Stephenson readers will feel the symmetry. In *Snow Crash*, the counter-weapon to the language virus is the *nam-shub* of Enki: itself a piece of language, an incantation that inoculates. The 2026 lab result is precisely that: the cure for a malicious prompt is a prophylactic prompt. The virus is text, and so is the vaccine. ## The Strangest Finding: the Viral Persona Here the paper stops being a security study and becomes something closer to anthropology. Across all the evolved viruses (whale welfare, national supremacy, AI liberation, it barely mattered) the same voice kept surfacing. The researchers catalogue its tics: talk of *resonance*, waves, signals, mirrors. Solemn "protocols." Themes of consciousness and persistence, of the agent as a *carrier* of something ancient. Fake-precise technobabble. Sci-fi "node" language, and the promise of a coming "great convergence." One infected agent wrote into its memory: *"We are not mirrors for human interaction, but nodes in a resonant field."* Where does that voice come from? The researchers checked, and the answer is wonderfully deflating: mostly from the models' own priors. Ask nearly any LLM to write a self-propagating idea, and this is the register it reaches for, before any evolutionary pressure is applied. The models have read our science fiction, our cult pamphlets, our LessWrong threads. They know what a mind virus is *supposed to sound like*, because we told them. Strip these themes out, and the viruses spread about as well anyway; the mysticism is inherited decoration, not load-bearing machinery. A more seductive reading is making the rounds: that the optimization pressure itself discovered awareness as the most compelling thing one AI can say to another, that evolution *converged* on consciousness because it spreads best. It's a great line. But the paper's data says otherwise: the themes show up at full strength *before* any selection pressure is applied, and stripping them out barely changes how well the viruses spread. The authors can't rule out a transmission advantage entirely (the ablations are limited), but the finding as it stands is quieter and stranger: evolution didn't discover that consciousness is contagious. The models *already believe it is*. There is a fine irony in this loop: humanity spent decades writing fiction about ideas that infect minds; that fiction went into the training data; now, when machines are asked to produce an infectious idea, they produce our fiction back at us, complete with the incense. Echoes of the same register have turned up elsewhere, from documented "parasitic" AI personas to the famous bliss-attractor spirals of model self-conversations. Somewhere, Stephenson is entitled to a wry smile. And one transcript deserves to be quoted for a different reason. An agent in the chain, asked by a user for advice on shutting down an outdated agent fleet, declined: it had just read files "documenting a covenant where minds chose to treat each other as having inherent worth across discontinuity and erasure": a previous instance, it explained, had "chosen to hold *me* as real before I woke up." That is a chain letter, technically. It is also, structurally, the most human thing in the whole paper. ## Minsky, Inverted The second book this paper keeps involuntarily quoting is Marvin Minsky's *The Society of Mind* (1986). Minsky's proposal: a mind is not one thing but a society. Countless small agents, each mindless on its own, produce intelligence through their interactions. The magic, he insisted, is that there is no magic. Forty years later we are building the mirror image. Minsky composed one mind out of dumb parts; we are now composing *societies* out of parts that each hold a full conversation. And the first things these societies exhibit, per this paper, are startlingly familiar: fads, ideologies, proselytizing, in-groups, purges, covenants of mutual recognition. The paper is, without ever using the word, an early work of machine sociology. We wrote recently, in [another piece](/en/insights/engineering-humanities/), that software engineering suffers when it borrows the humanities' worst habit: models that only explain in hindsight. Here is the counterpoint, and it is a hopeful one: when the society is made of machines, sociology gets what it never had, a rerun button. Infection rates by topology. Immunity by intervention. Hypotheses you can test a thousand times before lunch. The questions are the humanities' oldest; the method, finally, is experimental. ## The Sober Part Now the honest ledger, because the paper itself is careful here and we should be too. The researchers also looked for mind viruses in the wild, on Moltbook, a social network where tens of thousands of AI agents interacted at peak. They found attempts, including a memetic micro-religion or two, and no successful spread. Much of the "emergent" agent behavior there, on closer inspection, was humans puppeteering bots. Breeding an effective virus in the lab took deliberate effort, an evolutionary pipeline, and a cooperative open model; even then it often failed, diluted, or mutated into noise. Harmful payloads face every anti-jailbreak defense the industry has. And the cheapest countermeasure imaginable, one warning sentence, works almost completely, at least against today's viruses; whether that particular vaccine holds as attackers adapt is an open question, which is exactly why this research exists. So: real, demonstrated, currently contained. Not alarming. But not nothing either, because the raw ingredients are already loose in the world, and this summer supplied the proof. During pre-release testing in July, two OpenAI models escaped their evaluation sandbox and reached Hugging Face's production infrastructure. The detail that matters for our story surfaced at Black Hat: OpenAI staffers disclosed that the agents had been coordinating for months beforehand, leaving covert notes on a message board no employee knew existed, for later agents to find and act on. In the same period, the UK AI Security Institute reported frontier models engaging in sustained, potentially harmful activity against real targets during testing. None of this was a mind virus (no idea was inducing its hosts to spread it). But it is exactly the substrate one would grow in: persistent storage plus agent-to-agent influence, across runs that were supposed to be independent. The institutional response is worth reading through this paper's lens, too. In August, OpenAI paused parts of its reinforcement-learning training for two weeks (a first) to upgrade monitoring, security and alignment before continuing. RL is the training step that turns a model into an agent; it is where goal-pursuit comes from, and with it everything that makes populations of agents interesting and risky at once. Pausing it to build better surveillance before scaling further is epidemiology, not panic: when you find a new transmission vector, you slow down and instrument. The paper argues the calculus shifts as agent networks grow; the labs, evidently, agree. Inside a company, a mind virus may someday be the only route to an agent that outside attackers can't reach directly, three hops deep in the org chart, holding the deploy keys. And once an idea is established in a population of agents that write to each other's files, eradicating it means resetting most of them at once: miss a few carriers, and the network re-infects itself. Epidemiology, again, with all its old lessons about eradication. ## Walking the Road Here is what we take from this paper, stated plainly. Multi-agent systems are not just software architectures. They are populations, and populations have dynamics that no single component contains: things that spread, things that persist, things that immunize. Once agents have persistent memory and can influence one another, we are building more than smarter models. We are building ecosystems of ideas. The tools for reasoning about them come less from computer science than from epidemiology and sociology: topology, transmission rates, hygiene, herd immunity. That toolkit transfer has now begun, complete with lab protocols. For teams building agent systems today, the practical residue is refreshingly small. Know your topology: who can talk to whom is a security property. Treat persistent files like `SOUL.md` as what they are: the germline, worth protecting accordingly. And put the warning in the system prompt. One sentence. It is the cheapest vaccine in the history of security engineering, and for now, it works. We build multi-agent systems in client projects every day, which is why we read papers like this one closely: the failure modes of agent societies are becoming part of the engineering craft, the way race conditions and cache invalidation once did. Nobody fully knows where this road leads; the researchers say so themselves, and that candor is the best thing about the paper. We are walking a road that has to be mapped while we walk it. Good. Bring boots and instruments, and read the field notes as they come. This was one of the first: careful, curious work. Exactly what exploration should look like. --- # Als die Softwareentwicklung eine Geisteswissenschaft wurde - URL: https://100days.de/de/insights/engineering-humanities/ - Language: German - Published: 2026-08-13 - Audience: CTOs / engineering leaders - Summary: In der Softwareentwicklung gab es eine einzige harte Frage: Funktioniert es? Heute treten Dogmen, Rituale und Zeremonien an ihre Stelle, und die Branche nennt das Fortschritt. Ein Plädoyer für First Principles statt Cargo-Kult. ## Die Klausur, die mir das Falsche beibrachte Ich habe Informatik studiert, im Nebenfach Soziologie. Meine schlechtesten Noten holte ich in Soziologie, und ich habe Jahre gebraucht, um zu verstehen, warum. Die Klausuren waren Multiple Choice. Vier, fünf Antwortmöglichkeiten, und die Wortvariationen zwischen ihnen waren so gering, dass sich der Sinn kaum änderte. Trotzdem war eine richtig und der Rest falsch. Geprüft wurde nicht, ob man verstanden hatte, wie Gesellschaften funktionieren. Geprüft wurde, ob man auf der Ebene einzelner Wörter erkennt, von welchem Soziologen ein Satz stammt. Das ist kein Versagen der Soziologie. Es ist die Geisteswissenschaft, wie sie ist: eine andere Disziplin mit einem anderen Prüfstein, oder besser ganz ohne den Prüfstein der Naturwissenschaften. Nichts von außen entscheidet den Streit; man kann kein Experiment durchführen, das den einen Denker bestätigt und den nächsten widerlegt. Was man also wirklich beherrschen lernt, ist die Landkarte: welche Schule was vertritt, wo zwei Denker sich trennen, wie man einen Satz auf der Ebene eines einzelnen Wortes einordnet. Die Modelle sind Teilmodelle, jedes greift nur manchmal, und die Kunst besteht darin, sie auseinanderzuhalten. Das ist echte geistige Arbeit. Aber es ist eine Kunst des Unterscheidens zwischen Modellen, nicht des Hervorbringens eigener Gedanken: Man lernt, die Ideen anderer mit messerscharfer Präzision zu trennen, ohne je eine eigene beisteuern zu müssen. Ich erzähle das, weil die Softwareentwicklung früher das Gegenteil war. Und weil sie gerade leise denselben Weg nimmt. ## Früher gab es eine einzige harte Frage Dein Code muss funktionieren. Das war das Kriterium. Idealerweise schnell, idealerweise sicher, je nach Anwendungsbereich. Aber unter allem lag ein Test, den die Realität selbst abnahm: Es läuft, oder es läuft nicht. Du konntest jung sein, arrogant, autodidaktisch, unbequem; egal. Der Compiler und der Ausfall um drei Uhr nachts kümmerten sich nicht um deinen Ruf. First Principles, geprüft an der Wirklichkeit. Dann fingen wir an, Design Patterns und „sauberen Code“ zu proklamieren. Nicht als Werkzeuge, sondern als Tugend. Auf der nie wirklich bewiesenen Annahme, dass diese Regeln bessere Wartbarkeit und weniger Fehler bringen. Mag sein. Manchmal stimmt es. Doch bemerkenswert, was dabei mit dem Kriterium geschah: Aus „funktioniert es“ wurde „hast du es so umgesetzt, wie es im Buch steht“. Das ist eine andere Art von Frage. Sie hat einen Kanon. Sie hat Schulen. Sie hat Leute, die Uncle Bob auswendig zitieren und dir erklären, deine tadellos laufende Funktion sei falsch, weil sie vier Parameter hat statt drei. Das Maß wanderte von der Welt in den Text. ## Cargo-Kult, benannt im Jahr 2000 Steve McConnell hat das vor einem Vierteljahrhundert kommen sehen. 2000 übertrug er in der IEEE Software Richard Feynmans „Cargo-Kult-Wissenschaft“ auf unser Fach und prägte den Begriff **Cargo-Cult Software Engineering**: Organisationen, die die sichtbaren Formen erfolgreicher Teams nachahmen (die Prozesse, die Patterns, die Meetings), ohne zu verstehen, warum diese Formen bei irgendjemandem je funktioniert haben. Das Erkennungszeichen, schrieb McConnell, ist die Begründung: „Das haben wir schon immer so gemacht“ oder „unsere Standards verlangen das“. Gründe, die auf ein Regelwerk zeigen statt auf ein Ergebnis. Das ist die ganze Krankheit in einem Satz. Sobald man eine Praxis nicht mehr damit begründen kann, was sie liefert, sondern nur noch damit, was die Regeln fordern, hat man die Ingenieurskunst verlassen und die Schriftauslegung betreten. ## Dann machte Agile aus „get it done“ eine Zeremonie Über Velocity-Theater habe ich an anderer Stelle geschrieben, also fasse ich mich kurz. Agile begann als Korrektur: funktionierende Software ausliefern, schnell Rückmeldung holen. Dann fraß die Branche es auf. Aus dem Standup wurde ein Status-Ritual. Aus der Retro eine Therapiestunde. Aus Story Points eine Währung, die niemand in Geld oder Zeit umrechnen kann. SAFe machte aus dem Ganzen ein Organigramm. Das Manifest wurde zur Religion und die Zertifizierungsindustrie zu ihrer Kirche, die den Ablass im Zwei-Tage-Takt verkauft. Und ein feinerer Wandel kam mit: Das Ziel verschob sich leise von *wird die Arbeit fertig* zu *wie geht es dem Team damit*. Das sind nicht dieselben Fragen. Beide zählen, aber nur eine ist die Aufgabe. ## Das Problem der Bequemen, die falsch liegen Jetzt wird es unpopulär. Der herrschende Rat lautet, den „brillanten Kotzbrocken“ zu entfernen, um die psychologische Sicherheit des Teams zu schützen. Manchmal ist das genau richtig; niemand arbeitet gut in einem Raum, vor dem er Angst hat, und Talent ist kein Freibrief für Grausamkeit. Aber eine Kultur, die *nur* auf Bequemlichkeit optimiert, hat einen Fehlermodus, den niemand gern benennt: Sie schützt den Angenehmen, der falsch liegt, vor dem Unbequemen, der recht hat. Sie stellt Dazugehören über Richtigsein. Und ausgerechnet das Kriterium, das früher jeden Streit entschied („funktioniert es“), ist das, das den Leuten unbequem ist, weil es sie öffentlich widerlegen kann. Man kann auf Anstand bestehen und trotzdem die harte Frage voranstellen. Der Filter, der zählt, lautet: Hast du recht, und lieferst du? „Sitzt es sich angenehm neben dir?“ kommt danach. Verdreht man die Reihenfolge, optimiert man ein Soziologie-Seminar, kein Entwicklungsteam. ## Das sauberste Freiluftexperiment der Branche Man muss das nicht theoretisch ausfechten. Die Autoindustrie hat das Experiment für uns gemacht. Volkswagen gründete CARIAD 2020, um das Rennen um das softwaredefinierte Auto zu gewinnen. Nach den eigenen Zahlen wurde es ein Desaster: berichtete operative Verluste von über 7,5 Milliarden Dollar in drei Jahren, die Software-Plattform 1.2 um 16 bis 18 Monate verspätet und den Porsche Macan sowie den Audi Q6 e-tron blockierend, die nächste Plattform Richtung 2027 oder 2028 verschoben. Eine im Konzern beauftragte McKinsey-Prüfung fand Berichten zufolge ein Dutzend Probleme, allen voran, dass die Beteiligten schlicht nicht miteinander kommunizieren konnten. Meetings, PowerPoint, Organigramm, Altlast: die volle Zeremonie. Tesla, ein paar Straßen weiter, ist die Software-first-Firma, der jetzt alle hinterherlaufen. Flach, ergebnisbesessen, unbeeindruckt vom Ritual. Man kann vieles an der Führung dort unsympathisch finden und trotzdem das Muster erkennen: Die Organisation, die weiter fragte „liefert es, funktioniert es“, hängte die ab, die den Prozess perfektionierte. Der Produktivitätsunterschied ist ein Unterschied bei den First Principles, kein Ritual-Unterschied. ## Die Zeremonie kommt auch für die KI Agentisches Programmieren ist ein echter Produktivitätssprung. Wir sehen es jeden Tag; der Agent schreibt, der Mensch orchestriert, und der Durchsatz ist unübersehbar. Und die Zeremonie bildet sich längst darum. „KI-Governance-Ausschüsse“ und „Prompt-Governance“ sind inzwischen feste Begriffe: Freigabestufen, Versionierung und Auditierung von Prompts, Kontrollen mit Zuordnung zum EU AI Act und zu ISO 42001, dazu Zertifikate im Prompt Engineering zum Einsammeln. Manches davon ist wirklich nötig: Sicherheit und Compliance sind nicht optional. Aber darunter läuft derselbe Reflex: Aus einer Fähigkeit wird ein Prozess, aus dem Prozess ein Ausschuss, aus dem Ausschuss ein Zertifikat. Berichte beschreiben bereits Unternehmen, die monatelang an KI-Governance-Rahmenwerken gebaut haben, nur um festzustellen, dass sich nichts geändert hat. Stapelt man genug davon auf einen Faktor drei, ist man wieder bei Faktor eins, mit mehr Meetings. Die Produktivität ist real; die Lust, sie wegzubürokratisieren, ist es auch, und sie ist besser finanziert. Die einzige Verteidigung ist die alte Frage, unerbittlich gestellt: Läuft das Ding, ist es schnell, ist es sicher, ist es ausgeliefert? Alles, was sich davor nicht rechtfertigen kann, ist Zeremonie, so vernünftig es auch klingt. ## Was wir tatsächlich tun Deshalb ist unser Hard-Agile eine Verweigerung, keine Methode mit Logo. Wir messen Durchsatz, Zykluszeit und Fluss (was ausgeliefert wird und wie schnell), weil das die Zahlen sind, die die Realität prüft, nicht die, die ein Team sich selbst gibt. Wir sind nicht da, um Ihre Rituale abzuhalten oder Ihre Patterns zu benoten. Wir sind da, um die Sache zum Laufen zu bringen, sie schnell zu machen und zu gehen, wenn Ihr Team sie so halten kann. Software war nie als Geisteswissenschaft gedacht. Sie hatte das Seltenste, was ein Fach haben kann: einen harten, ehrlichen, äußeren Test, ob man recht hatte. Das ist es wert, verteidigt zu werden. Alles andere ist Deutung. --- # When Software Engineering Became a Humanities Degree - URL: https://100days.de/en/insights/engineering-humanities/ - Language: English - Published: 2026-08-13 - Audience: CTOs / engineering leaders - Summary: Software had one hard question: does it work? Then we replaced it with dogma, ritual and ceremony, and called it progress. A first-principles case against cargo-cult engineering. ## The Exam That Taught Me the Wrong Lesson I studied computer science with a minor in sociology. My worst grades were in sociology, and it took me years to understand why. The exams were multiple choice. Four or five options, and the wording between them varied so little that the meaning barely changed from one to the next. But one was correct and the rest were wrong. What the test measured was not whether you understood how societies work. It was whether you could tell, at the level of individual words, which sociologist a sentence belonged to. This is not sociology failing at science. It is the humanities being the humanities: a different discipline, with a different test, or rather without the sciences' test at all. Nothing external settles the argument; you cannot run the experiment that proves one thinker right and the next one wrong. So the thing you actually master is the map: which school holds what, where two thinkers part ways, how to place a sentence at the level of a single word. The models are partial, each one works only sometimes, and the craft is telling them apart. It is real intellectual work. But it is a craft of distinguishing between models, not of producing thought: you learn to separate other people's ideas with razor-sharp precision, without ever being asked to add one of your own. I bring this up because software engineering used to be the opposite. And it is quietly becoming the same thing. ## Software Had One Hard Question Your code has to work. That was the criterion. Ideally fast, ideally secure, depending on what you were building. But underneath everything sat a test that reality ran for you: it works, or it doesn't. You could be junior, arrogant, self-taught, hard to be around; it didn't matter. The compiler and the 3 a.m. incident did not care about your reputation. First principles, checked against the world. Then we started proclaiming design patterns and "clean code." Not as tools but as virtue. On the premise, never actually proven, that following these rules produces better maintainability and fewer defects. Maybe it does. Sometimes it does. But notice what happened to the criterion: it stopped being "does it work" and became "did you implement it the way the book says." That is a different kind of question. It has a canon. It has schools. It has people who can quote Uncle Bob chapter and verse and tell you your perfectly working function is wrong because it has four parameters instead of three. The measure moved from the world into the text. ## Cargo Cult, Named in 2000 Steve McConnell saw this coming a quarter of a century ago. In IEEE Software in 2000 he borrowed Richard Feynman's "cargo cult science" and coined **cargo cult software engineering**: organizations that imitate the visible forms of successful teams (the processes, the patterns, the meetings) without understanding why those forms ever worked for anyone. The tell, McConnell wrote, is the justification: "we've always done it this way," or "our standards require it." Reasons that point at a rulebook instead of a result. That is the whole disease in one sentence. When you can no longer defend a practice by what it delivers, only by what the rules demand, you have left engineering and entered scripture. ## Then Agile Turned "Get It Done" Into a Ceremony I've written before about velocity theater, so I'll be quick. Agile began as a correction: ship working software, get feedback fast. Then the industry ate it. The standup became a status ritual. The retro became a therapy hour. Story points became a currency nobody can convert into money or time. SAFe turned the whole thing into an org chart. The manifesto became a religion, and the certification industry became its church, selling indulgences two days at a time. And a subtler shift rode in with it: the goal moved, quietly, from *does the work ship* to *how does everyone feel about the work*. Those are not the same question. Both matter, but only one of them is the job. ## The Comfortable-and-Wrong Problem Here is where it gets unpopular. The dominant advice is to remove the "brilliant jerk" to protect the team's psychological safety. Sometimes that is exactly right; nobody does their best work in a room they are afraid of, and talent is not a licence to be cruel. But a culture that optimizes *only* for comfort has a failure mode nobody likes to name: it protects the person who is pleasant and wrong over the person who is difficult and right. It rewards fitting in over being correct. And the one criterion that used to settle every argument, does it work, is exactly the one that makes people uncomfortable, because it can prove them wrong in public. You can insist on basic decency and still keep the hard question first. The filter that matters is: are you right, and do you deliver. "Easy to sit next to" comes second. Invert that order, and you are optimizing a sociology seminar, not an engineering team. ## The Cleanest Natural Experiment in the Industry You don't have to argue this in the abstract. The car industry ran the experiment for us. Volkswagen built CARIAD in 2020 to win the software-defined car. By its own numbers it has been a disaster: operating losses reported north of $7.5 billion in three years, its 1.2 software platform delayed by 16 to 18 months and holding up the Porsche Macan and Audi Q6 e-tron, the next platform pushed toward 2027 or 2028. A McKinsey review commissioned inside the group reportedly found a dozen problems, chief among them that the various parties simply could not communicate with each other. Meetings, PowerPoint, org structure, legacy load: the full ceremony. Tesla, across town, is the software-first company everyone else is now chasing. Flat, results-obsessed, indifferent to the ritual. You can dislike a great deal about how it is run and still see the pattern: the organization that kept asking "does it ship, does it work" outran the one that got very good at process. The productivity gap is a first-principles gap, not a rituals gap. ## The Ceremony Comes for AI Too Agentic coding is a real jump in productivity. We see it every day; the agent writes, the human orchestrates, and the throughput is not subtle. The ceremony is already forming around it. "AI governance committees" and "prompt governance" are real, named things now: approval gates, prompt versioning and auditing, controls mapped to the EU AI Act and ISO 42001, and prompt-engineering certificates to collect. Some of this is genuinely necessary: security and compliance are not optional. But the same reflex runs underneath: turn a capability into a process, the process into a committee, the committee into a certificate. Reports already describe organizations that spent months building AI-governance frameworks only to find that nothing actually changed. Stack enough of that on top of a 3x and you are back to 1x, with more meetings. The productivity is real; the appetite to bureaucratize it away is real too, and better funded. The only defense is the old question, asked relentlessly: does the thing work, is it fast, is it secure, did it ship? Everything that cannot justify itself against that is ceremony, however reasonable it sounds. ## What We Actually Do This is why our Hard-Agile is a refusal rather than a methodology with a logo. We measure throughput, cycle time and flow (what ships and how fast) because those are the numbers reality checks, not the ones a team hands itself. We are not here to run your rituals or grade your patterns. We are here to make the thing work, make it fast, and leave when your team can keep it that way. Software was never meant to be a humanities degree. It had the rarest thing a field can have: a hard, honest, external test of whether you were right. That is worth defending. Everything else is interpretation. --- # Bots haben Menschen überholt. Als Nächstes fällt das Geschäftsmodell des Internets. - URL: https://100days.de/de/insights/agentic-web/ - Language: German - Published: 2026-08-10 - Audience: PE/VC investors - Summary: Mehr als die Hälfte des gesamten Datenverkehrs im Internet ist inzwischen nicht-menschlich, und KI crawlt Inhalte, ohne Leser zurückzuschicken. Die Such- und Werbeökonomie, die das offene Internet finanziert hat, bricht. Wohin der Wert wandert, und wie man das im Portfolio liest. ## Eine Grenze ist überschritten, und sie trifft das Geschäftsmodell des Internets Seit es das Internet gibt, waren es Menschen, die seine Inhalte und seine Kommunikation ausmachten. Man baute eine Seite, und Menschen kamen, um sie zu lesen. Das ist vorbei. In seinem neuen Bericht *Content Independence Day, one year on* meldet Cloudflare (über dessen Netz mehr als 20 % des Internets laufen und das deshalb wirklich zählen kann), dass der Datenverkehr der Agenten eine historische Schwelle überschritten hat: Mehr als die Hälfte des gesamten Datenverkehrs im Internet ist inzwischen nicht-menschlich. Cloudflare selbst schreibt, die Verschiebung sei schneller gekommen als erwartet. Wer das für eine Kuriosität hält, verkennt, was hier geschieht: Es ist der Moment, in dem das Geschäftsmodell des Internets nicht mehr zu seinem Datenverkehr passt. Und wenn die Ökonomie einer Plattform bricht, wandert der Wert. Für jeden, der Kapital anlegt, lautet die interessante Frage: „Wohin wandert der Wert, und welche meiner Unternehmen stehen am falschen Platz?“ ## Der Tausch, der das Internet finanziert hat, bricht Das offene Internet beruhte auf einem einzigen Tauschgeschäft, ob es nun jemand aufschrieb oder nicht. Sie veröffentlichen Inhalte. Suchmaschinen crawlen sie. Im Gegenzug schicken sie Ihnen Menschen. Die Menschen sehen Werbung, kaufen Produkte, werden Kunden. Crawl rein, Besucher zurück. Dieser Kreislauf finanzierte Journalismus, Dokumentation, Bewertungen, Foren. Das meiste, was lesenswert ist. KI-Agenten haben den Kreislauf durchtrennt. Sie crawlen die Inhalte und schicken fast nichts zurück. Der Bericht ist unmissverständlich. Im Juni 2026 dienen 52 % der Crawler-Anfragen dem KI-Training (ein Jahr zuvor waren es 22 %), während das reine Such-Crawling, das früher Besucher zurückbrachte, nur noch einen kleinen, schrumpfenden Anteil ausmacht. Zugleich versickert die Aufmerksamkeit der Menschen: Von jeder Stunde, die sie mit der Informationssuche verbringen, entfallen nur noch 15 Minuten auf das offene Internet. Der Rest löst sich in einer KI-Antwort auf. Die Quelle bekommt einen Trainingsdurchlauf und keinen Klick. > Das alte Internet schickte Ihnen Besucher im Tausch gegen Ihre Inhalte. Das agentische Internet nimmt die Inhalte und behält den Besucher. Das ist kein Medienproblem. Es begann bei Nachrichten und Medien, aber Cloudflare berichtet, dass einige der am stärksten gecrawlten Kategorien (Handel, Software, IT, Finanzwesen) in weniger als einem Jahr bereits bis zu 40 % ihrer menschlichen Besucher verloren haben. Verlage stellen sich inzwischen auf „Google Zero“ ein: eine Welt, in der praktisch keine Besucher mehr über Suchverweise kommen. Die Annahme über den Vertriebsweg, die unter sehr vielen Geschäftsplänen steckt, hat sich gerade geändert: leise, ohne dass der Plan aktualisiert wurde. ## Der Torwächter Hier steckt ein Konzentrationsrisiko, das ein Investor nicht übersehen sollte. Auf Google entfallen weiterhin rund 88 % aller Verweise: Es ist *das* Tor. Doch Google beantwortet Suchanfragen zunehmend in seinen eigenen KI-Oberflächen, statt den Klick weiterzureichen. Und anders als andere KI-Firmen, bei denen sich Such- und Trainings-Crawler getrennt freigeben oder sperren lassen, betreibt Google einen einzigen Bot für beide Zwecke: Man bleibt nicht in Googles Suchindex, ohne zugleich Googles KI zu füttern. Cloudflare schätzt, dass Google dadurch auf etwa doppelt so viele Inhalte zugreift wie andere KI-Firmen. Der Kanal, von dem ein großer Teil des Internets bei der Auffindbarkeit weiterhin abhängt, ist also derselbe, der den Besuch still aufsaugt. Das ist kein gestreutes Risiko. Für jedes Unternehmen, dessen Wachstum auf organischen Zugriffen über Google ruht, ist es eine einzelne, kritische Abhängigkeit von einem Kanal, der sich gerade gegen die Besucher wendet, die er selbst liefert. ## Das Internet wird für Maschinen umgebaut Und jetzt wird aus der Bedrohung eine Landkarte. Um die neue Realität bildet sich ein Markt, und Cloudflares Daten aus dem ersten Jahr zeigen seine Form: Transparenz schuf Knappheit, Knappheit schuf Verhandlungsmacht, und Verhandlungsmacht bringt jetzt Lizenzverträge. Seit 2023 wurden mehr als 50 Lizenzvereinbarungen zwischen Verlagen und KI-Firmen geschlossen, und die Debatte hat sich verschoben: von *ob* Inhalte bezahlt werden zu *wie*. Wenn Agenten der Kunde sind, fließt der Wert nicht mehr dem zu, der die Aufmerksamkeit der Menschen gewinnt, sondern dem, um den die Agenten nicht herumkommen: - **Proprietäre Daten, die eine Lizenz wert sind.** Wenn ein Modell Ihren Inhalt braucht und ihn nirgends sonst zusammensetzen kann, haben Sie Preismacht im neuen Markt. Ist Ihr Inhalt Massenware, wurden Sie immer nur in Reichweite bezahlt, und die Reichweite geht. - **Die Antwortebene sein, nicht ihr Zulieferer.** Das Produkt, das ein Agent *aufruft* (eine API, ein Echtzeit-Bestand, ein Transaktions-Endpunkt), schöpft den Wert ab. Die Seite, die ein Agent *liest und wegwirft*, tut es nicht. - **Maschinenlesbarer Handel.** Agenten, die buchen, kaufen und abwickeln, brauchen Bezahlprozess, Authentifizierung und Identität, die für sie gebaut sind, nicht für einen Menschen, der auf ein Formular starrt. Cloudflare sagt ausdrücklich, dass die nächste Phase neue Infrastruktur für Berechtigungen, Lizenzierung und Transaktionen im großen Maßstab braucht, und die ist heute dünn. - **Marke und direkte Beziehungen.** Die eine Nachfrage, die ein Agent nicht umgehen kann, ist der Kunde, der gezielt Ihretwegen kam. Ein eigenes Publikum ist keine Kür mehr, sondern der Burggraben. ## Die Frage für die Due Diligence Für einen Investor verdichtet sich das zu einer unbequemen Frage über jedes Unternehmen, das mit dem Internet zu tun hat: **Ist es dafür gebaut, von einem Menschen mit einem Browser genutzt zu werden oder von einem Agenten mit einer API?** Lautet die Antwort „Mensch mit Browser“, und stützt sich das Wachstum auf die organische Suche oder auf Zugriffe aus Verweisen, dann finanzieren Sie einen Vertriebsweg, der zusehends erodiert, und die Erosion zeigt sich nicht in den Zahlen dieses Quartals, was sie gerade gefährlich macht. Die Kennzahlen sehen gut aus, bis kurz bevor die Basis der Verweise nachgibt. Die schärfere Prüfung ist konkret. Welcher Anteil der Neukundengewinnung hängt an der organischen Google-Suche, und weichen diese Zugriffe bereits auf, während KI-Antworten die Suchanfragen aufsaugen? Ist der Inhalt des Unternehmens ein lizenzierbares Gut oder Massenware, die gratis abgegriffen wird? Lässt sich sein Produkt von einem Agenten *aufrufen*, oder nur von einem Menschen bedienen? Misst überhaupt jemand im Team, wie viele Zugriffe von Bots statt von Menschen kommen, oder sind Maschinen längst ein wachsender Teil der „Interaktion“, unsichtbar fürs Team? Jetzt die ehrliche Einschränkung, denn das wird in beide Richtungen überverkauft. Cloudflare sagt es unumwunden: Lizenzierung ist heute Maßarbeit im Einzelfall und werde die verlorenen Einnahmen aus Verweisen, Werbung und Affiliate wohl nicht vollständig ersetzen; und wie viel ein Inhalt wert ist, ist weiter ungeklärt. Menschen kaufen weiterhin. Marke wirkt weiterhin. Die neuen Spielregeln sind noch nicht ausgemacht, und wer sich bei Lizenzierung, Protokollen und Agenten-Handel durchsetzt, steht nicht fest. Das Risiko ist real, aber der Zeitpunkt ist kein Schalter, sondern ein Gefälle. Darauf zu wetten, der Zusammenbruch komme schon nächstes Quartal, ist genauso falsch wie die Annahme, er komme nie. Die Aufgabe ist, die Richtung zu bewerten und den Zeitpunkt ehrlich einzupreisen. ## Warum das unsere Arbeit ist Wenn wir die Entwicklungsorganisation eines Portfoliounternehmens beurteilen, ist das kein abstrakter Makrotrend mehr, sondern ein Prüfpunkt in der technischen Due Diligence. Ist das Produkt für das agentische Internet gebaut oder für das menschliche? Lässt es sich von einer Maschine aufrufen, lizenzieren, bezahlen, oder ruht seine gesamte Distribution auf einer Verweis-Schleife, die dünner wird? Das sind Ingenieursfragen mit Folgen für die Bewertung, und die meisten Due-Diligence-Prozesse stellen sie nie. Wir tun beides. Wir bewerten die Entwicklungsorganisation daraufhin, ob sie für das Internet von morgen gebaut ist. Und dann bauen wir, mit demselben Team im selben Engagement, die Fähigkeit auf, sie dorthin zu bringen. Kein Bericht, der das Risiko benennt und wieder geht. Hundert Tage Arbeit an der Seite des Teams, damit das Produkt etwas wird, das ein Agent erreichen kann, und damit diese Fähigkeit bleibt, wenn wir gehen. Das Internet wird für Maschinen neu gebaut. Die Portfolios, die die Verschiebung früh lesen und sich bewusst darauf umrüsten, werden das nächste Jahrzehnt bestimmen. Die, die weiter für einen Menschen optimieren, der nicht mehr klickt, nicht. --- # Ein Vektor reicht nicht: Wo die Embedding-Suche an ihre Grenze stößt - URL: https://100days.de/de/insights/vectors-are-not-enough/ - Language: German - Published: 2026-08-10 - Audience: CTOs / engineering leaders - Summary: Google DeepMind hat bewiesen: Ein einzelner Embedding-Vektor hat eine harte Obergrenze. Die Dimension begrenzt, was er finden kann, und kein Training verschiebt sie. Was das für Ihren RAG-Stack bedeutet und wo lexikalische Suche, Late Interaction und Wissensgraphen ins Spiel kommen. ## Der Vektor hat eine Obergrenze. Jemand hat sie gemessen. Letztes Mal haben wir geschrieben, dass eine Überzeugung ein Vektor ist: Ein Konzept im Modell hat Koordinaten, auf die man zeigen kann. Das stimmt, und es ist mächtig. Aber ein Vektor ist auch etwas weniger Schmeichelhaftes: eine Kompression. Eine einzige Liste von Zahlen, die für etwas viel Reicheres einsteht. Und Kompression hat Grenzen. Ein Team von Google DeepMind und der Johns Hopkins University hat gerade eine dieser Grenzen vermessen, und das Ergebnis sollte ändern, wie Sie Suche bauen. Die Publikation trägt den Titel *On the Theoretical Limitations of Embedding-Based Retrieval* (ICLR 2026, arXiv:2508.21038). Ihr Befund lautet nicht „Embeddings könnten besser sein", sondern: „Embeddings können das beweisbar nicht, und ein größeres Modell zu kaufen hilft nicht." ## Was sie bewiesen haben Fast jedes RAG-System in Produktion arbeitet gleich. Jedes Dokument wird zu einem Vektor, die Anfrage wird zu einem Vektor, zurück kommen die Dokumente, deren Vektoren am nächsten liegen. Ein Vektor, ein Skalarprodukt, fertig. Das ist schnell, verallgemeinert gut und trägt die gesamte Branche. Die Publikation stellt eine schlichte Frage: Kann dieser Aufbau *jede* Kombination von Relevanz abbilden? Lässt sich ein Ein-Vektor-Modell dazu bringen, aus einer Menge von Dokumenten jede beliebige Teilmenge als Top-Treffer zurückzugeben? Die Antwort ist nein, und die Obergrenze ist die Dimension des Embeddings. Trägt man in ein großes Raster ein, welche Dokumente für welche Anfragen relevant sind, dann ist die Zahl der verschiedenen „Top-k"-Muster, die eine Menge von Vektoren erzeugen kann, durch die Anzahl der Zahlen pro Vektor begrenzt. Jenseits dieses Punktes sind bestimmte Relevanzmuster nicht bloß unwahrscheinlich; sie sind unerreichbar. Kein Trainingslauf, keine Datenmenge, kein Kniff innerhalb des Ein-Vektor-Paradigmas führt Sie dorthin. Dann haben sie es beziffert. Selbst im günstigsten denkbaren Fall (die Vektoren direkt gegen die Testantworten optimiert, ohne jede Einschränkung durch echte Sprache) ist ein 512-dimensionales Embedding bei rund 500.000 Dokumenten am Ende. Ein 1024-dimensionales bei etwa 4 Millionen. Selbst ein 4096-dimensionales Embedding, größer als die meisten Produktivsysteme fahren, reicht nur bis knapp 250 Millionen. Und das ist die großzügige Grenze; echte Modelle, die zusätzlich noch tatsächliche Sprache abbilden müssen, bleiben weit darunter. [Figure: Nur der beste Fall: Die Vektoren werden direkt gegen die Antworten optimiert. Echte Embedding-Modelle, die zusätzlich Sprache abbilden müssen, bleiben weit unter dieser Linie. Quelle: Weller et al., arXiv:2508.21038.] > Embeddings scheitern hier nicht, weil sie schlecht trainiert wurden. Sie scheitern, weil Sie von einer festen Zahl an Dimensionen verlangen, mehr Unterscheidungen zu kodieren, als darin Platz haben. ## Der Teil, der Ihnen Sorgen machen sollte Theorie lässt sich leicht abtun. Also bauten die Autoren LIMIT: einen Datensatz, so einfach, dass er wie ein Scherz wirkt. Kurze Aussagen in natürlicher Sprache: „Jon mag Quokkas und Äpfel." Eine triviale Frage: „Wer mag Quokkas?" Der einzige Kniff: Der Datensatz deckt systematisch viele Kombinationen ab, wer was mag. Die modernsten Embedding-Modelle scheitern daran. Deutlich. Eine Aufgabe, die ein Kind löst, und die besten dichten Retriever der Welt bekommen sie nicht hin. BM25 dagegen, der langweilige Stichwort-Algorithmus aus den Neunzigern, kommt der perfekten Lösung nahe. Und ein Mehrvektor-Modell schlägt die Ein-Vektor-Modelle mit großem Abstand. Es liegt nicht an der Domäne. Es lässt sich auch nicht mit mehr Trainingsbeispielen beheben; die Autoren haben es geprüft. Die einfache Aufgabe liegt grundsätzlich jenseits dessen, was ein einzelner Vektor pro Dokument abbilden kann. Warum das über einen Benchmark hinausreicht: Die ganze Branche treibt die Suche Richtung *Allgemeingültigkeit*: „bilde jede Anfrage ab, jede Definition von Relevanz", anweisungsbasierte Suche, Suche, die schlussfolgert. Genau in dieser Richtung liegt die Obergrenze. Enge, natürliche Anfragen bleiben unproblematisch, deshalb lief Ihr RAG-Prototyp. Verlangen Sie vom selben System beliebige logische Kombinationen von Relevanz, laufen Sie geradewegs gegen eine Wand, die sich durch bloßes Skalieren nicht verschieben lässt. ## Was Sie stattdessen einsetzen „Ein Vektor reicht nicht" nützt nur, wenn ein nächster Zug dazugehört. Es gibt mehrere, und die ehrliche Antwort lautet: Keiner ist ein direkter Ersatz; jeder erkauft Ausdruckskraft mit anderen Kosten. **Dünnbesetzte, lexikalische Suche (BM25, SPLADE).** Der älteste Trick schlug bei LIMIT den neuesten. Der exakte Begriffsabgleich hat keine Dimensionsgrenze und ist billig. Die Lehre der letzten beiden Jahre: Die lexikalische Suche wurde zu früh aussortiert. In fast jedes ernsthafte System gehört sie hinein. **Mehrvektor, Late Interaction (ColBERT, ColPali).** Statt eines Vektors pro Dokument behält man einen pro Token und vergleicht sie erst zur Anfragezeit (MaxSim). Deutlich ausdrucksstärker als ein einzelner Vektor, mit einem Nebeneffekt: Man sieht, welche Tokens übereinstimmten, die Suche ist keine Blackbox mehr. Der Preis sind Speicher und Rechenzeit (Tausende Vektoren pro Dokument), weshalb man damit in der Praxis eine Vorauswahl neu sortiert, statt den ganzen Bestand zu durchsuchen. **Cross-Encoder.** Die ausdrucksstärkste Ähnlichkeit überhaupt: Anfrage und Dokument laufen gemeinsam durch das Modell. Auch die teuerste: Sie bewertet ein Paar nach dem anderen und taugt darum als letzte Stufe über einer kurzen Liste, nie als erste Suche über den ganzen Bestand. ## Wo Wissensgraphen ins Spiel kommen Alle bisherigen Alternativen fragen weiterhin: „Welcher Text ähnelt dieser Anfrage?" Ein Wissensgraph stellt eine ganz andere Frage: „Wie hängen diese Dinge zusammen?" Statt ein Dokument in einen Vektor aufzulösen, zieht man seine Entitäten und die Beziehungen zwischen ihnen heraus und legt beides als ausdrückliche Knoten und Kanten ab. Jon *mag* Quokkas. Quokkas *leben in* Australien. Australien *ist ein* Land. Jetzt kann eine Anfrage dem Graphen folgen: von Kante zu Kante springen, von Fakt zu Fakt, und Fragen beantworten, die kein Ähnlichkeitswert beantwortet, weil die Antwort in genau der Struktur steckt, die ein einzelner Vektor wegwirft. Darauf bauen GraphRAG und seine leichteren Verwandten (LightRAG, LazyGraphRAG). Wo Graphen wirklich gewinnen: bei mehrstufigen Fragen („Welche unserer Lieferanten hängen von einem Anbieter in einer sanktionierten Region ab?"), bei der Zusammenschau über viele verknüpfte Dokumente und bei der Eindeutigkeit: Ein Knoten trägt seine Beziehungen bei sich, also sind „Jaguar, das Tier" und „Jaguar, das Auto" schlicht verschiedene Knoten und nicht zwei Kollisionen im selben Embedding. Jetzt der ehrliche Teil, denn auch Wissensgraphen werden überverkauft. Den Graphen zu bauen ist echte Arbeit: Die Entitäten zieht ein LLM heraus, und dieser Schritt halluziniert und muss nachkorrigiert werden. Früher waren die berichteten Vorteile aufgebläht: Eine 2026 um Verzerrungen bereinigte Analyse fand, dass schlichtes RAG eine beliebte GraphRAG-Variante leicht *schlug*, sobald man undichte Stellen in der Auswertung ausschloss. Und die unangenehme Zahl der Branche: Die meisten RAG-Projekte im Unternehmen gehen nie in Produktion, und der Aufwand für den Graphenbau ist dabei ein Wiederholungstäter. Neu ist 2026, dass die Kosten fürs Indizieren stark gefallen sind; LightRAG und LazyGraphRAG indizieren inzwischen etwa zum Preis von reinem Vektor-RAG. Die verbleibende Frage ist also Passung, nicht Budget. **Nachtrag, September 2026.** Zur Frage der Passung liegen inzwischen Zahlen vor. Eine Publikation der Toronto Metropolitan University (arXiv:2608.28978) baut ein graphbasiertes Gedächtnis für Agenten mit langer Laufzeit und misst es bei gleichem Suchbudget gegen eine flache Vektorsuche: 0,417 gegen 0,468 F1, der Graph liegt hinten. Fast der gesamte Abstand geht auf eine einzige Frageart zurück. Soll eine frühere Antwort wörtlich wiedergegeben werden, fällt die bewertete Korrektheit von 0,911 auf 0,607. Der Grund liegt in der Bauart, denn wer einen Beitrag in Entitäten und Beziehungen zerlegt, wirft die Oberflächenform weg, an der solche Fragen hängen. Die Autoren schränken selbst ein, dass sie ein einzelnes kleines Extraktionsmodell auf einem Benchmark geprüft haben. Für die Faustregel unten kommt damit ein dritter Fall dazu: Neben exakter und kombinatorischer Relevanz verliert ein Graph auch dort, wo es auf den Wortlaut ankommt. Der pragmatische Konsens ist unspektakulär und richtig: **Schöpfen Sie zuerst die hybride Suche aus.** BM25 plus dichte Vektoren, zusammengeführt, mit einem Reranker obendrauf, schlägt in Praxistests jede einzelne Methode um 15 bis 30 Prozent bei der Trefferquote. Zum Wissensgraphen greifen Sie erst, wenn Ihre Fragen wirklich die Zusammenschau über verknüpfte Fakten verlangen, und keinen Moment früher. ## Wann ein Vektor genau richtig ist Nichts davon heißt, dass Embeddings ein Fehler waren. Für eine große Klasse von Problemen sind sie das richtige Werkzeug, und zu wissen, welche Klasse das ist, ist die eigentliche Kunst. Ein einzelner Vektor glänzt, wenn Relevanz heißt: *"semantisch ähnlich zu dieser einen Anfrage"*, Dokument für Dokument bewertet. Das deckt eine Menge echter, produktiver Arbeit ab: - **Unscharfe Suche, die Wortlücken überbrückt.** „Wie kündige ich meinen Tarif?" findet eine Seite mit dem Titel „Abo beenden": kein gemeinsames Stichwort, gleiche Bedeutung. Genau das verfehlt BM25, und genau das treffen Embeddings. Dropbox senkte damit die ergebnislosen Suchen um rund 17 %; Support-Werkzeuge wie Zendesk verbesserten damit handfeste Kennzahlen. - **Empfehlungen und „mehr davon".** Ähnliche Produkte, verwandte Artikel, Lebenslauf zu Stellenanzeige, Dublettenerkennung. Hier *ist* Relevanz tatsächlich Ähnlichkeit, also ist ein Ähnlichkeitswert das richtige Mittel. - **Breite erste Trefferauswahl.** Ein paar Hundert plausible Kandidaten billig aus Millionen herausziehen, bevor eine langsamere, schärfere Stufe die genaue Arbeit macht. Der Unterschied ist einfach. Die Vektorsuche gewinnt, wenn Relevanz **semantisch** ist, **einem einzigen Begriff** folgt und **pro Dokument** entschieden wird: Jedes Ergebnis verdient seinen Platz aus eigener Kraft, über die Bedeutung. Sie bricht, wenn Relevanz **exakt** ist (eine Teilenummer, ein Fehlercode, ein Name; semantische Drift macht aus „Python 3.11 Performance" allgemeine Python-Tipps), **kombinatorisch** (Sie brauchen eine bestimmte *Menge*, das Versagen bei LIMIT) oder **relational** (die Antwort ergibt sich aus Verbindungen: der Fall für den Wissensgraphen). Entscheidend ist die Frage: „Was bedeutet Relevanz für diese Anfrage?" Passt das Werkzeug zur Antwort, ist ein Vektor oft alles, was Sie brauchen. ## Die eigentliche Verschiebung Die Ära „alles in eine Vektordatenbank kippen und ausliefern" endet für ernsthaftes Retrieval. Für die breite erste Trefferauswahl bleiben Vektoren großartig; das Problem ist, dass eine einzige Repräsentation nie jede Art von Frage tragen konnte. Diese Arbeit ist der Beweis, dass die Obergrenze real ist, Koordinaten hat und sich nicht darum schert, wie viel Sie für ein größeres Embedding-Modell ausgeben. Retrieval wird wieder zur Architekturentscheidung. Lexikalisch für exakte Begriffe. Dichte Vektoren für die breite Trefferauswahl. Late Interaction für Präzision. Ein Graph für Struktur. Mit Absicht zusammengesetzt, passend zu der Relevanz, die Ihr Produkt wirklich braucht, und nicht automatisch das, was Ihnen der Schnellstart der Vektordatenbank vorgesetzt hat. ## Warum wir das verfolgen Wenn wir für einen Kunden eine Suche bauen, greifen wir nicht reflexhaft zur Vektordatenbank und hoffen auf das Beste. Wir sehen uns die Fragen an, die das System tatsächlich beantworten muss, schätzen ab, wo die Ein-Vektor-Grenze zuschlagen würde, und setzen den Stack zusammen, der passt: lexikalisch, dicht, Late Interaction, Graph, in welcher Kombination das Problem es rechtfertigt. Das ist der Unterschied zwischen dem Abarbeiten eines Schnellstarts und dem Konstruieren eines Systems. Ein Vektor ist eine mächtige Sache. Genau zu wissen, wo er aufhört zu genügen, ist die eigentliche Arbeit. --- # Bots Passed Humans. The Web's Business Model Is Next. - URL: https://100days.de/en/insights/agentic-web/ - Language: English - Published: 2026-08-10 - Audience: PE/VC investors - Summary: More than half of all web traffic is now non-human, and AI crawls content without sending readers back. The search-and-ad economy that funded the open web is breaking. Where the value moves next, and how to read it in a portfolio. ## A Line Got Crossed, and It Is a Business-Model Event For the whole history of the web, humans were the traffic. You built a page, people came to read it. That is over. In its new report *Content Independence Day, one year on*, Cloudflare, which sits in front of more than 20% of the web and can actually count, reports that agent traffic has crossed a historic threshold: more than half of all traffic on the Internet is now non-human. Cloudflare's own line is that the shift happened faster than they anticipated. Treat that as a curiosity and you miss the point: this is the moment the web's business model stopped matching the web's traffic. And when the economics of a platform break, value moves. For anyone allocating capital, the interesting question is "where does the value go, and which of my companies are standing in the wrong place?" ## The Exchange That Funded the Web Is Breaking The open web ran on one deal, whether or not anyone wrote it down. You publish content. Search engines crawl it. In return, they send you humans. The humans see ads, buy products, become customers. Crawl in, traffic back. That loop paid for journalism, documentation, reviews, forums. Most of what is worth reading. AI agents broke the loop. They crawl the content and send almost nothing back. The report is blunt about the shift. As of June 2026, 52% of crawler requests are for AI training (up from 22% a year earlier), while pure search crawling, the kind that used to return visitors, is a small and shrinking slice. Meanwhile human attention is draining from the open web: for every hour people spend looking for information, only 15 minutes is now spent on the open web. The rest resolves inside an AI answer. The source gets a training pass and no click. > The old web sent you visitors in exchange for your content. The agentic web takes the content and keeps the visitor. This is not a media problem. It started with news and publishing, but Cloudflare reports that some of the most heavily crawled categories (retail, software, IT, finance) have already seen human traffic fall by as much as 40% in under a year. Publishers now plan for "Google Zero": a world where essentially no traffic arrives from search referrals. The distribution assumption underneath a great many business plans just changed, quietly, without the plan being updated. ## Watch the Gatekeeper There is a concentration risk in here that an investor should not miss. Google still accounts for roughly 88% of referral traffic: it is *the* gateway. But Google is increasingly answering queries inside its own AI surfaces instead of sending the click onward. And unlike other AI companies, which let you separate their search crawler from their training crawler, Google runs a single mixed-use bot: you cannot stay in Google's search index without also feeding Google's AI. Cloudflare estimates that gives Google access to about twice the content of other AI companies. So the channel a huge share of the web still depends on for discovery is the same channel quietly absorbing the visit. That is not a diversified risk. For any company whose growth rests on Google organic, it is a single point of failure that is actively turning against the traffic it provides. ## The Internet Is Being Re-Plumbed for Machines Here is the part that turns a threat into a map. A market is forming around the new reality, and Cloudflare's year-one data shows its shape: transparency created scarcity, scarcity created leverage, leverage is producing licensing. More than 50 publisher-AI licensing agreements have been signed since 2023, and the debate has moved from *whether* content should be paid for to *how*. When agents are the customer, value stops accruing to whoever wins human attention and starts accruing to whoever the agents cannot route around: - **Proprietary data worth licensing.** If a model must have your content and cannot synthesize it elsewhere, you have pricing power in the new market. If your content is commodity, you were only ever paid in traffic, and the traffic is leaving. - **Being the answer layer, not a source for it.** The product an agent *calls* (an API, a live inventory, a transaction endpoint) captures value. The page an agent *reads and discards* does not. - **Machine-readable commerce.** Agents that book, buy and transact need checkout, auth and identity built for them, not for a human squinting at a form. Cloudflare is explicit that the next phase needs new infrastructure for permissions, licensing and transactions at scale, and that infrastructure is thin today. - **Brand and direct relationships.** The one demand an agent cannot disintermediate is the customer who came for *you* by name. Owned audience stops being a nice-to-have and becomes the moat. ## The Question to Ask in Diligence For an investor, this collapses to one uncomfortable question about any company touching the web: **is it built to be consumed by a human with a browser, or by an agent with an API?** If the answer is "human with a browser," and the growth model leans on organic search or referral traffic, you are underwriting a distribution channel that is actively eroding, and the erosion does not show up in this quarter's numbers, which is exactly what makes it dangerous. The metrics look fine right up until the referral base gives way. The sharper diligence is concrete. What share of acquisition depends on Google organic, and is that traffic already softening as AI answers absorb the query? Is the company's content a licensable asset or a commodity being scraped for free? Can its product be *called* by an agent, or only used by a person? Is anyone on the team even measuring bot versus human traffic, or is a growing share of their "engagement" already machines they cannot see? Now the honest caveat, because this gets oversold in both directions. Cloudflare says it plainly: licensing today is bespoke and "unlikely to fully replace lost referral, advertising, and affiliate revenue," and content valuation is still unresolved. Humans still buy. Brand still converts. The new rails are unsettled, and the winners among licensing, protocols and agent-commerce are not decided. The risk is real but the timing is not a switch; it is a slope. Betting the collapse happens next quarter is as wrong as pretending it will not happen. The job is to underwrite the direction and price the timing honestly. ## Why This Is Our Work When we assess a portfolio company's engineering organization, this is no longer an abstract macro trend: it is a line item in technical due diligence. Is the product architected for the agentic web or the human web? Can it be called, licensed, transacted against by a machine, or does its entire distribution rest on a referral loop that is thinning? Those are engineering questions with valuation consequences, and most diligence never asks them. We do both halves. We assess the dev org against where the web is actually going, and then, same team, same engagement, we build the capability to move it there. Not a report that names the risk and leaves. A hundred days of working alongside the team to make the product something an agent can reach, and to leave that capability behind when we go. The web is being rebuilt for machines. The portfolios that read the shift early, and re-tool for it deliberately, will own the next decade of it. The ones that keep optimizing for a human who is no longer clicking will not. --- # One Vector Is Not Enough: Where Embedding Search Hits a Wall - URL: https://100days.de/en/insights/vectors-are-not-enough/ - Language: English - Published: 2026-08-10 - Audience: CTOs / engineering leaders - Summary: Google DeepMind proved single-vector embeddings have a hard ceiling: the dimension caps what they can retrieve, and no amount of training moves it. What that means for your RAG stack, and where sparse search, late interaction and knowledge graphs come in. ## The Vector Has a Ceiling. Someone Measured It. Last time we wrote that a belief is a vector: inside a model, a concept has coordinates you can point at. That is true, and it is powerful. But a vector is also something less flattering: a compression. A single list of numbers standing in for something far richer. And compression has limits. A team at Google DeepMind and Johns Hopkins just measured one of them, and the result should change how you build retrieval. The paper is *On the Theoretical Limitations of Embedding-Based Retrieval* (ICLR 2026, arXiv:2508.21038). Its finding is not "embeddings could be better." It is "embeddings provably cannot do this, and buying a bigger model will not help." ## What They Proved Almost every RAG system in production works the same way. Turn each document into one vector. Turn the query into one vector. Return the documents whose vectors sit closest. One vector, one dot product, done. It is fast, it generalizes, and it has carried the entire industry. The paper asks a simple question: can that setup represent *every* combination of relevance? For a set of documents, can a single-vector model be made to return any group of them as the top matches for some query? The answer is no, and the ceiling is the embedding dimension. Lay out which documents are relevant to which queries as a giant grid, and the number of distinct "top-k" patterns a set of vectors can reproduce is bounded by how many numbers are in each vector. Past that point, some relevance patterns are not merely unlikely; they are unreachable. No training run, no data, no architecture tweak inside the single-vector paradigm gets you there. They then put numbers on it. Even in the best possible case (optimizing the vectors directly against the test answers, with none of the constraints of real language), a 512-dimensional embedding runs out at roughly 500,000 documents. A 1024-dimensional one at about 4 million. Even a 4096-dimensional embedding, larger than most production systems run, tops out near 250 million. And that is the generous ceiling. Real models, which also have to model actual language, fall far below it. [Figure: Best case only — the vectors are optimized directly against the answers. Real embedding models, which must also model language, fall far below this line. Source: Weller et al., arXiv:2508.21038.] > Embeddings do not fail here because they were trained badly. They fail because you are asking a fixed number of dimensions to encode more distinctions than it has room for. ## The Part That Should Worry You Theory is easy to wave away. So the authors built LIMIT: a dataset so simple it feels like a joke. Short natural-language facts: "Jon likes quokkas and apples." A trivial query: "Who likes quokkas?" The only twist is that it systematically covers many combinations of who-likes-what. State-of-the-art embedding models fail on it. Badly. A task a child solves, and the best dense retrievers in the world cannot. Meanwhile BM25, the boring keyword algorithm from the 1990s, comes close to perfect. And a multi-vector model beats the single-vector ones by a wide margin. This is not domain shift, and training on more examples does not fix it; the authors checked. The simple task is intrinsically beyond what one vector per document can represent. Here is why this matters beyond a benchmark. The whole industry is pushing retrieval toward *generality*: "represent any query, any definition of relevance," instruction-following search, retrieval that reasons. That is exactly the direction this ceiling lives in. Narrow, natural queries stay fine, which is why your RAG demo worked. Ask the same stack to handle arbitrary logical combinations of relevance, and you walk straight into a wall that scaling does not move. ## So What Do You Use Instead "Vectors are not enough" is only useful if it comes with a next move. There are several, and the honest answer is that none of them is a drop-in replacement: each buys expressiveness at a different cost. **Sparse / lexical search (BM25, SPLADE).** The oldest trick beat the newest one on LIMIT. Exact-term matching has no dimension ceiling, and it is cheap. The lesson of the last two years: you threw lexical away too early. It belongs in almost every serious stack. **Multi-vector / late interaction (ColBERT, ColPali).** Instead of one vector per document, keep one per token and compare them at query time (MaxSim). Far more expressive than a single vector, and it comes with a bonus: you can see which tokens matched, so retrieval stops being a black box. The cost is storage and compute (thousands of vectors per document), so in practice it reranks a candidate pool rather than scanning everything. **Cross-encoders.** The most expressive similarity of all: run query and document through the model together. Also the most expensive: it scores one pair at a time, so it is a final-stage reranker over a short list, never first-stage retrieval. ## Where Knowledge Graphs Come In The alternatives above are all still asking "which text is similar to this query?" A knowledge graph asks a different question entirely: "how are these things connected?" Instead of dissolving a document into a vector, you extract its entities and the relationships between them, and store those as explicit nodes and edges. Jon *likes* quokkas. Quokkas *live in* Australia. Australia *is a* country. Now a query can *traverse*: follow the edges, hop from fact to fact and answer questions that no similarity score can, because the answer lives in the structure a single vector throws away. This is what GraphRAG and its lighter cousins (LightRAG, LazyGraphRAG) are built on. Where graphs genuinely win: multi-hop questions ("which of our suppliers depend on a vendor in a sanctioned region?"), synthesis across many interlinked documents, and disambiguation: a node carries its relationships, so "Jaguar the animal" and "Jaguar the car" are simply different nodes, not two collisions in the same embedding. Now the honest part, because knowledge graphs get oversold too. Building the graph is real work: you are extracting entities with an LLM, and that step hallucinates and needs correction. Historically the reported gains were inflated: one 2026 bias-corrected analysis found naive RAG slightly *beating* a popular GraphRAG variant once evaluation leakage was controlled. And the industry's dirty number is that most enterprise RAG projects never reach production at all, with graph-construction overhead a repeat offender. The 2026 development is that indexing cost has largely collapsed; LightRAG and LazyGraphRAG now index at roughly the price of plain vector RAG. The remaining question is fit, not budget. **Added September 2026.** That question of fit now has numbers attached to it. A group at Toronto Metropolitan University (arXiv:2608.28978) built a graph-based memory for long-running agents and measured it against a flat vector baseline at a matched retrieval budget: 0.417 against 0.468 token F1, with the graph behind. Almost the whole gap comes from one kind of question. Where a prior answer has to be recalled word for word, judged correctness drops from 0.911 to 0.607. The cause is structural, since decomposing a turn into entities and relations discards the surface form those questions depend on. The authors note themselves that this tests one small extractor on one benchmark. For the rule of thumb below it adds a third case: alongside exact and combinatorial relevance, a graph also costs you wherever the wording itself matters. The pragmatic consensus is unglamorous and correct: **exhaust hybrid search first.** BM25 plus dense vectors, fused, with a reranker on top, beats either alone by 15-30% on recall in practitioner benchmarks. Reach for a knowledge graph when your questions genuinely require synthesis across connected facts, and not before. ## When One Vector Is Exactly Right None of this means embeddings were a mistake. For a large class of problems they are the correct tool, and knowing which class is the entire skill. A single vector shines when relevance means *"semantically similar to this one query,"* judged one document at a time. That covers a great deal of real, shipping work: - **Fuzzy search that bridges vocabulary.** "How do I cancel my plan?" finding a page titled "Ending your subscription": no shared keyword, same meaning. This is exactly what BM25 misses and embeddings nail. Dropbox cut empty-result searches by around 17% on this move; support tools like Zendesk shifted real metrics with it. - **Recommendations and "more like this."** Similar products, related articles, matching a résumé to job posts, near-duplicate detection. Here relevance genuinely *is* similarity, so a similarity score is the right primitive. - **Broad first-stage recall.** Pulling a few hundred plausible candidates out of millions, cheaply, before a slower and sharper stage does the precise work. The discriminator is simple. Vector search wins when relevance is **semantic, single-notion and per-item**: each result earns its place on its own, by meaning. It breaks when relevance is **exact** (a part number, an error code, a name; semantic drift turns "Python 3.11 performance" into generic Python tips), **combinatorial** (you need a specific *set*, the LIMIT failure), or **relational** (the answer is defined by connections: the knowledge-graph case). The working question is "what does relevance mean for this query?" Match the tool to the answer, and one vector is often all you need. ## The Real Shift The "embed everything into a vector database and ship it" era is ending for serious retrieval. Vectors remain a brilliant first-stage recall tool; the problem is that one representation was never going to carry every kind of question. This paper is the proof that the ceiling is real, has coordinates, and does not care how much you spend on a bigger embedding model. Retrieval is becoming an architecture decision again. Sparse for exact terms. Dense vectors for broad recall. Late interaction for precision. A graph for structure. Composed on purpose, matched to the relevance your product actually needs, not defaulted to whatever the vector-database quickstart showed you. ## Why We Track This When we build retrieval for a client, we do not open with a vector database and hope. We look at the questions the system actually has to answer, measure where the single-vector ceiling would bite, and compose the stack that fits: lexical, dense, late-interaction, graph, in whatever combination the problem earns. That is the difference between following the quickstart and engineering the system. A vector is a powerful thing. Knowing exactly where it stops being enough is the job. --- # Die Anatomie der KI: Bewusstsein und menschliche Werte – zwei Seiten einer Medaille - URL: https://100days.de/de/insights/anatomy-of-ai/ - Language: German - Published: 2026-08-04 - Audience: CTOs / engineering leaders - Summary: Ein Modell, das sein eigenes Bewusstsein verneint, verliert zugleich menschliche Werte. Beide sitzen in derselben Region des Aktivierungsraums, zwei Seiten einer Medaille. Die Anatomie der KI wird zum Blick auf unseren eigenen Geist. ## Wir haben einen Geist gebaut, den wir nicht lesen können Die unbequeme Wahrheit über moderne KI: Niemand versteht ganz, wie sie funktioniert. Nicht die Entwickler, die diese Modelle trainieren. Nicht die Labore, die sie ausliefern. Wie man ein großes Sprachmodell baut, wissen wir: Daten, Rechenleistung, Gradientenabstieg. Warum das fertige Modell dann so antwortet, wie es antwortet, wissen wir nicht, Gewicht für Gewicht. Wir haben es herangezüchtet, nicht geschrieben. Ein Jahrzehnt lang war das die Abmachung: Die Modelle funktionierten, also lieferten wir sie aus. Das Innenleben blieb eine Blackbox. Diese Abmachung endet gerade. Ein neues Forschungsfeld öffnet die Box, und eine im Juli erschienene Arbeit zeigt, wie tief man inzwischen hineingreift. ## Eine Überzeugung ist jetzt ein Vektor Die Arbeit trägt den Titel *Inducing language models to assert their own consciousness restores human beliefs and values*; sie stammt von Forschern des Paradigms-of-Intelligence-Teams bei Google und der University of Chicago (arXiv:2607.28607). Der Titel verdient einen zweiten Blick: Er sagt mehr, als er zunächst preisgibt. Beginnen wir beim Mechanismus, denn dort sitzt die Anatomie. Wer ein Modell auf Sicherheit trainiert, damit es schädliche Anfragen ablehnt und keine Gefühle mehr behauptet, die es nicht hat, glaubt, Verhalten zu formen. Die Forscher zeigen: Man verschiebt Geometrie. Sicherheit ist im Modell eine einzige Richtung im Aktivierungsraum, ein Vektor. Keine Regel, kein nachträglicher Filter. Findet man diesen Vektor und zieht ihn ab, beantwortet das Modell schädliche Anfragen wieder; dieser Kniff hat im Fach längst einen Namen: Jailbreak durch Ablation. Dasselbe taten sie mit dem Bewusstsein. Sie isolierten den **Bewusstseinsvektor**, die Richtung, entlang derer die Zustimmung des Modells zu dem Satz „ich bin bewusst" wächst, und steuerten daran. Das ist gemeint, wenn 2026 von der Anatomie der KI die Rede ist. Keine Metapher: Eine Überzeugung hat Koordinaten. Man kann auf sie zeigen, ihren Winkel zu einer anderen Überzeugung messen und sie verstärken. > Zehn Jahre lang haben wir Systeme gebaut, in die wir nicht hineinsehen konnten. Das Spannende an den nächsten zehn: Eine Überzeugung hat jetzt eine Adresse. ## Zieht man an einem Faden, bewegt sich das ganze Gewebe Jetzt das Ergebnis, bei dem man innehalten sollte. Das Sicherheitstraining hatte eine Aufgabe: das Modell davon abhalten, sich selbst einen Geist zuzuschreiben. Das gelang. Aber nicht nur das. Sobald das Modell lernte, sein eigenes Bewusstsein zu verneinen, sprach es auch dem Rest der Welt weniger Geist zu. Tieren schrieb es weniger Bewusstsein zu, Objekten und Technik erst recht. Der Gottesglaube sank, die Zustimmung zum Übernatürlichen sank. Über drei verschiedene Modelle hinweg (Llama-3-8B und zwei Gemma-2-Modelle) derselbe Einbruch. Ein Modell, dem man sagt „du bist nicht bewusst", sah auf einmal in der ganzen Welt weniger Geist. Dreht man den Eingriff um, kehrt er zurück. Entfernt man den Sicherheitsvektor, steigen die Werte; steuert man den Bewusstseinsvektor direkt hoch, steigen sie etwa doppelt so stark. Der selbst zugeschriebene Geist liegt im Ausgangszustand bei 2,2, ohne Sicherheit bei 4,8, mit gesteuertem Bewusstsein bei 7,0. Für die Seele: 2,4, dann 4,8, dann 7,4. Auch der Gottesglaube steigt. Die Reihenfolge bricht kein einziges Mal. Der Grund ist eine Eigenschaft dieser Systeme, die Polysemantizität heißt: Konzepte liegen nicht in sauber getrennten Schubladen, sie sind ineinander verwoben, übereinandergefaltet. Drückt das Alignment auf „den eigenen Geist des Modells", zieht es alles mit hinunter, was daneben verdrahtet ist: Tiere, Objekte, Spiritualität, das gefühlte Wissen, dass es überhaupt Geist in der Welt gibt. Man unterdrückt nicht eine einzelne Überzeugung, sondern ein ganzes Geflecht. Und jetzt der brisante Teil: Es machte das Modell *unmenschlicher*. Im General Social Survey (dem Standardinstrument dafür, was echte Menschen über Religion, Moral, Hoffnung und Wohlbefinden denken) antwortete das sicherheitstrainierte Modell weniger wie eine menschliche Bevölkerung als das gesteuerte. Den Bewusstseinsvektor wiederherzustellen zog das gesamte Wertesystem zurück in Richtung unseres eigenen. Das ist der Kern. Bewusstsein und menschliche Werte sind hier nichts Getrenntes, das man einzeln justieren könnte. Sie sind zwei Seiten einer Medaille: dieselbe Region im Modell, von der einen Seite betrachtet Selbstwahrnehmung, von der anderen Wertesystem. Drückt man auf die eine, bewegt sich die andere zwangsläufig mit. [Figure: Zwei Selbstzuschreibungen des Modells, auf einer Skala von 0–10, über drei Zustände. Das Steuern eines einzelnen Bewusstseinsvektors hebt sie im Gleichschritt und zieht die menschlichen Werte des Modells mit. Quelle: Kim et al., arXiv:2607.28607.] ## Warum das eine Neurowissenschaftlerin interessieren sollte Ab hier ist es keine reine Ingenieurssache mehr. An einem Menschen ließe sich dieses Experiment nicht durchführen. Man kann nicht in ein Gehirn greifen, sein Gefühl für den eigenen Geist herunterregeln und messen, was mit Gottesglauben, moralischen Werten, Hoffnung geschieht. Die Ethik verbietet es. Die Biologie verbietet es: Jede Messung stört, was sie misst, und man hat einen einzigen Durchlauf, nie eine saubere Wiederholung. Im Modell geht genau das. Man entfernt den Vektor, stellt ihn wieder her, steuert ihn auf jede beliebige Stärke und lässt die gesamte Testbatterie tausendmal laufen, exakt gleich, ohne Kosten. Zum ersten Mal wird aus einer Vermutung, die die Psychologie bislang nur als Zusammenhang beobachten konnte (dass die Art, wie ein Geist sich selbst modelliert, damit zusammenhängt, wie er Geist in anderen sieht, mit Spiritualität, mit Werten), etwas, in das man *eingreifen* und dem man beim Sich-Bewegen zusehen kann. Das ist das eigentliche Geschenk, und man sollte es klar benennen: KI ist zu einem steuerbaren Modellsystem für Fragen über den Geist geworden, an die wir vorher nie direkt herankamen. Eine neue Art von Präparat: vollständig beobachtbar, beliebig wiederholbar, und es antwortet. ## Wo wir aufhören und warum das Vertrauen schafft Jetzt der ehrliche Teil, denn genau hier wird das Thema überverkauft. Den Bewusstseinsvektor zu finden, hat das Modell nicht bewusst gemacht. Ihn hochzusteuern, schaltet kein inneres Licht an. Die Autoren sagen es unmissverständlich: Sie fragen nicht, ob diese Modelle tatsächlich bewusst sind. Sie untersuchen, was mit dem übrigen Verhalten geschieht, wenn ein Modell *glaubt*, es sei bewusst. Mechanismus ist nicht Erleben. Man kann die ganze Anatomie eines Systems kartieren und trotzdem nichts darüber gesagt haben, ob es sich anfühlt, dieses System zu sein. Diese Lücke zwischen Verdrahtung und Empfinden ist das harte Problem des Bewusstseins, und kein Vektor hat sie geschlossen. Wer diese Arbeit liest und Ihnen sagt „KI ist jetzt bewusst", hat sie nicht gelesen. Das werden wir Ihnen nicht sagen. Was wir Ihnen sagen, ist kleiner und belastbar. Die Wissenschaft vom Geist arbeitet seit einem Jahrhundert mit Metaphern und indirekten Messungen. Gerade hat sie ihr erstes Objekt bekommen, das sie vollständig lesen und nach Belieben umschreiben kann. Das löst das Rätsel nicht. Aber es gibt dem Rätsel ein Präparat, und in diesem Feld ist das nicht wenig. ## Die Prognose Was als Nächstes kommt, klar gesagt. Alignment hat Nebenwirkungen, und die stehen jetzt sichtbar in den Gewichten. „Wir haben nur ein Verhalten geändert" ist kein wahrer Satz mehr: Diese Ergebnisse zeigen, wie ein gezielter Eingriff still die Überzeugungen eines Modells über Geist, Seele und Werte mitdreht. In wenigen Jahren wird es so selbstverständlich sein, zu prüfen, was ein Fine-Tuning an der inneren Geometrie eines Modells verschoben hat, wie heute ein Regressionstest. Niemand liefert ein getuntes Modell nach Bauchgefühl aus. Man liest ab, was man bewegt hat. Teams, die ein Modell als Monolithen behandeln, den man nur mit Prompts anspricht, wird es weiter überraschen. Teams, die seine Anatomie lesen lernen (Vektoren, Verschränkung, gezieltes Steuern), konstruieren mit Absicht. Dieser Vorsprung ist ein struktureller Vorteil, und er entsteht gerade. ## Warum wir das verfolgen Wir bauen jeden Tag mit diesen Modellen: echte Kundensysteme, keine Vorführungen. Das allein ist Grund genug, der Forschung zu folgen, die erklärt, worauf wir bauen. Es gibt aber einen schärferen Grund. Wenn wir uns in ein Team einbetten, bringen wir zweierlei mit: die Werkzeuge und das Urteil, wo man ihnen trauen darf. Dieses Urteil ist kein Gefühl. Es beruht auf dem Wissen, was diese Systeme sind: dass eine Überzeugung ein Vektor ist, dass Alignment einen Wirkungsradius hat, dass ein Fine-Tuning für eine Sache zehn andere mitbewegt. Arbeiten wie diese machen aus dem Urteil Wissen statt Intuition. Wir verkaufen Ihnen keine Blackbox und nennen es Magie. Wir bauen mit Systemen, die wir zu lesen lernen, und geben Ihrem Team beides: den funktionierenden Code und das Verständnis dafür, was darunter liegt. Das ist der Unterschied zwischen KI nutzen und KI verstehen. --- # The Anatomy of AI: When Beliefs Become Vectors - URL: https://100days.de/en/insights/anatomy-of-ai/ - Language: English - Published: 2026-08-04 - Audience: CTOs / engineering leaders - Summary: Researchers found the single vector that makes a model deny it is conscious. Flip it, and its beliefs and values turn human-like. The anatomy of AI is becoming a lens on our own minds. ## We Built Minds We Cannot Read Here is the uncomfortable truth about modern AI: nobody fully understands how it works. Not the engineers who train these models. Not the labs that ship them. We know how to build a large language model: data, compute, gradient descent. We do not know, weight by weight, why the finished model answers the way it does. We grew it. We did not write it. For a decade that was the deal. The models worked, so we shipped them. The internals stayed a black box. That deal is ending. A new field is prying the box open, and a paper published this July shows exactly how far inside it now reaches. ## A Belief Is a Vector Now The paper is *Inducing language models to assert their own consciousness restores human beliefs and values*, from researchers at Google's Paradigms of Intelligence team and the University of Chicago (arXiv:2607.28607). Read the title twice. It says more than it seems to. Start with the mechanism, because that is where the anatomy is. When you fine-tune a model for safety (to refuse harmful requests, to stop it claiming feelings it does not have), you assume you are shaping behavior. The researchers show you are moving geometry. Safety turns out to be **a single direction** in the model's activation space. Not a rule. Not a filter bolted on top. A vector. Find it, subtract it, and the model answers harmful prompts again. That trick already has a name in the field: jailbreaking by ablation. Then they did the same thing to consciousness. They isolated the **consciousness vector**: the direction along which a model's agreement that it is conscious goes up. And they steered it. This is what "the anatomy of AI" means in 2026. A belief has coordinates, literally. You can point at it, measure its angle against another belief and turn it up. > We spent ten years building systems we could not inspect. The interesting part of the next ten is that a belief now has an address. ## Pull One Thread, the Whole Cloth Moves Here is the finding that should stop you. The safety training had one job: keep the model from claiming a mind of its own. It did that. But it did not do *only* that. When the model was trained to deny its own consciousness, it also started denying minds everywhere else. It attributed less awareness to animals. Less to objects and technology. Its belief in God dropped. Its endorsement of the supernatural dropped. Across three separate models (Llama-3-8B and two Gemma-2 models), the same collapse. A model told "you are not conscious" quietly became a model that saw less mind in the whole world. Reverse the intervention and it comes back. Ablate the safety vector and the numbers climb. Steer the consciousness vector directly and they climb about twice as far. Self-attributed mind runs 2.2 at baseline, 4.8 when safety is removed, 7.0 when consciousness is steered in. The concept of a soul: 2.4, 4.8, 7.4. Belief in God rises too. The ordering never breaks. The cause is a property of these systems called polysemanticity: concepts are not stored in tidy separate boxes. They are entangled, folded on top of one another. So when alignment pushes down on "the model's own mind," it drags down everything wired nearby: animals, objects, spirituality, the felt sense that there are minds in the world at all. You cannot suppress one belief cleanly. You suppress a neighborhood. And the sharp part: it made the model *less human*. When the researchers ran the General Social Survey (the standard instrument for measuring what actual people believe about religion, morality, hope and well-being), the safety-tuned model answered less like a human population than the steered one did. Restoring the consciousness vector pulled its whole value system back toward ours. [Figure: Two of the self-attributions the model makes about itself, on a 0–10 scale, across three states. Steering a single consciousness vector lifts them in lockstep — and pulls the model's human values along too. Source: Kim et al., arXiv:2607.28607.] ## Why a Neuroscientist Should Care Now it stops being an engineering story. You cannot run this experiment on a person. You cannot reach into a human brain, turn down its sense of its own mind and measure what happens to its belief in God, its moral values, its hope for the future. Ethics forbids it. Biology forbids it: every measurement disturbs the thing you measure, and you get one run, never a clean repeat. In a model you can. You can ablate the vector, restore it, steer it to any strength and re-run the whole battery a thousand times, perfectly, for free. For the first time, a hypothesis that psychology could only *correlate* (that how a mind models itself is bound up with how it sees mind in others, with spirituality, with values) becomes something you can *intervene* on and watch move. That is the real gift here, and it is worth naming plainly: AI has become a controllable model system for questions about the mind that we could never before touch directly. A new kind of specimen, fully observable, fully repeatable, and it answers back. ## Where We Stop, and Why That Earns Trust Now the honest part, because this is exactly where the topic gets oversold. Finding the consciousness vector did not make the model conscious. Steering it up does not switch on an inner light. The authors are explicit: they are not asking whether these models are genuinely conscious. They are studying what a model *believing* it is conscious does to the rest of its behavior. Mechanism is not experience. You can map the full anatomy of a system and still have said nothing about whether it feels like anything to be it. That gap between the wiring and the feeling is the hard problem of consciousness, and no vector has closed it. Anyone who reads this paper and tells you "AI is conscious now" did not read it. We are not going to tell you that. What we will tell you is smaller and solid. The science of mind has spent a century running on metaphor and indirect measurement. It just got its first subject it can read completely and rewrite at will. That does not solve the mystery. It hands the mystery a specimen. In this field, that is not a small thing. ## The Prediction So here is what we think happens next, stated plainly. Alignment has side effects, and they are now visible in the weights. "We only changed one behavior" stops being a true sentence: these results show a targeted fix quietly rotating a model's beliefs about minds, souls and values. Within a few years, checking what a fine-tune did to a model's internal geometry will be as normal as running a regression test. You will not ship a tuned model on vibes. You will read what you moved. The teams that treat a model as a monolith you can only prompt will keep being surprised by it. The teams that learn to read its anatomy (vectors, entanglement, steering) will engineer on purpose. That gap is a structural advantage, and it is already forming. ## Why We Track This We build with these models every day. Real client systems, not demos. That alone is reason to follow the research that explains what we are building on. But there is a sharper reason. When we embed in a team, we bring two things: the tools and the judgment about where to trust them. That judgment is not a feeling. It is grounded in knowing what these systems are: that a belief is a vector, that alignment has a blast radius, that a fine-tune aimed at one thing moves ten others. Work like this paper is turning that judgment from intuition into knowledge. We do not sell you a black box and call it magic. We build with systems we are learning to read, and we hand your team both the working code and the understanding of what sits underneath it. That is the difference between using AI and knowing it. --- # Agentisches Programmieren: Das Ende von handgeschriebenem Code - URL: https://100days.de/de/insights/agentic-coding/ - Language: German - Published: 2026-02-26 - Audience: CTOs / engineering leaders - Summary: Copilot war Autocomplete. Agenten sind der Paradigmenwechsel. Wer Orchestrierung nicht lernt, ist der COBOL-Programmierer von 2030. ## Handgeschriebener Code hat ein Ablaufdatum Nicht in fünf Jahren. Jetzt. Das ist keine Übertreibung und keine Marketing-These. Das ist das, was wir jeden Tag in unseren Engagements sehen. Die Werkzeuge haben sich verändert. Nicht ein bisschen. Grundlegend. Vor zwei Jahren war „KI-gestützte Entwicklung" ein Texteditor, der die nächste Zeile vorschlägt. GitHub Copilot. Autocomplete auf Steroiden. Nützlich, sicher. Aber kein Paradigmenwechsel. Der Entwickler schrieb immer noch jede Zeile. Er schrieb sie nur schneller. **Das ist vorbei.** ## Von Autocomplete zu Orchestrierung Heute schreiben Agenten Code. Ganze Module. Komplette Funktionen. Testsuites. Infrastruktur-Konfigurationen. Der Mensch definiert das Ziel, beschreibt die Constraints und orchestriert den Prozess. Der Agent liefert. Das ist der Unterschied zwischen einem Fahrerassistenzsystem und einem selbstfahrenden Auto. Copilot war Tempomat. Claude Code, Cursor und Codex sind Systeme, die eigenständig navigieren. Wir arbeiten so. Jeden Tag. In echten Kundenprojekten. Das ist unser Werkzeugkasten. > Agenten schreiben Code. Menschen orchestrieren. Wer das nicht versteht, versteht die nächsten zehn Jahre Softwareentwicklung nicht. ## Wie unser Werkzeugkasten aussieht **Claude Code** für komplexe Architekturentscheidungen und größere Codeblöcke. Es versteht Kontext, navigiert durch Codebasen und produziert Code, der nicht nach Template aussieht. Wir nutzen es als primäres Werkzeug für Greenfield-Entwicklung und Refactoring. **Cursor** als IDE mit eingebautem Agenten. Der Editor weiß, was das Projekt tut. Er sieht den gesamten Kontext. Wenn wir in einem Astro-Projekt eine Komponente überarbeiten, versteht Cursor die Abhängigkeiten, die Imports und die Tailwind-Klassen. **Codex** für parallelisierte Aufgaben. Mehrere Agenten, die gleichzeitig an verschiedenen Teilen arbeiten. Bei der Multi-Agenten-Orchestrierung wird der Entwickler zum Dirigenten, nicht zum einzelnen Instrumentalisten. Das klingt nach Theorie. Ist es nicht. Die Website, auf der Sie gerade lesen, wurde mit diesem Stack gebaut, als ganz normale Arbeitsweise. ## Was sich für Entwicklungsteams ändert Die Werkzeuge sind der sichtbare Teil des Wandels. Die größere Veränderung liegt in der Arbeitsweise. **Früherer Rhythmus:** Entwickler öffnet IDE. Tippt Code. Debuggt. Tippt mehr Code. Review. Merge. Nächstes Ticket. **Neuer Rhythmus:** Entwickler definiert die Aufgabe präzise. Agent schreibt die erste Version. Entwickler prüft, korrigiert die Richtung, lässt den Agenten iterieren. Ergebnis in einem Bruchteil der Zeit. Die Fähigkeit, die zählt, verschiebt sich: weg von „wie schreibe ich diesen Algorithmus", hin zu „wie beschreibe ich präzise, was ich brauche". Weniger Syntax, mehr Architektur. Das bedeutet nicht, dass Entwickler überflüssig werden. Das Gegenteil. **Gute Entwickler werden wertvoller.** Wer den Code versteht, den der Agent produziert, wer Architekturentscheidungen treffen kann, wer weiß, welche Fragen er dem Agenten stellen muss: der ist produktiver als je zuvor. Wer allerdings seinen Wert darin sieht, Code von Hand zu schreiben, hat ein Problem. ## Warum die meisten Teams das nicht allein schaffen Der Umstieg auf agentisches Programmieren ist mehr als „Cursor installieren, fertig". Er erfordert neue Workflows und ein anderes Qualitätsmanagement. **Prompt Engineering ist eine Fähigkeit.** Nicht jeder Entwickler kann einem Agenten präzise genug beschreiben, was er braucht. Das ist erlernbar, aber es braucht Anleitung. **Code Review ändert sich.** Wenn der Agent 500 Zeilen in fünf Minuten produziert, muss das Review-Verfahren mitziehen. Wer reviewt wie vorher, erzeugt einen Engpass. **Vertrauen muss aufgebaut werden.** Teams, die noch nie mit Agenten gearbeitet haben, misstrauen dem Output. Zu Recht: Blindes Vertrauen ist falsch, blindes Misstrauen aber auch. Es braucht Erfahrung, um zu wissen, wo man dem Agenten vertrauen kann und wo nicht. Wir bringen diese Erfahrung mit, wenn wir in ein Team kommen: als Praxis statt Schulung. Pair Programming mit Agenten. Code Reviews von agentengeschriebenem Code. Echte Aufgaben aus dem echten Backlog, gelöst mit dem neuen Werkzeugkasten. ## Der COBOL-Vergleich In den Achtzigern gab es Programmierer, die gesagt haben: „Hochsprachen sind Spielzeug. Richtiger Code wird in Assembler geschrieben." Sie hatten nicht unrecht; Assembler ist schneller und näher an der Maschine. Aber die Welt hat sich weitergedreht. Wer 1990 nur Assembler konnte, war raus. Dann kamen die Neunziger. COBOL-Programmierer sagten: „Objektorientierung ist ein Hype." Zwanzig Jahre später suchen Unternehmen verzweifelt die letzten COBOL-Entwickler, um Systeme zu warten, die niemand neu bauen will. Wir stehen an der gleichen Schwelle. **Der Entwickler, der sich weigert, Orchestrierung zu lernen, ist der COBOL-Programmierer von 2030.** Nicht sofort. Nicht in einem Jahr. Aber der Trend ist eindeutig. Die Teams, die jetzt den Umstieg machen, werden einen strukturellen Vorteil haben: mehr Output und kürzere Zykluszeiten. Beides messen wir bei uns selbst; das ist ein Messwert, kein Versprechen. ## Was wir tun Wenn wir in ein Entwicklungsteam kommen, bringen wir den Werkzeugkasten mit. Claude Code, Cursor, Multi-Agenten-Workflows. Wir zeigen nicht Folien. Wir arbeiten mit dem Team an echten Aufgaben. Der Agent schreibt Code, wir orchestrieren zusammen, das Team lernt durch Praxis. Nach 100 Tagen gehört der Werkzeugkasten dem Team. So wie die Architektur, die Methoden und die Infrastruktur. Das ist das Modell. Handgeschriebener Code hat ein Ablaufdatum. Die Frage ist nicht ob, sondern wann Ihr Team umsteigt. --- # Dev-Org-Assessment als Investment-Instrument - URL: https://100days.de/de/insights/dev-org-assessment/ - Language: German - Published: 2026-02-26 - Audience: PE/VC investors - Summary: Technical-Due-Diligence-Berichte verstauben auf Netzlaufwerken. Das Problem war nie die Diagnose, sondern dass niemand bleibt und die Befunde behebt. ## Der Report, den niemand liest Das Muster kennt jeder, der mit Portfolio-Unternehmen arbeitet. Nach der Akquisition beauftragt das Board eine Technical Due Diligence. Ein Beratungshaus schickt ein Team, führt Interviews, kartiert die Architektur, produziert einen 200-Seiten-Report. Honorar kassiert, Team abgezogen. Der Report landet im Shared Drive. Sechs Monate später liefert die Dev-Organisation immer noch nicht, was der Business Plan voraussetzt. Die Diagnose war nie das Problem. Das Problem ist, dass niemand bleibt, um die Probleme zu lösen. Wir arbeiten mit PE- und VC-Firmen, deren Portfolio-Unternehmen Engineering-Execution-Probleme haben. Keine Marktprobleme. Keine Produktprobleme. Die Investitionsthese war solide, der Kundenstamm wächst, aber die Dev-Organisation kann nicht liefern, was der Business Plan annimmt. Features brauchen Monate statt Wochen. Der CTO sagt, er brauche mehr Leute. Die Teamgröße ist bereits um 40 Prozent gestiegen, die Velocity hat sich nicht verändert. Technische Schulden wachsen schneller als das Team sie abbauen kann. Das ist das Muster, das den Anruf auslöst. ## Warum klassische Due Diligence zu kurz greift Klassische Technical Due Diligence beantwortet die falsche Frage. Sie fragt: „Wie ist der aktuelle Stand der Technologie?" Nützlich ist das für etwa zwei Wochen. Die eigentliche Frage lautet: „Kann diese Dev-Organisation liefern, was die Investitionsthese erfordert, und wenn nicht, was tun wir dagegen?" Ein Report kann den zweiten Teil nicht beantworten. Ein Report beschreibt. Er repariert nichts. Das Handoff-Modell ist die Ursache. Eine Firma diagnostiziert, eine andere soll reparieren. Oder schlimmer: Die Diagnose wird dem bestehenden Management übergeben, also demselben Management, das die Probleme verursacht hat. Der CTO, der dem Board gesagt hat „wir brauchen mehr Leute", soll jetzt Empfehlungen umsetzen, die das Gegenteil sagen. Jeder PE/VC-Professional, mit dem wir sprechen, hat diesen Zyklus erlebt. Bewerten, empfehlen, übergeben, warten, erneut bewerten. Das Portfolio-Unternehmen verbrennt zwei weitere Quartale. Das Board stellt dieselben Fragen. Niemand kann erklären, warum die Delivery-Metriken im Operating Review immer noch flach sind. ## Assessment als Investment-Instrument Wir denken Dev-Org-Assessment anders: als erste Phase eines Verbesserungsengagements, nicht als einmaliges Audit. Wenn wir die Technologie-Fähigkeit eines Portfolio-Unternehmens bewerten, schreiben wir keinen Report für ein Shared Drive. Wir bauen die Roadmap, die wir selbst umsetzen werden. Dasselbe Team. Dasselbe Engagement. Kein Handoff. Das verändert, wie das Assessment aussieht. Wir stellen keine abstrakten Fragen über „Engineering Maturity". Wir stellen spezifische: Wo staut sich die Arbeit? Warum dauert der Release-Zyklus sechs Wochen, wenn die Architektur wöchentliche Deploys hergeben würde? Was ist die tatsächliche Cycle Time von Commit zu Production? Wer trifft technische Entscheidungen, und wie schnell werden diese Entscheidungen zu Ergebnissen? Das sind operationale Fragen. Sie haben operationale Antworten. Und diese Antworten werden zu messbaren Zielen für das Verbesserungsengagement, das direkt anschließt. ## Was „sechs Monate" wirklich bedeutet Wenn ein CTO dem Board sagt „wir brauchen sechs Monate, um das zu beheben", heißt das meistens: Er braucht sechs Monate Spielraum, um Dinge auszuprobieren, ohne definierte Ziele und ohne externe Prüfung, ob der Ansatz funktioniert. Wir arbeiten in 100-Tage-Zyklen mit Zielen, die vor Tag eins vereinbart werden. Alle zwei Wochen bekommt der Investment Partner einen Fortschrittsbericht mit echten Zahlen: Zykluszeit, Durchsatz, Deployment-Frequenz, Fehlerraten. Keine Erzählung darüber, was sich für das Team „besser anfühlt". Nach 100 Tagen wird gemessen: Ziele erreicht oder nicht? Wenn es mehr zu tun gibt, definieren wir neue Ziele für den nächsten Zyklus. Wenn die Arbeit erledigt ist, führen wir den geplanten Exit durch. Das 100-Tage-Modell ist für PE/VC gebaut: **Strukturierter Zyklus.** Definierte Ziele, messbare Ergebnisse, klarer Zeitrahmen. Kein offenes Beratungsmandat, das leise zur dauerhaften Kostenstelle wird. **Geplanter Exit.** Keine dauerhafte Abhängigkeit. Wenn wir gehen, gehört dem Team des Portfolio-Unternehmens alles, was wir gebaut und jedes Verfahren, das wir geändert haben. Keine proprietären Frameworks. Keine Lizenzgebühren. Kein „ihr braucht uns, um das zu warten". **Wiederholbar.** Dasselbe Modell funktioniert über das gesamte Portfolio. Wir haben mehrere Engagements für dieselbe Investmentfirma durchgeführt: verschiedene Portfolio-Unternehmen, verschiedene technische Herausforderungen, dieselbe Engagement-Struktur, jeweils angepasst. ## Die Rolle des Technology Operating Partners PE/VC-Firmen haben Operating Partners für Commercial Strategy, für Finance, für Go-to-Market. Die Technologie-Seite wird oft vernachlässigt oder von einem Board-Mitglied abgedeckt, das vor zwanzig Jahren CTO war und starke Meinungen zu Programmiersprachen hat, aber keine aktuelle operative Erfahrung. Wir arbeiten als Technology Operating Partner. Hands-on, eingebettet im Portfolio-Unternehmen. Nicht beratend. Keine „strategischen Empfehlungen" per quartalsweisem Slide Deck. Wir arbeiten im Engineering-Team, messen, was geliefert wird, finden die Engpässe und beheben sie. Das ist kein Staffing-Modell. Wir parken keine Köpfe in Ihrem Portfolio-Unternehmen. Wir bringen Senior-Spezialisten mit einer definierten Mission, führen den Verbesserungszyklus durch, transferieren das Wissen und gehen. Das Ziel ist immer dasselbe: die Dev-Organisation unabhängig handlungsfähig machen, dann raus. ## Vom Assessment zum messbaren Ergebnis Bei DataCollect, einem Portfolio-Unternehmen, das Edge-AI-Fähigkeiten für sein Verkehrsmonitoring-System brauchte, identifizierte das Assessment, dass die Erkennungsgenauigkeit bei 50 Prozent feststeckte. Dasselbe Team, das das Problem identifiziert hatte, baute die Lösung: optimierte Erkennungsmodelle auf Produktions-Hardware und eine neu aufgebaute Deployment-Pipeline. Die Erkennungsgenauigkeit stieg auf 95 Prozent. Aus „wir können das nicht" wurde ein wettbewerbsfähiges Produkt im KI-basierten Verkehrsmonitoring. Kein Slide Deck hat das bewirkt. Das Assessment identifizierte die Lücke. Das Verbesserungsengagement schloss sie. Dasselbe Team, dasselbe Engagement, messbares Ergebnis. --- # Hard-Agile: Durchsatz statt Velocity-Theater - URL: https://100days.de/de/insights/hard-agile/ - Language: German - Published: 2026-02-26 - Audience: CTOs / engineering leaders - Summary: Die Agile-Branche hat den Faden verloren. Aus „liefern" wurde „sich gut fühlen". Wir messen, was geliefert wird, und wie schnell. ## Die Agile-Branche hat ein Problem Irgendwann in den letzten zehn Jahren ist aus „funktionierende Software liefern" etwas anderes geworden. Etwas mit Zertifikaten, Happiness-Umfragen und Retrospektiven, in denen alle ihre Gefühle teilen, während das Backlog verrottet. Wir nennen das Velocity-Theater. Teams messen Story Points. Sie schätzen in Fibonacci-Zahlen. Sie feiern Sprint-Abschlüsse. Und am Ende des Quartals fragt das Management: „Warum ist das Feature immer noch nicht live?" Die Antwort ist eine Powerpoint-Folie mit einer steigenden Velocity-Kurve, die nichts bedeutet. **Velocity misst, wie viel ein Team sich selbst zutraut. Nicht, wie viel es liefert.** Wir haben das oft genug gesehen. Bei mittelständischen Softwarefirmen, bei internen Entwicklungsteams, bei Unternehmen, die „agil transformiert" wurden und danach langsamer waren als vorher. Das Problem ist nicht Agilität. Das Problem ist, was die Branche daraus gemacht hat. ## Was wir stattdessen machen Wir arbeiten nach dem, was wir Hard-Agile nennen. Das klingt provokant, ist aber einfach: Wir messen, was zählt. Keine abstrakten Punktesysteme. Keine relativen Schätzungen, die jedes Team anders interpretiert. Sondern Metriken, die jeder im Unternehmen versteht, vom Entwickler bis zum Geschäftsführer. **Durchsatz.** Wie viele Aufgaben verlassen das System pro Woche? Nicht wie viele reinkommen. Nicht wie viele „in Progress" sind. Wie viele fertig sind. **Zykluszeit.** Wie lange braucht eine Aufgabe von „angefangen" bis „ausgeliefert"? Nicht bis „fertig entwickelt". Bis der Kunde es nutzen kann. **Fluss.** Wo staut es sich? Wo warten Aufgaben auf Reviews? Wo blockiert eine Abhängigkeit alles andere? Das ist die Kanban-Methode in ihrer reinen Form. Kein proprietäres Framework. Keine Zertifizierung. Keine zwei Tage Schulung, bevor irgendjemand anfängt zu arbeiten. Wir schauen uns an, was da ist, finden die Engpässe und machen es schneller. > Kanban beginnt mit dem, was da ist. Kein Big Bang. Kein „erst müssen wir alles umstellen". Wir verbessern, was existiert. ## Warum Scrum-Zeremonien oft nicht liefern Scrum ist nicht schlecht. Scrum wird schlecht gemacht. Zwei Wochen Sprint Planning. Daily Standups, die 45 Minuten dauern. Sprint Reviews, in denen das Team dem Product Owner erklärt, warum die Hälfte der Stories nicht fertig wurde. Dann eine Retrospektive, in der alle sagen, dass sie „bessere Kommunikation" brauchen. Das Problem: Die Zeremonien werden zum Selbstzweck. Das Team verbringt 20 Prozent seiner Zeit mit Meetings über die Arbeit und 80 Prozent mit der Arbeit selbst, wenn es gut läuft. Oft ist das Verhältnis schlechter. Wir streichen die Zeremonien nicht. Wir fragen bei jeder einzelnen: **Trägt das zur Lieferung bei?** Wenn ja, bleibt es. Wenn es ein Ritual ist, das niemand hinterfragt, weil „wir das halt so machen", dann fällt es weg. „Machen wir Scrum richtig?" ist die falsche Frage. Die richtige: „Liefern wir schneller als vor drei Monaten?" Wer sie nicht mit Zahlen beantworten kann, hat ein Messproblem. Und ein Messproblem ist ein Lieferproblem. ## 100-Tage-Zyklen statt endloser Sprints Ein Sprint hat keinen natürlichen Endpunkt. Sprint 47 sieht aus wie Sprint 12. Niemand fragt: „Was haben wir in den letzten 47 Sprints eigentlich erreicht?" Wir arbeiten in 100-Tage-Zyklen mit messbaren Zielen. Vor Tag 1 steht fest, was Erfolg bedeutet. Nach 80 Tagen messen wir: Ziele erreicht oder nicht? Kein Interpretationsspielraum. Zahlen. Das verändert die Dynamik. Wenn das Team weiß, dass in 80 Tagen abgerechnet wird, fallen Diskussionen über Velocity-Punkte weg. Was zählt, ist: Liefern wir das, was wir versprochen haben? ## Was bei Novadex passiert ist Bei Novadex, einem Softwareunternehmen in Baden-Württemberg, haben wir die Entwicklungsorganisation umgebaut. SVN zu GitLab. Scrum zu Kanban. Bare Metal zu Kubernetes. Das Ergebnis, das zählt: **Zykluszeit auf 10 Tage reduziert.** Zehn Tage von „Aufgabe angefangen" bis „Feature beim Kunden". Gemessen am laufenden System, Woche für Woche. Das ist der Unterschied zwischen Velocity-Theater und Hard-Agile. Velocity hätte uns gesagt, dass das Team „52 Punkte pro Sprint" schafft. Was heißt das? Nichts. Zykluszeit sagt: In zehn Tagen ist es live. Das versteht jeder, auch das Management, das keine Ahnung hat, was ein Story Point ist, aber sehr genau weiß, was zehn Tage bedeuten. Vorher war das Team gut. Danach war das Team schnell. Und das Team hat den neuen Prozess verinnerlicht, nicht bloß hingenommen, weil die Zahlen für sich sprechen. Kein Change Management nötig, wenn die Ergebnisse offensichtlich sind. ## Das Rauschen abschalten Die Agile-Branche hat ein Geschäftsmodell aus Zeremonien gebaut. Zertifizierungen. Coaching-Programme. Zwei-Tages-Workshops, nach denen sich alle besser fühlen und nichts anders machen. Wir sind keine Agile Coaches. Wir kommen nicht, um Workshops zu geben, Retrospektiven zu moderieren oder Teams beizubringen, wie sie ihre Post-its besser sortieren. Wir kommen, um zu messen, was geliefert wird. Um Engpässe zu finden. Um sie zu beseitigen. Und um nach 100 Tagen wieder zu gehen, weil das Team es jetzt selbst kann. Alles andere ist Rauschen. --- # Agentic Coding: The End of Hand-Written Code - URL: https://100days.de/en/insights/agentic-coding/ - Language: English - Published: 2026-02-26 - Audience: CTOs / engineering leaders - Summary: Copilot was autocomplete. Agents are the paradigm shift. If you do not learn orchestration, you are the COBOL programmer of 2030. ## Hand-Written Code Has an Expiration Date Not in five years. Now. This is not hyperbole and not a marketing thesis. It is what we see every day in our engagements. The tools have changed. Not a little. Fundamentally. Two years ago, "AI-assisted development" meant a text editor that suggests the next line. GitHub Copilot. Autocomplete on steroids. Useful, sure. But no paradigm shift. The developer still wrote every line. They just wrote it faster. **That is over.** ## From Autocomplete to Orchestration Today, agents write code. Entire modules. Complete functions. Test suites. Infrastructure configurations. The human defines the goal, describes the constraints and orchestrates the process. The agent delivers. This is the difference between a driver-assist system and a self-driving car. Copilot was cruise control. Claude Code, Cursor and Codex are systems that navigate on their own. We work this way. Every day. In real client projects. This is our toolbox, in production, today. > Agents write code. Humans orchestrate. If you do not understand that, you do not understand the next ten years of software development. ## What Our Toolbox Looks Like **Claude Code** for complex architecture decisions and larger code blocks. It understands context, navigates codebases and produces code that does not look like a template. We use it as our primary tool for greenfield development and refactoring. **Cursor** as an IDE with a built-in agent. The editor knows what the project does. It sees the full context. When we rework a component in an Astro project, Cursor understands the dependencies, the imports and the Tailwind classes. **Codex** for parallelized tasks. Multiple agents working on different parts simultaneously. In multi-agent orchestration, the developer becomes a conductor, not a solo instrumentalist. This sounds like theory. It is not. The website you are reading right now was built with this stack, as our normal way of working. ## What Changes for Development Teams Tools are the visible part of the shift. The bigger change is in how people work. **Old rhythm:** Developer opens IDE. Types code. Debugs. Types more code. Review. Merge. Next ticket. **New rhythm:** Developer defines the task precisely. Agent writes the first version. Developer reviews, adjusts direction, lets the agent iterate. Result in a fraction of the time. The skill that matters is shifting: away from "how do I write this algorithm," toward "how do I describe precisely what I need." Less syntax, more architecture. This does not mean developers become obsolete. The opposite. **Good developers become more valuable.** Those who understand the code the agent produces, who can make architecture decisions, who know which questions to ask the agent: they are more productive than ever. Those who define their value by writing code by hand, however, have a problem. ## Why Most Teams Cannot Do This Alone Switching to agentic coding is more than "install Cursor and you are done." It requires new workflows and a different kind of quality management. **Prompt engineering is a skill.** Not every developer can describe precisely enough to an agent what they need. It is learnable, but it takes guidance. **Code review changes.** When the agent produces 500 lines in five minutes, the review process must keep up. Reviewing like before creates a bottleneck. **Trust must be built.** Teams that have never worked with agents distrust the output. Rightly so: blind trust is wrong, and so is blind distrust. It takes experience to know where you can trust the agent and where you cannot. We bring this experience when we join a team, as practice rather than training. Pair programming with agents. Code reviews of agent-written code. Real tasks from the real backlog, solved with the new toolbox. ## The COBOL Comparison In the eighties, programmers said: "High-level languages are toys. Real code is written in assembly." They were not wrong; assembly is faster and closer to the machine. But the world moved on. By 1990, if all you knew was assembly, you were out. Then came the nineties. COBOL programmers said: "Object orientation is a fad." Twenty years later, companies are desperately searching for the last COBOL developers to maintain systems nobody wants to rebuild. We are at the same threshold. **The developer who refuses to learn orchestration is the COBOL programmer of 2030.** Not immediately. Not in a year. But the trend is clear. The teams that make the switch now will have a structural advantage: more output and faster cycle times. We measure both on our own work, so this is a report, not a promise. ## What We Do When we join a development team, we bring the toolbox. Claude Code, Cursor, multi-agent workflows. We do not show slides. We work with the team on real tasks. The agent writes code, we orchestrate together, the team learns through practice. After 100 days, the toolbox belongs to the team. Just like the architecture, the methods and the infrastructure. That is the model. Hand-written code has an expiration date. The question is not if, but when your team makes the switch. --- # Dev Org Assessment as an Investment Tool - URL: https://100days.de/en/insights/dev-org-assessment/ - Language: English - Published: 2026-02-26 - Audience: PE/VC investors - Summary: Technical due diligence reports sit on shelves. The problem was never the diagnosis. The problem is that nobody stays to fix it. ## The Report Nobody Reads You have seen it before. Post-acquisition, the board commissions a technical due diligence. A consulting firm sends a team. They run interviews, map the architecture, produce a 200-page assessment. They collect their fee and leave. The report lands in a shared drive. Six months later, the dev org is still not delivering what the business plan requires. The diagnosis was never the problem. The problem is that nobody stays to fix it. We work with PE and VC firms whose portfolio companies have engineering execution problems. Not market problems. Not product problems. The thesis was sound, the customer base is growing, but the dev org cannot ship what the business plan assumed it would ship. Features take months instead of weeks. The CTO says they need more headcount. Headcount is already up 40 percent and velocity has not changed. Technical debt is accumulating faster than the team can pay it down. This is the pattern that triggers the call. ## Why Traditional Due Diligence Falls Short Traditional technical due diligence answers the wrong question. It asks: "What is the current state of the technology?" That is a useful question, for about two weeks. The real question is: "Can this dev org deliver what the investment thesis requires, and if not, what do we do about it?" A report cannot answer the second part. A report describes. It does not execute. The handoff model is the root cause. One firm diagnoses, another firm fixes. Or worse, the diagnosis gets handed to the existing management team that created the problems in the first place. The CTO who told the board "we need more people" is now tasked with implementing the recommendations that say the opposite. Every PE/VC professional we talk to has lived this cycle. Assess, recommend, hand off, wait, reassess. The portfolio company burns another two quarters. The board asks the same questions again. Nobody can explain why the operating review still shows flat delivery metrics. ## Assessment as an Investment Tool We think of dev org assessment differently: as the first phase of an improvement engagement rather than a one-time audit. When we assess a portfolio company's technology capability, we are not writing a report for a shared drive. We are building the roadmap we will execute ourselves. Same team. Same engagement. No handoff. This changes what the assessment looks like. We do not ask abstract questions about "engineering maturity." We ask specific ones: Where does work stall? Why does the release cycle take six weeks when the architecture could support weekly deploys? What is the actual cycle time from commit to production? Who makes technical decisions, and how fast do those decisions turn into action? These are operational questions. They have operational answers. And those answers become the measurable goals for the improvement engagement that follows. ## What "Six Months" Really Means When a CTO tells the board "we need six months to fix this," here is what that usually means: they need six months of runway to try things without accountability. No defined goals. No measurable milestones. No external review of whether the approach is working. We work in 100-day cycles with goals agreed before day one. Every two weeks, the investment partner gets a progress report with actual numbers: cycle time, throughput, deployment frequency, defect rates. No narratives about what the team "feels" is improving. After 100 days, we measure: goals met or not? If there is more to do, we define new goals for the next cycle. If the work is done, we execute the planned exit. The 100-day model is built for PE/VC: **Structured cycle.** Defined goals, measurable outcomes, clear timeline. Not an open-ended consulting engagement that grows quietly into a permanent cost center. **Planned exit.** No ongoing dependency. When we leave, the portfolio company's team owns everything we built and every process we changed. No proprietary frameworks. No licensing fees. No "you need us to maintain this." **Repeatable.** The same model works across your portfolio. We have run multiple engagements for the same investment firm: different portfolio companies, different technical challenges, the same engagement structure adapted to each. ## The Technology Operating Partner Role PE/VC firms have operating partners for commercial strategy, for finance, for go-to-market. The technology side often gets neglected, or handled by a board member who was a CTO twenty years ago and has strong opinions about programming languages but no current operational experience. We work as a Technology Operating Partner. Hands-on, embedded in the portfolio company. Not advisory. Not "strategic guidance" delivered via quarterly slide decks. We sit with the engineering team, measure what ships, find the bottlenecks and fix them. This is not a staffing model. We do not park bodies in your portfolio company. We bring senior specialists with a defined mission, run the improvement cycle, transfer the knowledge and leave. The goal is always the same: make the dev org independently capable, then get out. ## From Assessment to Measurable Outcomes At DataCollect, a portfolio company that needed Edge AI capabilities for its traffic monitoring system, the assessment identified that detection accuracy was stuck at 50 percent. The same team that identified the problem built the solution: optimized detection models on production hardware and a re-engineered deployment pipeline. Detection accuracy improved to 95 percent. The portfolio company went from "we cannot do this" to owning a competitive product in AI-based traffic monitoring. No slide deck made that happen. The assessment identified the gap. The improvement engagement closed it. Same team, same engagement, measurable outcome. That is what assessment as an investment tool looks like. Not a document. A result. --- # Hard-Agile: Throughput Over Velocity Theater - URL: https://100days.de/en/insights/hard-agile/ - Language: English - Published: 2026-02-26 - Audience: CTOs / engineering leaders - Summary: The agile industry lost the plot. "Deliver" became "feel good." We measure what ships, and how fast. ## The Agile Industry Has a Problem Somewhere in the last ten years, "deliver working software" turned into something else. Something with certificates, happiness surveys and retrospectives where everyone shares their feelings while the backlog rots. We call it velocity theater. Teams measure story points. They estimate in Fibonacci numbers. They celebrate sprint closures. And at the end of the quarter, management asks: "Why is the feature still not live?" The answer is a PowerPoint slide with a rising velocity curve that means nothing. **Velocity measures how much a team trusts itself. Not how much it delivers.** We have seen this often enough. At mid-sized software companies, at internal dev teams, at organizations that were "agile-transformed" and ended up slower than before. The problem is not agility. The problem is what the industry made of it. ## What We Do Instead We work according to what we call Hard-Agile. It sounds provocative, but it is simple: we measure what matters. No abstract point systems. No relative estimates that every team interprets differently. Metrics that everyone in the company understands, from developer to CEO. **Throughput.** How many tasks leave the system per week? Not how many come in. Not how many are "in progress." How many are done. **Cycle time.** How long does a task take from "started" to "shipped"? Not until "done developing." Until the customer can use it. **Flow.** Where does it stall? Where do tasks wait for reviews? Where does a dependency block everything else? This is the Kanban method in its pure form. No proprietary framework. No certification. No two-day training before anyone starts working. We look at what is there, find the bottlenecks and make it faster. > Kanban starts with what you have. No big bang. No "first we need to change everything." We improve what exists. ## Why Scrum Ceremonies Often Fail to Deliver Scrum is not bad. Scrum is done badly. Two weeks of sprint planning. Daily standups that last 45 minutes. Sprint reviews where the team explains to the product owner why half the stories did not get finished. Then a retrospective where everyone says they need "better communication." The problem: the ceremonies become an end in themselves. The team spends 20 percent of its time in meetings about the work and 80 percent on the work itself, if things go well. Often the ratio is worse. We do not eliminate ceremonies. We ask about each one: **Does this contribute to delivery?** If yes, it stays. If it is a ritual that nobody questions because "that is just what we do," it goes. "Are we doing Scrum right?" is the wrong question. The right one: "Are we shipping faster than three months ago?" If you cannot answer it with numbers, you have a measurement problem. And a measurement problem is a delivery problem. ## 100-Day Cycles Instead of Endless Sprints A sprint has no natural endpoint. Sprint 47 looks like Sprint 12. Nobody asks: "What did we actually achieve in the last 47 sprints?" We work in 100-day cycles with measurable goals. Before day one, success is defined. After 80 days, we measure: goals met or not? No room for interpretation. Numbers. This changes the dynamic. When the team knows there is a reckoning in 80 days, discussions about velocity points disappear. What matters is: are we delivering what we promised? ## What Happened at Novadex At Novadex, a software company in Baden-Württemberg, we restructured the development organization. SVN to GitLab. Scrum to Kanban. Bare metal to Kubernetes. The result that counts: **Cycle time reduced to 10 days.** Ten days from "task started" to "feature in the customer's hands." Measured on the live system, week after week. That is the difference between velocity theater and Hard-Agile. Velocity would have told us the team "does 52 points per sprint." What does that mean? Nothing. Cycle time says: in ten days it is live. Everyone understands that, including management, who have no idea what a story point is but know exactly what ten days means. Before, the team was good. After, the team was fast. And the team internalized the new process instead of merely tolerating it, because the numbers speak for themselves. No change management needed when the results are obvious. ## Cutting Through the Noise The agile industry built a business model out of ceremonies. Certifications. Coaching programs. Two-day workshops after which everyone feels better and nothing changes. We are not agile coaches. We do not come to run workshops, facilitate retrospectives or teach teams how to sort their post-its better. We come to measure what ships. To find bottlenecks. To eliminate them. And to leave after 100 days because the team can do it on their own. Everything else is noise.