AI in der Programmierung: Wie sich die Arbeit von Entwicklern verändert

Noch vor Kurzem wurde AI in der Softwareentwicklung vor allem als intelligenteres Autocomplete wahrgenommen. Copilot schlug die nächste Zeile vor, ChatGPT half beim Erklären einer Fehlermeldung, und der Entwickler blieb die einzige Person im Prozess, die die Aufgabe wirklich als Ganzes sehen konnte.

In den Jahren 2025-2026 sieht die Lage anders aus. Code LLMs leben nicht mehr nur im Chatfenster, sondern in IDEs, Terminals, Pull Requests, CI und Cloud-Umgebungen. GitHub beschreibt den Copilot coding agent als Werkzeug, das Aufgaben in einem Repository bearbeiten, in GitHub Actions laufen und Änderungen in Branches vorbereiten kann. OpenAI entwickelt Codex als Coding Agent zum Lesen von Codebasen, Schreiben von Code, Debuggen, Testen und Refactoring. Anthropic positioniert Claude Code als agentisches Werkzeug, das ein Projekt liest, Dateien bearbeitet und über CLI oder IDE arbeitet. (1 3)

Der wichtigste Wandel besteht nicht darin, dass AI "schneller schreiben hilft". Das ist zu weich formuliert. Der Engpass der Entwicklung verschiebt sich allmählich vom Tippen des Codes hin zur Aufgabenstellung, zum Kontextmanagement und zur Prüfung des Ergebnisses. Die Ära des Entwicklers, dessen Hauptwert darin bestand, Anforderungen manuell in Codezeilen zu übersetzen, geht tatsächlich zu Ende.

Was an ihre Stelle tritt, lässt sich noch nicht endgültig beschreiben. Die Branche hatte noch nie ein Werkzeug, das in wenigen Minuten einen funktionierenden Diff zusammenstellt, eine fremde Codebasis erklärt, Tests schreibt, Architekturänderungen vorschlägt und zugleich ein statistisches System ohne eigenes Produktverständnis bleibt. Deshalb ist es ehrlicher, nicht von einer einfachen Ersetzung von Programmierern zu sprechen, sondern vom Umbau der Arbeit selbst: Code wird billiger, Verantwortung für Sinn, Grenzen und Qualität wird teurer.

Von Copilot zu Code LLMs

Die erste massentaugliche AI-Schicht in der Programmierung war einfach: Das Modell blickte auf die aktuelle Datei und schlug eine Fortsetzung vor. Das beschleunigte bereits Routinearbeit, blieb aber eine lokale Hilfe. Der Entwickler schrieb die Funktion, und AI half, schneller zu einer syntaktisch plausiblen Lösung zu kommen.

Die neue Schicht ist breiter. Copilot, ChatGPT, Codex, Claude Code und ähnliche Code LLMs können nicht nur mit einem Fragment arbeiten, sondern mit einer Aufgabe: ein fremdes Modul erklären, die richtige Stelle für eine Änderung finden, eine Migration vorschlagen, einen Test erzeugen, einen Pull Request vorbereiten, einen Diff durchgehen und Risiken markieren. GitHub entwickelt Copilot code review separat weiter: Das ist kein Autocomplete mehr, sondern ein weiterer Teilnehmer im Review-Prozess, der Kommentare hinterlässt und Korrekturen vorschlägt. (4)

Man sollte die Autonomie dieser Schicht nicht überschätzen. Ein Modell "versteht das Projekt" nicht so, wie es ein Team versteht, das seit Jahren mit Produkt, Kunden und Incidents lebt. Aber es kann aus Code und Textkontext schnell eine brauchbare Hypothese bilden. Das reicht bereits aus, um die Ökonomie der Entwicklung zu verändern: Entwurfsimplementierung, Suche im Projekt und der erste Zusammenbau einer Lösung werden deutlich billiger als früher.

AI als Assistent des Entwicklers

Der praktische Nutzen von AI zeigt sich am deutlichsten dort, wo früher viel Zeit in mechanische Arbeit floss.

