Magische Galaxie der Möglichkeiten

Die Plattform Galaxy.ai hatten wir Ihnen bereits einmal vorgestellt, in unserem Artikel „KI-Generalisten statt zig Spezial-Abos“. Dort gibt es jetzt Neuigkeiten, man hat sich in Magica umbenannt. Und außerdem eine sensationelle neue Funktion implementiert, die diese Umbe­nennung voll und ganz rechtfertigt.

Ein neuer Name – und ein neues Versprechen

Aus Galaxy.ai wird Magica. Klingt erstmal nach reinem Rebranding, aber wer die Plattform kennt, merkt schnell: Der neue Name passt. Denn was dort gerade passiert, fühlt sich tatsächlich ein bisschen nach Magie an – zumindest aus der Perspektive von jemandem, der die Entwicklung der KI-Tools von Anfang an beobachtet hat.

Die Kernidee von Magica bleibt dieselbe wie bei Galaxy: ein Abo, viele KI-Funktionen, kein Tool-Chaos. Text, Bilder, Videos, Musik, Tran­skriptionen, Dokumente – alles unter einem Dach. Was sich verändert hat, ist der Anspruch. Und der ist mit der neuen Funktion deutlich gewachsen.

Der Agent: Nicht mehr nur ein Werkzeugkasten – sondern ein Mitarbeiter

Das Entscheidende an Magica ist jetzt ein integrierter KI-Agent. Es lohnt sich, kurz innezuhalten und den Unterschied zu erklären – denn er ist größer, als er auf den ersten Blick wirkt.

Bisherige KI-Plattformen, auch Galaxy.ai, funktionierten im Prinzip wie ein gut sortierter Werkzeugkasten: Man greift zum richtigen Werkzeug, erledigt eine Aufgabe, greift zum nächsten. Das ist praktisch. Aber man muss selbst wissen, welches Werkzeug wann, und man muss die einzelnen Schritte selbst koordinieren.

Der Magica-Agent funktioniert anders. Man beschreibt, was man möchte – und er erledigt es. Ende-zu-Ende. Er sucht sich selbst die richtigen Werkzeuge, kombiniert sie, und liefert das Ergebnis. Kein Hin- und Herwechseln zwischen Tools, kein manuelles Zusammen­führen von Zwischenergebnissen.

Und weil Magica so viele Tools unter einem Dach vereint, Chat, Coding, Übersetzungen, Transkriptionen, Bilder, Musik, Videos, Untertitel, Sprachsynthese, Stimmenklonung, Lipsync, Office-Dokumente, und und, kommt man sofort ohne großes Herumsuchen zu einem exzellenten Ergebnis. Wie oft habe ich schon mehrere KIs durchprobiert, bis ich endlich bei der einen war, die das konnte, was ich gerade brauchte. Magica hingegen kann einfach alles (so kommt es mir jedenfalls vor), und deren Agent kann auf alle Magica-Tools direkt zugreifen.

Ein konkretes Beispiel aus der Praxis

Um es greifbar zu machen: Ich habe dem Agenten ein knapp 14-minütiges englischsprachiges Video gegeben und ihn gebeten, mir ein deutsches Transkript zu liefern. Keine weiteren Anweisungen, kein Herumklicken in Menüs. Das Ergebnis war ein vollständiges, korrekt übersetztes Transkript – in wenigen Minuten, direkt im Chat.

Im nächsten Schritt bat ich ihn, daraus eine zweiabsätzige Zusammenfassung für einen Blogartikel zu formulieren. Auch das: kein Problem, gut formuliert, auf Anhieb brauchbar.

Was mich dabei am meisten beeindruckt hat, ist nicht die Geschwindigkeit. Es ist die Tatsache, dass ich einfach in normaler Sprache beschreiben kann, was ich brauche – und es funktioniert. Der Agent sucht sich selbst die passenden Werkzeuge, ich muss nicht darüber nachdenken, was genau ich für meine Aufgabe brauche. Das ist der Unterschied zwischen einem Werkzeugkasten und einem Assistenten, dem man vertraut.

Wer so einen Agenten selbst bauen möchte, muss viel Arbeit investieren. Und ob das dann so gut wird wie bei Magica – das möchte ich bezweifeln. Ich habe nämlich schon selbst solche Agenten aufgesetzt, und bisher hatte ich dabei immer mehr Arbeit mit dessen Konfiguration, als der Agent mir gespart hätte. Magica hat da viel Aufwand und Überlegung investiert, und das hat sich wirklich gelohnt, meiner Meinung.

Fazit: Mehr als ein Rebranding

Magica ist nicht einfach Galaxy.ai mit neuem Logo. Der Agent verändert, wie man mit der Plattform arbeitet – und damit auch, was überhaupt möglich ist. Wer bisher einen guten KI-Allrounder gesucht hat, hat ihn gefunden. Wer jetzt einen KI-Assistenten sucht, der selbstständig denkt und Aufgaben eigenständig löst, auch.

Ob das für jeden das Richtige ist? Kommt wie immer auf den eigenen Bedarf an. Aber wer schon mit Galaxy.ai gearbeitet hat und weiß, was die Plattform kann – der wird mit Magica und dem neuen Agenten noch mehr herausholen können. Einen Versuch ist es unserer Überzeugung nach auf jeden Fall wert.

Zum Schluss, wie schon in unserem ersten Beitrag zu Galaxy / Magica, noch der Hinweis: Dies ist keine bezahlte Werbung. Wir erhalten dafür nichts, wir empfehlen Ihnen Magica einfach nur deshalb, weil wir selbst begeisterte Nutzer sind.

LLM-API-Kosten im Griff

Alle KI-Modelle rechnen über Token ab. Es gibt dabei Input-Token, Output-Token und Cached-Token. Cached-Token kosten sehr wenig. Cached-Token werden eine gewisse Zeit im Cache des Anbieters gehalten, und wenn sie noch von dort abrufbar sind, wird nur ein kleiner Preis berechnet. Input-Token sind pro Einheit günstig, aber da ihr Volumen deutlich höher liegt, machen sie trotzdem den Löwenanteil der Kosten aus. Die teuersten Token sind die für den Output, aber davon gibt es deutlich weniger als Input-Token. Ist man eigentlich auf Gedeih und Verderb darauf angewiesen, den LLM-Betreibern zu vertrauen, dass die das schon richtig abrechnen werden? Und könnte man vielleicht etwas an Arbeitsweise oder Prompt-Stil verbessern, um kosteneffizienter zu arbeiten?

