Ein Entwickler beschreibt seinem KI-Assistenten in drei Sätzen eine neue Exportfunktion. Zehn Minuten später liegen Code, Tests und eine Beschreibung für den Pull Request vor. Früher hätte das einen halben Tag gekostet. Die naheliegende Frage lautet: Wofür braucht es den Entwickler dann noch?

Die Antwort ist unbequemer und zugleich beruhigender, als es die Schlagzeilen über „Programmierer bald überflüssig“ nahelegen. Code zu tippen wird billiger. Zu entscheiden, welcher Code entstehen soll, ob er stimmt und wie er in ein bestehendes System passt, wird dagegen wertvoller. Dieser Beitrag ordnet ein, welche Thesen hinter der Debatte stehen, was davon trägt und welche Fähigkeiten Entwickler:innen jetzt ausbauen sollten.

Woher die These vom „Super-Entwickler“ stammt

Die Erzählung, KI mache Entwickler nicht arbeitslos, sondern mächtiger, wird in den USA vor allem von Investoren und Gründern vertreten. Prominent ist der Risikokapitalgeber Marc Andreessen, Mitgründer der Firma Andreessen Horowitz. Er hat in Interviews und Podcasts mehrfach argumentiert, etwa im Januar 2026 in „Lenny's Podcast“, dass KI Fachleute nicht ersetze, sondern mit enormem Hebel ausstatte – und dass gerade Menschen, die mehrere Disziplinen verbinden, davon profitieren.

Diese Herkunft sollte man im Blick behalten. Ein Investor, der Geld in KI-Firmen steckt, hat ein Interesse an einer optimistischen Erzählung. Das macht die Thesen nicht falsch, aber es lohnt sich, sie einzeln zu prüfen, statt sie als Gewissheit zu übernehmen. Einige halten der Praxis gut stand, andere sind eher Motivationsrede.

Zum Hintergrund gehört ein volkswirtschaftliches Argument: In vielen Industrieländern altert die Bevölkerung, der Fachkräftemangel in der IT ist seit Jahren ein Thema. Wenn weniger Menschen mehr Software bauen und betreiben sollen, braucht es Werkzeuge, die die Produktivität des Einzelnen steigern. Aus dieser Sicht ist KI weniger Jobkiller als Antwort auf einen Engpass. Ob das für jede Branche und jede Rolle gilt, ist offen. Für die Softwareentwicklung ist es zumindest plausibel, denn die Nachfrage nach Software war bisher stets größer als die Kapazität, sie zu bauen.

Was KI-Assistenten heute tatsächlich übernehmen

Um die Rollenfrage zu beantworten, hilft ein nüchterner Blick auf den Stand der Werkzeuge. Assistenten wie GitHub Copilot, Cursor, Claude Code oder OpenAI Codex vervollständigen nicht mehr nur Zeilen. Als sogenannte Coding-Agenten – Programme, die selbstständig Dateien lesen, Code ändern, Tests ausführen und auf Fehler reagieren – erledigen sie zusammenhängende Aufgaben über mehrere Dateien hinweg.

Gut funktioniert das bei klar umrissenen Aufgaben: ein Formular ergänzen, eine Bibliothek aktualisieren, Tests für bestehenden Code schreiben, eine Fehlermeldung nachvollziehen. Schwieriger wird es, wenn Anforderungen unklar sind, wenn Wissen über das Unternehmen fehlt oder wenn eine Änderung Folgen für Sicherheit, Datenschutz und Architektur hat. Dann liefern die Werkzeuge oft Code, der auf den ersten Blick überzeugt und auf den zweiten an der falschen Stelle ansetzt.

Wie Teams solche Agenten gezielt steuern, beschreiben wir ausführlicher im Beitrag über Spezifikationen für KI-Agenten. Für die Rollenfrage reicht hier die Beobachtung: Die Arbeit verschiebt sich vom Schreiben zum Beschreiben, Prüfen und Entscheiden.

Vibe Coding und warum Erfahrung den Unterschied macht