Sie hilft gut bei Boilerplate: einen typischen Endpoint, ein DTO, ein Testgerüst, eine SQL-Migration, eine SDK-Konfiguration, einen Formular-Handler oder einen Adapter für eine externe API erstellen. Sie ist nützlich beim Lesen eines unbekannten Projekts: Man kann sich den Datenfluss erklären lassen, eine ähnliche Implementierung finden, die wichtigsten Abstraktionen herausarbeiten und zeigen lassen, wo sich Zustand tatsächlich ändert.

Ein weiteres starkes Szenario sind Testentwürfe. Das Modell kann schnell Edge Cases vorschlagen, Fixtures vorbereiten, einen einfachen Unit Test schreiben oder darauf hinweisen, wo eine Fehlerprüfung fehlt. Das ersetzt kein Testdesign, senkt aber die Reibung in dem Moment, in dem der Entwickler bereits weiß, was geprüft werden muss.

AI beschleunigt auch Dokumentationsarbeit. Sie kann einen Diff in eine verständliche Beschreibung verwandeln, ein README für ein internes Werkzeug zusammenstellen, einen Breaking Change erklären oder PR-Kommentare vorbereiten. In einem guten Team hebt das Sorgfalt nicht auf, macht sie aber günstiger.

Genau hier entsteht der wichtige Unterschied. AI ist nicht dann nützlich, wenn sie einfach "statt des Entwicklers schreibt", sondern wenn sie in einen funktionierenden Engineering-Prozess eingebunden ist: Die Aufgabe ist beschrieben, der Kontext gesammelt, die Grenzen benannt, die Fertigkriterien sind klar, und Prüfungen laufen automatisch. Ohne das produziert das Modell mehr Text und mehr Code. Mit diesem Rahmen wird es zum Beschleuniger einer bereits vorhandenen Disziplin.

DORA formuliert das im Bericht von 2025 sehr treffend: AI wirkt in der Entwicklung als Verstärker. Sie hilft starken Organisationen mit Tests, Reviews, Plattformpraktiken und schnellen Feedback-Loops. Und sie verstärkt genauso das Chaos dort, wo Code ohnehin ohne klare Qualitätskriterien in production gelangte. (7)

Der Entwickler wird Architekt und Redakteur

Die wichtigste Veränderung besteht nicht darin, dass AI einen Teil des Codes schreibt. Entscheidend ist, dass der Entwickler immer häufiger nicht als Tastaturbediener arbeitet, sondern als derjenige, der die Aufgabe rahmt, das Ergebnis redigiert und den Kontext besitzt.

Um guten Code vom Modell zu bekommen, muss man nicht nur beschreiben, "was zu tun ist", sondern auch "innerhalb welcher Grenzen": welche Dateien berührt werden dürfen, welche APIs bereits existieren, welche Invarianten nicht verletzt werden dürfen, welche Tests bestehen müssen, wo Rückwärtskompatibilität wichtig ist, welcher Stil im Projekt gilt, was als Fehler zählt und was erwartetes Verhalten ist. OpenAI verdichtet seine Empfehlungen für Codex auf einen einfachen Rahmen: Ziel, Kontext, Einschränkungen und Definition of Done. (8)

Das ähnelt der Arbeit eines Architekten oder Tech Leads, nur im kleineren Maßstab. Der Entwickler gibt der Lösung Form, zerlegt die Aufgabe in prüfbare Schritte, begrenzt den Änderungsumfang, schaut den Diff durch, entfernt Überflüssiges, lässt strittige Teile neu schreiben und trifft die endgültige Entscheidung.

In diesem Sinn verstärkt AI nicht jeden Entwickler gleich. Sie hilft stärker denen, die bereits Code lesen, Architekturgrenzen sehen, Änderungskosten verstehen und eine plausible Antwort schnell von einer richtigen unterscheiden können.

