Am 7. August ist das von vielen mit Spannung erwartete GPT-5 erschienen. So offen OpenAI mit den wenige Tage zuvor veröffentlichten GPT-OSS-Modellen umgeht, so wenig ist über die Architektur von GPT-5 bekannt. Daher müssen viele Details Spekulation bleiben. Und wie so oft bei neuen Modellen gehen die Meinungen in der Community stark auseinander.

Spekulationen zur Architektur

Dass OpenAI einige Ideen für die GPT-OSS-Modelle dem kurz danach veröffentlichten großen GPT-5 entliehen hat, wäre anzunehmen. Vieles deutet aber darauf hin, dass GPT-5 nicht auf das schlanke MXFP4-Format setzt, das GPT-OSS so effizient macht. Die Gründe kennt nur OpenAI. Es ist schade, dass Unternehmen wie Anthropic, OpenAI und in gewissem Maße auch Google so wenig über die Architektur ihrer großen Modelle verraten.

Klar ist aber zumindest, dass GPT-5 ein sogenanntes Routing-Modell ist. Je nach Komplexität der Frage beantwortet das Modell sie entweder direkt oder gibt sie an ein Reasoning-Modell weiter, das dann versucht, das Problem strukturiert zu lösen. Leider klappt das nicht immer, wie die im Folgenden gezeigten ersten Versuche belegen.

Anders als die bisher von OpenAI veröffentlichten Modelle steht GPT-5 allen Nutzerinnen und Nutzern direkt zum Start zur Verfügung. Die interessante Strategieänderung könnte darauf zurückzuführen sein, dass das neue Modell dank Routing deutlich effizienter arbeitet und OpenAI damit Infrastruktur und somit Geld sparen kann, wenn möglichst viele das neue Modell nutzen.

OpenAI hat nach der Veröffentlichung von GPT-5 für viele User ältere Modelle wie GPT-4o und GPT-o3 in den unterschiedlichen Varianten nicht mehr bereitgestellt. Das Vorgehen hat OpenAI allerdings inzwischen korrigiert, sodass zumindest zahlende Kunden auch wieder alte Modelle wählen können.

Erste Chats mit GPT-5

Bei ersten Versuchen zeigt sich, dass GPT-5 Wissensfragen kompetent beantwortet:

Das Routing zu den Reasoning-Modellen funktioniert gut und verarbeitet den Erdbeertest korrekt. Im Netz kursieren aber auch Berichte über von GPT-5 falsch beantwortete Varianten der Strawberry-Challenge auf Englisch.

Bei komplexeren Fragen kommen allerdings nicht immer die richtigen Antworten heraus. Die Frage nach der Primfaktorenzerlegung von 2²⁰+1 beantwortet das Modell zwar eloquent und mit vielen Formeln, die Antwort ist aber leider falsch:

Ein interessantes Detail an dieser Konversation ist, dass GPT-5 manchmal die LaTeX-Notation verwendet, manchmal aber auch nicht. Offenbar hat es aus unterschiedlichen Trainingsdaten gelernt. Durch deren Harmonisierung könnte OpenAI sicher die Performance verbessern. Allerdings sind weder der Trainingsprozess noch die dazugehörigen Gewichte bekannt. Der Fehler in der Rechnung erklärt sich dadurch, dass 2²⁰+1 nicht durch 241 dividierbar ist, die richtige Primfaktoren-Zerlegung wäre 17*61.681, das richtige Ergebnis also 61.681.

Hinsichtlich des Trainings reicht das Wissen von GPT-5 wie bei GPT-OSS bis zum Juni 2024. Die im Artikel gezeigten Chats sind auf der ChatGPT-Seite zu finden.

Unterschiedliche Meinungen aus der Community

Erwartungsgemäß ist die Community in Bezug auf GPT-5 gespalten. User gewöhnen sich an Sprachmodelle wie an alte Freunde, und wenn sie plötzlich anders agieren, sind einige besonders begeistert, andere reagieren mit Ablehnung. Einige Meinungen treten auffällig häufig auf: weniger kreative Antworten, gut für die Softwareentwicklung geeignet, Enttäuschung im Vergleich zum Wettbewerb und Fortschritte beim Frontend.