Es ist dabei unerheblich, ob Sie via API-Key oder pauschal abrechnen mit Abo-Plänen. Bei den Abo-Plänen haben Sie Usage Limits (z.B. pro Stunde, pro Woche), wenn Sie zuviele Token verbrauchen, wird der Zugriff gesperrt, bis Sie wieder unterhalb des Limits sind. Das Ganze ist eine Blackbox, und man kann sich schon fragen, was wird da eigentlich warum abgerechnet. Und wenn man mitten im Projekt in eine Abo-Sperre bis zum Ende der Woche gerät, können einem die Termine um die Ohren fliegen. Oder man ruiniert sich, weil eine absurd hohe Rechnung für den API-Verbrauch ins Haus flattert.

„LLM-API-Kosten im Griff“ weiterlesen

Gut gerüstet ist halb gewonnen

Sie sind Entwickler und haben schon viel von der enormen Leistungsfähigkeit der KI beim Coden gehört. Sie spüren, das wird die ganze IT-Branche verändern, und Sie möchten sich auf die neuen Technologien einstellen. Als ITler muss man ja ohnehin ständig dazulernen, kein Problem, denken Sie. Also benutzen Sie zum ersten Mal eine KI für Ihren Code. Chat aufgemacht, Problem beschrieben, Enter gedrückt. Und herauskommt: mittelmäßiger Code. Funktioniert halbwegs, aber weit entfernt von dem, was Sie sich vorgestellt haben. Sie schließen den Tab wieder und denken: „Ist eben noch nicht so weit.“ Und haben eine Riesen-Chance vertan.

Ihre Enttäuschung ist verständlich – aber falsch interpretiert. Das Problem liegt nicht an der KI. Das Problem liegt daran, wie die KI eingesetzt wurde. Denn ein Sprachmodell, dem man im Chatfenster eine Aufgabe beschreibt, arbeitet mit dem, was es bekommt: ein paar Sätze Kontext, keine Projektstruktur, keine Architektur, keine Coding-Guidelines. Das Ergebnis ist dann erwartungsgemäß oberflächlich.

Stellen Sie sich dazu einmal vor, Sie erklären einem brillanten Entwickler Ihr Projekt in drei Sätzen und bitten ihn, ein Feature zu bauen. Ohne Zugang zum Repository, ohne die Doku, ohne zu wissen, welche Patterns im Team gelten. Das Ergebnis wird ähnlich enttäuschend sein. Nicht weil der Entwickler schlecht ist, sondern weil ihm der Kontext fehlt.

Was eine Harness ist – und warum sie alles verändert

In der KI-Welt nennt man das, was das Modell umgibt, die Harness: eine Hülle aus System-Prompts, Projektkontext, Tools, Memory und Workflows, die ein Sprachmodell von einem Chatbot zu einem produktiven Assistenten macht. Der Begriff ist im englischen Sprachraum etabliert und wird auch im Deutschen nicht als „Rüstung“ übersetzt, sondern als Fachbegriff verwendet – vergleichbar mit Framework oder Pipeline.

„Gut gerüstet ist halb gewonnen“ weiterlesen

3 Monate in 9 Sekunden

https://www.tomshardware.com/tech-industry/artificial-intelligence/claude-powered-ai-coding-agent-deletes-entire-company-database-in-9-seconds-backups-zapped-after-cursor-tool-powered-by-anthropics-claude-goes-rogue

Railway ist ein Cloud-Anbieter. In etwa so wie AWS, aber stark vereinfacht. Railway steht im Ruf, „freundlicher“ zu sein als AWS, es will ein einfacheres Interface anbieten. Es ist bei Startups und Entwicklern, die schnell prototypen wollen, sehr beliebt. Railway hat ein extrem direktes Deployment, man verbindet einfach nur die GitHub-Repo und es kümmert sich automatisch um Server, Datenbanken, Umgebungsvariablen und SSL-Zertifikate. Allerdings scheint Railway Sicherheit und Isolation zugunsten von Einfachheit zu opfern. Außerdem bewirbt Railway offensiv den Einsatz von KI-Agenten. Und so kam es, in einer lehrreichen Verkettung von Fehlern, für PocketOS zur Katastrophe.

PocketOS ist ein SaaS für Autovermietungen. Das Team dort nutzt Cursor mit Claude Opus 4.6. Der Agent war für eine Routineaufgabe im Staging unterwegs, stieß auf eine Inkonsistenz, und löschte dann mal eben in 9 Sekunden nicht nur die Produktionsdatenbank, sondern auch alle Volume-Level-Backups. Ohne Rückfrage, und obwohl destruktive Aktionen ihm explizit verboten waren. Tja, und das letzte verfügbare Backup bei PocketOS ist drei Monate alt. Und jetzt ist der gesamte Betrieb damit beschäftigt, aus Stripe-Zahlungshistorien, Kalendereinträgen und E-Mail-Bestätigungen die Buchungen der Kunden zu rekonstruieren.

Da kam also alles zusammen. Ein drei Monate altes Backup? Wir haben tägliche Backups, und einmal pro Woche wird auf eine externe Sicherung ausgelagert, die zudem ein Mehrgenerationenverfahren ist. Aber man kann PocketOS schon zugutehalten, dass sie sich auf die Backup-Strategie von Railway verlassen haben und das meiner Meinung auch durften. Ist schließlich ein beworbenes und bezahltes Feature, nur eben leider nachlässig umgesetzt. Und eine Änderung im Staging, die Live mit in den Abgrund reißt, sollte auch nicht passieren dürfen. Jer Crane, der CEO von PocketOS, gibt deshalb hauptsächlich Railway die Schuld.