Deshalb ist der Satz "AI ersetzt Junior-Entwickler" zu grob, enthält aber einen unangenehmen Kern. Wenn Arbeit darin bestand, gut beschriebene Aufgaben nach vertrautem Muster abzuarbeiten, wird sie zuerst automatisiert. Wenn ein Mensch dagegen eine unklare Aufgabe in einen konkreten Plan verwandeln, fehlenden Kontext finden und das Ergebnis prüfen kann, bleibt er auch in AI-durchdrungener Entwicklung nötig - zumindest solange die Verantwortung für das Ergebnis nicht auf das Modell übertragen werden kann.

Schnelle MVP-Entwicklung

Für MVPs ist AI besonders nützlich. Wenn man an einem Tag einen Prototyp bauen muss - Authentifizierung anschließen, ein Formular erstellen, ein einfaches Backend hochziehen, eine API-Integration schreiben, eine Einstellungsseite hinzufügen und Tests skizzieren - verkürzen Code LLMs den Weg von der Idee zur ersten funktionierenden Version deutlich.

Früher verbrachten Entwickler oft Stunden mit Startverkabelung: ein Beispiel aus der Dokumentation auswählen, SDK-Parameter nachschlagen, repetitive Serialisierung schreiben, ein Screen-Template zusammensetzen, das Antwortformat prüfen. Heute verlagert sich ein großer Teil dieser Arbeit in den Dialog mit dem Modell und in das Review des Ergebnisses.

Aber es gibt eine harte Grenze. AI beschleunigt die "erste Version", entscheidet aber nicht für das Team, welches Produkt der Nutzer wirklich braucht. Sie weiß nicht, welche Metrik verbessert werden soll, welcher Kompromiss akzeptabel ist, wo ein Ablauf vereinfacht werden darf und wo Daten auf keinen Fall verloren gehen dürfen. Das MVP entsteht also schneller, wird dadurch aber nicht automatisch wertvoll.

Ein weiteres Risiko schneller MVPs ist unsichtbare Schuld. Das Modell erzeugt leicht Code, der "für die Demo funktioniert": ohne sauberes Fehlermodell, ohne Migrationsstrategie, ohne Observability, ohne Zugriffsrechte und ohne klares Datenmodell. Je schneller der Prototyp entsteht, desto wichtiger ist es, rechtzeitig zu entscheiden, was weiterentwickelt werden kann und was vor production neu geschrieben werden muss.

Der praktische Schluss für MVPs ist einfach: AI sollte genutzt werden, um eine Hypothese schnell zu prüfen, nicht als Entschuldigung für fehlende Engineering-Disziplin. Schon in der ersten Version ist es sinnvoll, einen Wegwerfprototyp von der Grundlage eines künftigen Produkts zu trennen: temporäre Entscheidungen markieren, unbekannte Risiken festhalten, zumindest minimale Tests um kritische Szenarien schreiben und "die Demo läuft" nicht mit "das System ist wartbar" verwechseln.

Wo AI-Code bricht

Die Probleme von AI-Code beginnen fast nie bei der Syntax. Moderne Modelle schreiben meist Code, der plausibel aussieht und oft eine Basisprüfung besteht. Schwieriger ist etwas anderes: Sie können selbstbewusst eine Lösung vorschlagen, die nicht zum realen Projekt passt.

Das erste Problem ist unvollständiger Kontext. Das Modell sieht nur das, was man ihm gegeben hat: einige Dateien, die Aufgabenbeschreibung, einen Fehlerausschnitt, manchmal die Chat-Historie. Es kennt vielleicht keine versteckte Business-Regel, keinen alten API-Client, keine Teamabsprache, kein ungewöhnliches Deployment und keinen Incident, wegen dem dieser seltsame Code überhaupt existiert.

Das zweite Problem sind erfundene oder veraltete APIs. Code LLMs verallgemeinern Muster gut, bauen aber manchmal syntaktisch überzeugenden Code aus inkompatiblen Bibliotheksversionen, nicht existierenden Methoden oder alter Dokumentation zusammen. Besonders sichtbar ist das bei SDKs und Frameworks, die sich schnell ändern.