Verringerte Kreativität: Nutzer kritisieren oft, dass das Modell weniger kreativ antwortet als die GPT-4-Modelle. Das könnte damit zusammenhängen, dass die Frage über das das Routing an ein simpleres Modell gelangt, das nicht über das notwendige Wissen für eine kreative Antwort verfügt.

Gut fürs Programmieren: Viele, die das Modell gut finden, sind besonders überzeugt von den Programmierfähigkeiten. Auch hier könnte ein Spezialmodell dahinterstehen, an das GPT-5 die Prompts weitergibt. Es ist denkbar, dass OpenAI dieses Modell mit gruppenbezogener Strategieoptimierung (Group Relative Policy Optimization, GRPO) trainiert hat, einer Methode, die das chinesische Unternehmen DeepSeek erfunden und veröffentlicht hat.

Vergleich mit Claude und Gemini 2.5 Pro: Viele Nutzerinnen und Nutzer sind enttäuscht und bevorzugen die Modelle von Anthropic und Google. Auch hier könnten Bias oder Gewöhnungseffekte eine entscheidende Rolle spielen. Harte Fakten wie die größere Kontextlänge (400.000 für GPT-5 im Vergleich zu bis zu einer Million Token bei anderen Anbietern) sprechen auch für die Modelle der Wettbewerber.

Frontend: Dass OpenAI mächtig aufgeräumt hat und unter anderem mehr Themes anbietet, sieht die Community allgemein positiv.

Vielleicht kennen Sie das: Sie arbeiten an einem System mit Event-Sourcing (oder Sie möchten ein neues System damit aufbauen) und haben das Gefühl, dass Sie eigentlich schon recht weit sind. Sie haben eine gute Vorstellung davon, was Ihre Entitäten sind. Sie haben bereits erste Event-Typen formuliert, vielleicht sogar schon die ersten Commands. Doch dann kommt der Punkt, an dem Sie eine zentrale Frage beantworten müssen:

„Wie schneide ich eigentlich meine Aggregates?“

Und plötzlich wird alles kompliziert. Sie merken, dass die Entscheidung, wo Sie Ihre Konsistenzgrenzen ziehen, gar nicht so einfach ist. Sie ist im Gegenteil sogar eine der schwierigsten Entscheidungen in einem Event-getriebenen System und gleichzeitig leider auch eine der folgenreichsten. In diesem Blogpost möchte ich Ihnen zeigen, warum das so ist, warum Aggregates problematisch sein können und was Sie dagegen beziehungsweise stattdessen tun können.

Falls Sie mit Event-Sourcing noch nicht viel Erfahrung haben, empfehle ich Ihnen für den Einstieg zunächst das Video „Event-Sourcing – das einzige Video, das Du brauchst„. Dort erkläre ich Ihnen ausführlich, was Event-Sourcing überhaupt ist, wie es grundsätzlich funktioniert, wie man Events schreibt und sie nachher wieder liest, und warum das Ganze überhaupt sinnvoll ist.

Willkommen in der Stadtbibliothek!

Lassen Sie uns mit einem Beispiel beginnen – einem Beispiel, das ich inzwischen in vielen meiner Beiträge verwende, weil es einerseits einfach genug ist, um anschaulich und übersichtlich zu bleiben, und andererseits genug Komplexität bietet, um echte Probleme sichtbar zu machen. Die Rede ist von einer fiktiven Stadtbibliothek. Dort können Leserinnen und Leser Bücher ausleihen, sie bei Bedarf verlängern oder irgendwann (hoffentlich zumindest) zurückgeben. Es gibt außerdem Vormerkungen, Mahnungen und manchmal auch Strafen in Form von Gebühren, zum Beispiel, wenn etwas zu spät oder beschädigt zurückgegeben wird.

Natürlich gibt es auch Regeln, wie das Ganze ablaufen soll, beispielsweise:

