Kategorie: Tool-Tests

„Qwen 3.8 unterstützt `reasoning_effort` offiziell. Damit lassen sich Denktiefe und Kosten steuern: `xhigh` (Standard) für komplexe Aufgaben mit gründlicher Analyse.“ So steht es in der Doku. Genau dieser Standard nervt alle, die das Modell lokal betreiben. Der Autor, ein erfahrener Entwickler und Tech-Blogger, hat es ausgiebig getestet. Sein Urteil: Die Voreinstellung ist unpraktisch und führt bei einfachsten Anfragen zu absurd langen Wartezeiten.

Bei 27B Parametern und einer 17GB-Datei leistet das Modell auf dem Laptop erstaunlich viel – sofern man die Denk-Effort-Stufe manuell senkt. Der Blogpost ist ein Erfahrungsbericht mit konkreten Messungen, Vergleichen und einer Prise Ironie. Gleich siehst du, warum Standardeinstellungen oft der größte Feind der Effizienz sind.

Ein Modell mit Potenzial und einer überraschenden Eigenheit

Qwen 3.8 27B ist die neueste Veröffentlichung aus dem Qwen-Labor von Alibaba. Sie ist unter Apache 2.0 lizenziert und frei nutzbar, auch kommerziell. Mit 27B Parametern bietet sie einen guten Mittelweg: groß genug für starke Leistungen, klein genug für einen leistungsfähigen Laptop. Der Autor testete auf einem M5 Max MacBook Pro und einem NVIDIA DGX Spark, jeweils mit LM Studio und einem Q4_K_M-Quant. Die von Qwen gemeldeten Benchmarks zeigen Verbesserungen gegenüber dem Vorgänger Qwen 3.6 27B und sogar gegenüber dem deutlich größeren, geschlossenen Qwen 3.7-Plus. Das ist vielversprechend.

Aber es gibt einen Haken, der sofort auffällt: Das Modell ist standardmäßig auf „extra hohe Denktiefe“ (xhigh) gestellt. Es denkt vor jeder Antwort lange nach – so lange, dass banale Aufforderungen zu langen Denkprozessen führen. Der Autor nennt das „wild überdenkend“. In seinen Tests führte diese Einstellung dazu, dass LM Studios Standard-Kontextlimit von 8.192 Tokens schon nach wenigen Prompts ausgeschöpft war – nicht durch die Antwort, sondern durch Reasoning-Tokens. Erst mit dem maximalen Kontext von 262.144 Tokens (den er frisch nachlud) konnte er sinnvoll arbeiten.

Das Problem mit dem Reasoning-Default: Überdenken als Standard

Ein Beispiel verdeutlicht das: Der Autor bat das Modell, ein SVG von einem Pelikan auf einem Fahrrad zu generieren. Mit xhigh dauerte das 21 Minuten und verbrauchte 22.276 Reasoning-Tokens für 3.223 Ausgabe-Tokens. Das Ergebnis war das beste Pelikan-SVG, das er je mit einem lokalen Modell gesehen hat – mit korrekt geformtem Rahmen, Beinen auf beiden Seiten des Rades und sogar einer Flügelhaltung am Lenker. Aber die Wartezeit ist inakzeptabel. „War das die 21 Minuten wert? Absolut nicht“, kommentiert er trocken.

Ohne Reasoning sieht es anders aus: Dieselbe Aufforderung erzeugte in 137 Sekunden ein SVG, das zwar erkennbar einen Pelikan zeigte, aber deutlich schlechter war: Der Rahmen war falsch geformt, die Füße verfehlten das Pedal, der Flügel berührte den Lenker nicht. Das Modell braucht die Denktiefe, um komplexe räumliche Anordnungen zu meistern. Nur wenn sie unnötig ist, wird der Aufwand zum Problem.

Der Test mit einem simplen „draw an svg of a circle“ zeigt die Absurdität. Auch hier startete Qwen im xhigh-Modus und begann eine lange Reflexion über die Ästhetik eines Kreises, über Farbpaletten, Animationen und geometrische Studien. Minuten später erschien ein wunderschönes, animiertes Kunstwerk – niemand hatte danach gefragt. Der Autor empfiehlt daher: Senke die Reasoning-Stufe auf „low“ oder schalte sie für Alltagsaufgaben ganz aus. Das Modell bleibt beeindruckend, aber du sparst Stunden an Wartezeit.

Wo das Modell glänzt: Vision und präzise Bounding Boxes

Trotz der Eigenheiten ist Qwen 3.8 27B in einem Bereich sehr stark: der Bildanalyse. Der Autor testete, wie gut das Modell Bounding Boxes um Objekte in Fotos zeichnet – eine typische Aufgabe für Vision-Modelle. Er lud ein Foto von zwei Pelikanen auf einem Felsen und bat um JSON-Koordinaten im 0–1000-Maßstab. Das Modell lieferte zwei Boxen, die exakt die Vögel umschlossen, inklusive der Beschriftung „pelicans“. Die Präzision war so gut, dass die Visualisierung direkt über dem Originalbild perfekt aussah.

Aber auch hier spielt die Reasoning-Einstellung eine Rolle. Der Autor nutzte für diese Aufgabe denselben xhigh-Modus, weil er schlicht vergessen hatte, ihn zu ändern. Das Modell baute nebenbei ein komplettes HTML-Tool zur Visualisierung der Boxen. Das Tool namens „bbox·lab“ war überladen – es enthielt sogar eine Demo-Szene mit selbst gezeichneten Pelikanen, weil der Autor im Prompt das Wort „pelicans“ verwendet hatte. Das Modell interpretierte das als Aufforderung für eine Beispielgrafik. Charmant, aber unnötig. Als der Autor dieselbe Aufgabe ohne Reasoning wiederholte, funktionierte das Tool zwar, aber die Boxen saßen falsch – das Modell hatte die Skalierung nicht richtig umgesetzt. Ein gutes Beispiel dafür, wie Denktiefe den Unterschied zwischen brauchbarem und fehlerhaftem Ergebnis macht.

Coding-Agent-Tauglichkeit: Ein lokaler Assistent mit Verstand

Entwickler fragen sich oft: Können lokale Modelle als Coding-Agenten arbeiten? Dafür braucht es drei Dinge: langen Kontext, zuverlässiges Tool-Calling und stabile Code-Generierung. Qwen 3.8 27B erfüllt diese Bedingungen auf dem Papier. Der Autor testete das Modell mit dem Open-Source-Agenten „Pi“, den er über LM Studio auf einem NVIDIA DGX Spark einrichtete. Die Konfiguration über eine Modelldatei in `~/.pi/agent/models.json` war simpel. Schon die erste Aufforderung, „how does auth work?“, beantwortete das Modell nach einigen Reasoning-Schritten und Dateizugriffen korrekt und verständlich.

Beeindruckender war der zweite Test: Der Autor wollte eine JSONL-Transkriptdatei in Markdown umwandeln lassen. Qwen schrieb nicht nur das Python-Skript, sondern führte es auch aus, testete es und veröffentlichte das Ergebnis – wieder mit dem selbst erstellten Tool. Das funktionierte reibungslos. Für ein 17GB-Modell auf lokaler Hardware ist das eine starke Leistung. Der Autor hebt hervor, dass Pi wegen seines kurzen System-Prompts ideal für solche Tests ist, weil es weniger Kontext für Systemanweisungen verbraucht und so mehr Platz für die eigentliche Arbeit lässt. Fazit: Als Coding-Agent ist Qwen 3.8 27B ernst zu nehmen.

