Die Diskussion über AI in der Softwareentwicklung dreht sich fast immer um dieselbe Frage: Ersetzt die Maschine den Entwickler? Ist die falsche Frage, weil sie unterstellt, dass das Schreiben von Code der Kern der Arbeit eines Software-Entwicklers gewesen sei. War es tatsächlich aber nie. Und je besser die Maschinen Code schreiben, desto klarer wird, worin die Arbeit wirklich besteht: entscheiden, was gebaut werden soll, und prüfen, ob das Gebaute funktional stimmt und auch für die Nutzer das Richtige ist.
AI schreibt mittlerweile Code in guter Qualität
Wie schnell die Entwicklungen sprichwörtlich gerade sind, lässt sich auf der Coding-Plattform GitHub live beobachten: Claude Code allein ist für 4% aller Commits weltweit verantwortlich, Prognose bis Ende des Jahres: 20%. Let that sink in! 1
Und die Qualität ist nicht schlecht! Laut Stanford University sind die besten Modelle bei einem Test mit echten Programmieraufgaben aus großen Softwareprojekten innerhalb eines Jahres von 60 auf nahezu 100 Prozent Lösungsrate gesprungen.2 Dario Amodei, Chef von Anthropic, schreibt in einem Essay vom Juni 2026:
„AI-Modelle sind in nur vier Jahren von kaum einer brauchbaren Zeile Code dahin gekommen, den größten Teil des Codes in den großen AI-Unternehmen zu schreiben."
Wenn das Coden in guter Qualität automatisch geht, verschwindet das Bottleneck nicht, sondern verschiebt sich (wie das Bottlenecks so an sich haben) stromaufwärts - zu den Requirements Engineers und Product Ownern. Ich kenne einige Teams, deren Backlogs einfach leer sind. Und genau jetzt entscheidet sich, welche Entwicklungsteams von AI profitieren und es schaffen, schneller Nützliches zu liefern.
Super, lasst uns Geld sparen!
Und schon setzt der typische Sparreflex in Organisationen ein, nach dem Motto: Code schreiben geht jetzt von alleine und Tokens sind teuer, also brauchen wir weniger Entwickler:innen. Dieser Schluss übersieht, was Softwareentwicklung eigentlich bedeutet. Das Tippen war immer nur ein Teil des Zyklus. Der Rest ist Verstehen, Abstimmen, Testen, Prüfen, Integrieren, Betreiben. Wer nur den Coding-Teil beschleunigt, beschleunigt nicht das System. Er verlagert die Last.
Der DORA-Report (Frühjahr 2026) von Google sagt: Organisationen durchlaufen nach der Einführung von AI-Werkzeugen zunächst eine J-Kurve: Die Produktivität sinkt, bevor sie steigt, unter anderem wegen einer "Verification Tax", einer Prüfsteuer, weil Review- und Testprozesse mit dem gestiegenen Code-Volumen nicht Schritt halten.
„AI erzeugt lokale Produktivitätsinseln, die im nachgelagerten Chaos oft wieder verloren gehen."
Was die XP-Community schon wusste
Hier lohnt ein Blick 20 Jahre zurück an die Anfänge meiner Karriere, denn nichts an dem, was hier vielerorts schief läuft, ist neu. Das Konzept hieß Shift Left. Qualität nicht am Ende prüfen, sondern an den Anfang bringen - an den Punkt, wo die Software noch gar nicht geschrieben wurde. Aus dem eXtreme Programming kamen testgetriebene Entwicklung und später Behaviour Driven Development, beide mit derselben Grundidee: Erst sagen, was richtig ist, dann bauen.
Meine Rolle als XP-Coach bestand damals aus zwei Dingen: a) Entwicklungsteams die Best Practices des Codens/Testens/Denkens/Kommunizierens/Miteinanders beizubringen, und b) ihren Führungskräften beizubringen, wie gute Softwareentwicklung funktioniert, und wie nicht.
2012 saß ich in einem Workshop von Gojko Adzic zum Thema Specification by Example, um mich herum lauter arme Skype-Entwickler, deren Vorgabe lautete: Macht Skype Mobile genauso wie Skype Desktop. Wir wissen mittlerweile, wie gut das funktioniert hat :D
„The best code is no code at all."
Atwoods Begründung ist zeitlos: Jede neue Zeile Code, die man in die Welt setzt, muss gelesen, verstanden, debuggt und gepflegt werden. Weniger Code ist kein Mangel an Fleiß, es ist ein Qualitätsmerkmal.
Fun Fact am Rande: der überaus unterhaltsame AI-Skill ponytail kodiert genau dieses Wissen, in Form eines genervten Senior-Developers. Die Best Practice von damals ist in den Maschinen angekommen.
Warum diese Zeitreise? Weil Andrej Karpathy, einer der prägenden Köpfe des Feldes und meines Erachtens ein visionäres Genie, in diesem Jahr den Twist auf den Punkt gebracht hat:3
„Klassische Computer automatisieren, was man in Code spezifizieren kann. Diese neue Generation von Modellen automatisiert, was man verifizieren kann."
Und das schärfste Verifikationsinstrument der Softwareentwicklung sind nun mal automatisierte Tests.
Und plötzlich kommt die alte XP-Tugend flott im neuen Gewändchen daher. Testgetriebene Entwicklung, jahrelang eine Qualitätspraxis, zu der man Teams überreden musste, wird zur Voraussetzung für gute Software. Wenn die Maschine den Code erzeugt, ist der Test die Stelle, an der ein Mensch festlegt, was richtig überhaupt bedeutet. Der Test ist nicht mehr die Kontrolle nach der Arbeit. Er ist die Spezifikation vor der Arbeit. Was die XP-Community vor über zwanzig Jahren zum Standard erklärt hat, findet heute dank AI endlich Einzug in die Software-Entwicklungs-Teams. Heureka.
Niemand braucht mehr manuelle Code Reviews
Während die Maschinen liefern, staut es sich an einer Stelle, die in kaum einer AI-Strategie vorkommt: beim Code-Review. Ich habe kürzlich mit einem Team gearbeitet, dessen Lead Developer vollkommen Land unter war, weil der Rest des Teams ihn mit Code-Reviews überschüttet hat.
Und zu genau dem Punkt kommt eine aktuelle BCG-Arbeitsmarktstudie: 47 Prozent der Beschäftigten, die regelmäßig mit AI arbeiten, verbringen inzwischen mehr Zeit damit, AI-Ergebnisse zu prüfen und zu korrigieren, als die Arbeit selbst zu erledigen.4 Tja, Code-Reviewer willst du wirklich nicht sein, diese Tage - falsche Job Description.
Fazit: Manuelle Code-Reviews machen keinen Sinn mehr. Man kann heute Armadas von Agenten auf jegliche Änderung loslassen: ein Agent prüft Clean Code, ein anderer Performance, Design, Sicherheit. Und zwar - unlike humans - jede Zeile, jedes Mal, ohne Ermattungserscheinungen.
Die menschliche Aufmerksamkeit, die knappste Ressource im Team, gehört nicht in das Abklopfen von Clean Code. Henry Ford hat mal gesagt "No man should be forced to do manually what a machine can do" (oder so ähnlich). Wir Menschen sollten das tun, wo wir unersetzlich sind (und hoffentlich bleiben werden): Gute Ideen haben, Risiken abschätzen und eingehen, und: Entscheiden.
Testautomatisierung - almost Free Lunch
Wie gut das automatische Code-Schreiben schon klappt, hat gerade ein Beispiel gezeigt, das man sich auf der Zunge zergehen lassen sollte: Stripe hat mit Claude Fable 5 (bevor es vom US Government für zwei Wochen aus dem Verkehr gezogen wurde) eine Migration quer durch eine Codebasis von 50 Millionen Zeilen an einem einzigen Tag durchgezogen, wofür ein Team sonst über zwei Monate gebraucht hätte.5 Die Teams, in denen ich früher unterwegs war, hätten das gar nicht erst probiert.
Mit einem dichten Netz automatisierter Tests wird so eine Migration vom Blindflug zum Tagesprojekt. Das ist - gelinde gesagt - ganz schön krass.
Die gute Nachricht: Mit ein wenig List und Tücke bekommt man viele dieser Tests geschenkt. Sie lassen sich nämlich sauber aus Akzeptanzkriterien ableiten. Genau hier kommen die Produktleute ins Spiel. Akzeptanzkriterien waren bisher Prosa im Ticket - vom Entwickler gelesen, (fehl-)interpretiert und in Code übersetzt, den kein Produktler mehr versteht. In einem AI-gestützten Team wird diese Prosa direkt zum automatisch ausführbaren Akzeptanztest. Die Qualität der Produktarbeit sickert ungefiltert in die Software. Schöne neue Welt.
Meine Hypothese: Die Software, die wir in nicht allzu langer Zeit sehen werden, ist besser als das, was 95 Prozent aller Teams jemals hinbekommen haben. Und mit all der Testautomatisierung kann dann auch viel öfter released werden. Softwareentwicklung wird für viele Firmen, die sich engagieren, mega schnell werden, nicht nur für Amazon, Google, Netflix & Co.
Die neue Rangordnung: Verification over Coding
Testen und Qualitätssicherung, schon bevor der Code geschrieben wird, sind nun also wichtiger, als die Software selbst zu schreiben.
Wer die Fähigkeit hat, richtig gut zu beschreiben, was er haben will (funktional und nicht-funktional), trägt in einem AI-gestützten Team mehr zur Geschwindigkeit bei als der, der schnell tippt.
Das ist keine Abwertung des Entwicklerberufs, es ist eine Verschiebung innerhalb des Berufs. Es wird immer Ecken geben, in denen Senior-Entwickler nicht wegzudenken sind. Aber es gibt Milliarden von Zeilen Code, die eine AI schlicht besser schreibt. Der Job wandelt sich: hin zu Data Engineers, LLM Engineers, Evaluations-Ingenieuren, Architekten und Dirigenten ganzer Agenten-Teams. Stellenprofile, die auf Programmiersprachen-Kenntnisse optimieren, gibt's nur noch in Nischen. Persönlich kann ich's nur gut heißen, wenn Tester nicht mehr - wie leider viel zu oft - auch bezahlungsmäßig nur 2nd Class Citizens sind, Ausputzer am Ende der Pipeline.
Wird am Ende alles agentisch?
Bleibt die Frage, wie weit der momentane Trend noch trägt. Die Werkzeuge greifen längst über das Coden hinaus: Bei Gartner erzählen sie, wie AI-Agenten sich vom Code-Schreiben über den gesamten Entwicklungsprozess ausbreiten, von der Anforderung über den Test bis zur Auslieferung.6 Es ist keine Science-Fiction mehr, sich eine Pipeline vorzustellen, in der Agenten spezifizieren, bauen, testen und sich gegenseitig reviewen. Eine Art "Spec-Dev-Ops-Agent" also.
Boris Cherny, der Kopf hinter Claude Code, hat es im Februar in Lenny Rachitskys Podcast so gesagt:
„Coding ist weitgehend gelöst. Zumindest für die Art von Programmierung, die ich mache, ist es ein gelöstes Problem, weil Claude es kann."
An dieser Stelle teilt sich das Feld in zwei Lager. Das eine hält die vollständig agentische Entwicklung für schaffbar: Der Mensch verlässt die Coding-Schleife, so wie er die Fertigungsstraße verlassen hat. Das andere Lager hält dagegen: ohne erfahrene Senior-Entwickler, die anleiten, einordnen und die typischen Fehlerklassen der Maschinen erkennen, ist ein Team aufgeschmissen, egal wie gut die Agenten werden.
Ich code selbst und habe die Tage das neueste Modell von Anthropic ausprobiert: Ich lese mir den Code nur noch ab und an aus Neugier durch. Er mag noch nicht Production Grade sein, aber funktional tut er, was er soll. Ich bin mir sicher, dass wir einfach eine neue Abstraktionsstufe in der Softwareentwicklung erreicht haben. Die in Bits und Bytes kodierten Manifestationen unserer Ideen - Programmiersprachen wie JavaScript - werden für den Coder von morgen so unbedeutend sein, wie es für mich Assembler war.
Was heute allerdings schon gilt, unabhängig davon, welches Lager Recht behält: Die Teams, die jetzt lernen, Anforderungen als Tests zu automatisieren, sind für jede Zukunft vorbereitet. Die Teams, die ungeprüft Code generieren lassen, sind es nicht.
Dieser Beitrag vertieft These 1 des Thesenpapiers Der verschobene Engpass: Software zu schreiben ist nicht mehr der Engpass. Entscheiden schon.
Wo steht euer Team beim Prüfen?
Der kostenlose AI-Standort-Check zeigt es in 5 Minuten. Oder wir springen direkt rein: 30 Minuten, unverbindlich, mit mir.
Quellen
- SemiAnalysis-Report, besprochen bei OfficeChai, 7. Februar 2026 (ca. 4% aller öffentlichen GitHub-Commits von Claude Code, 135.000+ Commits täglich, Stand 2. Februar; Prognose 20% bis Jahresende).
- Stanford University HAI: The 2026 AI Index Report, April 2026.
- Andrej Karpathy: Sequoia AI Ascent 2026, Zusammenfassung des Autors, Juni 2026.
- Boston Consulting Group: AI at Work 2026: Why Strategy Matters More Than Tools, 3. Juni 2026.
- Anthropic: Claude Fable 5 and Claude Mythos 5, Launch-Ankündigung mit dem Stripe-Beispiel (Migration über 50 Mio. Zeilen Ruby an einem Tag), 9. Juni 2026.
- Gartner: Market for Enterprise AI Coding Agents, Pressemitteilung, 20. Mai 2026.
Bildnachweise: D. Amodei – TechCrunch (CC BY 2.0); A. Karpathy – karpathy.ai; J. Atwood – D. Begley (CC BY 2.0). Alle via Wikimedia Commons, zugeschnitten. B. Cherny – Standbild aus dem Sequoia-AI-Ascent-Vortrag (YouTube), zugeschnitten. Ponytail-Screenshot: skills.sh. Commit-Grafik: SemiAnalysis via OfficeChai.