Kurz vor Weihnachten gab es für die LLM-Community eine unerwartete Überraschung: Nvidia veröffentlichte ein neues Modell mit dem Namen Nvidia-Nemotron-3-Nano-30B-A3B. Schon etwas früher war die Reddit-Community informiert, weil ein aufmerksamer Leser entdeckt hatte, dass ein weniger aufmerksamer Mitarbeiter von Nvidia versehentlich ein übergeordnetes Verzeichnis zu Hugging Face gepusht hatte. In dem am 15. Dezember 2025 veröffentlichten Nvidia-Modell stecken jede Menge neue Ideen, sodass sich ein genauerer Blick lohnt – auch weil es sich nur um das erste Modell aus einer ganzen Familie handelt.

Überblick über die Architektur

Bisher waren die Nemotron-Modelle häufig Finetunes anderer Modelle wie Llama 3.1. Das hätte man aufgrund der ähnlichen Parameteranzahl eines Qwen3-Modells auch bei Nemotron 3 vermuten können. Bei Nemotron 3 hat Nvidia die Modelle von Grund auf neu trainiert und sich dafür eine neue Architektur ausgedacht. Die bisherigen Mixture-of-Experts-Layer (MoE) verwendet Nvidia dabei abwechselnd mit Mamba-Layern, die im strengen Sinne keine Transformer-Architektur nutzen. Der Vorteil ist eine deutlich höhere Ausführungsgeschwindigkeit und ein geringerer Speicherverbrauch, weil der Key-Value-Cache, der sich den Kontext merkt, in den Mamba-Layern nicht mit der Kontextlänge wächst. Vermutlich genau aus diesem Grund konnte Nvidia die Kontextlänge auf eine Million Token erhöhen. Das Modell eignet sich somit für sehr lange Dokumente.

Obwohl das Modell „Nano“ im Namen trägt, ist es nicht wirklich klein, sondern hat 31,6 Milliarden Parameter, von denen es bei jeder Token-Vorhersage 3,6 Milliarden verwendet. Das macht das Modell schnell, dazu tragen außerdem die leichter zu berechnenden Mamba-Layer bei. Nvidia spricht von einem Faktor 3,3 gegenüber vergleichbaren Modellen. Solche Zahlen lassen sich nicht einfach verifizieren, was ebenfalls für die von Nvidia genannte beste Genauigkeit für Reasoning, Coding, Benutzung von Tools und mehrstufigen Agenten-Aufgaben gilt. Hier muss sich das Modell erst noch in der Praxis beweisen.

Direkt überprüfbar sind dagegen die Möglichkeiten, das Reasoning ein- und auszuschalten oder darüber die Anzahl der generierten Token zu begrenzen. Das ist besonders für agentische Aufgaben wichtig, weil sonst dort unkontrollierbar hohe Kosten entstehen können.

Nemotron Nano besteht aus 52 Layern mit einer Modelldimension von 2.688 und setzt auf 32 Attention-Heads. Die Mamba-Layern haben 128 Zustandsdimensionen in acht Gruppen, mit jeweils 64 Mamba-Heads in 64 Head-Dimensionen. Insgesamt gibt es 128 Experten, von denen zwei als Shared Experts arbeiten; weiterhin aktiviert das Modell sechs zusätzliche Experten. Da die Experten nur 1.856 Dimensionen haben, erklärt sich so die Anzahl der aktiven Parameter von 3,6 Milliarden. Abgesehen von den Mamba-Layern nutzen andere Modelle ähnliche MoE-Architekturen.

Trainingsdaten fast vollständig veröffentlicht

Was das Nemotron-Modell allerdings wirklich gegenüber fast allen anderen Modellen auszeichnet, sind die Trainingsdaten. Nahezu alle hat Nvidia veröffentlicht, genau wie auch die im Training verwendeten Algorithmen. Das haben bisher neben den Olmo- und Apertus-Modellen nur wenige Anbieter geleistet. Die Daten finden sich als Pre- und Post-Trainings-Datensatz auf Hugging Face.