„Eine Leserin oder ein Leser darf maximal drei Bücher gleichzeitig ausleihen.“

Oder:

„Ein Buch darf nur dann verlängert werden, wenn es nicht schon von jemand anderem vorgemerkt wurde.“

Das klingt zunächst recht einfach. Wenn Sie die Vorgaben jedoch in ein Event-basiertes System bringen möchten, werden Sie schnell merken: Die Umsetzung ist alles andere als trivial. Ein wesentlicher Grund dafür liegt in den Aggregates, die übrigens ironischerweise eigentlich gar nichts mit Event-Sourcing zu tun haben, da sie ursprünglich ein Konzept aus dem Domain-Driven Design (DDD) sind.

Aggregates sind transaktionale Konsistenzgrenzen

In DDD, und damit oft auch im Event-Sourcing, sind Aggregates die zentralen Konsistenzgrenzen. Sie kapseln Geschäftslogik, sie schützen Invarianten, sie garantieren, dass innerhalb ihrer Grenzen keine fachlich ungültigen Zustände entstehen können, und so weiter. Wenn Sie zum Beispiel ein Book-Aggregate haben, muss es sicherstellen, dass ein Buch nicht doppelt ausgeliehen werden kann oder nur dann zurückgegeben werden kann, wenn es vorher tatsächlich ausgeliehen wurde. Das klingt zunächst sinnvoll, und in vielen Fällen funktioniert es auch gut. Aber eben nicht immer. Aggregates haben ihren Preis. Wie es im Englischen so schön heißt: There is no free lunch.

Das Schneiden eines Aggregate ist eine weitreichende Entscheidung. Es bestimmt nicht nur, wo Konsistenz gilt, sondern auch, wie Sie Events strukturieren, wie Sie Commands modellieren, wie Sie dementsprechend Ihre APIs gestalten, wie Sie Ihre Event-Streams aufbauen, wie Sie diese speichern und wieder lesen. Kurz gesagt: Es bestimmt einen großen Teil Ihrer (Daten-)Architektur. Genau deshalb ist diese Entscheidung so wichtig – und gleichzeitig auch gefährlich.

Sie müssen sie nämlich sehr früh treffen, oft bevor Sie überhaupt genau wissen, wie Ihre Domäne im Detail funktioniert. Sie treffen also eine Entscheidung mit großer Tragweite auf der Basis von sehr wenig Wissen. Und sobald Sie sie einmal getroffen haben, wird es sehr schwierig, sie noch einmal zu revidieren.

Das Schlimmste an alldem: Aggregates sind keine isolierten Konzepte. Sie beeinflussen Ihr gesamtes System. Sie können sie nicht einfach umschneiden. Sie können sie nicht zur Laufzeit neu anordnen. Sie können sie nicht modular ersetzen wie einzelne Services oder Datenbanktabellen. Wenn Sie ein Aggregate falsch schneiden, zahlen Sie diesen Preis oft über Jahre.

Ein Beispiel aus der Praxis

Um das anschaulich zu machen, nehmen wir noch einmal das Beispiel aus der Bibliothek: Wir hatten gesagt, dass eine Leserin oder ein Leser maximal drei Bücher gleichzeitig ausgeliehen haben darf. Wenn Sie nun sagen

„Okay, dann mache ich einfach ein Reader-Aggregate“,

dann müssen Sie dort alle Ausleihen zusammenführen. Das bedeutet: Jedes Mal, wenn jemand ein Buch ausleihen möchte, müssen Sie alle bisherigen Ausleihen dieser Person kennen. Das wiederum bedeutet: Sie brauchen eine Event-Historie, die das abbildet – also einen Stream, der diese Informationen enthält. Doch was ist, wenn Sie stattdessen pro Ausleihe ein eigenes Aggregate haben wollen, also ein Loan-Aggregate?

