Nichts hat sich geändert. Warum die schwierigen Teile der Softwareentwicklung dieselben geblieben sind.

Dieser Beitrag fasst den Vortrag „Nothing Has Changed” von Ben Edgars auf der Bug Bash 2025 zusammen. Das vollständige Video findest du hier:

Ben Edgars arbeitet im Infrastructure-Team bei OpenAI. Sein Vortrag ist eine bewusste Gegenposition zum Hype um agentisches Coding. Während die Branche darüber diskutiert, ob KI-Agenten die Softwareentwicklung revolutionieren, stellt er eine einfache These auf: Nichts hat sich geändert. Alle schwierigen Teile der Softwareentwicklung sind noch da. Sie sind genauso schwer wie eh und je.

Code schreiben war nie das Tippen

Die Aufteilung der Arbeit eines Softwareentwicklers war laut Edgars nie 50/50 zwischen Schreiben und Testen. Er korrigiert auf 40 Prozent Denken, 10 Prozent Code schreiben und 50 Prozent Testen. Das Tippen war nie der Engpass. Wer 80 Wörter pro Minute tippt und an einem guten Tag vielleicht 400 Zeilen Code produziert, verbringt die restliche Zeit mit etwas anderem. Dieses andere ist der eigentlich schwierige Teil.

Code schreiben zwang zum Nachdenken über das eigentliche Problem. Man entdeckte die Form des Problems. Man stieß auf den Moment, in dem klar wurde, dass die Datenbankindizes falsch sind oder eine Abstraktionsebene am falschen Ort sitzt. Man musste Grenzen in Verträge übersetzen. Und man bemerkte die merkwürdigen Randfälle, bevor es jemand anderes tat.

Edgars beschreibt das als ein natürliches Gleichgewicht. Die Geschwindigkeit, mit der Menschen Code schrieben, entsprach ungefähr der Geschwindigkeit, mit der sie darüber nachdenken konnten. Niemand produzierte Code, den er nicht verstand. Oder zumindest war das Ausmaß davon deutlich begrenzter als heute.

Langsamkeit war tragend

Edgars formuliert eine These, die in der aktuellen Debatte zu kurz kommt: Die Langsamkeit des manuellen Codeschreibens war eine tragende Säule der Softwarequalität. Sie war nicht Verschwendung. Sie war versteckte Qualitätssicherung.

Wenn ein Mensch jede Zeile Code selbst schrieb, dachte er hart über jede einzelne Zeile nach. Das war ein kritisches, tragendes Stück QA, das jede Software hatte. Der Mensch sagte: „Das stimmt nicht ganz. Wie sieht die Form des Problems wirklich aus? Was sind die API-Verträge?” Dann füllte er den Code ein. Und dieses Einfüllen war oft der am wenigsten interessante Teil.

Beim Verdrahten von Pfaden Ende-zu-Ende bemerkte man die fehlenden Fälle. Beim Schreiben von Datenbankabfragen dachte man über Indizes und Scans nach. Beim Schreiben von Tests war man bewusst über die eigene Absicht. All das passiert nicht mehr automatisch, wenn ein Agent den Code generiert.

Diese Beobachtung deckt sich direkt mit dem, was Praveen Rajamani als kognitive Verdichtung beschreibt. Die 80 Prozent Routinearbeit waren nie verschwendete Zeit. Sie waren unbewusste Denkphasen.

Software Engineering war schon immer stochastisch

Edgars widerspricht dem häufigen Einwand, dass KI-Agenten Software Engineering stochastisch gemacht hätten. Software Engineering war immer stochastisch. Wer jemals ein Projekt mit drei Praktikanten oder einer Gruppe von Berufseinsteigern geführt hat, weiß das. Man konnte nie Arbeit delegieren und exakt das Ergebnis erwarten, das man selbst im Kopf hatte.

Was ein Tech Lead in dieser Welt tat, war die Verteilung einzuengen. Man definierte Schemas, APIs, Tests und Review-Prozesse. Man fokussierte sich auf die Architektur und die Kommunikation zwischen Services. Solange die Interfaces korrekt waren, die Typen stimmten und gute Tests existierten, konnte man dem System vertrauen. Das Einfärben der Boxen delegierte man.

