Disruption in der IT-Ausbildung

Gero Scholz, Ralf S. Engelschall

Ab dem zweiten Quartal 2025 ist es möglich geworden, durch "Prompt-Engineering" kleinere IT-Systeme (<10.000 LoC) mit relativ guter Qualität zu erzeugen — insbesondere, wenn man einer KI Ziele Top-Down vorgibt, den "Planning Mode" des Agenten nutzt und klare Leitplanken in Form von Regeln hinterlegt.

Wir blicken auf 40 Jahre "Computer Aided Software Engineering (CASE)" zurück, haben zahlreiche Hype-Cycles erlebt und natürlich auch graduelle Verbesserungen. Diesmal ist es anders.

Mit den neuen Large-Language-Models (LLMs) der Generativen KI und ihrer Adaption an die speziellen Bedürfnisse von Software-Entwicklern verlassen wir die Idee, formale Spezifikations-Notationen zu definieren, die mit geeigneten Tools eindeutig in ausführbare Artefakte transformiert werden können. Das Verständnis der LLM-Agents von natürlicher Sprache einerseits und formaler Notation andererseits ist an einem Punkt angekommen, wo funktionierende Code-Berge sogar durch Plauderei ("Vibe-Coding") erzeugt werden können. Das mag beim Basteln kleiner Skripte helfen. Sobald die Ergebnisse jedoch einen gewissen Umfang annehmen, landen der Agent und sein menschlicher Gesprächspartner in einem Sumpf aus Redundanz und struktureller Unklarheit.

Warum ist es dann diesmal anders?

Weil AI Helfer bei guter Anleitung auch anders agieren können! Es liegt an uns, sie so einzusetzen, dass sie tragfähige Strukturen erzeugen oder sich zumindest empathisch an ihnen orientieren. Wir müssen ihnen solche Strukturen zeigen und darauf dringen, dass sie sich daran halten. Das ist heute in einem Maß möglich, das überrascht und die Grenze dessen, was professionell erreichbar ist, von 10.000 LoC möglicherweise in naher Zukunft auf 100.000 LoC verschieben wird. Und das ist dann doch schon eine praktisch relevante Größenordnung. Selbst wenn man einkalkuliert, dass AI-generierter Code in der Regel weniger kompakt ist als das, was ein kluger Mensch geschrieben hätte.

Denn es ist zu beachten, dass selbst bei großen Systemen mit vielen Millionen LoC, aufgrund ihrer inhärent für das Meistern der Komplexität notwendigen Modularisierung, jeder einzelne Arbeitsschritt sich auch nur auf wenige Module mit selten mehr als 10.000 LoC fokussiert. Genauso wie Menschen nicht mit so einem großen System als Ganzes auf einmal agieren können, muss es auch die KI gar nicht können.

Wer schon einmal mit einem Agenten eine Diskussion geführt hat, die mit den Worten begann: "Wir reden jetzt darüber, welche Varianten es gibt, die zuvor genannten neuen Anforderungen umzusetzen. Finger weg vom Code! Wir suchen jetzt einen guten Kompromiss aus konzeptioneller Sauberkeit, Umsetzungsaufwand, Testbarkeit und Konformität mit der bisherigen Architektur!" — der weiß, dass Zusammenarbeit zwischen einem erfahrenen menschlichen Software-Designer und einem AI-System auf Augenhöhe keine Fiktion mehr ist. Wer sich darauf einlässt, wird merken, wie er dem Agenten ein gewisses Persönlichkeitsbild zuzuschreiben beginnt und wie er danach trachten wird, die Wertmaßstäbe "seines Agenten" durch ausführliche Regeln (also quasi "System-Prompts") so zu formen, dass er sich auf ihn verlassen kann. Weit entfernt von naiver Anthropomorphisierung wird er doch eine gewisse Freude an seinem "Schützling" entwickeln, wenn er ihn positiv überrascht. Und eine gewisse Enttäuschung, wenn der Agent einen beschönigenden Quick-Fix für ein Problem befürwortet, welchen er nicht gut heißt.

