~florian/www

Agentic Coding nimmt Azubis nicht die Jobs weg – sondern vielleicht das Lernen

8 Min. Lesezeit

Am Samstag habe ich beim Commander-Spielen mit ein paar Leuten über den aktuellen Arbeitsmarkt in der IT gesprochen. Irgendwann kamen wir auf Azubis, Studierende und Berufseinsteiger. Und natürlich auf KI. Wir hatten alle schon ähnliche Beobachtungen gemacht: Generative KI wird inzwischen sehr intensiv eingesetzt. Gleichzeitig scheint bei einigen Nachwuchsentwickler:innen das grundlegende Verständnis davon abzunehmen, wie Software eigentlich funktioniert.

Wir drei, die dort darüber gesprochen haben, haben jeweils ungefähr 15 bis 20 Jahre Erfahrung in der IT. Und vielleicht ist genau das das Problem. Denn für uns ist Agentic Coding etwas fundamental anderes als für jemanden, der gerade erst lernt, Software zu entwickeln.

Für mich ist Agentic Coding großartig

Ich möchte das ausdrücklich vorwegstellen: Ich halte generative KI beim Programmieren für einen enormen Fortschritt. Es gibt unglaublich viel Programmierarbeit, die ich nach all den Jahren nicht mehr unbedingt selbst erledigen muss.Boilerplate schreiben. APIs anbinden. Daten transformieren. Tests ergänzen. Eine bekannte Lösung in einer leicht anderen Variante implementieren. Wenn ein Agent mir davon einen Teil abnimmt, kann ich mich stärker mit der Architektur und dem eigentlichen Problem beschäftigen.

Das ist fantastisch.

Aber ich kann das nur deshalb, weil ich die andere Seite kenne.

Ich weiß, wie leicht Software auseinanderfallen kann. Ich habe Systeme gebaut, die später Probleme gemacht haben. Ich habe schlechte Architekturentscheidungen getroffen. Ich habe Bugs gesucht, bei denen die sichtbare Ursache kilometerweit von der eigentlichen Ursache entfernt lag. Ich habe erlebt, dass Dinge funktioniert haben, obwohl sie eigentlich nicht hätten funktionieren dürfen. Und natürlich auch das Gegenteil.

Diese Erfahrungen sind heute ein großer Teil dessen, was es mir überhaupt ermöglicht, den Output einer KI zu beurteilen.

Fehler sind Teil der Ausbildung

Wenn wir Programmieren lernen, lernen wir eben nicht nur, Code zu schreiben.

Wir lernen, Systeme zu verstehen.

Man entwirft etwas. Man implementiert es. Es funktioniert nicht. Man sucht. Man bildet Hypothesen. Man stellt fest, dass die erste Hypothese falsch war. Man liest Code. Man benutzt einen Debugger. Man schaut in Logs. Man versteht plötzlich einen Zusammenhang, den man vorher überhaupt nicht gesehen hat. Und irgendwann findet man den Fehler. Das kostet Zeit. Es ist ineffizient.

Und es ist unglaublich wertvoll.

Denn beim nächsten Mal erkennt man dieses Muster vielleicht schon vorher. So entsteht Erfahrung.

Ein Coding Agent kann inzwischen einen großen Teil dieses Kreislaufs übernehmen.

Und genau das macht mir bei der Ausbildung Sorgen.

Wie soll man lernen, einen Agenten zu kontrollieren?

Agentic Coding unterscheidet sich für mich dabei noch einmal deutlich von einem einfachen Code-Vorschlag. Ein Agent kann ein Repository untersuchen, Dateien verändern, Tests schreiben, Tests ausführen, Fehler finden und anschließend seine eigene Implementierung korrigieren. Das ist beeindruckend.

Es bedeutet aber auch, dass ein Entwickler ein ziemlich umfangreiches Ergebnis bekommen kann, ohne selbst jeden Schritt gegangen zu sein. Für einen erfahrenen Entwickler kann das ein Multiplikator sein. Für einen Anfänger könnte es eine Abkürzung sein, die einen wichtigen Teil des Weges überspringt.

Und daraus entsteht ein Problem, das ich momentan für schwer lösbar halte:

Wie soll jemand lernen, AI-generierten Code kompetent zu beurteilen, wenn die AI genau die Tätigkeiten übernimmt, durch die man diese Kompetenz normalerweise erwirbt?

Man muss eine halbwegs brauchbare Vorstellung davon haben, wie ein System aufgebaut ist, um beurteilen zu können, ob eine Änderung sinnvoll ist. Man braucht ein mentales Modell der Architektur. Man muss einschätzen können, an welcher Stelle ein Fehler überhaupt entstehen könnte. Das bekommt man nicht automatisch dadurch, dass man den generierten Code nachträglich liest.

Debugging ist mehr als einen kaputten Button zu finden

Manche Fehler sind einfach. Ich klicke auf einen Button und die UI macht etwas Falsches. Dann kann ich ziemlich direkt anfangen zu suchen. Die interessanten Probleme sehen anders aus.

Das sind keine Probleme, die man allein dadurch lösen kann, dass man generierten Code lesen kann.

Man braucht Erfahrung mit Systemen.

Und ein erheblicher Teil dieser Erfahrung entsteht dadurch, dass man vorher selbst Dinge gebaut und kaputtgemacht hat.

Weniger Code, weniger Bugs

Es gibt ein altes und ziemlich banales Mantra in der Softwareentwicklung:

“Je weniger Code existiert, desto weniger Code kann Bugs enthalten.”