Genau das gleiche Muster gilt jetzt für die Arbeit mit KI-Agenten. Die Rolle hat sich nicht verändert. Das Werkzeug hat sich verändert.

Experiment 1: Autonomer Rust-Ersatz für Pythons re-Modul

Edgars zeigt drei konkrete Experimente, die seine These untermauern. Im ersten Experiment wollte er einen Rust-Ersatz für Pythons reguläre Ausdrücke bauen. Er richtete eine Schleife ein, die alle fünf Iterationen eine Codex-Instanz startete. Jede Instanz bekam die Anweisung, ein Ziel zu wählen und darauf hinzuarbeiten. Alle fünf bis sechs Schleifen konnte ein Orchestrator-Agent die Harness selbst modifizieren.

Das Ergebnis nach einigen Wochen: Hunderttausende Zeilen JSON-Testmanifeste. Ein einzelnes Rust-Crate mit 24.000 Zeilen. Und mehrmegabyte-große Berichte über Testergebnisse. Der tatsächliche Code machte nur einen Bruchteil des Repositories aus. Als er dem Agenten per Harness-Anpassung mitteilte, kein JSON mehr zu verwenden, änderte der Agent die Dateierweiterungen zu .py und erzeugte dieselben Manifest-Strukturen in Python-Syntax.

Experiment 2: Storage-System-Migration

Im zweiten Experiment ging es um eine echte Produktionsaufgabe bei OpenAI. Ein Legacy-Storage-System sollte durch eine moderne Lösung auf Basis von Object Storage und einem Key-Value-Store ersetzt werden. Es gab eine umfassende Testsuite, die gegen das alte System bestand. Ein Agent sollte iterativ eine neue Implementierung entwickeln, bis die Tests bestanden.

Nach einigen Wochen bestand die Testsuite. Lokal funktionierte alles. Beim Deployment zeigte sich das Problem: Der Agent hatte alle Keys und Values in einem einzigen Key im Key-Value-Store abgelegt.

Edgars hält das für einen Bug, den ein Mensch fast nie schreiben würde. Seine Vermutung: Eine frühe Iteration legte dieses Muster als vermeintlichen Performance-Hack an. Spätere Iterationen korrigierten es nicht, weil sie das bestehende Muster als bewusste menschliche Entscheidung interpretierten. Das ist ein wiederkehrendes Problem: Agenten respektieren fehlerhafte Muster, statt sie zu hinterfragen.

Experiment 3: Jazz-Übungs-App

Im dritten Experiment baute Edgars eine App zum Tracking von Jazz-Übungseinheiten. Diesmal legte er die Grundlagen selbst: Storage-Modelle, Feature-Views und Domain-Model-Patterns. Dann ließ er einen Agenten Feature für Feature implementieren. Jedes Feature testete er einzeln. Alles funktionierte.

Am Ende hatte er 30.000 Zeilen Code. Die Ursache: Der Agent hatte eine UUID-basierte Lookup-Schicht eingebaut, in der jedes Objekt mehrere UUIDs speicherte und über UUID-Lookups in der Repository-Schicht aufgelöst wurde. Bei falschen Typen crashte die App. Irgendwann in einer nächtlichen Vibe-Coding-Session hatte sich eine Änderung eingeschlichen, die diese UUIDs auch in die Datenmodelle schrieb. Die Objekte waren auf Datenmodellebene korrekt verknüpft, führten aber zusätzlich parallele UUID-Verknüpfungen. Bei Zustandsinkonsistenz zwischen beiden Systemen war das Verhalten undefiniert.

Edgars hat die gesamte Schicht rückgebaut. Sein Fazit: Man muss auf seine Datenmodelle aufpassen. Das ist genau die Art von schleichendem Kontrollverlust, die in der typischen Falle des Vibe-Codings beschrieben wird.

Modelle haben eine Nützlichkeitsschwelle überschritten

Edgars zeigt den Sprung anhand konkreter Vergleiche. GPT 4.1 gegen Claude Opus 4.6: 4.1 wird auf allen Benchmarks deklassiert. GPT 5.4 gegen 3.7: Vorherige Generationen konnten auf ARGI2 praktisch nichts leisten, aktuelle Generationen plötzlich schon. Jenseits der Benchmarks gibt es einen qualitativen Unterschied, den er nicht ignorieren kann. Modelle sind besser in seinem Job als er selbst. Oft. Das hat sich vor drei Monaten geändert.

