Einordnung

Large Language Models und agentische Systeme verändern bereits heute, wie Software entsteht. Sie beschleunigen Recherche, unterstützen bei der Codeerzeugung, helfen beim Verstehen bestehender Systeme und senken die Einstiegshürden in technische Randbereiche wie CI/CD, Deployment, Docker oder Infrastruktur. Gerade deshalb ist eine nüchterne Einordnung wichtig.

Dieses Kapitel versteht LLMs zunächst als das, was sie in der Praxis sind: leistungsfähige Werkzeuge zur Verarbeitung und Erzeugung von Sprache, Code und Struktur. Sie können Muster erkennen, bestehende Informationen verdichten, Vorschläge formulieren und in vielen Fällen lokale Probleme überraschend gut lösen. Daraus folgt jedoch nicht, dass sie Softwaresysteme im architektonischen Sinn verstehen.

Agentische Systeme gehen einen Schritt weiter. Sie kombinieren ein Modell mit Kontext, Werkzeugen, Planungs- und Iterationsschleifen. Dadurch entsteht der Eindruck von Autonomie: Ein System analysiert Anforderungen, führt mehrere Schritte aus, nutzt Dateien oder APIs und erzeugt Ergebnisse, die über einzelne Antworten hinausgehen. Auch hier gilt jedoch: Mehr Orchestrierung bedeutet nicht automatisch mehr Verständnis.

Für die Einordnung ist deshalb die Unterscheidung zwischen Assistenz, Teilautonomie und Verantwortung zentral.

Assistenz bedeutet, dass ein System Vorschläge macht, erklärt, generiert oder strukturiert, während ein Mensch Ziel, Richtung und Bewertung vorgibt. Teilautonomie bedeutet, dass ein System mehrere Zwischenschritte selbst ausführt, etwa Informationen sammelt, Artefakte erzeugt oder Werkzeuge kombiniert. Verantwortung bleibt dennoch beim Menschen. Denn weder ein LLM noch ein agentisches System trägt die Folgen einer falschen Architekturentscheidung, eines unpassenden Datenmodells oder einer strategisch falschen Priorisierung.

Genau an dieser Stelle beginnt die eigentliche Grenze heutiger KI-Nutzung in der Softwareentwicklung. Funktionierender Code ist nicht dasselbe wie ein gutes System. Ein korrekt beantworteter Prompt ist nicht dasselbe wie tragfähiges Architekturdenken. Und ein automatisierter Ablauf ist nicht dasselbe wie verantwortete Produktentwicklung.

Architekturdenken bleibt notwendig, weil Softwaresysteme nicht nur aus Funktionen bestehen, sondern aus Abhängigkeiten, Schnittstellen, Datenflüssen, Qualitätsanforderungen und langfristigen Entscheidungen. Systemverständnis bleibt notwendig, weil sich die eigentlichen Schwierigkeiten größerer Systeme selten im einzelnen Codefragment zeigen, sondern in ihren Wechselwirkungen. Priorisierung bleibt notwendig, weil Software nicht nur technisch, sondern immer auch wirtschaftlich, organisatorisch und fachlich eingebettet ist.

Dieses Kapitel betrachtet LLMs und agentische Systeme deshalb weder als Bedrohung noch als Heilsversprechen. Es behandelt sie als Werkzeuge mit klaren Stärken, realen Grenzen und erheblichen Auswirkungen auf Entwicklungsprozesse, Architekturarbeit und Organisationsdynamik.

Die leitende Perspektive ist dabei einfach:

LLMs können Entwicklungsarbeit wirksam unterstützen.
Sie ersetzen jedoch weder Architekturverantwortung noch Systemverständnis.

Von dieser Grundposition aus lässt sich anschließend genauer betrachten, was diese Systeme sind, warum die Erwartungen oft überzogen sind, wo ihre realen Stärken liegen und an welchen Stellen ihr Einsatz neue Risiken erzeugt.--- title: Einordnung sidebar_position: 1

