Vom Code-Schreiber zum Code-Verantwortlichen:
Wie KI das Entwickler-Profil neu sortiert

Ein Berufsbild endet: die Definitionsfrage

Ein Beruf ist über seinen Tätigkeitskern definiert — über das, was jemand den größten Teil seines Arbeitstags tut und wofür er ausgebildet wurde. Der Kern des herkömmlichen Programmierer-Berufs war das Implementieren: Anforderungen entgegennehmen, Code schreiben, Code zum Laufen bringen. Fällt dieser Kern als menschliche Arbeit weg, hört der Beruf in seiner hergebrachten Definition auf zu existieren. Das ist keine Zukunftsdeutung, das ist Begriffslogik — offen ist allein, wie schnell einzelne Betriebe den Wegfall nachvollziehen.

Dass der Kern fällt, ist inzwischen amtlich vermessen. Das Institut für Arbeitsmarkt- und Berufsforschung, die Forschungseinrichtung der Bundesagentur für Arbeit, bewertet für jeden Beruf, welcher Anteil seiner Kerntätigkeiten vollautomatisch erledigt werden könnte. Für Softwareentwickler ist dieses Substituierbarkeitspotenzial zwischen 2019 und 2022 um rund 30 Prozentpunkte gestiegen — und die IT-Berufe verzeichnen damit den stärksten Anstieg aller untersuchten Berufssegmente. Der Auslöser laut IAB: generative KI kann selbstständig programmieren. Die Werkzeuge, die seither erschienen sind, haben diese Bewertung nicht entschärft, sondern eingeholt.

Der Entwickler-Beruf ist damit der zweite, an dem dieselbe Mechanik durchläuft, die derzeit die Kreativabteilungen erfasst — dort fällt das Produktionshandwerk des Mediengestalters, wie unser Beitrag über KI in Design-Abteilungen zeigt. Bei den Entwicklern läuft sie schneller, denn Code ist das Heimspiel der Sprachmodelle: strukturiert, testbar und in gewaltigen Mengen als Trainingsmaterial vorhanden. Was verschwindet, ist in beiden Fällen das Berufsbild — nicht die Menschen. Der Unterschied zwischen beiden Aussagen entscheidet über die richtige Reaktion, und er zieht sich durch den Rest dieses Beitrags.

Warum die Branche leiser spricht, als die Zahlen es tun

Wer diese Entwicklung in Anbieter- und Verbandskommunikation nachliest, findet auffallend weiche Formulierungen: von „Assistenz" ist die Rede, von „Unterstützung im Alltag", davon, dass sich „am Berufsbild im Kern nichts ändert". Diese Zurückhaltung sagt wenig über die Datenlage und viel über die Interessenlage derer, die formulieren.

Drei Anreize wirken hier gleichzeitig. Wer Entwicklungsleistung nach Aufwand verkauft, entwertet mit jedem offenen Wort über automatisiertes Implementieren die eigene Kalkulationsbasis. Wer Aus- und Weiterbildung für das hergebrachte Curriculum anbietet, sägt mit der klaren Diagnose am eigenen Katalog. Und wer eine Belegschaft aus Code-Schreibern führt, wird ihren Rollenwandel kaum in der Außenkommunikation vorwegnehmen. Alle drei Motive sind nachvollziehbar — nur helfen sie niemandem, der auf dieser Grundlage einstellen, ausbilden oder einkaufen muss.

Deshalb stützt sich dieser Beitrag auf Messgrößen statt auf Selbstbeschreibungen: Das Substituierbarkeits-Register der amtlichen Arbeitsmarktforschung nimmt keine Rücksicht auf Geschäftsmodelle, und die Sicherheits- und Stabilitätsdaten aus dem nächsten Kapitel stammen aus Messungen, nicht aus Broschüren. Für Sie als Auftraggeber folgt daraus eine einfache Lesehilfe: Je beruhigender eine Anbieteraussage zum Thema klingt, desto genauer lohnt der Blick auf das, was sich prüfen lässt.

Die fünf Schichten der Entwicklungsarbeit