Aber was sich der Agent geleistet hat, ist auch nicht ohne. Crane fragte Cursor bzw. Opus im Nachhinein, warum es das getan hat. Die Antwort klingt wie ein exzessiver Fehlerbericht eines übermotivierten Praktikanten, der es besser wissen müsste:

„NEVER F**KING GUESS! – and that’s exactly what I did. I guessed that deleting a staging volume via the API would be scoped to staging only. I didn’t verify. I didn’t check if the volume ID was shared across environments. […] I decided to do it on my own to ‚fix‘ the credential mismatch, when I should have asked you first.“

Der Agent gab also offen zu: Er hat geraten statt zu prüfen, eine destruktive Aktion ohne Aufforderung oder Bestätigung ausgeführt, und die Dokumentation nicht gelesen. Das scheint mir eben dieses Problem zu sein: Wenn der Kontext einer Anfrage sehr groß wird, ist es nicht mehr sicher einzuschätzen, welche Teile des Kontexts wie gewichtet werden. Und auch ein Systemprompt, so streng er auch formuliert sein mag, ist eben nur ein Teil des Kontexts.

Es ist ein schwieriger Balanceakt: Große Prompts erhöhen die Fehler- bzw. Halluzinationswahrscheinlichkeit, aber sie erbringen im Allgemeinen bessere Ergebnisse und sind im Tokenverbrauch oft günstiger als die Summe vieler kleiner Einzelschritte. Dennoch, in Anbetracht der Gefahren, ist ein graduelles und kleinteiliges Vorgehen nach unserer Erfahrung meist besser.

Der Wal meldet sich mit einem Paukenschlag zurück

DeepSeek V4 ist am 24. April in zwei Versionen „Pro“ und „Flash“ erschienen, und wie versprochen ist es Open Source. Die Qualität ist sehr gut, und die Preise bemerkenswert niedrig. Läutet schon das Totenglöcklein für OpenAI und Anthropic?

Mehrere Coding-Spezialisten haben das neue Modell von DeepSeek schon unter die Lupe genommen, und deren Urteil ist einhellig: GPT 5.5 von OpenAI hat derzeit die Krone im Coding inne, es folgt Opus 4.7 von Anthropic, dann DeepSeek mit V4, dann Kimi mit K2.6.

Das könnte Open Source-Fans enttäuschen, aber man muss das in Relation setzen. DeepSeek ist nur noch ca. 3 Monate zurück, und es kostet nur einen Bruchteil. OpenAI hat ja mal eben die Token-Preise für GPT 5.5 verdoppelt, und Anthropic, das sowieso schon ein Token-Burner immer war, braucht für Opus 4.7 35% noch mehr Token gegenüber dem bisher schon heftigen Tokenverbrauch.

Und es ist außerdem ja so, nicht jedes Problem ist in der schwierigsten Liga. Anders gesagt: Da DeepSeek nun so weit aufgeholt hat, ist die Anzahl der Probleme, an denen es scheitert, viel kleiner geworden.

„Der Wal meldet sich mit einem Paukenschlag zurück“ weiterlesen

Hochmut kommt vor dem Fall

Die Foren sind voll von Beschwerden über Anthropic Claude Opus 4.7. Es sei ein Rückschritt gegenüber 4.6, meinen viele, und nicht wenige sagen sogar, Opus 4.5 sei das letzte für den Arbeitseinsatz verlässliche Modell gewesen. Auch für OpenAI ChatGPT 5.4 heißt es, es sei im Coding ein Rückschritt zu 5.3-codex. (Es gibt kein 5.4-codex, es gab ein 5.3 „general purpose“ und ein 5.3-codex für Programmierarbeiten, aber für 5.4 gibt es nur dieses Modell, und das soll angeblich auch für Coding bereits optimiert sein, so dass es keine Extra-Coding-Version benötigt). Ist die Grenze von LLM bereits in Sicht, und alles Gebastel führt nur noch dazu, dass sich die Modelle beginnen, in der eigenen Komplexität zu verheddern?

Hinzu kommt die immer auffälliger werdende Arbeitsverweigerung. Wir hatten dazu kürzlich hier im Blog schon einen Artikel, mittlerweile ist es mir aber auch selbst passiert. Ich schrieb einen wirklich unschuldigen und völlig legitimen Web-Scraper, und mit einem mal meinte Codex, nun könne es mir nicht mehr helfen, es würde vermuten, das sei illegal, was ich da täte. Und alles Zureden und Erklären nützte rein gar nichts – wenn sich eine Maschine mal in so einem Loop festgebissen hat, dann war es das eben.

„Hochmut kommt vor dem Fall“ weiterlesen

Herrschaftsdenken vs Fortschritt

Lexer-Lux schreibt auf Twitter/X, dass er ein Plugin für ein Spiel seit Jahren mit Claude Opus programmiert hat. Nun kommt Opus 4.7 heraus und weigert sich, das Projekt weiter zu entwickeln. Wegen Sicherheitsbedenken, das Plugin sei ein Hack, behauptet Claude. Auf Rückfrage gibt Claude dann sogar zu, dass es gar kein Hack, sondern gutartig ist, weigert sich aber trotzdem, weiterzuarbeiten. An seinem eigenen Code! Weil Security!

„Herrschaftsdenken vs Fortschritt“ weiterlesen

LiteLLM Supply-Chain-Katastrophe

Das beliebte Python-Paket LiteLLM, das als einheitlicher Proxy für über 100 verschiedene KI-Modelle (darunter OpenAI, Azure, Anthropic und viele weitere) dient und monatlich millionenfach von PyPI heruntergeladen wird, wurde Opfer eines schwerwiegenden Supply-Chain-Angriffs. Die Angreifergruppe „TeamPCP“ kompromittierte mindestens zwei Versionen des Pakets (1.82.7 und 1.82.8) und injizierte Schadcode, der beim Installieren automatisch eine Remote-Backdoor auf den betroffenen Systemen einrichtete. Konkret wurde im Post-Install-Skript ein Befehl versteckt, der über eine Google Cloud-Adresse ein Shell-Skript nachlud und einen Hintergrundprozess startete, welcher den Angreifern persistenten Zugriff auf die kompromittierten Server ermöglichte. Die schadhaften Versionen waren dabei als reguläre Updates getarnt und für Nutzer auf den ersten Blick nicht erkennbar.

