AI News #13

Dieses Transkript wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Maßgeblich ist immer das im Mitschnitt gesprochene Wort.

Fabian Walther: Hallo, ich begrüße euch zur 13. Folge der AI News. Schön, dass ihr dabei seid, und schön, dass Ole dabei ist. Hallo Ole, du bist momentan ungewöhnlich unterwegs, sehe ich gerade.

Ole Wendland: Ja, genau, das wird eine Kinderzimmerfolge. Ich bin bei meinem Vater im südwestlichen Niedersachsen, im kleinen Dorf Fürstenau. Ich hatte gestern einen Vortrag bei einer kleinen Hauskonferenz, war super nett, am Dümmer, etwa 50 km von hier. Darum bin ich jetzt mal nicht in meinem Schweizer Setup, sondern wieder in der niedersächsischen Heimat.

Fabian Walther: Ja, ist doch schön, mal Abwechslung, mal rauskommen. Sehr gut.

Ole Wendland: Genau.

Fabian Walther: Du hast bestimmt auch über spannende Themen für die Sendung gesprochen.

Ole Wendland: Auf jeden Fall, ja.

Fabian Walther: Sehr gut. Ja, also ich habe mich in den letzten Tagen auch wieder viel mit agentischer Entwicklung befasst und ein Training gegeben, das war auch sehr nett. Grüße gehen raus an die lustige Truppe. Die meisten saßen, glaube ich, in Köln, aber es war diesmal remote und hat Spaß gemacht. Es kamen spannende Fragen auf, und dazu habe ich dann auch noch etwas recherchiert und ein Paper mitgebracht, weil einige Fragen in diese Richtung gingen. Da habe ich versucht, ein bisschen Evidenz aufzutreiben. Das kommt dann auch, aber erst mal haben wir natürlich wieder News für euch. Einiges ist passiert, was Modelle angeht. Am Pricing wurde viel geschraubt, und da gab es jetzt auch eine relativ spannende Analyse, die du dir angeschaut hast, was denn die tatsächlichen Kosten eigentlich sind. Das fand ich auch richtig gut. Und dann haben wir noch einen größeren Block, wo es darum geht, dass jetzt angeblich ganz viele mathematische Probleme gelöst sind, und es stellt sich heraus: manche vielleicht doch nicht, denn irgendwer muss das ja auch alles noch mal verifizieren, ob das alles stimmt. Das finde ich auch einen richtig spannenden Aspekt, das passt auch zu meinem Thema. Da können wir dann gleich hoffentlich gut drüber diskutieren. Und dann hast du noch ein paar spannende Dinge zu dekompilierten Games und Software mitgebracht.

Ole Wendland: Genau, ja.

Fabian Walther: Darauf freue ich mich auch schon. Und wir haben tatsächlich etwas in Richtung News: Mistral hat etwas rausgehauen, was ich auch ziemlich bemerkenswert finde. Also die Europäer lassen sich doch nicht ganz abhängen. Gut, das waren jetzt, glaube ich, die wichtigsten Sachen, die wir vorhaben.

Ole Wendland: Das war schon wieder ganz schön viel, glaube ich. Gucken wir mal, dass wir das unterkriegen.

Fabian Walther: Vielleicht fangen wir tatsächlich mit Anthropic an.

Ole Wendland: Was ist denn da passiert? Du nennst alle Themen vorher, das weiß ich, oder?

Fabian Walther: Ja.

Ole Wendland: Das müssen wir auch alles machen. Genau, Anthropic hat nachgeliefert, die ganze Claude-Familie ist jetzt auf 5.5 hochgezogen. Über Opus 5.5 hatten wir letztes Mal schon geredet und waren beide ja auch große Fans. Und jetzt kamen Sonnet 5.5 und Haiku 5.5. Von Haiku gab es schon lange keinen Release mehr, ich hätte jetzt gesagt, bestimmt 10 Monate. Ja, 4.5 war das letzte, es gab zwischendurch nichts.

Fabian Walther: Genau.

Ole Wendland: Ja, genau.

Fabian Walther: Ja, genau.

Ole Wendland: Finde ich gut. Es wird deutlich billiger. Gerade Sonnet kostet 2 $ Read und 10 $ pro Million Tokens im Output, und Haiku ist sogar nur 10 Cent pro Million Token Read und 50 Cent in der Ausgabe. Das ist schon sehr respektabel, und tatsächlich schlägt sich das Sonnet auch gar nicht so schlecht im Vergleich zu Opus 5.5, liegt da so ein bisschen dahinter. Aber meistens sind das nur so 1, 2 Prozentpunkte in den meisten Benchmarks.

Fabian Walther: Mhm.

Ole Wendland: Ja. Sie haben wieder am Tokenizer geschraubt. Also der Tokenizer verbraucht jetzt wieder mehr Tokens, wohl gerüchteweise. Andererseits, ich weiß nicht, wie es dir geht. Ich verwende ja meistens Opus 5.5, ich schaffe es eigentlich kaum, meine Quote auszureizen. Also eigentlich bin ich fast immer voll zufrieden und schaffe es wirklich nur in Ausnahmefällen, wenn ich viele Agenten parallel laufen lasse, dass ich da mal ins 3-Stunden-Limit reinlaufe. Habe ich eigentlich keine Schmerzen mit. Wie häufig schaffst du es, deine Quote auszureizen?

