# AI Model Economics and Legacy Code Modernization

**Podcast:** INNOQ Podcast
**Published:** 2026-10-12

## Transcript

Hallo, ich begrüße euch zur 13.
Folge mittlerweile der AI News.
Schön, dass ihr dabei seid und schön, dass der Ole dabei ist.
Hallo Ole, du bist ungewöhnlich unterwegs momentan, sehe ich gerade.
Ja, genau, das wird eine Kinderzimmer-Folge.
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 hier.
So 50 Kilometer von hier.
Und genau, darum bin ich jetzt mal nicht in meinem Schweizer Setup, sondern wieder in der niedersächsischen Heimat.
Ja, ist doch schön.
Mal Abwechslung, mal rauskommen.
Sehr gut.
Genau.
Du hast bestimmt auch über spannende Themen für die Sendung gesprochen.
Auf jeden Fall, ja.
Sehr gut.
Ja, also ich habe auch in den letzten Tagen mich viel wieder mit agentischer Entwicklung befasst.
Habe ein Training gegeben wieder.
Das war auch sehr, sehr nett.
Grüße gehen raus an die lustige Truppe.
Die meisten saßen, glaube ich, in Köln, aber es war remote diesmal.
Hat Spaß gemacht und es kamen spannende Fragen auf.
Und dazu habe ich dann auch noch was recherchiert und ein Paper mitgebracht, weil das in die Richtung ging.
Einige Fragen, da habe ich versucht, ein bisschen Evidenz noch aufzutreiben.
Das kommt dann auch.
Aber erstmal haben wir natürlich für euch News wieder.
Einiges ist passiert, was Modelle angeht.
Am Pricing wurde ganz viel geschraubt und da gab es jetzt auch mal eine relativ spannende Analyse, die du dir da mal 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 mal darum geht, dass jetzt ja ganz viel mathematische Probleme angeblich gelöst sind und stellt sich raus, manche vielleicht doch nicht, denn irgendwer muss das ja auch alles dann doch nochmal verifizieren, dass das dann alles stimmt.
Das finde ich auch einen richtig spannenden Aspekt.
Das passt auch zu meinem Thema so ein bisschen dazu.
Da können wir dann gleich hoffentlich gut drüber diskutieren.
Genau.
Und dann hast du noch ein paar spannende Dinge zu dekompilierten Games und Software mitgebracht.
Genau.
Da freue ich mich auch schon drauf.
Und wir haben tatsächlich was Richtung News.
Mistral hat was rausgehauen, was ich auch ziemlich bemerkenswert finde.
Also die Europäer lassen sich doch nicht ganz abhängen.
Gut, das war jetzt, glaube ich, so die wichtigsten Sachen, die wir vorhaben.
Das war schon wieder ganz schön viel, glaube ich.
Gucken wir mal, dass wir das unterkriegen.
Vielleicht fangen wir tatsächlich dann mit Amthropic an.
Was ist denn da passiert?
Das weißt du, oder?
Ja, das war Absicht.
Genau, Antropic hat nachgeliefert.
Die ganze Claude-Familie ist jetzt auf 5.5 hochgezogen.
Also über Opus 5.5 hatten wir letztes Mal schon geredet und waren beide ja auch große Fans.
Und jetzt kam Sonnet 5.5 und Haiku 5.5.
Also von Haiku gab es schon lange keinen Release mehr.
Also ich hätte jetzt gesagt, bestimmt.
Zehn Monate?
Ja, vier, fünf war das letzte.
Es gab zwischendurch nichts.
Finde ich gut.
Es wird deutlich billiger.
Also gerade Sonnet ist irgendwie zwei Dollar Read und zehn Dollar pro Million Tokens im Output.
Und Haiku ist sogar nur zehn Cent pro Million Dollar Read und 50 Cent in der Ausgabe.
Das ist schon...
Sehr respektabel.
Und tatsächlich, dass Sonnet schlägt sich auch gar nicht so schlecht zum Opus 5.5, liegt also so ein bisschen dahinter.
Aber meistens sind das nur so ein, zwei Prozentpunkte in den meisten Benchmarks.
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 Quota auszureizen.
Also eigentlich bin ich fast immer voll zufrieden und schaffe es also wirklich nur in Ausnahmefällen, wenn ich viele Agenten parallel laufen lasse, dass ich da mein 3-Stunden-Limit reinlaufe.
Da habe ich eigentlich keine Schmerzen mit.
Wie häufig schaffst du deine Quota auszureizen?
Tatsächlich in letzter Zeit auch gar nicht, aber das liegt einfach an meinem Arbeitsmodus, dass ich jetzt auch nicht an einem Produkt bin, wo ich jetzt Feature nach Feature raushauen muss.
Und ja, dass das sowieso auch nicht sinnvoll ist, das zu tun.
Ich glaube, das sagen wir auch immer an verschiedenen Stellen.
Insofern, also ich laufe da auch nicht in die Limits meiner Subscription rein.
Können natürlich manche sagen, ich mache einfach nicht genug parallel und nutze es nicht genug aus.
Aber ja, ich glaube auch mittlerweile sind die ganz gut.
kommt man da ganz gut mit aus, wenn man da eine mittlere Subscription hat.
Und selbst wenn man wirklich kontinuierlich damit arbeitet, finde ich das auch relativ gut.
Und ich bin tatsächlich auch ein großer Fan von Haiku.
Ich hatte jetzt im Training auch jemanden, der wirklich sich eine Challenge gesetzt hat, alles mit Haiku zu machen.
Meine Prediction ist, Haiku ist das neue Sonnet.
Proof me wrong.
Aber tatsächlich habe ich dann auch verschiedene Dinge mal versucht mit Heiko dann zu machen und einfach dadurch, dass es auch schneller ist, gefällt mir das ziemlich gut und jetzt auch so zumindest in Anthropic eigenen Benchmarks ist ja das auch ein Riesensprung von dem 4.5er jetzt auf das 5.5er und kommt dann schon an Sonnet ran teilweise.
Ich hätte jetzt tatsächlich auch die Vermutung für die Sachen, für die man vor einem Jahr halt eben das Sonnet benutzt hat, da benutzt man jetzt einfach Haiku.
Und das ist vermutlich dann einfach gut genug.
Also ich glaube, wir kommen jetzt wirklich in die Region, wo sich jetzt rauskristallisiert.
Für bestimmte Anwendungsfälle reichen einfach günstige Modelle aus.
Die sind dann eh auch schneller.
Man kriegt schneller Ergebnisse.
Und von der Qualität reicht es halt auch.
Also wo ich vorher halt mit Opus geplant habe und mit Sonnet umgesetzt habe, könnte man wahrscheinlich jetzt sogar mit Heiko dann in die Umsetzung gehen.
Wenn das Projekt vernünftig aufgesetzt ist, dein HANIS vernünftig konfiguriert ist, würde ich das jetzt mal als Challenge annehmen, das mal auszuprobieren.
Genau, was gab es noch?
Ah, ein Punkt noch.
Man kann bei Opus, das hatten wir letztes Mal gar nicht erwähnt.
Mir ist aufgefallen, dass man bei Opus 5.5 das Thinking gar nicht mehr ausstellen kann.
Also 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.
Ja, nee, abschalten tue ich sowieso nie ganz, aber ich bin tatsächlich jemand, der das Thinking zumindest bei den großen Modellen eher runterstellt, weil meistens, wenn ich jetzt einen Fable mit Low oder meistens habe ich da Medium drin, da kriege ich halt im One-Shot meistens dann sofort ein ziemlich gutes Ergebnis, zumindest für die Fragen, die ich dann stelle.
Dann brauche ich gar nicht dieses ganz lange Thinking machen.
Dann mache ich lieber dann die größeren Modelle mit weniger Thinking und bei den günstigeren Modellen kann man das dann ein bisschen hochdrehen.
Das frisst dann so ein bisschen den Zeitvorteil wieder auf.
Und man muss dann immer balancieren.
Also bei den Kosten muss man dann wirklich balancieren.
Nämlich das große Modell mit wenig Thinking, das kleine Modell mit sehr viel.
Dann nähern sich die Kosten wieder aneinander an.
Zumindest von den Tokenkosten her.
Also das ist dann schon, muss man so ein bisschen für sich den Sweet Spot finden.
Ja, genau.
Opus.
Nach wie vor ein Fan, aber...
Ich nehme es halt wirklich meistens mittlerweile nur zum Planen und nicht mehr zum Implementieren.
Aber das ist auch so eine Erkenntnis jetzt aus den Trainings, die wir machen.
Am Anfang hieß es so, die Implementierung mit Sonnet funktioniert gut.
Man verwendet eben für das Planning auf jeden Fall noch Opus, aber für bestimmte Sachen.
Am Anfang größere Vibe-Coding-Geschichte, die wir mal gemacht haben für einen Prototypen.
Das hat halt nur mit Opus funktioniert.
Und mittlerweile funktioniert das halt auch in wesentlich schnellerer Zeit auch mit dem Sonnet.
Also das ist jetzt der Standard in dem Training, einfach Sonnet zu nehmen, weil das für die Sache, die wir da machen, ausreicht.
Finde ich auch eine schöne Erkenntnis, dass das halt mittlerweile einfach so ist, dass selbst die vermeintlich günstigeren Modelle halt da mächtiger geworden sind in dem, was damit geht.
Gut, bevor wir uns zu lange bei Anthropik aufhalten, es gibt ja noch viele andere spannende Sachen.
Womit möchtest du weitermachen?
Ja, Model News.
Model News.
Wir haben endlich ein eine Billion großes europäisches Modell.
Also Mistral hat ein neues Modell.
Large Four, Le Chonk geliefert.
Le Chonk, schön haben wir.
Ja, es ist frisch raus.
Ganz viele Details haben wir noch nicht.
Die W rates sind noch nicht raus.
Die sollen Ende des Monats kommen.
Aber was wir bis jetzt wissen, ist so eine Billion Parameter.
So um die 50 Milliarden Parameter sind immer aktiv.
Da sind die Angaben sich nicht ganz einig.
Einige sagen 49, andere sagen 52.
Ansonsten State of the Art.
Es ist multimodal.
Eine Million Context-Window.
Es wurde auf 3.800 Blackwell-GPUs trainiert in einem europäischen Rechenzentrum.
Kostet 3,6 Euro pro Million-Token-Input und 4,1 Dollar für Output.
Genau.
Was gibt es noch zu sagen?
In den Benchmarks ist es nicht ganz so gut.
Also es ist das beste Modell, 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, jetzt fällt mir das Wort an, die Enforcement Learning Pipelines noch nicht ganz abgeschlossen sind.
Also da können wir bis Monatsende noch einige Verbesserungen erwarten, aber es scheint nicht ganz an die chinesischen Open-Source-Modelle reinzukommen.
Aber nichtsdestotrotz bin ich der Meinung, es gibt eigentlich keine Alternative, als dass Europa auch ein eigenes starkes Modell hat, was man zur Not ohne China und ohne die USA betreiben kann.
Und ich meine, wie ist das deutsche Modell?
Aleph Alpha?
Von denen hört man ja sehr wenig.
Ich glaube, unsere einzige Hoffnung ist da, glaube ich, so ein bisschen das Mistralmodel aus Frankreich.
Ja, das Colibri 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, glaube ich, wenn ich das in Erinnerung habe.
Also es gibt ja so ein paar Einhörner in Deutschland, die da was machen.
Aber das muss ich auch noch mehr mal genauer anschauen.
Das war ja auch ein bisschen anderer Fokus, jetzt kein echtes, riesiges Foundation-Model.
Aber Mistral zumindest, wie es jetzt von den Benchmarks aussieht, es ist zumindest nicht mehr extrem abgeschlagen von den chinesischen Open-Source-Modellen.
Wenn man es mit dem GLM 5.3 vergleicht, es ist jetzt nicht komplett andere Liga, sondern es nähert sich dem langsam an.
Insofern finde ich das schon bemerkenswert, dass das eben nicht abgeschlagen ist.
sondern dass da durchaus was geht.
Genau, ausprobiert habe ich es jetzt auch noch nicht, aber man kann es natürlich jetzt über die diversen Provider sich auch schon zum Testen holen.
Genau.
Es hat keine Cybersecurity-Verweigerung wie die anderen.
Und staatliche Akteure kriegen es zuerst.
Das fällt mir noch gerade dazu ein.
Ja, also das scheint sich auch irgendwie jetzt als, ja.
durchzusetzen als normales Vorgehen, dass sie das dann immer vorab veröffentlichen für staatliche Akteure, damit sie hinterher sagen können, ihr hattet es ja gesehen und ihr konntet ja gucken, ob es schlimm ist.
Und ja, ich bin mir auch nicht sicher, ob das einfach, dass sie sich selber absichern.
Das ist quasi einfach so, okay, das machen wir jetzt, dann sind wir abgesichert, da kann jemand hinterher sagen, wir haben irgendwie die Öffentlichkeit gefährdet und damit ist das dann quasi abgehakt.
Haben wir noch mehr Model News oder wollen wir es dabei belassen erstmal für heute?
Model News glaube ich nicht.
Wir können mit den Mathematikern weitermachen.
Oh ja.
Nachdem wir letztes Mal Stokes schon hatten, hat die, also wir in der Informatik kennen ja das Problem, dass wir, 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 mal gechalliged 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 mit Navier Stokes gesprochen, dass da das Millennium Problem geknackt ist.
Und jetzt hat OpenAI einfach mal nochmal ein Repository.
Ich glaube, das heißt nur OpenAI Math.
veröffentlicht und davon 4000 Problemen, 722 gelöste Probleme veröffentlicht.
Also 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 ist das was Schlechtes.
Genau, es kann halt auch bedeuten, dass sie eigentlich sehr gut in Mathematik sind und OpenAI aber das 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 genau jetzt wartet man.
Ich glaube für die Hälfte ungefähr sind mittlerweile Lean-Beweise.
Und jetzt müssen die Mathematiker das reviewen.
Wobei Lean ist halt auch nur sowas wie ein Unit-Test.
Das muss man halt auch sagen.
Das setzt halt den grünen Haken so.
Und ob das jetzt auch die richtige Fragestellung war oder ob man die Frage genau richtig formuliert hat.
heißt es halt immer noch so ein bisschen schwierig.
Genau, das ist ja genau der Bogen dann zur Softwareentwicklung, dass die Modelle uns halt total viele Unit-Tests generieren.
Das sieht dann so aus, als wäre alles wunderbar abgetestet.
Dann wird irgendwelcher Code generiert, der diese Tests dann grün macht und dann ist man zufrieden.
Aber wenn man dann manchmal reinguckt, was das denn für Tests sind, dann merkt man, okay, die testen ganz viele Dinge, aber die erfassen eigentlich das eigentliche Problem gar nicht.
Und das ist etwas, was...
Was wir genau da jetzt auch sehen, was ja dabei rauskam.
Es wurde halt nur überprüft, hat das Lean automatisiert eben diesen Beweis erbracht, aber nicht, ob die Problemformulierung eigentlich die richtige war und ob die halt das war.
Und das muss halt dann doch wieder dann ein Mensch sich anschauen und dann eben zumindest die richtige Problembeschreibung sicherstellen.
Und dann kann der Solver natürlich das hinterher dann irgendwie den Nachweis erbringen.
Aber das ist genau das Problem, was wir auch in der Softwareentwicklung sehen.
Das fand ich dann extrem spannend, weil wir hatten das ja, ich weiß nicht, ob wir das letzte Mal angesprochen hatten, als ich da auf der Konferenz, wo ich war, tatsächlich mir wieder dann dieses Property-Based Testing habe schmackhaft machen lassen, was ich bisher auch immer gesagt habe, ja, müsste man eigentlich tun, wäre eigentlich total gut, aber ist auch irgendwie anstrengend, diese Dinger zu formulieren, weil eben das Anstrengende da dran ist, man kann diese Property-Based-Tests nur formulieren, wenn man den Problemraum halt formal beschreiben kann.
Und da ist aber der eigentliche Knackpunkt in der Softwareentwicklung halt auch.
Wenn ich den halt beschreiben kann, dann weiß ich, okay, hinterher hat wahrscheinlich meine Software keine Bugs, aber das muss ich halt vorher tun.
Und was wir halt in der Regel halt nicht machen, sondern wir machen halt diese Example-Based-Tests, die Unit-Tests, wo wir sagen, okay, wir haben hier so ein paar Edge-Cases, die frühstücken wir ab, da sind wir sicher, unsere Software erfüllt das, aber die ganzen Lücken, die ganzen möglichen, also den ganzen Lösungsraum, den wir eben nicht beschrieben haben, da liegen halt die ganzen Bugs.
Und das finden wir halt erst in der Entwicklung raus, wo diese Lücken liegen.
Ja, genau.
Und das Problem, genau das Problem sehen wir jetzt hier eben auch.
Das System nimmt dir halt nicht das Denken und das Verstehen des Problems ab.
Also es löst dir irgendein Problem, aber es ist nicht klar, ob das wirklich das Problem ist, was du jetzt gerade lösen möchtest.
Das musst du halt irgendwie beschreiben.
Und dann musst du dem System nahe bringen.
Und da liegt für mich der Knackpunkt.
Finde ich sehr schön, dass jetzt aus der Mathematik wir genau gegen die gleiche Gewand laufen.
Nicht nur, was wir als Softwareentwickler halt tun.
Geteiltes Leid ist halbes Leid, ne?
Ja, ne, ich hatte es ja letztes Mal gesagt, dass jetzt irgendwie Historiker halt auch dann jetzt auf bestimmte Dinge dadurch vielleicht gelöst bekommen.
Aber auch das muss dann hinterher ein Mensch sich wieder angucken und sagen, ist denn das plausibel oder nicht?
Muster zusammenpassen, heißt es halt nicht, dass es wirklich so ist.
Ja, fand ich sehr spannend.
Die Mathematik hat die gleichen Probleme wie die Informatik.
Gut, ist auch irgendwie nah beieinander, ist irgendwie auch naheliegend.
Machen wir mit den Biologen weiter.
Genau.
Oha, ja, da bin ich auch gespannt, was da noch kommt.
Beeindruckend fand ich das Tempo.
Also bei Navier Stokes haben sie ja irgendwie 10.000 Agenten 88 Stunden rechnen lassen und jetzt das Modell, was glaube ich noch nicht richtig benannt ist, bei Twitter ist irgendwie so der Name oder Codename Bell, der da so ein bisschen durch die Gegend fliegt, ist aber nicht offensichtlich, ist nicht offiziell bestätigt von OpenAI, hat wirklich nur ein Agent und drei Stunden pro Problem gerechnet.
Das ist verdammt beeindruckend für 722 Lösungen.
Wie viel davon stehen bleiben, ist noch eine andere Frage.
Aber wir sind in der Zeit des exponentiellen Wachstums, glaube ich.
Ja, ich vermute auch.
Ich hatte ja irgendwann gesagt, momentan ist es noch so, dass diese im Vergleich zum menschlicher...
Zu menschlicher Intelligenz ist der Energieverbrauch da noch viel höher.
Vielleicht kippt sich das dann irgendwann doch, dass einen Menschen über Jahre mit Energie zu versorgen, damit nach Jahren vielleicht so ein Beweis erbracht wird im Rahmen von einer Promotion oder so.
Das verbraucht vielleicht dann doch mehr Strom, als wenn man auf manche Probleme eben solche Technologie loslässt.
Das finde ich schon irgendwie, finde ich bemerkenswert und ist dann eher so ein gesellschaftliches Dilemma, in das man dann läuft.
Ja, ja, richtig, richtig spannend.
Da, weil wir gerade bei Softwareentwicklung waren und was denn die Agenten tun und dass man irgendwie verstehen muss, was die eigentlich machen, vielleicht schiebe ich kurz das Paper ein, weil das ganz 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 nämlich genau im Grunde das, dass die Agenten immer versuchen, die kleinstmögliche Lösung zu bauen, damit die Tests grün werden.
und damit das Problem gelöst wird.
Und in dem Paper fand ich eine ganz schöne Systematik.
Sie haben sich da eben eine Möglichkeit gebaut, Code-Reuse zu messen.
Also indem sie den Syntax-Dreh aufbauen und so kann man sich anschauen, fand ich eine ganz schöne Systematik.
Und messen im Grunde dann, wie viel Code-Reuse-Agenten tun und stellen halt fest, eher wenig.
Und weil sie eben nämlich genau das machen.
Sie bauen halt immer eine minimale Lösung, bauen die aber im Grunde, legen die neben den alten Code daneben und dadurch akkumuliert sich natürlich dann so eine Structural Debt, wie ich das nennen würde.
Also das ist dann halt, vielleicht könnte man es auch Tactical Debt bezeichnen, wenn man halt zu wenig Refactorings macht, dann akkumuliert sich halt in der Codebase halt parallele Dinge, die irgendwie das Ähnliche tun und dann entstehen halt Bugs, weil sie, weil eben.
nicht zwischendurch mal zurückgetreten wird und ein Refactoring gemacht wird, Dinge zusammengefügt wird.
Also für mich war das dann so ein bisschen die Erkenntnis, das ist genau der gegenteilige Effekt, was so Entwickler zu tun pflegen, die dann irgendwie sich irgendwelche Abstraktionen ausdenken, die man vielleicht mal brauchen könnte, was wir dann irgendwie als Jagni bezeichnen würden.
Und dann gibt es am Ende eine Stelle, die diese komplizierte Abstraktionsschicht verwendet und niemand anders.
hat verstanden, was die eigentlich tun soll und verwendet sie dann deswegen auch nicht.
Deswegen bleibt sie dann einsam in der Ecke liegen und man hat diesen ganzen Code und diese ganze Abstraktion gebaut und sie wird halt nicht benutzt.
Und ja, die Modelle scheinen offensichtlich genau das Gegenteilige zu machen.
Und irgendwo wollen wir ja in der Mitte sein und da ist es dann wahrscheinlich wieder an den Menschen in ihrem Coding-Hahn ist, entsprechend dafür zu sorgen, dass eben doch manchmal zurückgetreten wird.
Dinge jetzt wieder zusammengefügt werden, dann doch nochmal Abstraktionen eingezogen werden, was dann eben auch vielleicht jede Menge Boilerplate-Code vermeidet, der die dann wiederum bei der Wartung nicht den Kontext vollmüllt.
So, das war so meine Erkenntnis daraus.
Deswegen fand ich dieses Paper ganz spannend, weil es zumindest mal so ein bisschen versucht, da Evidenz dran zu legen.
Also das empfehle ich euch da mal reinzulesen.
Ich versuche jetzt dann...
ab und zu mal sowas einzuwerfen, weil ja gerade, es ist immer ganz viel Gefühl.
Wir haben das Gefühl, das neue Modell ist besser und ich versuche jetzt irgendwie immer mehr ein bisschen auch zu schauen, gerade für die Dinge, die wir empfehlen, dass es da zumindest auch mal Evidenz gibt, ob denn das wirklich in der Praxis funktioniert.
Natürlich ist immer, wer macht, hat recht.
Wenn jemand halt irgendwie herausfindet, mit dem Werkzeug bin ich effizient, habe gute Ergebnisse, ist erstmal egal, warum das so ist, aber ich finde trotzdem.
Zumindest retrospektiv hilft das dann doch mal, da noch mal ein bisschen Evidenz hinterzulegen.
Ja, das wollte ich dann noch anbringen.
Die sind sehr schlechteren in dry und neigen dazu, also gar nicht mal minimalen Code, aber unsinnigen Code nochmal zu schreiben.
Irgendwelche Retry-Logiken, wo man sagt, Spring kann das doch super.
Warum verwendest du das nicht von Spring?
Oder sie weigern sich dann, irgendwelche Libraries zu nutzen, wo du sagst, das ist doch Standard.
Und dann weigern sie sich aber wieder, Retry zu machen und machen das zweimal dieselbe Methode in Services.
Wo ich denke so, ja, gut, wir sind noch nicht arbeitslos.
Genau, also das wird mir immer mehr klar.
Wir brauchen weiter softwareentwickelnde Personen.
Die machen vielleicht andere Sachen als vorher, aber sie leisten einen wichtigen Beitrag dazu, dass wir vernünftige Software bekommen.
Genau, womit machen wir weiter?
Tokenpreise hätte ich gesagt.
Tokenpreise, das wäre noch ein wichtiges Thema.
Tokenpreise ist auf jeden Fall nochmal ein größerer Block, den können wir gerne machen.
Was hat denn Semi-Analysis rausgefunden?
Genau, die Jungs und Mädels von Semi-Analysis haben gemessen, wie viele Tokens man in Abos bekommt.
Und tatsächlich sind die da mal sehr methodisch gut rangegangen.
Also was die machen, ist meistens methodisch gut.
Aber sie haben halt erst mal gemessen, wie viele Input-Output-Tokens, Cash-Read- und Cash-Write-Tokens man bekommt für ein Modell.
Und sie haben sich da spezielle Prompts geschrieben, die halt genau das...
maximieren, dass du entweder Primär-Input-Tokens hast oder Primär-Cash-Right-Tokens und haben dann gemessen, wie viele Tokens du bekommen kannst, bis du in dein 5-Stunden- oder deinen Wochen-Limit reinläufst.
Und damit wussten sie halt, in welchem Modus, für welches Modell man wie viele Tokens bekommt und dann haben sie sich halt angeguckt, was ihre persönlichen Nutzerprofile waren im September.
Die haben ja auch irgendwie 200 Leute und dann haben sie geguckt, der hatte halt so und so viele Input-Tokens, so viele Cash-Reads, Cash-Writes, Output-Tokens und haben daraus halt Profile erstellt und haben das dann auf die Modelle umgerechnet von Opus und ChatGPT und geguckt, wie viele Tokens kann man so aus seinem Abo rausholen.
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.
Also Preis-Leistungs-Sieger war Sonnet.
Wenn man es komplett voll ausnutzt, kann man da 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 OpenAI deutlich günstiger als, Ach, Antropic deutlich günstiger als OpenAI, so rum.
Also teilweise bis zum Mal mehr.
Interessant, ich hätte es andersrum vermutet, ja.
Nee, eben gar nicht.
Auch muss man fairerweise sagen, OpenAI hat ja gerade ihre Quota halbiert.
Das war nach der Halbierung gemessen.
Also vor der Halbierung wäre es vielleicht der Faktor nur zweieinhalb gewesen.
Aber jetzt ist meistens der Faktor so fünfmal mehr Tokens bei Anthropic.
Genau.
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 extremst stark subventioniert?
Und die Antwort von Semi-Analysis war, dass es eher ein Indiz dafür ist, dass die API unfassbare Margen abwirft.
Also teilweise bis zu 94% Gewinn auf den API-Tokens.
Das ist schon ein bisschen verrückt, was die da für Umsätze mitmachen können und dass tatsächlich die Abos nur so leicht im Minus sind.
Also die sind dann halt nur so zu 20% subventioniert.
Ja, das finde ich eine sehr spannende Erkenntnis.
Ich hätte es nämlich eigentlich gedacht, dass es eher andersrum ist, dass sie mit den API-Dingern leicht Gewinn machen und damit halt irgendwie die Abos quer subventionieren, weil über die Abos versuchen sie die Leute ranzubekommen und da können sie ja auch drauf zahlen, weil der Massenumsatz kommt ja dann doch eher über die API-Nutzung.
Aber finde ich interessant, diese Erkenntnis finde ich tatsächlich sehr interessant.
Mit API-Nutzung machen sie tatsächlich wohl unfassbar viel Geld.
Wobei, sie haben jetzt gemessen, was passiert, wenn man das ausnutzt.
Wenn man davon ausgeht, dass Menschen ab und zu nochmal schlafen wollen, essen wollen und vielleicht sogar noch ein Privatleben haben wollen, schaffen wir es sehr selten, unsere Abos auszunutzen.
Selbst die Leute von Semi-Analysis, die man wohl...
guten Gewissens als AI-Pilt bezeichnen kann.
Auch wenn ich Ihre Arbeit immer geil finde, man muss mal gucken, aus welchem Bereich gucken Sie, was für ein Mindset haben Sie.
Und Sie sind sehr pro AI und nutzen das halt auch Exerciest.
Aber auch Sie kommen in der Regel selten über 20% Ausnutzung von Ihren Quotas für Ihre Abos.
Sie machen jetzt nicht großen Minus, sondern das ist wie bei so einem Fitnessstudio-Abo, es ist halt eingeplant.
dass die Leute überhaupt nicht, also zumindest über die Tage gerechnet, jeden Tag schaffen, ihre Quota da auszunutzen.
Das Minus hält sie, also sie haben überhaupt gar kein Minus mit ihren Abos, sondern 20 Prozent Minus, die theoretisch da sind, rechnet sich halt auf eine 100 Prozent Auslastung, die aber kein Mensch erreicht.
Ja, genau.
Also das ist ja, glaube ich, auch so kalkuliert.
dass diese Abos halt wirklich dafür da sind, dass primär ein Mensch irgendwie das Modell nutzt und betreibt und dass du eben nicht eine Agentenflotte hast, die halt irgendwie autonom Tag und Nacht läuft.
Dafür sind die einfach auch nicht gepriced und nicht ausgelegt.
Und klar, wenn man das natürlich macht, wahrscheinlich auch im totalen Widerspruch zu den AGBs, die niemand gelesen hat, dann wird man wahrscheinlich da auch reinlaufen.
Aber so scheint das momentan ganz gut ausbalanciert zu sein.
Also wenn ich wirklich, ich würde jetzt mal sagen, verantwortungsbewusst zu einer Subscription arbeite und zwischendurch auch genug Schlaf bekomme, wie du schon sagst, dann ist das eigentlich nicht möglich, da an die Grenzen zu laufen.
Oder ich bin halt jemand, der halt Output über Outcome priorisiert und einfach nur sagt, ich muss Features, Features, Features und ich lese den Code nicht mehr.
Aber gut, dann sind wir auch jenseits von Software Engineering dann angelangt.
Gut, genau.
Das war nochmal auf jeden Fall ein sehr spannendes Thema.
Da werde ich durch das Paper auch nochmal durchgucken.
Und vielleicht zum Abschluss noch Dekompilieren von Games.
Das fand ich auch interessant, was du da gefunden hast.
Ja, kommen wir zum Wichtigsten.
Das Wichtigste machen wir wieder zum Schluss.
Nein, es ist nicht wirklich wichtig, aber es war halt auffällig, was man bei Twitter gerade so in den Timelines los ist.
ist es ein richtiger Trend aufbekommen, Spiele und auch teilweise Programme zu dekompilieren.
Also einer hat einen Photoshop-Klon in Rust geschrieben, aber nicht dekompiliert.
Der hat tatsächlich das Neue geschrieben, glaube ich zumindest.
Und die andere Welle ist, dass man sich alte Spiele nimmt, wo man dann nur noch den Byte-Code hat, das dann zu Assembler.
wieder zurück dekompiliert und das dann wieder von Assembler zu teilweise nutzbaren Hochsprachen rekompiliert.
Und wenn man es dann wieder im Vorwärtslauf sollte idealerweise derselbe Bytecode dabei rauskommen.
Und es gab wohl schon eine kleine Szene, die sich das zum Hobby gemacht hat und das war halt extremst arbeitsaufwendig.
Aber ja, die unsere...
Freunde der LLMs haben da wohl große Freude dran und sind auch sehr ausdauernd, das zu machen.
Und das führt dazu, dass erst kleine Spiele irgendwie dekompiliert wurden.
Aber jetzt gab es ein neues Fallout-Spiel, Fallout New York, was es ja offiziell nicht gab, sondern sie haben Fallout dekompiliert und dann tatsächlich daraus ein neues Spiel mit einem New York-Setting gemacht.
Modern Warfare 2 wurde dekompiliert.
Das ist so ihr Flaggschiff.
was sie gemacht haben, witzigerweise auch mit einem 200-Dollar-Abo, das aber ungefähr 200 Milliarden Tokens verschlungen hat innerhalb von vier Wochen.
Er hat vielleicht geschafft, sein Abo auszunutzen.
Ich wollte gerade sagen, dass mir dann wirklich Token-Maxing im Wörterbuch steht quasi.
Entsprechend begeistert waren Activision und Bethesda und haben das gleich wieder.
Abgeschaltet.
Genau.
Lustiges Hobby.
Interessant für die Modder-Szene.
Also wenn einem irgendwas gestört hat an den Spielen, kann man das jetzt tatsächlich ändern oder sich neue Level für sein längst vergessenes Lieblingsspiel basteln.
Aber hat auch natürlich spannende Rückkopplungen auf Legacy-Software-Modernisierung.
Wenn du also irgendwelche Binaries von irgendwelchen Java-Code rumliegen hast.
kann man wahrscheinlich sich wieder die Source-Dateien herstellen lassen.
Dazu gehört dann halt, dass man einen guten Harness hat, dass er sich die Methoden nimmt, dass man irgendwie eine virtualisierte Umgebung hat, wo man das dann 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.
Ja, genau.
Das ist natürlich dann immer die Frage, inwiefern noch Kontext über das Softwareprojekt, was du gerade bearbeitest, vorhanden ist.
Weil wir hatten das ja auch, also ich habe mir auch so ein Projekt angeguckt, da ging es um irgendwie Playstation Portable Spiele, wo dann aus dem MIPS Maschinencode irgendwie, der wurde dann wieder in C zurück übersetzt und das dann wieder nach WebAssembly kompiliert, damit es dann im Browser läuft, fand ich auch ein extrem spannendes Projekt.
Nur wenn man dann da in den Code reinguckt, der dann da aus diesem Maschinencode raus extrahiert wird, das ist halt kein menschenlesbarer Code mehr teilweise.
Da hast du dann riesige Arrays mit irgendwelchen Byte-Werten, die dann irgendwie bearbeitet werden.
Das ist dann quasi wirklich schon fast kein Assembler mehr.
Also du kannst es einfach nicht lesen, weil man weiß nicht, was die Funktionalität dann wirklich tut.
Weil das nur noch irgendwelche Pointer sind, die irgendwo hinspringen und irgendwas verrechnen und das läuft dann hinterher.
Das sieht dann auch genau so aus, aber das Modifizieren, dafür fehlt dann eben doch noch ein bisschen Kontext, weil so ein paar Methodennamen und sowas wären halt schon super gut.
Aber ich glaube auch, dass da dann halt, ich meine so klassische Decompiler, die gab es ja auch vorher schon, aber dass dann eben so ein LLM, dem man eben noch ein bisschen mehr Kontext gibt, zum Beispiel irgendwie noch.
Wenn du jetzt irgendeine Legacy-Software hast, du nimmst halt irgendwie noch einen Haufen von Interviews von Nutzerinnen und Nutzern der Software und sagst, okay, was sind eure Use Cases?
Was macht ihr mit der Software?
Dass du dir wirklich interviewst, dir noch Kontext holst und das dann kombinierst mit diesem Prozess.
Ich glaube, da hat man eine größere Chance, dass das LLM diese Muster dann eben auch übereinander legt und sagt, okay, vielleicht diese Funktion, die irgendwie kryptischen Namen jetzt hat, im Dekompiler.
Die könnte vielleicht das tun fachlich, weil eben noch mehr fachlicher Kontext da ist.
Aber das Problem ist ja häufig, dass du gerade bei so Software, die sehr alt ist, die halt auf knappen Speicher, Speicher ist teuer, optimiert war und dann irgendwie die Tabellennamen haben dann irgendwie, heißt nur noch AA und AB und X und dann, weil hier alles möglichst klein ist und dass du halt irgendwie dann die ganzen, ja alles, den Code so weit komprimierst, dass da eben die eigentliche Fachlichkeit nicht mehr daraus hervorgeht.
Und dann hast du natürlich wirklich da Probleme.
Und ich glaube, wenn man das eben kombiniert mit einem LLM, was noch weiteres Kontextwissen damit hineingebt in den Prozess, dann könnte das tatsächlich was werden.
Da bin ich gespannt auf die ersten Projekte, die dann bei uns laufen, die dann in der Richtung was machen, welchen Erfolg die damit haben mit dieser Methodik.
Aber für mich als Spieler ist es auch interessant.
Ich glaube entscheidend ist halt, dass man das alte Programm noch laufbar hat.
Genau.
Dass du halt irgendeine Testreferenzumgebung hast, wo du dann abgleichen kannst, dass dieselben Dinge passieren.
Bei Spielen ist das natürlich relativ einfach, gerade so bei alten linearen Spielen, wo du von Level zu Level geführt hast.
Ja, Kassensysteme selten linear.
Ja, also ich sehe genau den Punkt, den du meinst.
Wenn du verschiedene Inputs an verschiedenen Stellen hast, die sich dann irgendwie im Prozess viel später überlagern und so weiter, ist das natürlich ein signifikant schwereres Problem als ein Level, was du irgendwie durchspielst und wo genau klar ist, welche Falltüren jetzt oder welche Gegner wann aktiviert werden müssen, in welchen Bereich du reinläufst.
Ja, das ist schon einfacher zu testen.
Du brauchst halt Prozesswissen.
Mein Beispiel ist da immer, was ich mal gesehen habe in einer Software, da war halt ein Check drin.
If Customer Number starts with three, then don't send Rechnung.
Und dann stehst du da und überlegst dir, was war denn mal der fachliche Hintergrund davon, dass jetzt Kundennummern, die mit drei anfangen, keine Rechnung bekommen.
Da ist halt einfach, da hat kein LLM eine Chance, aus dem Code heraus die fachliche Anforderung zu extraieren, weil die einfach nicht in dem Code drinsteckt.
Dieser Code hat das Problem gelöst.
Aber der eigentliche fachliche Hintergrund geht daraus nicht hervor.
Das war halt irgendwie die Kundengruppen, da hat man halt nochmal, da hat nochmal ein Mitarbeiter manuell über die Rechnung geschaut, weil das waren irgendwie VIP-Kunden oder so.
Und dann wurde die später per Mail verschickt.
Aber dieses Wissen war halt nur in den Köpfen der Leute und nicht in der Software.
Deswegen hat man da, gerade bei Legacy-Modernisierung, du brauchst halt noch weiteren Kontext außer den Source-Code.
Ja, das ist ja genau der Schlüssel in der Datenbank.
Genau.
Kategorie ist drei, ja.
Okay, danke für nichts.
Deswegen sage ich heute immer, ich weiß, es ist vielleicht gerade nicht mehr so, aber 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, weil dann hast du genau später diese Probleme nicht.
Gut, so viel zum Abschweifen.
Das fiel mir gerade bei diesem Thema ein, aus dem Code die fachliche Anforderungen herauslesen.
Das scheitert nämlich genau an dieser Stelle dann.
Gut, wir sind bei Minute 38.
Wir machen Schluss, glaube ich.
Das war sehr kurzweilig.
Ich danke dir.
Ja, hat mir auch wieder sehr viel Spaß bereitet.
Ja, wunderbar.
Ich hoffe, euch auch.
Wir bleiben am Thema dran.
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 sage es jetzt wahrscheinlich jede Folge bis zum 12.
November.
Meldet euch an, kommt dazu.
Wir freuen uns.
Macht's gut.
Ciao Ole.
Ciao, ciao.