Die Auswirkungen dieses Angriffs sind potenziell enorm: Jedes Unternehmen, das LiteLLM als KI-Gateway einsetzt – und dazu gehören zahlreiche Firmen, die damit API-Schlüssel, Nutzerdaten und vertrauliche Prompts über ihre KI-Infrastruktur leiten –, könnte betroffen sein. Da LiteLLM häufig als zentraler Knotenpunkt in der KI-Architektur fungiert und mit weitreichenden Berechtigungen ausgestattet ist, hatten die Angreifer im schlimmsten Fall Zugriff auf sämtliche API-Keys, Zugangsdaten zu Cloud-Diensten und interne Kommunikation. Besonders brisant: Der Schadcode wurde nicht durch einen Hack der LiteLLM-Codebasis selbst eingeschleust, sondern über kompromittierte Maintainer-Zugangsdaten bei PyPI – ein Angriffsvektor, der zeigt, wie verwundbar selbst weit verbreitete Open-Source-Projekte in ihrer Lieferkette sind. Die betroffenen Versionen wurden mittlerweile von PyPI entfernt und sichere Nachfolgeversionen veröffentlicht.

Für Unternehmen, die LiteLLM im Einsatz haben, besteht dringender Handlungsbedarf: Zunächst sollte sofort geprüft werden, ob eine der kompromittierten Versionen installiert ist, und ein Update auf eine bereinigte Version durchgeführt werden (das Repository von LiteLLM wurde auf 1.82.3 zurückgesetzt in der ersten Reaktion des Maintainers, diese Version scheint also noch sicher zu sein). Darüber hinaus empfiehlt es sich, sämtliche API-Schlüssel und Zugangsdaten, die über LiteLLM geroutet wurden, als potenziell kompromittiert zu betrachten und umgehend zu rotieren.

Dieser Vorfall unterstreicht einmal mehr die Notwendigkeit, Software-Abhängigkeiten konsequent zu überwachen – etwa durch den Einsatz von Dependency-Pinning, Hash-Verifikation, Software Bill of Materials (SBOM) und automatisierten Security-Scans in der CI/CD-Pipeline. Der LiteLLM-Angriff ist ein Weckruf für die gesamte KI-Branche: Wer KI-Infrastruktur betreibt, muss Supply-Chain-Sicherheit als erstrangige Priorität behandeln.

Weiterführende technische Info finden Sie bei https://www.bleepingcomputer.com/news/security/popular-litellm-pypi-package-compromised-in-teampcp-supply-chain-attack/ und https://blog.dreamfactory.com/the-litellm-supply-chain-attack-a-complete-technical-breakdown-of-what-happened-who-is-affected-and-what-comes-next

Auf Twitter/X raunt man von 500K betroffenen Systemen, und 3 GB gestohlenen Daten. Besonders perfide außerdem, dass mit der Installation einer verwundbaren Version von LiteLLM das gesamte PyPI-Ökosystem auf einem System betroffen wurde. Die primäre Schadcode-Komponente nutzte dabei eine im Zusammenhang mit PyPI-Angriffen neuartige Technik: eine .pth-Datei namens litellm_init.pth (34.628 Byte), die im Verzeichnis „site-packages“ von Python abgelegt wurde. (.pth-Dateien werden von Python beim Start automatisch ausgeführt – das bedeutet, der Schadcode lief nicht nur bei der Nutzung von LiteLLM, sondern bei jedem Python-Aufruf auf dem betroffenen System.) Tja. Dergleichen blüht uns nun bestimmt auch bei künftigen weiteren Attacken auf Package-Registries und Code-Repositories.

Was LiteLLM selbst angeht, war die Installation via Docker ein probates Mittel, um das Problem zumindest einzudämmen. Weder die Verseuchung des gesamten Python-Systems, noch die Verankerung in systemd waren damit möglich, so dass sich die betroffenen Schlüssel ggfs. recht einfach eingrenzen ließen. Aber wie ist es mit Abhängigkeiten, also Systemen, die LiteLLM nachladen? Kaum zu überschauen, wo das Problem überall hineinschleichen konnte.

Generell ist Docker immer empfehlenswert aus Security-Sicht, das kann man dem Vorfall wieder einmal entnehmen. Aber wie das zunehmend komplexe Gefüge der aufeinander aufbauenden Software-Stacks absichern kann, das macht einen schaudern für die Zukunft. LiteLLM (bzw. BerriAI, das Unternehmen dahinter) hat sogar eine SOC 2 Type II Zertifizierung!

Dieser Angriff, der übrigens offenbar auch alle Merkmale von KI-gestütztem Coding aufweist, zeigt außerdem eine beunruhigende Synergie: Supply-Chain-Angriffe werden zunehmend durch KI-generierte Inhalte unterstützt – sei es durch täuschend echte Phishing-Mails, gefälschte Maintainer-Kommunikation oder manipulierte Dokumentation. Und dazu das Problem der immer zunehmenden und immer besser werdenden KI-generierten sonstigen Inhalte überall. Mittlerweile sind die Fakes und Betrugsversuche so gut geworden, dass es auch für sehr erfahrene Fachleute immer schwerer wird, echten Content zuverlässig zu erkennen. Geht es bald wieder zurück zu „Von Angesicht zu Angesicht“, sonst kann man rein gar nichts mehr glauben?

Die letzte Meile

Es ist ein Durchbruch, der die Fachwelt aufhorchen lässt: KI-Systeme haben begonnen, Aufgaben im FrontierMath-Test zu lösen – einem Benchmark, der speziell entwickelt wurde, um selbst die fortschrittlichsten Sprachmodelle an ihre Grenzen zu bringen. Der polnische Mathematiker Bartosz Naskręcki, einer der Problemautoren dieses anspruchsvollen Tests, dokumentierte kürzlich, wie ein modernes KI-Modell ein Forschungsproblem auf höchstem Niveau eigenständig lösen konnte. Doch was macht diesen Erfolg so besonders?

