AI Picks der 19. KW

Die 19. KW war wieder eine, in der man beim Lesen der Tech-Timeline öfter „aha“ und seltener „lol“ gedacht hat – was eine gute Mischung ist. Sechs Picks, von Agent-Frameworks über ein neues Notiz-Tool für Markdown-Liebhaber bis zu einer ETH-Studie, die den „Vibe Coder“-Hype mit Daten unterfüttert. Plus ein Reasoning-Modell aus Peking, das mit dem westlichen Frontier ungemütlich nahe liegt.

Flue – „Agent = Model + Harness“

Das Astro-Team hat mit Flue ein TypeScript-Framework rausgehauen, das nicht weniger sein will als die Infrastruktur für „die nächste Generation von Agenten“. Die These dahinter ist auf ihrer Landingpage charmant kompakt: Ein Agent ist nicht der Modellaufruf, sondern Modell plus Harness – also die Schicht aus Skills, Memory, Sandbox und Filesystem, die aus einem Chatbot ein Werkzeug macht, das planen, Dateien schreiben, Subagenten spawnen und Rollen annehmen kann. Genau dieser Stack macht Claude Code und Codex eben so brauchbar, und Flue will diesen Stack programmierbar machen.

Was im Code-Beispiel auf der Seite tatsächlich auffällt: das ist kein weiterer „LangChain-aber-anders“-SDK, sondern ein recht eigensinniger Versuch, Agenten als HTTP-Endpoints oder als CLI-Workflows zu deployen – Cloudflare Workers, GitHub Actions, Node, alles abgedeckt. Skills haben strukturierte Outputs, Sandboxes können Daytona-Container oder eingebaute virtuelle Filesysteme sein, und Sicherheits-Tokens bleiben über den env-Parameter draußen aus dem Modellkontext. Letzteres ist tatsächlich eine schöne Konstruktion.

Eine Kuriosität am Rande: Die Marketingseite verkauft Flue als „programmable TypeScript harness“, das GitHub-Repo sagt im Untertitel aber „Connect a full OpenCode session to your AI agents and CI workflows“ – also offenbar OpenCode unter der Haube, was so deutlich auf der Webseite gar nicht steht. Status: Experimental, 24 Stars beim Fetchen. Spannend genug, um es im Auge zu behalten, aber bevor ich da Production-Workflows draufbaue, warte ich auf ein Release ohne API-Wackler.

Tolaria – ein zweites Gehirn für die KI-Ära

Tolaria kommt von Luca Rossi (dem Autor von Refactoring) und ist im Kern ein lokaler Markdown-Notiz-Editor mit Block-Editor-Feel à la Notion, integriertem Git-Client und – das ist der eigentliche Pitch – eingebautem MCP-Server, damit Claude Code & Co. nativ mit dem Vault arbeiten können. Open Source, kostenlos, kein Account, auf GitHub.

Als Obsidian-Nutzer bin ich erstmal misstrauisch, weil die Welt der „Notion-Killer mit Markdown“ inzwischen hinreichend bevölkert ist. Trotzdem: die drei Achsen, an denen Tolaria sich positioniert, sind interessant und nicht deckungsgleich mit Obsidian.

Gegen Notion ist die Sache einfach: Notion liegt in der Cloud, Daten gehören Notion, Export ist ein Krampf, KI-Tools können bestenfalls über API ran. Tolaria liegt als reine Markdown-Dateien mit YAML-Frontmatter auf Deiner Platte – grep-bar, git-bar, jeder beliebige Editor kommt ran. Das ist die alte Plain-Text-Religion, und sie macht im Agenten-Zeitalter wieder besonders Sinn: ein Sprachmodell mit MCP-Zugriff arbeitet auf Files deutlich nüchterner als auf einer proprietären API.

Gegen Obsidian wird's schon nuancierter. Obsidian ist bereits Markdown auf Disk, hat Wikilinks, Plugins (inkl. Git-Plugin), und MCP-Anbindungen gibt es auch – nur eben über Plugins, nicht out of the Box – und vor allem ein echt leistungsstarkes CLI. Tolaria liefert das alles als Default mit (bis auf das CLI, glaube ich), und der Block-Editor schreibt nach eigener Aussage „clean Markdown“. Das könnte für Leute interessant sein, denen Obsidian zu Plugin-fummelig ist und denen das Notion-artige Schreibgefühl wichtiger ist als Obsidians Ökosystem.

Was ich noch nicht beurteilen kann, weil ich es nicht selbst getestet habe: wie sauber der Block-Editor Markdown wirklich rausschreibt (typischer Schmerzpunkt bei dieser Art Tool – Notion-Exports sind berüchtigt für ihren Markdown-Müll), und wie sich das Modell mit 9.000-Notes-Vaults schlägt. Solange beides nicht klar ist, bleibe ich bei Obsidian – aber Tolaria steht jetzt mit auf der Liste.

Karina Nguyens „Things I Learned at OpenAI“