Tempo und Optimierungsansätze: Die Frage nach der Geschwindigkeit

Der größte Kritikpunkt neben dem übermäßigen Denken ist die Geschwindigkeit. Der Autor maß 15 bis 30 Tokens pro Sekunde in LM Studio. Das ist nicht langsam im Vergleich zu vielen anderen lokalen Modellen, aber deutlich langsamer als gehostete APIs. Er zitiert Artificial Analysis, wonach Modelle wie OpenAI 5.6 Sol auf 74 Tokens pro Sekunde kommen und 5.6 Luna sogar auf 184. Für Web-Anwendungen mit wartenden Nutzern macht das den Unterschied zwischen angenehmem Arbeiten und Ungeduld.

Die Community hat seit der Freigabe vor zwei Tagen bereits Optimierungen entwickelt. Eine steckt direkt im Modell: Multi-Token-Prediction. Dabei sagt das Modell mehrere Tokens gleichzeitig voraus, statt nur eines. Das reduziert die Rechenschritte und kann die Token-Rate deutlich erhöhen. Der Autor nennt das einen der vielversprechendsten Ansätze, um das Modell auf Consumer-Hardware schneller zu machen. Die reale Leistung hängt natürlich auch von Hardware, Quantisierung und Prompt-Länge ab – aber es zeigt, dass lokale Inferenz noch nicht ausgereizt ist.

Fazit: Was bedeutet das für die Praxis?

Qwen 3.8 27B ist ein starkes Paket: ein gutes Vision-Modell, das als 17GB-Datei läuft, präzise Bounding Boxes liefert, Coding-Agenten antreibt und unter Apache 2.0 frei verfügbar ist. Die Standard-Reasoning-Einstellung xhigh ist jedoch ein Hindernis. Du solltest sie umgehen, bevor du dich über scheinbare Ineffizienz ärgerst. Setze die Denktiefe auf „low“ oder schalte sie für schnelle Aufgaben ab – dann zeigt das Modell ein Tempo, das für die meisten Anwendungen reicht, und eine Qualität, die mit deutlich größeren Modellen mithalten kann.

Die Erfahrungen des Autors zeigen dir, wie du das Beste herausholst: Nutze es für Vision-Aufgaben, wo die Genauigkeit der Bounding Boxes beeindruckt, und für Coding-Agenten, wo du mit etwas Geduld echte Ergebnisse bekommst. Die Geschwindigkeit bleibt ein Schwachpunkt, aber Multi-Token-Prediction und weitere Community-Optimierungen könnten das bald ändern. Für dich bedeutet das: Wer ein paar Minuten warten und die Einstellungen verstehen kann, bekommt ein Werkzeug, das auf einem durchschnittlichen Laptop mehr leistet als viele gehostete Dienste – und das kostenlos. Mit der richtigen Konfiguration ist es ein nützliches Werkzeug für lokale KI-Arbeit.

Quelle: simonwillison.net

Wie viel passiert wirklich, wenn LLM-Agenten eine Woche lang Backend-Entwicklung übernehmen? Ein Entwickler hat das gemessen, fünf Tage lang, in einer großen Rails-Codebasis. Er protokollierte jede Session, jeden Prompt und jeden Tool-Aufruf – und ließ anschließend weitere Agenten die Transkripte analysieren. Das Ergebnis zeigt, was autonome KI-Assistenten leisten können, wo sie scheitern und welche Rolle der Mensch dabei spielt.

Die Datenmenge ist groß: 2.200 Session-Dateien über vier verschiedene Tools, dazu 350 manuell getippte Prompts und 54 Stunden aktive Sessions. Aber die Zahlen erzählen nur einen Teil der Geschichte. Entscheidend ist, was in diesen Sessions tatsächlich passiert – und was die Agenten am Ende wirklich gefunden haben.

Die Messung einer ungewöhnlichen Arbeitswoche

Der Entwickler nutzte vier verschiedene Werkzeuge: Claude Code als Hauptagenten und Orchestrator, dazu Codex, Cursor und Amp für spezielle Aufgaben. Um die Wochenleistung zu erfassen, schrieb er ein Ruby-Skript, das alle Session-Protokolle durchging und für jede Session den Arbeitsordner, den Git-Branch, Start- und Endzeit, jeden eingegebenen Prompt, jeden Tool-Aufruf, Token-Zählungen und die auslösenden Skills extrahierte. Sechs weitere Agenten analysierten im Anschluss die Transkripte in der Tiefe.

Die Zahlen zeigen ein klares Ungleichgewicht: Von den 730 Claude-Code-Session-Dateien liefen nur 80 mit dem Entwickler an der Tastatur. Die restlichen 650 wurden von anderen Agenten gestartet – eine Kettenreaktion, die sich durch alle Tools zieht. Codex verzeichnete 2.100 Sessions, wovon 1.200 einem einzigen Workflow zuzuordnen sind: der automatisierten Überprüfung einzelner Diff-Blöcke, den sogenannten Hunks. Ein Hunk ist ein zusammenhängender Block geänderter Zeilen in einem Diff – und genau darauf war dieser Reviewer spezialisiert.

Auch die Token-Bilanz fällt auf: Für jedes getippte Token erzeugte das System durchschnittlich 1.500 Token Output. Der Median-Prompt war nur 83 Zeichen lang, fast die Hälfte aller Prompts unter 80 Zeichen. Statt langer Anweisungen verließ sich der Entwickler auf ein eingespieltes Setup aus Projektinstruktionen, Skills, MCPs und Kontextdateien – und gab dann kurze Befehle wie „retry“, „apply“ oder „push with lease“. Der Aufwand pro Prompt blieb über die Woche konstant, aber die Wirkung wuchs: Am Montag startete ein Prompt 7 Prozent der Machine-Outputs, am Donnerstag bereits 44 Prozent.

Vier Werkzeuge, vier Arbeitsweisen

Jedes Tool entwickelte eine eigene Persönlichkeit. Claude Code diente als Orchesterdirigent: Es startete Sub-Agenten, koordinierte Panels und führte die Fäden zusammen. Codex übernahm die Rolle des akribischen Prüfers – 946 seiner Sessions begannen mit der Anweisung, als adversärer, hunk-fokussierter Reviewer zu arbeiten. Cursor wiederum war überwiegend mit Lesen beschäftigt: 1.014 Datei-Lesevorgänge und 951 Suchvorgänge stehen nur 149 Edits gegenüber. Das entsprach seiner Funktion als einer der schnellsten Panel-Reviewer – mit einer Medianlaufzeit von 283 Sekunden gegenüber 739 Sekunden bei Claude. Amp blieb weitgehend unsichtbar, da seine Sub-Agenten nicht einsehbar waren.