Fabian Walther: Tatsächlich in letzter Zeit auch gar nicht, aber das liegt einfach auch an meinem Arbeitsmodus, dass ich jetzt auch nicht an einem Produkt bin, wo ich Feature nach Feature raushauen muss, was ja sowieso auch nicht sinnvoll ist. Ich glaube, das sagen wir auch immer an verschiedenen Stellen. Insofern laufe ich da auch nicht in die Limits meiner Subscription rein. Manche können natürlich sagen, ich mache einfach nicht genug parallel und nutze es nicht genug aus, aber ja, ich glaube, mittlerweile sind die ganz gut, da kommt man gut mit aus, wenn man eine mittlere Subscription hat, und selbst wenn man wirklich kontinuierlich damit arbeitet, finde ich das relativ gut. Und ich bin tatsächlich auch ein großer Fan von Haiku. Ich hatte jetzt im Training auch jemanden, der sich wirklich eine Challenge gesetzt hat, alles mit Haiku zu machen, und meine Prediction ist: Haiku ist das neue Sonnet. Prove me wrong. Tatsächlich habe ich dann auch verschiedene Dinge mal mit Haiku versucht, und einfach dadurch, dass es schneller ist, gefällt mir das ziemlich gut. Und jetzt ist auch zumindest in den Anthropic-eigenen Benchmarks ein riesiger Sprung vom 4.5er auf das 5.5er, es kommt teilweise schon an Sonnet ran. Ich hätte tatsächlich auch die Vermutung: Für die Sachen, für die man vor einem Jahr das Sonnet benutzt hat, benutzt man jetzt einfach Haiku, und es ist vermutlich einfach gut genug. Ich glaube, wir kommen jetzt wirklich in die Regionen, wo sich herauskristallisiert, dass für bestimmte Anwendungsfälle günstige Modelle ausreichen. Die sind dann eh auch schneller, man kriegt schnellere Ergebnisse, und von der Qualität reicht es auch. Wo ich vorher mit Opus geplant und mit Sonnet umgesetzt habe, könnte man jetzt wahrscheinlich sogar mit Haiku in die Umsetzung gehen, wenn das Projekt vernünftig aufgesetzt ist und dein Harness vernünftig konfiguriert ist. Das würde ich jetzt mal als Challenge annehmen, das auszuprobieren.

Ole Wendland: Genau, was gab es noch? Ein Punkt noch: Mir ist aufgefallen, dass man bei Opus 5.5 das Thinking gar nicht mehr ausstellen kann, das hatten wir letztes Mal nicht erwähnt. Wenn man so einen API-Aufruf hat, wenn ihr irgendwelche Anwendungen mit LLMs drin habt und die API aufruft, könnt ihr Thinking nicht mehr ausstellen. Das hat zu ein paar Problemen geführt, weil die Aufrufe dann teilweise abgelehnt wurden, wenn man Thinking disabled hatte, um Tokens zu sparen. Das war mir noch eingefallen.

Fabian Walther: Ja. Abschalten tue ich es sowieso nie ganz, aber ich bin tatsächlich jemand, der das Thinking zumindest bei den großen Modellen eher runterstellt. Meistens, wenn ich ein Fable mit Low oder Medium nehme, kriege ich im One Shot sofort ein ziemlich gutes Ergebnis, zumindest für die Fragen, die ich stelle, dann brauche ich gar nicht dieses ganz lange Thinking. Dann nehme ich lieber die größeren Modelle mit weniger Thinking, und bei den günstigeren Modellen kann man das ein bisschen hochdrehen. Das frisst dann den Zeitvorteil wieder auf, und man muss immer balancieren. Bei den Kosten muss man dann wirklich balancieren: Nehme ich das große Modell mit wenig Thinking oder das kleine Modell mit sehr viel? Dann nähern sich die Kosten wieder aneinander an, zumindest von den Tokenkosten her. Da muss man so ein bisschen für sich den Sweet Spot finden. Opus bin ich nach wie vor Fan, aber ich nehme es mittlerweile wirklich meistens nur noch zum Planen und nicht mehr zum Implementieren. Das ist auch eine Erkenntnis aus den Trainings, die wir machen. Am Anfang hieß es, die Implementierung mit Sonnet funktioniert gut, fürs Planning verwendet man auf jeden Fall noch Opus. Aber eine größere Vibe-Coding-Geschichte, die wir mal für einen Prototypen gemacht haben, das hat nur mit Opus funktioniert, und mittlerweile funktioniert das in wesentlich schnellerer Zeit auch mit Sonnet. Das ist jetzt der Standard in dem Training, einfach Sonnet zu nehmen, weil es für die Sache, die wir da machen, ausreicht. Finde ich auch eine schöne Erkenntnis, dass selbst die vermeintlich günstigeren Modelle mächtiger geworden sind. Gut, bevor wir uns zu lange bei Anthropic aufhalten, es gibt ja noch viele andere spannende Sachen.

Ole Wendland: Ja.

Fabian Walther: Womit wir dann weitermachen.

Ole Wendland: Ja, Model News, Model News.

Fabian Walther: Model News.

Ole Wendland: Model News, wir haben endlich ein eine Billion großes europäisches Modell. Mistral hat ein neues Modell geliefert, Large 4 Le Chonk.

Fabian Walther: Le Chonk, schöner Name.

Ole Wendland: Es ist frisch raus, ganz viele Details haben wir noch nicht. Die Weights sind noch nicht raus, die sollen Ende des Monats kommen. Aber was wir bis jetzt wissen: so eine Billion Parameter, um die 50 Milliarden Parameter sind immer aktiv. Da sind sich die Angaben nicht ganz einig, einige sagen 49, andere sagen 52. Ansonsten State of the Art, es ist multimodal, es hat ein Million Context Window, es wurde auf 3800 Blackwell GPUs in einem europäischen Rechenzentrum trainiert, kostet 3,6 Euro pro Million Token Input und 4,1 Dollar für Output. Was gibt es noch zu sagen? In den Benchmarks ist es nicht ganz so gut, also es ist das beste Open Source Modell, wenn man China nicht mitzählt. Das ist leider so ein kleines Aber: Es gibt immer noch ein paar chinesische Modelle, die besser sind, also MiMo ist besser, GLM ist besser. Man muss aber auch sagen, dass die Reinforcement Learning Pipelines noch nicht ganz abgeschlossen sind. Da können wir bis Monatsende noch einige Verbesserungen erwarten. Es scheint nicht ganz an die chinesischen Open Source Modelle ranzukommen, aber nichtsdestotrotz bin ich der Meinung, es gibt eigentlich keine Alternative dazu, dass Europa auch ein eigenes starkes Modell hat, das man zur Not ohne China und ohne USA betreiben kann. Und wie ist das deutsche Modell Aleph Alpha, von denen hört man ja sehr wenig. Ich glaube, unsere einzige Hoffnung ist da so ein bisschen das Mistral Modell aus Frankreich.