Dann fehlt Ihnen plötzlich der Überblick: Sie wissen nicht, wie viele aktive Ausleihen es gibt, weil jede Ausleihe in einem eigenen Stream steckt. Sie müssten sie erst zusammenführen, was bei Event-Sourcing nicht trivial ist, da auf Event-Sourcing spezialisierte Datenbanken in der Regel keine Joins oder sonstige relationale Abfragen erlauben. Oder Sie entscheiden sich, das Buch als Aggregate zu modellieren. Dann steht die Regel aber völlig außerhalb des Kontexts dieses Aggregate, weil sie sich nicht auf ein einzelnes Buch, sondern auf die Summe der ausgeliehenen Bücher pro Leserin beziehungsweise pro Leser bezieht. Egal, wie Sie es schneiden – es passt nie so richtig.

Das Problem mit den Aggregates

Das eigentliche Problem: Aggregates sind statisch, viele Regeln sind in der Realität jedoch dynamisch. Aggregates sind strukturell, viele Geschäftsregeln dagegen semantisch. Aggregates orientieren sich an Objekten, viele Invarianten betreffen jedoch Beziehungen, Kombinationen oder Mengen. All das führt dazu, dass Sie Ihr Modell über kurz oder lang an die Struktur Ihrer Aggregate anpassen, statt Ihre Geschäftslogik so ausdrücken zu können, wie sie fachlich sinnvoll wäre.

Vielleicht war das früher weniger ein Problem. Solange Event-Sourcing ein Nischenthema für einige wenige war, konnte man sich mit komplexen Aggregates arrangieren. Das ändert sich jedoch derzeit. Event-Sourcing kommt langsam, aber stetig im Alltag an. Immer mehr Teams interessieren sich dafür, immer mehr Projekte setzen das Konzept produktiv ein. Websites wie CQRS.com und eventsourcing.ai oder Produkte wie EventSourcingDB (alle von the native web GmbH) tragen ihren Teil dazu bei. Doch je mehr Event-Sourcing in der Breite eingesetzt wird, desto mehr Menschen stoßen auf genau diese Fragen:

• Wie schneide ich meine Aggregates?
• Wie drücke ich Regeln aus, die sich nicht sauber in einem Objekt zusammenfassen lassen?
• Wie gehe ich mit Konsistenz um, wenn mehrere Dinge zusammenhängen?

Kurz: Was lange als Randproblem galt, wird für viele Entwicklerinnen und Entwickler zur Alltagsfrage. Wir brauchen Lösungen, die dem gerecht werden.

Eventual statt Strong Consistency

Es kommt noch etwas hinzu: Manche Regeln betreffen nicht nur mehrere Entitäten, sondern sogar mehrere Aggregates. Dann wird es richtig kompliziert. Stellen Sie sich vor, jemand möchte ein Buch verlängern. Um zu prüfen, ob das erlaubt ist, müssen Sie wissen: Ist das Buch aktuell überhaupt ausgeliehen? Ist es von der richtigen Person ausgeliehen? Ist es noch nicht vorgemerkt? All diese Informationen liegen in unterschiedlichen Kontexten vor: Die Ausleihe ist eine Transaktion zwischen der Leserin oder dem Leser und dem Buch. Die Vormerkung ist ein separater Kontext: Sie hängt zwar am Buch, ist aber kein Teil der Ausleihe. Die maximale Anzahl an Verlängerungen kann je nach Bibliotheksregelung ebenfalls eine Rolle spielen. Versuchen Sie, das alles in ein einziges Aggregate zu pressen. Das geht in der Regel entweder gar nicht oder nur um den Preis enormer Komplexität.

Viele Systeme akzeptieren in solchen Fällen die sogenannte Eventual Consistency. Das heißt: Sie lassen die Verlängerung zunächst durchgehen und prüfen dann asynchron, ob die Operation tatsächlich gültig war. Wenn nicht, erzeugen sie ein Kompensations-Event, schicken eine Benachrichtigung oder markieren den Zustand als ungültig. Das funktioniert technisch, ist aber aus fachlicher Sicht unsauber. Sie modellieren damit keine echte Invariante mehr, sondern einen nachträglichen Reparaturmechanismus.

