Agentic Coding in der Praxis – Diverge · Decide · Converge

Ich experimentiere privat relativ bewusst mit unterschiedlichen Modellen und Reasoning-Stufen. Nicht aus akademischem Interesse, sondern weil ich den Unterschied unmittelbar merke. Ein umfangreiches, aber weitgehend mechanisches Refactoring kann mit einem starken High-Reasoning-Modell hervorragend funktionieren und gleichzeitig einen erstaunlich großen Teil eines begrenzten Wochenkontingents verbrauchen.

Deshalb verwende ich für solche Aufgaben inzwischen häufig bewusst niedrigere Reasoning-Stufen. Nicht, weil ich diese Modelle grundsätzlich für besser hielte oder anspruchsvolle Modelle ihren Preis nicht wert wären. Gerade bei Requirements Engineering, Architekturfragen oder schwierigen Analysen möchte ich momentan kaum auf ein starkes Frontier-Modell verzichten. Bei Routinearbeit stellt sich für mich inzwischen aber eine andere Frage: Brauche ich dafür wirklich dieselbe Menge an Modellintelligenz?

Im Unternehmenskontext ist dieses Feedback oft schwächer. Tokenverbrauch, Credits und API-Kosten werden zentral getragen, einzelne Entwickler sehen sie nur indirekt. Das ist nachvollziehbar, führt aber leicht zu einer Arbeitsweise, in der Modellintelligenz kaum bewusst geroutet wird. Man nimmt das stärkste verfügbare Modell, weil es verfügbar ist. Privat merkt man sehr viel schneller, wenn ein stumpfes Refactoring plötzlich einen erheblichen Teil des Wochenkontingents verbraucht.

Das hat meine Sicht auf Agentic Coding verändert.

Das stärkste verfügbare Modell ist nicht automatisch das sinnvollste Modell für jede Aufgabe.

Die interessantere Frage lautet für mich deshalb nicht mehr: Welches Modell ist das beste? Sondern:

Wie viel Modellintelligenz braucht die konkrete Aufgabe an diesem Punkt ihrer Bearbeitung überhaupt noch?

Die Antwort hängt überraschend wenig davon ab, ob wir das Etikett Requirements, Architektur, Coding oder Testing auf die Tätigkeit kleben. Entscheidend ist etwas anderes: Wie viele relevante Entscheidungen sind noch offen?

Der offene Entscheidungsraum

Es wäre verführerisch, Agentic Work grob in zwei Klassen einzuteilen: Requirements und Architektur gehen an ein großes Modell, Coding und Tests an ein kleineres. Das ist einfach, aber fachlich zu grob.

Coding kann hochgradig explorativ sein. Wer in einem unbekannten Legacy-System einen schwer reproduzierbaren Fehler sucht, Architekturgrenzen rekonstruieren oder eine tragfähige Refactoring-Strategie entwickeln muss, arbeitet zwar am Code, befindet sich aber in einem großen Entscheidungsraum. Umgekehrt können Requirements bereits weitgehend konvergiert sein. Wenn ein bestehender fachlicher Contract lediglich um ein exakt beschriebenes Feld erweitert werden soll, ist möglicherweise kaum noch etwas zu entscheiden.

Die für mich interessantere Achse ist deshalb der offene Entscheidungsraum:

Je weiter wir uns oben befinden, desto mehr sinnvolle Varianz brauchen wir. Wir wollen Alternativen sehen, Annahmen angreifen, Zusammenhänge entdecken und unter Umständen auch Lösungen vorgeschlagen bekommen, auf die wir selbst nicht gekommen wären. Je kleiner der Entscheidungsraum wird, desto weniger erwünschte Varianz bleibt übrig.

Damit verändert sich nicht nur die Aufgabe. Es verändert sich auch die Rolle, die das Modell in dieser Aufgabe spielen soll.

Diverge: Varianz ist erwünscht

Ein großer Teil meiner heutigen Arbeit beginnt nicht mit einer klaren Implementierungsanweisung. Tickets sind unvollständig. Requirements stehen teilweise nur implizit im bestehenden Verhalten. Ein Legacy-System erzählt seine Architektur nicht, sondern zwingt mich, sie aus Code, Abhängigkeiten und historischen Entscheidungen zu rekonstruieren. Bei Fehlern ist die Ursache zunächst unbekannt. Für größere Umbauten existieren mehrere plausible Varianten mit unterschiedlichen Trade-offs.