Das dritte Problem ist Sicherheit. OWASP nennt in den Top 10 for LLM Applications ausdrücklich Prompt Injection und Insecure Output Handling: Wenn das Modell externe Anweisungen erhält oder seine Ausgabe ungeprüft an Shell, Browser, SQL, Workflow oder ein Werkzeug mit Rechten weitergegeben wird, wird die AI-Schicht Teil der Angriffsfläche. Für Coding Agents ist das besonders wichtig, weil sie nahe an Quellcode, Secrets, CI und Infrastrukturkommandos arbeiten. (5)

Das vierte Problem sind Tests, die besser aussehen, als sie sind. Das Modell kann Prüfungen für den Happy Path schreiben und die Struktur der Implementierung nachbilden, aber echte Edge Cases übersehen. Manchmal passt es sogar den Test an den aktuellen Code an, statt die Anforderung zu prüfen.

Das fünfte Problem ist Wartbarkeit. AI erzeugt sehr leicht viel Code. Aber viel Code ist nicht dasselbe wie gute Architektur. Im Projekt bleiben unnötige Abstraktionen, Duplikate, komplizierte Fallback-Zweige, unklare Abhängigkeiten und Funktionen zurück, die niemand im Team wirklich entworfen hat.

Warum AI Werkzeug bleibt und kein eigenständiger Akteur wird

Der wichtigste Grund ist einfach: AI trägt keine Verantwortung für das System. Sie haftet nicht gegenüber Nutzern für verlorene Daten, gegenüber dem Business für einen gescheiterten Release, gegenüber dem Security-Team für ein geleaktes Secret oder gegenüber zukünftigen Entwicklern für Architekturschulden.

Das ist keine philosophische Einschränkung, sondern eine praktische Grenze. Ein Modell kann eine Option vorschlagen, besitzt aber nicht das Produktziel. Es weiß nicht, warum ein Edge Case kritisch ist und ein anderer warten kann. Es versteht nicht den politischen Kontext im Unternehmen, die Fehlerkosten, rechtliche Einschränkungen, Kundenabsprachen oder die Kompromisse, die das Team bereits ausprobiert hat.

Auch der Agentenmodus hebt diese Grenze nicht auf. Ein Agent kann Dateien lesen, Tests ausführen, Commits in einen Branch schreiben und einen PR vorbereiten. Aber er arbeitet weiterhin innerhalb der Grenzen, die Menschen setzen: Zugriffe, Werkzeuge, Sandbox, Anweisungen, Akzeptanzkriterien, Review-Prozess und production gates.

NIST beschreibt dieses Thema im Profil zu generativer AI breiter: Der Wert eines AI-Systems hängt nicht nur vom Modell ab, sondern auch von Risikomanagement, Monitoring, Qualitätsbewertung, Nutzungskontrolle und menschlicher Aufsicht dort, wo die Fehlerkosten hoch sind. Für Softwareentwicklung bedeutet das schlicht: AI kann ein mächtiger Ausführer sein, aber die Engineering-Verantwortung bleibt beim Team. (6)

Die neue Fähigkeit: Context Engineering

Der Begriff prompt engineering wurde schnell zu eng. In der Programmierung löst selten ein schöner Satz im Chat das Problem. Viel wichtiger ist context engineering: die Fähigkeit, um eine Aufgabe herum den Kontext so zu sammeln, dass das Modell nicht blind arbeitet, sondern innerhalb eines klaren Systems von Einschränkungen.

Auf Ebene einer einzelnen Aufgabe bedeutet das, die Anfrage wie eine Mini-Spezifikation zu beschreiben. Nicht "baue Authentifizierung", sondern: welches Problem gelöst wird, welche Dateien und Beispiele wichtig sind, welche Frameworks bereits verwendet werden, welche Szenarien funktionieren müssen, welche nicht kaputtgehen dürfen, welche Prüfungen laufen sollen und was als abgeschlossen gilt.

Auf Repository-Ebene bedeutet es, das Projekt für Agenten vorzubereiten. GitHub empfiehlt custom instructions für Copilot: wo der Code liegt, wie der Build läuft, welche Tests verpflichtend sind, welche Standards das Team einhält. OpenAI schlägt AGENTS.md als dauerhafte Anleitung für Coding Agents vor: Repository-Struktur, Befehle, Konventionen, Einschränkungen und Definition of Done. Anthropic betont in Claude Code ähnlich stark Projektspeicher und Anweisungen. (8 10)

