Agentic Work in Real Life

LLMs und Coding Agents verändern die Softwareentwicklung. Darüber besteht inzwischen kaum noch Zweifel. Sehr viel schwieriger ist die Frage, was davon tatsächlich funktioniert, warum es funktioniert und wo die Grenzen liegen.

Wer Diskussionen über AI verfolgt, trifft schnell auf zwei Extreme. Auf der einen Seite steht die Vorstellung, dass LLMs Entwickler in kurzer Zeit weitgehend ersetzen werden. Auf der anderen Seite werden sie als glorifiziertes Autocomplete abgetan, das hauptsächlich überzeugend klingenden Unsinn produziert.

Diese Serie möchte sich bewusst in keinem dieser Lager einordnen.

Sie ist weder ein Plädoyer für AI noch eines dagegen. Und sie ist auch keine Sammlung vermeintlich perfekter Prompts.

Es geht um Agentic Work in Real Life: um Erfahrungen aus der tatsächlichen Arbeit mit LLMs und Coding Agents, um die Mechanismen dahinter und um die Konsequenzen für professionelles Software Engineering.

Was können diese Systeme wirklich?

Dafür müssen wir zunächst verstehen, womit wir überhaupt arbeiten.

Was ist ein LLM? Was bedeutet Inference? Was sind Tokens, Context, Memory oder Skills? Warum liefert dieselbe Aufgabe nicht zwangsläufig dieselbe Lösung? Was misst ein SWE-bench-Score eigentlich – und was gerade nicht?

Viele Begriffe rund um AI werden inzwischen selbstverständlich verwendet, obwohl ihre Bedeutung häufig nur ungefähr bekannt ist. Gleichzeitig entstehen daraus weitreichende Aussagen über Produktivität, Qualität und sogar die Zukunft ganzer Berufsgruppen.

Deshalb beginnt diese Serie bewusst bei den Grundlagen.

Nicht, um Machine Learning bis ins mathematische Detail zu erklären, sondern um ein belastbares mentales Modell dafür zu entwickeln, warum LLMs sich so verhalten, wie sie sich verhalten.

Was bedeutet „funktioniert“?

Coding Agents können heute in erstaunlicher Geschwindigkeit Code erzeugen.

Aber Geschwindigkeit sagt wenig über Qualität aus.

Eine Lösung kann funktionieren und trotzdem schlecht sein. Sie kann unnötig koppeln, fachliche Regeln an der falschen Stelle implementieren, bestehende Architektur verletzen, schwer wartbar sein oder langfristig hohe Kosten verursachen.

„Funktioniert“ ist deshalb nur die unterste Qualitätsstufe.

Interessanter wird die Frage:

Was ist eine gute Lösung – und wer kann das beurteilen?

Je billiger die reine Codeproduktion wird, desto stärker verschiebt sich der Engpass in Richtung Requirements, Architektur, Planung, Review und Verifikation.

Damit verändert sich auch die Rolle erfahrener Entwickler.

Alte Probleme unter neuen Bedingungen

Viele vermeintlich neue AI-Probleme sind erstaunlich alte Probleme des Software Engineerings.

Unklare Requirements waren schon immer gefährlich. Schlechte Architektur wurde schon immer kopiert. Implizites Wissen war schon immer ein Risiko. Eine falsche Annahme konnte schon immer weitere falsche Entscheidungen nach sich ziehen.

Coding Agents verändern jedoch Geschwindigkeit und Größenordnung.

Ein Mensch benötigt vielleicht Tage, um auf einer falschen Annahme eine umfangreiche Implementierung aufzubauen. Ein Agent kann innerhalb kurzer Zeit dutzende Dateien konsistent anpassen, Tests ergänzen und damit eine falsche Interpretation tief im System verankern.

Das macht Requirements Engineering, Architektur und Verifikation nicht überflüssig.

Im Gegenteil: Möglicherweise werden sie wichtiger.

Stand Ende 2026

Diese Serie ist eine Bestandsaufnahme Stand Ende 2026.

Das ist bei diesem Thema wichtig.

LLMs haben sich innerhalb weniger Jahre enorm weiterentwickelt. Fähigkeiten, die heute noch als Grenze erscheinen, können in kurzer Zeit technisch gelöst oder zumindest deutlich verbessert werden.

Deshalb unterscheidet die Serie bewusst zwischen:

heute beobachtbaren Fähigkeiten und Grenzen,
grundlegenden Eigenschaften der eingesetzten Verfahren,
Ableitungen aus heutigen Entwicklungen,
und ausdrücklich gekennzeichneten Zukunftshypothesen.

Konkrete Modelle, Preise und Benchmarks dienen dabei nur als datierte Beispiele.

Die Frage, ob GPT, Claude, Qwen oder ein anderes Modell heute einige Punkte mehr auf einem Benchmark erreicht, ist wesentlich weniger interessant als die Frage, was dieser Benchmark überhaupt misst und welche Konsequenzen sich daraus für reale Softwareentwicklung ableiten lassen.

Und was passiert mit uns?

Die vielleicht schwierigsten Fragen sind nicht technischer Natur.

Wenn LLMs viele Aufgaben übernehmen können, die heute von Junior- oder Midlevel-Entwicklern erledigt werden, kann es für Unternehmen kurzfristig wirtschaftlich sinnvoll erscheinen, weniger dieser Entwickler einzustellen.

Aber Juniorarbeit war nie nur Produktionskapazität.

Sie war auch ein Lernweg.

Wenn erfahrene Entwickler zukünftig stärker zu Planern, Reviewern, Architekten und Orchestratoren werden, stellt sich eine entscheidende Frage:

Wie entstehen diese erfahrenen Entwickler, wenn wir ihnen die Lernwege dorthin nehmen?

Auch solche organisatorischen, ökonomischen und gesellschaftlichen Konsequenzen gehören für mich zu einer realistischen Betrachtung von Agentic Work.

Der Anspruch dieser Serie

Mechanismus kommt vor Meinung.

Beeindruckende Fähigkeiten werden nicht kleingeredet. Fehler werden nicht beschönigt. Menschen werden dabei genauso wenig idealisiert wie Maschinen.

Und wenn aus Beobachtungen Prognosen werden, sollen sie als solche erkennbar bleiben.

Das Ziel ist nicht, am Ende zu beweisen, dass AI gut oder schlecht für Softwareentwicklung ist.

Das Ziel ist, besser beurteilen zu können, wo sie heute sinnvoll eingesetzt werden kann, welche Voraussetzungen dafür notwendig sind und welche neuen Probleme wir uns möglicherweise gleichzeitig schaffen.

Artikel

Ergänzend führt das LLM-/Agentic-Engineering-Glossar die zentralen Begriffe der Serie zusammen.