An solchen Stellen möchte ich Exploration. Ich gebe einem starken Planning- oder Reasoning-Modell das Problem und lasse zunächst untersuchen, was eigentlich fachlich gemeint ist, welche impliziten Requirements im vorhandenen Verhalten stecken, welche Teile des Systems betroffen sind, welche Alternativen existieren und welche Konsequenzen unterschiedliche Architekturvarianten hätten. Besonders wichtig ist mir dabei, dass das Modell auch meine eigenen Annahmen angreift. Manchmal formuliere ich bewusst nur: Überrasche mich.

Gerade beim Requirements Engineering arbeite ich momentan praktisch ausschließlich mit einem starken Frontier-Modell. Das ist keine Aussage darüber, welches Modell objektiv das beste Requirements-Modell wäre. Es beschreibt meine derzeitige Praxis. Der eigentliche Nutzen liegt für mich auch nicht nur in besserer Sprache, sondern darin, einen Lösungsraum gemeinsam zu untersuchen, der bewusst noch nicht geschlossen ist.

Ein POC gehört für mich ebenfalls in diese Kategorie. Sein Zweck besteht häufig gerade darin, eine offene technische Frage zu beantworten. Dass dabei Code entsteht, macht die Tätigkeit nicht automatisch zu einer konvergierten Implementierungsaufgabe. Dasselbe gilt für Legacy-Analysen, unbekannte Fehlerursachen oder eine Refactoring-Frage, bei der ich zunächst mehrere mögliche Schnitte verstehen möchte.

In dieser Phase ist Kreativität tatsächlich eine Capability. Sie ist erwünscht, weil wir noch nicht wissen, welche Lösung die richtige ist.

Decide: Unsicherheit darf nicht unbemerkt in den Code wandern

Exploration allein produziert noch keine gute Software. Irgendwann müssen aus möglichen Lösungen konkrete Entscheidungen werden. Genau hier liegt für mich ein wesentlicher Unterschied zwischen einem Agenten als Sparringspartner und einem Agenten als autonomem Entscheider.

Ein Modell kann Optionen entwickeln, Trade-offs erklären, meine bevorzugte Variante kritisieren und alternative Konsequenzen sichtbar machen. Die Verantwortung dafür, welche Lösung tatsächlich gebaut wird, bleibt aber beim verantwortlichen Engineering-Team.

Decide bedeutet deshalb in der Praxis deutlich mehr als die Auswahl einer Variante. Analyseergebnisse werden bewertet, mit einem starken Modell erneut gespiegelt, nachgeschärft und schließlich in einen expliziten Umsetzungsauftrag übersetzt. Dabei können mehrere Runden entstehen.

Der Punkt ist nicht, jede Kleinigkeit in ein formales Architecture Decision Record zu verwandeln. Entscheidend ist, dass die relevanten Entscheidungen vor der mechanischen Implementierung sichtbar werden.

Das setzt die Logik der vorherigen Artikel dieser Serie fort. Requirements Engineering reduziert fachliche Unschärfe. Architektur begrenzt den strukturellen Lösungsraum. Informationsschutz begrenzt Context und Fähigkeiten eines Agenten. Decide beantwortet innerhalb dieser Grenzen die nächste Frage: Welche der noch offenen Entscheidungen wollen wir jetzt tatsächlich treffen?

Je mehr davon ungeklärt in einen Coding-Auftrag gelangen, desto mehr muss der Agent selbst entscheiden. Das kann gut gehen und sogar beeindruckend plausibel aussehen. Aber dann haben wir einen Teil unseres Software Designs implizit an die Codegenerierung delegiert.

Verschieben ist noch kein Refactoring

Ein kleines Beispiel aus meiner eigenen Arbeit hat mir diese Grenze sehr deutlich gezeigt.

Ein Coding Agent hatte Business-Orchestrierung in einer UI-Komponente implementiert. Für mich war das ein sofort sichtbarer Architecture Smell. Die Komponente koordinierte Dinge, die dort nach unserem Architekturverständnis nicht hingehörten.