Diese Unterschiede sind kein Zufall. Der Entwickler setzte Claude Code als Orchestrator ein, weil es die umfassendste Kontrolle über Sub-Agenten bietet. Codex wurde hauptsächlich als automatischer Reviewer für einzelne Diff-Änderungen eingesetzt, Cursor als schneller Zweitmeinung-Geber, und Amp ergänzte das Feld, ohne dass eine direkte Interaktion nötig war. Die Verteilung zeigt, wie LLM-Agenten nicht als monolithische Einheit arbeiten, sondern als spezialisierte Werkzeuge, die unterschiedliche Aufgaben übernehmen.

Wo die Agenten wirklich fanden – echte Defekte

Die eigentliche Frage ist: Was haben die Agenten entdeckt? Der Entwickler besprach 19 Merge-Requests – eigene und fremde. In 16 Panel-Durchläufen, bei denen vier Tools unabhängig dieselbe Änderung prüften, entstanden 17 Berichte. Elf Mal lautete das Urteil „Request changes“, fünf Mal „Approve with nits“. Insgesamt wurden 44 Kommentare an 10 Merge-Requests platziert, davon 56 Befunde mit Übereinstimmung von mindestens zwei Tools und 116 Einzelbefunde, die einzeln durchgesehen werden mussten.

Unter den echten Funden waren einige schwerwiegende Fehler. Ein Betragsverlust von einem Cent entstand, weil eine Steuerberechnung auf ganze Pence abrundete – was ein schriftliches Akzeptanzkriterium verletzte. Zwei Tools fanden das Kriterienproblem, ein drittes entdeckte die zugrunde liegende Floating-Point-Ungenauigkeit und reproduzierte sie. Eine Datenbank-Migration verzichtete auf einen Statement-Timeout-Schutz, obwohl dieselbe Migration in der Produktion bereits drei Wochen zuvor gescheitert war – der Fix war auf einem Pre-Production-Zweig gemerged, aber nie in den Hauptzweig übernommen worden. Genau dieser Befund enthüllte, dass 54 Commits auf dem Pre-Production-Zweig fehlten, darunter drei echte Produktions-Fixes.

Ein weiterer Fund betraf eine versteckte Änderung: Ein One-Time-Passwort-Bypass-Wert wurde in einem Commit zu einem anderen Thema manipuliert – das hatte die Pipeline rot gemacht. Alle vier Tools fanden diesen Fehler. Dazu kam ein Lookup-Problem: Wenn der erste übereinstimmende Datensatz ungültig war, gab der Dienst diesen zurück und ignorierte spätere gültige Datensätze. Der Entwickler maß die betroffene Population – einige hundert Fälle, bei einem Drittel mit gültigem Folge-Datensatz – bevor er entschied, das zu beheben.

Besonders spannend war ein Test, der nicht fehlschlagen konnte: Ein Regressionstest sollte ein bestimmtes Verhalten absichern, aber seine Fixture schrieb denselben Wert in beide verglichenen Felder. Eine Implementierung, die einfach nur den Eingabewert zurückgab, würde alle positiven Beispiele bestehen. Eine Test-Quality-Linse fand das bei einer Kollegen-Änderung; die Lösung war, die Fixture so anzupassen, dass die beiden Werte unterschiedlich wurden. Solche Befunde zeigen, dass LLM-Agenten nicht nur Code, sondern auch Testqualität prüfen können – wenn sie darauf spezialisiert sind.

Das Rauschen: Wenn die Hälfte der Meldungen falsch ist

So nützlich die echten Funde sind, so ernüchternd ist die Fehlerquote. Der Per-Hunk-Reviewer produzierte in drei Läufen 59 Kandidaten-Befunde – aber nur 17 wurden bestätigt, 42 widerlegt. Das entspricht einer Fehlerrate von 71 Prozent. Der schlimmste Lauf verschlang 133 Agenten und etwa 50 Minuten, um nur vier Befunde mit niedriger Schwere aus 26 Kandidaten zu liefern. Diese Widerlegungen waren nicht oberflächlich: Jeder einzelne wurde von einem separaten Agenten durchgeführt, der den echten Quellcode las und versuchte, die Behauptung zu widerlegen. Ohne diesen Schritt wäre das Ergebnis unbrauchbar, aber er kostet Zeit und Aufwand.

Ein weiteres Problem: Die Übereinstimmung zweier Tools ist kein Beweis für Richtigkeit. Auf einem Merge-Request meldeten zwei verschiedene Tools unabhängig voneinander denselben schwerwiegenden Befund mit korrekten Zeilenangaben. Doch beide lasen einen Worktree, der acht Commits veraltet war. Die zitierte Konstante war bereits absichtlich gelöscht worden – eine Entscheidung, die dokumentiert und überprüft war. Hätte der Entwickler dem Befund vertraut, hätte er gelöschten Code wieder eingeführt und fünf geschlossene Review-Threads wieder geöffnet. Der Grund war offensichtlich: Der Entwickler hatte in nur 5 von 14 Läufen eine aktuelle Zusammenfassung des Ziel-Branch-Zustands geliefert.

Umgekehrt ist Schweigen kein Zeichen von Zustimmung. In einem Review meldeten zwei Tools nichts, während die anderen beiden echte Probleme fanden – alle mit dem Muster „Der Code tut nicht, was die Beschreibung sagt“. Ein Tool, das die Beschreibung nicht gelesen hat, kann solche Diskrepanzen nicht erkennen. Die Panel-Übereinstimmung war also nur eine scheinbare: Es waren zwei Tools, die unterschiedliche Fragen beantworteten.

Am schwerwiegendsten war ein Fall, den das gesamte Panel verpasste. Eine Änderung stützte sich auf Zeilen aus einer Tabelle, um eine historische Tatsache zu etablieren. Aber ein nächtlicher Scheduled Job löscht genau diese Zeilen permanent, sobald sie ablaufen. Für abgelaufene Datensätze war die Tatsache also nicht wiederherstellbar – und der Test zu diesem Fall lief grün, weil während des Tests nichts gelöscht wurde. Keiner der acht Reviewer oder Linsen fand das. Ein späterer separater Durchgang deckte es auf. Die Ursache lag in einer fehlenden Frage: Jeder Reviewer argumentierte vom Schema aus, aber keiner fragte „Was schreibt oder löscht sonst noch in diese Tabelle?“. Der Fall zeigt, dass LLM-Agenten systematische Denkmuster übersehen, die einem erfahrenen Menschen sofort auffallen.

Der Mensch als Filter: Entscheiden statt nur abnicken

Was bleibt also für den Menschen zu tun? Der Entwickler formuliert es klar: Die Tools produzieren Kandidaten, aber er entscheidet. Er las jeden einzelnen Kommentar, bevor er gepostet wurde – in elf von elf Fällen gab seine Standardinstruktion vor: „In einfachem technischem Englisch, sag mir die Kommentare, die du posten willst, pro Datei und pro Zeile.“ Er überstimmte auch Befunde: Er behielt einen Kommentar, den ein Reviewer löschen wollte, weil er die nächste Entwicklung vor einer bewusst ausgeschlossenen Datensammlung bewahrte. Er lehnte ein Refactoring ab, das der Reviewer bereits angewendet hatte, weil es eine lesbare Sequenz in zwei undurchsichtige Methoden komprimierte.

