Früher habe ich den Großteil meines Codes selbst getippt. Heute lese ich ihn.
Ein KI-Werkzeug schreibt die erste Fassung. Ich erkläre, was wir brauchen, prüfe das Ergebnis und entscheide, ob es veröffentlicht wird. So hat sich meine Arbeit in den neunzehn Monaten seit meinem Start bei beWirken verändert, einer gemeinnützigen Organisation im Bildungsbereich.
Der Rest der Arbeit ist geblieben. Website, Lernplattform und Server müssen laufen. Jemand muss entscheiden, wer welche Daten sehen darf. Generierter Code klärt das alles nicht.
Dahin bewegt sich IT-Arbeit aus meiner Sicht: mehr Verantwortung für das ganze System, während das Tippen einen kleineren Teil des Tages einnimmt.
In diesem Artikel
Die Werkzeuge sind längst da
JetBrains befragte zwischen Mai und Juli 2026 mehr als 15.000 professionelle Entwickler*innen. 90 Prozent gaben an, mindestens wöchentlich KI-Agenten zum Programmieren zu nutzen.[1] Unter den Befragten sind sie also weit verbreitet. Ob die Software dadurch besser wird, verrät die Zahl nicht.
Dieser Unterschied geht gern verloren, wenn eine funktionierende Demo zur Prognose wird, bald brauche niemand mehr Entwickler*innen. Eine Demo zeigt meistens den Fall, in dem alles klappt. Im Alltag kommen alte Daten dazu, fehlende Zugriffsrechte und jemand, der zweimal auf den Knopf drückt.
Über diese Probleme muss ich weiter nachdenken. Egal, wer den Code schreibt.
Wer darf den Beruf noch lernen?
Mich beunruhigt die erste Stufe der Karriereleiter.
Stanfords Analyse vom August 2026 fand bei 22- bis 25-Jährigen in Berufen mit vielen Aufgaben, die KI bearbeiten kann, einen relativen Beschäftigungsrückstand von 19 Prozent. Als Vergleich diente die Entwicklung Gleichaltriger in Berufen mit weniger solcher Aufgaben. Die Daten reichen bis Juni 2026; der Unterschied zeigte sich vor allem bei Neueinstellungen. Das ist ein beobachtetes Muster, kein Beweis dafür, dass KI es verursacht hat.[2]
Kleine Fehlerbehebungen und Routineaufgaben sind auch Gelegenheiten zum Lernen. Wer sie komplett an Agenten abgibt und dann erfahrene Entwickler*innen verlangt, hat ein ziemlich offensichtliches Problem: Wo soll die Erfahrung herkommen?
Teams müssen Berufseinsteiger*innen echte Aufgaben, Rückmeldung und wachsende Verantwortung geben. „Prüf mal, was die KI gemacht hat“ ist ein schwieriger erster Auftrag, wenn man noch nie gelernt hat, woran man gute Arbeit erkennt.
Fünf Arten von Arbeit
Ich teile meinen Job in fünf Verantwortungsbereiche auf. Das sind meine Bezeichnungen für Arbeit, die Menschen längst machen. Eine Person kann mehrere abdecken. In einer kleinen Organisation wie unserer übernehme ich alle fünf.
01 / Bauen
Beim Bauen wird aus einem Wunsch etwas, das Menschen nutzen können.
Meine Arbeit beginnt mit konkreten Fragen: Welche Daten dürfen den Server verlassen? Welche Werkzeuge nutzen wir bereits? Was soll die Person im Schulsekretariat sehen? Ein Agent kann das umsetzen. Eine Anforderung, die ich nicht durchdacht habe, rettet er mir nicht.
Zu wissen, was „fertig“ bedeutet, hilft mir im Alltag mehr, als Befehle auswendig zu kennen. Kann die richtige Person das Werkzeug nutzen? Kommt auch die falsche hinein? Passt es dazu, wie die Organisation tatsächlich arbeitet?
Das ist auch für Menschen nützlich, die Software beauftragen. Mit einer klaren Problembeschreibung können Entwickler*innen deutlich mehr anfangen als mit einer Liste angesagter Funktionen.
02 / Pflegen
Jemand muss die Software noch verstehen, wenn die aufregende Demo sechs Monate her ist.
Bei mir sind das ein WordPress-Shop, eine Lernplattform und mehrere Anwendungen auf gemeinsamer Infrastruktur. Eine Änderung an einer Stelle kann eine andere lahmlegen. Ein Agent kann ein Update vorschlagen. Zu wissen, was davon abhängt, ist der schwierige Teil.
Diese Abhängigkeiten müssen sichtbar werden: Was muss weiter funktionieren? Wie prüfen wir das? Wie kommen wir zurück, wenn die Änderung scheitert? Dieses Wissen darf nicht verschwinden, sobald die Person geht, die es zufällig im Kopf hat.
Wer das Budget verantwortet, sollte fragen, wie die Software nach dem Start am Laufen bleibt. Die erste Version ist erst der Anfang der Rechnung.
03 / Prüfen
Beim Prüfen geht es darum, ob ein Ergebnis Vertrauen verdient. Tester*innen, Sicherheitsfachleute und Forschende tun das bereits.
In Sonars Befragung vom Januar 2026 vertrauten 96 Prozent der befragten Entwickler*innen nicht vollständig darauf, dass KI-generierter Code korrekt funktioniert. Nur 48 Prozent gaben an, ihn vor der Übernahme immer zu prüfen. Das sind Angaben zum eigenen Verhalten.[3] Trotzdem: Zwischen Misstrauen und Handeln liegt offenbar noch etwas Platz.
Ich will die Aufmerksamkeit nach den möglichen Folgen verteilen. Eine neue Farbe braucht einen kurzen Blick. Änderungen an Anmeldung, Zahlungen oder persönlichen Daten brauchen jemanden, der prüft, was im Fehlerfall passiert.
Eine selbstsichere Antwort bekommt man schnell. Festzustellen, ob sie stimmt, kostet Arbeit.
04 / Gestalten
Wenn sich Prototypen leichter bauen lassen, können auch Menschen außerhalb der Entwicklung zeigen, was sie meinen. Das hilft: Wer die Arbeit macht, weiß oft genau, wo der Ablauf hakt.
Die schwierigeren Fragen bleiben. Wer braucht das? Was darf es niemals tun? Wer übernimmt die Verantwortung? Würde ein besserer Ablauf die neue App überflüssig machen?
Wenn man das Werkzeug einfach generieren kann, wird die letzte Frage unbequem. Ich würde sie trotzdem stellen, bevor eine Organisation noch ein System zu betreuen hat.
05 / Betreiben
Wenn sich eine Lehrkraft am Morgen einer Fortbildung nicht anmelden kann, muss jemand den Dienst wieder zum Laufen bringen. Und entscheiden, was gestoppt und wer informiert wird.
Ich betreibe die Server. Agenten können Protokolle auswerten, Lösungen vorschlagen und Updates einspielen. Die Erlaubnis, ein Problem zu untersuchen, ist aber etwas anderes als die Erlaubnis, einen laufenden Dienst zu verändern. Diese Grenzen müssen vor einem Vorfall stehen.
Wer kann die Automatisierung stoppen? Wo ist das Backup? Lässt es sich wiederherstellen? Diese Fragen sind weniger spannend als die Demo. Während eines Ausfalls werden sie deutlich interessanter.
Worauf ich mich konzentrieren würde
Ich würde bei einem Teil der Arbeit ansetzen, den ich beurteilen kann: warum ein System ausfällt, was eine Abteilung braucht oder ob eine Änderung sicher veröffentlicht werden kann. Dann würde ich genug von den angrenzenden Aufgaben lernen, um eine nützliche Idee weiterzubringen.
Und ich würde messen, ob die Werkzeuge helfen. In METRs randomisierter Studie brauchten 16 erfahrene Open-Source-Entwickler*innen mit KI-Werkzeugen von Anfang 2025 für Aufgaben in vertrauten Projekten 19 Prozent länger. Sie hielten sich trotzdem für schneller.[4] Die Folgeuntersuchung vom Februar 2026 lieferte keine belastbare Schätzung für neuere Werkzeuge: Die Auswahl der Teilnehmenden und Aufgaben sowie unzuverlässige Zeiterfassung erschwerten die Messung.[5] Das Ergebnis hängt vom Arbeitsumfeld ab. Mein Gefühl von Geschwindigkeit ist eine schlechte Stoppuhr.
Für mich heißt das vorerst:
- Festlegen, was fertig bedeutet. Ergebnis und Prüfungen aufschreiben, bevor ein Agent loslegt.
- Es selbst reparieren können. Das Ergebnis verstehen, die Backups kennen und wissen, wie man es stoppt.
- Mit den Menschen sprechen, die es nutzen. Erst das Problem finden, dann das Werkzeug wählen.
- Menschen lernen lassen. Berufseinsteiger*innen Übung, Rückmeldung und echte Verantwortung geben.
Wer außerhalb der IT arbeitet, sollte vor dem nächsten beeindruckenden Werkzeug eine Frage stellen: Wer versteht es gut genug, um die Verantwortung zu übernehmen, wenn es ausfällt? Eine überzeugende Antwort sollte eine Person und einen Plan enthalten.
Wo heutige IT-Berufe hineinpassen – Tabelle aufklappen
| Heutiger Beruf | Wohin sich die Arbeit verlagert | Erfahrung, die wertvoll bleibt |
|---|---|---|
| Frontend-, Backend- oder Fullstack-Entwickler*in | Bauen; zunehmend Prüfen von generiertem Code | Anforderungen in Verhalten übersetzen, Komponenten verbinden, Fehler finden |
| Integrations- oder Automatisierungsentwickler*in | Bauen, mit Verantwortung für den Betrieb | Wissen, was passiert, wenn ein Ablauf scheitert |
| Legacy-Entwickler*in, Datenbankadministrator*in, ERP-Spezialist*in | Pflegen; oft auch Betreiben | Abhängigkeiten, Vorgeschichte und Folgen einer Änderung |
| System- oder Cloud-Administrator*in | Betreiben oder Pflegen; Bauen, wo Automatisierung überwiegt | Zugriffsrechte, Infrastruktur, Upgrades, Wiederherstellung |
| QA-Analyst*in oder Testautomatisierer*in | Prüfen; Test- und Evaluationsumgebungen bauen | Testentwurf, Fehlermuster, Risiken einer Veröffentlichung |
| Sicherheitsanalyst*in oder Penetrationstester*in | Prüfen; bei Vorfällen auch Betreiben | Schwachstellen finden, relevante Hinweise von Rauschen trennen |
| Produktmanager*in, Business-Analyst*in, UX-Researcher*in | Gestalten und nun auch Prototypen bauen | Bedürfnisse, Annahmen, gewünschte Ergebnisse bestimmen |
| Lösungsarchitekt*in oder technische*r Berater*in | Gestalten und Bauen | Organisatorische Rahmenbedingungen mit technischen Entscheidungen verbinden |
| Fachkraft für IT- oder Anwendungssupport | Betreiben; Wege ins Prüfen und Gestalten | Reale Probleme untersuchen, wiederkehrende Reibung erkennen |
| DevOps-, Plattform-, SRE- oder MLOps-Engineer | Betreiben, Bauen und Pflegen; nun auch Agenten beaufsichtigen | Automatisierung, Bereitstellung, Zuverlässigkeit, Lebenszyklus |
| Data Engineer oder Datenanalyst*in | Engineering: Bauen und Pflegen. Analyse: Prüfen und Gestalten | Verlässliche Datenflüsse; Befunde und ihre Bedeutung |
Quellen
- JetBrains, AI coding agent adoption 2026, August 2026. ↩
- Brynjolfsson, Chandar und Chen, Canaries in the Coal Mine, August 2026 update, Stanford Digital Economy Lab, 12. August 2026. ↩
- Sonar, State of Code 2026: the verification gap, 8. Januar 2026. ↩
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 10. Juli 2025. ↩
- METR, We are Changing our Developer Productivity Experiment Design, 24. Februar 2026. ↩