Skill-Shift statt Stellenabbau: Was Entwickler über ihre Arbeit mit KI berichten

KI ersetzt in der Praxis keine Entwickler, sie verschiebt deren Arbeit. Die neue Kernaufgabe heißt Kontrolle, und organisiert hat sie fast niemand.

Über KI und Entwickler-Jobs wird viel geschrieben, meist auf Basis von Studien aus Ökonomie, Beratung und HR. Nützlich, aber sie reden über die Betroffenen. Wir haben sie selbst gefragt: Im Rahmen einer Erhebung des PySV e. V. hat die PyCon-DE-Community berichtet, wie sich ihr Arbeitsalltag mit KI verändert, und ob überhaupt. 383 Antworten von der vordersten Front, erhoben Anfang Juni 2026, überwiegend von erfahrenen Entwicklerinnen und Entwicklern aus Deutschland. Das Ergebnis widerspricht den Schlagzeilen: Nicht Stellen verschwinden, sondern Tätigkeiten verschieben sich, hin zu Kontrolle und Verantwortung, die bislang fast niemand organisiert.

Auf einen Blick

• KI-Nutzung ist Alltag: 96 Prozent nutzen KI-Tools mindestens mehrmals täglich, gut jeder Fünfte automatisiert über die Hälfte seiner Routineaufgaben. Trotzdem berichtet in über 1.200 Freitexten niemand von konkretem Stellenabbau durch KI.
• Die Arbeit verschwindet nicht, sie verschiebt sich: 68 Prozent nennen das Prüfen und Kuratieren von KI-Output als neue Aufgabe. Nur 9 Prozent sagen, es seien keine nennenswerten neuen Aufgaben entstanden.
• Der Skill-Shift hat eine klare Richtung: Domänenwissen (60 Prozent), Architektur (56 Prozent) und Anforderungskommunikation (48 Prozent) gewinnen an Wert, während die Schreibarbeit zur Maschine wandert.
• Die eigentliche Lücke ist organisatorisch und liegt zwischen den Abteilungen: 71 Prozent sagen, die Verantwortung für KI-verursachte Fehler ist nicht geregelt und landet faktisch beim einzelnen Entwickler. Eine formale Evaluation hat nicht einmal jeder dritte Befragte.

Wir haben die Front gefragt, nicht über sie geredet

Die meisten Zahlen zur Zukunft der Entwicklerarbeit stammen aus Modellrechnungen, Analystenreports oder HR-Umfragen. Sie sind nützlich, betrachten die Betroffenen aber von außen. Diese Erhebung dreht die Perspektive um und fragt die Menschen, die KI-Werkzeuge täglich produktiv einsetzen, was sich in ihrer Arbeit konkret ändert.

Bewusst haben wir dort gefragt, wo die Veränderung am weitesten ist: in einer erfahrenen, KI-affinen Python-Community. Wer wissen will, wohin sich ein Beruf bewegt, schaut nicht in den Durchschnitt, sondern an die Spitze der Bewegung. Genau dort zeigt sich das Bild deutlicher, als die Schlagzeilen vermuten lassen.

Die neue Arbeit: prüfen, kuratieren, steuern

Der belastbarste Befund der Erhebung ist die Gegenliste zur Automatisierung. Auf die Frage, welche Aufgaben durch KI neu entstanden sind, nennen 232 von 343 Befragten (68 Prozent) das Überprüfen und Kuratieren von KI-Output. Es folgen das Schreiben von Prompts und Anweisungen (48 Prozent) und das Aufbereiten von Kontext für die Werkzeuge (38 Prozent). Nur 30 Befragte sehen keine nennenswerten neuen Aufgaben.

So räumt die Erhebung mit dem ersten Klischee auf: KI lässt Arbeit nicht verschwinden. Selbst bei nahezu flächendeckender Nutzung, 96 Prozent setzen KI mindestens mehrmals täglich ein, ein Viertel „fast durchgehend", findet Substitution auf Tätigkeitsebene statt, nicht auf Stellenebene. Delegiert werden Boilerplate, Tests, Dokumentation, Recherche, Refactoring, Prototypen. Was bleibt, ist nicht weniger Arbeit, sondern andere. In über 1.200 Freitexten berichtet niemand von konkretem Stellenabbau durch KI, nur 4 Prozent erleben ihre Arbeit als entwertet, und 45 Befragte vermissen in ihren Teams sogar zusätzliche klassische Entwickler.

