Peter Pedross, CEO & Gründer, PEDCO AG – SAFe Fellow

Die Unterscheidung zwischen der Automatisierung von Arbeit und der Delegation von Entscheidungen mag auf den ersten Blick subtil erscheinen. In der Realität verändert sie jedoch grundlegend die Art und Weise, wie Engineering-Organisationen arbeiten. Traditionelle Automatisierung konzentrierte sich stets auf die Ausführung von Tätigkeiten. Build-Server kompilierten Software, automatisierte Tests validierten Funktionen, Deployment-Pipelines veröffentlichten neue Versionen und Monitoring-Plattformen erkannten operative Probleme. All diese Systeme beschleunigten die Arbeit, ohne zu verändern, wer letztlich für die technischen Entscheidungen verantwortlich blieb. Menschen definierten weiterhin die Architektur, interpretierten Anforderungen, bewerteten Zielkonflikte und bestimmten akzeptable Risiken. Agentic Engineering führt ein anderes Modell ein.

Anstatt lediglich vordefinierte Aktivitäten auszuführen, nehmen autonome Agenten zunehmend am eigentlichen Engineering-Prozess teil. Sie analysieren Anforderungen, schlagen Architekturvarianten vor, entwickeln Implementierungsstrategien, überprüfen Code, identifizieren Risiken und koordinieren Arbeiten über verschiedene Engineering-Disziplinen hinweg. Damit beginnt sich auch die Rolle des Engineers zu verändern. Anstatt jedes Artefakt direkt selbst zu erzeugen, gestalten Engineers zunehmend die Umgebung, in der autonome Systeme erfolgreich arbeiten können. Dies ist ein wichtiger Unterschied, denn Engineering verschiebt sich schrittweise von der Ausführung von Arbeit hin zur Gestaltung von Entscheidungssystemen.

In unseren eigenen Vorhaben haben wir wiederholt beobachtet, dass die erste von einem autonomen Agenten vorgeschlagene Implementierung nur selten die endgültige Lösung darstellt. Der eigentliche Mehrwert entsteht durch den kontinuierlichen Dialog.

  • Ein Agent schlägt einen Architekturansatz vor.
  • Ein Architekt hinterfragt eine Annahme.
  • Der Agent überarbeitet seinen Vorschlag.
  • Zusätzlicher Kontext wird verfügbar.
  • Die Lösung verbessert sich.

Diese Interaktion ähnelt der Zusammenarbeit zwischen erfahrenen Engineers deutlich stärker als einer klassischen Befehls- und Antwortbeziehung mit einem Softwarewerkzeug. Je leistungsfähiger Agenten werden, desto stärker wird Engineering zu einem Gespräch. Die Qualität dieses Gesprächs hängt dabei weit weniger von Prompting-Techniken ab als von der Qualität des gemeinsamen Engineering-Kontexts.

  • Architekturbeschreibungen.
  • Solution Intent
  • Architecture Decision Records
  • Arbeitsvereinbarungen
  • DevOps-Pipelines
  • Qualitätsstandards
  • Geschäftsziele

Gemeinsam bilden diese Artefakte die Wissensbasis, die es sowohl Menschen als auch autonomen Agenten ermöglicht, über dasselbe Engineering-Problem zu argumentieren und Entscheidungen zu treffen. Ohne diesen gemeinsamen Kontext sind Agenten gezwungen, fehlende Informationen zu interpretieren und zu ergänzen. Sie können zwar weiterhin überzeugende Ergebnisse erzeugen, doch diese Ergebnisse werden zunehmend inkonsistent, schwer nachvollziehbar und häufig nicht mehr mit der architektonischen Zielsetzung, dem Sulution Intent, in Einklang stehen.

Die Konsequenz ist erheblich. Organisationen sollten autonome Agenten nicht länger lediglich als fortschrittliche Entwicklungswerkzeuge betrachten. Sie sollten sie vielmehr als neue Teilnehmer ihrer Engineering-Organisation verstehen. Wie jedes neue Teammitglied benötigt auch ein Agent ein strukturiertes Onboarding:

  • Er benötigt Zugang zum organisatorischen Wissen.
  • Er muss die Architekturprinzipien verstehen.
  • Er muss lernen, welche Entscheidungen er eigenständig treffen darf und bei welchen Entscheidungen menschliche Beteiligung erforderlich ist.
  • Er muss innerhalb klar definierter Grenzen arbeiten, die die Qualitätsstandards, das Governance-Modell und die regulatorischen Anforderungen der Organisation widerspiegeln.

Diese Beobachtung verändert eine weitere langjährige Annahme. Über viele Jahre hinweg investierten Engineering-Organisationen vor allem in die Verbesserung der Produktivität von Entwicklern. In den kommenden Jahren könnte die größere Chance jedoch an anderer Stelle liegen. Organisationen, die in die Verbesserung ihres organisatorischen Wissens investieren, werden langfristig vermutlich größere Vorteile erzielen als jene, die sich ausschließlich auf die Verbesserung individueller KI-Fähigkeiten konzentrieren. Damit entsteht eine Disziplin, die heute überraschend wenig Aufmerksamkeit erhält:

  • Es ist nicht Prompt Engineering.
  • Es ist Context Engineering.

Anstatt zu fragen, wie bessere Prompts formuliert werden können, stellt Context Engineering eine grundlegendere Frage:

Wie kann eine Organisation ihr kollektives Engineering-Wissen explizit, vertrauenswürdig und kontinuierlich sowohl Menschen als auch autonomen Systemen zur Verfügung stellen?

Diese Frage wird zunehmend an Bedeutung gewinnen, sobald Organisationen über isolierte KI-Experimente hinausgehen und beginnen, Engineering-Organisationen aufzubauen, in denen Menschen und autonome Agenten als gleichwertige Teilnehmer zusammenarbeiten.

Das nächste Kapitel untersucht, warum Dokumentation – die in der Softwareentwicklung häufig als notwendiger Overhead betrachtet wird – zu einem der wertvollsten Engineering-Assets im Zeitalter des Agentic Engineering wird.

Vorheriges Kapitel Nächstes