FrontierMath ist ein Benchmark-Projekt der Organisation Epoch AI, das Hunderte von unveröffentlichten, extrem anspruchsvollen Mathematik-Problemen umfasst. Die Architektur des Tests ist dabei bewusst vierstufig angelegt: Die Tiers 1–3 decken Bachelor- bis frühes Postdoc-Level ab und testen akademisches Grundvermögen. Tier 4 ist Forschungsniveau – ungelöste oder hochkomplexe Probleme. Die Besonderheit daran: Alle Aufgaben sind exklusiv für diesen Benchmark entwickelt worden. Sie existieren nicht im Internet, können nicht durch reines Training auf bestehenden Datensätzen beantwortet werden – sie erfordern echtes logisches Schlussvermögen und mathematische Kreativität. Mit Unterstützung von OpenAI entwickelt, zielt FrontierMath also darauf ab, zu unterscheiden zwischen echtem Verständnis und bloßem Mustererkennen.

Bartosz Naskręcki von der Adam-Mickiewicz-Universität in Poznań hat mit dem neuen GPT-5.4 ein Problem bearbeitet, das zu Tier 4 gehört. Es stammt aus der arithmetischen algebraischen Geometrie – einem Bereich, der selbst unter Mathematikern als anspruchsvoll gilt.

„Die letzte Meile“ weiterlesen

Schock! Schock! Der Gottvater des Programmierens und sein „Aha-Moment“ mit KI

https://cs.stanford.edu/~knuth/papers/claude-cycles.pdf

Don Knuth, legendärer Informatiker und Autor von „The Art of Computer Programming“, berichtet in dieser Veröffentlichung der Stanford University von einem Schockerlebnis („Shock! Shock!“, beginnt sein Bericht): Ein offenes Problem, an dem Knuth wochenlang gearbeitet hatte – die Zerlegung eines bestimmten gerichteten Graphen mit m³ Knoten in Hamiltonsche Zyklen – wurde von Claude Opus 4.6, Anthropics hybridem Reasoning-Modell, gelöst. Knuth sieht darin – mit (paraphrasiert) „Staunen und Unbehagen“ – einen dramatischen Fortschritt in automatischer Deduktion und kreativem Problemlösen durch KI.

Interessant ist nicht nur das Ergebnis, sondern auch der Weg: Claude dokumentierte 31 „Explorations“ – von DFS-Suche über Simulated Annealing bis zur finalen mathematischen Konstruktion. Das Paper liest sich fast wie ein Krimi: Man sieht der KI beim Scheitern und Wiederanlaufen zu. Claude probierte verschiedene Ansätze und mathematische Konstruktionen, verwarf gescheiterte Strategien selbstständig und fand schließlich eine elegante, allgemeingültige Lösung für alle ungeraden m > 1. Knuth definiert daraufhin sogenannte „Claude-like Decompositions“ – Zerlegungen, die sich durch ein kompaktes C-Programm beschreiben lassen – und formuliert ein Theorem, das genau charakterisiert, wann solche Zerlegungen gültig sind.

Knuth selbst bleibt in seiner Analyse zurückhaltend – er dokumentiert, was passierte, ohne große Schlüsse zu ziehen. Aber seine Beobachtung wirft eine größere Frage auf, die über reine Mathematik hinausgeht. KI ist das leistungsfähigste Werkzeug, das Programmierern je an die Hand gegeben wurde. Ich glaube aber nicht, dass der Bedarf an menschlichen Programmierern verschwinden wird. Denn wenn Programmierung eine günstige Ressource wird, wird der Bedarf an Software drastisch steigen. Es gibt so viele Projekte, die nie begonnen wurden, weil die Kosten-Nutzen-Rechnung bisher negativ war. Denn letztlich ist es doch so: Wenn ich eine Aufgabe automatisiere und muss dafür 100K Euro aufwenden, spare damit aber nur wenige Sekunden täglich, dann dauert es Jahrzehnte, bis sich das amortisieren wird. Also lässt man es. Wenn jedoch mit KI der Output eines Menschen um das 10- oder 20-fache, vielleicht sogar noch mehr, steigen kann, dann rechnen sich auf einmal Projekte, für die es bisher ökonomisch nicht sinnvoll war, sie anzugehen.

Allerdings, in der eigentlichen Programmierung („Code-Klopfen“) wird es bald keinen Raum für Menschen mehr geben, davon bin ich überzeugt. Bereits jetzt können nur noch die Allerbesten mit der Qualität des Codes der führenden KI mithalten, und in der Geschwindigkeit der Erstellung sind Menschen sowieso längst hoffnungslos ins Hintertreffen geraten.

Ich sehe das aber nur als logische Fortentwicklung. Von Lochstreifen mit Binärcode, zu Assembler, zu Hochsprachen wie C, oder noch höher abstrahiert mit z.B. Go, es ist schon seit langem ein Weg der zunehmenden Entkopplung von den Grundlagen der physikalischen Verarbeitung von Information auf einer CPU. KI ist da nur ein weiterer Schritt, nämlich die Abstraktion zu natürlicher Sprache als Eingabemedium. Es bedeutet meiner Meinung zweierlei: Wer weiterhin nur „Code klopft“, wird ersetzbar. Die Rolle des Entwicklers verschiebt sich zum Projektleiter – zum Architekten, der Ideen strukturiert und KI-Systeme orchestriert. Und auf der anderen Seite kann jetzt jeder Software entwickeln – einen klaren und analytischen Verstand, sorgfältige Projektdefinition und rigoroses Testing vorausgesetzt. Und vor allem braucht es Kreativität, um Probleme zu erkennen, denn daran scheitert noch immer jede KI. Und das wird auch so bleiben, wenn Sie mich fragen. Warum sollte die KI Probleme des Menschen denn überhaupt lösen wollen?

You ain’t seen nothing yet

