Agentic Engineering: Was wird aus Microservices und SCS?

Noch vor einem Jahr prognostizierte Dario Amodei, CEO von Anthropic, dass KI innerhalb von 12 Monaten praktisch den gesamten Code schreiben werde. Grady Booch verglich den Aufstieg von KI-Programmier-Agents mit der Einführung von Compilern zu Zeiten von Grace Hopper. Und Boris Cherny berichtet im Februar 2026, dass bei ihm inzwischen Produktmanager:innen, Data Scientists und User Researcher:innen selbst programmieren. Doch was bedeutet das konkret für Architekturentscheidungen? Auf der DevLand 2026 im Europapark Rust haben wir genau diese Frage gestellt: Was wird aus Microservices und Self-Contained-Systems im Zeitalter von Agentic Engineering?

Warum Microservices und SCS entstanden sind

Bevor wir nach vorne schauen, lohnt ein Blick zurück. Microservices und Self-Contained-Systems (SCS) sind als Antwort auf sehr reale Probleme entstanden: Monolithische Architekturen, die unter Conway's Law litten und bei denen Änderbarkeit zum Albtraum wurde. Die Kernideen waren dabei: Bounded Contexts aus Domain-Driven Design als fachliche Schnittlinien nutzen, Komplexität durch Teile-und-herrsche beherrschbar machen, Entkopplung und Änderbarkeit sicherstellen und Teams technologische Autonomie geben. Parallel dazu haben sich Agile-Methoden und DevSecOps durchgesetzt – als Antwort auf das strukturelle Versagen des Wasserfallmodells, auf organisationale Silos und mit dem Ziel, Kommunikation und Kontext zu optimieren. Das Inverse Conway Maneuver aus den Team Topologies zeigt, wie Teamstrukturen bewusst so geschnitten werden, dass die gewünschte Architektur entsteht. Diese Prinzipien bleiben weiterhin gültig. Doch die Rahmenbedingungen verändern sich gerade fundamental.

Drei Phasen der KI-gestützten Entwicklung

Wir beobachten eine klare Evolution in drei Phasen: Phase 1 – AI Assisted Coding: KI unterstützt beim Schreiben von Code. Autocomplete, Vorschläge, Erklärungen. Der Mensch bleibt am Steuer. Phase 2 – Vibe-Coding / Agentic Coding: KI-Agents übernehmen größere Aufgaben. Fachabteilungen erstellen eigene Dashboards und Prototypen. Low-Code-Plattformen bekommen Konkurrenz durch individuell generierte Lösungen. Phase 3 – Agentic Engineering: Hier stehen wir jetzt. Agents planen selbstständig, unterteilen Aufgaben und iterieren autonom. Das bringt mehrere neue Merkmale mit sich, die wir in der Praxis täglich erleben: Der Verlust von Steuerbarkeit ist real – Agents ohne ausreichenden Kontext und klare Leitplanken brechen aus und produzieren statistisch wahrscheinlichen, aber nicht zwingend richtigen Code. Der Entwicklungsdruck nimmt rasant zu, weil Agents jederzeit verfügbar sind und sich ständig weiterentwickeln. Menschliche Kommunikation und Reaktionszeiten werden scheinbar zum Engpass. Und viele Entwickler:innen spüren einen Identitätsverlust – das Berufsbild verändert sich grundlegend. Der entscheidende Shift: Der Fokus bewegt sich vom WIE zum WAS. Früher fragten wir uns „Wie implementiere ich Feature XY?" und dachten in Algorithmen, Patterns und Syntax. Heute lautet die Frage: „Was sind die nächsten Anweisungen für die Coding-Agents? Wie stelle ich sicher, dass sie ihre Ergebnisse selbst validieren?"

Context Engineering: Die richtige Information zur richtigen Zeit

Andrej Karpathy hat es treffend formuliert: Context Engineering sei die Kunst, das Context Window mit genau den richtigen Informationen zur richtigen Zeit zu füllen. Das Context Window eines Agents besteht aus statischen und dynamischen Bestandteilen. Auf der statischen Seite – einmal pro Projekt definiert – stehen der System Prompt mit grundlegenden Anweisungen und Verhaltensregeln, die AGENTS.md mit projektspezifischen Regeln, Konventionen und Architektur-Vorgaben sowie die verfügbaren Tools und MCPs für Dateizugriff, Terminal, Browser und APIs. Dynamisch pro Session kommen hinzu: der Codebase-Kontext aus gelesenen Dateien und Abhängigkeiten, der aktuelle User-Prompt und die bisherige Konversation mit Entscheidungen und Zwischenergebnissen. In der Praxis bedeutet das ein bewusstes Context Window Management. In einer ersten Session lässt du den Agent die Codebasis analysieren, Anforderungen validieren und Inkonsistenzen aufdecken. Das Ergebnis wird in einer feature+research.md als Zwischenergebnis festgehalten – mit klar spezifizierten Anforderungen, abgestimmten Testszenarien und dem aktuellen Systemstand. In einer neuen Session wird dieses Dokument dann als Kontext geladen und der Agent kann mit einem frischen Context Window die eigentliche Implementierung durchführen. Dieses Muster – Research-Phase und Implementierungs-Phase in getrennten Sessions – verhindert, dass der Kontext überladen wird und der Agent die Orientierung verliert.

Harness Engineering: Leitplanken für autonome Agents