Karina Nguyen war erst bei Anthropic, dann bei OpenAI und hat zum Abschied einen Reflexionspost auf ihrem Substack geschrieben. Das Format kennt man – ich-bin-jetzt-woanders-und-hier-meine-Lehren – aber ein paar Punkte daraus fand ich substanziell genug, sie hier herauszupicken.

Erstens: Evals sind unterschätzt. Nguyens These ist, dass das Erstellen einer guten Benchmark oft impactvoller ist als das Modell, das sie schlägt – weil eine gute Benchmark ein Schelling-Punkt wird, an dem sich das ganze Feld orientiert. Wer den Maßstab setzt, lenkt die Forschung. Klingt banal, ist aber in der hektischen Modell-Pressemitteilungs-Lage ein guter Reminder.

Zweitens: Post-Training ist nach ihrer Einschätzung die Frontier für die nächsten Jahre, vor allem für die schwer messbaren Sachen – Geschmack, Humor, kreatives Urteil, emotionale Intelligenz. Base-Modelle würden das zunehmend „können“; die Frage sei, wie man das aus ihnen herausholt. Wer schon mal versucht hat, einem Modell einen halbwegs erwachsenen Witz beizubringen, statt der bekannten KI-Glücksbärchen-Energie, wird das unterschreiben.

Drittens, und das ist der Punkt, den ich am ehrlichsten finde:

Model personality is a reflection of the people who trained it. This is more literal than most realize.

Wer sich fragt, warum Claude und ChatGPT so unterschiedlich klingen, obwohl beide auf vergleichbarer Tech laufen – da ist die Antwort.

Und schließlich, weniger fröhlich: Ihre Sorge ist, dass die gesellschaftlichen Schäden von AGI – psychologische Abhängigkeit, Verlust von Agency, Disempowerment – „closer than most people realize“ seien. Das ist der ungemütliche Teil, und sie sagt das nicht aus der Anti-KI-Ecke heraus, sondern als jemand, der genau diese Modelle mitgebaut hat. Liest sich entsprechend nicht wie das übliche Doom-Geschwafel.

Xiaomi MiMo-V2.5-Pro

Xiaomi hat MiMo-V2.5-Pro released und open-sourced – ein 1.02T-Parameter-MoE mit 42B aktiven Parametern, 1M-Token-Kontext, und Benchmarks, die laut Xiaomis eigener „MiMo Coding Bench“-Suite „closing the gap to Opus 4.6“ zeigen. Auf Hugging Face liegen Weights, Tokenizer und Modellkarte.

Was Xiaomi vorzeigt, sind keine kleinen Aufgaben: einen kompletten SysY-Compiler in Rust in 4,3 Stunden über 672 Tool Calls (perfekter Score gegen die Hidden-Test-Suite eines PKU-Compilerbau-Kurses), einen funktionierenden Video-Editor mit 8.192 Lines of Code in 11,5 Stunden über 1.868 Tool Calls. Token-Effizienz auf ClawEval angeblich 40–60 % besser als Opus 4.6, Gemini 3.1 Pro und GPT-5.4 bei vergleichbarer Capability.

Bevor man das jetzt aber als „China holt auf, Game Over für den Westen“ liest, ein paar Einordnungs-Dämpfer:

Erstens: Vergleichbarkeit. Xiaomi misst auf der eigenen MiMo Coding Bench. Das ist legitim als Aussage über die eigene Entwicklung, aber es ist eben dann doch „nur“ eine In-House-Bench. Eine unabhängige Drittevaluation auf etablierten Suiten – LiveCodeBench, SWE-bench Verified, was auch immer gerade als Standard gilt – steht aus.

Und vor allem: „Closing the gap“. Auf der eigenen Bench den Abstand zu verkleinern, ist ungefähr genau so aussagekräftig wie im eigenen Wohnzimmer Weltmeister zu werden.

Zweitens, und das ist der spannendere Punkt: Xiaomi tritt mit MiMo gar nicht primär gegen Anthropic oder OpenAI an, sondern gegen Alibabas Qwen und DeepSeek. Qwen3 ist im innerchinesischen Vergleich der Platzhirsch im Open-Weight-Segment und DeepSeek-V4 (das Xiaomi in seiner eigenen Benchmark-Tabelle als Vergleichsmodell hat) setzt regelmäßig die Latte für Reasoning. Die eigentliche Frage ist also nicht „kann MiMo mit Opus 4.6 mithalten“, sondern „kann MiMo Qwen vom chinesischen Open-Weight-Thron stoßen“. Und da ist die Antwort deutlich offener.

Drittens: Open Source unter „permissive license“ ist gut, die Modellkarte verweist auf SGLang und vLLM für Deployment, das ist alles sauber. Aber 1,02T Parameter sind 1,02T Parameter – das wird kein Hobbyist auf der heimischen RTX 5090 laufen lassen. Der praktische Nutzen für Solo-Entwickler ist begrenzt, der für mittelgroße Inferenz-Anbieter potenziell interessant.