Diese Übersteuerungen sind kein Zeichen von Sturheit, sondern von Urteilsvermögen. Der Entwickler kannte den Codebase-Kontext, die Review-Historie und die fachlichen Anforderungen – Wissen, das die Agenten nicht haben. Seine Rolle war nicht die eines Tippgebers, sondern eines Qualitätsgatters. Das zeigt sich auch in seinen eigenen Beiträgen: Er schrieb kurze Prompts, aber er baute ein System aus Skills, Instruktionen und Kontext, das den Agenten die Arbeit ermöglichte. Am Donnerstag, als die Maschinen-Anteile am Output 44 Prozent erreichten, blieb seine Tipparbeit konstant – das System war eingespielt.

Was du daraus für deinen Workflow mitnehmen kannst

Die Erfahrung lässt sich in konkrete Handlungsempfehlungen übersetzen. Erstens: Kontext liefern, bevor du Agenten losschickst. Der veraltete Worktree-Vorfall zeigt, dass eine aktuelle Zusammenfassung des Ziel-Branch-Zustands essenziell ist. Zweitens: Plane Rauschen ein. Eine Fehlerrate von 71 Prozent bedeutet, dass du Zeit für die Sichtung von Befunden einplanen musst – und dass die Widerlegung durch separate Agenten ein notwendiger Schritt ist, auch wenn er teuer ist. Drittens: Überprüfe Tests mit Mutationsanalyse. Der Entwickler bestätigte vor jedem Commit, dass die wichtigen Tests scheitern würden, wenn der Code gebrochen wird – das beweist, dass sie den behaupteten Fehler tatsächlich erkennen können.

Viertens: Verlasse dich nie auf Übereinstimmung oder Schweigen der Werkzeuge. Zwei übereinstimmende Tools können beide falsch liegen, wenn sie den gleichen veralteten Kontext haben. Und zwei schweigende Tools können einfach nur eine andere Frage beantworten. Fünftens: Lies jeden Kommentar, den ein Agent generiert, bevor du ihn postest – und habe den Mut, Befunde zu verwerfen. Die eigene Erfahrung und das Verständnis der Codebase sind nicht durch Automatisierung ersetzbar, sie bleiben das Entscheidungswerkzeug.

LLM-Agenten sind wie ein hochmotivierter, aber ungestümer Praktikant: Sie liefern viele Ideen, aber die Hälfte davon ist Unsinn. Du brauchst einen klaren Filter, eine gute Einarbeitung und die Bereitschaft, Nein zu sagen. Die Woche des Entwicklers zeigt, dass die Automatisierung funktioniert – aber nur, wenn der Mensch im Kreislauf bleibt und die Verantwortung trägt. Die Werkzeuge sind da, um dir Arbeit abzunehmen, nicht um sie zu ersetzen. Und das ist vielleicht die wichtigste Erkenntnis: Die Zukunft des Codes gehört nicht den Agenten, sondern den Entwicklern, die wissen, wie man sie einsetzt.

Quelle: allaboutcoding.ghinda.com

„AI removed the speed limit“ – mit diesem Satz beschreibt ein vielbeachteter Blogpost die aktuelle Entwicklung in der Softwareentwicklung. Gemeint ist nicht, dass jetzt alles schneller fertig wird und wir alle mehr Freizeit haben. Im Gegenteil: KI-gestützte Code-Erstellung gefährdet die Qualität ganzer Codebasen, weil die Geschwindigkeit des Erzeugens die Fähigkeit des Verstehens übersteigt. Das klingt provokant, spiegelt aber viele aktuelle Erfahrungen in Entwicklerteams wider.

Arbeitest du in einem Team, das KI-Tools wie Copilot, Claude oder ähnliche Agenten einsetzt, kennst du das vielleicht: Pull Requests werden größer, Review-Prozesse dauern länger, und die Entscheidungen hinter dem Code sind oft nicht mehr nachvollziehbar. Der Autor beschreibt diese Entwicklung anhand eines fiktiven, aber realistischen Beispiels aus dem Jahr 2026 – und zeigt, warum dies kein temporäres Problem ist, sondern strukturelle Auswirkungen auf die Rollen von Entwicklern haben wird.

Das Szenario 2026: Wenn KI die Code-Erstellung beschleunigt

Das Bild, das der Autor malt, dürfte vielen bekannt vorkommen: Ein Entwickler öffnet an einem Montagmorgen sieben Pull Requests, die seit Freitag eingegangen sind. Früher war das die Menge nach einem zweiwöchigen Urlaub. Jetzt passiert das über ein Wochenende. Die erste PR umfasst 25.000 Zeilen Code, begleitet von einer KI-generierten Beschreibung, die vage klingt und keine wirkliche Erklärung liefert. Auf Nachfrage verweist der Kollege auf ein Gespräch mit einem LLM – ein Chatverlauf, in dem die Architekturentscheidung irgendwo zwischen 15 Änderungsvorschlägen begraben liegt.

Das beschriebene Phänomen beobachten viele Teams bereits: Die Werkzeuge ermöglichen enorme Produktivitätssteigerung, aber ohne tiefes Verständnis des Kontexts entsteht Code, der funktioniert, den aber niemand durchschaut. Der Autor vergleicht das mit einem Luxusauto auf Kredit: Man sieht den schönen Wagen, aber die Schulden – die technischen Schulden – sind unsichtbar. Während man die monatliche Rate zahlt, türmen sich die Zinsen auf.

Die Situation führt zu einer paradoxen Entwicklung: Das Team produziert mehr, aber das System wird zunehmend unwartbar. Ein einfacher Bug lässt sich nicht mehr anhand von Logik, sondern nur durch erneutes Fragen an die KI beheben. Der Autor erzählt von einem Feature, bei dem niemand mehr weiß, woher die Daten kommen. Der Entwickler, der es gebaut hat, schlägt vor, einfach die KI zu fragen. Das Problem: Die KI gibt Antworten, die selbstsicher klingen, aber nicht verifiziert sind.

Technische Schulden auf Kredit: Die unsichtbare Gefahr

Technische Schulden sind nicht per se schlecht, betont der Autor. Entscheidend ist, dass man sie bewusst eingeht und weiß, dass es sich um einen Kompromiss handelt. Doch mit der Geschwindigkeit, die KI-generierter Code ermöglicht, entstehen Schulden unkontrolliert. Ein Entwickler kann 20.000 Zeilen an einem Nachmittag erzeugen – aber die Zeit, diese Zeilen zu verstehen, ist nicht mitgewachsen. Die Folge: Entscheidungen basieren auf vagen Annahmen, und die Auswirkungen zeigen sich erst Monate später.

Besonders tückisch sind Datenmodell-Änderungen. Wenn ein LLM in zehn Minuten ein paar Tabellen und Spalten zur Datenbank hinzufügt, ist das schnell erledigt. Aber sobald diese Tabellen mit echten Daten gefüllt sind, lässt sich das nicht einfach rückgängig machen. Man braucht Migrationspläne, muss auf laufende Systeme achten und Risiken absichern. Während man also versucht, einen Fehler zu beheben, kommen fünf neue PRs dazu – und der Berg wächst.