Wer mit Agentic Coding eigene Erfahrungen gesammelt hat, weiß allerdings auch, wie es sich anfühlt, wenn der Agent Code-Änderungen auf "Verdacht" durchgeführt hat, weil er nicht alles gelesen hat, was schon existiert und für diese Änderung relevant gewesen wäre. Wir behaupten, dass das Problem des begrenzten Session-Kontextes in der Zusammenarbeit mit einem Agenten sich nicht qualitativ von demjenigen unterscheidet, das der Softwareentwicklung im Team grundsätzlich zu eigen ist. Um ein Team produktiv zu machen, müssen bestimmte Rahmenbedingungen hergestellt werden, die auf AI-Agenten genauso anwendbar sind wie auf menschliche Team-Mitglieder:

  • Alle müssen eine gemeinsame Vision vom Ziel haben,
  • Wertvorstellungen teilen,
  • sich an generelle und projektspezifische Standards halten,
  • die technische und die fachliche Systemarchitektur verstehen
  • und spezifisches Detailwissen besitzen, welches sich notwendigerweise immer nur auf Ausschnitte des Gesamtsystems beziehen kann.

IT-Fachleute werden in naher Zukunft einen oder sogar mehrere Agenten führen. Sie werden die AI als einen Kollegen verstehen, der kompetent und fleißig ist, der durchaus ab und zu bessere Ideen zur Lösung eines Problems hat als sie selbst. In einem Jahr werden führende Softwarehäuser mit dieser Art von Arbeitsteilung ganz selbstverständlich umgehen, egal ob bei der Neuentwicklung oder bei der Wartung von Systemen. Weitere zwei Jahre später wird die Mehrheit aller Software-Entwickler das Ende des Gartner Hype Cycles erreicht haben, also das Plateau höherer Produktivität.

Wir müssen diesen Prozess jetzt selbst ausprobieren, von innen heraus verstehen und die richtigen Steuerungsinstrumente dafür entwickeln, damit das unvermeidliche "Tal der Tränen" nur eine flache Mulde wird.

Human periodically in the loop

Die Führung einer KI erscheint recht ähnlich zur Führung von Mitarbeitern: man sollte grundsätzlich "Microcontrolling" vermeiden und große Spielräume geben, man muss aber regelmäßig zumindest den Status Quo abfragen, Probleme frühzeitig erkennen und Ergebnisse einer Qualitätssicherung unterwerfen.

Wir plädieren deshalb für ein Modell, das wir als "human periodically in the loop" bezeichnen:

  • Der Mensch muss ausreichende Kompetenz besitzen, um absolut sicher auf Detailebene nachzuvollziehen, was der Agent vorschlägt oder produziert hat
  • Er muss ausreichend Zeit und Selbstdisziplin besitzen, dies immer wieder an kritischen Punkten zu tun
  • Er braucht gute Instinkte, um solche kritischen Punkte zu erkennen
  • Er muss wissen, wann er gut daran tut, den Agenten als Partner und Berater einzusetzen oder ihm ganz freie Hand lassen kann
  • Er darf sich freuen, dass ihm der Agent lästige Routine abnimmt und er muss wissen, dass er einen Preis dafür bezahlt in Form von wachsender innerer Distanz zu technischen Artefakten

Der Knackpunkt ist bei einer KI ähnlich wie im Verhältnis zu einem menschlichen Mitarbeiter: Wenn wir "die Leine zu früh einholen", nimmt uns der KI-Agent zu wenig Arbeit ab. Wenn wir "die Leine zu spät einholen", ist der Agent eventuell schon zu lange "falsch abgebogen". Die richtige Balance zwischen maximaler Produktivität und vernünftiger Ergebnisqualität zu treffen, ist hier entscheidend. Und diese Balance muss teilweise pro Arbeitsschritt neu gefunden werden: ein Refactoring erlaubt durchaus "eine lange Leine", während eine statische Code-Analyse (Linting) mit direkter Code-Anpassung (Fixing) tendenziell eher eine "kurze Leine" verlangt.

