KI macht anders k.o.: Entwickler-Alltag mit einem Agententeam

Seit Monaten hab ich keine Zeile Code mehr geschrieben und bin trotzdem jeden Tag Softwareentwickler. Ein Bericht von einer Mauer aus Waschbeton über den Entwickler-Alltag mit KI-Agenten: Müdigkeit, Tiefe und die Frage, was von mir übrig bleibt.

Waschbeton, und irgendwer hat die Mauer mal besprüht. Das Graffiti ist so verblasst, dass man nur noch ahnt, was da mal stand. Ich sitz obendrauf, Füße hochgelegt, Jeans, Trekkingschuhe mit orangen Schnürsenkeln. Vor mir ein Tablet im Ständer, daneben eine kleine Bluetooth-Tastatur. Wenn du auf dem Foto oben genau hinguckst, erkennst du auf dem dunklen Bildschirm eine Chat-Oberfläche: Da drin sitzt mein Team.

Hinter dem Tablet kommt erst Wiese, dann ein paar Büsche, und dann geht der Blick weit raus über Felder und Wälder bis zum Horizont. Die Sonne steht tief, es ist leicht diesig. Man könnte das für ein Urlaubsfoto halten. Einer, der so dasitzt, arbeitet doch nicht, oder?

Doch. Das Foto zeigt ziemlich genau, was sich verändert hat. Mein Entwickler-Alltag mit KI hat mit dem, was ich fast 20 Jahre lang unter Arbeit verstanden hab, nur noch wenig zu tun. Klingt nach Prospekt, ich weiß. Ich versuch es deshalb der Reihe nach, ahne aber jetzt schon, dass die Reihe nicht hält.

Zehn Stunden tippen, das war einmal

Ich schreib den Satz einfach mal hin, weil er sich immer noch komisch anfühlt: Seit Monaten habe ich keine Zeile Code mehr geschrieben. Ich sitz nicht mehr zehn Stunden vorm Computer und schreibe Code herunter, Funktion für Funktion, Klammer auf, Klammer zu. Keine zehn Stunden mehr programmieren, sondern orchestrieren: Ich beschreibe, was gebaut werden soll, und KI-Agenten bauen es.

Komisch fühlt sich das an, weil „Entwickler“ für mich immer hieß: der, der tippt. Wer den Code schreibt, hat ihn verstanden, und wer ihn verstanden hat, ist der Entwickler; so ungefähr ging die Gleichung. Mein Alltag als Softwareentwickler besteht heute aus Reden, Lesen, Entscheiden und Abnehmen, und die Gleichung geht trotzdem irgendwie noch auf. Erst mal zu den Kollegen.

Mein Team besteht aus KI-Agenten, und ich besetze es jeden Tag neu

Ich hab ein ganzes Team um mich geschart: Entwickler, Designer, Projektleiter, Code-Reviewer, Tester, Qualitätssicherer und noch ein paar Rollen mehr. Alles KI-Agenten, jeder mit eigenem Auftrag und eigenem Blick auf die Sache. Wie ich die Agenten technisch orchestriere, steht in einem eigenen Artikel; dort darf dann auch das Wort Vibe Coding fallen. Hier interessiert mich, was das Ganze mit dem Arbeitstag macht.

Je nach Aufgabe stelle ich daraus ein individuelles Team zusammen. Ein kleiner Fehler in einem Formular braucht keinen Designer; eine neue Anwendung für einen Kunden braucht ihn, dazu jemanden, der vorher recherchiert, und mehrere, die hinterher prüfen. Ich lasse Infos recherchieren, analysiere Kundenprobleme und Prozesse und lasse daraus Software bauen. Am ehesten bin ich dabei so etwas wie der Polier auf der Baustelle: Ich mauere nicht mehr selbst, aber ich weiß, wie eine gerade Wand aussieht, und ich merke, wenn einer das Fundament vergessen hat.

Auch dieser Beitrag ist übrigens so entstanden. Ich hab meine Gedanken hingeworfen, ein Lead-Agent hat sich einen Texter und einen SEO-Fachmann dazugeholt, die haben daraus einen Text gebaut, und ich hab ihn gelesen und freigegeben. Wie viel ich dazwischen noch umgeworfen hab, behalte ich für mich ;) Ich hab mir schon einmal einen eigenen KI-Assistenten gebaut; das hier ist die Fortsetzung mit mehr Personal.

Macht KI müde? Sie macht anders k.o.