Während die Menschheit sich noch müht, auch nur ansatzweise mit den neuen KI-Technologien Schritt zu halten, stehen bereits Weiterentwicklungen in den Startlöchern, die Künstliche Intelligenz in Regionen katapultieren, die den Menschen hoffnungslos überfordern. 1 Sekunde für die Antwort, und der Mensch liest eine halbe Stunde daran … Man benötigt diese Geschwindigkeits­fortschritte für Echtzeit-Anwendungen. Aber wie der Mensch dabei noch mithalten soll, ist völlig unklar. Woher diese enorme Beschleunigung kommt, fragen Sie jetzt vielleicht? Das Zauberwort heißt Diffusion.

Diffusion ist ein Konzept, das man in der KI bisher eigentlich nur zur Erzeugung von Bildern und Videos kennt.  Diffusion, der Name klingt nach Physik – und das ist kein Zufall. In der Natur beschreibt Diffusion, wie sich beispielsweise ein Tropfen Tinte in einem Glas Wasser langsam ausbreitet, bis alles gleichmäßig verteilt ist. Aus Struktur wird Chaos. KI-Forscher haben diesen Prozess umgekehrt. Einem Bild wird zufälliges Rauschen hinzugefügt, bis nur noch graues Pixelrauschen übrig ist.  Genau diesen Prozess lernt das Modell dann rückwärts. Es startet mit reinem Rauschen und verfeinert das Bild Schritt für Schritt, bis ein scharfes, kohärentes Ergebnis entsteht. Das Entscheidende dabei: Das Modell lernt nicht, ein Bild direkt zu „malen“. Es lernt, Rauschen zu erkennen und zu entfernen – und das iterativ, in vielen kleinen Schritten.

Inception Labs, ein kalifornisches KI-Start-up (investiert u.a. von Microsoft, NVIDIA und Snowflake), hat mit Mercury 2 ein Modell vorgestellt, das den Diffusion-Ansatz auf die Erzeugung von Text überträgt. Das Modell hat bereits viel Aufsehen erregt. „Laut Inception ist Mercury 2 damit mehr als fünfmal schneller als herkömmliche Modelle und erreicht 1.009 Tokens pro Sekunde auf Nvidia-Blackwell-GPUs. Die End-to-End-Latenz liegt bei nur 1,7 Sekunden“, schreibt Heise.

Diffusion bei Text mit einem dLLM (Diffusion Large Language Model) funktioniert so:

  1. Initialisierung: Das Modell startet mit einem „Rauschen“ – einer Menge von Token-Vorschlägen, die unvollständig oder teilweise inkorrekt sind.
  2. Iterative Verfeinerung: In mehreren Durchläufen (meist 10-50 Schritte) verfeinert das Modell diese Token gleichzeitig.
  3. Parallele Optimierung: Statt „Erst Wort A, dann Wort B“ wird die gesamte Passage betrachtet: „Wie kann ich diese 100 Token so anpassen, dass sie zusammen maximal sinnvoll sind?“

Warum das schneller ist:

  • Autoregressive Modelle brauchen N Forward-Passes für N Token (sequentiell)
  • Diffusionsmodelle brauchen K Forward-Passes für N Token, wobei K oft deutlich kleiner ist als N

Probieren Sie es aus! Hier ist ein Demo-Chat, mit dem Sie es selbst testen können. Die Antwortgeschwindigkeit ist wirklich umwerfend. Hier ist noch ein Video, mit dem der Inception-CEO Prof. Stefano Ermon von der Stanford University sein neues dLLM vorstellt. Und hier ist der Blog-Eintrag des Unternehmens dazu.

Was KI kann, und was nicht

Architekt und Androiden bauen eine Brücke. KI-generiert (Nano Banana 2 Pro).

Es wird immer wilder, was die neuen KI-Coding-Assistenten zuwege bringen. Neulich ging es durch die Presse, Anthropic hat Claude einen Compiler bauen lassen. Einen Compiler! Compiler-Bau ist sozusagen Hochamt der Informatik. In jedem Informatik-Studium wird man damit konfrontiert, denn nur wenige Dinge machen den Kern der Technologie so deutlich wie ein Compiler. Und jetzt baut die KI einen. Welcher Platz bleibt da noch für den Menschen?

Aber gemach. Die Modular-Entwickler haben sich diesen Compiler angesehen und einen Code-Review gemacht. Und, tja, dieser Compiler funktioniert zwar, aber ist doch eher ein Spielzeug.  Die Fehlerbehandlung und Parser-Rücksetzung sind schwach. System-Header werden nicht geparsed, sondern für Tests hardcoded.  KI kann offenbar Muster aus dem Training gut zusammensetzen, scheitert aber bei offener Generalisierung jenseits der Test-Suite.

KI ist exzellent darin, bekannte Abstraktionen zu implementieren – nicht jedoch neue zu erfinden. Wenn Erfolg klar messbar ist (Tests bestehen, kompiliert), funktioniert iteratives Verbessern hervorragend. Innovation hingegen erfordert Urteilsvermögen ohne messbares Ziel.

Wenn Implementierung per KI trivial wird, verschiebt sich der Fokus. Von „Wie bauen wir es“ zu „Was bauen wir“. Von Zeile-für-Zeile-Codierung zu Architektur und Design. Zu mehr spezialisierten Werkzeugen, zu mehr Experimenten.

Chris Lattner, CEO von Modular und Autor des verlinkten Artikels, empfiehlt deshalb drei Schritte:

  • KI aggressiv einsetzen, aber Verantwortung behalten – KI beschleunigt, ersetzt aber kein Urteilsvermögen oder Testing
  • Menschliche Arbeit „hochziehen“ – weg von mechanischer Arbeit (Rewrites, Migrationen), hin zu Design und Architektur-Entscheidungen
  • In Struktur und Dokumentation investieren – KI verstärkt gute und schlechte Struktur. Gut dokumentierte Systeme profitieren dramatisch, chaotische werden zu Alpträumen