Ich erklärte dem Agenten also, dass diese Business-Orchestrierung aus der UI heraus müsse. Die Reaktion war formal völlig korrekt: Der Agent verschob die Logik in die Facade.

Das Problem war danach nur leider nicht gelöst.

Die Verantwortlichkeit befand sich jetzt in einer anderen Datei, die eigentliche Orchestrierung war strukturell aber weiterhin falsch geschnitten. Der Agent hatte meine sichtbare Anweisung erfüllt, ohne die dahinterliegende Architekturentscheidung neu aufzulösen.

Genau an solchen Stellen ist der Unterschied zwischen Codeproduktion und Software Engineering besonders gut sichtbar.

Einen Architecture Smell zu erkennen ist häufig leicht. Eine bessere Struktur daraus abzuleiten, ist die eigentliche Engineering-Arbeit.

Ich gehe dann bewusst zurück in Analyse und Planung. Statt mit einem weiteren Prompt nur die nächste Verschiebung anzuweisen, gebe ich den relevanten Kontext wieder an ein starkes Reasoning-Modell, lasse Verantwortlichkeiten und Abhängigkeiten untersuchen, prüfe das Ergebnis selbst und entscheide anschließend erneut.

Damit wird auch sichtbar, dass Diverge · Decide · Converge keine lineare Pipeline ist. Eine Implementierung kann neue Information erzeugen. Ein Smell kann zeigen, dass eine vermeintlich getroffene Entscheidung in Wahrheit noch nicht ausreichend getroffen war.

Dann muss der Entscheidungsraum wieder geöffnet werden.

Converge: maximale Langeweile

Wenn die wesentlichen Entscheidungen tatsächlich gefallen sind, ändert sich meine Erwartung an einen Coding Agent grundlegend. Dann möchte ich keine Überraschungen mehr.

Der Auftrag beschreibt den Scope. Agent Files erklären die Regeln. Skills oder projektspezifische Instruktionen stellen bekannte Vorgehensweisen bereit. Layering und Slicing sind definiert. Patterns existieren. Tests, Linter, Architekturregeln und weitere Verifikationsmechanismen begrenzen das Ergebnis.

Meine Idealvorstellung für den erzeugten Code lässt sich dann ziemlich einfach zusammenfassen:

Maximale Langeweile.

Kein neues Pattern, das niemand verlangt hat. Keine zusätzliche Abstraktion, weil sie irgendwie eleganter wirken könnte. Keine spontane Neuinterpretation einer Architekturgrenze und keine kreative Generalisierung eines Problems, das absichtlich lokal gelöst werden soll.

Bei einem ausreichend konvergierten Task ist Kreativität nicht zwangsläufig eine Capability. Sie kann Drift sein.

Typische Kandidaten sind Mapper, DTO-Konvertierungen, einfache Adapter, Moves und Renames, mechanische Refactorings, klar beschriebene CRUD-Anteile oder Unit Tests nach einem bereits etablierten Pattern. Aber auch daraus darf man keine neue starre Regel machen.

Ein Unit Test kann nahezu mechanisch sein: Implementiere die Tests analog zu den bestehenden Tests dieses Use Cases. Ein anderer Auftrag kann lauten: Analysiere diesen unbekannten Algorithmus, bestimme seine relevanten Invarianten und entwickle daraus eine belastbare Teststrategie. Beides erzeugt Unit Tests. Der Entscheidungsraum ist völlig verschieden.

Dasselbe gilt für Refactoring. Das Umbenennen und Verschieben bereits eindeutig identifizierter Strukturen ist etwas anderes als die Frage, welche Struktur fachlich und architektonisch sinnvoll wäre.

Der Tasktyp ist deshalb für mich höchstens ein Proxy.

Die eigentliche Frage ist also nicht, welchen Dateityp oder welches Artefakt wir erzeugen, sondern wie viel Exploration, Judgment und Verifikation die verbleibende Aufgabe tatsächlich benötigt.

Model Routing folgt dem Entscheidungsraum

Ein kleineres, schnelleres oder günstigeres Modell wird für mich dann interessant, wenn die relevanten Entscheidungen bereits gefallen sind, das vorhandene Pattern klar ist, der Auftrag überschaubar bleibt und das Ergebnis gut überprüft werden kann.