Früher war ich teilweise nach vier Stunden durch. Vier Stunden hohe Konzentration, ein Problem mit all seinen Verästelungen im Kopf halten, und danach war da oben nur noch Matsch. Heute bin ich nach einem Acht-Stunden-Tag noch fit. Die vier Stunden hab ich mir übrigens nicht eingebildet: Anders Ericsson und Kollegen haben 1993 in ihrer Arbeit über gezieltes Üben bei Spitzenmusikern beobachtet, dass jenseits von etwa vier Stunden konzentriertem Üben am Tag nichts mehr dazukommt. Passt zu meinen vier Stunden, auch wenn Geige üben kein Programmieren ist.

Andere berichten allerdings genau das Gegenteil. Der Entwickler Simon Willison erzählt, dass er vier Agenten parallel startet und „by like 11 AM“ erledigt ist, „wiped out for the day“. Die Harvard Business Review hat im März 2026 sogar ein Wort dafür in Umlauf gebracht: „Brain Fry“, mentale Erschöpfung durch exzessive Nutzung oder Überwachung von KI, beschrieben anhand einer Befragung von 1.488 US-Beschäftigten. Und Addy Osmani schreibt in „Your parallel Agent limit“ von „comprehension debt“, also Verständnisschulden, und von einer Hintergrundunruhe namens „ambient anxiety“, wenn mehrere Agenten gleichzeitig laufen.

Ok, was denn nun? Die sind um elf platt, ich bin nach acht Stunden noch fit. Ich weiß nicht, warum das bei mir anders ist, und ich trau keinem, der es genau zu wissen behauptet. Vermutungen hab ich. Vielleicht sind das bei mir noch die Flitterwochen. Vielleicht fühlt sich nach Jahren der Tiefenkonzentration einfach alles leichter an, was keine ist. Vielleicht merk ich es auch nur noch nicht; darüber, warum Burnout zurückkommt, solange das System dasselbe bleibt, hab ich hier schon geschrieben.

Ja: KI macht anders k.o. Unberührt bin ich abends nämlich auch nicht. Die Müdigkeit kommt nur aus einer anderen Ecke: aus den vielen Entscheidungen, aus dem Wechsel zwischen den Themen, aus dem Dauerüberblick über Dinge, die parallel laufen. Früher war der Akku nach der Tiefenkonzentration leer wie nach einem langen Lauf. Heute fühlt es sich eher an wie nach einem Familienfest: körperlich nix gemacht, aber mit jedem geredet und jedem zugehört.

Mehrere Probleme am Tag statt eines pro Woche

Früher hab ich mich eine Woche lang auf ein konkretes Problem konzentriert. Heute streife ich mehrere Probleme pro Tag, und mein Agententeam geht in die Tiefe. Ich komme vorbei, stelle Fragen, lese Ergebnisse, entscheide und bin schon beim nächsten Thema, während hinter mir weitergegraben wird.

Was macht das mit einem? Erst mal macht es Spaß, das geb ich zu. Als Generalist kommst du plötzlich auf deine Kosten: Recherche, Prozessanalyse, Design, Architektur, Text, alles an einem Tag und immer mit jemandem an der Seite, der sich im Detail auskennt. Die Arbeit fühlt sich weniger nach Bergwerk an und mehr nach Redaktionskonferenz.

Eigentlich wollte ich in diesem Abschnitt die Breite feiern. Stelle aber gerade fest, dass mich etwas anderes beschäftigt: Ich streife. Das Wort hab ich eben selbst benutzt, und schmeichelhaft ist es eigentlich nicht. Wer streift, bleibt nirgends, und wer nirgends bleibt, kennt am Ende viele Dinge vom Sehen. Und damit bin ich bei der Frage, um die ich mich gern herumdrücke.

Wie viel eigene Tiefe brauche ich noch?

Der Kritikpunkt liegt auf der Hand: Man geht selbst nicht mehr in die Tiefe. Mein erster Reflex darauf ist ein Schulterzucken. Aber wie wichtig ist das wirklich? Tiefe war nie Selbstzweck, der Kunde bezahlt für eine Lösung, die funktioniert.

Ok, das ist zu billig. Ich kann nur deshalb beurteilen, was mein Team abliefert, weil ich fast 20 Jahre lang selbst gegraben hab. Eine wacklige Architektur erkenne ich am Geruch, und den Geruchssinn hab ich mir in genau den Wochen geholt, die ich heute nicht mehr brauche. Wovon zehrt einer, der diese Wochen nie hatte?