Manche der Daten scheinen aus der Zukunft zu stammen und tragen ein Änderungsdatum von 20. Dezember 2025, ein offensichtlicher Fehler. Unabhängig davon reichen die Daten bis zum Juni 2025. Fragen nach dem Wissensstand beantwortet das Modell allerdings mit Juni 2024 – auch eine Inkonsistenz. Insgesamt stehen 10 Billionen Tokens zum Download in den Datensets zur Verfügung. Das lässt sich kaum mit bezahlbarer Hardware trainieren (oder feintunen), dennoch ist es sehr spannend, einen Blick in die Datensets zu werfen oder zumindest Teile davon zu verwenden. In jedem Fall werden die Modelle dadurch deutlich transparenter. Das Nano-Modell steht unter der Nvidia-Open-Model-Lizenz, damit ist auch die kommerzielle Nutzung und Veränderung gestattet.

Deutlich mehr Informationen finden sich in Nvidias Blog-Artikel bei Hugging Face, im Nvidia-Blog, einem zugehörigen Whitepaper oder im technischen Bericht. Ein GitHub-Projekt enthält Cookbooks, die zeigen, wie man das Modell mit Frameworks wie SGLang oder vLLM verwendet.

Pre-Training

Unter dem Pre- oder Base-Training versteht man den Teil, in dem das Modell mit sehr großen Datenmengen trainiert wird, um den jeweils nächsten Token vorherzusagen. Üblicherweise verbraucht das Pre-Training bei weitem am meisten Rechenkapazität, auch wenn sich das bei einigen Anbietern (wie Qwen) gerade ändert.

Für das Pre-Traning nutzt Nvidia den Warmup-Stable-Decay als Scheduler und trainiert das Modell mit 25 Billionen Token in 15 unterschiedlichen Kategorien. Dieses Pre-Training haben die Entwickler noch in zwei Phasen unterteilt, die erste Phase nutzt 23,5 Billionen Token aus relativ einfachen Texten, in einer zweiten Phase folgen 1,5 Billionen Token mit deutlich höherer Qualität.

Die größte der 15 Komponenten sind Daten aus dem Web Crawling (Common Crawl), die in fünf Teilbereiche mit verschiedenen Qualitätsstufen zerfallen (crawl-medium, crawl-medium-high, syn-crawl-medium-high, crawl-high, syn-crawl-high). Neben den Crawling-Daten enthält der Mix auch mathematische Daten, weitere aus Wikipedia, speziellen Programmcode und verschiedene andere.

Im Pre-Training verwendet Nvidia auch synthetische Daten, die normalerweise für das Supervised Finetuning Verwendung finden. Unter Crawl++ versteht Nvidia Daten, die aus OpenWebText, BigScience und Reddit kommen. Das Pre-Training erfolgt in 19 Sprachen: Arabisch, Chinesisch (vermutlich Mandarin), Tschechisch, Dänisch, Flämisch, Finnisch, Französisch, Deutsch, Hebräisch, Hindi, Italienisch, Japanisch, Koreanisch, Portugiesisch, Polnisch, Russisch, Spanisch, Schwedisch und Thai. Daten mit höherer Qualität erhalten von Nvidia ein höheres Gewicht im Training; der technische Bericht schweigt sich aber darüber aus, wie die Qualität bestimmt wird.

In den unterschiedlichen Phasen arbeitet Nvidia mit verschieden langen Kontexten. RoPE (Rotational Position Embeddings zur Vergrößerung des Kontexts) benutzt Nvidia dabei wegen der Mamba-Layer zwar nicht, aber mit den höherwertigen Inhalten wird der Kontext auf bis zu 512K Token erhöht. Nemotron-3-Nano trainiert Nvidia in bfloat16, für die größeren Varianten, die noch nicht erschienen sind, kommt das viel kompaktere NVFP4 zum Einsatz. Nvidia behauptet, damit keine großen Quantisierungsfehler zu machen. Nvidia hat auch die nach dem Pre-Training entstandenen Basis-Modelle veröffentlicht, die noch nicht feingetunt sind.

Post-Training

Das Post-Training unterteilt Nvidia in drei Phasen, ein Supervised Finetuning (SFT), ein Reinforcement Learning with Verifiable Rewards (RLVR) für unterschiedliche Umgebungen und schließlich ein Reinforcement Learning with Human Feedback (RLHF).