Ein starkes Modell wird wichtiger, sobald mehrere fachlich plausible Lösungen existieren, Ursachen unbekannt sind, Architektur verändert wird, große Teile eines Systems verstanden werden müssen oder komplexe Trade-offs bewertet werden sollen.

Das bedeutet ausdrücklich nicht, dass kleinere Modelle deterministisch wären. Sie können halluzinieren, Regeln übersehen, einen einfachen Auftrag falsch verstehen oder trotz guter Vorgaben in eine falsche Richtung laufen. Der kleinere Entscheidungsraum verändert nicht die Natur des Modells. Er verändert die Anforderungen an seine Arbeit.

Ein kleiner Entscheidungsraum reduziert die Menge an Exploration und Judgment, die eine Aufgabe benötigt.

Ein günstiges Modell wird deshalb nicht dadurch wirtschaftlich, dass wir ihm schwierige Entscheidungen schlecht überlassen. Es wird wirtschaftlich, wenn wir die schwierigen Entscheidungen vorher aus seinem Auftrag entfernen.

Dazu gehört für mich eine weitere Regel: Stop statt Raten.

Wenn ein Agent während der Umsetzung auf eine notwendige, aber nicht getroffene Architekturentscheidung stößt, möchte ich nicht, dass er die wahrscheinlichste Variante errät. Wenn ein Contract unklar ist, möchte ich keinen erfundenen Contract. Und wenn zwei bestehende Patterns miteinander konkurrieren und aus dem Auftrag nicht hervorgeht, welches fortgeführt werden soll, ist genau das neue Information.

Der richtige nächste Schritt ist dann nicht mehr Converge. Der Entscheidungsraum hat sich wieder geöffnet. Das gilt unabhängig davon, ob gerade ein kleines oder ein großes Modell arbeitet.

Mein Workflow ist ein Loop

In der Praxis sieht meine Arbeit deshalb inzwischen anders aus als noch vor wenigen Jahren.

Ich war lange leidenschaftlicher Entwickler. Auch als Tech Lead und später als Softwarearchitekt habe ich immer selbst implementiert. Coding war für mich nie nur das notwendige Mittel, um Architektur sichtbar zu machen. Es war ein Teil dessen, was mir an Softwareentwicklung Spaß gemacht hat.

Heute schreibe ich erstaunlich wenig Code selbst. Stattdessen verbringe ich viel Zeit damit, Probleme zu verstehen, Requirements zu klären, Lösungsräume zu analysieren, Architekturentscheidungen zu treffen, Constraints zu formulieren, Arbeitsaufträge zu definieren, Agenten implementieren zu lassen und deren Ergebnisse zu verstehen und zu überprüfen.

Ein realer Auftrag besteht bei mir inzwischen typischerweise aus mehreren Schleifen: Zunächst versuche ich, Ticket und fachliches Problem selbst zu verstehen und daraus einen Analyseauftrag zu formulieren. Ein starkes Modell analysiert System und Problem. Ich bewerte das Ergebnis, spiele es erneut zurück und schärfe so lange nach, bis daraus belastbare Arbeitsaufträge entstehen. Erst dann implementiert ein Coding Agent.

Auch nach der Implementierung endet dieser Prozess nicht. Ich bewerte das Ergebnis selbst und spiele jeden wesentlichen Ergebnisschritt wieder an ein starkes Modell zurück. Darauf folgen fachliches und technisches Review, gegebenenfalls ein Korrekturauftrag, erneute Implementierung und Verifikation. Erst wenn diese Schleife sauber abgeschlossen ist, folgt der Commit.

Ein Detail daran ist mir wichtig: Ich spiele Ergebnisse nicht erst dann an das starke Modell zurück, wenn ich bereits einen Fehler gefunden habe. Ich tue das bei jedem wesentlichen Ergebnisschritt.

Ich reviewe selbst und nutze das Modell danach als zusätzlichen Review-Kanal. Der Grund ist banal: Auch nach vielen Jahren Softwareentwicklung und Architektur übersehe ich Dinge. Und auch ein starkes Modell übersieht Dinge.

Human Review ersetzt Model Review nicht. Model Review ersetzt Human Review nicht.