Das betrifft nicht nur unerfahrene Entwickler. Auch erfahrene Ingenieure geraten in den Sog der Beschleunigung. Die Verlockung, einfach mal schnell etwas ausprobieren zu lassen, ist groß. Aber die Verantwortung für die Entscheidung bleibt beim Menschen – und wenn er die Entscheidung nicht nachvollziehen kann, dann wäre es besser, sie nicht zu treffen. Genau diese Reflexion geht in der Routine des täglichen Arbeitens verloren.

Gute und schlechte Ingenieure: Die Schere öffnet sich

Die KI vergrößert die Lücke zwischen guten und schlechten Entwicklern. Vorher gab es eine natürliche Begrenzung: Ein schlechter Entwickler konnte vielleicht viel Code schreiben, aber nicht zu viel davon war ein echtes Problem, weil er Zeit brauchte. Heute kann er mit Hilfe von KI in einer Woche so viel produzieren wie früher in einem Jahr – mit entsprechend mehr Gelegenheiten, Unsinn zu verzapfen. Der Schaden, den ein einzelner unkritischer Entwickler anrichten kann, ist heute ungleich größer.

Gleichzeitig werden die guten Entwickler wertvoller, weil sie die KI als Werkzeug nutzen, ohne die Kontrolle zu verlieren. Sie können die Outputs bewerten, fundierte Entscheidungen treffen und die Architektur im Blick behalten. Diese Fähigkeit, das Gesamtbild zu verstehen und Verantwortung zu übernehmen, wird zum entscheidenden Differenzierungsmerkmal. Die hohen Gehälter in Tech-Zentren wie London oder San Francisco sind ein Indikator: Unternehmen zahlen nicht für die reine Umsetzung, sondern für Entscheidungskompetenz.

Das hat Konsequenzen für den Arbeitsmarkt. Der Autor prognostiziert, dass die Gehaltsspreizung weiter zunehmen wird: Die besten Ingenieure werden noch besser bezahlt, weil sie mit KI-Unterstützung immense Produktivität entfalten und gleichzeitig für Stabilität sorgen. Diejenigen, die nur implementieren, ohne zu verstehen, werden ersetzbar – nicht durch bessere KI, sondern durch andere, die die KI besser beherrschen. Die Mittelschicht, die früher durchschnittliche Leistung erbrachte, wird ausgedünnt.

Warum jemand das Gesamtbild verstehen muss

Im Zentrum des Artikels steht die These: „Jemand muss wissen, was gerade passiert.“ Gemeint ist, dass in jedem Projekt eine Person existieren muss, die die Zusammenhänge überblickt – nicht jede Codezeile kennt, aber die Architektur, die Datenflüsse und die Abhängigkeiten. In der Vergangenheit war das der Senior-/Lead-Entwickler. Heute stellt sich die Frage, wie diese Rolle unter den Bedingungen der KI-gestützten Entwicklung ausgeübt werden kann.

Der Autor schildert die Situation, in der ein Entwickler auf die Frage nach der Datenquelle einfach einen Link zu einem Claude-Chatverlauf schickt. Das ist ehrlich, aber auch ein Zeichen dafür, dass er selbst nicht mehr weiß, warum das System so funktioniert, wie es funktioniert. Genau da liegt das Problem: Wenn niemand mehr das Warum kennt, dann gibt es auch niemanden, der erklären kann, warum eine Änderung nötig ist oder welche Auswirkungen sie haben wird. Die Wartbarkeit leidet massiv.

Das Verständnis des Kontexts ist eine nicht delegierbare menschliche Fähigkeit. Man kann die KI bitten, einen Code zu erklären, aber man kann ihr nicht die Verantwortung für die Entscheidung übertragen, ob diese Lösung richtig ist. Diese Verantwortung bleibt beim Menschen – und diejenigen, die sie übernehmen, werden unverzichtbar. Die anderen werden zu reinen Ausführungsgehilfen degradiert – mit deutlich geringerer Wertschätzung und geringerem Gehalt.

Über Software hinaus: Der Trend in der Wissensarbeit

Die Beobachtungen des Autors beschränken sich nicht auf die Softwareentwicklung. Er sieht eine ähnliche Dynamik in anderen Bereichen der Wissensarbeit: überall dort, wo KI eingesetzt wird, um Ergebnisse zu erzeugen, wird die Fähigkeit, diese Ergebnisse zu beurteilen, zum kritischen Faktor. Ob in der Rechtsberatung, im Finanzwesen oder in der medizinischen Diagnostik – überall entsteht die Spaltung zwischen denen, die KI nutzen, um bessere Entscheidungen zu treffen, und denen, die sich von der KI treiben lassen.

Früher konnte ein gewisses Maß an Inkompetenz toleriert werden, weil die Geschwindigkeit der Arbeit limitiert war. Ein schlechter Analyst konnte nicht allzu viel Schaden anrichten, wenn er nur wenige Berichte pro Monat erstellen konnte. Heute kann er hunderte generieren lassen – und wenn niemand die Qualität prüft, entstehen falsche Entscheidungen, die teuer werden. Die KI verstärkt also nicht nur positive Effekte, sondern auch negative.

Das führt zu einer radikalen Konsequenz: Die Anforderungen an diejenigen, die in Wissensberufen arbeiten wollen, werden steigen. Es reicht nicht mehr, die Werkzeuge zu bedienen; man muss die dahinterliegenden Prinzipien verstehen und kritisch hinterfragen können. Der Autor formuliert es klar: „Wenn dir das Urteilsvermögen fehlt, um die Empfehlung des LLM zu bewerten, dann löst das Nachfragen mehr Urteilsvermögen nicht das Problem.“ Eine einfache, aber tiefgreifende Einsicht.

Was das konkret für deine Karriere bedeutet

Wenn du jetzt in der Softwareentwicklung arbeitest oder dich darauf vorbereitest, solltest du die Warnung des Autors ernst nehmen. Die KI wird nicht alle Jobs ersetzen, aber sie wird die Wertigkeit bestimmter Fähigkeiten verschieben. Reines Code-Schreiben wird immer weniger wert sein, weil es die Maschine günstiger und schneller kann. Was einen Entwickler unersetzlich macht, ist das Verständnis für das System als Ganzes – die Fähigkeit, Trade-offs zu erkennen, Risiken abzuwägen und Entscheidungen zu treffen, die auf einem soliden mentalen Modell basieren.

Das bedeutet nicht, dass du jede Zeile selbst schreiben musst. Die KI kann dir die Implementierung abnehmen – das ist ein Segen. Aber du musst verstehen, was sie da tut, und du musst in der Lage sein, ihre Vorschläge zu hinterfragen. Ein gutes Training dafür ist, regelmäßig Refactoring zu üben, Architektur-Dokumentationen zu erstellen und dich in Reviews nicht nur auf die Logik, sondern auch auf die konzeptionelle Passung zu konzentrieren. Wer das beherrscht, wird in der neuen Ökonomie nicht nur überleben, sondern florieren.