In der SFT-Phase nutzt Nvidia eine Kontextlänge von 256k Token und Trainingsdaten aus Chats, Dialogen mit Agenten und Reasoning. Letzteres soll dabei helfen, dem Modell ein Limit für das Reasoning anzutrainieren oder es ganz auszuschalten, damit es nicht zu viele Token und damit Kosten erzeugt. Das Modell lernt an dieser Stelle, Reasoning mit Tools durchzuführen. Die Daten hat Nvidia in unterschiedliche Bereiche getrennt: mathematische Probleme mit formalen Beweisen, Programmcode, wissenschaftliche und Softwarethemen sowie verschiedene Sprachen. Auch die Sicherheit berücksichtigt Nvidia hier, damit das Modell seine Grenzen nicht überschreitet. Sehr spezifisch für Nvidia sind die CUDA-Trainingsdaten, Nemotron beherrscht also auch diese Programmiersprache.

Beim RLVR trainiert Nvidia mit Daten in ganz ähnlichen Bereichen parallel. Der Fokus liegt hier auf verifizierbaren Ergebnissen, Programme müssen etwa Unit-Tests durchlaufen. Nvidia erklärt leider nicht, ob es ähnlich wie DeepSeek V3.2 auch die einzelnen Prozessschritte verifiziert, möglicherweise ist das noch eine Optimierung, die zu einem späteren Zeitpunkt eingesetzt werden kann. Der Kontext ist bei RLVR mit 256k Token etwas kleiner als beim SFT.

Neue Ideen bringt Nvidia beim RLHF ein und nutzt ein generatives Belohnungsmodell (GenRM), interessanterweise ein großes Qwen3-Modell (Qwen3-235B-A22B-Thinking-2507). Das Qwen3-Modell wird zunächst feingetunt: Im Trainingsprozess bewertet es mit seinen Reasoning-Fähigkeiten zwei Antworten danach, wie hilfreich sie sind. Die Korrektheit überprüft Nvidia anhand eines synthetischen Datensatzes und dem HelpSteer3-Datenset. Sobald GenRM trainiert ist, kommt es im eigentlichen Reinforcement Learning zum Einsatz und bewertet 16 mögliche Antworten von Nemotron. Um nicht alle 120 möglichen Kombinationen zu bewerten, vergleicht GenRM jeweils nur eine Antwort mit der jeweils nächsten (und die letzte mit der ersten), was zu 16 Bewertungen führt. Das Human Feedback hat Nvidia hier also durch das GenRM-Feedback ersetzt und kann damit sehr viel besser skalieren – an der notwendigen Hardware wird es kaum mangeln. Es ist fast schon erstaunlich, dass Nvidia nicht alle 120 Vergleiche durchführt.

Am Ende quantisiert Nvidia das bfloat16 Modell noch auf FP8 und zeigt, dass damit fast keine Qualität verloren geht. Vermutlich hat man das auch mit NVFP4 probiert und dabei schlechtere Ergebnisse erzielt und daher die größeren Modelle gleich in diesem Datenformat trainiert.

Ausprobieren

Sowohl vllm als auch SGLang unterstützen das neue Nemotron-Modell bereits. Aber auch mit llama.cpp lässt sich das Modell verwenden, da die Architektur mit den Mamba-Layern so ähnlich schon in Qwen3-Next vorkam. Damit lässt sich das Modell auch mit moderater Hardware ausführen und funktioniert ohne GPU auf der CPU in akzeptabler Geschwindigkeit.

Bei der Frage nach dem Heise-Verlag antwortet das Modell etwas zu kreativ, aber immerhin in korrekter deutscher Sprache:

Die Anzahl der „e“ in „Erdbeere“ kann das Modell hervorragend zählen und antwortet kurz und knapp – sehr viel knapper als fast alle anderen bisher getesteten Modelle:

Die Geschwindigkeit von Nemotron-Nano ist hoch, auf einem MacStudio (M2 Ultra) erreicht es etwa 80 Token/s beim Generieren von Antworten.

Große Nemotrons

Die noch nicht veröffentlichten größeren Nemotron-Modelle sollen noch mehr Tricks auf Lager haben. Nvidia kündigt etwa LatentMoE an und erklärt, dass das damit verbundene Design der Expert-Layer auf die Hardware optimiert wurde. Das wird wie das verwendete NVFP4-Format dann wohl nur gut mit Nvidia-GPUs funktionieren. Denn diese Fähigkeiten unterstützen nur die neueste Hardware-Generation von Nvidia.

