Programmieren ist das Feld, in dem KI gerade am sichtbarsten umgepflügt wird. Aus dem Autocomplete im Editor sind Agenten geworden, die ganze Aufgaben übernehmen – planen, Code schreiben, testen, nachbessern. Dieser Artikel trennt das Belegte vom Hype: was Zahlen und Primärquellen hergeben, was sich in der Praxis bewährt, und wo die Aufsicht des Menschen unersetzlich bleibt.
10 Min. Lesezeit
10 Abschnitte
12 Quellen
Stand: 21. Juni 2026
Vom Tippen zum Dirigieren
Der Anteil von Code, den KI schreibt, ist an der Spitze bereits hoch. Anthropic berichtet, dass im zweiten Quartal 2026 über 80 % des in die eigene Produktion eingespielten Codes von Claude stammten – vor dem Start von Claude Code Anfang 2025 lag dieser Wert noch im einstelligen Prozentbereich. Typische Entwickelnde spielen laut Anthropic rund achtmal so viel Code pro Tag ein wie 2024; das Unternehmen nennt diese Zahl selbst „mit ziemlicher Sicherheit eine Überzeichnung“ des echten Produktivitätsgewinns.
Warum kippt ausgerechnet Coding so schnell? Der quellenbewusste Analyse-Kanal AI Explained referiert eine Einordnung von OpenAIs Greg Brockman: Der Coding-Rückstand mancher Labore kam vom Fokus auf „exquisite generalization“ – das Brillieren in Programmierwettbewerben – statt auf die „last mile usability“ an echten, unordentlichen Codebases; Anthropic habe diese Verschiebung früher erkannt. Eine benannte Position eines Beteiligten, kein neutraler Befund – aber sie erklärt, warum sich das Feld so ungleichmäßig bewegt.
Damit verschiebt sich die Arbeit: weg vom Schreiben einzelner Zeilen, hin zum Steuern von Agenten. Ein Agent ist – in Abgrenzung zum festen Programmablauf (Workflow) – ein System, in dem das Modell seinen eigenen Ablauf und Werkzeugeinsatz dynamisch selbst bestimmt: Es plant mehrschrittig, ruft Werkzeuge auf und arbeitet an Rückmeldungen aus der Umgebung weiter.
Code bei Anthropic von Claude
> 80 % (Q2 2026)
Vorher (Anfang 2025)
einstelliger Prozentbereich
MerksatzDie Frage ist immer seltener „Wie tippe ich das?“ und immer öfter „Wie führe ich den Agenten?“.
Der Aufgaben-Horizont wächst
Wie lang darf eine Aufgabe sein, die ein Modell eigenständig schafft? Die Forschungsorganisation METR misst genau das – die Länge der Aufgaben, die ein Modell mit 50 % Erfolg autonom erledigt – und stellt fest: Dieser Horizont verdoppelt sich langfristig etwa alle sieben Monate, der jüngere Trend seit 2023 ist mit gut vier Monaten noch schneller.
Konkret als Größenordnung: GPT-4 (2023) schaffte Aufgaben von wenigen Minuten, ein Modell von Mitte 2025 schon rund anderthalb Stunden, Anfang 2026 lag die Spitze bei mehreren Stunden. Wichtig ist das Kleingedruckte: Es ist eine 50-%-Erfolgsmarke, kein „gelöst“. Agenten greifen nach immer längeren Aufgabenketten – verlässlich erledigt sind sie damit noch nicht.
„Welches Modell soll ich zum Programmieren nehmen?“ – die ehrliche Antwort beginnt mit einer Warnung. Anbieter werben gern mit SWE-bench-Verified-Werten nahe 90 %, doch dieser Benchmark gilt als gesättigt und kontaminationsanfällig: Lösungen können bereits im Trainingsmaterial stecken. Aussagekräftiger sind unabhängige, fortlaufend gemessene Indizes wie der Artificial-Analysis-Coding-Index oder kontaminationsfreie Langhorizont-Tests (DeepSWE). Und selbst die ersetzen nicht den eigenen Versuch: Kein Benchmark kennt deine Codebasis.
Stand Mitte 2026 zeichnet der unabhängige Coding-Index dieses Bild der praktisch verfügbaren Modelle: An der Spitze der reinen Code-Qualität liegt GPT-5.5 (59) – knapp vor Claude Opus 4.8 (57) und Gemini 3.1 Pro (55) – und führt zusätzlich den kontaminationsfreien DeepSWE-Test klar an (70 %); der Haken ist der höchste Output-Preis. Opus 4.8 ist der stärkste Allrounder, wenn Tiefe und lange autonome Läufe zählen. Wer auf Preis und Tempo achtet, fährt mit Claude Sonnet 4.6 (51) deutlich günstiger ($3/$15 statt $5/$25) bei nur mäßig geringerem Coding-Wert; für latenz- und kostensensitive Hochvolumen-Aufgaben genügt oft Haiku 4.5 (33). Ein Sonderfall mahnt zur Vorsicht: Anthropics Fable 5 führt den Index nominal (62), ist aber seit dem 12.06.2026 ausgesetzt – die nominal beste Zahl gehört also zu einem Modell, das gerade nicht nutzbar ist.
Code-Qualität (AA Coding Index)
GPT-5.5 59 · Opus 4.8 57 · Gemini 3.1 Pro 55
Preis/Tempo-Wahl
Sonnet 4.6 (51, $3/$15) · Haiku 4.5 (33)
Vorsicht
SWE-bench gesättigt; Fable 5 (62) ausgesetzt
MerksatzFürs reine Coding führt aktuell GPT-5.5, der beste verfügbare Allrounder ist Opus 4.8, das Preis-Tempo-Pferd Sonnet 4.6 – aber kein Benchmark kennt deine Codebasis.
Ein gut dokumentiertes Praxisbeispiel ist Cloudflares automatisierte Code-Review: rund 131.000 KI-Reviews pro Monat über etwa 5.000 Code-Repositories, zum Median von ungefähr einem Dollar je Review und in gut drei Minuten. Der Clou ist die Aufteilung: Statt eines Alleskönners prüfen bis zu sieben spezialisierte Agenten (für Sicherheit, Performance, Code-Qualität, Dokumentation, Release-Management, Compliance), und ein Koordinator-Agent fasst zusammen, entdoppelt und filtert.
Drei Techniken daraus lassen sich übertragen: Erstens skaliert man den Aufwand nach Risiko – eine triviale Änderung bekommt zwei Agenten, eine große die volle Suite; „kein Dream-Team für einen Tippfehler“. Zweitens bekommt jeder Agent nur seinen Ausschnitt (Context-Engineering – die für ihn relevanten Dateien plus geteilter Kontext), sonst vervielfachen sich die Kosten. Drittens streamt das System seine Zwischenschritte zeilenweise (als JSON-Lines), was Beobachtbarkeit und gezielte Wiederholungen erlaubt.
MerksatzNicht ein Universal-Agent, sondern viele fokussierte plus ein Koordinator – und Aufwand nach Risiko dosiert.
KI-Code absichern: warum ein Modell sich nicht selbst benoten sollte
Ein Agent, der seinen eigenen frischen Code prüft, neigt dazu, ihn durchzuwinken. Das ist kein bloßer Verdacht aus der Praxis, sondern messbar: Forschung zum Self-Preference-BiasMessbarer Effekt, dass ein Sprachmodell als Bewerter (LLM-as-judge) eigene und modell-familieneigene Ausgaben systematisch höher einstuft. Mechanismus: geringere Perplexität bzw. höhere Vertrautheit der Selbst-Outputs, nicht objektiv bessere Qualität. Belegt u. a. für GPT-4 (arXiv:2410.21819).Mehr im Wissen → zeigt, dass Sprachmodelle als Bewerter ihre eigenen – und modell-familieneigenen – Ausgaben systematisch höher einstufen; GPT-4 etwa zeigt einen signifikanten Eigen-Vorzug. Der Mechanismus ist Vertrautheit, nicht Qualität: Das Modell „erkennt“ seinen eigenen Stil als wahrscheinlicher wieder und verwechselt diese geringere Überraschung mit Güte. Für Prosa-Bewertung ist das sauber belegt; die Übertragung auf Code-Review ist plausibel, aber noch nicht durch eine code-spezifische kontrollierte Studie hart gemessen – nimm es als Mechanismus-Analogie, nicht als gemessenen Code-Befund.
Anthropic zieht in seinen Claude-Code-Best-Practices genau die operative Konsequenz: Lass das Modell, das die Arbeit gemacht hat, nicht dieselbe Arbeit benoten. Ein frischer SubagentSpezialisierter Hilfs-Agent mit eigenem, sauberem Kontextfenster: Ein Leit-Agent koordiniert den Plan, Subagenten erledigen Teilaufgaben und liefern nur eine verdichtete Zusammenfassung (oft 1.000–2.000 Tokens) zurück – Kontext-Isolation als Arbeitsteilung.Mehr im Wissen → oder ein zweites Modell soll das Ergebnis aktiv zu widerlegen versuchen, weil ein frischer Kontext die Voreingenommenheit gegenüber dem eben selbst geschriebenen Code gar nicht erst aufbaut. Dahinter steht ein dokumentiertes Fehlermuster, der „trust-then-verify gap“ – „sieht fertig aus“ als Abnahme-Signal zu nehmen, statt es zu prüfen. Eine Einzelarbeit zur Kontext-Trennung stützt dieselbe Stoßrichtung: Self-Review scheitert, weil derselbe Kontext, der den Code erzeugte, ihn auch beurteilt; trennt man Produktions- von Review-Sitzung, steigt die Output-Qualität.
Praktiker bringen denselben Satz auf eine kürzere Formel – „ein Modell darf nicht seine eigene Arbeit benoten“, „lieber ein zweites Paar Augen als dieselbe KI, die plant und prüft“ (so etwa der Coding-Kanal Chase AI). Diese Stoßrichtung ist nun belegt; die konkreten Zahlen, die solche Kanäle aus eigenen Versuchen nennen, bleiben Einzelmessungen und taugen nicht als Beleg für die Überlegenheit eines bestimmten Modells.
Self-Preference-Bias
LLM-Judges bevorzugen eigene Ausgaben (belegt, GPT-4 signifikant)
MerksatzWer den eigenen Code schrieb, ist der schlechteste Gutachter dafür – nicht aus Faulheit, sondern aus Vertrautheits-Bias.
Zwei Hebel: deterministischer Check und ein fremdes Augenpaar
Aus dem Befund folgen zwei Hebel, die sich ergänzen. Der erste ist der Verifikations-LoopSchleife, in der ein Agent seine Arbeit gegen einen ausführbaren Prüfstein laufen lässt – Tests, Build, Lint, Screenshot-Abgleich – und an den Rückmeldungen so lange iteriert, bis der Check grün ist. Ersetzt „sieht fertig aus“ durch einen deterministischen Beweis und schließt den „trust-then-verify gap“.Mehr im Wissen →: Gib dem Modell einen ausführbaren Prüfstein – Tests, Build, Lint, einen Screenshot-Abgleich – gegen den es selbst iteriert, statt „sieht fertig aus“ als Signal zu nehmen. Das untermauert die ältere Praktiker-Regel „lass den Agenten gegen die Realität prüfen“ jetzt mit einer belastbaren Quelle. Der zweite Hebel ist das fremde Augenpaar: ein Cross-Modell-ReviewCode-Review, bei dem ein anderes Modell (oder zumindest ein frischer Kontext) das Ergebnis prüft, statt das produzierende Modell sich selbst – um den Self-Review-/Self-Preference-Bias zu umgehen. Ein zweites, unabhängiges Augenpaar findet nachweislich mehr Fehler; ersetzt aber nicht die menschliche Aufsicht.Mehr im Wissen →, bei dem ein anderes Modell – oder zumindest ein frischer Kontext – das Ergebnis zerlegt. Deterministischer Check und zweiter, unabhängiger Gutachter sind die zwei tragenden Säulen: Der eine fängt, was sich ausführen lässt, der andere, was nur ein Mensch oder ein nicht-voreingenommenes Modell bemerkt.
Dass ein zweites Paar Augen tatsächlich mehr findet, ist über Praxis-Anekdoten hinaus belegt: OpenAIs CriticGPT-Arbeit (Jan Leike u. a.) zeigt, dass ein darauf trainierter LLM-Kritiker mehr eingeschleuste Bugs fängt als bezahlte menschliche Reviewer – seine Kritiken wurden in 63 % der Fälle bevorzugt – und sogar als „fehlerfrei“ markierte Trainingsbeispiele als fehlerhaft entlarvt. Das ist die belastbare Variante dessen, was Praktiker wie der Coding-Kanal Chase AI beobachten, wenn sie Claude Code und Codex gegeneinander den jeweils anderen Code grillen lassen.
Konkretes Tooling gibt es bereits: OpenAIs offizielles Codex-Plugin enthält einen Adversarial ReviewCode-Review-Muster, bei dem das Modell den Code grundsätzlich als kaputt annimmt und ihn gezielt gegen typische Produktions-Fehlerklassen (Auth/Mandanten-Isolation, Datenverlust, Idempotenz, Race-Conditions u. a.) angreift – statt ihn wohlwollend zu lesen. Liefert meist einen strukturierten Befund mit Schweregrad, Konfidenz und Zeile.Mehr im Wissen →-Skill, der das Modell anweist, den Code grundsätzlich als kaputt anzunehmen und ihn gegen rund sieben Produktions-Fehlerklassen zu prüfen – Authentifizierung und Mandanten-Isolation, Datenverlust und -korruption, Rollback und Idempotenz, Race-Conditions, degradierte Abhängigkeiten, Version-Skew und Lücken in der Beobachtbarkeit – und valides JSON mit Schweregrad, Konfidenz und Zeilennummern zurückzugeben. Das ist Anbieter-Tooling: Es belegt das Muster und seine Struktur, nicht eine Überlegenheit über andere Verfahren. Den Maßstab dazu liefert der weiter oben beschriebene Cloudflare-Fall – dessen übertragbarer Baustein ist das Risk-Tiering: Aufwand nach Risiko und Diff-Größe dosieren, kein Dream-Team für einen Tippfehler.
Adversarialer Review als strukturierter Befund (schematisch)json
{"annahme":"Code ist kaputt, bis das Gegenteil bewiesen ist","befunde":[{"klasse":"auth/mandanten-isolation","schwere":"hoch","konfidenz":0.8,"datei":"src/api/orders.ts","zeile":88,"problem":"Tenant-ID aus Request-Body statt aus Session"},{"klasse":"datenverlust/idempotenz","schwere":"mittel","konfidenz":0.6,"datei":"src/jobs/cleanup.ts","zeile":23,"problem":"Retry ohne Idempotenz-Schlüssel kann doppelt löschen"}]}
Zwei Hebel
deterministischer Check + unabhängiges Augenpaar
CriticGPT (OpenAI)
Kritiken in 63 % der Fälle bevorzugt; fängt mehr Bugs
Codex adversarial-review
~7 Fehlerklassen, JSON mit Schwere/Konfidenz/Zeile
MerksatzEin ausführbarer Prüfstein plus ein fremdes Augenpaar – nicht entweder, sondern beides; den Aufwand nach Risiko dosieren.
Die Grenze: auch der Gutachter halluziniert
Cross-Modell-Review ist kein Freibrief. Ein Reviewer, den man auf Lücken ansetzt, meldet fast immer welche – auch bei solidem Code; Anthropic warnt ausdrücklich davor, jeden gemeldeten Befund blind zu verfolgen. Dieselbe ehrliche Kehrseite steht in der CriticGPT-Arbeit: LLM-Kritiker halluzinieren Bugs. Entscheidend ist dort der direkte Vergleich – ein Mensch-plus-Kritiker-Team fängt ähnlich viele echte Fehler wie der Kritiker allein, produziert aber deutlich weniger Fehlalarme. Der Mensch im Loop ist also nicht Zierde, sondern der Filter, der die Halluzinationen des Gutachters wegfängt.
Dass der Review-Aufwand sich überhaupt lohnt, legt ein Anbieter-Report nahe, der bei KI-koautoriertem Code rund 1,7-mal so viele zu prüfende Probleme pro Pull-Request meldet wie bei rein menschlichem. Solche Zahlen kommen von Tool-Anbietern mit Eigeninteresse und werden im Quellenkanon entsprechend abgewertet – sie motivieren den Aufwand, sind aber kein neutraler Beleg. Festhalten lässt sich das Belastbare: Mehr und schnellerer Code heißt mehr zu prüfen, ein zweites unabhängiges Modell fängt nachweislich mehr als die Selbstkontrolle – und beides zusammen ersetzt die menschliche Aufsicht nicht, sondern macht sie effizienter.
Jenseits der belegten Fälle hat sich unter Praktikern eine Handvoll Faustregeln herausgebildet (Erfahrungswissen, kein hartes Studienergebnis – entsprechend zu behandeln). Die wichtigste: Verankere den Agenten in der Realität. Lass ihn nicht blind Code erzeugen, sondern gegen einen echten Prüfstein laufen – den Compiler, die Tests, ein Schema oder die laufende Anwendung samt Screenshot-Abgleich. Was der Agent nicht überprüfen kann, rät er notfalls zusammen.
Zweitens: Ziehe eine deterministische Kern-Grenze. Datenbank, Authentifizierung und Bezahlung gehören in harten, vorhersagbaren Code; nur Verbindungslogik, Oberfläche und Hilfsskripte sind ein guter Platz für agentische Dynamik. Drittens gilt: „Ein fokussierter Agent ist ein leistungsfähiger Agent“ – ein kleiner, klar umrissener Kontext senkt die Fehlerrate stärker, als auf ein noch größeres KontextfensterDie maximale Textmenge (in Tokens), die ein Modell pro Anfrage gleichzeitig „im Blick“ hat – Eingabe plus bisheriger Verlauf. Ist es voll, fällt Älteres aus dem Kontext.Mehr im Wissen → zu warten.
MerksatzLass den Agenten gegen die Realität prüfen – Tests, Compiler, die laufende App. Verifizierte Arbeit schlägt geratene.
KI & Entwickler-Jobs
Verdrängt das alles die Entwickler? Die Schlagzeilen legen es nahe: Die Tech-Entlassungen erreichten Mitte 2026 den höchsten Monatswert seit zwei Jahren (knapp 40.000), und „KI“ war den dritten Monat in Folge der meistgenannte Grund (Challenger, Gray & Christmas). Doch die Kausalität ist umstritten. Vieles davon ist „AI washing“ – Kürzungen, die mit KI begründet, aber von Missmanagement oder Marktlage getrieben sind; selbst Investor Marc Andreessen nennt KI die „Silberkugel-Ausrede“ für Entlassungen. Wo Arbeitsmarktdaten (etwa US-WARN-Meldungen) geprüft wurden, ließ sich nur ein Bruchteil der Streichungen tatsächlich KI zuordnen.
Die nüchterne Einordnung: KI verschiebt die Tätigkeit, statt den Beruf zu streichen. Programmieren ist nicht der Engpass – Entwickelnde verbringen je nach Studie nur 9 bis 61 % ihrer Zeit mit dem Schreiben von Code; der Rest sind Abstimmung, Fehlersuche und Entscheidungen. KI komprimiert vor allem diese Ausführung; das Entscheiden, was gebaut wird, und das Verantworten, Verifizieren und Ausliefern bleiben menschlich. Narayanan und Kapoor zeichnen das Bild des Kranführers: Die Agenten übernehmen den kognitiven Großteil, ihn zu beaufsichtigen und unter Kontrolle zu halten wird zur eigentlichen Aufgabe des Menschen. Hinzu kommt die induzierte Nachfrage (Jevons-Paradox): Wird Software billiger, entsteht mehr davon – und damit eher mehr als weniger Bedarf an Entwicklern. Der reale wunde Punkt liegt woanders, bei den Junioren: Wenn Agenten die Einstiegsaufgaben übernehmen, fehlen die Lerngelegenheiten, aus denen Senior-Entwickler erst entstehen.
Belege auf beiden Seiten sind Tier B – kein hartes Urteil, sondern ein datierter Snapshot, der beweglich bleibt. Festhalten lässt sich Mitte 2026: wenig belegte Netto-Verdrängung durch KI selbst, aber eine spürbar verschobene Rolle – mehr Spezifizieren und Reviewen, weniger Tippen.
Tech-Layoffs (Mitte 2026)
Höchstwert seit 2 J.; „KI“ 3 Monate in Folge meistgenannt
Coding-Anteil am Entwickler-Tag
je nach Studie 9–61 %
Netto-Verdrängung durch KI selbst
bislang wenig belegt (Snapshot)
MerksatzKein „KI ersetzt Entwickler“ als Tatsache: Die Rolle verschiebt sich – mehr Spezifizieren und Reviewen, weniger Tippen. Der wunde Punkt ist der Junior-Einstieg.
So beeindruckend die Werkzeuge sind – sie beschleunigen, sie ersetzen die Aufsicht nicht. KI-Modelle helfen, prüfen und beschleunigen, arbeiten aber nicht zuverlässig vollständig autonom; ein Fehler ohne Kontrolle kann teuer werden. Typisch ist die Code-Halluzination: Liest ein Agent eine leere oder falsche Datei, beschreibt er die vermeintliche Funktion mitunter als real, statt nachzuforschen. Ein leerer Treffer muss eine Untersuchung auslösen, keine Annahme.
Sicherheitskritisch ist vor allem der interne Agent mit Zugriff auf Produktivsysteme – weniger der Angreifer von außen. Hier gilt: Eine Positivliste erlaubter Befehle schlägt eine Sperrliste verbotener; am sichersten ist gar kein allgemeines Shell-Werkzeug, sondern nur explizit definierte Werkzeuge. „Das Risiko wächst mit der Laufzeit“: Je länger ein Agent läuft, desto eher verliert er die ursprüngliche Anweisung aus dem Blick. Setze deshalb unumkehrbare Aktionen (Daten löschen, Volumes leeren) auf null und mache Dateiänderungen über Versionskontrolle rückgängig-fähig.
Den Agenten eng einhegen (schematisch)bash
# Positivliste statt allgemeiner Shell — nur explizit erlaubte Befehle
agent run --aufgabe "Flaky-Test stabilisieren" \
--erlaube "pnpm test, git add, git commit" \
--verbiete "rm -rf, docker volume rm, DROP TABLE" \
--auto-commit # jede Dateiänderung über Git rückgängig-fähig
MerksatzKI-Agenten beschleunigen – die Aufsicht ersetzen sie nicht. Sichere die unumkehrbaren Aktionen, nicht nur den Agenten.