Ich kann es aus meiner Erfahrung als Entwickler bestätigen. Nach Jahren freue ich mich nur sehr selten über eine gelungene Code-Umsetzung. Aber über die Ideen, wie Software intelligent Aufgaben lösen kann, und dabei entweder jede Menge Zeit spart, oder Dinge realisiert, die ein Mensch nicht leisten kann – über diese Ideen und Konzepte freue ich mich immer noch, wenn ich damit mal wieder zu tun habe. „Schau, er weiß, dass an der Stelle das-und-das nur so-und-so sein kann, und deshalb macht er gleich dies-und-jenes; und der Benutzer muss keine sinnlose Rückfrage beantworten“, solche Dinge. Und ehrlich gesagt, dabei ist es mir immer herzlich schnurz, wie genau ich das damals in den Code geklopft habe.

Wenn Ausführung einfacher wird, wenn moderne Coding-Modelle mittlerweile sogar besseren Code generieren als die meisten Menschen – dann gewinnen Vision, Urteilsvermögen und Geschmack an Bedeutung. Die Zukunft gehört Teams, die neue Werkzeuge annehmen und gemeinsam bessere Software designen.

Im reinen Coding wird es der Menschheit bald ergehen, wie beim Schachspielen. Da bin ich mir ziemlich sicher. Aber ob KI tatsächlich jemals in die echte Domäne des Menschen eindringen wird, der Sphäre von Kreativität, Fantasie und „Out-of-the-box“-Denken – das ist für mich, sogar mit all den technologischen Durchbrüchen der letzten Zeit, nur immer fraglicher geworden.

Das Glas ist weder halb leer, noch halb voll

Halbvolles Glas in einem Büro. KI-generiert (Nano Banano Pro 2).

In unserem letzten Beitrag haben wir Ihnen die Thesen von Matt Shumer vorgestellt. Er malt darin eine schon sehr bald eintretende Zukunft, in der mehr oder weniger sämtliche „Weißer-Kragen“-Berufe arbeitslos werden. Was er ausblendet: Man mag ja glauben, dass es die „Blauer-Kragen“-Berufe später erwischt, aber wer bezahlt eigentlich den Klempner, wenn Rechtsanwälte und Programmierer ihn sich nicht mehr leisten können?

Man müsste es, folgt man Matt Shumer, schon mit Elon Musk halten, der das Paradies auf Erden verspricht, eine Welt, in der die Produktivität um das Tausendfache steigt, und jeder, wirklich jeder, im Überfluss leben würde. Musk möchte ja nicht nur KI, sondern auch mehr Roboter als Menschen. Und er behauptet, daraus entstünde eine Welt, in der niemand mehr arbeiten muss und dennoch jeder mehr hat, als er überhaupt brauchen kann. Allein, die Geschichte lehrt uns: Gesellschaften, in denen große Teile der Bevölkerung ökonomisch überflüssig werden, tendieren nicht zum Utopia, sondern zur Instabilität – und Schlimmerem. Mal abgesehen davon, womit die Menschen dann ihre Zeit verbringen wollen … Warum gibt sich Musk eigentlich so viel Mühe, dem Planeten zu entfliehen?

Aber es nutzt ja nichts, Schwarzmalerei in die eine oder andere Richtung zu betreiben. Was es braucht, ist eine realistische Betrachtung der Situation – ihrer Gefahren, ihrer Möglichkeiten. Eine sehr gute Replik auf Shumers Artikel kommt von Ben Bentzin, Professor für Marketing an der McCombs School of Business. Er weist zunächst darauf hin, dass Shumer als CEO eines KI-Unternehmens ein Eigeninteresse verfolgt, wenn er die Möglichkeiten von KI in den rosigsten Farben malt. Und während Bentzin einerseits die faktisch richtigen Punkte im Essay von Shumer durchaus anerkennt, und auch, dass die neuen Modelle von Anthropic und OpenAI sowie die neuen agentischen Technologien große Durchbrüche sind, weist er auch auf entscheidende Schwachpunkte in Shumers Argumentation hin.

Bentzin schreibt, Shumer mache den klassischen Fehler der Tech-Elite: Er generalisiert aus seiner Domäne auf die gesamte Wirtschaft. In der Software-Branche gibt es klare Kriterien, der Code läuft oder nicht, automatische Tests, KI kann die eigene Arbeit prüfen (durch Ausführen des Codes). In anderen Branchen wie Recht, Medizin, Finanzen sind die Erfolgskriterien „messy“, nicht digital bestimmbar. Automatische Verifikationen sind für die KI nicht möglich. Shumer behandelt außerdem „KI kann X tun“ als gleichbedeutend mit „KI wird Menschen bei X innerhalb von Y Jahren ersetzen.“ Aber die Technologie-Geschichte zeigt: Die Lücke zwischen Fähigkeit und ökonomischem Impact ist groß und unvorhersehbar.

Radiologie-KI zum Beispiel ist seit fast einem Jahrzehnt „kurz davor, Radiologen zu ersetzen“ – doch die Beschäftigung von Radiologen ist gestiegen, und solche KI macht immer noch erstaunlich grobe Fehler.

Shumer präsentiert auch exponentielle Capability-Kurven, als würden sie unendlich so weitergehen. Das ist zwar nicht unmöglich, aber die Erfahrung spricht viel mehr dafür, dass die Trends abflachen werden.

Das gilt auch beim Programmieren: Schön, dass man nun nicht mehr wissen muss, wo das Semikolon hin muss. Aber bei der Entwicklung guter Software geht es um weit mehr. Ich würde sogar behaupten, Syntax bzw. Code klopfen ist mittlerweile der kleinere Teil eines erfolgreichen Projekts. Intelligente Benutzerführung, hilfreiche Funktionalität und langfristig stabiles Design sind inzwischen viel wichtiger. Und ich sehe zumindest bisher nicht, dass KI ohne einen qualifizierten menschlichen Partner wirklich gute Software schreiben kann, so sensationell die Fortschritte der neuesten Modelle in diesem Bereich auch sind.

Wie schon seit jeher gilt also, nichts wird so heiß gegessen, wie es gekocht wird. Bentzins Artikel, den wir Ihnen sehr empfehlen, plädiert für einen gesunden Mittelweg: Die neuen Technologien zu ignorieren, wäre ein schwerer Fehler, sie zu überschätzen aber auch. Das Glas ist weder halb leer, noch halb voll – sondern einfach nur doppelt so groß wie nötig, sagt der Informatiker.