Multi-Token Prediction beherrschen schon einige Modelle, auch das sollen die Super- und Ultra-Modelle dann können. Nvidia verspricht sich davon eine verbesserte Generierung langer Texte und eine insgesamt höhere Modellqualität. Noch ist nicht bekannt, wie groß die weiteren Modelle sein werden und wann mit ihnen zu rechnen ist – Nvidia spricht von „in den nächsten Monaten“.

Fazit

Nvidia hat geliefert. Mit der Nemotron-Familie ist bereits in der kleinsten Nano-Version (endlich!) ein Modell verfügbar, das den chinesischen Anbietern von Open-Weight-Modellen Konkurrenz macht. Glaubt man Nvidias Auswertungen, ist das eigene Modell aktuell führend, wenn man die Kosten pro Token im Vergleich zu der Genauigkeit betrachtet (Grenzlinie von Genauigkeit-Inferenz-Durchsatz). Gleichzeitig ist das Modell mit offenen Gewichten verfügbar und kann kommerziell genutzt werden. Zusätzlich hat Nvidia einen Großteil der Trainingsdaten veröffentlicht und schafft damit fast ein Open-Source-Modell. Es wird spannend zu sehen, wie gut die angekündigten größeren Modelle sein werden.

Ganz aktuell hat Nvidia auch das Framework veröffentlicht, mit dem sie die Performance der Modelle gemessen haben; auch das steht frei zur Verfügung und heißt Open Evaluation Standard. Dies ist sicher ein weiterer Beitrag zur Transparenz der Modelle und motiviert vielleicht auch andere Anbieter, damit ihre Modelle zu benchmarken.

(pst)

Das Kubernetes-Projektteam hat Version 1.35 veröffentlicht, die insgesamt 60 Neuerungen umfasst – davon 17 stabile Features sowie 19 Beta- und 22 Alpha-Funktionen. Aufbauend auf der seit Version 1.34 als stabiles Feature verfügbaren Dynamic Resource Allocation (DRA) erweitert das neue Release die Möglichkeiten für Ressourcenmanagement und Workload-Sicherheit.

In-place Updates für Pod-Ressourcen und Beta-Features für Sicherheit

Das wohl wichtigste neue stabile Feature erlaubt laut der Ankündigung zu „Timbernetes“ (The World Tree Release) das Anpassen von CPU- und Speicherressourcen laufender Pods, ohne diese neu starten zu müssen. Bisher erforderten solche Änderungen das Neuerstellen von Pods, was insbesondere bei zustandsbehafteten oder Batch-Anwendungen zu Unterbrechungen führen konnte. Die Funktion soll insbesondere vertikales Skalieren vereinfachen.

Native Pod-Zertifikate für Workload-Identität mit automatisierter Zertifikatsrotation stehen nun im Rahmen der Beta-Phase zur Verfügung: Der kubelet generiert Schlüssel, fordert Zertifikate über PodCertificateRequest an und schreibt Credentials gebündelt in das Dateisystem des Pods. Die Knotenbeschränkung erzwingt der kube-apiserver ab dem Zeitpunkt der Zulassung. So sollen sich auch die beim Einsatz von Signierern durch Drittanbieter häufig auftretenden, versehentlichen Verletzungen der Knotenisolationsgrenzen vermeiden lassen. Laut Ankündigung des Kubernetes-Teams eröffnet sich damit auch der Weg zu reinen mTLS-Flows ohne Bearer-Tokens im Ausstellungspfad.

Die native Storage Version Migration ist in Kubernetes 1.35 ebenfalls Beta und standardmäßig aktiviert. Damit rückt die Migrationslogik direkt in die Control Plane. Für StatefulSets steht das maxUnavailable-Feld jetzt ebenfalls standardmäßig zur Verfügung. Es definiert, wie viele Pods während eines Updates gleichzeitig nicht verfügbar sein dürfen, was Updates beschleunigen kann. Die als sicherere YAML-Variante für Kubernetes in Release 1.34 eingeführte KYAML hat auch die Betaphase erreicht und ist standardmäßig aktiviert.

Veraltete und entfernte Funktionen