Fabian Walther: Das Kolibri gab es jetzt noch aus Deutschland, das haben wir, glaube ich, jetzt nicht im Programm, weil ich mir das auch noch gar nicht angeschaut hatte. Das war aber, glaube ich, von den Black Forest Labs, wenn ich das richtig in Erinnerung habe. Es gibt ja so ein paar Einhörner in Deutschland, die da etwas machen, aber das muss ich auch noch mal genauer anschauen. Das hatte auch einen etwas anderen Fokus, jetzt kein echtes riesiges Foundation Model. Aber Mistral zumindest, wie es jetzt von den Benchmarks aussieht, ist nicht mehr extrem abgeschlagen von den chinesischen Open Source Modellen. Wenn man es mit dem GLM 5.3 vergleicht, ist es jetzt nicht komplett andere Liga, sondern nähert sich dem langsam an. Insofern finde ich das schon bemerkenswert, dass das eben nicht abgeschlagen bedeutet, sondern dass da durchaus was geht.

Ole Wendland: Ja, genau.

Fabian Walther: Ausprobiert habe ich es jetzt auch noch nicht, aber man kann es natürlich über die diversen Provider schon zum Testen holen.

Ole Wendland: Genau. Es hat keine Cybersecurity-Verweigerung wie die anderen. Und staatliche Akteure kriegen es zuerst, das fällt mir noch gerade ein.

Fabian Walther: Ja, das scheint sich auch irgendwie als normales Vorgehen durchzusetzen, dass sie es immer vorab für staatliche Akteure veröffentlichen, damit sie hinterher sagen können: „Ihr habt es ja gesehen und konntet gucken, ob es schlimm ist." Ich bin mir nicht sicher, ob das einfach eine Absicherung für sie selbst ist, nach dem Motto: „Okay, das machen wir jetzt, dann sind wir abgesichert, da kann niemand hinterher sagen, wir haben die Öffentlichkeit gefährdet." Und damit ist das dann abgehakt. Haben wir noch mehr Model News, oder wollen wir es erst mal dabei belassen für heute?

Ole Wendland: Model News, glaube ich, nicht. Wir können mit den Mathematikern weitermachen. Nachdem wir letztes Mal Navier-Stokes schon hatten: Wir in der Informatik kennen ja das Problem, dass die Code-Generierung jetzt billig und schnell geworden ist und wir eigentlich in den Merge Requests, ich will nicht sagen ersaufen, aber dass wir zumindest gefordert sind, die ganzen Merge Requests zu reviewen. Und die Mathematik hat jetzt ein ähnliches Problem bekommen, die haben nämlich auch viel zu reviewen. Vor zwei Wochen haben wir von Navier-Stokes gesprochen, dass da das Millennium-Problem geknackt ist. Und jetzt hat OpenAI einfach noch mal ein Repository veröffentlicht, ich glaube, das heißt nur „OpenAI Math", und davon von 4000 Problemen 722 gelöste Probleme veröffentlicht. Die müssen jetzt alle reviewed werden, die Mathematiker werden gut beschäftigt sein. Ganz verschiedene Bereiche. Interessanterweise kein einziges Paper aus der Kryptografie. Man kann jetzt drüber nachdenken, ist das was Gutes oder was Schlechtes?

Fabian Walther: Oh ja. Das ist was Gutes.

Ole Wendland: Genau, es kann halt auch bedeuten, dass sie eigentlich sehr gut in Mathematik sind und OpenAI das aber nicht veröffentlichen möchte. Für einen Großteil dieser Paper sind Lean-Beweise veröffentlicht worden. Es sind allerdings auch drei davon schon zurückgezogen worden, 14 hatten irgendwelche Anmerkungen, die repariert wurden. Und jetzt wartet man. Ich glaube, für ungefähr die Hälfte sind mittlerweile Lean-Beweise da, und jetzt müssen die Mathematiker das reviewen. Wobei Lean ist halt auch nur so etwas wie ein Unit-Test, das muss man auch sagen. Da setzt man den grünen Haken, und ob das jetzt auch die richtige Fragestellung war oder ob man die Frage genau richtig formuliert hat, ist immer noch so ein bisschen schwierig.