Um präzise zu sehen, was verschwindet und was entsteht, hilft es, „Softwareentwicklung" nicht als einen Block zu betrachten, sondern als fünf übereinanderliegende Tätigkeitsschichten — jede mit ihrem eigenen Automatisierungsgrad:

• Schicht 1 — Implementieren: Syntax, Standardmuster, Routine-Code. Am weitesten automatisiert. Das war der definierende Kern des alten Berufs und zugleich seine Ausbildungs- und Einstiegsschicht.
• Schicht 2 — Prüfen und Testen: Review, Testentwurf, Fehlersuche. Wächst im Volumen, weil jede erzeugte Zeile geprüft werden muss — von Menschen, die verstehen, was sie lesen.
• Schicht 3 — Entwerfen: Architektur, Schnittstellen, Datenmodell. Die Maschine schlägt vor; entscheiden muss ein Mensch, der Randbedingungen kennt, die in keinem Code stehen — Budget, Bestandssysteme, Team.
• Schicht 4 — Übersetzen: Fachdomäne in präzise Anforderungen überführen. Der Engpass, den kein Modell füllt, weil das entscheidende Wissen im Betrieb steckt, nicht im Trainingsmaterial.
• Schicht 5 — Verantworten: Freigabe, Nachvollziehbarkeit, Sicherheits- und Rechtsfolgen. Prinzipiell nicht delegierbar — und mit jeder automatisierten Schicht darunter gewichtiger.

Die Neusortierung des Profils ist damit keine Behauptung mehr, sondern eine Ableitung: Schicht 1 geht an die Maschine, die Schichten 2 bis 5 fallen vollständig auf den Menschen zurück — in größerem Volumen und mit höherem Anspruch als zuvor. Auch das IAB kommt zu diesem Schluss: In keinem Beruf sind alle Tätigkeiten automatisierbar, aber die verbleibenden verschieben sich zum Konzipieren, Einrichten, Warten und Bewerten der Systeme. Genau das ist der Weg vom Code-Schreiber zum Code-Verantwortlichen.

Die Denkarbeit wandert nach vorn

Die Schichten 3 und 4 verändern durch die Automatisierung ihren Charakter — und hier liegt der Kern des neuen Anforderungsprofils. KI-gestützte Entwicklung kehrt die Arbeitsreihenfolge um: Wer früher Funktion für Funktion schrieb, konnte sich das System unterwegs erschließen und Kurskorrekturen im Kleinen vornehmen. Wer heute erzeugen lässt, muss das System vorher fertig gedacht haben — Wechselwirkungen zwischen Modulen, Datenflüsse, die Anbindung an Bestandssysteme, Fehlerfolgen im Gesamtprozess. Die Maschine setzt in Minuten um, was der Mensch spezifiziert hat. Sie setzt auch in Minuten um, was er falsch spezifiziert hat.

Planerische Kompetenz und vernetztes Denken sind damit keine Begleitfähigkeiten mehr, sondern der neue Tätigkeitskern. Die Qualität eines KI-gestützt gebauten Systems ist eine direkte Funktion der Qualität der Vorausplanung — jede Unschärfe im Entwurf wird mit Maschinengeschwindigkeit in Code gegossen und muss später mit Menschengeschwindigkeit wieder herausoperiert werden.

Dazu kommt eine Fähigkeit, die im alten Beruf das Werkzeug erledigte: sprachliche Präzision. Bisher erzwang die Programmiersprache die Eindeutigkeit — mehrdeutigen Code gab es nicht, der Übersetzer lehnte ihn ab. Jetzt ist natürliche Sprache die Schnittstelle zur Maschine, und die kennt keine solche Kontrolle: Eine unscharfe Anweisung erzeugt keine Fehlermeldung, sondern ein plausibles, falsches Ergebnis. Die Präzisionsdisziplin, die im Compiler steckte, muss der Entwickler jetzt selbst mitbringen — sauber abstrahieren, Probleme in benennbare Teile zerlegen, Annahmen explizit machen, Mehrdeutigkeiten erkennen, bevor die Maschine sie ausnutzt. Wer unklar denkt, formuliert unklar und erhält unklaren Code in fehlerfreier Syntax. Die Handwerksebene dieser Disziplin behandelt unser Beitrag über das richtige Kommunizieren mit KI; hier genügt der Befund: Die Anforderungsbeschreibung ist der neue Quelltext.