Das Kubernetes-Projekt hat den Support für cgroup v1 ab Release 1.35 entfernt. Cluster-Administratoren müssen ihre Nodes auf Systeme mit cgroup-v2-Unterstützung migrieren, andernfalls startet der kubelet nicht mehr. Ebenso endet jetzt der Support für die Runtime containerd 1.x – vor dem nächsten Upgrade ist der Wechsel auf containerd 2.0 oder höher erforderlich.

Der IPVS-Modus in kube-proxy gilt nun als veraltet (deprecated). Das Projektteam empfiehlt den Wechsel zu nftables. Zudem hat das Kubernetes-Team angekündigt, Ingress NGINX nur noch bis März 2026 zu pflegen. Danach wird das Projekt archiviert – die Migration zur Gateway API wird empfohlen.

Einen vollständigen Überblick aller Änderungen und Neuerungen liefern der Blogbeitrag zu Kubernetes 1.35 sowie die Release Notes auf GitHub.

(map)

Softwareentwicklung ist kein Selbstzweck, sondern folgt immer einer zugrunde liegenden Fachlichkeit.

Dieser Satz steht gefühlt in jedem meiner Blogposts hier bei Heise Developer. Er ist mein Leitsatz, meine Überzeugung, mein Kompass. Aber 2025 war das Jahr, in dem er für mich mehr Bedeutung bekommen hat als je zuvor.

Warum scheitern so viele Softwareprojekte? Warum werden sie teurer als geplant, dauern länger als versprochen, liefern weniger als erhofft? Die Antwort, die ich immer wieder sehe, lautet nicht: „Weil die Technik versagt hat.“ Die Frameworks waren gut genug. Die Datenbanken schnell genug. Die Cloud skalierbar genug. Nein, die Projekte scheitern, weil die Fachlichkeit vergessen wird. Weil Technik zum Selbstzweck wird. Weil man Datenbanktabellen entwirft, statt zu fragen, was eigentlich passiert.

Dieses Jahr habe ich versucht, dagegen anzuschreiben. Und nicht nur das.

EventSourcingDB: Die Konsequenz der These

Im Mai dieses Jahres haben wir EventSourcingDB veröffentlicht, eine Datenbank, die speziell für Event Sourcing entwickelt wurde. Keine weitere NoSQL-Datenbank, kein weiteres Tool „um des Tools willen“, sondern die technische Konsequenz einer Überzeugung.

Event Sourcing zwingt zum Nachdenken über Fachlichkeit. Man speichert nicht Zustände, sondern fachliche Ereignisse. Nicht „Kunde hat Adresse Y“, sondern „Kundin ist am 15. März an folgende Adresse umgezogen“. Das klingt nach lediglich einem kleinen Unterschied, ist aber ein fundamentaler Perspektivwechsel. Die Technik dient der Domäne, nicht umgekehrt.

Dass EventSourcingDB inzwischen über 10.000 Docker-Downloads verzeichnet, freut mich. Aber mich freut noch mehr, dass offenbar immer mehr Entwicklerinnen und Entwickler nach genau so einem Werkzeug gesucht haben – einem Werkzeug, das Fachlichkeit ernst nimmt.

Der rote Faden: Die wichtigsten Artikel des Jahres

Über 40 Blogposts habe ich 2025 hier bei Heise Developer veröffentlicht. Über Event Sourcing, über Architektur, über KI, über Agilität und ihre Abgründe. Aber wenn ich zurückblicke, bilden sieben davon für mich den Kern dessen, worum es mir eigentlich geht. Sie erzählen zusammen eine Geschichte: Die Geschichte, warum Softwareentwicklung anders gedacht werden muss.

Das Problem sichtbar machen

Beginnen möchte ich mit einem Märchen. In meinem Blogpost „Warum CRUD für Märchen und Unternehmen gleichermaßen ungeeignet ist“ habe ich versucht, ein komplexes Thema über eine einfache Metapher zugänglich zu machen: Der Wolf hat die Großmutter nicht gelöscht – er hat sie gefressen.

CRUD (Create, Read, Update, Delete) ist das Standardvokabular der meisten Anwendungen. Aber es ist ein technisches Vokabular, kein fachliches. Es versteckt, was wirklich passiert. Es reduziert Geschäftsprozesse auf Datenbankoperationen. Und es macht Systeme zu schwarzen Löchern, in denen die Vergangenheit verschwindet.