Das zweite Klischee fällt gleich mit: dass KI entlastet. 67 Prozent beschreiben ihre KI-intensiven Arbeitstage als dichter, anstrengender oder gleich belastend bei höherem Output. Spürbar entlastet fühlen sich 6 Prozent. Die Produktivitätsdividende existiert, aber sie kommt bislang nicht als Entlastung im Team an, sondern als Erwartungssteigerung.

Aus Entwicklerarbeit wird Prüfarbeit. Wer das nicht einplant, bekommt sie trotzdem: unbudgetiert, unsichtbar und auf Kosten der Substanz.

Skill-Shift: vom Produzenten zum verantwortlichen Prüfer

Stellt man nebeneinander, was die Befragten an die Maschine abgeben und was an Wert gewinnt, entsteht das eigentliche Bild dieser Erhebung:

Auffällig dabei: Prompting wird zwar von knapp der Hälfte als neue Tätigkeit gelebt, aber nur von einem Drittel als wertsteigernder Skill eingeschätzt. Die Community wertet Kontext- und Domänenkompetenz höher als Prompt-Handwerk, eine Bestätigung der Hire-Logik „Domänenexperte mit Experimentierwillen", die ich nach der PyCon DE & PyData 2026 beschrieben habe.

In den Daten zeichnen sich drei exemplarische Profile ab, je nach Arbeitsfeld. Data Engineers verschieben sich am stärksten Richtung Fachlichkeit und Business-Übersetzung. Web-Entwickler delegieren am meisten Codeproduktion und werden zu Architekten des generierten Codes. ML-Engineers, die Gruppe mit der tiefsten KI-Nutzung, bauen am häufigsten das auf, was allen anderen fehlt: Evals, Kontext-Pipelines, Agenten-Steuerung. Die Rolle des Eval-Ingenieurs entsteht gerade, in den Daten sichtbar, bevor sie in Stellenanzeigen steht.

Vertrauen wächst schneller als Kontrolle

Der unbequemste Befund liegt quer zu beiden Lagern der Job-Debatte. Das Vertrauen in KI-Output ist zuletzt bei 58 Prozent gestiegen. Die Kontrollstrukturen sind nicht mitgewachsen: 89 Prozent prüfen KI-Output per manuellem Review, aber nur 30 Prozent haben eine formale Eval-Pipeline. 14 Prozent verlassen sich nach eigener Aussage überwiegend auf Bauchgefühl.

Und die Verantwortungsfrage ist offen: 71 Prozent sagen, bei einem KI-verursachten Bug sei die Haftung nicht explizit geregelt, sie liegt in der Praxis beim Entwickler, der den Code übernommen hat. Ein dokumentiertes Framework mit Review-Pflicht, Sign-off und Audit-Trail haben 11 Prozent. Damit fällt auch das dritte Klischee, die KI-Einführung sei vor allem ein Technikproblem. Als größte Engpässe nennen die Befragten nicht die Werkzeuge, sondern unklare Verantwortlichkeiten (40 Prozent) sowie Security, Datenschutz und EU AI Act (36 Prozent). Beides sind keine Engineering-Fragen, sondern organisatorische, und sie entstehen genau dort, wo Geschäftsleitung, Entwicklung und Compliance aneinandergrenzen.

Die 59 geschilderten Vorfälle illustrieren, was das konkret heißt: still geänderter Aufgabenumfang, versteckte Code-Duplikate, Löschvorschläge für Produktivdaten trotz Guardrails. Ein Befragter bringt das Grundmuster auf den Punkt:

„Es passiert öfters beim generieren von Code, dass Packageversionen einfach erfunden werden […] Wenn man darauf blind vertraut kommt man schnell in einen Strudel von Halluzinationen und Debugging an der völlig falschen Stelle."

Genau hier schließt sich der Kreis: Die neue Prüfarbeit existiert heute als individuelle Heldenleistung. Tragfähig wird sie erst als System, als Harness aus Evals, Audit-Spur und geregelter Freigabe, das gleiche Muster, das ich in Agenten in Produktion anhand von Trust Boundaries beschrieben habe. Wer Qualitätssicherung als kritische Funktion ernst nimmt, kann sie nicht dem Bauchgefühl des Einzelnen überlassen und schon gar nicht an einer Abteilungsgrenze versanden lassen.

Neu denken statt abbilden