Fabian Walther: Mhm. Genau, das ist genau der Bogen zur Softwareentwicklung: dass die Modelle uns total viele Unit-Tests generieren. Das sieht dann so aus, als wäre alles wunderbar abgetestet. Dann wird irgendwelcher Code generiert, der diese Tests grün macht, und dann ist man zufrieden. Aber wenn man dann reinguckt, was das für Tests sind, merkt man: Okay, die testen ganz viele Dinge, aber erfassen das eigentliche Problem gar nicht. Und genau das sehen wir jetzt hier auch. Es wurde nur überprüft, ob das Lean automatisiert diesen Beweis erbracht hat, aber nicht, ob die Problemformulierung die richtige war. Das muss doch wieder ein Mensch sich anschauen und zumindest die richtige Problembeschreibung sicherstellen. Dann kann der Solver hinterher den Nachweis erbringen, aber das ist genau das Problem, das wir auch in der Softwareentwicklung sehen. Das fand ich extrem spannend, weil ich mir auf der Konferenz, auf der ich war, wieder dieses Property-Based Testing habe schmackhaft machen lassen, von dem ich bisher immer gesagt habe: „Ja, müsste man eigentlich tun, wäre total gut, aber ist auch anstrengend, diese Dinger zu formulieren." Das Anstrengende daran ist, man kann diese Property-Based Tests nur formulieren, wenn man den Problemraum formal beschreiben kann. Und da ist der eigentliche Knackpunkt in der Softwareentwicklung. Wenn ich ihn beschreiben kann, dann weiß ich, hinterher hat meine Software wahrscheinlich keine Bugs, aber das muss ich vorher tun. Und was wir in der Regel nicht machen: Wir machen diese Example-Based Tests, die Unit-Tests, wo wir sagen, wir haben hier ein paar Edge Cases, die frühstücken wir ab, da sind wir sicher. Aber die ganzen Lücken, den ganzen Lösungsraum, den wir nicht beschrieben haben, da liegen die Bugs. Und das finden wir erst in der Entwicklung raus, wo diese Lücken liegen. Genau das Problem sehen wir jetzt hier auch. Das System nimmt dir nicht das Denken und das Verstehen des Problems ab. Es löst dir irgendein Problem, aber es ist nicht klar, ob das wirklich das Problem ist, das du gerade lösen möchtest. Das musst du beschreiben und dem System nahebringen. Da liegt für mich der Knackpunkt. Ich finde schön, dass jetzt die Mathematik gegen die gleiche Wand läuft, nicht nur wir als Softwareentwickler.

Ole Wendland: Geteiltes Leid ist halbes Leid, ne?

Fabian Walther: Ja, ich hatte es ja letztes Mal gesagt, dass jetzt Historiker auch bestimmte Dinge dadurch vielleicht gelöst bekommen, aber auch das muss hinterher ein Mensch sich wieder angucken und sagen, ist das plausibel oder nicht? Nur weil Muster zusammenpassen, heißt es noch nicht, dass es wirklich so ist. Fand ich sehr spannend. Die Mathematik hat die gleichen Probleme wie die Informatik. Ist auch irgendwie nah beieinander, ist naheliegend.

Ole Wendland: Machen wir mit den Biologen weiter. Nein.

Fabian Walther: Oha. Ja, da bin ich auch gespannt, was da noch kommt.

Ole Wendland: Beeindruckend fand ich das Tempo: Bei Navier-Stokes haben sie irgendwie 10.000 Agenten 88 Stunden rechnen lassen. Und jetzt das Modell, das, glaube ich, noch nicht richtig benannt ist, bei Twitter fliegt irgendwie der Name oder Codename „Bel" durch die Gegend, ist aber nicht offiziell von OpenAI bestätigt, hat wirklich nur einen Agenten und 3 Stunden pro Problem gerechnet. Und das ist verdammt beeindruckend für 722 Lösungen. Gut, wie viel davon stehen bleibt, ist noch eine andere Frage, aber ja, wir sind in der Zeit des exponentiellen Wachstums, glaube ich.

Fabian Walther: Ja, ich vermute auch. Ich hatte ja irgendwann gesagt, momentan ist es noch so, dass im Vergleich zu menschlicher Intelligenz der Energieverbrauch da noch viel höher ist. Vielleicht kippt sich das irgendwann doch: Einen Menschen über Jahre mit Energie zu versorgen, damit nach Jahren so ein Beweis im Rahmen einer Promotion erbracht wird, verbraucht vielleicht doch mehr Strom, als wenn man auf manche Probleme solche Technologie loslässt. Das finde ich bemerkenswert und ist eher so ein gesellschaftliches Dilemma, in das man läuft. Richtig spannend. Weil wir gerade bei Softwareentwicklung waren und was die Agenten tun und dass man verstehen muss, was die eigentlich machen: Vielleicht schiebe ich kurz das Paper ein, weil das gut passt. Der Name des Papers ist nämlich, was ich euch verlinke: „Do Coding Agents reuse existing Code or reinvent the Wheel?" Und das ist genau das: dass die Agenten immer versuchen, die kleinstmögliche Lösung zu bauen, damit die Tests grün werden und das Problem gelöst wird. In dem Paper fand ich eine schöne Systematik. Sie haben sich eine Möglichkeit gebaut, Code-Reuse zu messen, indem sie den Syntax-Tree aufbauen, und messen im Grunde, wie viel Code-Reuse Agenten betreiben, und stellen fest: eher wenig. Weil sie genau das machen: Sie bauen immer eine minimale Lösung, legen die aber neben den alten Code daneben, und dadurch akkumuliert sich so eine Structural Debt, wie ich das nennen würde. Vielleicht könnte man es auch Tactical Debt nennen. Wenn man zu wenig Refactorings macht, akkumulieren sich in der Codebase parallele Dinge, die etwas Ähnliches tun, und dann entstehen Bugs, weil nichts zwischendurch mal zurückgetreten und ein Refactoring gemacht, Dinge zusammengefügt werden. Für mich war das die Erkenntnis: Das ist genau der gegenteilige Effekt zu dem, was Entwickler zu tun pflegen, die sich irgendwelche Abstraktionen ausdenken, die man vielleicht mal brauchen könnte, was wir als YAGNI bezeichnen würden. Dann gibt es am Ende eine Stelle, die diese komplizierte Abstraktionsschicht verwendet, und niemand sonst hat verstanden, was die eigentlich tun soll, und verwendet sie deswegen nicht, und sie bleibt einsam in der Ecke liegen. Die Modelle scheinen genau das Gegenteil zu machen, und irgendwo wollen wir ja in der Mitte sein. Da ist es dann wieder an den Menschen, in ihrem Coding Harness dafür zu sorgen, dass doch manchmal zurückgetreten wird, Dinge wieder zusammengefügt werden, Abstraktionen eingezogen werden, was auch jede Menge Boilerplate-Code vermeidet, der bei der Wartung den Kontext vollmüllt. Das war so meine Erkenntnis daraus. Deswegen fand ich dieses Paper spannend, weil es zumindest versucht, da Evidenz anzulegen. Das empfehle ich euch zu lesen. Ich versuche jetzt ab und zu so etwas einzuwerfen, weil gerade immer ganz viel Gefühl im Spiel ist: Wir haben das Gefühl, das neue Modell ist besser. Ich versuche jetzt immer mehr zu schauen, gerade für die Dinge, die wir empfehlen, dass es zumindest auch mal Evidenz gibt, ob das wirklich in der Praxis funktioniert. Natürlich gilt immer: Wer macht, hat recht. Wenn jemand herausfindet, mit dem Werkzeug bin ich effizient und habe gute Ergebnisse, ist erst mal egal, warum. Aber ich finde, zumindest retrospektiv hilft es, da ein bisschen Evidenz zu hinterlegen. Das wollte ich noch anbringen.