Ergänzend enthalten viele Systeme sogenannte Prozessmanager oder Sagas, die diese Prüfungen orchestrieren. Sie führen mehrere Streams zusammen, lesen parallele Zustände, berechnen Ergebnisse und entscheiden auf Basis von Zeitverhalten, Idempotenz und Zustandskombinationen. Auch das funktioniert, ist jedoch schwer zu durchschauen, zu testen und zu warten. Oft ist es ein völlig überdimensioniertes Konstrukt für eine fachlich eigentlich einfache Regel.

Kill the Aggregate!

Genau deshalb stellt sich die Frage: Geht das nicht auch anders? Kann man Konsistenz nicht so modellieren, wie man sie eigentlich denkt? Also nicht in Form eines Objekts, das alles weiß, sondern in Form einer Regel, die einfach prüft: Gilt das, was ich fachlich will? Genau das ist die Idee hinter Dynamic Consistency Boundaries (oder kurz DCBs).

Dieser Begriff wurde von der italienischen Informatikerin Sara Pellegrini geprägt, die in einem Vortrag mit dem Titel „Kill Aggregate!“ (nach einigen Minuten mit englischen Untertiteln) vor ein paar Jahren genau dieses Paradigma infrage gestellt hat: Muss Konsistenz wirklich immer an einem Objekt hängen? Oder geht es auch anders, nämlich dynamisch, operationsspezifisch und regelbasiert? Stellen Sie sich vor, Sie formulieren eine Regel nicht in Form eines Aggregate, sondern als direkte Bedingung auf die Event-Historie. Zum Beispiel:

„Zähle alle Events vom Typ bookLoaned, bei denen die Leser-ID 23 ist und für die noch kein bookReturned-Event existiert. Wenn die Anzahl kleiner als drei ist, ist die Operation erlaubt.“

Das ist alles. Keine Aggregates. Kein Slicing. Keine Refactoring-Hölle. Keine Joins. Keine Prozessmanager. Keine Sagas. Einfach nur eine Regel: direkt formuliert, direkt überprüft und direkt durchgesetzt. Das ist die Stärke von Dynamic Consistency Boundaries: Sie machen die Konsistenzprüfung zum Teil der Operation und nicht zum Teil der Struktur.

Voraussetzungen für DCBs

Damit das in der Praxis funktioniert, müssen einige Voraussetzungen erfüllt sein. Erstens benötigen Sie Zugriff auf alle relevanten Events. Sie müssen also in der Lage sein, bestimmte Event-Typen zu filtern, zum Beispiel alle bookLoaned-Events für eine bestimmte Nutzerin oder einen bestimmten Nutzer. Zweitens brauchen Sie die Möglichkeit, Bedingungen zu formulieren. Sie wollen etwas ausdrücken können wie:

„Wenn Bedingung X erfüllt ist, dann (und nur dann) schreibe Event Y.“

Drittens benötigen Sie ein System, das diese Bedingungen verlässlich prüft – serverseitig und atomar. Wenn Sie die Bedingungen im Anwendungscode prüfen und dann das Event schreiben, haben Sie wieder eine Race Condition. Diese drei Punkte zusammen bilden das Fundament für DCBs.

Genau das wird künftig zum Beispiel von der auf Event-Sourcing spezialisierten Datenbank EventSourcingDB unterstützt (die von meinem Unternehmen the native web entwickelt wird), und zwar über die eigens für EventSourcingDB entwickelte, deklarative Sprache EventQL. Sie können sich EventQL wie eine Art SQL vorstellen, nur für Events. Mit EventQL können Sie solche Regeln direkt formulieren und zukünftig beim Schreiben von Events in die EventSourcingDB als Vorbedingung angeben. Die Bedingung wird dann beim Schreiben des Events direkt im Server geprüft. Wenn sie erfüllt ist, wird das Event geschrieben. Wenn nicht, wird der Vorgang abgelehnt, und Sie können entsprechend reagieren. Das ist dann echte Konsistenz auf der Basis von realen Events – mit klaren Regeln, ohne Umwege.

