Stand: Oktober 2026. Für alle, die Software entwickeln und sich fragen, was davon in fünf Jahren noch ihre Arbeit ist. Kein Abgesang, keine Beschwichtigung.
Für viele von uns war Programmieren nie nur ein Beruf. Es war das, worin wir richtig gut waren. Daran hingen Selbstwert, Anerkennung im Team und nicht zuletzt das Gehalt.
Genau dieses Handwerk erledigt jetzt eine Maschine in Sekunden, zumindest große Teile davon. Wer dabei kein mulmiges Gefühl hat, schaut nicht genau hin.
Die kurze Antwort vorweg: Softwareentwicklung verschwindet nicht, aber sie verschiebt sich. Weg vom Schreiben von Code, hin zum Beschreiben, Prüfen und Verantworten. Diese Verschiebung trifft nicht alle gleich, und sie verlangt mehr als neue Werkzeuge: ein anderes Selbstverständnis.
Ich schreibe das nicht von außen: Ich bin seit Jahrzehnten leidenschaftlicher Softwareentwickler und -architekt. Und ich programmiere seit mehreren Monaten nicht mehr – zumindest nicht im klassischen Sinne. Zum Glück habe ich dabei festgestellt, was ein geschätzter Kollege für sich so formuliert hat: Ich bin mehr Builder als Coder.
Was sich gerade wirklich verändert
Die Werkzeuge sind angekommen, die Gewinne sind real – aber ungleicher verteilt, als die Werbung verspricht. Und der Arbeitsmarkt trifft zuerst die Jüngsten.
Die Nutzung steigt, die Begeisterung nicht. In der Entwicklerumfrage von Stack Overflow stieg der Anteil der KI-Nutzer von 44 Prozent (2023) über 62 und 79 auf 83 Prozent (2026). Eine Zwischenumfrage im April 2026 zeigt fast doppelt so viel Agenten-Nutzung wie ein Jahr zuvor: 59 statt 31 Prozent. Die positive Grundstimmung fiel von 72 Prozent (2024) auf knapp 60 und liegt 2026 bei 62 Prozent; der Anteil, der KI als Bedrohung für den eigenen Job sieht, stieg 2025 von 12 auf 15 Prozent (Stack Overflow, Sept. 2026; Umfrage 2026).
Gefühlte Produktivität ist ein schlechter Messwert. Eine kontrollierte Studie stammt von METR: 16 erfahrene Open-Source-Entwickler, 246 echte Aufgaben in Projekten, die sie seit Jahren kannten. Mit KI brauchten sie 19 Prozent länger – und schätzten hinterher, sie seien 20 Prozent schneller gewesen (METR, Juli 2025).
Das Ergebnis ist inzwischen überholt, und zwar auf lehrreiche Weise. Die Folgestudie mit Werkzeugen von Ende 2025 zeigt Hinweise auf Beschleunigung, ist aber kaum auswertbar: Zu viele Entwickler wollten schlicht nicht mehr ohne KI arbeiten und mieden die Studie oder bestimmte Aufgaben (METR, Feb. 2026). Das sagt mehr über den Stand der Dinge als jede Prozentzahl.
KI verstärkt, was schon da ist. Der DORA-Report 2025 von Google beschreibt KI als Verstärker: Sie macht gute Teams besser und schwache Teams schneller schlechter. Ohne solides Fundament aus Tests, kleinen Änderungen und klaren Abläufen steigt der Durchsatz, aber die Stabilität leidet (DORA 2025).
Bei mir wirkt dieser Verstärker in die gute Richtung. Der METR-Studie widerspricht das nicht: Sie hat 2025 mit den Assistenten von damals gemessen, eine Aufgabe nach der anderen. Ich arbeite mit Agenten, oft mit mehreren parallel – und das kann eine Zeitmessung je Aufgabe nach METRs eigener Aussage nicht erfassen. In einem Produkt, an dem ich seit Jahren baue, hat eine KI neun dokumentierte Fehlerfälle, einen davon sechs Jahre unbemerkt, gelöst; meine Vorgaben passten in zehn Zeilen Chat. Eine technische Schuld, die sieben Jahre stand, war nach einer Nacht abgebaut. Und diese Seite ging einen Tag nach dem ersten Commit online. Das Fundament dafür ist das, wovon DORA spricht: Tests, kleine Schritte, klare Leitplanken.
Am Arbeitsmarkt trifft es zuerst die Einsteiger. In den USA lag die Beschäftigung von Softwareentwicklern zwischen 22 und 25 Jahren im September 2025 rund 20 Prozent unter ihrem Höchststand von Ende 2022; ältere Kollegen blieben stabil oder legten zu (Stanford Digital Economy Lab). Wie viel davon wirklich KI ist, bleibt umstritten: Zinswende, Post-Pandemie-Korrektur und Remote-Arbeit wirken mit, und der Gesamteffekt auf die Beschäftigung ist bislang klein (SIEPR, Juli 2026).
In Deutschland sieht es ähnlich aus, nur leiser. Der Bitkom zählt 79.000 offene IT-Stellen, nach 149.000 im Jahr 2023 – vor allem eine Folge der Konjunktur. Nur 10 Prozent der Unternehmen mit KI in der IT haben deshalb vereinzelt Stellen abgebaut. Aber 55 Prozent erwarten, dass klassische Einstiegsaufgaben wegfallen, und 74 Prozent, dass Steuerung und Kontrolle von KI wichtiger werden (Bitkom, Sept. 2026).
Das Bild in einem Satz: kein Massensterben von Entwicklerjobs, aber eine Verschiebung, die an der Einstiegstür beginnt und sich von dort nach oben arbeitet.
Die Ängste – und was an ihnen dran ist
Wer Angst hat, ist nicht rückständig. Die meisten Sorgen von Entwicklern sind eine nüchterne Lageeinschätzung, und einige davon sind schlicht berechtigt.
„Ich werde überflüssig.“ Ganz unbegründet ist das nicht. Wenn eine Person mit Agenten schafft, wofür früher drei nötig waren, werden Teams kleiner geplant und Stellen gar nicht erst ausgeschrieben. Laut Bitkom ersetzen 35 Prozent der Unternehmen, die Stellen abbauen oder damit rechnen, offene IT-Stellen durch KI – und in 47 Prozent dieser Fälle trifft der Abbau erfahrene Fachkräfte, nicht nur Einsteiger. Einen flächendeckenden Abbau zeigen die Daten nicht; dass Erfahrung allein kein Schutz mehr ist, zeigen sie sehr wohl.
„Für Einsteiger gibt es keine Leiter mehr.“ Diese Sorge ist gut begründet. Die Aufgaben, an denen Junioren früher gelernt haben – kleine Bugs, Formulare, Standard-Schnittstellen –, erledigt heute die Maschine. In einem Experiment von Anthropic (selbst ein KI-Anbieter) schnitten Entwickler, die eine neue Bibliothek mit KI-Hilfe lernten, im anschließenden Verständnistest 17 Prozent schlechter ab; die größte Lücke klaffte beim Debugging (Anthropic, Jan. 2026). Wer heute keine Junioren ausbildet, hat in zehn Jahren keine Senioren – das ist kein Problem der Einsteiger, sondern der ganzen Branche.
„Ich verlerne mein Handwerk.“ Auch Erfahrene merken es: Wer nur noch abnickt, verliert die Übung. Bei Stack Overflow gaben 2025 rund 20 Prozent an, durch KI weniger Vertrauen in die eigene Problemlösung zu haben; 16 Prozent fiel es schwer, zu verstehen, wie oder warum der erzeugte Code funktioniert. Den Mechanismus dahinter beschreibt Was KI mit uns macht ausführlich.
„Mir geht verloren, was mir Spaß gemacht hat.“ Diese Sorge wird oft belächelt, dabei ist sie einfach menschlich. Viele sind Entwickler geworden, weil sie das Schreiben von Code lieben: den Flow, das Tüfteln, die elegante Lösung. Wer stattdessen den ganzen Tag KI-generierten Code prüft, fühlt sich schnell zum Korrekturleser degradiert – und darf das betrauern.
„Ich hafte für Code, den ich nicht geschrieben habe.“ Richtig, und das bleibt so. KI-Ergebnisse sind oft fast richtig, und „fast richtig“ wird in der Software schnell teuer. Selbst in einer Zukunft, in der KI das meiste programmiert, würden drei Viertel der Befragten bei Stack Overflow (2025) einen Menschen fragen, wenn sie der Antwort der Maschine nicht trauen. Die Verantwortung wandert nicht zur KI; sie konzentriert sich bei dem, der auf „Merge“ drückt.
„Ich komme nicht mehr hinterher.“ Jeden Monat ein neues Modell, ein neues Werkzeug, ein neuer Workflow. 61 Prozent der Unternehmen erwarten laut Bitkom, dass IT-Fachkräfte stärker unter Druck geraten, sich laufend weiterzubilden. Das Gefühl, permanent hinterherzulaufen, ist also keine Einbildung.
Keine dieser Sorgen löst sich durch gutes Zureden. Aber zu jeder gibt es eine Antwort, die mehr ist als „Lern halt Prompting“.
Was nicht stimmt – auf beiden Seiten
Die Debatte leidet daran, dass beide Lager zu einfache Geschichten erzählen. Wer sich orientieren will, sollte beide kennen.
Was die Hype-Seite falsch erzählt:
- „Bald braucht niemand mehr Entwickler.“ Die Daten zeigen das nicht. In den USA wuchsen die Stellenausschreibungen für Softwareentwickler zuletzt sogar schneller als für andere Berufe, und Firmen, die KI breit einführten, stellten danach eher mehr Leute ein als weniger (SIEPR). Bei vielen Entlassungen, die mit KI begründet werden, ist selbst unter Ökonomen umstritten, ob KI der Grund ist oder nur eine bequeme Erklärung.
- „Mit KI ist jeder zehnmal produktiver.“ Schneller tippen heißt nicht schneller liefern. Der Engpass wandert vom Schreiben zum Prüfen, Testen und Abstimmen – und wer dort nicht nachzieht, produziert vor allem schneller Fehler.
- „Prompting ist die neue Kernkompetenz.“ Prompt-Tricks veralten mit jedem Modell. Was bleibt, ist die Fähigkeit, ein Problem so klar zu beschreiben und abzugrenzen, dass Mensch oder Maschine es lösen kann. Das hieß früher Anforderungsanalyse.
Was die Abwehr-Seite falsch erzählt:
- „Das ist ein Hype, der vorbeigeht.“ Wenn erfahrene Entwickler eine bezahlte Studie meiden, weil sie die Hälfte ihrer Aufgaben ohne KI erledigen müssten, ist das kein Strohfeuer mehr.
- „KI-Code ist grundsätzlich Schrott.“ KI-Code ist so gut wie der Kontext, die Vorgaben und die Prüfung drumherum. Schlechter Code entsteht meist dort, wo Menschen auch vorher schon ohne Tests und klare Architektur gearbeitet haben.
- „Ich bin zu erfahren, um mich noch umzustellen.“ Das Gegenteil ist richtig: Urteilsvermögen, Architekturgefühl und Fachwissen sind das, was man braucht, um KI zu steuern und ihre Ergebnisse zu bewerten. Erfahrung ist hier kein Ballast, sondern das Kapital – wenn man sie einsetzt, statt sie zu verteidigen.
- „Wenn ich es nicht nutze, betrifft es mich nicht.“ Der Markt bewegt sich unabhängig davon. 63 Prozent der Unternehmen erwarten laut Bitkom, dass KI-Kenntnisse künftig in allen IT-Berufen gebraucht werden.
Rollen im Wandel: vom Schreiben zum Verantworten
Code war lange das knappe Gut. Jetzt ist er billig – knapp sind Klarheit, Urteilsvermögen und jemand, der für das Ergebnis geradesteht.
Klarheit heißt: Was genau soll gebaut werden, für wen, unter welchen Randbedingungen? Urteilsvermögen heißt: Ist das richtig, sicher, wartbar, und passt es ins Ganze? Verantwortung heißt: Wer erklärt dem Kunden, warum es nicht funktioniert?
Ein Bild hilft: Wer früher Maurer war, wird eher Bauleiter. Aber ein guter Bauleiter muss mauern können – sonst sieht er nicht, wenn die Wand schief wird. Das Handwerk verschwindet also nicht, es wandert vom Ausführen zum Beurteilen.
Jede Rolle trifft das anders:
| Rolle | Was schrumpft | Was wächst |
|---|---|---|
| Einsteiger | Routineaufgaben als Übungsfeld | Code lesen, debuggen und erklären können; verstehen statt übernehmen |
| Entwickler | Boilerplate, Standardlogik, Nachschlagen | Aufgaben zerlegen, Kontext liefern, Ergebnisse prüfen, Tests als Spezifikation |
| Senior / Architekt | Selbst implementieren | Leitplanken setzen (Architektur, Konventionen, Regeln für Agenten), Reviews, Mentoring |
| Test / QA | Testfälle von Hand schreiben | Teststrategie, Abnahmekriterien, die Prüfung der Prüfung |
| Teamlead / Product Owner | Schätzen in Personentagen | Präzise Anforderungen, Priorisierung, schnellere Entscheidungen |
Schwieriger ist, was in keiner Tabelle steht: das Selbstbild. „Ich bin, was ich programmiere“ trägt nicht mehr. Tragfähiger ist: „Ich sorge dafür, dass Software entsteht, die ein echtes Problem löst – und ich kann begründen, warum sie richtig ist.“
Dazu gehört, dass Fachwissen wertvoller wird als Framework-Wissen. Eine KI kennt jedes .NET-API, aber nicht die Eigenheiten einer Energieabrechnung oder die ungeschriebenen Regeln im Haus des Kunden. Wer die Domäne versteht, für die er baut, ist schwer zu ersetzen.
Persönliche Weiterentwicklung: mehr als ein neues Werkzeug
Der Umstieg ist zur Hälfte ein technisches Projekt und zur Hälfte ein persönliches. Die zweite Hälfte wird fast immer unterschätzt.
Ein Ende anerkennen. Der Organisationsberater William Bridges unterschied zwischen Veränderung, die von außen kommt, und dem inneren Übergang, den jeder selbst durchlaufen muss. Jeder Übergang beginnt mit einem Ende, dann folgt eine unsichere Zwischenzone, erst danach ein Neuanfang. Wer so tut, als ändere sich nichts, bleibt länger in der Zwischenzone stecken. Es hilft, sich ehrlich einzugestehen, was man vermissen wird.
Den Selbstwert neu verankern. Wer seinen Wert an der Menge selbst geschriebenen Codes misst, verliert gegen jede Maschine. Tragfähiger sind Maßstäbe, die eine KI nicht erfüllen kann: das gelöste Problem, die gute Entscheidung, das Vertrauen von Kunden und Kollegen.
Wieder Anfänger sein dürfen. Gerade Erfahrenen fällt das schwer. Neue Arbeitsweisen fühlen sich die ersten Wochen langsamer und ungeschickter an – das ist normal und kein Beweis, dass sie nichts taugen.
Klar sprechen und schreiben. Wer einer KI eine Aufgabe sauber beschreiben kann, kann es auch einem Kollegen: Ziel benennen, Annahmen offenlegen, Abnahmekriterien festlegen. Dasselbe gilt im Gespräch mit Fachabteilungen. Die richtigen Fragen zu stellen, wird zur Kernaufgabe – und das ist Kommunikation, keine Technik.
Urteilen und widersprechen. Eine KI klingt immer überzeugt. Einer schnellen, freundlichen, selbstbewussten Antwort zu sagen „Das ist falsch“, braucht Selbstvertrauen (mehr dazu in Überzeugend falsch). Und gegenüber Vorgesetzten, die jetzt das Dreifache erwarten, braucht es den Mut zu realistischen Zusagen.
Weitergeben. Erfahrung wird nicht wertlos, sie wird zur Lehraufgabe. Zu erklären, warum man eine scheinbar funktionierende Lösung verwirft, ist wertvolles Wissen, das ein Senior heute weitergeben kann.
Das eigene Tempo finden. Niemand muss jedes Werkzeug am Erscheinungstag beherrschen. Wer sich jede Woche neu erfindet, brennt aus. Besser: ein Werkzeug gründlich lernen, in Ruhe prüfen, was sich lohnt.
Der Umstieg in der Praxis
Der Weg in die KI-gestützte Entwicklung führt nicht über Kurse, sondern über echte Arbeit – in kleinen, prüfbaren Schritten.
- Klein und echt anfangen. Keine Demo-Apps, sondern eine überschaubare Aufgabe aus dem eigenen Alltag: Tests für bestehenden Code, ein Migrationsskript, fehlende Dokumentation.
- Vom Autovervollständigen zum Agenten wechseln. Chat und Code-Vorschläge sind ein Anfang. Die Arbeitsweise ändert sich erst, wenn ein Agent selbst Dateien liest, Befehle ausführt und Tests laufen lässt – mit klaren Leitplanken.
- Kontext aufschreiben. Architektur, Konventionen, Verbote und Fachbegriffe gehören in eine Projektdatei, die der Agent bei jedem Start liest (etwa
AGENTS.md,CLAUDE.mdodercopilot-instructions.md). Warum das so viel ausmacht, erklärt Wenn dem Modell der Kontext ausgeht. - Erst planen lassen, dann bauen. Lass Dir einen Plan vorlegen und korrigiere ihn, bevor Code entsteht. Ein falscher Plan kostet zwei Minuten, falscher Code zwei Stunden.
- Tests zur Spezifikation machen. Ohne Tests ist Agentenarbeit Glücksspiel. Lass Tests ruhig erzeugen – aber prüfe sie selbst, denn sie sind der Vertrag.
- Jeden Diff lesen wie den eines neuen Kollegen. Die Grundregel: Nichts mergen, was Du nicht erklären kannst.
- Beim Lernen fragen statt delegieren. Wer Neues lernt, sollte um Erklärungen bitten und Konzeptfragen stellen, statt fertigen Code abzurufen. Dieses Verhalten unterschied im Anthropic-Experiment die Teilnehmer, die viel lernten, von denen, die wenig behielten. Viele Werkzeuge haben dafür eigene Lern- oder Erklärmodi.
- Bewusst ohne KI üben. Regelmäßig einen Bug selbst jagen, ein Modul selbst entwerfen – nicht aus Nostalgie, sondern um urteilsfähig zu bleiben.
- Messen statt fühlen. Notiere bei ein paar Aufgaben Zeit, Nacharbeit und Fehler – mit und ohne KI.
Wenn Du gerade erst anfängst: Zeig nicht, dass Du Code erzeugen kannst, sondern dass Du ihn verstehst. Code lesen, debuggen, eine Entscheidung begründen – das unterscheidet Dich von jedem, der nur Prompts abschickt. Und such Dir eine Fachdomäne, die Dich wirklich interessiert.
Wenn Du schon lange dabei bist: Deine Erfahrung ist der Hebel, nicht das Hindernis – nutze sie für Leitplanken, Reviews und die Begleitung von Einsteigern.
Für Teams und Führungskräfte
Ob der Umstieg gelingt, entscheidet sich selten am Werkzeug, sondern an der Organisation drumherum. Wer Führungsverantwortung hat, trägt hier den größeren Teil.
- Eine klare Haltung formulieren. Welche Werkzeuge sind erlaubt, welche Daten dürfen hinein, wer haftet wofür? Unklarheit erzeugt entweder Schatten-KI oder Stillstand. Zu den Grundlagen, die DORA für erfolgreiche KI-Einführung nennt, gehört diese klar kommunizierte Haltung.
- Fundament vor Tempo. Tests, kleine Änderungen, schnelle Rückmeldung aus der Pipeline und genug Zeit fürs Review: Was ohne KI gute Praxis war, wird mit KI zur Pflicht.
- Weiter Einsteiger einstellen – und anders ausbilden. Ein Ausbildungsplan statt eines Ersatzplans: Junioren erklären im Review, was der Agent gebaut hat, lösen gezielt Aufgaben ohne KI und arbeiten eng mit Erfahrenen zusammen.
- Gewinne nicht sofort verfrühstücken. Wer jede gewonnene Stunde direkt in mehr Tickets oder weniger Köpfe umrechnet, nimmt dem Team die Zeit zum Lernen – und bekommt Angst statt Engagement.
- Über die Angst reden. Offene Gespräche über Sorgen bringen mehr als Nutzungsquoten im Dashboard. Psychologische Sicherheit ist die Voraussetzung dafür, dass Leute Fehler der KI melden, statt sie zu vertuschen.
- Karrierepfade neu beschreiben. Was heißt „Senior“ in einem Team mit Agenten? Bewertet werden sollten Urteilsvermögen, Qualität der Entscheidungen und die Fähigkeit, andere besser zu machen – nicht die Zahl der Commits.
Fazit
Die Antwort auf „Was wird aus uns?“ lautet: Es wird anders, und für manche härter als für andere. Einsteiger trifft es zuerst, Erfahrene geraten in Versuchung, einfach so weiterzumachen. Beides ist lösbar, aber nicht von allein.
Software wird weiter gebraucht, vermutlich mehr denn je. Gebraucht werden Menschen, die verstehen, was gebaut werden soll, beurteilen können, ob es richtig ist, und dafür einstehen. Das ist kein Abstieg vom Handwerker zum Korrekturleser, sondern der Schritt vom Ausführen zum Verantworten – wenn man ihn bewusst geht.
Überarbeitet am 5. Oktober 2026 nach Rückmeldungen von Lesern: weniger Superlative, gestrafft und um meine Erfahrung mit Agenten ergänzt. Am 7. Oktober 2026 auf die Stack-Overflow-Umfrage 2026 aktualisiert.
/compact – das Wichtigste, wenn der Kontext knapp ist:
KI verändert die Softwareentwicklung, aber anders, als Hype und Abwehr behaupten. Mehr als vier von fünf Entwicklern nutzen sie, doch die Begeisterung hält nicht Schritt. Wie viel sie bringt, hängt an Werkzeug, Fundament und Arbeitsweise; das Gefühl allein ist ein schlechter Maßstab. Am Arbeitsmarkt trifft es zuerst die Einsteiger; einen Massenabbau zeigen die Daten nicht.
Die Sorgen der Entwickler sind meist eine nüchterne Lageeinschätzung, unlösbar ist keine. Die Arbeit verschiebt sich vom Schreiben zum Beschreiben, Prüfen und Verantworten. Was hilft: klein anfangen, Kontext aufschreiben, erst planen lassen, Tests als Vertrag nehmen und nichts mergen, was man nicht erklären kann. Teams brauchen dazu klare Regeln, ein solides Fundament und auch künftig Einsteiger.