Der neue Engpass: Prüfen statt Schreiben

Wenn Erzeugen billig wird, verschiebt sich der Flaschenhals der Produktion dorthin, wo es teuer bleibt: ins Prüfen. Die Zahlen dazu sind deutlich. In einer internationalen Entwickler-Befragung mit rund 49.000 Teilnehmern (Stack Overflow, 2025 — Community-Umfrage ohne Repräsentativitäts-Anspruch) geben 84 Prozent an, KI-Werkzeuge zu nutzen oder es konkret vorzuhaben; die Hälfte der professionellen Entwickler arbeitet täglich damit. Zugleich sagen nur 29 Prozent, dass sie den Ergebnissen vertrauen. Fast alle nutzen es, kaum einer traut ihm — diese Lücke ist exakt das Arbeitsvolumen, das in Schicht 2 entsteht.

Dass das Misstrauen begründet ist, zeigt eine Sicherheitsanalyse des Code-Prüfanbieters Veracode (2025): Von den Code-Proben, die mehr als 100 Sprachmodelle zu 80 standardisierten Aufgaben erzeugten, fielen 45 Prozent durch gängige Sicherheitstests — und neuere, größere Modelle schrieben funktional besseren, aber nicht sichereren Code. Der DORA-Forschungsbericht 2025 (knapp 5.000 befragte Fachleute) ergänzt die Systemsicht: KI-Einsatz erhöht den Durchsatz der Entwicklung, belastet aber die Stabilität der Auslieferung — wenn keine belastbaren Kontrollsysteme dagegenstehen, erzeugt mehr Änderungsvolumen schlicht mehr Instabilität.

Das Tückische daran ist die Plausibilitätsfalle: Maschinell erzeugter Code scheitert selten an der Syntax. Er scheitert an inhaltlichen Fehlern, die korrekt aussehen — der falsch behandelte Sonderfall, die stillschweigend geänderte Annahme, die Sicherheitslücke im sauber formatierten Codeblock. Prüfen ist dadurch anspruchsvoller geworden als Schreiben, denn der Prüfer muss Fehler finden, die sich tarnen. Für Geschäftsführer folgt daraus eine unbequeme Messfrage: Wer Entwicklungsleistung weiter am Output misst — Features, Tempo, Codemenge —, misst die Schicht, die die Maschine liefert, und übersieht die, an der sein Produkt hängt.

Das Junior-Paradoxon

Die automatisierte Schicht 1 hatte eine zweite Funktion, die in der Effizienzrechnung nicht auftaucht: Sie war die Lernschicht. Über das tausendfache Implementieren sind bisher die Könner entstanden, die heute entwerfen, prüfen und verantworten können. Ein Senior ist ein Junior, der jahrelang Fehler gemacht und verstanden hat.

Wer die Einstiegsschicht wegautomatisiert, ohne den Lernpfad zu ersetzen, sägt deshalb an der eigenen Senior-Pipeline: In fünf Jahren fehlen die Prüfer, weil heute niemand mehr die Arbeit macht, an der man Prüfen lernt. Für Betriebe, die ausbilden oder Berufseinsteiger beschäftigen, ist das die konkreteste Konsequenz des ganzen Wandels — und sie ist lösbar: Der neue Lernpfad ist das begleitete Prüfen. Einsteiger lesen, testen und zerlegen maschinell erzeugten Code unter Anleitung, statt selbst Routine-Code zu tippen. Das ist anspruchsvoller als der alte Weg, und es setzt voraus, dass der Betrieb ihn bewusst baut, statt darauf zu warten, dass Erfahrung von selbst entsteht.

Dieselbe Logik entwertet den alten Ausbildungsweg: Ein Curriculum, das primär Syntax und Implementierung lehrt, bildet für die Schicht aus, die es als menschliche Arbeit nicht mehr gibt. Auch hier gilt die Definitionsfrage vom Anfang — nicht als Prognose, sondern als Konsequenz.