Einordnung

Large Language Models und agentische Systeme verändern bereits heute, wie Software entsteht. Sie beschleunigen Recherche, unterstützen bei der Codeerzeugung, helfen beim Verstehen bestehender Systeme und senken die Einstiegshürden in technische Randbereiche wie CI/CD, Deployment, Docker oder Infrastruktur. Gerade deshalb ist eine nüchterne Einordnung wichtig.

Dieses Kapitel versteht LLMs zunächst als das, was sie in der Praxis sind: leistungsfähige Werkzeuge zur Verarbeitung und Erzeugung von Sprache, Code und Struktur. Sie können Muster erkennen, bestehende Informationen verdichten, Vorschläge formulieren und in vielen Fällen lokale Probleme überraschend gut lösen. Daraus folgt jedoch nicht, dass sie Softwaresysteme im architektonischen Sinn verstehen.

Agentische Systeme gehen einen Schritt weiter. Sie kombinieren ein Modell mit Kontext, Werkzeugen, Planungs- und Iterationsschleifen. Dadurch entsteht der Eindruck von Autonomie: Ein System analysiert Anforderungen, führt mehrere Schritte aus, nutzt Dateien oder APIs und erzeugt Ergebnisse, die über einzelne Antworten hinausgehen. Auch hier gilt jedoch: Mehr Orchestrierung bedeutet nicht automatisch mehr Verständnis.

Für die Einordnung ist deshalb die Unterscheidung zwischen Assistenz, Teilautonomie und Verantwortung zentral.

Assistenz bedeutet, dass ein System Vorschläge macht, erklärt, generiert oder strukturiert, während ein Mensch Ziel, Richtung und Bewertung vorgibt. Teilautonomie bedeutet, dass ein System mehrere Zwischenschritte selbst ausführt, etwa Informationen sammelt, Artefakte erzeugt oder Werkzeuge kombiniert. Verantwortung bleibt dennoch beim Menschen. Denn weder ein LLM noch ein agentisches System trägt die Folgen einer falschen Architekturentscheidung, eines unpassenden Datenmodells oder einer strategisch falschen Priorisierung.

Genau an dieser Stelle beginnt die eigentliche Grenze heutiger KI-Nutzung in der Softwareentwicklung. Funktionierender Code ist nicht dasselbe wie ein gutes System. Ein korrekt beantworteter Prompt ist nicht dasselbe wie tragfähiges Architekturdenken. Und ein automatisierter Ablauf ist nicht dasselbe wie verantwortete Produktentwicklung.

Architekturdenken bleibt notwendig, weil Softwaresysteme nicht nur aus Funktionen bestehen, sondern aus Abhängigkeiten, Schnittstellen, Datenflüssen, Qualitätsanforderungen und langfristigen Entscheidungen. Systemverständnis bleibt notwendig, weil sich die eigentlichen Schwierigkeiten größerer Systeme selten im einzelnen Codefragment zeigen, sondern in ihren Wechselwirkungen. Priorisierung bleibt notwendig, weil Software nicht nur technisch, sondern immer auch wirtschaftlich, organisatorisch und fachlich eingebettet ist.

Dieses Kapitel betrachtet LLMs und agentische Systeme deshalb weder als Bedrohung noch als Heilsversprechen. Es behandelt sie als Werkzeuge mit klaren Stärken, realen Grenzen und erheblichen Auswirkungen auf Entwicklungsprozesse, Architekturarbeit und Organisationsdynamik.

Die leitende Perspektive ist dabei einfach:

LLMs können Entwicklungsarbeit wirksam unterstützen.
Sie ersetzen jedoch weder Architekturverantwortung noch Systemverständnis.

Von dieser Grundposition aus lässt sich anschließend genauer betrachten, was diese Systeme sind, warum die Erwartungen oft überzogen sind, wo ihre realen Stärken liegen und an welchen Stellen ihr Einsatz neue Risiken erzeugt.