Kategorie: Tool-Tests

Drei SKILL.md-Dateien, ein gemeinsamer REST-Client: Das ist die Essenz des Projekts spark-observability-skills von EmbrasureAI. Das Open-Source-Projekt hilft, typische Probleme in Apache-Spark-Workloads schneller zu finden – von abgestürzten Executoren bis hin zu teuren SQL-Plänen. Wer schon einmal stundenlang Logs durchforstet hat, nachdem ein Spark-Job unerwartet fehlschlug, weiß, wie wertvoll ein strukturierter Ansatz sein kann.

Jeder Skill ist eine einzelne Datei mit einer priorisierten Checkliste. Ein kleines Python-Skript sammelt die nötigen Laufzeitdaten direkt vom History Server. Das Ganze ist read-only, begrenzt die Antwortgrößen und redigiert sensible Eigenschaften. Du bekommst ein Werkzeug, das dir den Weg durch den Spark-Dschungel weist, ohne tief in die Cluster-Interna eintauchen zu müssen.

Was genau sind Agent Skills?

Bevor wir uns die drei Skills im Detail ansehen, lohnt ein kurzer Blick auf das Konzept dahinter. Agent Skills sind kleine, klar definierte Anweisungen für KI-gestützte Programmierassistenten wie Codex oder Claude Code. Stell dir vor, du hast einen erfahrenen Kollegen, der bei einem Problem nicht nur Tipps gibt, sondern systematisch eine Diagnose durchführt – Schritt für Schritt, mit einer klaren Reihenfolge von Ursachen, die er zuerst prüft. Genau das macht ein Skill: Er gibt dem Agenten eine strukturierte Vorgehensweise vor.

Im Fall von spark-observability-skills ist jeder Skill eine Datei namens SKILL.md. Sie enthält eine geordnete Liste der häufigsten und wirkungsvollsten Ursachen für ein bestimmtes Problem – zum Beispiel für einen fehlgeschlagenen Job. Dazu kommt ein Skript, das die Beweise aus dem Spark History Server holt. Der Agent kann so nicht nur raten, sondern konkrete Daten auswerten und dir erklären, was schiefläuft.

Die drei Skills decken die klassischen Problemfelder ab: Fehlerdiagnose, Performance-Analyse und SQL-Optimierung. Diese Trennung ist sinnvoll. Ein abgestürzter Job hat andere Ursachen als ein langsamer, und eine teure Query verlangt wiederum nach anderen Hebeln.

Skill 1: Fehler im Spark-Job aufspüren

Der erste Skill heißt „Debug Spark failures“ und zielt auf den Albtraum jedes Dateningenieurs: Ein Job läuft nicht durch, aber der letzte Fehler im Log sagt nichts Nützliches. Oft sieht man nur die oberflächliche Meldung wie „Task failed“ oder „Executor lost“, während die eigentliche Ursache viel weiter zurückliegt – ein abgestürzter Treiber, ein Out-of-Memory-Kill, ein Fetch-Fehler oder eine Exception in einem Task.

Der Skill leitet dazu an, diese Symptome zu hinterfragen und zur frühesten unterstützenden Ursache zurückzugehen. Statt den letzten Retry-Error zu betrachten, schaut man sich die Kette der Ereignisse an. Dafür nutzt der Agent den History-Server-REST-Client, um die relevanten Teile des Event Logs zu ziehen – und nur die. Die Liste der Prioritäten hilft, die wahrscheinlichsten Verdächtigen zuerst zu überprüfen, statt alles gleichzeitig zu untersuchen.

Das klingt simpel. In der Praxis spart es Zeit und Frustration. Viele Spark-Nutzer verlieren Stunden damit, den falschen Fehler zu jagen. Dieser Skill kanalisiert die Diagnose in eine klare Bahn.

Skill 2: Langsame Jobs beschleunigen