Der Begriff „Vibe Coding“ geht auf den KI-Forscher Andrej Karpathy zurück, der ihn Anfang 2025 prägte. Gemeint ist ein Programmierstil, bei dem man der KI in Alltagssprache sagt, was man möchte, die Ergebnisse ausprobiert und nachsteuert, ohne den erzeugten Code im Detail zu lesen. Für Prototypen, Lernprojekte und kleine Werkzeuge ist das erstaunlich produktiv. Was dahintersteckt und wo die Grenzen liegen, erläutert unser Beitrag zu Vibe Coding als KI-gestützter Programmierung.

Angenommen, eine Mitarbeiterin aus dem Marketing baut mit einem KI-Werkzeug ein kleines Dashboard für Kampagnendaten. Es läuft, es sieht gut aus, und sie hat dafür keine Zeile selbst geschrieben. Ob die Datenbankabfrage bei zehnfacher Datenmenge noch schnell genug ist, ob ein Zugangsschlüssel im Quelltext steht oder ob das Werkzeug personenbezogene Daten an einen Dienst außerhalb der EU schickt, kann sie aber nicht beurteilen.

Genau hier liegt der Unterschied zur erfahrenen Entwicklerin. Ein Vergleich aus dem Straßenverkehr: Mit einer Navigations-App kommt fast jeder ans Ziel. Wenn eine Brücke gesperrt ist oder die App eine unsinnige Route vorschlägt, hilft Ortskenntnis. Vibe Coding senkt die Einstiegshürde. Es ersetzt nicht das Wissen, das nötig ist, um Software dauerhaft sicher, wartbar und wirtschaftlich zu betreiben.

Fachwissen wird wichtiger, nicht unwichtiger

Daraus folgt ein scheinbares Paradox: Gerade weil KI viel Code erzeugt, brauchen Entwickler:innen ein tieferes Verständnis ihres Handwerks. Andreessen rät in diesem Zusammenhang, beim Programmierenlernen bis hinunter zu Assembler und Maschinencode zu gehen. Nüchtern formuliert heißt das: Wer die Ausgaben einer KI bewerten will, muss verstehen, was darunter passiert.

Ein Beispiel: Ein Agent schlägt vor, ein Performance-Problem mit einem Cache zu lösen. Das klingt vernünftig. Wer aber weiß, dass die betroffenen Daten sich minütlich ändern und dass mehrere Server gleichzeitig darauf zugreifen, erkennt sofort, dass der Vorschlag neue Fehler erzeugt. Dieses Urteil entsteht nicht aus dem Prompt, sondern aus Erfahrung mit Datenbanken, Netzwerken und dem konkreten System.

Für die Praxis bedeutet das:

• Grundlagen pflegen: Datenstrukturen, Nebenläufigkeit, Speicher, Netzwerkprotokolle und Sicherheitsprinzipien sind die Prüfwerkzeuge für KI-Code.
• Code lesen lernen: Code-Review wird zur Kernkompetenz. Wer schnell erkennt, wo ein Vorschlag vom gewünschten Verhalten abweicht, arbeitet mit KI deutlich effizienter.
• Das eigene System kennen: Architektur, Geschäftsregeln und Altlasten eines Unternehmens stehen in keinem Trainingsdatensatz. Dieses Wissen bleibt beim Team.

Routinearbeit lässt sich zunehmend delegieren. Die Verantwortung für das Ergebnis lässt sich nicht delegieren.

Breite statt reiner Spezialisierung

Eine zweite These betrifft das Profil von Entwickler:innen. Andreessen beschreibt Produktteams, in denen Entwicklung, Design und Produktmanagement mit KI jeweils in die Nachbardisziplinen vordringen: Entwickler entwerfen Oberflächen, Designer bauen Prototypen, Produktmanager schreiben einfache Werkzeuge selbst. Er nennt das eine Pattsituation („Mexican Standoff“), in der jede Rolle glaubt, die anderen übernehmen zu können.

Hinter der zugespitzten Formulierung steckt eine brauchbare Beobachtung. Die Grenzen zwischen den Rollen werden durchlässiger, weil KI die Einstiegskosten in ein Nachbarfeld senkt. Wer als Entwickler Grundlagen von Gestaltung, Nutzerforschung oder Produktstrategie beherrscht, kann Anforderungen besser verstehen und schneller brauchbare Ergebnisse liefern.