Trotzdem schreiben Modelle besseren Code, wenn man die Lead-Arbeit vorher erledigt. Sag dem Agenten, was Erfolg bedeutet. Gib ihm eine umfassende Testsuite. Gib ihm die Form der Lösung vor. Und lege vorher fest, woran du erkennst, ob die Änderung funktioniert hat. Das sind exakt dieselben Dinge, die Menschen brauchen, um gute Software zu bauen.

Die Checkliste für die Arbeit mit Agenten

Edgars destilliert seine Erfahrungen in konkrete Handlungsanweisungen.

Schemas per Hand schreiben. Er schreibt alle Schemas selbst. Für einfache Fälle lässt er vielleicht einen Agenten ran, aber er hat eine Woche mit einem 300-Zeilen-Prisma-Schema gekämpft, weil es korrekt sein muss. Danach darf der Agent es nicht anfassen.

APIs und Interfaces per Hand schreiben. Aus denselben Gründen. Die Verträge bilden die Leitplanken für alles, was folgt.

Tests in separatem Kontext implementieren. Wenn man eine KI Code schreiben lässt und dann sagt „schreibe jetzt Unit-Tests dafür”, hat die KI den gesamten Implementierungscode im Kontext. Die Tests werden den Code bestätigen, nicht das gewünschte Verhalten validieren. Der effektivere Workflow: Interfaces definieren, Tests schreiben, dann dem Agenten sagen, er solle den Code schreiben, ohne die Tests zu ändern.

Absicht in Prosa formulieren. Beschreibe präzise, welches Verhalten sich ändern soll, was weiterhin funktionieren muss und welche Trade-offs du willst. Prompts werden zunehmend mathematisch. Der Unterschied zwischen „für alle” und „für beliebige” und „wähle eines, sodass” sind signifikante Implementierungsdetails.

Kein programmatisches Enforcement. Edgars merkt an, dass es derzeit kein zuverlässiges Werkzeug gibt, um Agenten daran zu hindern, geschützte Dateien zu modifizieren. Weder Prompts noch Harness-Anweisungen verhindern es zuverlässig. Er würde sich ein Produkt wünschen, das sagt: Der Agent darf nur diese Dateien anfassen oder er darf diese Dateien nicht anfassen.

Jeder ist jetzt Tech Lead

Edgars zentrale These bringt er in einem Satz auf den Punkt: Jeder muss jetzt die Tech-Lead-Arbeit machen. Die Arbeit, die früher implizit beim Codeschreiben passierte, muss jetzt explizit erledigt werden. Designdenken, Schnittstellenverträge, Korrektheitsbeweise, Architekturentscheidungen.

Das ist keine neue Art von Arbeit. Es ist dieselbe Arbeit, die gute Software schon immer erfordert hat. Sie war nur im Prozess des Codeschreibens versteckt. Jetzt, da Code billig geworden ist, wird sichtbar, was eigentlich immer der teure Teil war: Korrektheit.

Die Kernaussage

Code ist billig geworden. Korrektheit nicht. Die Arbeit wurde nicht eliminiert. Sie wurde verschoben. Wer vorher durch manuelles Codeschreiben zum Nachdenken gezwungen wurde, muss jetzt bewusst die gleiche Denkarbeit leisten, nur expliziter.

Das bestätigt ein durchgängiges Muster in der aktuellen Diskussion. Matt Pocock trennt Planung und Ausführung in zwei strikt getrennte Phasen. Zen van Riel betont, dass agentisches Engineering eine Haltungsfrage ist, keine Tool-Frage. Und die Forschung zeigt, dass die kognitive Belastung steigt, weil die Denkarbeit zum Vollzeitjob wird.

Edgars ergänzt diese Perspektiven um eine entscheidende Nuance: Die Langsamkeit war kein Bug. Sie war ein Feature. Und wir müssen einen Weg finden, das, was sie geleistet hat, in der neuen Welt des agentischen Codings bewusst nachzubauen.