Dazu gibt es Zahlen, die mir nicht gefallen und die deshalb hier reingehören. Anthropic hat im Januar 2026 eine Studie mit 52 Entwicklern, die meisten davon Juniors, veröffentlicht: Im Verständnistest kam die Gruppe mit KI-Hilfe auf 50 %, die Kontrollgruppe auf 67 %, und die größte Lücke lag beim Debugging. Ausgerechnet ein KI-Hersteller misst also, dass man mit KI weniger versteht. Das ist der stärkste Einwand gegen alles, was ich hier schreibe. Ich hab die Tiefe von früher im Rücken; ein Berufseinsteiger hat die nicht.

Vielleicht reicht es, einmal tief gewesen zu sein. Vielleicht verdunstet das aber auch, wenn man es nicht mehr übt, wie eine Fremdsprache, die man nach der Schule nie wieder spricht. Vielleicht entsteht auch eine andere Tiefe, eine im Fragenstellen und Beurteilen. Was, wenn Tiefe einfach umzieht? Weiß ich nicht. Ich beobachte das bei mir und sag Bescheid.

„KI-Code ist schlecht“: Das stimmte einmal

Und jetzt zu euch, ihr Qualitätswächter in meiner LinkedIn-Timeline. „KI-generierter Code ist doch Schrott, das kann hinterher kein Mensch warten, und die Sicherheit, und die technischen Schulden, bla bla bla.“ Ja ja. Absolut. Ihr hattet sogar Zahlen auf eurer Seite: METR ließ im Sommer 2025 16 erfahrene Open-Source-Entwickler 246 Aufgaben erledigen, und mit KI waren sie 19 % langsamer, obwohl sie selbst an eine Beschleunigung glaubten. CodeRabbit zählte im Dezember 2025 in 470 Pull Requests bei den KI-Beiträgen im Schnitt 10,83 Auffälligkeiten, bei den menschlichen 6,45, also etwa Faktor 1,7. KI baut Mist, geschenkt. Ich hab fast 20 Jahre lang Mist gebaut, von Hand, jeder Bug ein Unikat, und dazu hat nie jemand eine Studie in Auftrag gegeben.

2025 konnte man das also so sagen. Nur ist seitdem etwas passiert, und man sieht es am besten an derselben Quelle. METR wollte die Studie wiederholen und nennt die eigenen neuen Daten im Update vom Februar 2026 ein unzuverlässiges Signal, unter anderem weil 30 bis 50 % der Entwickler manche Aufgaben gar nicht mehr einreichten: Sie wollten sie nicht ohne KI erledigen. Eine Studie kommt ins Schleudern, weil die Teilnehmer nicht mehr ohne KI arbeiten wollen. Wild. METR selbst hält es nach Gesprächen mit den Teilnehmern für wahrscheinlich, dass Entwickler Anfang 2026 stärker von KI beschleunigt werden als noch Anfang 2025. Simon Willison nennt den November 2025 als Wendepunkt, seitdem täten die Agenten fast immer, was man ihnen sagt, und rund 95 % seines Codes tippt er nach eigener Aussage nicht mehr selbst. Sundar Pichai sagte im April 2026, 75 % des neuen Codes bei Google seien KI-generiert und von Ingenieuren freigegeben, nach 50 % im Herbst davor.

Klar: Verbreitung ist kein Qualitätsbeweis. Eine unabhängige Messung, die für 2026 überragende Codequalität belegt, kenne ich nicht. Ich kann dir nur sagen, was ich jeden Tag sehe, und das ist das Gegenteil von dem, was in der Timeline steht: Bei mir ist die Qualität heute, 2026, überragend. Besser getestet und besser dokumentiert als vieles, was ich früher selbst abgeliefert hab.

Aus der Steckdose kommt das allerdings nicht. Die Qualität entsteht im Prozess: Der Entwickler-Agent schreibt, der Reviewer liest gegen, der Tester versucht es kaputtzumachen, und die Qualitätssicherung prüft gegen Abnahmekriterien, die ich vorher klar formuliert hab. Review bleibt Pflicht, auch meins ganz am Ende.

Niemand hat je 100.000 Zeilen überblickt

Hinter der Qualitätskritik steckt oft ein Bild, das nie gestimmt hat: der Entwickler, der sein System kennt wie seine Westentasche. Niemand braucht mir erzählen, er habe damals schon hunderttausend Zeilen Code überblickt. Das ist schlicht nicht wahr. Entwickler haben immer Fehler gemacht, Software war immer fehleranfällig, und einen großen Teil der Zeit haben wir damit verbracht, überhaupt zu verstehen, was da steht. Das ist sogar gemessen: Eine Feldstudie mit 78 Entwicklern (Xia und Kollegen, 2017) kam auf rund 58 % der Arbeitszeit, die allein fürs Verstehen von Code draufgehen.