Sie können damit Regeln abbilden, wie beispielsweise:

• Ein Gutschein darf nur einmal eingelöst werden.
• Ein Benutzername darf nicht doppelt vergeben sein.
• Eine Anwenderin darf sich nur einmal mit demselben Token einloggen.
• Eine Rechnung darf nur dann geschrieben werden, wenn der Auftrag abgeschlossen ist.
• Ein Buch darf nur dann zurückgegeben werden, wenn es vorher tatsächlich ausgeliehen wurde.

Werden klassische Aggregates überflüssig?

All das sind Beispiele für Regeln, die sich schwer oder gar nicht mit klassischen Aggregates umsetzen lassen – zumindest nicht ohne großen Aufwand und Nebenwirkungen. Mit Dynamic Consistency Boundaries und EventQL werden sie hingegen trivial.

Das bedeutet nicht, dass Aggregates vollständig überflüssig werden. Es gibt nach wie vor viele Anwendungsfälle, in denen sie sinnvoll sind, insbesondere wenn Sie komplexe Zustandsübergänge modellieren oder interne Logik kapseln möchten. Sie benötigen sie jedoch nicht mehr zwingend für jede Regel. Das ist der entscheidende Punkt. Sie können jetzt wählen: Sie können fachliche Regeln direkt ausdrücken, so wie Sie sie verstehen, und entscheiden, ob Sie dafür wirklich ein Aggregate brauchen oder ob eine dynamische Konsistenzgrenze nicht vielleicht die bessere Wahl ist.

(rme)

Github-CEO Thomas Dohmke will den Hut nehmen. Er plant eigenen Angaben zufolge, wieder als Start-up-Gründer aktiv zu werden. Der Schritt folgt knapp vier Jahre, nachdem er den Posten als Chief Executive Officer im November 2021 übernommen hat.

Dohmke gründete 2011 das Unternehmen HockeyApp, das eine Plattform für App-Tests bot. Die Idee verkaufte er an Microsoft und landete selbst als Mitarbeiter in dem Unternehmen. Später wechselte er zu Github, wo er zusammen mit Nat Friedman an der Übernahme durch Microsoft beteiligt war.

Rückzug angekündigt

Im Blog von Github hat Thomas Dohmke seinen Rückzug aus Github am Montag dieser Woche angekündigt. Er fasst dort knapp seinen Werdegang, den Weggang aus Deutschland, den Verkauf seines Start-ups an Microsoft und einige Meilensteine bei Github zusammen. Dort gibt er auch seinen Beweggrund an: „Doch nach all dieser Zeit haben mich meine Start-up-Wurzeln gepackt und ich habe beschlossen, GitHub zu verlassen, um wieder ein Gründer zu werden“, schreibt Dohmke dort.

Auf LinkedIn ergänzt er zudem Danksagungen an Satya Nadella (Vorsitzender und CEO von Microsoft), Julia Liuson (Leiterin von Microsofts Entwicklungsabteilung) und den „Hubbers“ genannten Github-Mitarbeiterinnen und -Mitarbeitern.

Das Portal Axios hat zudem die Information erhalten, dass Microsoft die frei werdende Position des Github-CEO nicht unmittelbar neu besetzen will. Der Leiter von Microsofts CoreAI-Abteilung Jay Parikh hat demnach in einem weiteren Memo eine neue Struktur angekündigt, bei der die Github-Führungsriege an mehrere Microsoft-Führungskräfte berichten wird. Julia Liuson soll etwa die Umsätze, Technik und Support von Github beaufsichtigen. Githubs Produktchef Mario Rodriguez soll an Microsofts AI-Platform-Vizepräsidentin Asha Sharma berichten.

Dohmke verlässt seinen Angaben zufolge Github in einem guten Zustand. Mehr als 150 Millionen Entwickler arbeiten an über einer Milliarde Repositories und Forks. Außerdem sei Github führend im Markt bezüglich Künstlicher Intelligenz, die mehr als 20 Millionen Nutzer einsetzen: „Github war niemals stärker, als es heute ist.“

(dmk)