Ich behaupte nicht, damit eine wissenschaftlich optimale Arbeitsweise gefunden zu haben. Es ist mein momentaner Workflow. Er ist aber eine direkte Konsequenz aus einem Problem, das im Artikel Überzeugend falsch dieser Serie bereits eine Rolle gespielt hat: Plausibilität ist keine Verifikation.

Ein Diff kann vernünftig aussehen und trotzdem fachlich falsch sein. Ein Modellreview kann überzeugend klingen und trotzdem etwas übersehen. Ein erfahrener Entwickler kann einen Patch verstehen und dennoch eine Wechselwirkung nicht bemerken. Qualität entsteht für mich deshalb zunehmend aus mehreren unabhängigen Kontrollmechanismen: eigenes Verständnis, Modellreview, Tests, statische Regeln und dort, wo es möglich ist, reproduzierbare fachliche Verifikation.

Gute Architektur verkürzt die Vorgeschichte einer Änderung

An dieser Stelle wird eine Verbindung sichtbar, die ich in meiner täglichen Arbeit immer stärker wahrnehme: Ein simples CRUD-Feature ist nicht automatisch ein simpler Agentenauftrag.

Nehmen wir eine fachlich banale Kommentarfunktion. In einem Greenfield-System mit klarer Boundary, bekanntem Layering, etabliertem Slice, vorhandenen CRUD-Patterns und eindeutigen Contracts kann die Aufgabe tatsächlich schnell konvergieren. Der Agent muss nicht erst rekonstruieren, wo das Feature hingehört oder welches der vorhandenen Patterns zufällig das richtige ist.

In einem gewachsenen Legacy-System beginnt dieselbe fachliche Funktion häufig viel früher. Zuerst muss geklärt werden, welcher bestehende Teil des Systems überhaupt verantwortlich ist. Dann tauchen konkurrierende Strukturen auf, Abhängigkeiten müssen rekonstruiert werden und gleichzeitig soll das neue Feature nicht noch mehr Legacy fortschreiben. Unter Umständen muss zunächst eine Grenze gefunden werden, an der die bestehenden Strukturen abgefangen werden können.

In meiner Praxis kann dieser Teil Stunden dauern. Nicht weil das spätere CRUD kompliziert wäre, sondern weil vor der Implementierung erst ein belastbarer Entscheidungsraum hergestellt werden muss.

Das ist zunächst persönliche Erfahrung. Die angrenzende Forschung zu Repository-Struktur und Context Retrieval samt ihren Grenzen habe ich in Artikel 08 – Architektur als Constraint eingeordnet. Für Diverge · Decide · Converge ist daran die operative Frage wichtig: Welche strukturellen Entscheidungen müssen noch geklärt werden, bevor der Auftrag in die Umsetzung gehen kann?

Gute Architektur macht den Agenten nicht intelligenter. Sie kann die Arbeit reduzieren, die notwendig ist, bevor sinnvoll implementiert werden kann.

Ownership, Boundaries, Layering, Contracts, Tests und Architekturregeln sind deshalb nicht nur Wartbarkeitsinstrumente für Menschen. Sie sind Orientierung. Und Orientierung reduziert den Teil der Arbeit, in dem ein Agent erst rekonstruieren muss, was wir eigentlich gemeint haben.

Zeit ist dabei mindestens so interessant wie Tokens. Ein langer Analyse-Loop kostet Agentlaufzeit, Context, Modellnutzung, Lesen, Reviews, Nachschärfung und menschliche Aufmerksamkeit. Der teuerste Teil eines schlecht definierten Tasks kann deshalb am Ende gar nicht die Codegenerierung sein, sondern die Arbeit, die notwendig ist, bevor überhaupt klar ist, welcher Code entstehen soll.

Die vollständige ökonomische Betrachtung verdient einen eigenen Artikel. Für diesen reicht zunächst die Feststellung, dass der offene Entscheidungsraum nicht nur ein Qualitätsproblem ist. Er ist auch ein Kostenfaktor.

Model Routing wird wirtschaftlich relevant

Wie groß die Unterschiede inzwischen sein können, zeigt bereits ein kurzer Blick auf aktuelle Preisstrukturen.

