Die meisten Gespräche über KI in der Softwareentwicklung drehen sich um den Output – mehr Code, schnellere Releases, kürzere Sprints. Weniger Beachtung findet, was mit der Person passiert, die diesen Code schreibt, und wie sich der Job selbst verändert, während niemand hinsieht.

Ich erlebe diesen Wandel seit anderthalb Jahren, über mehrere Projekte hinweg, in denen KI-Agenten vom Helfer im Chatfenster zu einem vollwertigen Teilnehmer in der Codebasis wurden.

In dieser Zeit haben sich sowohl die Tools als auch meine Rolle ständig verändert. Inzwischen ist eines klar: Der Job, den ich heute habe, ist nicht mehr derselbe, mit dem ich angefangen habe. Der Wandel begann langsam, nahm dann aber schnell Fahrt auf.

Ich hatte nicht vor, jemand zu werden, der überwiegend den Code eines Agenten überprüft, anstatt selbst zu schreiben. Es geschah Projekt für Projekt, Tool für Tool. Im Rückblick würde ich diese Gedanken für alle festhalten, die denselben Weg erkunden wollen – oder einfach die Perspektive eines anderen Menschen suchen.

#1 Ein Sprung nach dem anderen

Die erste Phase konnte man kaum als agentisch bezeichnen. Ich nutzte Chat-KI hauptsächlich, um die kleineren, mechanischeren Teile der Arbeit zu beschleunigen: Snippets einfügen, um einem Problem nachzugehen, während ich mich auf die größere Aufgabe konzentrierte, um eine Hilfsfunktion oder einen kleinen Algorithmus bitten, oder einfach Codeschnipsel abgeben, die es nicht wert waren, von Grund auf selbst geschrieben zu werden. Sicherheitsvorgaben machten selbst das bei manchen Projekten umständlich, sodass Beispiele mitunter von ihrem Kontext befreit oder so verändert werden mussten, dass der eigentliche Code weniger erkennbar war. Es war nützlich und sparte Zeit, aber nur in kleinen Dosen. Alles musste noch manuell durch das Chatfenster und zurück in die Codebasis wandern, was der Skalierbarkeit dieser Arbeitsweise eine ziemlich harte Grenze setzte.

Der nächste Schritt war die erste Generation agentischer Coding-Tools wie Cursor. Die KI zog in den Editor ein, erhielt Zugriff auf den umgebenden Code und konnte Änderungen direkt vorschlagen oder vornehmen, anstatt darauf angewiesen zu sein, dass ich Snippets hin- und herschiebe. Damals fühlte sich das wie ein bedeutender Sprung an.

Dann kam die aktuelle Generation agentischer Tools, mit Claude als gutem Beispiel: verbunden nicht nur mit der Codebasis, sondern auch mit dem Ticketing-System und der Versionsverwaltung. Ab diesem Punkt bestand die Arbeit an den meisten Tagen nicht mehr darin, Code zu schreiben, sondern darin, zu entscheiden, was gebaut werden sollte, und zu prüfen, ob es richtig gebaut wurde.

#2 Output ist nicht mehr der Punkt

Den größten Teil meiner Karriere war das, was ich produzierte, Code. Geschriebene Zeilen, ausgelieferte Features, behobene Bugs. Heute produziere ich eher eine Richtung: wie das Ergebnis aussehen soll, welche Rahmenbedingungen gelten, wann etwas gut genug ist, um ausgeliefert zu werden, und wann nicht.

Das ist eine andere Fähigkeit als die, für die ich ausgebildet wurde. Guten Code zu schreiben und zu beurteilen, ob Code, den jemand (oder etwas) anderes geschrieben hat, tatsächlich das richtige Problem löst – das ist nicht derselbe Muskel. Den zweiten baue ich noch auf.

#3 Die Grenzen zwischen den Rollen verschwimmen

Ich habe beobachtet, wie sich das über die Softwareentwicklung hinaus ausgebreitet hat. Eine Designerin in einem unserer Projekte begann, kleine Codeänderungen direkt selbst vorzunehmen, weil der Agent die Umsetzung übernehmen konnte, sobald sie beschrieben hatte, was sie wollte. Eine Projektmanagerin schreibt Tickets, die bereits eine grobe technische Aufschlüsselung enthalten, weil sie den Agenten bitten kann, den Ansatz zu prüfen, bevor er überhaupt bei einem Entwickler landet.

