Glaubt man prominenten Stimmen aus der Techbranche, dann wird zunehmend mehr Code in Unternehmen durch KI generiert. Alphabet-CEO Sundar Pichai spricht von 25 Prozent des neuen Codes, Microsoft-CEO Satya Nadella nennt 20 bis 30 Prozent in Repositories und bestimmten Projekten, Meta-Gründer Mark Zuckerberg erwartet in seinem Unternehmen rund die Hälfte KI-Code im kommenden Jahr. Und Softbank-Chef Masayoshi Son möchte sogar die Ära menschlicher Programmierung beenden. Haben Menschen im Entwicklerjob etwa bald ausgedient? Darüber sprach die iX-Redaktion mit dem Arbeitsmarktforscher Enzo Weber.

iX: Derzeit überschlagen sich Techkonzerne wie Microsoft, Salesforce oder Softbank mit Verlautbarungen, wie viel Code die generative KI im Unternehmen bereits erzeugt. Müssen sich Entwickler wegen Jobverlust durch KI Sorgen machen?

Weber: Wenn man abgleicht, welche Tätigkeiten zu Berufen gehören und welche Möglichkeiten heute KI-Technologie hat, dann zählt Standardprogrammierung tatsächlich zu den Tätigkeiten, die in ziemlich großem Umfang bereits ersetzbar sind. Dazu gibt es zum Beispiel vom IAB eine Studie zum Automatisierungspotential beruflicher Tätigkeiten. Die nennt für das Feld der Informations- und Kommunikationstechnologien – also breiter gefasst als nur Entwickler – einen Wert bei 56 Prozent. Das sollte man aber nicht verabsolutieren. Einerseits werden am Ende aus verschiedensten Gründen nie sämtliche Automatisierungspotenziale auch realisiert. Und andererseits schreitet die Technologie gleichzeitig weiter voran.

Sich Sorgen machen zu müssen, ist trotzdem noch mal etwas anderes. Ersetzt wird ohne Zweifel ziemlich viel von dem, was man in der Vergangenheit in diesen Jobs gemacht hat. Der entscheidende Punkt ist aber, was man in der Zukunft macht.

Also wird sich der Entwicklerjob generell dann einfach stärker verändern, aber die Menschen nicht unbedingt ihren Job verlieren?

Die Veränderung der Jobs ist in der Tat das Entscheidende. Wir sitzen im Moment da, staunen über die Entwicklung der Technologie und sehen, dass sie vieles von dem, was wir bisher gemacht haben, jetzt auch kann. Uns selbst scheinen wir aber irgendwie ziemlich wenig Entwicklungsfähigkeit zuzutrauen. Aber das ist doch eigentlich die große Chance: Die Technologie ist ja nicht die Einzige, die sich weiterentwickeln kann – Menschen können das auch, bei sich und ihrer Arbeit und ihren Kompetenzen.

Mir kann kein Entwickler erzählen, dass er seinen Beruf gewählt hat, weil er total heiß darauf war, massenweise Standardcode runterzuschrubben. KI bietet auch einfach die Möglichkeit, in Zukunft in einem Berufe das zu machen, wofür man ihn eigentlich mal ergriffen hat. Das gilt nicht nur bei Entwicklern, denn KI kann wirklich quer durch alle Berufe Anwendung finden.

Wird dann die Ersetzung oder die Ergänzung menschlicher Arbeit durch KI vorherrschen?

Ich würde in substanziellem Umfang von einer Ersetzung menschlicher Arbeit ausgehen, wie wir sie auch aus der Vergangenheit kennen. Wenn das nicht so wäre, würde es ja betriebswirtschaftlich überhaupt keinen Sinn ergeben, solche Technologien einzusetzen. Aber wir sollten nicht denken, dass menschliche Arbeit im Jahr 2025 sozusagen das Optimum erreicht hat und jetzt kommt eine Technologie, und die stört dieses Optimum. Wir sind auf einem bestimmten Entwicklungsstand und da geht auch noch mehr.

Es gibt zwei Seiten: Etwas von dem, was bisher da war, wird ersetzt. Auf der anderen Seite werden dadurch aber Kapazitäten von schlauen Menschen frei, die sich weiterentwickeln und neue Arbeiten übernehmen können. Menschen, die am Ende auch mit der KI zusammenarbeiten, indem sie das bewerten, kontrollieren, sich überlegen, wie man KI einsetzen kann, aber auch ganz neue Geschäftsmodelle und Tätigkeiten entwickeln. Das ist ja nicht das, was KI macht. Echte Kreativität – das machen immer noch Menschen. Das heißt also nicht, dass in Zukunft weniger Jobs da sein werden.