Stand 10. September 2026 listet OpenAI für ChatGPT Work und Codex beispielsweise GPT-5.6 Luna mit 0,20 US-Dollar pro Million Input- und 1,20 US-Dollar pro Million Output-Tokens, GPT-5.6 Sol mit 4 beziehungsweise 20 US-Dollar als zeitlich begrenztem Aktionspreis und GPT-6 Astra mit 10 beziehungsweise 50 US-Dollar. Innerhalb desselben Produktökosystems liegen damit zwischen Modellklassen Größenordnungen, die bei hoher Agentennutzung wirtschaftlich relevant werden. OpenAI: Enterprise Rate Card; ergänzend die Sol-Modellseite mit Promotionshinweis.

Bei Anthropic zeigt sich dasselbe Prinzip: Die aktuelle API-Preisliste reicht unter anderem von Claude Haiku 4.5 mit 1/5 US-Dollar pro Million Input-/Output-Tokens über Claude Sonnet 5 mit 2/10 bis zu Claude Fable 5.1 mit 10/50. Diese Zahlen sind Momentaufnahmen vom 10. September 2026, keine Qualitätsrangliste und schon gar keine dauerhafte Empfehlung für bestimmte Aufgaben. Anthropic: API-Preisliste.

Auch Reasoning ist differenzierter als ein einfacher Preis-Multiplikator. OpenAI berechnet bei GPT-5.6 in der genannten Enterprise-Tarifstruktur für verschiedene Reasoning-Stufen denselben Preis pro Token. Das bedeutet aber nicht, dass unterschiedliche Reasoning-Stufen denselben Gesamtverbrauch erzeugen. GitHub weist in seiner aktuellen Copilot-Dokumentation explizit darauf hin, dass höhere Reasoning-Level mehr Tokens und damit mehr Credits verbrauchen können. Einheitspreis und tatsächlicher Verbrauch sind zwei verschiedene Dinge.

Genau diesen Mechanismus spüre ich privat unmittelbar. Für einen einzelnen mechanischen Task mag die Differenz banal wirken. Bei hoher Agentennutzung entscheidet sie irgendwann darüber, ob ein Kontingent nach zwei Tagen oder nach einer Woche aufgebraucht ist.

Und die Industrie beginnt bereits, darauf zu reagieren.

GitHub Copilot besitzt inzwischen eine automatische Modellauswahl mit Task Optimization. Laut GitHub bewertet der Router unter anderem die Task-Komplexität und die aktuelle Modellverfügbarkeit und versucht, teurere Reasoning-Modelle für Aufgaben zu reservieren, die diese zusätzliche Kapazität benötigen, während einfachere Aufgaben an schnellere und günstigere Modelle geroutet werden.

GitHubs eigene Empfehlungen gehen inzwischen sogar explizit in Richtung research, plan, then implement: Planung mit stärkerem Reasoning, fokussierte Umsetzung anschließend mit einem für die Execution geeigneten Modell. Außerdem empfiehlt GitHub günstigere Modelle für klar begrenzte Subagents und weist darauf hin, dass präzise Instruktionen und Repository-Maps unnötige Exploration reduzieren können.

Model Routing ist damit keine rein theoretische Zukunftsidee mehr. Trotzdem würde ich diese Automatisierung nicht mit meinem eigentlichen Decide-Schritt verwechseln.

Ein Router kann aus einem Prompt abschätzen, wie komplex eine Aufgabe wirkt. Er weiß deshalb noch lange nicht, welche Architekturentscheidung in meinem Unternehmen zulässig ist, ob zwei vorhandene Patterns historische Altlasten oder bewusst unterschiedliche Varianten sind oder ob eine Abweichung vom bestehenden Pattern gerade erwünscht ist. Und er weiß auch nicht zuverlässig, welche relevante Entscheidung bereits getroffen wurde, wenn sie nicht als Context oder Constraint sichtbar gemacht wurde.

Automatisches Model Routing ersetzt nicht die Definition des Entscheidungsraums.

Es optimiert innerhalb dessen, was wir dem System sichtbar machen.

Lokale Modelle erweitern den Lösungsraum

Model Routing wird noch interessanter, wenn neben Cloud-Modellen auch lokal betreibbare Modelle relevant werden.