Das ist eine praktische Verschiebung. Gute Dokumentation half früher Menschen. Jetzt hilft sie auch Agenten. Aber es geht nicht darum, Texte um der AI willen zu schreiben. Es geht darum, Engineering-Regeln explizit zu machen. Wenn ein Team einem Agenten nicht erklären kann, wie das System korrekt geändert wird, erklärt es das Menschen oft mündlich, zufällig und mit Verlusten.

Welche Fähigkeiten wichtiger werden

Der naive Schluss lautet: Wenn AI Code schreibt, müssen Programmierer weniger über Sprachen und Frameworks wissen. In der Praxis gilt das Gegenteil: Je schneller Code erzeugt wird, desto wichtiger wird es, ihn bewerten zu können.

Architektonisches Denken wird wichtiger. Entwickler müssen Modulgrenzen, Datenlebenszyklen, Invarianten, Migrationskosten, Rückwärtskompatibilität und die Folgen einer kleinen Änderung in einem Monat verstehen. Ein Modell kann einen lokalen Diff vorschlagen, aber der Entwickler muss das System sehen.

Code Review wird wichtiger. Nicht als formales "ich habe es angeschaut", sondern als Fähigkeit, schnell eine falsche Annahme, einen übersehenen Fehler, eine unnötige Abstraktion, einen unsicheren Pfad oder einen Test zu finden, der nichts beweist. In der Welt von AI-Code wird Review von Stilkontrolle zu Sinnkontrolle.

Tests und Observability gewinnen an Wert. Wenn AI das Schreiben von Features beschleunigt, muss das Team auch die Prüfung beschleunigen: Unit Tests, Integration Tests, Contract Tests, Static Analysis, Linter, Security Scanning, Feature Flags, Logs und Metriken. Sonst liefert die Generierungsgeschwindigkeit Fehler nur schneller an Nutzer aus.

Eine eigene Fähigkeit wird das Stoppen der Generierung. Ein guter Entwickler muss den Moment erkennen, in dem das Modell selbstbewusst schreibt, aber in die falsche Richtung läuft: falsche Architekturschicht, falsches Datenmodell, falsche Abstraktionsebene, falsches Risikoprofil.

Schließlich wird Produktlogik wichtiger. AI kann einen Endpoint schreiben, entscheidet aber nicht, ob er gebraucht wird. Sie kann einen Screen erzeugen, versteht aber nicht, warum der Nutzer den Ablauf nicht abschließt. Sie kann die MVP-Entwicklung beschleunigen, ersetzt aber nicht Gespräche mit dem Markt, Datenanalyse und Priorisierung.

Was Entwickler jetzt tun sollten

Der erste Schritt besteht darin, AI nicht mehr als zufälligen Chat zur Beschleunigung kleiner Dinge zu behandeln. Nützlicher ist es, sie in den Arbeitsprozess einzubauen: Recherche, Plan, Implementierung, Prüfung, Review. Bei komplexen Aufgaben sollte man das Modell zuerst den Code untersuchen und einen Plan vorschlagen lassen, statt sofort Änderungen schreiben zu lassen. GitHub empfiehlt für Copilot cloud agent ausdrücklich, das Repository zu recherchieren, zu planen und zu iterieren, bevor ein PR geöffnet wird. (9)

Der zweite Schritt ist, Aufgaben so zu schreiben, dass ein Agent sie ausführen kann. Eine gute Aufgabe enthält Ziel, Kontext, Einschränkungen und Acceptance Criteria. Wenn der Entwickler kein Fertigkriterium formulieren kann, wird AI die Lücke fast sicher mit Vermutungen füllen.