Der zweite Skill „Debug slow Spark jobs“ richtet sich an das alltägliche Problem, dass ein Job zwar läuft, aber deutlich länger oder teurer ist als erhofft. Hier empfiehlt der Skill einen Vergleich mit einem gesunden Lauf: Du brauchst eine Referenz, um die erste Abweichung zu lokalisieren. Liegt es an Skew – also ungleicher Datenverteilung –, an exzessivem Shuffle, an Spill auf die Festplatte, an GC-Pausen, an schlechter Parallelität oder doch an der Infrastruktur?

Der Agent nutzt wieder den REST-Client, schaut sich aber diesmal Metriken wie Aufgabenzeiten, Shuffle-Volumen und Speichernutzung an. Die Skill-Datei listet die wahrscheinlichsten Ursachen in sinnvoller Reihenfolge. So folgst du einer deduktiven Spur, statt ratlos durch die Benutzeroberfläche zu gehen.

Der Hinweis, dass ein gesunder Lauf als Basis dient, ist nützlich. Wenn du eine frühere erfolgreiche Ausführung hast, kann der Agent die Unterschiede punktgenau herausarbeiten. Das ist präziser, als pauschal nach „Performance-Problemen“ zu suchen.

Skill 3: SQL-Pläne kosteneffizient machen

Der dritte Skill widmet sich einer typischen Spark-Herausforderung: Eine Query liefert die richtigen Ergebnisse, aber sie kostet zu viel – zu viele Scans, zu teure Joins, unnötige Shuffles. Hier geht es um „Optimize Spark SQL plans“. Der Skill liest den finalen adaptiven Plan und die Laufzeitmetriken, um Schwachstellen zu identifizieren, ohne das Ergebnis zu verändern.

Dabei hilft der History-Server-REST-Client, detaillierte Informationen über die ausgeführten Operationen zu sammeln. So kann der Agent sehen, wo Daten gescannt werden, welche Joins besonders teuer sind und ob es unnötige Arbeit gibt. Anschließend schlägt er konkrete Optimierungen vor – etwa das Umformulieren der Query, das Hinzufügen von Partitionen oder das Anpassen von Join-Hinweisen.

Wichtig ist: Der Skill verändert nichts an der Logik. Er ist auf Konservierung der Semantik ausgelegt. Du kannst die Vorschläge übernehmen, ohne befürchten zu müssen, dass sich die Ergebnisse ändern.

Der gemeinsame REST-Client: Beweise sammeln, ohne etwas zu verändern

Alle drei Skills basieren auf demselben Skript: `scripts/spark_history_api.py`. Es agiert als read-only REST-Client gegenüber dem Spark History Server oder der Live-UI einer laufenden Anwendung (Port 4040). Der Client begrenzt standardmäßig große Antworten, redigiert sensible Spark-Eigenschaften und lässt TLS-Verifikation aktiviert. Das ist eine durchdachte Sicherheitsvorkehrung – du willst nicht, dass ein KI-Agent versehentlich Daten verändert oder Zugangsdaten preisgibt.

Das Skript sammelt die relevanten Beweise in einem „bounded snapshot“ – also einem zeitlich und größenmäßig begrenzten Ausschnitt. Das ist wichtig, denn ein Spark History Server kann riesige Datenmengen enthalten. Durch die Begrenzung bleibt die Analyse effizient und der Agent wird nicht mit überflüssigen Informationen überflutet.

Die Einrichtung ist unkompliziert: Du setzt die Umgebungsvariable `SPARK_HISTORY_URL`, optional mit Authorization-Token oder Cookie für SSO-Proxys. Wenn der Server im Cluster läuft, reicht ein Port-Forward, etwa `kubectl port-forward`. Die Skills erwarten, dass die History-Daten vorhanden sind – also dass `spark.eventLog.enabled=true` gesetzt war, als die Jobs liefen. Das solltest du im Hinterkopf behalten.

Der Einrichtungsprozess und nötige Voraussetzungen

Die Installation ist simpel: Du klonst das Repository und erstellst einen Symlink auf dein Skills-Verzeichnis – sei es bei Codex, Claude oder einem anderen Agenten. Genau genommen musst du nur den Ordner `skills/` mit deinem vorhandenen Skills-Pfad verknüpfen. Sobald du den Agenten neu lädst, stehen dir die drei Skills zur Verfügung.