In der Personalentwicklung wird dafür gern das Bild vom „T-förmigen“ Profil verwendet: breites Grundwissen und eine tiefe Spezialisierung. Manche erweitern es zur E-Form mit mehreren Vertiefungen. Das Bild ist eingängig, sollte aber nicht missverstanden werden. Niemand wird durch einen KI-Assistenten über Nacht zur Designerin oder zum Produktmanager. Realistisch ist, dass Entwickler:innen in Nachbarfeldern so weit kommen, dass sie gute Fragen stellen, Entwürfe einschätzen und einfache Aufgaben selbst erledigen können. Für anspruchsvolle Arbeit bleiben Spezialisten nötig.

Die Behauptung, mehrere Fähigkeiten würden den eigenen Wert nicht addieren, sondern multiplizieren, ist eher ein Bild als eine belastbare Rechnung. Plausibel ist sie trotzdem: Wer Technik und Fachlichkeit zusammenbringt, wird in Projekten häufig zur Schnittstelle, an der Entscheidungen fallen.

Orchestrieren: die neue Kernaufgabe

Mit Coding-Agenten verändert sich die tägliche Arbeit. Statt eine Aufgabe von Anfang bis Ende selbst zu programmieren, zerlegen Entwickler:innen sie in Teilaufgaben, beschreiben Ziele und Randbedingungen, lassen Agenten arbeiten und prüfen die Ergebnisse. Manche Teams lassen mehrere Agenten parallel an getrennten Aufgaben laufen.

Das hat Ähnlichkeit mit der Rolle eines technischen Leiters in einem kleinen Team. Gefragt sind:

• Klare Aufgabenbeschreibungen: Was soll entstehen, was darf sich nicht ändern, woran erkennt man Erfolg?
• Prüfbare Ergebnisse: Automatische Tests, statische Analyse und Code-Review sind die Leitplanken, an denen Agenten sich messen lassen.
• Kontext bereitstellen: Architekturentscheidungen, Konventionen und Fachbegriffe in Form von Dokumenten, die der Agent lesen kann.

Wie sich die Arbeit von Software-Teams insgesamt in Richtung Architektur und Systemdenken verschiebt, beschreibt der Beitrag Software Engineering in der KI-Ära. Der Wandel der Arbeitsumgebung jenseits der Softwareentwicklung, also weg von Menüs und Fenstern hin zu Assistenten, die Aufgaben selbst erledigen, ist Thema des Beitrags Das Ende der Menüs.

Lernen mit KI als Tutor

Eine der überzeugendsten Thesen betrifft das Lernen. Der Erziehungswissenschaftler Benjamin Bloom beschrieb 1984 das sogenannte 2-Sigma-Problem: In den Studien zweier seiner Doktoranden schnitten Lernende mit persönlicher Eins-zu-eins-Betreuung deutlich besser ab als Lernende im klassischen Unterricht – im Mittel um rund zwei Standardabweichungen. Persönliche Betreuung war aber immer teuer und knapp.

Sprachmodelle sind keine perfekten Lehrer. Sie irren sich, erfinden gelegentlich Fakten und neigen dazu, falsche Annahmen zu bestätigen. Als geduldiger Gesprächspartner, der Konzepte erklärt, Beispiele liefert und Rückfragen beantwortet, sind sie trotzdem ein starkes Lernwerkzeug.

Angenommen, ein Backend-Entwickler soll sich in Barrierefreiheit von Weboberflächen einarbeiten. Er kann sich von einem Assistenten die Grundprinzipien erklären lassen, eigenen Code auf typische Fehler prüfen lassen und gezielt nachfragen, warum eine bestimmte Lösung besser ist. Wichtig ist, die Antworten an Primärquellen wie Normen oder Herstellerdokumentation zu überprüfen. So genutzt, beschleunigt KI den Weg in neue Felder erheblich.

Für Berufseinsteiger hat das zwei Seiten. Einerseits lernen sie schneller. Andererseits fallen viele einfache Aufgaben weg, an denen Juniors bisher ihr Handwerk geübt haben. Teams sollten deshalb bewusst Lerngelegenheiten schaffen, etwa indem Einsteiger KI-Vorschläge erklären müssen, bevor sie übernommen werden.