Das Märchen hat offenbar einen Nerv getroffen. Vielleicht, weil jede Entwicklerin und jeder Entwickler schon einmal vor einem System stand und sich gefragt hat: „Wie ist dieser Datensatz eigentlich in diesen Zustand gekommen?“

Die konzeptionellen Grundlagen

Wenn CRUD das Problem ist, was ist dann die Lösung? Darauf habe ich in zwei Artikeln geantwortet: „Event Sourcing: Die bessere Art zu entwickeln?“ und „CQRS als Grundlage für moderne, flexible und skalierbare Anwendungsarchitektur“.

Event Sourcing bedeutet, nicht den Zustand zu speichern, sondern die Ereignisse, die zu diesem Zustand geführt haben. CQRS bedeutet, Lesen und Schreiben zu trennen, weil beide unterschiedliche Anforderungen haben. Zusammen bilden sie die Bausteine für Systeme, die Fachlichkeit ernst nehmen. Systeme, in denen man nachvollziehen kann, was passiert ist, und in denen man neue Fragen an alte Daten stellen kann.

Die Vertiefung

Konzepte sind das eine, Umsetzung das andere. Deshalb habe ich im Sommer eine siebenteilige Serie geschrieben: „Event-Driven“. Von den Grenzen klassischer Architekturen über die Bausteine Event-getriebener Systeme bis hin zur praktischen Umsetzung am Beispiel einer Stadtbibliothek.

Es war mein umfassendstes Werk zum Thema in diesem Jahr. Und es war mir wichtig zu zeigen, dass Event-getriebene Architektur kein akademisches Konzept ist, sondern ein praktikabler Weg, Software zu bauen, die die Sprache der Domäne spricht.

Technische Tiefe im Dienst der Fachlichkeit

Wer über Event Sourcing spricht, muss auch über Vertrauen sprechen. Wie kann ich beweisen, dass ein bestimmtes Ereignis zu einem bestimmten Zeitpunkt stattgefunden hat? Wie kann ich Nachvollziehbarkeit garantieren, ohne alle meine Daten offenlegen zu müssen?

In „Merkle-Trees: Datenintegrität kryptografisch beweisen“ habe ich gezeigt, wie sich diese Fragen elegant lösen lassen. Merkle-Trees sind keine neue Erfindung. Sie stecken in Git, in Blockchains, in Certificate-Transparency. Aber im Zusammenspiel mit Event Sourcing entfalten sie ihre volle Stärke: Sie machen Nachvollziehbarkeit nicht nur möglich, sondern beweisbar.

Das ist keine technische Spielerei. Das ist relevant für Compliance, für Audits, für die DSGVO. Technik im Dienst realer Anforderungen.

Heilige Kühe hinterfragen

Der letzte Artikel in dieser Reihe ist der jüngste und vielleicht der kontroverseste: „Wendet man DDD auf DDD an, bleibt kein Domain-Driven Design übrig“.

Domain-Driven Design ist in meiner Community so etwas wie eine heilige Kuh. Und ich schätze die Grundideen von DDD sehr. Aber ich beobachte auch, wie DDD selbst zur Selbstbeschäftigung wird. Wie Teams Bounded-Contexts definieren, ohne je mit einer Fachexpertin gesprochen zu haben. Wie Aggregate und Value-Objects zum Selbstzweck werden, statt der Domäne zu dienen.

Das ist keine Kritik an Eric Evans oder an DDD als Idee. Es ist eine Kritik daran, wie wir als Community manchmal Methoden über Ergebnisse stellen. Und es ist ein Plädoyer dafür, auch unsere liebsten Werkzeuge kritisch zu hinterfragen.

So viel ich auch schreibe, am Ende ist es die Community, die diese Themen lebendig macht. Und 2025 hat mir gezeigt, dass ich mit meinen Überzeugungen nicht allein bin.

Im Oktober waren mein Kollege Rendani und ich auf der KanDDDinsky in Berlin – erstmals als Sponsoren und Aussteller für EventSourcingDB. 250 bis 300 Menschen, die unsere Leidenschaft für Domain-Driven Design, Event-Sourcing und durchdachte Softwarearchitektur teilen. Die Gespräche dort haben mir gezeigt: Das Thema hat Momentum. Event-Sourcing und CQRS sind keine Nischeninteressen mehr, die von einer kleinen Gruppe Enthusiasten in isolierten Ecken praktiziert werden.