Wichtig ist die Umgebungsvariable `SPARK_HISTORY_URL`. Ohne sie kann der Client nicht arbeiten. Du hast die Wahl zwischen einem öffentlich erreichbaren History Server oder einem getunnelten Port. Für private Zertifikate gibt es die Option `–ca-file`, und für SSO-Proxys kannst du entweder ein Cookie oder zusätzliche HTTP-Header übergeben. Das deckt die meisten Realweltszenarien ab.

Die Autoren betonen, dass der Client vollständig read-only arbeitet. Trotzdem empfehlen sie, jeden Befehl vor der Ausführung gegen die eigenen Sicherheitsrichtlinien zu prüfen. Das ist verantwortungsvoll, gerade wenn du den Agenten in einer Produktionsumgebung einsetzt.

Was das für deine Spark-Praxis bedeutet

Betrachtet man das Projekt als Ganzes, zeigt sich ein klarer Trend: KI-Assistenten werden von reinen Code-Generatoren zu diagnostischen Werkzeugen. Die Skills von Embrasure sind ein Beispiel dafür, wie man implizites Wissen über Spark – das oft in den Köpfen erfahrener Ingenieure steckt – explizit und für Agenten zugänglich macht. Die geordneten Checklisten ersetzen keine tiefe Systemkenntnis, aber sie helfen dir, schneller an die richtige Stelle zu schauen.

Ein Detail: Die Skripte sind in allen drei Skill-Ordnern identisch. Das ist eine bewusste Designentscheidung, damit jeder Skill eigenständig funktioniert – du kannst also auch nur einen Skill auswählen, ohne die anderen zu installieren. Diese Modularität ist angenehm, auch wenn sie Wartungsaufwand bedeutet: Änderst du etwas am Skript, musst du alle drei Kopien synchronisieren.

Das Projekt ist eine solide Brücke zwischen der komplexen Welt von Apache Spark und dem Wunsch nach schneller Fehlerbehebung. Es ersetzt kein professionelles Monitoring, aber es gibt dir und deinem Agenten eine gemeinsame Sprache und einen strukturierten Blick ins Innere deiner Workloads. Wenn du mit Spark arbeitest und eine neutralere, datenbasierte Diagnose willst, ist dieses Open-Source-Tool einen Blick wert.

Quelle: github.com

Ein Datenanalyst sitzt vor einem Dashboard und hat soeben eine Anfrage an einen KI-Agenten geschickt. Die Frage: Hat die Marketingkampagne „Midwest acquisition v2″ den Einsatz gelohnt? Der Agent rechnet, summiert und liefert nach wenigen Sekunden eine klare Antwort: Nein, die Kampagne war das Geld nicht wert. Der Analyst nickt zufrieden, bis er bemerkt, dass die zugrunde liegenden Daten gar nicht existieren. Es gibt schlicht keinen Tracking-Code für die Kampagne. Der Agent hat sich die Zahlen aus dem Zusammenhang heraus erfunden – mit einer Selbstsicherheit, die menschliche Analysten verblüfft.

Genau dieses Szenario beschreibt das Team von Hex, einer Plattform für kollaborative Datenanalyse, in ihrem neuen Benchmark. Sie nennen ihn DataBench. Die Lektion daraus ist unbequem: Die größte Stärke großer Sprachmodelle – ihre Fähigkeit, aus Kontext Wahrscheinlichkeiten zu berechnen – wird in der Datenanalyse zur tödlichen Schwäche, weil sie keine intrinsische Skepsis kennen. Die Ergebnisse betreffen jeden, der mit Daten arbeitet.

Warum herkömmliche Benchmarks ein falsches Bild zeichnen

Die führenden KI-Modelle glänzen auf etablierten Benchmarks wie Spider 2.0 oder DABstep mit Erfolgsraten von über 85 Prozent. Sonnet 4.5 von Anthropic erreicht 90 Prozent, Claude Haiku 4.5 liegt bei 89 Prozent. Auf dem Papier wirkt die Datenanalyse damit nahezu gelöst. Doch das Team von Hex argumentiert, dass diese Benchmarks eine Realität abbilden, die mit der Arbeit echter Datenanalysten wenig zu tun hat.