Mein Fazit: Anschauen, im Auge behalten, aber bei der Pressemitteilungs-Choreografie nüchtern bleiben. Open-Weights-Modelle aus China werden in Zwölfwochen-Takten besser, und die meisten überleben ihren ersten Hype-Zyklus nicht.

ETH-Studie: Was Vibe Coding wirklich braucht

Die ETH Zürich hat eine Studie veröffentlicht, die endlich mal mit Daten beantwortet, was beim sogenannten Vibe Coding tatsächlich über Erfolg oder Misserfolg entscheidet. 100 Zürcher Studierende, drei Coding-Aufgaben mit KI-Agent, dazu Tests auf Informatikkenntnisse, Schreibfähigkeit und allgemeine kognitive Fähigkeiten. Veröffentlicht auf der CHI '26 in Barcelona (DOI).

Das Ergebnis ist erwartbar – und gleichzeitig wichtig, weil es die seit Monaten kursierende „Programmieren kann jetzt jeder“-Erzählung sauber zerlegt. Den größten Effekt auf Vibe-Coding-Erfolg haben die Informatikkenntnisse. Auch wenn die kognitiven Fähigkeiten herausgerechnet werden. Wer versteht, wie Apps gebaut sind, gibt einer KI bessere Anweisungen, plant gezielter, debuggt schneller. Klingt trivial, ist aber genau das Argument gegen die These, dass natürliche Sprache als Programmierschnittstelle die Domain-Expertise obsolet mache. Surprise: tut sie nicht.

Zweiter signifikanter Faktor: Schreibkompetenz. Wer klar und strukturiert formulieren kann, promptet besser. Auch hier: nicht überraschend, aber datentechnisch jetzt mal belegt.

Der wirklich interessante Befund kommt zum Schluss: Studierende, die im Alltag besonders oft Sprachmodelle nutzen, schnitten schlechter ab – beim Essay und beim Vibe Coding. Die Forscher selbst geben zu, dass die Korrelationsstudie keine Kausalität zeigt, und beide Richtungen plausibel sind: Entweder schwächt häufige LLM-Nutzung die eigene Ausdrucksfähigkeit, oder Leute mit schwächerer Ausdrucksfähigkeit greifen häufiger zu LLMs. Beides ist unbequem, beides verdient mehr Forschung.

Bonus-Befund aus einer parallelen Studie von Martin Vechev am gleichen Departement: Gängige KI-Agenten „korrigieren“ in über 70 % der Fälle Code, der gar keinen Fehler hat. Was den eigenen Eindruck bestätigt, dass Claude Code und Konsorten manchmal überzeugt einen Bug erfinden, nur um ihn dann zu fixen – ein Verhalten, das mit besserem Tooling und vor allem mit besseren Tests adressiert werden muss. Womit wir nahtlos beim nächsten Pick wären.

Eivind Kjosbakken: Claude Code mit automatisierten Tests aufbohren

Passend zum ETH-Befund hat Eivind Kjosbakken auf Towards Data Science einen pragmatischen Erfahrungsbericht geschrieben, wie man Claude Code (und andere Coding-Agenten) deutlich produktiver macht – mit einer einzigen Stellschraube: automatisierten Tests.

Die These ist nicht neu, aber sie ist richtig: Seitdem Coding-Agenten ordentlich Code schreiben können, ist nicht mehr das Schreiben der Bottleneck, sondern das Testen. Wenn der Agent seine eigenen Implementierungen testen kann, spart das Iterations-Loops. Drei Schritte: dem Agent die nötigen Permissions geben (in Claude Code via --dangerously-skip-permissions oder dem neuen Auto Mode), ihn explizit Tests schreiben und ausführen lassen, und sicherstellen, dass die Tests in Pre-Commit-Hooks oder CI laufen.

Sein zweiter Punkt finde ich persönlich noch wertvoller: für die Tests, die Du nicht automatisieren kannst, lass den Agent eine Checklisten-HTML-Seite generieren – mit Links zu den zu testenden Stellen, Erwartungswerten und Checkboxen. Klingt trivial, reduziert aber die Reibung beim manuellen Verifizieren erheblich, weil Du nicht jedes Mal selbst rekonstruieren musst, was Du jetzt wo prüfen sollst.

Eine kleine Warnung zum Artikel: Kjosbakken nennt seine Konkurrenzmodelle „Gemini“ und „Chachipetee“– letzteres ist offenbar ein launiger Spitzname für ChatGPT, der einmalig im Text auftaucht und nicht weiter erklärt wird. Inhaltlich tut das nichts zur Sache, ist aber ein leicht irritierender Stilbruch in einem ansonsten nüchternen Text.

Mein Take: Wer mit Claude Code arbeitet und noch keine Tests automatisiert vom Agent schreiben lässt, sollte das diese Woche ändern. Nicht wegen der Code-Qualität – die wird durch Tests selbstverständlich besser, aber das ist seit dreißig Jahren bekannt – sondern wegen der Feedback-Loop. Ein Agent, der seine eigenen Fehler im Loop fixt, ist deutlich angenehmer als einer, der jede Iteration auf Dein „OK“ wartet.