Besonders gefreut hat mich die Veröffentlichung von OpenCQRS 1.0 durch Digital Frontiers, ein CQRS- und Event-Sourcing-Framework für die JVM mit nativer EventSourcingDB-Integration. Es entsteht ein Ökosystem. Andere bauen auf dem Fundament auf. Das ist die schönste Bestätigung für die Arbeit, die man in ein Projekt steckt.

Und natürlich danke ich Ihnen, den Leserinnen und Lesern, die kommentiert, diskutiert, widersprochen haben. Gerade die kontroversen Artikel haben mir gezeigt, dass das Thema bewegt. Widerspruch ist kein Problem, Gleichgültigkeit wäre eines.

Ausblick: Fachlichkeit, Architektur und KI

Wenn ich auf 2026 blicke, sehe ich ein Thema, das alles andere überlagern wird: Künstliche Intelligenz. Aber nicht so, wie es oft diskutiert wird.

In meinem Blogpost „Event-Sourcing als perfekte Grundlage für KI“ habe ich argumentiert, dass die Diskussion um KI zu oft bei den Modellen beginnt. Welches LLM ist das beste? GPT oder Claude? Aber das ist die falsche Frage. Die richtige Frage lautet: „Welche Daten habe ich?“

Ein durchschnittliches Modell mit hochwertigen Daten wird jedes Spitzenmodell schlagen, das auf minderwertigen Daten trainiert wurde. Und die Daten der meisten Unternehmen sind minderwertig, weil sie in CRUD-Systemen liegen, die nur den aktuellen Zustand kennen. Die Vergangenheit? Überschrieben. Der Kontext? Verloren. Die Kausalität? Nicht rekonstruierbar.

Event Sourcing ändert das. Es liefert kontextreiche, nachvollziehbare Daten. Es beantwortet nicht nur die Frage „Was ist?“, sondern auch „Wie ist es dazu gekommen?“ Und genau das braucht KI.

Gleichzeitig verschiebt sich die Wertschöpfung in der Softwareentwicklung. In „KI macht Entwickler ersetzbar, aber gute Architekten nicht“ habe ich beschrieben, was das bedeutet: Codieren wird zur Commodity. Was bleibt, ist Domänenwissen, Architektur, Modellierung. Das ist kein Untergang für unseren Berufsstand, es ist vielmehr eine Chance für alle, die Fachlichkeit ernst nehmen.

Die Kombination aus Architektur, Fachlichkeit und KI wird in Zukunft immer wichtiger. Wer versteht, wie man Systeme baut, die gute Daten produzieren, wer versteht, wie man KI sinnvoll einsetzt, und wer gleichzeitig die Domäne versteht, für die er entwickelt, der wird gefragt sein. Genau an dieser Schnittstelle arbeite ich gerade an einer Webinar-Reihe für 2026: der tech:lounge 360°. Für alle, die nicht von KI überrollt werden wollen, sondern sie verstehen und nutzen möchten.

Zum Schluss

Softwareentwicklung ist kein Selbstzweck. Das war mein Leitsatz zu Beginn dieses Artikels, und es ist mein Leitsatz am Ende dieses Jahres.

2025 war für mich das Jahr, in dem dieser Satz Gestalt angenommen hat: in EventSourcingDB, in über 40 Blogposts, in Gesprächen auf Konferenzen, in der Arbeit mit Kundinnen und Kunden. Es war ein intensives Jahr, ein produktives Jahr, und ich bin dankbar für alle, die diesen Weg mitgegangen sind.

Ich wünsche Ihnen Zeit zwischen den Jahren. Zeit zum Nachdenken, was eigentlich das fachliche Problem ist, das Sie lösen wollen. Zeit, um innezuhalten und sich zu fragen, ob die Technik, mit der Sie arbeiten, der Fachlichkeit dient oder zum Selbstzweck geworden ist.

Und dann ein Jahr 2026, in dem die Technik wieder das wird, was sie sein sollte: ein Werkzeug im Dienst dieser Fachlichkeit.

Frohe Weihnachten, ruhige und erholsame Feiertage, und einen guten Start ins neue Jahr.

(rme)