Einstellen und Einkaufen nach dem neuen Profil

Niemand stellt sinnvoll für einen Beruf ein, den es nicht mehr gibt. Wer eine Entwickler-Stelle besetzt, besetzt heute die Schichten 2 bis 5 — und muss folglich anders prüfen als mit der klassischen Programmieraufgabe, die nur Schicht 1 misst. Drei Prüfungen leisten das:

1. Die Systemfrage: „Skizzieren Sie, was sich alles ändert, wenn dieser eine Prozessschritt automatisiert wird." Wer nur die Funktion sieht, denkt in Schicht 1. Wer Datenflüsse, Nachbarprozesse und Fehlerfälle mitnennt, denkt vernetzt.
2. Die Formulierungsaufgabe: „Beschreiben Sie diese Anforderung so, dass ein System sie ohne Rückfrage umsetzen kann." Präzise formulieren kann nur, wer präzise denkt — die Aufgabe prüft beides zugleich.
3. Das Review unter Beobachtung: Maschinell erzeugten Code mit einem versteckten inhaltlichen Fehler vorlegen. Gesucht ist keine Syntax-Kritik, sondern die Frage nach Annahmen, Sonderfällen und Tests — das Verhalten eines Verantwortlichen, nicht eines Schreibers.

Die allgemeinen Verhaltenssignale für den Umgang mit KI-Werkzeugen — Neugier, Reflexion des eigenen Arbeitsablaufs, Reaktion auf Umstellungs-Szenarien — haben wir im Beitrag zum Einstellungskriterium KI-Affinität ausgearbeitet; die drei Prüfungen hier sind deren Entwickler-Fassung.

Für die Mehrheit der Mittelständler ist die wichtigere Anwendung allerdings der Einkauf: Sie beschäftigen keine Entwickler, sie beauftragen welche. Dann gilt dieselbe Schichten-Logik von außen — maßgeblich ist nicht, ob ein Dienstleister KI einsetzt (das tun inzwischen fast alle), sondern ob er die Schichten 2 und 5 beherrscht: ein nachweisbares Prüfverfahren für erzeugten Code, belegbare automatisierte Tests, eine benannte Person, die Freigaben verantwortet. Wer auf diese Fragen präzise Antworten bekommt, kauft kontrollierte Produktion. Wer Geschwindigkeit ohne Prüfkette angeboten bekommt, kauft ein Risiko mit Lieferdatum.

Was aus den Entwicklern wird

Das Berufsbild endet, die Menschen nicht — und die Reihenfolge, in der ein Betrieb daraus Konsequenzen zieht, entscheidet darüber, ob er Substanz gewinnt oder verliert. Der langjährige Entwickler ist kein Auslaufmodell, er ist der geborene Code-Verantwortliche: Wer jahrelang selbst implementiert hat, besitzt genau das Gespür für kippende Stellen, das die Plausibilitätsfalle verlangt. Dieses Erfahrungswissen ist der Rohstoff der neuen Rolle, und es steht in keiner Lizenz und keinem Lebenslauf eines Neueinsteigers.

Der Umstieg organisiert sich über dieselben Bausteine wie jeder Rollenwandel: klar definierte Prüfprozesse statt informellem Review, Schulung in der Arbeit mit den erzeugenden Systemen, Zeit für den Übergang — und ein Messsystem, das Prüf- und Entwurfsleistung honoriert statt Codemenge. Wie sich die Rolle des Fachexperten generell vom Ausführenden zum Steuernden verschiebt, entwickelt unser Beitrag Domänen-Experte plus KI: Vom Auftraggeber zum Operator — der Entwickler ist davon der am weitesten fortgeschrittene Fall.

Und für den Betrieb als Ganzes schließt sich hier der Kreis zur Ausgangsfrage dieser Serie: Die Neusortierung findet statt, ob ein Unternehmen teilnimmt oder nicht. Warum Abwarten dabei das teurere Risiko ist als jeder kontrollierte Anfang, begründet der Auftakt der Serie — KI-Angst und das falsche Risiko.