Es wird Reviews geben müssen, in denen der Mensch beweisen muss, dass er noch alles im Griff hat. Nicht von ungefähr müssen Berufspiloten immer wieder eine Landung manuell fliegen, obwohl der Autopilot bei schwierigen Windverhältnissen vielleicht sogar eine perfektere Landung hinlegen würde als sie selbst. Berufspiloten haben manchmal ganz schön Angst vor den Checks im Simulator. Wer mit einem Softwaresystem Sicherheitsansprüche auf dem Niveau der Luftfahrt verbindet, wird entsprechende Mechanismen schaffen müssen, in denen Mensch und Maschine getrennt voneinander beweisen müssen, dass sie noch verstehen, was sie zusammen geschaffen haben.

Vielleicht werden zukünftige Setups für Software Engineering so konfiguriert sein, dass der Entwickler zwar 95% seiner Aufgaben an Agenten delegieren darf, aber in der restlichen Zeit vom Setup bewusst gezwungen wird, die Aufgabe selbst durchzuführen. Der Agent verweigert also bewusst bei 5% der Aufgaben die Delegation, damit der Entwickler nicht verlernt, wie Software-Entwicklung funktioniert.

Vielleicht ist der Eindruck entstanden, dass wir nur über die Erstellung ausführbarer Artefakte sprechen. Das wäre ein großer Irrtum. Es gilt für Requirements, UML-Diagramme, Testfälle, Dokumente zum Deployment und Projektpläne gleichermaßen.

Das Berufsbild der Menschen, die mit einer Mischung aus software-technischem Können und fachlichem Anwendungswissen zusammen mit AI-Agenten IT-Systeme schaffen und weiterentwickeln, wird sich wandeln.

Aktuelle Herausforderungen verstehen