Nichts davon wäre möglich gewesen, ohne dass ein Entwickler selbst bei den kleinsten Änderungen eingebunden war. Ich glaube nicht, dass das bedeutet, dass diese Rollen ineinander verschmelzen. Es bedeutet, dass sich der Engpass verschoben hat: Die technische Umsetzung ist günstiger geworden, und das Urteilsvermögen darüber, was es wert ist, gebaut zu werden, ist für alle im Team wertvoller geworden – nicht nur für Entwickler.

#4 Was ich dafür aufgegeben habe

Ich möchte ehrlich sein – ein Teil davon ist kein klarer Gewinn. Ich kenne diese Codebasis weniger intim, als ich früher die kannte, die ich von Hand geschrieben habe. Wenn um zwei Uhr morgens etwas an einem System kaputtgeht, das ich größtenteils überprüft statt geschrieben habe, fehlt mir das Gespür dafür, wo ich zuerst nachsehen sollte – das Gespür, das ich bei Code hätte, den ich selbst, Zeile für Zeile, getippt habe.

Das ist ein echter Preis. Der Kompromiss ergibt nur Sinn, wenn das, was dieses Gespür ersetzt – Tests, Regeln, Dokumentation, die aktuell bleibt – tatsächlich zuverlässig genug ist, um das aufzufangen, was früher mein Bauchgefühl aufgefangen hat. An den meisten Tagen ist es das. Ob es das immer sein wird, weiß ich nicht.

#5 Was unverändert bleibt

Egal wie gut die Tools werden, jemand muss das Fundament trotzdem von Hand legen. Dieser Teil hat sich nicht verändert, und ich glaube nicht, dass er sich verändern wird.

Mein bisher agentischstes Projekt war ein Greenfield-Projekt, was nach dem einfachen Fall klingt: kein Legacy-Code, keine alten Muster, gegen die man ankämpfen muss. In der Praxis waren die ersten zwei bis drei Wochen das Gegenteil von reibungslos. Der Agent hatte keine bestehende Codebasis, aus der er lernen konnte, keine Muster, denen er folgen konnte, sodass frühe architektonische Entscheidungen deutlich mehr manuelle Korrektur brauchten, als ich zu Beginn erwartet hatte.

Sobald dieses Fundament stand, hatte der Agent eine Grundlage, von der aus er schlussfolgern konnte, und das Tempo veränderte sich vollständig. Ich glaube nicht, dass diese anfängliche Reibung ein Versagen des Ansatzes war. Es ist die eigentliche Form davon, Dinge gut zu machen, unabhängig vom Framework: langsamer am Anfang, schneller sobald die Grundlage solide steht. Die Tools haben sich verändert. Die Notwendigkeit, dass jemand dieses erste Fundament sorgfältig legt, nicht.

#6 Wie Anpassungsfähigkeit tatsächlich aussieht

Wenn es eine Sache gibt, die ich einem Entwickler sagen würde, der diesen Wandel beginnt, dann die: Das Unbehagen in den ersten Wochen ist kein Zeichen dafür, dass man etwas falsch macht. Eine Fähigkeit, in der man sicher ist, gegen eine einzutauschen, die man noch aufbaut, soll sich erst schlechter anfühlen, bevor es besser wird. Die Tools haben sich schneller verändert als jeder frühere Wandel, den ich in diesem Job erlebt habe. Was sich nicht verändert hat: Jemand muss trotzdem entscheiden, was es wert ist, gebaut zu werden – und bereit sein, „noch nicht“ zu sagen, wenn der Agent zuversichtlich, aber falsch liegt.

#7 Eine Frage an mein zukünftiges Ich

Sehe ich mich noch als Programmierer? Ja, solange ich glaube, dass ich immer noch zurückkönnte zum Codeschreiben, Zeile für Zeile. Aber es gibt Tage, an denen das, was ich tatsächlich getippt habe, das nicht beweisen würde. Vielleicht ist das der eigentliche Wandel: Früher wurde der Job daran gemessen, was ich geschrieben habe, heute daran, wofür ich bereit bin, geradezustehen. Ist das ein fairer Tausch? Fragt mich in sechs Monaten noch einmal.