Und wie haben wir Fehler gefunden? Oft gar nicht. Oft hat man nur reagiert, wenn ein Kunde sich gemeldet hat: Der Kunde war das Monitoring. Ich nehm mich da ausdrücklich nicht aus. Heute kannste eine Schar von Agenten auf den Code loslassen und Fehler finden, bevor der Kunde das tut. Heute kannste Code in Sekunden überblicken, den früher niemand überblickt hat. Wie weit das trägt, hat die AI Cyber Challenge der DARPA gezeigt: Im Finale im August 2025 durchsuchten die Systeme 54 Millionen Zeilen Code, fanden 54 von 63 absichtlich eingebauten Schwachstellen und obendrauf 18 echte, die vorher niemand kannte. Bei 54 Millionen Zeilen hätte ich mich früher schon im ersten Verzeichnis verlaufen.

Der Bus-Faktor, über den die Kritiker schweigen

Der Bus-Faktor ist die Zahl der Leute, die vom Bus überfahren werden dürfen, bevor ein Softwareprojekt stillsteht, weil das Wissen weg ist. In der Forschung heißt er auch Truck Factor, und er ist erschreckend niedrig: Avelino und Kollegen haben 2016 133 populäre GitHub-Projekte untersucht, und 65 % davon hatten einen Truck Factor von höchstens 2.

Das sind Open-Source-Projekte. Für kleine Firmen kenne ich keine Studie, dafür kenne ich kleine Firmen. In vielen gab es nur einen oder zwei Entwickler, und war der weg, war das Know-how weg. Zurück blieb Code, den keiner mehr anfassen wollte. Über dieses Risiko hab ich in all den Qualitätsdebatten erstaunlich wenig gelesen: Der handgeschriebene Code eines einzelnen Menschen galt als solide, obwohl das ganze Verständnis dafür an einem einzigen Arbeitsvertrag hing.

Heute übernimmt KI. Ein Agent liest sich in eine Codebasis ein, die er nie gesehen hat, erklärt sie dir, dokumentiert sie nach und baut darin weiter. Das Know-how steckt damit weniger in einem Kopf und mehr im Code, in den Tests und in der Dokumentation. Ganz ohne Menschen geht es trotzdem nicht; irgendwer darf weiterhin wissen, was die Firma eigentlich will. Aber vor dem Bus hab ich deutlich weniger Respekt als früher.

Gerade auf dem Tisch: Traffalyzer, erst als Drupal-Modul, jetzt als WordPress-Plugin

Damit das nicht im Ungefähren bleibt: Aktuell arbeite ich an einem Traffalyzer WordPress-Plugin, nachdem ich vor ein paar Tagen das Traffalyzer Drupal-Modul entwickelt hab. Traffalyzer ist mein eigenes SEO-Tool: Du gibst auf traffalyzer.com deine Domain ein und bekommst einen kostenlosen ersten Scan, ohne Account. Warum ich Traffalyzer gebaut habe, hab ich an anderer Stelle aufgeschrieben, und wo das Modul zwischen den anderen steht, zeigt mein Vergleich der Drupal-SEO-Module.

Zum WordPress-Plugin gibt es noch keinen Link; es ist in Arbeit, und versprechen tu ich hier nichts. Interessant finde ich ohnehin etwas anderes: Das sind zwei Systeme mit eigenen Regeln und eigenen Fallstricken, und zwischen beiden liegen nur ein paar Tage. Nach der alten Rechnung, ein Problem pro Woche, säße ich vermutlich noch am ersten. Und ja, genau hier ploppt die Frage von oben wieder auf: Wie tief stecke ich selbst in dem, was da entsteht? Tief genug, um zu beurteilen, was geliefert wird, glaub ich zumindest.

Was bleibt von mir als Entwickler?

Wenn ich nicht mehr tippe und nicht mehr selbst in die Tiefe gehe: Was mach ich dann eigentlich den ganzen Tag? Aufgeschrieben ist mein Entwickler-Alltag mit KI weniger spektakulär, als das ganze Agenten-Gerede vermuten lässt:

• das Problem des Kunden verstehen, bevor irgendwer etwas baut
• das passende Team für die Aufgabe zusammenstellen
• Abnahmekriterien so klar formulieren, dass sich keiner rausreden kann
• Ergebnisse lesen, nachfragen, entscheiden
• am Ende den Kopf dafür hinhalten