Der Autor endet mit einer nüchternen Prognose: Die Mittelschicht der Softwareentwickler wird verschwinden, weil die KI die Produktivität einzelner erhöht und gleichzeitig die Fehlerkosten für Untaugliche explodieren. Das ist keine Katastrophe, sondern eine Bereinigung. Für diejenigen, die bereit sind, Verantwortung zu übernehmen und ihre Urteilsfähigkeit zu schärfen, eröffnen sich Chancen. Für alle anderen wird es eng. Also nutze die KI als Werkzeug, aber lass dich nicht von ihr ersetzen – indem du selbst zum Experten für das große Ganze wirst.

Quelle: blog.florianherrengt.com

Ein Agent erhält einen Screenshot des Bildschirms, klickt auf Schaltflächen und tippt in Formulare. Diese Fähigkeit, Computer zu bedienen, hat sich im vergangenen Jahr rasant verbessert – und doch bleibt die Frage, ob sie in Unternehmen wirklich verlässlich eingesetzt werden kann.

Die Zahlen zeigen einen Sprung: Beim Benchmark OSWorld-Verified stieg die beste Punktzahl von 42 auf 85 Prozent. Menschliche Testpersonen kommen auf etwa 72 Prozent. Damit schlagen die besten Modelle inzwischen die Menschen. Doch im echten Geschäftsleben zählt mehr als ein Benchmark: ob ein Agent über Monate hinweg zuverlässig arbeitet, ohne dass ein Mensch jeden Schritt kontrolliert. Genau dort liegt die eigentliche Herausforderung.

Der Stand der Dinge: Daten und was sie wirklich bedeuten

Die OsWorld-Verified-Zahlen stammen vom Leaderboard llm-stats.com (Stand Juni 2026). Sie messen den Anteil abgeschlossener Aufgaben in einer kontrollierten Desktop-Umgebung. Vor einem Jahr lag der beste Wert bei 42 Prozent – heute sind es 85 Prozent. Das klingt beeindruckend, aber ein Geschäftsprozess ist nur dann erfolgreich, wenn jeder einzelne Schritt klappt. Wenn ein Agent 15 von 100 Aufgaben vermasselt, bleibt für einen Backoffice-Workflow ein erhebliches Risiko. Zudem arbeiten die Modelle in der Praxis anders als im Benchmark: Sie bekommen Screenshots und liefern Klicks und Tastatureingaben zurück, oft ergänzt um DOM- oder Accessibility-Daten. Die eigentliche Magie passiert jedoch im Rahmen darum herum – der Sandbox, der Orchestrierung, der Verifikation und Wiederholungslogik.

Ein bezeichnendes Detail: Einer der größten Betreiber automatisierter Workflows – mit Millionen von Tasks pro Monat – konnte nicht sagen, welches Modell seine Agenten gerade ausführt. Der Anbieter tauscht die Modelle im Hintergrund aus, wie ein Cloud-Provider die Hardware wechselt. Sobald die Fähigkeiten eine gewisse Schwelle überschreiten, rückt das Modell in den Hintergrund. Was zählt, ist die Zuverlässigkeit des gesamten Systems.

Wo Computer-Use-Agenten heute schon produktiv arbeiten

Die praktischen Einsatzgebiete sind klar umrissen: Agenten übernehmen standardisierte, wiederholbare Aufgaben, bei denen sonst ein Mensch durch eine Benutzeroberfläche klickt. Typische Beispiele sind das Pflegen von CRM-Einträgen, das Abrufen von Daten aus Regierungs- oder Versicherungsportalen, die Verarbeitung von Aufträgen oder das Bearbeiten von IT-Tickets in ServiceNow. Entscheidend ist, dass der Pfad eindeutig und überprüfbar ist.

Ein konkretes Zahlenbeispiel: Eine CPG-Datenplattform wickelt 15 bis 20 Millionen automatisierte Portal-Interaktionen pro Monat ab. Ihre Agenten dienen als selbstheilender Fallback für handgeschriebene Scraper. Wenn ein Einzelhandelsportal sein Layout ändert, erkennt der Agent den Bruch, repariert die Automatisierung und sorgt dafür, dass die Daten weiterfließen – bevor ein Ingenieur überhaupt von dem Fehler erfährt. Ein globaler Systemintegrator berichtet von 27 aktiven Workflows, die täglich 1500 bis 2100 IT-Tickets bearbeiten, mit dem Ziel, 20 bis 25 Prozent des Personals auf höherwertige Aufgaben umzuschichten. Eine Agentur hat den gesamten Rekrutierungs-Workflow automatisiert: Nach einem Interview wird der Kandidat automatisch in das Bewerberverfolgungssystem eingetragen. Sie nutzen ein günstiges Nicht-Frontier-Modell, weil es „alles tut, was wir brauchen, und das gut“. Das Muster ist überall gleich: Je klarer die Regeln und je einfacher die Überprüfung, desto zuverlässiger funktioniert der Agent.

Die harte Realität: Wenn die Arbeit aus dem Rahmen fällt

Die größten Probleme treten auf, wenn ein Workflow mehrdeutig wird oder keine klare Erfolgskontrolle existiert. Ein Agent, der Zahlungsbedingungen aus Verträgen in ein ERP-System überträgt, könnte „net 60“ als „net 30“ lesen – der Fehler bleibt unentdeckt, bis eine Rechnung falsch rausgeht. Ebenso kritisch ist der Fall, in dem der Erfolg erst später sichtbar wird: Ein Agent reicht einen Versicherungsanspruch ein, der Bildschirm zeigt „erhalten“, die Aufgabe gilt als erledigt. Doch zwei Tage später meldet sich ein Sachbearbeiter telefonisch, weil eine Policennummer fehlt. Ein Mensch hätte das sofort geklärt, der Agent hat keinen Zugriff auf solche Nachzügler-Informationen. Der Prozess stockt still.

Diese Beispiele zeigen: Ein besseres Modell allein löst das Problem nicht. Die Lösung liegt in der Harness-Architektur – also in der Umgebung, die den Agenten umgibt und dafür sorgt, dass unerwartete Situationen erkannt und eskaliert werden. Genau hier setzen die Anbieter an, die in der Praxis erfolgreich sind. Sie bauen Systeme mit einer Feedback-Schleife, die auch subtile Fehler aufspürt, sei es durch Quervergleiche mit anderen Datenquellen oder durch manuelle Überprüfung an definierten Kontrollpunkten.

Infrastruktur schlägt Modell: Worauf Käufer wirklich achten

Im Gespräch mit Enterprise-Kunden wird deutlich: Das Modell ist selten das entscheidende Kriterium. „Die Modelle sind heute schon gut genug“, sagen sie. Entscheidend ist die Infrastruktur, die Skalierbarkeit, Sicherheit und nachweisbare Rendite bietet. Käufer interessiert nicht, ob ein bestimmtes Frontier-Modell eingesetzt wird, sondern ob die Lösung den Job zuverlässig und kosteneffizient erledigt. Deshalb entwerfen Architekten die Systeme mit Blick auf Fehlertoleranz.