Der dritte Schritt ist, Prüfungen zu stärken. Anthropic nennt in den Empfehlungen für Claude Code Verifikation den wichtigsten Hebel: Der Agent braucht die Möglichkeit, seine eigene Arbeit über Tests, Linter, Build, Screenshots oder reproduzierbare Befehle zu prüfen. Ohne das erhält der Entwickler einen plausiblen Diff. Mit diesen Checks ist der Diff zumindest mit der Realität kollidiert. (10)

Der vierte Schritt ist, wiederholbare Anweisungen zu schaffen. Wenn das Modell denselben Fehler zum zweiten Mal macht, ist das nicht nur ein Grund zur Verärgerung, sondern ein Signal, eine Regel in AGENTS.md, CLAUDE.md, .github/copilot-instructions.md oder eine interne Review-Checkliste aufzunehmen. Gute AI-Praxis verwandelt persönliche Korrekturen des Entwicklers schrittweise in gemeinsames Projektgedächtnis.

Der fünfte Schritt ist, dem Agenten nicht alles zu geben. Gute Kandidaten: Tests, Dokumentation, kleine Bugs, klare Refactorings, Migrationen nach Vorlage, Verbesserungen der Observability, Entwürfe. Schlechte Kandidaten: production incidents, security-sensitive Änderungen, Authentifizierung, Zahlungen, große fachliche Umschreibungen, Aufgaben ohne klare Anforderungen. Dort kann AI helfen, sollte die Arbeit aber nicht eigenständig führen.

Prognose: Das Ende des Berufs in seiner alten Form

Die ehrlichste Prognose klingt unangenehm: Die Ära der Entwickler, die vor allem Code von Hand schreiben, geht zu Ende. Nicht weil Code verschwindet. Im Gegenteil, es wird mehr Code geben. Aber das Schreiben typischen Codes hört auf, eine seltene und teure Fähigkeit zu sein. Es wird zu einer Operation, die immer häufiger an ein Modell delegiert werden kann.

Das bedeutet nicht, dass in wenigen Jahren nur noch Architekten übrig bleiben und AI selbst Produkte baut. Dafür ist es zu früh. Wir wissen nicht, wie Teamstrukturen aussehen werden, wie sich Ausbildung verändert, wie viele Aufgaben an Agenten gehen, welche Berufe rund um AI-native Entwicklung entstehen und wo der Markt an Grenzen bei Sicherheit, Fehlerkosten und rechtlicher Verantwortung stößt.

Aber die Richtung ist bereits sichtbar. Wenn der Entwickler früher vor allem der Mensch war, der Anforderungen in Code verwandelte, zerfällt diese Funktion jetzt. Ein Teil geht an das Modell. Ein Teil bleibt beim Menschen. Ein Teil wird zu neuen Praktiken: Aufgaben an Agenten stellen, Kontext verwalten, Qualität kontrollieren, Autonomiegrenzen entwerfen, AI-generated diffs prüfen, Checks konfigurieren und das Engineering-Gedächtnis des Projekts pflegen.

Die Frage ist daher nicht, ob AI Programmierer ersetzt. Das ist eine zu einfache Frage für einen zu komplexen Übergang. Präziser ist: Welcher Teil der heutigen Entwicklerarbeit war wirklich Denken, und welcher war manuelle Produktion von Code nach bereits verstandenem Muster. Der zweite Teil wird schnell billiger. Der erste wird wichtiger, muss sich aber durch Praxis beweisen, nicht durch Titel.

Fazit

AI verändert Programmierung tiefer, als nur "Entwickler schneller zu machen". Sie untergräbt die alte Ökonomie des Codings: typische Implementierung wird billiger, die Geschwindigkeit der Diff-Produktion steigt, und das Hauptrisiko verschiebt sich zur Qualität der Aufgabenstellung und Ergebnisprüfung.

Niemand weiß schon genau, was die vertraute Rolle des Programmierers ersetzen wird. Aber klar ist bereits: Gewinnen werden nicht diejenigen, die mit AI einfach mehr Code schreiben, sondern diejenigen, die AI in einen steuerbaren Engineering-Prozess verwandeln können - mit Kontext, Einschränkungen, Tests, Reviews und Verantwortung für das System.