Eigeninitiative als knappe Ressource

In der US-Debatte fällt oft der Begriff „Agency“. Gemeint ist die Fähigkeit, selbst zu erkennen, was getan werden muss, und es anzupacken, statt auf Anweisungen zu warten. Wenn KI viele Ausführungsschritte übernimmt, verschiebt sich der menschliche Beitrag zu den Fragen davor: Welches Problem lohnt sich zu lösen? Für wen? Mit welchem Aufwand?

Im Alltag eines Entwicklungsteams heißt das zum Beispiel: nicht nur das Ticket umsetzen, sondern nachfragen, ob die beschriebene Lösung das eigentliche Problem trifft. Oder ein wiederkehrendes manuelles Ärgernis bemerken und mit einem kleinen, KI-gestützten Werkzeug beheben. Wer so arbeitet, nutzt die gewonnene Zeit für Wirkung statt für mehr Tickets.

Was das für Entwickler:innen und Teams bedeutet

Unsere Einschätzung: Die Sorge, KI mache Entwickler:innen grundsätzlich überflüssig, ist überzogen. Die Erwartung, KI mache jeden automatisch zum „Super-Entwickler“, ist es ebenfalls. Wahrscheinlicher ist eine Verschiebung: weniger Zeit für das Schreiben von Routinecode, mehr Zeit für Anforderungen, Architektur, Prüfung und Abstimmung. Wer diese Fähigkeiten beherrscht, gewinnt. Wer nur Tickets in Code übersetzt, gerät stärker unter Druck.

Für einzelne Entwickler:innen lassen sich daraus vier Schritte ableiten:

1. Grundlagen vertiefen, um KI-Ausgaben sicher beurteilen zu können.
2. In Nachbarfelder vordringen und KI dabei als Tutor nutzen, ohne die eigenen Grenzen zu überschätzen.
3. Orchestrieren üben: Aufgaben zerlegen, Agenten anleiten, Ergebnisse mit Tests absichern.
4. Eigeninitiative zeigen, also Probleme erkennen und lösen, bevor jemand ein Ticket schreibt.

Für Unternehmen heißt das: Der Einsatz von KI-Assistenten braucht Regeln für Codequalität, Sicherheit und Datenschutz sowie Zeit für Weiterbildung. Wer nur ein Werkzeug einführt, ohne die Arbeitsweise anzupassen, verschenkt einen großen Teil des Nutzens. Wer GitHub Copilot im Team strukturiert einführen und die Arbeitsweise darauf abstimmen möchte, findet auf unserer Seite zu Beratung und Seminaren rund um GitHub Copilot passende Angebote.

Häufige Fragen zur Rolle von Entwicklern im KI-Zeitalter

Müssen Entwickler:innen jetzt komplett umlernen?

Nein. Bestehendes Wissen über Programmierung, Architektur und das eigene System wird wichtiger, weil es die Grundlage für die Bewertung von KI-Ergebnissen ist. Neu hinzu kommen Fähigkeiten wie präzises Beschreiben von Aufgaben, systematisches Prüfen und das Steuern von Agenten.

Werden Junior-Entwickler noch gebraucht?

Ja, aber ihr Einstieg verändert sich. Einfache Aufgaben übernimmt zunehmend die KI. Gleichzeitig können Einsteiger mit KI als Tutor schneller lernen. Teams sollten bewusst dafür sorgen, dass Juniors Verständnis aufbauen und nicht nur Vorschläge übernehmen. Ohne Nachwuchs fehlen in einigen Jahren die erfahrenen Leute, die KI-Ergebnisse beurteilen können.

Worin unterscheidet sich professionelle Entwicklung von reinem Vibe Coding?

Vor allem in der Verantwortung für den Betrieb. Mit Vibe Coding lassen sich schnell funktionierende Prototypen bauen. Professionelle Entwicklung muss zusätzlich Sicherheit, Datenschutz, Skalierung, Wartbarkeit und die Einbindung in bestehende Systeme gewährleisten. Dafür braucht es Fachwissen, das kein Prompt ersetzt.