Large Language Models (LLMs) haben ihre Coding-Fähigkeiten insbesondere in den vergangenen beiden Jahren dramatisch verbessert – und zwar soweit, dass manche sogar davon ausgehen, dass es in ferner oder auch naher Zukunft keine menschlichen Programmierer:innen mehr braucht. Aber ist das wirklich realistisch? Und welche Probleme ergeben sich beim praktischen Einsatz von KI in der Softwarentwicklung? Diesem Thema ging die neue Folge der brutkasten-Serie „No Hype KI“ nach. Es diskutierten Johannes Berger, Co-Founder und CEO der auf Entwickler:innen spezialisierten Lernplattform Mimo, und Alexander Zeiss, Head of AI bei der ISTV, dem IT-Dienstleister der österreichischen Sozialversicherungen.

Gleich zu Beginn der Diskussion räumt Johannes Berger mit der Angst auf, der Berufsstand könnte verschwinden. „Software wird es immer geben. Software muss erstellt werden von Entwicklern und Entwicklerinnen“, stellt Berger klar. Doch er fügt sofort eine entscheidende Einschränkung hinzu: „Ob der Job der Softwareentwicklerin, des Softwareentwicklers komplett anders ausschaut in Zukunft, das muss man sich ein bisschen differenzierter anschauen und da könnte die Antwort sein: Ja, der schaut anders aus in Zukunft.“

Der Entwickler als Orchestrator

Alexander Zeiss zieht eine Metapher für den Rollenwandel heran, den er vor allem auf Senior-Ebene beobachtet. „Das wird sich insofern verändern, als dass man sagt, vom Musiker hin zum Dirigenten“, erklärt Zeiss. Während früher Schnelligkeit beim Coden und Erfahrung zählten, verschiebt sich der Fokus nun. Es gehe darum, „viel Domain-Wissen“ zu haben, einen guten Überblick zu bewahren und beurteilen zu können, „ob das Ganze für das Unternehmen einen Sinn ergibt, ob es von der Strategie her passt“.

Auch bei Mimo ist dieser Wandel bereits gelebte Realität. Berger beschreibt die Arbeitsweise seines Teams: „KI schreibt den Großteil des Codes, der Entwickler, die Entwicklerin wird mehr als Dirigent bezeichnet, wird bei uns mehr zum Orchestrator, schaut sich das an, reviewt das, gibt Input.“ Dennoch betont er, dass tiefes Verständnis unverzichtbar ist: „Wir würden niemanden bei uns selbst als Entwickler oder Entwicklerin anstellen, der oder die den Code nicht verstehen kann.“

Die Junior-Falle: Züchten wir abhängige Entwickler?

Womit die Diskussion beim Thema Nachwuchs landet. Alexander Zeiss sieht in der KI zwar einen „super Mentor“, der „24-7 verfügbar“ ist, warnt jedoch eindringlich vor den langfristigen Folgen für die Kompetenzentwicklung: „Die Gefahr, die ich persönlich aber dadurch sehe, ist einfach die, dass man vielleicht sich einer Generation von Entwicklern heranzüchtet, die halt eine irrsinnige Abhängigkeit zur KI haben“, sagt Zeiss. Wenn die KI alle Probleme löse, könnten junge Talente „ein bisschen dieses Problemlösungsverständnis verlieren“. Dann stelle sich aber die Frage: „Was ist, wenn einmal die KI nicht da ist?“

Johannes Berger hält dem pragmatisch entgegen: „Was macht ein Entwickler, was macht ein Entwickler, wenn das Internet nicht da ist, wenn der Strom nicht da ist?“. Der Mimo-CEO sieht KI als fundamentale Infrastruktur: „KI ist ein Hilfsmittel, das einfach da sein muss, um vernünftig und produktiv zu arbeiten. Genauso wie das Internet, wie der Computer, wie der Strom.“

Dennoch bestätigt Berger ein strukturelles Problem am Arbeitsmarkt. Da KI-Tools heute oft Aufgaben auf dem Niveau von Einsteigern übernehmen, sinkt die Bereitschaft von Unternehmen, Juniors einzustellen. „Die KI wird heutzutage von unseren Softwareentwickler:innen im Team bei Mimo so verwendet wie ein Junior- oder Mid-Developer“, berichtet Berger.

Das Resultat sei effizient, aber es werfe eine gesellschaftliche Frage auf: „Wenn die Unternehmen weniger bereit sind, in die Bildung zu investieren, wo kommen dann die erfahrenen Entwickler, erfahrenen Entwicklerinnen her in ein paar Jahren?“

Vibe Coding vs. Engineering