Der Begriff Harness stammt aus der Pferdehaltung – Zaumzeug, Sattel, Gebiss – die vollständige Ausrüstung, um ein mächtiges, aber unberechenbares Tier in die richtige Richtung zu lenken. Mitchell Hashimoto hat dieses Bild auf die Softwareentwicklung übertragen, und es trifft den Kern. Harness Engineering beantwortet die Frage: Wie designe ich ein System, in dem Agents zuverlässig guten Code produzieren? Die Bausteine dafür sind klare Spezifikationen wie OpenAPI, AsyncAPI und Architecture Decision Records, deterministische CI-Pipelines, Test-Suites als Sicherheitsnetz, reproduzierbare Dev-Umgebungen, Observability für Agentenläufe und Architektur- sowie Security-Guardrails. Die zentrale Erkenntnis dabei: Nicht das Modell ist kritisch – die Qualität des Harness entscheidet über die Qualität der Ergebnisse.

Spec-Driven Development: Code als Ableitung

Im Zusammenspiel mit Context und Harness Engineering entsteht ein neuer Entwicklungsansatz: Spec-Driven Development. Dabei wird eine formale, maschinenlesbare Spezifikation zur primären Quelle der Wahrheit – vor der Implementierung. Die Konsequenzen sind weitreichend: Guidelines werden maschinenlesbar formuliert, die Spezifikation wird zum primären Artefakt, Repositories enthalten Spezifikationen für verschiedene Aspekte und Code wird zur Ableitung statt zum Ausgangspunkt. Der Zyklus läuft dann: SPEC → Generate Plan → Validate → Implement → Review → Refine SPEC. Dieser Kreislauf passt perfekt zu agentenbasierter Entwicklung, weil jeder Schritt gegen die Spezifikation validiert werden kann.

Die neue Rolle der Engineers

Disziplinen werden verschmelzen. Aus dem klassischen „Coder" entstehen neue Rollen: System-Designer:in, Context-Engineer:in, Harness-Builder:in und Qualitäts-Orchestrator:in. Die Kernkompetenzen 2026 verschieben sich entsprechend. Präzise Spezifikation – also die Fähigkeit, klare Anforderungen und gute Context-Anweisungen zu formulieren – wird zentral. Architekturverständnis bleibt essenziell, denn jemand muss Systeme ganzheitlich denken und strukturelle Entscheidungen treffen. Testdesign gewinnt an Bedeutung als Qualitätssicherung durch gezielte Tests und Validierung. Und die kritische Bewertung von AI-Outputs wird zur täglichen Kernaufgabe.

Der Blast-Radius von Fehlern

Eine wichtige Warnung: Das Denken darf nicht outgesourct werden. Denn der Blast-Radius von Fehlern wächst mit der Abstraktionsebene. Ein Fehler im Implementierungsplan führt zu einigen Zeilen schlechten Codes – ärgerlich, aber reparabel. Ein Fehler im Systemverständnis führt zu falschen Architekturentscheidungen – schon deutlich teurer. Ein Fehler in der Anforderungs-Spezifikation führt dazu, dass das falsche Problem gelöst wird – verschwendete Arbeit im großen Stil. Und ein Fehler im Agenten-Ausführungsrahmen führt zu chaotischen Entwicklungsabläufen – das betrifft dann alles.

Zukunftsbilder: Digital Product Factory und On-The-Fly Computing

Wohin kann die Reise gehen? Wir sehen zwei mögliche Zukunftsbilder. Die Digital Product Factory beschreibt eine Welt, in der Architekturmuster und Qualitätsstandards einmal definiert und dann konsequent durchgesetzt werden. Interdisziplinäre Teams nutzen ein Agentic-Engineering-Ökosystem, um passgenau Software zu generieren. Cloud-Plattformen werden durch Agents betrieben und austauschbar. Integration erfolgt auf Basis von Spezifikationsstandards und einem Service-Katalog. Noch weiter gedacht: On-The-Fly Computing. Spezifische Agents in dedizierten Sandbox-Instanzen kommunizieren untereinander und mit bestehenden Systemen. Sie erzeugen selbstständig Schnittstellen, Code und Werkzeuge. User-Interfaces und Logik entstehen on-the-fly für die jeweilige Aktion.

Strategische Implikationen

Agentic Engineering ist kein Tool-Upgrade. Es ist eine fundamentale Veränderung – von der Software-Manufaktur hin zu einem industrialisierten Produktionsprozess. Wir brauchen ein Shift-Left-Left: Der gesamte Softwareentwicklungsprozess wird unter direkter Mitwirkung der Bedarfsträger:innen produziert. Nicht nur Entwickler:innen und Architekt:innen sind betroffen, sondern auch Produkt-Owner, Fachabteilungen und die gesamte Organisation. Architekturmodelle wie Microservices und SCS bilden dabei nützliches „Geschirrzeug" für die agentische Produktion. Sie sind nicht der heilige Gral – aber sie werden einfach spezifiziert und liefern genau die Struktur, die Agents brauchen, um innerhalb sinnvoller Grenzen zu arbeiten. Und eine provokante Frage zum Schluss: Haben Cloud-, SaaS- und Low-Code-Plattformen angesichts dieser neuen Möglichkeiten noch den gleichen Stellenwert wie vor drei Jahren in einer IT-Strategie? Die Antwort darauf wird jedes Unternehmen für sich finden müssen. Sicher ist nur: Die Veränderung ist da und sie beschleunigt sich.