Das gilt auch 2026 noch. Generative KI führt aber nicht unbedingt dazu, dass weniger Software entsteht. Im Gegenteil. Wenn Software billiger und schneller erzeugt werden kann, werden wir vermutlich einfach wesentlich mehr davon bauen. Eine Änderung, die früher zwei Tage gekostet hätte, kostet vielleicht plötzlich zwei Stunden. Also bauen wir mehr Änderungen. Mehr Features. Mehr interne Tools. Mehr Integrationen.

Mehr Software.

Selbst wenn AI-generierter Code im Durchschnitt hervorragend wäre, steigt mit der Menge an Software auch die Menge der Dinge, die verstanden, betrieben, aktualisiert und irgendwann debuggt werden müssen. Das Problem verschwindet also nicht. Wir können es nur wesentlich schneller erzeugen.

Was bedeutet eigentlich „Erfahrung mit KI“?

Gleichzeitig sehe ich inzwischen Stellenausschreibungen und höre Forderungen von Führungskräften, dass Entwickler:innen „Erfahrung mit KI“ haben sollen.

Ich frage mich dabei immer häufiger, was das eigentlich bedeutet.

Claude Code starten zu können? Codex benutzen? Einen guten Prompt schreiben? Einen Agenten eine User Story implementieren lassen? Natürlich werden diese Werkzeuge Bestandteil unseres Berufs. Ein Azubi, der heute seine Ausbildung beginnt, sollte wissen, wie man sie benutzt.

Aber ich würde jemanden nicht deshalb für eine:n guten Softwareentwickler:in halten, weil er besonders schnell Code erzeugen kann. Gerade bei einer Azubi ist doch eigentlich etwas anderes entscheidend. Sie soll lernen, warum ein System so funktioniert, wie es funktioniert. Sie soll seine Fallstricke kennenlernen. Sie soll Fehler machen. Und sie soll lernen, diese Fehler wieder zu finden.

Vielleicht müssen wir Ausbildung absichtlich ineffizient machen

Vor einiger Zeit habe ich einen Artikel eines sehr erfahrenen Entwicklers gelesen, der eine interessante Methode beschrieben hat. Er lässt sich von generativer KI durchaus Code vorschlagen. Aber er kopiert ihn nicht einfach. Er tippt den Code selbst ab. Zeichen für Zeichen. Das klingt zunächst absurd ineffizient.

Aber genau das ist der Punkt.

Denn dadurch muss er sich mit dem Code beschäftigen. Er sieht die Strukturen. Er trifft zumindest teilweise wieder selbst Entscheidungen. Der Code geht anders durch den Kopf, als wenn man einfach einen fertigen Block übernimmt. Wenn selbst sehr erfahrene Entwickler anfangen, sich solche künstlichen Grenzen zu setzen, um ihr Verständnis eines Systems nicht zu verlieren, sollten wir vielleicht darüber nachdenken, was das für Menschen bedeutet, die dieses Verständnis überhaupt erst entwickeln müssen. Vielleicht ist Effizienz in einer Ausbildung nicht immer das wichtigste Ziel. Vielleicht brauchen wir sogar bewusst Ineffizienz.

Nicht weil KI schlecht wäre. Sondern weil der Weg zum Ergebnis manchmal der eigentliche Lerninhalt ist.

Ich glaube nicht, dass KI den Nachwuchs überflüssig macht

Das ist vielleicht der wichtigste Punkt. Meine Sorge ist nicht, dass generative KI Azubis und Junior Developers die Jobs wegnimmt. Das halte ich zumindest momentan nicht für das größte Problem. Meine Sorge ist, dass sie ihnen das Denken abnimmt. Dass sie Ergebnisse bekommen, bevor sie gelernt haben, wie schwierig es ist, zu diesen Ergebnissen zu kommen. Dass sie komplexe Systeme erzeugen können, bevor sie gelernt haben, komplexe Systeme zu verstehen. Und dass wir irgendwann sehr viele Menschen haben, die hervorragend darin sind, Software von Agenten produzieren zu lassen, aber deutlich weniger Menschen, die wissen, was zu tun ist, wenn diese Software nicht mehr funktioniert.

Erfahrung lässt sich nicht prompten

Ein Teil meiner beruflichen Erfahrung besteht aus Dingen, die ich heute wahrscheinlich nicht noch einmal freiwillig machen würde. Stundenlang Bugs suchen. Fehlentscheidungen korrigieren. Systeme neu entwerfen. Mit Kollegen diskutieren, warum etwas eine schlechte Idee war. Anderen beim Lösen eines Problems zuschauen. Und natürlich auch gemeinsam darüber lachen, wie absurd die eigentliche Ursache am Ende war.

Rückblickend waren genau diese Dinge unbezahlbar. Auch der Austausch mit anderen Menschen war immer ein großer Teil davon. Man bekommt nicht nur eine Antwort. Man bekommt Geschichten.

Dieses Erfahrungswissen ist schwer in Dokumentation zu packen. Und bisher habe ich noch nicht das Gefühl, dass ein Gespräch mit einer KI diesen Erfahrungsaustausch vollständig ersetzen kann. Generative KI ist für mich weiterhin ein Segen. Gerade als erfahrener Entwickler möchte ich auf diese Werkzeuge nicht mehr verzichten. Bei Azubis, Studierenden und Menschen in ihren ersten Berufsjahren wäre ich inzwischen aber wesentlich vorsichtiger. Nicht weil sie die Technologie nicht kennenlernen sollen. Sondern weil sie zuerst etwas aufbauen müssen, das ein Agent ihnen später nicht einfach geben kann:

Erfahrung.

Vielleicht sollten wir uns deshalb bei der nächsten Aufgabe nicht nur fragen:

Kann ich das von einer KI erledigen lassen?

Sondern auch:

Was hätte ich gelernt, wenn ich es selbst gemacht hätte?