Aktuell sehen wir folgende Herausforderungen bei der KI-Unterstützung von Software-Engineering, die wir in der Lehre erläutern sollten:

  • Fuzzyness im Input:
    Aktuelle Generative KI basiert auf Large-Language-Models (LLMs), welche ihrerseits neuronale Netze auf Transformer-Basis sind. Sie sind perfekt geeignet, wenn bei der Input-Verarbeitung eine inhärente Fuzzyness benötigt wird, wie es z.B. bei der Verarbeitung natürlicher Sprache der Fall ist. In der Informatik arbeiten wir aber primär mit formalen Sprachen, die gar keine solche Fuzzyness in der Verarbeitung benötigen. Zu viele Leute versuchen in der Zwischenzeit die Agentic Coding Tools für alles zu verwenden.

  • Wahrscheinlichkeit im Output:
    Die LLMs besitzen eine inhärente Wahrscheinlichkeit in ihren Outputs (das nächste Token ist nur mit einer gewissen Wahrscheinlichkeit das "richtige"). Diese Wahrscheinlichkeiten muss man fachlich akzeptieren können. Manchmal ist dies aber eher unerwünscht. Wir sollten lernen, jeweils "best tool for the job" zu nutzen. Manchmal ist ein deterministischer Algorithmus der bessere.

  • Fehlender Determinismus:
    Die LLMs nutzen in den Inputs teilweise zufällige "seeds" (Initialwerte). Dies führt dazu, dass ein LLM selbst bei exakt dem selben Prompt jedes Mal ein etwas anderes Ergebnis liefert. Dies führt zu Nicht-Determinismus, den wir als Informatiker eigentlich vermeiden wollen. Ein schönes Beispiel ist das Linting von Code: statische AST-basierte Code-Analyse-Werkzeuge sind voll deterministisch. Ein einmaliger Aufruf reicht vollkommen aus. Ein Linting mit einem LLM ist durchaus sinnvoll, aber man muss es mehrfach wiederholen, da das LLM bei einem Durchgang zwar viele, aber nicht alle Probleme erkennt. Beim Beispiel des Linting ist die Erfahrung, dass man sogar beide Sorten von Werkzeugen gleichzeitig benötigt: die AST-basierten Werkzeuge für Präzision und den Fokus auf syntaktische Aspekte, die LLM-basierten Werkzeuge für Fuzzyness und den Fokus auf semantische Aspekte.

  • Neue Abstraktionsebene:
    Die Informatik ist eine Wissenschaft der Abstraktion und Modellierung. Deswegen sind wir in der Informatik seit jeher bestrebt, auf abstraktere, höhere Ausdrucksebenen zu gelangen. Früher programmierte man in Maschinencode, dann in Assembler, danach in C/C++, danach in Java/JavaScript/TypeScript/etc. Jede abstraktere Ebene hatte eine präzise, formale Sprache als Input und diese konnte bisher weiterhin voll deterministisch auf die jeweils existierenden unterliegenden Ebenen abgebildet werden. Wenn man nun auf LLMs setzt, erhält man ebenfalls eine neue Ebene, bei der aber mit natürlicher Sprache in Prompts gearbeitet wird und deren Abbildung auf die unterliegenden Ebenen nicht mehr deterministisch passiert. Das ist eine neue Qualität der Abstraktion, die mit zahlreichen Herausforderungen einher geht. Ihr Umgang muss von uns erst noch viel besser erlernt werden.

  • AI Slob:
    Aktuell wird das gesamte Internet mit AI-generierten Inhalten geradezu überflutet. Dank Agentic Coding Tools in der Zwischenzeit auch mit AI-generiertem Code. Man kann die "Spreu vom Weizen" kaum mehr trennen. Man kann manche Autoren nicht mal mehr nach ihrem Code fragen, denn sie kennen ihn gar nicht mehr. Diese Schwemme kann eventuell durch Kuration guter Inhalte eingedämmt werden.

  • Durchschnittlicher Code:
    LLMs sind so leistungsfähig geworden, weil man sie buchstäblich mit dem gesamten Internet füttert. Agentic Coding Tools sind so gut, weil sie mit fast dem gesamten Open Source Code-Bestand von Github & Co gefüttert worden sind. Leider gibt es dort aber massenhaft schlechten oder zumindest nur mittelmäßigen Code. Der von einem LLM generierte Code ist deshalb ebenfalls des Öfteren nur mittelmäßig. Wir sollten lernen, die LLMs nur noch mit gutem, kuratierten Code anzulernen.

  • Kontinuierliche Verdummung der LLMs:
    Wenn aufgrund des AI Slobs zentrale Portale wie Github mehr und mehr überschwemmt werden, werden zukünftige LLMs prinzipbedingt schlechter und schlechter. Wir halten es für möglich, durch Zusammenarbeit von Mensch und Maschine Systeme zu erzeugen, deren Qualität ÜBER dem durchschnittlichen Github-Niveau liegt. Wir brauchen künftig Indikatoren, die den menschlichen Anteil der "Schöpfungshöhe" eines Systems erkennen und bewerten. AI-erzeugte Systeme durch Markierungen auszuschließen, kann eine Notmaßnahme für die Übergangszeit sein, aber langfristig muss es Wege geben, Spreu und Weizen in den Trainingsdaten anders zu erkennen, um der langfristigen Verdummung entgegenzuwirken.

  • Esoterische Programmiermodelle:
    Wenn man "mainstream" programmiert (z.B. Java, JavaScript, TypeScript als Sprachen und Vue/React/Angular als Frameworks) sind LLMs exzellent. Wechselt man zu einem eher esoterischen Programmiermodell (z.B. Lua oder Elixir als Sprachen) geht die Qualität sehr deutlich zurück. Denn es gab einfach zu wenig Code während der Trainings-Phase des LLMs. Das kann dazu führen, dass nicht mehr "best tool for the job" verwendet wird, sondern nur noch "Einheitsprogrammierung" mit "mainstream tools" stattfindet. Die LLMs sollten mehr mit kuratiertem Wissen angelernt werden oder es ist zumindest ein Finetuning für esoterische Programmiermodelle notwendig.

  • Programmieren verlernen:
    Wer längere Zeit ein Agentic Coding Tool verwendet hat, bemerkt, dass man abhängig wird und anfängt, sogar Aufgaben an das Tool zu delegieren, die eigentlich auch ganz leicht selbst erledigt werden könnten. Man verlernt gefühlt nach und nach das Programmieren, wenn man nicht aufpasst und hohe Disziplin an den Tag legt. Zumindest wird die psychologische Hemmschwelle immer größer, selbst zu programmieren und dabei das eigene Gehirn anzustrengen. Regelmäßig vom "autonomous agent" in den "supervised agent" Modus zu schalten kann hier sinnvoll sein.

  • Geringer Kontext:
    Der Kontext von LLMs ist heute im Bereich von etwa 100-200k Tokens (z.B. bei Claude Sonnet 4.5). Ein Token entspricht in etwa 3-4 Zeichen. Beim Programmieren entstehen durchschnittlich 40 Zeichen pro Zeile Code, so dass in den Kontext eines aktuellen LLMs maximal 17.5K LoC passen. Da außerdem bereits die System-Prompts der Agentic Coding Tools und der eingebundenen MCP-Server davon meist 10% vom Kontext belegen und die Güte der LLMs bereits ab 40-50% Kontext-Befüllung bemerkbar schlechter wird, bleiben in der Praxis maximal 30% des Kontexts, was effektiv nur noch 5.2K LoC entspricht. Dies ist sehr wenig Code. Wir müssen also lernen, den Kontext viel gezielter als bisher zu befüllen, sonst degradieren die Ergebnisse dramatisch. In der Praxis wäre hier ein "Kontext-Gathering-MCP-Server" das Mittel der Wahl.

  • Kooperation von Agenten:
    Der Einsatz eines einzelnen Agentic Coding Tools wie Claude Code oder Github Copilot funktioniert bereits sehr gut. Will man aber mehrere solche Tools kombinieren, benötigt man eine gemeinsame Datenbasis, welche alle Tools gleich gut verstehen. Aktuell behilft man sich hier mit Markdown-Dateien als gemeinsamem Nenner. Diese sind aber nur semi-strukturiert. Für eine bessere Kooperation der Tools würde man vollstrukturierte Daten bevorzugen. Hier fehlt aktuell noch ein gemeinsames Datenmodell im Software-Engineering.

  • Skalierung der Agenten auf Teams:
    Der Einsatz eines Agentic Coding Tools unterstützt bereits sehr gut einzelne Software-Entwickler. Aber Software-Engineering ist inhärent eine Team-Anstrengung. Hier müssen wir erst Software-Engineering von der Methodik her verändern, um hybride Teams zu ermöglichen: Software-Engineers und Software-Engineering-Agents, welche eng kooperieren, um ein gemeinsames Ziel zu verfolgen.

  • Veränderungen in der Programmierer-Zunft:
    Dank KI sehen wir aktuell eine Schwemme von "vibe-coded programs", welche von "Halbstarken" der Programmierer-Zunft "entwickelt" wurden. Außerdem wird in der Zwischenzeit Programmierern mit höherem handwerklichen Können heute bereits implizit unterstellt, dass auch sie wohl nur KI für ihr Handwerk einsetzen würden — ihr Können wird also bereits durch die reine Verfügbarkeit von KI und nicht erst durch den tatsächlichen Einsatz stark entwertet. Das führt dazu, dass so mancher stolze Programmierer sich in seiner Ehre wesentlich gekränkt fühlt. Die Geschichte geht allerdings über solche persönlichen Befindlichkeiten hinweg. Wer wissen will, wie man einen mechanischen Webstuhl geschickt bedient, muss ins Museum gehen. Das Wissen der Besten ihrer Zunft wird in neue Werkzeuge integriert. Innovation und Kreativität bleiben für talentierte Menschen als Betätigungsfeld übrig, einige werden als Bediener der neuen Systeme gebraucht, etliche als deren Hersteller. Die anderen wechseln in neue Arbeitsfelder.

  • Thinking-Universe:
    Wie Alan Perlis bereits vor langer Zeit sagte: "A good programming language is a conceptual universe for thinking about programming". Man kann sogar das "about programming" weglassen, denn gute Programmiersprachen zeichnen sich dadurch aus, dass sie einem erlauben, die fachliche Lösung sinnvoll vor dem geistigen Auge zu strukturieren und in ihrem Ablauf zu durchdenken. Und zwar bereits BEVOR die erste Zeile Code in ihr geschrieben wird. Überlässt man nun einer KI die Erstellung des Codes, verliert man diesen Aspekt allerdings, da es keine Motivation gibt, in einer Programmiersprache zu denken, wenn man nicht auch vorhat, sie anschließend in der Realisierung zu nutzen. Wir brauchen also stattdessen neue Konstrukte, um über die Lösungen strukturiert vorab "nachzudenken".

  • KI-Blase:
    Die aktuellen AI-Services, wie z.B. OpenAI GPT und Anthropic Claude, werden aktuell für maximal 200 Euro pro Monat angeboten. Während sich diese Kosten in der Industrie bereits durch eine Einsparung von gerade einmal 2 Entwickler-Stunden pro Monat sehr schnell amortisieren, sind diese Kosten bereits zu teuer für viele Hobby-Programmierer der für die Industrie so wichtigen Open Source Community.
    Zusätzlich existiert das Problem, dass die Anbieter wie OpenAI und Anthropic nicht einmal annähernd gewinnbringend agieren können, da deren AIs einen dermaßen großen Hardware- und Energiebedarf haben, dass sie immer noch Milliardendefizite pro Jahr einfahren. Auch deren Investoren werden nicht beliebig langen Atem zeigen.
    Es wird sich deshalb zeigen müssen, ob weitere Entwicklungen im Bereich von AI es erlauben, die LLMs mittelfristig wirklich deutlich effizienter werden zu lassen und somit die AI-Anbieter in eine wirtschaftliche Gewinnzone zu bringen. Ansonsten wird leider, trotz der aktuell technisch beeindruckenden Fortschritte, die aktuelle KI-Blase unweigerlich platzen.

  • Überschattender Hype und unklares Gesamtbild:
    Der aktuell anhaltende AI-Hype überschattet so viel, dass sich ein sehr unklares Gesamtbild am Markt zeigt. Die einen loben die aktuellen LLM-basierten AI für ihre hohen Produktivitätssteigerungen in den Himmel, sehen uns kurz vor dem Erreichen von Artificial General Intelligence (AGI) und sprechen bereits vom Ende der traditionellen Software-Entwicklung. Die anderen sprechen von effektiven Produktivitätsverlusten, sehen AGI weiterhin genau so weit weg, wie sie es seit 50 Jahren in der Informatik ist, und sehen für die Zukunft sogar mehr statt weniger notwendige Software-Entwickler.
    Dahinter stecken die folgenden Fakten: (1) ob man eine Produktivitätssteigerung oder einen Produktivitätsverlust erzielt, hängt primär von der Art des konkreten Arbeitsschrittes, der eigenen Disziplin beim Erkennen des "Kipp-Punktes" und unserer Lernbereitschaft für neue Arbeitsweisen ab; (2) man darf nicht von großen Erfolgen bei bestimmten Spezialanwendungen (z.B. Speech-to-Text, Code-Generierung) auf allgemeine Fortschritte (Intelligenz mit echtem Verstehen) schließen; und (3) bereits bei COBOL, Fortran, 4GL-Sprachen, WYSIWYG, CASE, UML, MDD, Low-Code, No-Code, etc wurde jedes Mal, wie aktuell bei LLM, davon gesprochen, dass man keine Software-Entwickler mehr benötigen würde, während die Geschichte der IT klar zeigte, dass man am Ende effektiv sogar noch mehr benötigte. Vergleiche hier das "Jevons-Paradoxon" bzw. den "Rebound-Effekt".

← Übersicht: Disruption in der IT-Ausbildung | Weiter: Aus- und Weiterbildung in der IT →