Ein aktuelles Beispiel ist Qwen3.8-27B, das Alibaba am 14. August 2026 als Open-Weight-Modell veröffentlicht hat. Das dichte Modell besitzt 27 Milliarden Sprachmodellparameter, unterstützt unterschiedliche Reasoning-Einstellungen und steht unter Apache 2.0 zur Verfügung.

Die vom Hersteller veröffentlichten Coding-Benchmarks sind bemerkenswert: Auf seiner Model Card nennt Qwen beispielsweise 61,7 Prozent auf SWE-bench Pro und 73,0 auf Terminal-Bench 2.1 unter den jeweils beschriebenen Evaluationsbedingungen. Diese Werte sind Herstellerbenchmarks und sollten genau so gelesen werden.

Mittlerweile existieren zusätzlich unabhängige Messungen von Artificial Analysis. Auch dort gehört Qwen3.8-27B innerhalb seiner Open-Weight-Größenklasse zu den leistungsfähigen Modellen. Gleichzeitig zeigt die Evaluation einen für Model Routing interessanten Trade-off: Die Variante mit maximalem Reasoning produziert sehr viel Reasoning-Output und ist im Vergleich deutlich langsamer und ausführlicher. Mehr Reasoning ist also auch bei einem lokal verfügbaren Modell keine kostenlose Abstraktion.

Eigene belastbare Praxiserfahrung habe ich mit Qwen3.8-27B bisher nicht. Ich verfolge den aktuellen Hype deshalb mit Interesse und einer gewissen Skepsis. Modelle dieser Klasse zeigen zumindest, dass lokal betreibbare Systeme inzwischen eine Leistungskategorie erreichen, bei der ihr Einsatz für klar begrenzte Softwareaufgaben ernsthaft diskutiert werden kann. Mehr würde ich daraus momentan nicht ableiten.

Insbesondere bedeutet lokal nicht kostenlos. Lokal verschiebt die Kostenstruktur, statt sie aufzulösen. Hardware, Betrieb und Auslastung sowie die Frage, wann sich welche Variante rechnet, behandelt Artikel 13 – Die Ökonomie von Agentic Work.

Eine Specification schließt den Entscheidungsraum nicht automatisch

An diesem Punkt liegt ein mögliches Missverständnis nahe. Wenn ein kleiner Entscheidungsraum die Implementation einfacher macht, könnte man daraus eine sehr alte Softwareidee in neuem Gewand ableiten: Wir schreiben nur ein großes Pflichtenheft, geben es dem Agenten und erhalten hinten das fertige Produkt.

Das funktioniert nicht.

Eine Specification kann sehr groß und gleichzeitig voller offener Entscheidungen sein. Zwischen fachlicher Beschreibung und funktionierendem System können Architektur, Ownership, Datenmodell, UX, Fehlerverhalten, Security, Betriebsverhalten, Integrationsstrategie und Teststrategie weiterhin ungeklärt sein. Diese Entscheidungen verschwinden nicht dadurch, dass das Requirement-Dokument hundert Seiten lang ist. Wenn niemand sie explizit trifft, werden sie während der Umsetzung getroffen – dann eben vom Agenten.

Eine große Specification ist nicht automatisch ein kleiner Entscheidungsraum.

Spec Driven Development bedeutet für mich deshalb nicht, Unsicherheit in ein größeres Dokument zu kippen und anschließend auf deterministische Codegenerierung zu hoffen. Eine gute Specification reduziert Entscheidungen dort, wo sie tatsächlich getroffen wurden. Architecture Constraints reduzieren weitere. Contracts reduzieren weitere. Tests und Verifikationsregeln reduzieren weitere.

Erst dadurch konvergiert der Auftrag.

Genau an diesem Punkt treffen sich die bisherigen Artikel dieser Serie. Requirements Engineering begrenzt den fachlichen Lösungsraum. Architektur begrenzt den strukturellen Lösungsraum. Informationsschutz begrenzt Context und Aktionsmöglichkeiten. Und innerhalb dieses zunehmend definierten Raums entscheiden wir bewusst, wann wir Varianz erzeugen und wann wir sie reduzieren wollen.

Wenn Codeproduktion billiger wird

Mein eigener Rollenwechsel ist dabei vielleicht der Teil, an den ich mich am stärksten gewöhnen musste.