Diese Zahlen sind keine Verlustmeldung, sondern eine Gestaltungsaufgabe. KI ist kein schnelleres Werkzeug für die alte Arbeitsweise. Wer bestehende, papiergetriebene Prozesse eins zu eins in KI-Systeme abbildet, multipliziert deren Schwächen, statt sie zu beheben. Der Economist hat dieses Muster zuletzt am Beispiel Indiens beschrieben: Eine Digitalisierung, die nur den Papierprozess nachbaut, schafft keine Effizienz, sondern Chaos. Für KI gilt dasselbe, nur schneller und teurer.

Was KI ermöglicht

KI nimmt erfahrenen Fachleuten die Routine ab: Fast die Hälfte automatisiert mindestens 30 Prozent ihrer Routineaufgaben. Das setzt Kapazität frei für das, was an Wert gewinnt, also Domänenwissen, Architektur und Urteil. Die Rolle steigt vom Produzenten zum verantwortlichen Gestalter. Neue Funktionen entstehen, etwa der Eval-Ingenieur, der die Kontrollinfrastruktur baut, von der alle profitieren. Wer KI zum Anlass nimmt, Prozesse und Verantwortung neu zu schneiden, gewinnt mehr als Geschwindigkeit.

Was dabei zu navigieren ist

Die Kehrseite ist real, aber beherrschbar, sobald man sie benennt. Die Produktivität kommt bislang nicht als Entlastung an, sondern als dichtere Tage und höhere Erwartung. Das Vertrauen wächst schneller als die Kontrolle. Und die neue Prüf- und Verantwortungsarbeit fällt durch die Lücke zwischen den Abteilungen. Keiner dieser Punkte ist ein Grund zu bremsen. Jeder ist ein Grund, bewusst zu gestalten, statt die alte Organisation einfach weiterlaufen zu lassen. Wie Harness, Evaluation und Governance architektonisch zusammenspielen, habe ich in Die neue KI-Architektur 2026 zusammengeführt.

Für Entscheider heißt das

Erstens: Governance als Querschnitt, nicht als Silo

Der größte Engpass ist nicht die Technik, sondern die ungeklärte Zuständigkeit, und sie verläuft zwischen den Abteilungen. Die Geschäftsleitung erwartet Tempo, die Teams tragen die faktische Haftung (71 Prozent), Security und Compliance sitzen daneben. Eine tragfähige KI-Nutzung braucht ein gemeinsames Verantwortungsmodell über diese Ebenen hinweg: Review-Pflicht, Sign-off und Audit-Spur, gemeinsam getragen statt nach unten delegiert.

Zweitens: Kontrollarbeit als echte Arbeit budgetieren

Die neuen Prüf-, Kuratierungs- und Steuerungsaufgaben sind in keiner Velocity-Planung abgebildet, in 68 Prozent der Antworten aber real. Wer sie nicht einpreist, bezahlt sie mit Erschöpfung und Qualitätsverlust.

Drittens: Review-Last in Eval-Disziplin überführen

89 Prozent manuelles Review bei 30 Prozent formaler Evaluation ist kein Qualitätskonzept, sondern ein Engpass mit Ansage. Die wertvollste Investition bleibt ein eigenes, versioniertes Eval-Set, getragen vom fachlichen Eigentümer.

Viertens: Profile schärfen, nicht Stellen streichen

Die Daten geben keinen Anlass, Entwickler-Stellen zu streichen. Sie geben Anlass, Profile zu schärfen: Domänenwissen, Architektururteil, Eval-Kompetenz. Befragte melden Bedarf an klassischen Entwicklern, nicht deren Ende.

Der gemeinsame Nenner dieser vier Punkte ist kein Werkzeug, sondern eine Organisationsfrage. Die Daten zeigen genau, wo interne Strukturen tragen und wo sie knirschen: an den Nahtstellen zwischen Geschäftsleitung, Entwickler- und Datenteams, Security und Compliance.

Diese Lücke schließt sich nicht aus einer einzelnen Abteilung heraus. Sie verlangt Übersetzung in beide Richtungen, von der Strategie ins Engineering und zurück. Das gelingt nur mit Menschen, die auf allen Ebenen ernst genommen werden, von der Geschäftsleitung bis ins Entwicklerteam und überall dazwischen. Genau dort arbeite ich: Ich verbinde diese Ebenen, ordne ein, was KI wirklich leistet, und überführe die neue Kontrollarbeit in eine Governance, die im Alltag trägt. Wer wissen will, wo die eigene Governance-Lücke am größten ist, findet in der Boardroom-to-Code Session den strukturierten Einstieg.

KI ersetzt keine Entwickler. Sie verlangt, Arbeit und Verantwortung neu zu denken, und darin liegt die eigentliche Chance.