Bewerten, kontrollieren, kreative Federführung – das klingt vor allem nach erfahrenen Entwicklern. Haben dann die Berufsanfänger, die mit leicht automatisierbaren Routineaufgaben in den Job finden, am meisten unter dem KI-Hype zu leiden?

Dazu gibt es im Moment eine große Diskussion, vor allem in den USA. Es gibt Argumente in beide Richtungen. Also ja, Erfahrungswissen ist etwas, das man erst später hat und das einen sicherlich in höherwertige Tätigkeiten bringt. Auf der anderen Seite haben die jungen Leute natürlich auch einen frischen Blick. Die sind nicht geprägt durch eine Zeit, in der es keine KI gab. Wer da reingewachsen ist, kann auch ganz neu ganz anders starten.

Aber nur weil man schon in Jugendzeiten KI-Apps auf dem Smartphone benutzt hat, hat man deswegen nicht die konzeptionelle Kompetenz. Dafür braucht man mehr, und deswegen brauchen wir auch wirklich Bildungskonzepte und nicht einfach nur die Behauptung „Das sind doch alles digital Natives, die machen das schon“.

US-Techkonzerne setzen derzeit massenweise Personal frei und brüsten sich, wie KI ihre Entwicklerteams ersetzt. Werden da nicht auch Entlassungen als Innovation verbrämt?

Da ist natürlich schon eine signifikante Entwicklung im Tech-Sektor zu sehen. Das gab es ja früher auch schon, erinnern Sie sich mal an die New-Economy-Blase, die Anfang der Zweitausender dann geplatzt ist. Allerdings war die Wirtschaft nach der Energiekrise ohnehin im Abschwung und es kamen weitere äußere Faktoren dazu, die negativ wirkten. Die Dämpfung des Arbeitsmarkts ist also sicherlich nicht im Wesentlichen auf KI zurückzuführen. Außerdem ist es kein beliebtes Argument, Entlassungen damit anzukündigen, dass Technologie die Menschen ersetzt. In den USA geht das vielleicht noch eher als in Deutschland. Aber hier kann man so etwas überhaupt nicht bringen.

Wie sieht es denn auf dem deutschen Arbeitsmarkt aus? Hat der KI-Hype da bislang erkennbare Auswirkungen gezeigt?

In Deutschland haben wir jetzt seit drei Jahren schlicht Wirtschaftsabschwung, und das ist der wichtigste Grund dafür, dass die Beschäftigung abgeflacht ist. Es gibt aber bestimmte Bereiche, wo wir seit dem starken Aufkommen der generativen KI schon klare Effekte gesehen haben. Vor allem ist das auf Plattformen der Fall, wo Aufträge vergeben werden für Jobs wie Übersetzungsleistungen, Textarbeiten, grafische Gestaltung und durchaus auch Programmierarbeiten. Da war auch kurzfristig schon erkennbar, dass die Auftragslage deutlich zurückging.

Herr Weber, vielen Dank für das Gespräch!

(axk)

Das lange Warten auf das erste OpenAI-Modell mit offenen Gewichten hat ein Ende: OpenAI hat am 5. August GPT-OSS veröffentlicht. Bei genauerer Betrachtung zeigt sich: Das Warten hat sich gelohnt. Das Modell funktioniert hervorragend und enthält viele Innovationen. Außerdem steht es unter der sehr liberalen Apache-2.0-Lizenz zur Verfügung.

Architektur der Modelle

Eigentlich hat OpenAI nicht ein Modell, sondern gleich zwei veröffentlicht. Neben dem großen Modell 120B mit 117 Milliarden Parametern gibt es auch noch ein kleines 20B-Modell mit 21 Milliarden Parametern.

Beide Modelle nutzen die Mixture-of-Experts-Architektur und benötigen damit in der Inferenzphase deutlich weniger aktive Parameter, die in die Berechnung eingehen. Besonders ausgeprägt ist das beim großen Modell, das lediglich vier seiner 128 Experten gleichzeitig nutzt. Dadurch gibt es zwischen den beiden Modellen keinen großen Unterschied bei der Zahl der aktiven Parameter. Das kleinere Modell ist daher nicht viel schneller, benötigt aber deutlich weniger Arbeitsspeicher (dazu später mehr).

Interessant ist die Architektur der Layer: OpenAI verwendet abwechselnd eine volle Attention, also den Blick auf den gesamten Inhalt, und eine mit dem sogenannten Sliding Window, bei dem es die Inhalte in kleinere, überlappende Segmente aufteilt. Diese Variante benötigt deutlich weniger Speicher und Rechenzeit, kann aber weniger gut mit langen Kontexten umgehen. Das gleicht die volle Attention in den jeweils dazwischenliegenden Layern aus.