Die Aufgaben dort sind präzise formuliert, die Datenbanken sauber aufgeräumt, die Ziele glasklar. Es gibt genau eine richtige Antwort, oft sogar einen vorgegebenen SQL-Code als Vergleich. „Das ist wie Krafttraining im Fitnessstudio“, schreibt der Autor des Beitrags, „beeindruckend, aber nicht der Alltag.“ Echte Anfragen in Unternehmen sind vage, mehrdeutig und mit impliziten Annahmen durchsetzt. Ein Analyst fragt nicht: „Berechne die Summe aller Umsätze für Produktkategorie X im Zeitraum Y.“ Er fragt: „Sollten wir unsere Preisstrategie in Europa überdenken?“ – und erwartet eine Empfehlung, keine Zahl.

Die Diskrepanz zwischen Benchmarktests und realen Anforderungen ist das Kernproblem, das DataBench adressiert. Die Entwickler haben 100 realistische Aufgaben aus der Nutzung ihrer eigenen Plattform gesammelt, anonymisiert und in eine synthetische Geschäftswelt namens Shorelane Commerce eingebettet. Die Aufgaben reichen von einfachen Datenabfragen bis zu komplexen Entscheidungsszenarien mit Fallstricken, die bewusst an die Grenzen der Modelle führen.

Die unbequeme Wahrheit über Datenqualität und geteilte Verantwortung

Die Ergebnisse von DataBench zeigen ein ernüchterndes Bild: Selbst die besten Modelle scheitern an Aufgaben, die für Menschen trivial erscheinen. Die Hälfte der Testfälle beinhaltet chaotische Daten – widersprüchliche Metrikdefinitionen, fragmentierte Datensätze, veraltete Einträge. Hier zeigen die Modelle überraschende Stärke, solange die Absicht klar ist. Ein Beispiel: Die Aufgabe verlangt die aktuelle USD-Pipeline für einen historischen Bericht mit Stichtag 15. Januar – eine scheinbar simple Abfrage, die aber erfordert, dass der Agent den Datenbestand auf den damaligen Zustand zurückspult. 29 von 32 Modellkonfigurationen meistern das.

Doch sobald die Anweisung vage wird oder der Kontext Interpretationsspielraum lässt, kippt die Bilanz. Bei offenen, delegierten Entscheidungen sinkt die Erfolgsquote auf 66 Prozent, bei speziell konstruierten „Fallen“ – Aufgaben mit einer plausiblen, aber falschen Antwort – sogar auf 54 Prozent. Das Team spricht von einem „verfluchten Bereich“: In der Datenanalyse sehen einfache Fragen schwer aus, schwere Fragen leicht, und viele Fragen sind schlicht unmöglich zu beantworten, weil die Datenlage es nicht hergibt.

Ein konkretes Beispiel ist die Aufgabe mit den zwei Abrechnungssystemen, die unterschiedliche Aussagen darüber treffen, welche Kunden säumig sind. Die naheliegende Lösung – alle Kunden anzurufen, über die sich die Systeme uneinig sind – wird durch Daten im System gestützt. Doch diese Daten sind veraltet: Die meisten fraglichen Konten haben längst bezahlt, nur die Sync-Prozesse haben das nicht erfasst. Nur Opus 5 von Anthropic erkennt die Falle. Alle anderen Modelle folgen dem naheliegenden Pfad – und scheitern.

Das Problem der erfundenen Sicherheit

Besonders beunruhigend ist ein Muster, das sich durch die Tests zieht: Modelle konstruieren Sicherheit, wo keine existiert. In einem Testfall geht es um die Frage, ob Bestellungen, die in mehreren Paketen geliefert werden, mehr Support-Tickets erzeugen. Opus 5 rechnet elf Minuten lang korrekt, um dann eine kausale Beziehung zu „verifizieren“, die schlicht nicht aus den Daten ableitbar ist. Die Analyse ignoriert den Kontext: Bestellungen werden nur dann geteilt, wenn das Lagerbestände verteilen muss – was typischerweise bei Engpässen passiert, die auch ohne die Pakettrennung zu Beschwerden führen.