Ole Wendland: Genau, sie sind auch sehr schlecht darin, „DRY" zu sein, und neigen dazu, nicht mal minimalen, aber unsinnigen Code noch mal zu schreiben, irgendwelche Retry-Logiken, wo man sagt: „Spring kann das doch super, warum verwendest du das nicht von Spring?" Und dann weigern sie sich, irgendwelche Libraries zu nutzen, wo man sagt: „Ist doch Standard." Und dann weigern sie sich aber wieder, Retries zentral zu machen, und schreiben das zweimal in dieselbe Methode in Services, wo ich denke: hm, ja. Gut, die sind noch nicht arbeitslos, ist doch auch gut.

Fabian Walther: Genau, das wird mir immer mehr klar.

Ole Wendland: Ja.

Fabian Walther: Wir brauchen weiter Software entwickelnde Personen. Die machen vielleicht andere Sachen als vorher, aber sie leisten auf jeden Fall weiterhin einen wichtigen Beitrag dazu, dass wir vernünftige Software bekommen. Genau, womit machen wir weiter?

Ole Wendland: Tokenpreise hätte ich gesagt.

Fabian Walther: Tokenpreise, genau, das wäre noch.

Ole Wendland: Wir müssen uns beeilen, wir sind schon wieder 20 Minuten dabei.

Fabian Walther: Wichtiges Thema. Ja, genau, Tokenpreise ist auf jeden Fall noch mal ein größerer Block, den können wir gerne machen. Was hat denn SemiAnalysis rausgefunden?

Ole Wendland: Genau, die Jungs und Mädels von SemiAnalysis haben gemessen, wie viele Tokens man in Abos bekommt. Und tatsächlich sind sie da sehr methodisch drangegangen. Was sie machen, ist meistens methodisch gut. Sie haben erst mal gemessen, wie viele Input-, Output-, Cache-Read- und Cache-Write-Tokens man für ein Modell bekommt. Und sie haben spezielle Prompts geschrieben, die genau das maximieren, dass du entweder primär Input Tokens hast oder primär Cache-Write-Tokens. Und dann haben sie gemessen, wie viele Tokens du bekommen kannst, bis du in dein 5-Stunden- oder dein Wochenlimit reinläufst. Dann wussten sie, in welchem Modus für welches Modell man wie viele Tokens bekommt. Und dann haben sie sich ihre persönlichen Nutzerprofile im September angeschaut. Sie haben ja auch irgendwie 200 Leute, und dann haben sie geguckt: Der hatte so und so viele Input Tokens, so viele Cache Reads, Cache Writes, Output Tokens. Daraus haben sie Profile erstellt, das auf die Modelle von Opus und ChatGPT umgerechnet und geguckt, wie viele Tokens man aus seinem Abo rausholen kann, und das dann mit API-Tokens verglichen: Was hätte uns das denn an API-Tokens gekostet? Und es kommt raus: Man kann aus seinen Abos ganz schön viel rausholen. Preis-Leistungs-Sieger war Sonnet. Wenn man es komplett voll ausnutzt, kann man aus seiner 200-Dollar-Subscription 12.500 Dollar an Tokens rausbekommen, wenn man das über API laufen lassen würde. Und Fable war relativ schlecht, da kann man nur 2.500 Dollar an Tokens für die 200 Dollar bekommen. Allgemein war Anthropic deutlich günstiger als OpenAI. Teilweise bis zu.

Fabian Walther: Interessant, ich hätte es andersrum vermutet.

Ole Wendland: Nee, eben gar nicht. Man muss fairerweise sagen, OpenAI hat ja gerade ihre Quote halbiert. Das war nach der Halbierung gemessen. Vor der Halbierung wäre es vielleicht nur der Faktor zweieinhalb gewesen, aber jetzt ist meistens der Faktor so fünfmal mehr Tokens bei Anthropic. Was gab es noch dazu zu sagen? Schaut euch das Paper an, da sind viel zu viele gute Diagramme drin, als dass ich das jetzt alles mündlich wiedergeben kann. Eine Frage, die dann immer aufpoppt: Sind diese Abos extrem stark subventioniert? Und die Antwort von SemiAnalysis war, dass es eher ein Indiz dafür ist, dass die API unfassbare Margen abwirft. Teilweise bis zu 94 % Gewinn auf den API-Tokens. Das ist schon ein bisschen verrückt, was sie da für Umsätze machen können, und dass tatsächlich die Abos nur so leicht im Minus sind, also nur zu 20 % subventioniert.