Ein zentrales Thema des Talks ist außerdem die Abgrenzung des Trends „Vibe Coding“ von professioneller, KI-getriebener Softwareentwicklung. Berger definiert Vibe Coding als Methode, um Visionen schnell sichtbar zu machen. „Da geht es eigentlich gar nicht darum, dass das wirklich funktioniert, dass das effizient ist, dass das sicher ist. Da geht es einfach nur darum, deine Vision von diesem Pitch, von deiner Idee darzustellen“, erläutert er. Bei Mimo nutzen Mitarbeiter:innen das System, um „direkt einen Prototyp zu erzeugen, der schon dieses Look and Feel von Resultaten hat“.

In der Produktentwicklung gelten jedoch andere Gesetze. Alexander Zeiss warnt vor der Illusion, solche Ergebnisse direkt nutzen zu können: „Das ist ein Prototyp, aber kein produktionsreifes Produkt.“ Die Erwartungshaltung dürfe nicht sein, „dass man beim Prototyp einen Konfigurationsschalter umlegt und dann läuft das Ding in Produktion“.

Zeiss legt großen Wert auf Qualitätssicherung, um „technische Schulden“ zu vermeiden: „Ich muss automatische Überprüfungen haben“, fordert er. KI-Code funktioniere zwar oft auf den ersten Blick, aber: „Du baust dir einfach, wenn du es nicht anpasst, dann nach und nach technische Schulden auf, wo du dementsprechend massiv was tun musst.“

Auch Berger kennt das Problem, wenn Nicht-Entwickler:innen Tools nutzen: „Das ist so weit weg von der Architektur, von der Art und Weise, wie wir unsere Software aufbauen, dass es mehr Arbeit ist, das Ganze dann zu reviewen und zu ändern.“

Sicherheit und der „Human-in-the-Loop“

Im Umfeld der Sozialversicherung, in dem die ITSV tätig ist, spielt Sicherheit eine besonders wichtige Rolle. „Wir haben vier Sicherheitsklassen“, erklärt Zeiss den Umgang mit sensiblen Daten. Man prüfe nicht pauschal Applikationen, sondern spezifische Use Cases: „Wir prüfen einen Use Case. Es kommt einfach unter anderem auf die Daten an, welche verarbeitet werden.“ Die ITSV positioniert sich hier als Vorreiter im SV-Umfeld, der Daten und Modelltraining „on-prem bei uns im Rechenzentrum“ halten kann.

Ein Risiko beim schnellen Vibe Coding ist der sorglose Umgang mit Zugangsdaten – speziell zu Beginn des „Vibe Coding“-Hypes gab es viele Fälle, in denen API-Keys offen im Code auf GitHub veröffentlicht waren. Berger sieht hier jedoch Fortschritte sowohl bei der Ausbildung als auch bei den Tools selbst. Plattformen wie GitHub hätten mittlerweile bereits automatisierte Tests implementiert, die Warnungen ausgeben, wenn es aussieht, als würde jemand unbeabsichtigt sensible Informationen veröffentlichen.

Trotz aller Automatisierung bleibt der Mensch die letzte Instanz. Bei der ITSV gilt das bekannte Prinzip „Human-in-the-Loop“. Zeiss bekräftigt dabei: „Der Entwickler, die Entwicklerin ist im Driver Seat.“

Zukunft der Arbeit: Dokumentation und Testing

Blickt man in die Zukunft, sieht Johannes Berger auch im Bereich Software-Testing Veränderungen. Zwar werde man weiterhin Personen brauchen, die kritische Dinge wie Bezahlvorgänge prüfen, aber: „Es wird immer mehr automatisiert getestet.“ Die Lerninhalte bei Mimo passen sich daher auch bereits an. Man müsse „Syntax nicht mehr so stark lernen in Zukunft“, sondern Konzepte „eher auf einer höheren, abstrakteren Ebene verstehen“.

Alexander Zeiss sieht großes Potenzial in der Sicherung von Wissen, insbesondere bei Altsystemen. „Dass man schlussendlich KI dafür nutzt, um von diesem Code automatisierte Dokumentation erstellen zu lassen, damit das Wissen dann nicht verloren geht“, beschreibt er einen Anwendungsfall für Legacy-Code.

Zum Abschluss geben beide Experten Unternehmen einen klaren Rat: Ausprobieren, aber mit Bedacht. „KI ist im Prinzip dazu da, um Menschen zu unterstützen, um Dinge schneller, teilweise effizienter zu machen. KI ist nicht dazu da, um Menschen komplett abzulösen“, resümiert Alexander Zeiss. Er mahnt jedoch, dass Organisationen sich strukturell vorbereiten müssen: „Es werden sich Rollen verändern, es werden sich Skills der Rollen verändern.“ Johannes Berger plädiert für Experimentierfreude: „Einfach probieren und schauen, was es da so am Markt gibt.“ Wichtig sei dabei nur eines: Dies in einem „geschützten Umfeld“ zu tun, um Erfahrungen zu sammeln, ohne Schaden anzurichten.