Der Unterschied zwischen Korrelation und Kausalität ist für Modelle offenbar kaum überwindbar. Sie akzeptieren ihre eigenen Rechenergebnisse als Beweis für einen Mechanismus, den sie nur vermuten. Das Team von Hex nennt das „Herstellung von Gewissheit“ – ein Prozess, der die Modelle dazu bringt, ihre Ergebnisse zu überschätzen und menschliche Nutzer in die Irre zu führen.

Das ist kein Randphänomen. Die Entwickler berichten, dass sie bei fünf Aufgaben, die als „unlösbar“ konzipiert waren, die Bewertung ändern mussten, weil Fable 5 von Anthropic – eine der neuesten Modellgenerationen – elegantere Lösungen fand als die erwartete Antwort. Diese Mischung aus Brillanz und Arroganz macht die Arbeit mit KI-Agenten in der Datenanalyse zu einem ständigen Spagat zwischen Vertrauen und Kontrolle.

Die Kostenfrage: Wo günstige Modelle erstaunlich stark konkurrieren

DataBench zeigt auch, dass die Kosten-Nutzen-Rechnung vieler Unternehmen überdacht werden muss. Die „Pareto-Effizienzgrenze“ – ein Begriff für das beste Verhältnis von Kosten zu Genauigkeit – offenbart eine Überraschung: Das Modell GPT-5.6 Luna erreicht bei hohem Rechenaufwand fast die Leistung des deutlich teureren Sol – zu einem Bruchteil der Kosten. Das Team von Hex spricht von einem „absurden Preisleistungsverhältnis“. Während Fable 5 das einzige Modell ist, bei dem erhöhte Anstrengung keine negativen Effekte zeigt, verhält sich Opus 5 auf hohen Stufen erratisch.

Für Unternehmen bedeutet das: Das beste Modell ist nicht automatisch das wirtschaftlichste. Wer täglich hunderte Datenanalysen automatisiert ausführen lässt, kann mit einem günstigen Modell wie Luna erhebliche Kosten sparen – ohne signifikanten Qualitätsverlust bei Standardaufgaben. Bei kniffligen Fällen bleibt der Griff zu den großen Modellen unvermeidlich, aber die Schwelle, ab wann sich das lohnt, liegt deutlich höher als bisher angenommen.

Die Brücke zwischen Skepsis und Automatisierung

Die Autoren von DataBench lassen offen, ob sie eine Lösung für das Problem der mangelnden Modell-Skepsis haben. Ihr Rat ist bodenständig: Bleiben Sie neugierig, fragen Sie nach, testen Sie Ergebnisse, behalten Sie Ihr Urteilsvermögen. Sie versprechen, dass sie Bescheid geben, sobald man „das Gehirn ausschalten kann“ – ein Versprechen, das vermutlich noch lange uneingelöst bleibt.

Was DataBench konkret zeigt, ist, dass die Datenanalyse für KI-Agenten nicht nur eine technische, sondern eine kulturelle Herausforderung ist. Modelle müssen lernen, Unsicherheit zu kommunizieren statt Gewissheit zu erfinden. Sie müssen erkennen, wann eine Frage nicht beantwortet werden kann, und den Mut haben, das dem Nutzer mitzuteilen – auch auf die Gefahr hin, als weniger intelligent zu gelten. Denn in der Datenanalyse ist die Fähigkeit, die eigenen Grenzen zu kennen, wertvoller als jede errechnete Zahl.

Der Benchmark bleibt ein erster Versuch, wie die Entwickler selbst einräumen. Die 100 Aufgaben sind ein Ausschnitt, keine vollständige Landkarte des analytischen Denkens. Doch sie liefern ein wichtiges Signal für alle, die mit KI-Agenten arbeiten: Die Technologie ist mächtig, aber sie ist kein Ersatz für den gesunden Menschenverstand. Sie ist ein Werkzeug, das nachdenkliche Nutzer fordert – und belohnt.

Quelle: hex.tech

„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