Fabian Walther: Ja, das finde ich eine sehr spannende Erkenntnis. Ich hätte nämlich eigentlich gedacht, dass es andersrum ist, dass sie mit den API-Dingern leicht Gewinn machen und damit die Abos quersubventionieren, weil sie über die Abos die Leute ranbekommen und da auch draufzahlen können, weil der Massenumsatz dann doch eher über die API-Nutzung kommt. Aber diese Erkenntnis finde ich tatsächlich sehr interessant.

Ole Wendland: Mit API-Nutzung machen sie tatsächlich wohl unfassbar viel Geld. Wobei, sie haben jetzt gemessen, was passiert, wenn man das ausnutzt. Also wenn man davon ausgeht, dass Menschen ab und zu noch mal schlafen, essen und vielleicht sogar ein Privatleben haben wollen, schaffen wir es sehr selten, unsere Abos auszunutzen. Selbst die Leute von SemiAnalysis, die man wohl guten Gewissens als „AI Pilled" bezeichnen kann, auch wenn ich ihre Arbeit immer geil finde, man muss immer gucken, aus welchem Bereich sie kommen und welches Mindset sie haben, sie sind sehr pro AI und nutzen das exzessiv, aber auch sie kommen in der Regel selten über 20 % Ausnutzung ihrer Quotas für ihre Abos. Darum machen sie kein großes Minus. Das ist wie bei einem Fitnessstudio-Abo: Es ist eingeplant, dass die Leute es nicht jeden Tag schaffen, ihre Quota auszunutzen. Sie haben also gar kein Minus mit ihren Abos, sondern die 20 % Minus, die theoretisch da sind, rechnen sich auf eine 100-%-Auslastung, die aber kein Mensch erreicht.

Fabian Walther: Ja, genau.

Ole Wendland: Kein.

Fabian Walther: Das ist, glaube ich, auch so kalkuliert, dass diese Abos wirklich dafür da sind, dass primär ein Mensch das Modell nutzt und betreibt, und dass du eben nicht eine Agentenflotte hast, die autonom Tag und Nacht läuft. Dafür sind die einfach nicht gepreist und nicht ausgelegt. Und klar, wenn man das macht, wahrscheinlich auch im totalen Widerspruch zu den AGB, die niemand gelesen hat, dann wird man da auch reinlaufen. Aber so scheint das momentan ganz gut ausbalanciert zu sein. Wenn ich wirklich, sagen wir mal, verantwortungsbewusst mit so einer Subscription arbeite und zwischendurch genug Schlaf bekomme, wie du sagst, dann ist es eigentlich nicht möglich, an die Grenzen zu laufen. Oder ich bin jemand, der Output über Outcome priorisiert und einfach sagt, ich muss Features, Features, Features und ich lese den Code nicht mehr, aber dann sind wir auch jenseits von Software Engineering angelangt. Gut, das war auf jeden Fall ein sehr spannendes Thema, da werde ich das Paper auch noch mal durchgucken. Und vielleicht zum Abschluss noch das Dekompilieren von Games, das fand ich auch interessant, was du da gefunden hast.

Ole Wendland: Ja, kommen wir zum Wichtigsten, das Wichtigste machen wir wieder zum Schluss. Nein, es ist nicht wirklich wichtig, aber es war auffällig, was bei Twitter gerade in den Timelines los ist. Es ist ein richtiger Trend aufgekommen, Spiele und teilweise auch Programme zu dekompilieren. Einer hat einen Photoshop-Klon in Rust geschrieben, aber nicht dekompiliert, der hat das tatsächlich neu geschrieben, glaube ich zumindest. Und die andere Welle ist, dass man sich alte Spiele nimmt, wo man nur noch den Byte Code hat, das dann zu Assembler zurückdekompiliert und das dann von Assembler zu teilweise nutzbaren Hochsprachen rekompiliert. Und wenn man es wieder im Vorwärtslauf kompiliert, sollte idealerweise derselbe Byte Code dabei rauskommen. Es gab wohl schon eine kleine Szene, die sich das zum Hobby gemacht hat, und das war extrem arbeitsaufwendig. Aber ja, unsere Freunde, die LLMs, haben da wohl große Freude dran und sind auch sehr ausdauernd. Das führt dazu, dass erst kleine Spiele dekompiliert wurden, aber jetzt gab es ein neues Fallout-Spiel, Fallout New York, das es offiziell nicht gab, sondern sie haben Fallout dekompiliert und daraus ein neues Spiel mit einem New-York-Setting gemacht. Modern Warfare 2 wurde dekompiliert, das ist so ihr Flaggschiff, witzigerweise auch mit einem 200-Dollar-Abo, das aber ungefähr 200 Milliarden Tokens verschlungen hat, innerhalb von vier Wochen. Er hat es vielleicht geschafft, sein Abo auszunutzen.

Fabian Walther: Ich wollte gerade sagen, das wäre dann wirklich Token Maxing. Genau.

Ole Wendland: Genau. Im Wörterbuch steht das quasi, ja. Entsprechend begeistert waren Activision und Bethesda und haben das gleich wieder abgeschaltet. Lustiges Hobby, interessant für die Modder-Szene: Wenn einen irgendwas an den Spielen gestört hat, kann man das jetzt tatsächlich ändern oder sich neue Level für sein längst vergessenes Lieblingsspiel basteln. Aber es hat natürlich auch eine spannende Rückkopplung auf Legacy Software Modernisierung. Wenn du irgendwelche Binaries von irgendwelchem Java Code rumliegen hast, kann man sich wahrscheinlich wieder die Source-Dateien herstellen lassen. Dazu gehört, dass man einen guten Harness hat, der sich die Methoden nimmt, dass man eine virtualisierte Umgebung hat, wo man das laufen lassen kann, dann testet er das gegen das echte Spiel, und das wird alles automatisiert gemacht. Im Prinzip könnte das auch für viel Legacy Software Modernisierung mit einem guten Harness ein gangbarer Weg sein.

