Was passiert mit uns, wenn AI den Code schreibt?

Wer Software-Code selbst schreibt, versteht ihn deutlich besser als jemand, der ihn nur liest. Das klingt nach einer Randnotiz aus der Kognitionsforschung. Ist aber ein Kernproblem in der Debatte um Agentic Software Engineering, das zu wenig diskutiert wird. Denn die erste Frage lautet doch meist: Werden Devs überflüssig, wenn AI den Code schreibt? Die Antwort ist nein. Aber das Warum ist komplizierter, als es zunächst aussieht.

Rollen verschieben sich

Klar ist: Code zu schreiben war das Kernhandwerk im Entwicklungszyklus (SDLC), das wir jetzt an AI delegieren können. Weniger klar ist, welche Konsequenzen das für uns selber hat.

Zum Beispiel diese hier: Will ich einem Code-Agenten sagen, was ich von ihm benötige, brauche ich ein Qualitätsverständnis, das ich früher nicht explizit formulieren musste. Was bedeutet guter Code in meinem spezifischen Kontext? Wie erkenne ich, ob das Ergebnis in sechs Monaten noch handhabbar ist, wenn jemand anderes daran weiterarbeitet? Das waren Fragen, die ich beim Schreiben mitbeantwortet habe – intuitiv, durch Erfahrung, durch das Gefühl für den Code. Jetzt müssen sie gestellt und präzise beantwortet werden.

Gleichzeitig verlieren syntaktische Unterschiede zwischen Programmiersprachen an Gewicht. Frontend oder Backend, Java oder TypeScript – wenn präzise Anforderungen die Basis bilden, kann der Code-Agent vieles davon erzeugen. Der Wert verschiebt sich hin zum Denken über Software-Architekturen und -Qualität. Generalisten, die theoretische Konzepte über Sprachgrenzen hinweg anwenden, werden relevanter. Das klingt nach einer Aufwertung des Dev-Profils und in gewisser Weise ist es das auch.

Was dabei verloren geht

Die Kehrseite der Medaille sieht allerdings so aus: Ich starte drei Projekte in drei Sessions und bekomme hunderte Zeilen Code zurück, mit dem mich keine Entwicklungserfahrung verbindet. Ich muss ihn lesen, reviewen, bewerten. Das ist anstrengend auf eine Art, die sich vom Selberschreiben grundlegend unterscheidet. Motivation oder reine Erfahrung drücken das nicht weg. Je mehr Code ein Agent erzeugt, desto größer die Gefahr, dass Fehler ins Produktivsystem gelangen. Die kognitive Belastungsfähigkeit hat eine Grenze.

Teams, die früher mit fünf oder sechs Devs gearbeitet haben, können plötzlich so viel Code produzieren, dass die Review zum Engpass wird. Wer zu viel gleichzeitig will, liest irgendwann nur noch. Womit wir wieder beim Anfang wären.

Schreiben verankert. Lesen streift. Wer Code selbst entwickelt, ihn ausprobiert und Zwischenstände testet, verbindet sich mit diesem auf einer Ebene, die pures Lesen nicht erreicht. Das Schreiben ist schlicht die tiefere Stufe der Verarbeitung. 

Was das bedeutet

Die Menge Code, die ein Agent erzeugt, darf deshalb die Menge nicht übersteigen, die ein Team wirklich überprüfen kann – mit der notwendigen Aufmerksamkeit und der erforderlichen Tiefe, die unseren Qualitätsansprüchen gerecht wird. Wie sich das strukturell lösen lässt, ist eine offene Frage, die wir gerade bearbeiten. Zum Beispiel mit kleineren Teams, um die reine Menge an Output auf ein verarbeitbares Maß zu reduzieren. 

Was jetzt schon klar ist: Es braucht neue Routinen. Wer jahrelang gelernt hat, Code selbst zu schreiben, dem fällt es schwer, nur noch zu lesen. Das Reinfuchsen in fremden, von Agenten generierten Code ohne eigene Entstehungsgeschichte dahinter erfordert strenge Disziplin. Diese Form der Selbstregulation wird für uns mindestens so wichtig wie die Selbstorganisation.

Seit November 2025 arbeiten wir bei sipgate systematisch daran: Workshops, konkrete Ziele, ein Rahmen, der Ausprobieren ermöglicht, ohne den Datenschutz zu gefährden. Ob das eine Strategie ist? Das Wort passt halb. Genauer gesagt ist es ein Kulturwandel. Und der gelingt vor allem mit hoher intrinsischer Motivation.

Why we choose freedom

sipgate war in Deutschland ein Wegbereiter für agiles Arbeiten – durch ehrliche Dokumentation, was funktioniert hat und was nicht. Im Bereich Agentic Software Engineering könnte das wieder gelingen. Einblicke veröffentlichen, Erkenntnisse teilen, auch die unbequemen. Wandelbarkeit lässt sich nicht anordnen. Wir müssen sie gut vorbereiten und begleiten. Darin liegt die eigentliche Aufgabe. 

‍