Ich schreibe gern Code. Ich habe einen großen Teil meiner beruflichen Identität darüber aufgebaut, schwierige technische Probleme selbst implementieren zu können. Deshalb kann ich auch nachvollziehen, warum viele Entwickler der Automatisierung von Codeproduktion anders begegnen als einem neuen Refactoring-Werkzeug in der IDE. Wenn man zwanzig Jahre darin investiert hat, besonders gut Code schreiben zu können, ist es keine völlig neutrale Erfahrung, wenn genau diese Tätigkeit zunehmend automatisierbar wird.

Ich halte daraus trotzdem keine Untergangsgeschichte für Entwickler für sinnvoll. Meine persönliche Beobachtung ist eine andere:

Die Codeproduktion verschiebt sich zunehmend vom Menschen zum Agenten. Dadurch steigt der relative Wert der eigentlichen Software-Engineering-Disziplinen.

Problemverständnis, Requirements Engineering, Architektur, Modellierung, Testing, Security, Verifikation und technische Entscheidungsfähigkeit sind keine neuen Tätigkeiten. Wir konnten sie nur lange mit der sichtbarsten Tätigkeit unserer Branche verwechseln: Code schreiben.

Vielleicht müssen wir wieder etwas mehr Software Engineering lernen und etwas weniger stolz darauf sein, besonders schnell Code produzieren zu können. Denn wenn Codeproduktion billiger wird, steigt der relative Wert der Fähigkeiten, die entscheiden, welcher Code überhaupt entstehen sollte.

Für mich bedeutet Agentic Coding deshalb heute nicht, Coding einfach an ein Modell abzugeben. Es bedeutet, den Entscheidungsraum bewusst zu steuern: Exploration dort zuzulassen, wo wir sie brauchen, Entscheidungen dort zu treffen, wo Verantwortung notwendig ist, und Varianz dort zu reduzieren, wo die Entscheidung bereits gefallen ist.

Und wenn während der Umsetzung eine neue relevante Unsicherheit auftaucht, gehen wir zurück. Der Loop beginnt erneut.

Software Engineering braucht unterschiedliche Mengen an Varianz zu unterschiedlichen Zeitpunkten.

Diverge, wenn du noch nicht weißt, was die richtige Lösung ist. Decide, bevor diese Unsicherheit in den Code wandert. Converge, wenn die Entscheidung gefallen ist.

Coding ist zunehmend delegierbar. Software Engineering bleibt die Disziplin, die entscheidet, was entstehen soll, welche Grenzen gelten und ob das Ergebnis tatsächlich gut ist.

Quellen und Einordnung

• GitHub Copilot – Auto Model Selection und Efficiency Guidance: GitHub dokumentiert im September 2026 produktives Routing anhand von Task-Komplexität, Kosten- und Verfügbarkeitsaspekten und empfiehlt unterschiedliche Modellkapazitäten sowie Reasoning-Stufen für unterschiedlich offene beziehungsweise schwierige Aufgaben. Diese Produktlogik zeigt, dass Model Routing bereits praktisch eingesetzt wird; sie kennt jedoch nicht automatisch die fachlichen und architektonischen Entscheidungen eines konkreten Unternehmens.
• OpenAI und Anthropic – aktuelle Modellpreise: Die offiziellen Preislisten zeigen erhebliche Unterschiede zwischen Modellklassen. Die oben verlinkten Preislisten und Modellseiten wurden am 10. September 2026 abgerufen. GPT-5.6 Sol ist als Promotion ausgewiesen, laut OpenAI mindestens bis zum 21. November 2026. Die Preise sind keine langfristig stabilen Relationen.
• Qwen3.8-27B: Veröffentlichung, Architektur, Lizenz und die genannten Coding-Benchmarks stammen aus den offiziellen Qwen-Unterlagen; die Coding-Scores sind daher als Herstellerbenchmarks einzuordnen. Artificial Analysis liefert zusätzliche unabhängige Messungen und zeigt neben hoher Leistungsfähigkeit insbesondere die hohen Reasoning-Tokenmengen der maximalen Reasoning-Konfiguration. Eigene praktische Erfahrung mit dem Modell liegt diesem Artikel nicht zugrunde.