Weniger Speicherbedarf, flexibleres Reasoning

Auf der Model Card bei Hugging Face steht, dass das große Modell auf einer H100-GPU ausführbar ist. Das ist zunächst erstaunlich, denn 121 Milliarden Parameter sind selbst im von DeepSeek verwendeten sparsamen FP8-Format (8-bit Floating Point) zu groß. Allerdings hat OpenAI noch weiter gespart und die Gewichte im noch kompakteren MXFP4-Format (Microscaling 4-bit Floating Point) veröffentlicht, das nur halb so viel Speicher benötigt. Damit erfordert das Modell nur 60 GByte RAM für die Gewichte. Der Nachteil dabei ist, dass nur die in H100- oder RTX 5090-Karten verwendeten Hopper-GPUs von Nvidia mit diesem Format effizient rechnen können.

Auf GPUs der älteren Generation laufen die Modelle zwar, brauchen aber viermal so viel Speicher. Ein Schelm, der dabei an Cross-Sponsoring mit Nvidia denkt. Bemerkenswert ist dennoch, dass sich innerhalb nur eines Jahres das etablierte bfloat16-Format jetzt (zumindest bei diesen Modellen) auf vier Bit verkürzt hat und damit nur noch ein Viertel des Speicherplatzes notwendig ist.

OpenAI erlaubt außerdem, das Reasoning der GPT-OSS-Modelle zu konfigurieren. Man kann also festlegen, wie ausführlich die Modelle ihre Gedanken exponieren sollen. Das ist äußerst nützlich, weil manche Modelle im Reasoning-Mode zu geschwätzig sind und eine Menge Token erzeugen. Man muss also nicht nur lange Ausführungen lesen und auf das Generieren warten, sondern auch für viele Token zahlen. Wie gut diese Einstellung wirklich funktioniert, muss die Praxis zeigen.

Das neue Harmony Response Format

Bei den hybriden Qwen3-Modellen von Alibaba lässt sich durch die Angabe von /no_think im Prompt das Reasoning ausschalten, was wenig flexibel ist. Hier hat sich OpenAI mehr Gedanken gemacht und gleich ein neues Chatformat definiert: Das Harmony Response Format ist sehr viel flexibler als alle bisherigen Chat-Templates und lässt viele Möglichkeiten der Interaktion mit den Modellen zu.

Bei näherer Betrachtung ist es fast erstaunlich, dass man so lange an den – jetzt überkommen erscheinenden – Chat-Templates festgehalten hat. Spannend ist, dass sich beim Ausprobieren des Harmony-Codes der Knowledge Cut-off von GPT-OSS im Juni 2024 findet, die jüngsten Trainingsdaten für das Modell also über ein Jahr alt sind. Dass es für Harmony auch Rust-Code gibt, könnte ein Hinweis darauf sein, dass OpenAI intern mit der Programmiersprache arbeitet, um die Effizienz der Software zu erhöhen.

Harmony ist ein deutlich flexibleres Format als die bisherigen Chat-Templates. Es erlaubt mehr Meta-Instruktionen und sogenannte Channels, die das Modell auch bei der Antwort berücksichtigt. Bei allen Vorteilen hat Harmony aber auch einen Nachteil: Durch das Verarbeiten der zusätzlichen Bereiche wie Regeln und Channels produziert das System viele Token. Die dadurch verringerte Effizienz kann auch ein abgemildertes Reasoning nicht kompensieren.

GPT-OSS ist ein agentisches Modell, das Funktionen aufrufen kann. OpenAI geht dabei noch einen Schritt weiter und erlaubt neuerdings das Browsen im Web. Anbieter wie Anthropic ermöglichen jedoch schon länger, mit ihren Modellen den Browser zu steuern, und Perplexity bietet sogar einen eigenen Browser an. GPT-OSS ermöglicht es außerdem, Python-Code auszuführen. Wie weit man dem generierten Code vertrauen kann, lässt sich auf Anhieb nicht gesichert sagen.

Über Details des Trainingsprozesses schweigt OpenAI sich ebenso aus wie über die dafür verwendeten Daten. Hier kocht jeder vermutlich sein eigenes Süppchen, auch die chinesischen Modellanbieter hüllen sich dazu in Schweigen. Nur für Olmo vom Allen AI Institute und SmolLM von Hugging Face sind wirklich alle Details veröffentlicht.