Den letzten Punkt nimmt mir kein Agent ab. Wenn etwas schiefgeht, ruft der Kunde mich an und keinen Reviewer-Agenten. Verantwortung lässt sich schlecht delegieren, Urteilskraft auch, und beides speist sich bei mir aus den Jahren, in denen ich selbst getippt hab (wer ich bin und wo ich herkomme, steht auf der Seite über mich). Meine Rolle als Entwickler ist die eines Generalisten geworden. Spezialwissen hole ich mir dazu, wenn ich es brauche; die Frage, was gebaut werden soll und warum, bleibt an mir hängen.

Ob das in ein paar Jahren noch Softwareentwickler heißt, weiß ich nicht, und es ist mir auch ein bisschen wumpe. Auf dem Foto oben steht die Sonne tief, das Tablet ist so ziemlich das Kleinste im ganzen Bild, und die Füße liegen hoch. Wie viel eigene Tiefe der Typ auf der Mauer noch braucht, frag ich ihn in einem Jahr nochmal.

Häufig gestellte Fragen zum Entwickler-Alltag mit KI

Wie verändert KI den Alltag von Softwareentwicklern?

KI verschiebt den Alltag von Softwareentwicklern vom Programmieren zum Orchestrieren: Der Entwickler beschreibt, was gebaut werden soll, und KI-Agenten bauen es. Mein eigener Arbeitstag besteht heute aus Reden, Lesen, Entscheiden und Abnehmen. Statt eine Woche an einem Problem zu sitzen, streife ich mehrere Probleme am Tag, und das Agententeam geht in die Tiefe.

Macht die Arbeit mit KI-Agenten müde?

Ja, die Arbeit mit KI-Agenten macht müde, aber auf andere Art als konzentriertes Programmieren. An die Stelle der Tiefenkonzentration treten Entscheidungen, Kontextwechsel und Dauerüberblick. Ich selbst bin nach einem Acht-Stunden-Tag mit Agenten fitter als früher nach vier Stunden Code.

Verlernt man das Programmieren, wenn KI den Code schreibt?

Berufseinsteiger bauen mit KI-Hilfe laut einer Anthropic-Studie weniger Code-Verständnis auf als ohne. In der Untersuchung mit 52 Entwicklern, überwiegend Juniors, erreichte die KI-Gruppe im Verständnistest 50 %, die Kontrollgruppe 67 %. Ob erfahrene Entwickler ihre Tiefe verlieren, wenn sie sie nicht mehr üben, ist offen.

Ist KI-generierter Code schlechter als menschlicher?

KI-generierter Code ist so gut wie der Prozess, in dem er entsteht. Auswertungen aus 2025 wie die von CodeRabbit fanden in KI-Pull-Requests etwa 1,7-mal so viele Auffälligkeiten wie in menschlichen. Meine Erfahrung 2026 ist eine andere: Mit Reviewer-, Tester- und QA-Agenten und klaren Abnahmekriterien ist die Codequalität bei mir höher als früher von Hand. Unabhängig gemessen ist das bisher nicht.

Was macht ein Entwickler noch, wenn KI programmiert?

Ein Entwickler, der mit KI-Agenten arbeitet, versteht Probleme, formuliert Aufträge und Abnahmekriterien, prüft Ergebnisse und trägt die Verantwortung. Wegfallen tut vor allem das Tippen. So entstehen gerade auch das Drupal-Modul und das WordPress-Plugin für Traffalyzer, mein SEO-Tool.

Was ist der Bus-Faktor in der Softwareentwicklung, und senkt KI das Risiko?

Der Bus-Faktor gibt an, wie viele Personen ausfallen dürfen, bevor ein Softwareprojekt mangels Wissen stillsteht. Laut Avelino et al. (2016) liegt er bei 65 % von 133 untersuchten populären GitHub-Projekten bei höchstens 2. KI-Agenten entschärfen dieses Risiko, weil sie sich schnell in fremden Code einlesen, ihn erklären und nachdokumentieren können.

Werden Softwareentwickler durch KI ersetzt?

Nach meiner Erfahrung ersetzt KI das Schreiben von Code, während sich der Beruf des Softwareentwicklers zum Orchestrieren, Beurteilen und Verantworten verschiebt. Bei Google sind laut Sundar Pichai 75 % des neuen Codes KI-generiert; freigegeben wird er weiterhin von Ingenieuren.

Generalist oder Spezialist: Wer ist als Entwickler mit KI gefragt?

In der Softwareentwicklung mit KI-Agenten ist eher der Generalist mit Erfahrung gefragt als der Spezialist für ein einziges Framework. Spezialwissen wird leichter verfügbar, weil KI-Agenten es mitbringen; wertvoller wird die Fähigkeit, Ergebnisse zu beurteilen. Offen bleibt für mich, woher diese Urteilskraft kommt, wenn niemand mehr selbst in die Tiefe geht.