Eine wiederkehrende Strategie: Der Agent führt den Workflow einmal aus, das System „cached“ ihn als deterministischen Code, und ab dann laufen alle weiteren Instanzen als preiswerte Skripte. Der Agent wird nur noch aktiv, wenn etwas schiefgeht – er diagnostiziert, repariert und erneuert den Cache. So sinken die Kosten pro Ausführung über die Zeit, und das System wird wirtschaftlich, selbst für Aufgaben mit hohem Volumen. Die Designphilosophie geht mit Unsicherheit um: Wo früher deterministischer Code einfach scheiterte, übernimmt der Agent die Flexibilität und passt sich an. Das ist „Design für den Fehlerfall“ in Reinkultur – und es erklärt, warum selbst ein mittelmäßiges Modell mit exzellenter Infrastruktur besser performt als ein Spitzenmodell ohne robustes Framework.

Der Markt fokussiert sich derzeit auf die niedrig hängenden Früchte: Workflows mit klaren Erfolgskriterien und überschaubarem Risiko. Die anspruchsvolleren Aufgaben – etwa komplexe Vertragsprüfungen oder Kundeninteraktionen mit emotionaler Komponente – bleiben vorerst menschlichen Spezialisten überlassen. Doch das Potenzial ist riesig: Jeder manuelle Klick in einem Altsystem ist ein Kandidat für die Automatisierung.

Kontext ist das neue Moat: Vom Klicken zum Verstehen

Für Gründer und Entwickler verschiebt sich der Fokus weg von der reinen Bedienung der Oberfläche. Früher musste man Selenium oder Playwright beherrschen, um einen Browser zu steuern – heute wird diese Schicht abstrahiert. Das eigentliche Know-how liegt plötzlich in der Kenntnis des spezifischen Unternehmenskontexts: die internen Abkürzungen, die bevorzugten Formulierungen, die Abhängigkeiten zwischen Abteilungen. Ein Agent, der ein SAP-System bedienen kann, ist austauschbar. Aber ein Agent, der weiß, wie die Buchhaltung in einem mittelständischen Maschinenbauer arbeitet, das ist ein echter Wettbewerbsvorteil.

Die langfristige Entwicklung ist klar: Computer-Use-Agenten werden zu einem Standardwerkzeug, so wie früher Makros oder Skripte. Die Differenzierung entsteht durch die Qualität der Integration – durch die Menge an Kontextwissen, das der Agent über den Prozess und das Unternehmen hat. Unternehmen, die dieses Wissen strukturieren und in ihre Agenten-Infrastruktur einbetten, werden ihre Effizienz dramatisch steigern. Wer es versäumt, riskiert, den Anschluss zu verlieren – denn die Konkurrenz findet gerade heraus, wie man mit weniger Klickarbeit und mehr Denkarbeit die Betriebskosten senkt.

Für dich als Entscheider heißt das: Wenn du über den Einsatz von Computer-Use-Agenten nachdenkst, lohnt es sich, nicht auf das neueste Modell zu schielen, sondern auf die Plattform und das Ecosystem, das den Agenten trägt. Frage nach den Referenzen, den Fehlerquoten, den Eskalationsmechanismen. Und sei dir bewusst: Der wahre Wettbewerbsvorteil liegt in deinem Firmenwissen, nicht in der KI-Technologie an sich. Diese Erkenntnis ist unspektakulär, aber sie entscheidet über den Unterschied zwischen einem Pilotprojekt und einem skalierenden Produktivsystem.

Quelle: a16z.com

Acht verschiedene Erweiterungen bringt das neue Plugin-Paket Qwen-MM-Plugins für KI-Agenten mit. Das Projekt von Alibaba verleiht den Qwen-Modellen native multimodale Fähigkeiten – von Bild- und Videoanalyse über 3D-Modellierung bis zu Bildungsvideos.

Wer mit KI-Agenten arbeitet, kennt das Problem: Viele Modelle sind auf Text beschränkt. Separate APIs für Vision oder Audio existieren zwar, aber die Integration in bestehende Agenten ist oft mühsam. Die Qwen-MM-Plugins setzen genau hier an. Sie bündeln verschiedene multimodale Werkzeuge und machen sie über einheitliche Schnittstellen verfügbar – ohne dass du für jeden Einsatzzweck eine eigene Infrastruktur aufbauen musst.

Was sind die Qwen-MM-Plugins?

Die Qwen-MM-Plugins sind eine Sammlung von Erweiterungen, die die Fähigkeiten von Qwen-Modellen erweitern. Jede Erweiterung besteht aus zwei Teilen: einem Skill, der dem Modell mitteilt, welche Werkzeuge verfügbar sind, und einem optionalen MCP-Server, der die eigentlichen Werkzeuge bereitstellt. MCP steht für Model Context Protocol – ein offener Standard, der es KI-Modellen erlaubt, mit externen Tools zu kommunizieren. Dadurch können Agenten nicht nur Texte verarbeiten, sondern auch Bilder, Videos, 3D-Modelle und sogar CAD-Dateien.

Das Projekt richtet sich an Entwicklerinnen und Entwickler, die mit Qwen-Modellen arbeiten – sei es für Prototypen, interne Tools oder produktive Anwendungen. Die Plugins sind modular aufgebaut: Du installierst nur das, was du konkret brauchst, und sparst dir dadurch unnötigen Ballast. Das Repository enthält außerdem Kochbücher und Beispiele, die den Einsatz in der Praxis zeigen.

Bemerkenswert ist die Architektur. Die Plugins sind als native MCP-Server umgesetzt, die von vielen gängigen Agenten-Harnesses wie Claude Code, Codex oder Qwen Code direkt unterstützt werden. Du kannst die Werkzeuge also in deiner bevorzugten Umgebung nutzen, ohne auf proprietäre Schnittstellen angewiesen zu sein.

Die acht Capabilities im Überblick

Die Qwen-MM-Plugins umfassen acht verschiedene Capabilities, jede mit einem klaren Fokus. Die erste ist core – sie bietet lokale Ein- und Ausgabe für Bilder und Videos in dynamischer Auflösung. Du kannst damit Dokumente visualisieren, Bilder zuschneiden, Anmerkungen machen und Frames extrahieren. Diese Erweiterung ist die Basis für alle anderen, da sie den Umgang mit lokalen Dateien ermöglicht.

Die zweite Capability heißt api und bündelt Cloud-APIs für Medienverständnis. Dazu gehören Vision-Chat, OCR, Grounding, sowie Audio- und Videoverständnis mit Zeitstempeln. Wenn du Sprache transkribieren, Sprecher unterscheiden oder Ereignisse in Videos zählen willst, ist das hier abgedeckt. Aktuell wird DashScope als Provider unterstützt, was vor allem für Nutzer der Alibaba-Cloud interessant ist.

Die dritte Erweiterung, search, ermöglicht Websuche und umgekehrte Bildersuche, um Fakten zu überprüfen. Sie nutzt den Serper-Dienst und hilft Agenten, aktuelle Informationen abzurufen oder die Herkunft von Bildern zu klären. Die vierte, video-memory, ist ein hierarchischer Graph-Speicher für sehr lange Videos. Damit können Agenten Fragen über Inhalte beantworten, die viele Minuten oder Stunden dauern – ohne den Kontext zu verlieren.