Event-getriebene Architektur klingt zunächst nach einem radikalen Paradigmenwechsel – und das ist sie auch. Doch gerade weil sie auf einer anderen Denkweise beruht, ist der Einstieg oft einfacher, als viele glauben. Entscheidend ist, dass man nicht mit der Technik beginnt, sondern mit dem gemeinsamen Verständnis.

Dieser letzte Teil der Serie zeigt, wie man ein solches System in der Praxis aufbaut, welche typischen Stolperfallen man dabei vermeiden sollte und wie man Event-getriebene Architektur schrittweise einführen kann.

Reden ist wichtiger als Code

Am Anfang steht kein Code, kein Framework, keine Datenbank – sondern ein Gespräch. Wer Event-getriebene Systeme bauen will, muss zuerst verstehen, was in der Domäne passiert. Und das gelingt am besten im Dialog mit den Menschen, die diese Domäne kennen: den Fachexpertinnen und -experten.

Ein erster Schritt kann sein, gemeinsam Ereignisse zu sammeln: Was passiert in eurem Tagesgeschäft? Welche Abläufe gibt es? Welche Entscheidungen werden getroffen? Was ist wichtig, was ist selten, was ist kritisch?

Dabei hilft es, ganz bewusst in der Sprache der Fachlichkeit zu bleiben – ohne technische Begriffe, ohne JSON-Formate, ohne Implementierungsdetails.

Event Storming und ähnliche Methoden

Bewährt haben sich dabei Formate wie Event Storming: Man klebt Events als Post-Its an eine Wand, ordnet sie zeitlich und diskutiert darüber. So entstehen Schritt für Schritt die zentralen Abläufe der Domäne – verständlich, diskutierbar und überprüfbar.

In dieser Phase ist es wichtig, die Sprache ernst zu nehmen: Ein Event wie „Bestellung wurde storniert“ muss nicht nur technisch korrekt sein, sondern es muss auch inhaltlich passen. Und vor allem: Es muss für alle Beteiligten dasselbe bedeuten.

Nicht das ganze System umstellen

Ein häufiger Fehler ist, Event-getriebene Architektur gleich auf das gesamte System anwenden zu wollen. Das führt oft zu Überforderung – fachlich, organisatorisch und technisch.

Besser ist es, sich ein isoliertes Teilproblem zu suchen – einen Prozess, der in sich geschlossen ist, aber bereits von klassischen Architekturen überfordert wirkt.

Typisch sind:

• Benachrichtigungsprozesse
• Abrechnungs- oder Mahnwesen
• Genehmigungsworkflows
• Integration mit Drittsystemen

Hier lässt sich Event-getriebene Architektur gut einführen, zunächst als ergänzender Ansatz, nicht als Ersatz für das bestehende System.

Nicht die Technik überfrachten

Viele Einsteiger verlieren sich schnell in technischen Entscheidungen: Welches Event-Format soll man wählen? Welche Queue verwenden? Wie Event-Versionierung lösen?

Diese Fragen sind wichtig, aber nicht am Anfang. Wer Events als fachliche Beschreibung ernst nimmt, kann diese zunächst einfach als strukturierte Objekte behandeln – selbst ohne Event-Store oder Queue. Die technische Infrastruktur lässt sich nach und nach ergänzen.

Erst wenn klar ist, welche Events entstehen, wann sie entstehen und was sie bedeuten, lohnt es sich, über Serialisierung, Partitionierung und Replikation nachzudenken.

Was sich langfristig verändert

Wer einmal damit beginnt, in Events zu denken, verändert die eigene Sicht auf Systeme dauerhaft. Man beginnt, Abläufe nicht mehr als Abfolge von Methodenaufrufen zu sehen, sondern als Geschichte von Ereignissen. Und das hat viele positive Effekte:

• Die Kommunikation mit dem Fachbereich wird klarer.
• Die Modelle werden stabiler.
• Die Systeme werden flexibler und nachvollziehbarer.
• Neue Anforderungen lassen sich oft mit vorhandenen Events umsetzen.

Fazit und Ausblick

Event-getriebene Architektur ist kein Selbstzweck – und keine technische Mode. Sie ist eine Antwort auf Systeme, die zu unübersichtlich, zu gekoppelt und zu schwer veränderbar geworden sind. Wer Systeme baut, die sich natürlich weiterentwickeln lassen sollen, findet in Events ein kraftvolles Werkzeug.

Diese Serie hat den Bogen gespannt – von den Grenzen klassischer Architektur über die Bausteine, Denkweisen und Fallstricke bis hin zum konkreten Einstieg. Wer den nächsten Schritt gehen möchte, findet auf cqrs.com weitere Ressourcen, konkrete Beispiele und vertiefende Konzepte.

(mai)