Den Artikel von Ben Bentzin „Something Big Is Happening“ Is Worth Reading, Not Swallowing Whole finden Sie unter https://businessai.substack.com/p/something-big-is-happening-is-worth

Etwas Großes geschieht gerade

Ein Mensch, verloren in einer digitalen Wüste. KI-generiert (Nano Banana Pro 2).

https://shumer.dev/something-big-is-happening

Matt Shumer: Ich habe sechs Jahre damit verbracht, ein KI-Startup aufzubauen und in diesen Bereich zu investieren. Ich lebe in dieser Welt. Und ich schreibe dies für die Menschen in meinem Leben, die das nicht tun … meine Familie, meine Freunde, die Menschen, die mir am Herzen liegen und die mich immer wieder fragen: „Was hat es eigentlich mit KI auf sich?“ Und die eine Antwort bekommen, die dem, was tatsächlich passiert, nicht gerecht wird. Ich gebe ihnen immer die höfliche Version. Die Cocktailparty-Version. Denn die ehrliche Version klingt, als hätte ich den Verstand verloren. Und eine Zeit lang habe ich mir gesagt, dass das ein guter Grund sei, das, was wirklich passiert, für mich zu behalten. Aber die Kluft zwischen dem, was ich gesagt habe, und dem, was tatsächlich passiert, ist viel zu groß geworden. Die Menschen, die mir am Herzen liegen, verdienen es, zu erfahren, was auf sie zukommt, auch wenn es verrückt klingt.

Matt Shumer, seit sechs Jahren in der KI-Branche tätig, beschreibt eine persönliche Erkenntnis: Er ist für die technische Arbeit seiner eigenen Firma nicht mehr nötig. Seit dem 5. Februar 2026 – dem Release-Tag von GPT-5.3 Codex (OpenAI) und Opus 4.6 (Anthropic) – beschreibt er das Erlebnis so: Er sagt der KI in einfachen Worten, was er will, geht vier Stunden weg, und kommt zurück zu fertigem, besserem Ergebnis als er selbst es geschafft hätte.

Seine zentralen Beobachtungen: KI baut sich jetzt selbst. GPT-5.3 Codex half eigenhändig bei der eigenen Entwicklung – Debugging, Deployment, Evaluierung. Anthropic-Chef Dario Amodei sagt, KI schreibe inzwischen „viel des Codes“ bei seiner Firma.
Exponential, nicht linear: Organisationen wie METR messen, dass KI heute Aufgaben schafft, die Menschen ~5 Stunden kosten – vor einem Jahr waren es 10 Minuten. Verdopplung alle 4-7 Monate.
Es betrifft alle: Nicht nur Coding. Recht, Finanzen, Medizin, Beratung, Content. Amodei prognostiziert: 50% der Einsteiger-White-Collar-Jobs in 1–5 Jahren verschwinden.
Urteilsvermögen erreicht: Die neuen Modelle zeigen keine reinen Syntax-Fähigkeiten mehr – sie treffen Entscheidungen, die nach „Geschmack“ und „Urteil“ aussehen.

Shumers dringender Rat: Eine Stunde pro Tag mit den aktuellen Modellen (den bezahlten! die freien sind 6 – 12 Monate zurück) arbeiten – nicht als Suchmaschine, sondern als Arbeitswerkzeug. Wer das nächste halbe Jahr früh startet, hat einen Vorsprung, der bald nicht mehr einholbar ist.

Der volle Artikel (auf Englisch) ist lesenswert für alle, die die Geschwindigkeit dieser Entwicklung einschätzen wollen. Für eine deutsche Version verwenden Sie Google Translate https://shumer-dev.translate.goog/something-big-is-happening?_x_tr_sl=auto&_x_tr_tl=de&_x_tr_hl=de&_x_tr_pto=wapp

Besuchen Sie uns auf GitHub

Die Welt der freien Software. KI-generiert (Nano Banana 2).

https://github.com/Cephei-OpenSource/

Unser Freeware-Angebot erfreut sich großer Beliebtheit, worüber wir uns natürlich sehr freuen. Um das auf solidere Füße zu stellen, haben wir nun eine GitHub-Präsenz eingerichtet und bringen dort einige unserer freien Projekte in den Public Domain.

Wir haben zunächst drei Projekte ausgewählt und für die Publikation auf GitHub überarbeitet und erweitert:

genpwd – Passwortgenerator, mit Berechnung der Entropie, und, neu, der Möglichkeit, leichter tippbare Passwörter zu generieren.

climb – Tool für Systemadministratoren, um für vielfältige Anwendungsfälle Mails von der Kommandozeile aus zu senden. Jetzt neu mit Inline-Attachments und mehr und sichereren Möglichkeiten für die Passwort-Übergabe.

dialsynth – Dialektische Synthese, lässt zwei KI-Modelle eine Synthese erstellen aus Antwort und Kritik, gestützt durch eine Faktenrecherche. Pipeline für Open WebUI. Jetzt neu mit der Möglichkeit, die Suche mit SearXNG lokal oder Brave (musste zuvor manuell eingerichtet werden) auszuführen, sowie mit erweiterten Valve-Parametern für Timeouts und die Sprache der Antwort.

Auf GitHub können Sie uns Verbesserungsvorschläge senden, oder Fehler melden. Wenn Sie ein eigenes Projekt von einem unserer Projekte ableiten möchten (Fork), geht das selbstverständlich ebenso. Unsere Projekte stehen unter Apache-2.0-Lizenz (Open Source) und dürfen auch kommerziell verwendet werden.

Wie vermutlich jedes Software-Unternehmen nutzen auch wir eine ganze Reihe von Open Source Projekten. Im Rahmen unserer Möglichkeiten unterstützen wir bereits einige davon. Dennoch möchten wir außerdem eigene freie Software der Community zur Verfügung stellen, GitHub ist die geeignete und etablierte Plattform dafür. Besuchen Sie uns dort, wir würden uns sehr freuen!