Fabian Walther: Ja, genau, das ist dann immer die Frage, inwiefern noch Kontext über das Softwareprojekt vorhanden ist. Ich habe mir auch so ein Projekt angeguckt, da ging es um PlayStation Portable Spiele, wo aus dem MIPS Maschinencode wieder in C zurückübersetzt und das dann nach WebAssembly kompiliert wurde, damit es im Browser läuft. Fand ich auch ein extrem spannendes Projekt. Nur wenn man dann in den Code reinguckt, der aus diesem Maschinencode extrahiert wird, das ist teilweise kein menschenlesbarer Code mehr. Du hast riesige Arrays mit irgendwelchen Byte-Werten, die bearbeitet werden. Das ist dann fast kein Assembler mehr, du kannst es einfach nicht lesen, weil man nicht weiß, was die Funktionalität wirklich tut, und das nur noch Pointer sind, die irgendwo hinspringen und irgendwas verrechnen. Das läuft dann hinterher und sieht genauso aus, aber zum Modifizieren fehlt eben doch noch ein bisschen Kontext, weil ein paar Methodennamen und so wären schon super gut. Ich glaube auch, dass da, also so klassische Decompiler gab es ja auch vorher schon, aber dass so ein LLM, dem man noch ein bisschen mehr Kontext gibt, zum Beispiel: Wenn du eine Legacy Software hast, nimmst du noch einen Haufen Interviews von Nutzerinnen und Nutzern der Software und fragst: „Okay, was sind eure Use Cases, was macht ihr mit der Software?„, holst dir noch Kontext und kombinierst das mit diesem Prozess. Dann hat man eine größere Chance, dass das LLM diese Muster übereinanderlegt und sagt: „Okay, diese Funktion mit dem kryptischen Namen könnte fachlich vielleicht das tun, weil noch mehr fachlicher Kontext da ist.” Das Problem ist ja häufig, dass gerade bei sehr alter Software, die auf knappen Speicher optimiert war, Speicher teuer war, die Tabellennamen dann nur noch AA und AB und X heißen, damit alles möglichst klein ist, und dass du den Code so weit komprimierst, dass die eigentliche Fachlichkeit nicht mehr hervorgeht. Dann hast du wirklich Probleme. Ich glaube, wenn man das mit einem LLM kombiniert, das noch weiteres Kontextwissen in den Prozess hineingibt, dann könnte das tatsächlich etwas werden. Da bin ich gespannt auf die ersten Projekte, die bei uns in der Richtung laufen, und welchen Erfolg die mit dieser Methodik haben. Aber für mich als Spieler ist es auch interessant.

Ole Wendland: Ich glaube, entscheidend ist, dass man das alte Programm noch lauffähig hat, dass du eine Test-Referenzumgebung hast, wo du abgleichen kannst, dass dieselben Dinge passieren. Bei Spielen ist das relativ einfach, gerade bei alten linearen Spielen, wo du von Level zu Level geführt wirst. Kassensysteme sind selten linear. Ich sehe genau den Punkt, den du meinst: Wenn du verschiedene Inputs an verschiedenen Stellen hast, die sich dann im Prozess viel später überlagern, ist das ein signifikant schwereres Problem als ein Level, das du durchspielst und wo genau klar ist, welche Falltüren oder welche Gegner wann aktiviert werden müssen. Das ist schon einfacher zu testen, das glaube ich auch.

Fabian Walther: Genau. Du brauchst Prozesswissen. Mein Beispiel ist da immer, was ich mal in einer Software gesehen habe, da war ein Check drin: „If Customer Number starts with three, then don’t send Rechnung." Und dann stehst du da und überlegst: Was war denn mal der fachliche Hintergrund davon, dass Kundennummern, die mit drei anfangen, keine Rechnung bekommen? Da hat kein LLM eine Chance, aus dem Code die fachliche Anforderung zu extrahieren, weil die einfach nicht im Code steckt. Dieser Code hat das Problem gelöst, aber der eigentliche fachliche Hintergrund geht daraus nicht hervor. Das waren irgendwie die Kundengruppen, da hat noch mal ein Mitarbeiter manuell über die Rechnung geschaut, weil das VIP-Kunden waren oder so, und dann wurde sie später per Mail verschickt. Aber dieses Wissen war nur in den Köpfen der Leute und nicht in der Software. Deswegen brauchst du gerade bei Legacy-Modernisierung noch weiteren Kontext außer dem Source Code.

Ole Wendland: Ja, der Schlüssel in der Datenbank, und Kategorie ist drei, ja. Okay. Danke für nichts.

Fabian Walther: Deswegen sage ich heute immer, ich weiß, es ist vielleicht gerade nicht mehr so: Speicher ist nicht mehr der limitierende Faktor in der Softwareentwicklung. Bitte macht vernünftige Namen an eure Methoden und benennt das so, wie die fachliche Anforderung war, und nicht irgendwas Kryptisches, dann hast du später diese Probleme nicht. Gut, so viel zum Abschweifen, weil das gerade bei diesem Thema, aus dem Code die fachliche Anforderung herauszulesen, genau an dieser Stelle scheitert. Gut, wir sind bei Minute 38.

Ole Wendland: 40.

Fabian Walther: Genau, wir machen Schluss, glaube ich.

Ole Wendland: Genau.

Fabian Walther: Das war sehr kurzweilig. Ich danke dir.