Die restlichen Capabilities runden das Angebot ab: video-edit bietet Workflows für Videobearbeitung und -generierung, blender steuert eine laufende Blender-Instanz über Python – mit 22 Tools für Modellierung, Materialien, Beleuchtung und Rendering. freecad macht Ähnliches für FreeCAD und erlaubt parametrische CAD-Modellierung mit 14 Werkzeugen sowie STEP/STL-Import und FEM-Analyse. Schließlich gibt es noch edu-agent, das aus mathematischen oder naturwissenschaftlichen Problemstellungen Schritt-für-Schritt-Erklärvideos auf Chinesisch generiert – eine Erweiterung, die nur aus einem Skill ohne MCP-Server besteht.

Architektur: Skills und MCP-Server harmonisch kombiniert

Das architektonische Konzept ist einfach und flexibel. Jede Capability ist eine eigenständige Einheit, die du separat installieren kannst. Die Skills sind im Wesentlichen Beschreibungen, die dem Modell sagen: „Diese Werkzeuge existieren und so werden sie benutzt.“ Der MCP-Server liefert die eigentliche Funktionalität – er wird bei Bedarf über uvx gestartet, ein Tool, das Python-Pakete in isolierten Umgebungen ausführt. Dadurch entfällt die manuelle Installation von Abhängigkeiten via pip, was Zeit spart und Fehler vermeidet.

Ein weiterer Vorteil ist die Wiederverwendbarkeit. Da die Plugins auf dem standardisierten MCP-Protokoll basieren, funktionieren sie nicht nur mit Qwen-Modellen, sondern prinzipiell mit jedem Agenten, der dieses Protokoll unterstützt. Das Projekt nennt explizit Claude Code, Codex, Qoder, OpenClaw, Qwen Code und Gemini CLI als unterstützte Umgebungen. So kannst du dieselben Fähigkeiten in verschiedenen Tools nutzen, ohne jeweils eigene Implementierungen zu pflegen.

Gut gelöst ist die dynamische Auflösung beim Lesen von Bildern und Videos. Die Plugins skalieren jede Datei automatisch auf das Patch-Raster des Vision-Language-Modells – ein 4K-Screenshot mit winziger Schrift wird genauso detailreich erfasst wie ein kleines Thumbnail. Du musst keine manuelle Größenanpassung vornehmen, sondern einfach die Datei referenzieren und deine Frage stellen. Das macht die Arbeit mit gemischten Medien deutlich angenehmer.

Installation: So einfach geht’s

Die Installation der Qwen-MM-Plugins ist dank eines geführten Installationsskripts unkompliziert. Ein einziger Befehl erledigt Installation, Konfiguration, Verifikation und Deinstallation für alle unterstützten Agenten-Harnesses. Das Skript nutzt die nativen Installationsmechanismen der jeweiligen Umgebung und schreibt eine gemeinsame Konfigurationsdatei unter ~/.qwen-mm-plugins/config, die sowohl GUI- als auch Terminal-Anwendungen lesen können. So konfigurierst du alles einmal und nutzt es überall.

Für Windows-Nutzer gibt es eine Besonderheit: Unterstützt wird nur WSL2 (Windows Subsystem for Linux) mit Ubuntu. Du musst das Repository im Home-Verzeichnis von WSL klonen, nicht unter einem gemounteten Windows-Laufwerk wie /mnt/c. Das ist eine pragmatische Einschränkung, die für die meisten Entwickler kein Hindernis darstellt, da WSL2 inzwischen zum Standard gehört.

Wer lieber manuell vorgeht oder einen weniger verbreiteten Agenten nutzt, kann die Plugins auch per Hand installieren. Dazu registriert man den Skill und den MCP-Server in der Konfiguration des jeweiligen Harnesses. Das Projekt enthält detaillierte Anleitungen für jeden unterstützten Agenten. Alternativ kann man den Agenten auch einfach bitten, die Installation vorzunehmen – die meisten modernen Agenten sind dazu in der Lage, wenn sie das Repository kennen.

Konfiguration und erste Schritte

Bevor du die API-basierten Werkzeuge nutzen kannst, musst du in der Regel API-Schlüssel hinterlegen. Für die Cloud-Dienste von DashScope benötigst du eine DASHSCOPE_API_KEY, für die Websuche eine SERPER_API_KEY. Die lokale Bild- und Videoverarbeitung kommt ohne Schlüssel aus – ein großer Vorteil, wenn du sensible Daten nicht an externe Dienste senden willst. Du kannst die Schlüssel als Umgebungsvariablen exportieren oder in der Konfigurationsdatei ablegen, die standardmäßig gelesen wird, falls keine Variable gesetzt ist.

Der Schnellstart ist denkbar einfach: Sobald eine Capability installiert ist, kannst du eine Datei in deinem Agenten referenzieren und eine Frage dazu stellen. Das Modell wählt automatisch das passende Tool aus. Du musst weder die genauen API-Kommandos kennen noch selbst Werkzeuge ansteuern. Genau das macht diese Plugins aus: Sie machen Multimodalität komplett transparent.

Ein Beispiel: Du zeigst deinem Agenten ein Foto eines defekten Bauteils und fragst nach der wahrscheinlichen Verschleißursache. Die Core-Erweiterung liest das Bild, die API-Erweiterung nutzt Vision-Language-Modelle für die Analyse, und wenn du noch eine Websuche anschließt, kann der Agent sogar aktuelle Reparaturhinweise von Herstellern abrufen. So kombiniert er verschiedene Fähigkeiten in einer einzigen Anfrage – etwas, das früher mehrere separate Systeme erforderte.

Einordnung: Warum das wichtig ist

Die Qwen-MM-Plugins sind mehr als nur eine weitere Tool-Sammlung. Sie zeigen, wie sich multimodale KI praktisch einsetzen lässt, ohne dass du dich in proprietäre Ökosysteme einladen musst. Der Ansatz, standardisierte MCP-Server zu verwenden, fördert Interoperabilität und senkt die Einarbeitungszeit erheblich. Für Entwickler bedeutet das: weniger eigene Integrationen, mehr Fokus auf die eigentliche Anwendung.

Beeindruckend ist die Bandbreite der Fähigkeiten – von einfacher Bildanalyse über komplexe 3D-Modellierung in Blender bis hin zu parametrischer Konstruktion in FreeCAD. Damit adressiert das Projekt nicht nur klassische Text-Agenten, sondern auch Branchen wie Ingenieurwesen, Architektur und Produktdesign, die bisher kaum von generativen KI-Modellen profitiert haben. Die niedrige Einstiegsschwelle und die modulare Architektur machen es leicht, erste Versuche zu starten und später in bestehende Workflows einzubetten.

Allerdings hat das Projekt auch Grenzen. Viele Erweiterungen sind noch als „TBD“ markiert, die Kochbücher fehlen teilweise. Das Projekt ist jung, und die Abhängigkeit von Cloud-APIs wie DashScope könnte für manche Nutzer eine Hürde darstellen. Trotzdem ist die Richtung klar – und sie ist vielversprechend. Wenn sich solche Plugins weiter etablieren, könnten multimodale Agenten bald so selbstverständlich sein wie Text-Chatbots. Die Qwen-MM-Plugins liefern dafür einen wichtigen Baustein.

Quelle: github.com