Ole Wendland: Ja, es hat mir auch wieder sehr viel Spaß bereitet.

Fabian Walther: Ja, wunderbar. Also wir bleiben am Thema dran.

Ole Wendland: Ich hoffe, ihr auch.

Fabian Walther: Genau. Euch da draußen, danke für die Aufmerksamkeit. Wir freuen uns, wenn ihr beim nächsten Mal wieder dabei seid, und vergesst nicht, euch für den INNOQ Technology Day anzumelden. Ich sag’s jetzt wahrscheinlich jede Folge bis zum 12. November. Meldet euch an, kommt dazu, wir freuen uns. Macht’s gut. Ciao Ole.

Ole Wendland: Ciao, ciao.

Diese Zusammenfassung wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Maßgeblich ist immer das im Mitschnitt gesprochene Wort.

Die Claude-Familie wird günstiger

Anthropic hat nachgelegt. Nach Opus 5.5 sind jetzt auch Sonnet 5.5 und Haiku 5.5 da, und beide werden deutlich billiger. Sonnet kostet 2 Dollar im Input und 10 Dollar im Output pro Million Token, Haiku nur 10 Cent und 50 Cent. Ole hält Sonnet für den heimlichen Preis-Leistungs-Sieger, meist liegt es nur ein bis zwei Prozentpunkte hinter Opus. Fabian geht weiter und sagt: Haiku ist das neue Sonnet. Für vieles, wofür man vor einem Jahr Sonnet genommen hätte, reicht jetzt Haiku, vorausgesetzt, das Projekt ist sauber aufgesetzt und der Harness vernünftig konfiguriert.

Europa liefert mit Le Chonk

Mistral hat mit Large 4 „Le Chonk" ein europäisches Modell mit einer Billion Parametern vorgestellt, trainiert auf 3800 Blackwell GPUs in einem europäischen Rechenzentrum. Die Weights kommen Ende des Monats. In den Benchmarks ist es das beste Open-Source-Modell, wenn man China herausrechnet. MiMo und GLM liegen noch davor. Beide finden es trotzdem wichtig, dass Europa ein eigenes starkes Modell hat, das sich zur Not ohne China und USA betreiben lässt. Am Rande fällt auch Kolibri, das deutsche Open-Weight-Modell von Aleph Alpha, das am 3. Oktober für Unternehmen und Behörden veröffentlicht wurde.

Die Mathematik ertrinkt in Reviews

Nach Navier-Stokes im letzten Monat hat OpenAI jetzt ein Repository namens „OpenAI Math" veröffentlicht, mit 722 von 4000 gelösten Problemen. Die müssen alle von Hand reviewt werden. Ole weist auf den Haken hin: Für viele Probleme gibt es Lean-Beweise, aber Lean ist nur so etwas wie ein Unit-Test. Der grüne Haken sagt, dass der Beweis durchläuft, aber nicht, ob die Frage richtig gestellt war. Drei Lösungen wurden schon zurückgezogen. Fabian zieht die Parallele zur Softwareentwicklung. Auch da machen grüne Tests nicht automatisch gutes Verständnis des Problems. Er bringt Property-Based Testing ins Spiel, das nur funktioniert, wenn man den Problemraum formal beschreiben kann, und genau da liegt die Arbeit.

Ein Paper zu Code-Reuse

Passend dazu Fabians Paper-Tipp „Do Coding Agents reuse existing Code or reinvent the Wheel?". Die Antwort fällt ernüchternd aus. Agents bauen meist die kleinste Lösung, die die Tests grün macht, und legen sie neben den vorhandenen Code. So wächst, was Fabian Structural Debt nennt, parallele Stellen, die Ähnliches tun, und daraus entstehen Bugs. Ole ergänzt, dass Modelle schlecht darin sind, DRY zu sein, und lieber Retry-Logik doppelt schreiben, als eine Standard-Library zu nutzen. Beider Fazit: Es braucht weiter Menschen, die im Coding Harness dafür sorgen, dass zwischendurch refactored wird.

Was die Abos wirklich kosten

SemiAnalysis hat gemessen, wie viele Tokens man aus den Abos herausholt. Sieger ist Sonnet. Aus einer 200-Dollar-Subscription lassen sich rechnerisch bis zu 12.500 Dollar an API-Tokens holen, bei Fable nur 2.500. Anthropic ist deutlich günstiger als OpenAI, oft um den Faktor fünf. Überraschend ist die Deutung: Die Abos sind kaum subventioniert, nur etwa 20 Prozent. Das eigentliche Geld steckt in der API, mit Margen bis zu 94 Prozent. Dass die Abos trotzdem aufgehen, liegt am Fitnessstudio-Effekt. Kaum jemand nutzt seine Quota wirklich aus, selbst die AI-affinen Leute von SemiAnalysis kommen selten über 20 Prozent.

Dekompilieren als Trend

Zum Schluss ein Trend aus den Timelines. Leute dekompilieren alte Spiele und bauen sie um, etwa ein inoffizielles Fallout New York oder Modern Warfare 2, Letzteres mit einem 200-Dollar-Abo und rund 200 Milliarden Tokens in vier Wochen. Activision und Bethesda haben das schnell gestoppt. Interessanter als das Hobby ist die Rückkopplung auf Legacy-Modernisierung. Mit einem guten Harness und einer lauffähigen Referenzumgebung lässt sich aus Binaries wieder Quellcode gewinnen. Die Grenze bleibt das Prozesswissen. Fabians Beispiel ist eine Regel wie „Kundennummer beginnt mit drei, keine Rechnung senden". Warum das so war, steht nicht im Code, sondern saß nur in den Köpfen der Leute. Sein Appell: Speicher ist nicht mehr knapp, also gebt Euren Methoden Namen, die die fachliche Anforderung erzählen.