Agentic Engineering (Teil 9): Kontinuierliche Einhaltung

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

Agentic Engineering verändert grundlegend, wie Engineering-Organisationen Vertrauen schaffen. Da autonome Systeme zunehmend an der Softwareentwicklung beteiligt sind, reichen periodische Audits allein nicht mehr aus, um nachzuweisen, dass Engineering-Entscheidungen weiterhin mit Architekturprinzipien, Qualitätszielen und der organisatorischen Intention übereinstimmen. Dieser Artikel führt das Konzept der Continuous Adherence ein – die kontinuierliche Bewertung, ob die alltäglichen Engineering-Aktivitäten mit dem definierten Engineering-System einer Organisation im Einklang bleiben. Anstatt Nachweise erst am Ende eines Vorhabens zu sammeln, verbindet Continuous Adherence Engineering-Intention, Architektur, Governance und operative Nachweise über den gesamten Entwicklungslebenszyklus hinweg. Dieser Ansatz ist insbesondere für Organisationen relevant, die innerhalb von Frameworks wie Automotive SPICE, ISO 26262 und ASQMS arbeiten, bei denen Erklärbarkeit und objektive Nachweise unerlässlich sind. Plattformen wie PEDCO AuditPro tragen dazu bei, das Engineering-Verhalten beobachtbar zu machen. Dadurch können Organisationen kontinuierlich nicht nur nachweisen, dass sie compliant sind, sondern auch, dass sie Systeme konsequent so entwickeln, wie es beabsichtigt war.

Von periodischen Audits zu kontinuierlichen Erkenntnissen

Eine der interessantesten Beobachtungen, die wir bei der Arbeit mit autonomen Engineering-Systemen gemacht haben, hat überraschend wenig mit künstlicher Intelligenz selbst zu tun. Stattdessen betrifft sie eine Frage, die sich Engineering-Organisationen seit Jahrzehnten stellen: Woher wissen wir, dass wir Software so entwickeln, wie wir es beabsichtigt haben?

Jahrzehntelang lautete die traditionelle Antwort auf diese Frage: das Audit. Engineering-Teams bereiteten Nachweise vor, Dokumentationen wurden überprüft, Interviews geführt und zu einem festgelegten Zeitpunkt stellten Auditoren fest, ob ein Projekt mit internen Prozessen, externen Vorschriften oder Industriestandards übereinstimmte. Viele Jahre lang war dieses Modell praktikabel und in vielen Kontexten ausreichend. Software änderte sich weniger häufig, wichtige Entscheidungen konnten in der Regel auf identifizierbare Personen zurückgeführt werden und Engineering-Aktivitäten liessen sich vergleichsweise einfach rekonstruieren. Compliance wurde daher häufig durch eine zeitpunktbezogene Bewertung überprüft.

Agentic Engineering verändert diese Rahmenbedingungen. Moderne Engineering-Organisationen entwickeln sich kontinuierlich weiter. Jeden Tag entstehen neue Funktionalitäten, Deployments erfolgen automatisch und autonome Agenten beteiligen sich zunehmend an Aktivitäten, die zuvor ausschliesslich von Ingenieuren ausgeführt wurden. Bei unserer eigenen agentischen Entwicklung innerhalb von PEDCO AuditPro arbeiten wir beispielsweise intensiv mit Lean UX, ausführbaren Mock-ups und Prototypen. Das folgende ausführbare Mock-up wurde innerhalb eines halben Tages direkt gemeinsam mit Produktmanagern und Designern entworfen, getestet und mehrfach verändert.

Entscheidungen liegen nicht mehr konzentriert in den Händen einiger weniger erfahrener Architekten oder technischer Verantwortlicher. Sie entstehen im gesamten Engineering-System – durch Entwickler, Pipelines, KI-Assistenten und zunehmend autonome Agenten. Es werden mehr Entscheidungen getroffen, mit höherer Geschwindigkeit und durch eine wachsende Zahl menschlicher und autonomer Beteiligter. Dies wirft eine andere Frage auf. Anstatt zu fragen, ob eine Organisation heute compliant ist, müssen Engineering-Verantwortliche zunehmend verstehen, ob die alltäglichen Engineering-Entscheidungen weiterhin mit Architekturprinzipien, Qualitätszielen und der organisatorischen Intention übereinstimmen. Der Unterschied mag subtil erscheinen, doch er verändert die Rolle der Governance grundlegend. Herkömmliche Compliance-Bewertungen untersuchen häufig, ob die erforderlichen Prozesse, Kontrollen und Nachweise zu einem bestimmten Zeitpunkt vorhanden sind. Adherence stellt eine wesentlich operativere Frage:

Entwickeln wir Systeme tatsächlich so, wie wir es vereinbart haben?

Adherence ersetzt Compliance nicht. Sie schliesst die Lücke zwischen dem von einer Organisation definierten Engineering-System und der Arbeit, die tatsächlich ausgeführt wird. Continuous Compliance und Continuous Adherence sind daher eng miteinander verbunden, aber nicht identisch. Continuous Compliance fragt, ob interne und externe Verpflichtungen weiterhin erfüllt werden. Continuous Adherence fragt, ob das alltägliche Engineering-Verhalten weiterhin mit der Architektur, den Prozessen, den Qualitätszielen und dem Governance-Modell übereinstimmt, die zur Erfüllung dieser Verpflichtungen entwickelt wurden.

Die Nachweise existieren bereits

Diese Frage lässt sich nicht allein anhand der Prozessdokumentation beantworten. Sie erfordert Nachweise aus der tatsächlichen Engineering-Arbeit.

Glücklicherweise erzeugen moderne Engineering-Organisationen bereits jeden Tag eine aussergewöhnliche Menge solcher Nachweise. Source-Repositories erfassen jede Implementierung. DevOps-Pipelines dokumentieren Builds, Tests und Deployments. Architecture Decision Records bewahren die Begründungen wichtiger Designentscheidungen. Anforderungen entwickeln sich kontinuierlich weiter, automatisierte Tests überprüfen das erwartete Verhalten und operative Telemetriedaten liefern Einblicke in die in Produktion laufende Software. Einzeln betrachtet erzählen diese Artefakte nur einen Teil der Geschichte. In ihrer Gesamtheit beschreiben sie jedoch, wie sich eine Engineering-Organisation tatsächlich verhält.

Sie ermöglichen es uns, folgende Fragen zu stellen:

• Was war beabsichtigt?
• Welche Entscheidung wurde getroffen?
• Warum wurde sie getroffen?
• Welche Kontrollen und Architekturprinzipien galten?
• Welche Nachweise stützen die Entscheidung?
• Was geschah, als die Änderung die Produktion erreichte?

Diese Beobachtung verändert den Zweck von Audits grundlegend. Die Herausforderung besteht nicht mehr nur darin, Nachweise zu sammeln – auch wenn deren Qualität und Zugänglichkeit weiterhin wichtige Herausforderungen darstellen. Die grössere Herausforderung besteht darin, diese Nachweise im Kontext der Engineering-Intention der Organisation miteinander zu verbinden und zu interpretieren. Nachweise sollten daher nicht länger nur als etwas betrachtet werden, das am Ende eines Projekts für Auditoren vorbereitet wird. Sie werden zu einem kontinuierlichen Feedbackmechanismus, der es Organisationen ermöglicht zu beurteilen, ob Architektur, Governance und Engineering-Intention in der täglichen Arbeit weiterhin sichtbar bleiben.

Warum dies im regulierten Umfeld wichtig ist

Diese Herausforderung ist besonders relevant für Organisationen, die in regulierten Branchen tätig sind. Automobilunternehmen müssen die Einhaltung von Frameworks und Standards wie Automotive SPICE, ASQMS und ISO 26262 nachweisen. Organisationen in der Luft- und Raumfahrt sowie in der Verteidigungsindustrie arbeiten innerhalb ihrer eigenen Sicherheits-, Qualitäts- und Assurance-Frameworks. Hersteller von Medizinprodukten mit ISO 13485, Bahnbetreiber und Finanzinstitute sehen sich ähnlichen Erwartungen gegenüber. Wie das nachfolgende Beispiel zeigt, können wir die Adherence eines einzelnen Vorhabens gegenüber einem Prozess überprüfen. Die Inhalte des Repositories eines Vorhabens werden untersucht, klassifiziert und auf ihre Einhaltung des definierten Prozesses überprüft. Als Beispiel ist hier ein Screenshot einer Medizinproduktebewertung nach ISO 13485 mit PEDCO AuditPro dargestellt.

Die Terminologie und der regulatorische Kontext mögen unterschiedlich sein, doch die zugrunde liegende Frage ist bemerkenswert einheitlich:

Können wir nicht nur erklären, welche Entscheidung getroffen wurde, sondern auch, warum sie getroffen wurde und ob sie weiterhin mit den Engineering-Prinzipien und Verpflichtungen der Organisation übereinstimmte?

Ein abschliessendes Dokument kann zeigen, dass eine erforderliche Aktivität durchgeführt wurde. Es weist jedoch nicht zwangsläufig nach, wie eine Entscheidung zustande kam, ob die relevanten architektonischen Einschränkungen berücksichtigt wurden oder ob ein autonomer Agent innerhalb seiner zulässigen Grenzen blieb. Dafür ist eine vernetzte Sicht auf Intention, Entscheidungen, Ausführung und Nachweise erforderlich.

Was Continuous Adherence bedeutet

Wir verwenden den Begriff Continuous Adherence, um die Fähigkeit einer Organisation zu beschreiben, kontinuierlich zu bewerten, ob die tatsächlichen Engineering-Aktivitäten weiterhin mit ihrem definierten Engineering-System übereinstimmen – einschliesslich Solution Intent, Architektur, Qualitätszielen, Working Agreements, Prozessen, Kontrollen und regulatorischen Verpflichtungen. Continuous Adherence bedeutet nicht, dass jede Engineering-Entscheidung auf eine automatisierte Compliance-Prüfung reduziert werden kann. Ebenso wenig beseitigt sie die Notwendigkeit professioneller Beurteilung, unabhängiger Audits oder menschlicher Überprüfung. Ihr Zweck besteht darin, Abweichungen so früh sichtbar zu machen, dass die Organisation sie verstehen und beheben kann, solange der relevante Engineering-Kontext noch vorhanden ist.

Sie stellt Fragen wie:

• Spiegeln sich die Architekturprinzipien in der Implementierung wider?
• Sind die Qualitätsziele während der gesamten Bereitstellung sichtbar?
• Bleiben Engineering-Entscheidungen mit der dokumentierten Solution Intent konsistent?
• Werden die erforderlichen Überprüfungs- und Genehmigungsgrenzen eingehalten?
• Arbeiten autonome Agenten innerhalb derselben Leitplanken, die auch menschliche Ingenieure führen?
• Kann die Organisation erklären, warum eine bestimmte Implementierung als akzeptabel betrachtet wurde?

Diese Fragen können realistischerweise nicht nur einmal alle sechs oder zwölf Monate beantwortet werden. Zunehmend müssen sie als Teil des Engineering-Lebenszyklus selbst beantwortet werden. Betrachten wir ein scheinbar einfaches Beispiel. Ein autonomer Agent verändert eine Schnittstelle zwischen zwei Services. Der Code lässt sich kompilieren, alle automatisierten Tests sind erfolgreich und die Änderung kann erfolgreich bereitgestellt werden. Aus Sicht der Bereitstellung scheint die Änderung abgeschlossen zu sein. Aus der Perspektive der Adherence ergeben sich jedoch zusätzliche Fragen. War die Schnittstelle durch einen Architecture Decision Record eingeschränkt? Wirkte sich die Änderung auf eine Security- oder Safety-Anforderung aus? War eine menschliche Überprüfung erforderlich? Wurden die relevanten Qualitätsziele berücksichtigt? Entspricht die Implementierung weiterhin der dokumentierten Solution Intent? Weder die Codeänderung noch eine herkömmliche Compliance-Checkliste können diese Fragen für sich allein beantworten. Die Antwort ergibt sich erst, wenn Intention, Ausführung und Nachweise miteinander verbunden werden. Haben wir die für diesen Kontext definierte Definition of Done erfüllt? Das nachfolgende Bild veranschaulicht eine automatisierte Prüfung für eine bestimmte Definition of Done.

Engineering-Verhalten beobachtbar machen

Diese Perspektive verändert auch die Rolle von Plattformen wie PEDCO AuditPro. Ihr Zweck besteht nicht einfach darin, Audit-Aktivitäten zu automatisieren. Ihr umfassenderer Zweck besteht darin, Engineering-Verhalten beobachtbar und erklärbar zu machen. Durch die Verknüpfung von Engineering-Artefakten, operativen Nachweisen, Prozesswissen, regulatorischen Erwartungen und architektonischer Intention erhalten Organisationen die Fähigkeit zu verstehen, wie Entscheidungen sowohl bei menschlichen als auch bei autonomen Mitwirkenden entstehen. Ein Mapping von Standards kann erklären, welche Verpflichtungen gelten. Ein Prozessmodell kann beschreiben, wie die Arbeit ausgeführt werden sollte. Ein Source-Repository kann zeigen, was implementiert wurde. Eine Pipeline kann nachweisen, welche Tests ausgeführt wurden. Erst die Beziehung zwischen diesen Elementen zeigt, ob das tatsächliche Engineering-Verhalten weiterhin mit der organisatorischen Intention übereinstimmt.

Vertrauen, während die Arbeit geschieht

Die vielleicht bedeutendste Konsequenz besteht darin, dass sich das Vertrauen selbst zu verändern beginnt. In der Vergangenheit schufen Organisationen Vertrauen in erster Linie durch die periodische Überprüfung abgeschlossener Arbeiten. Im Zeitalter des Agentic Engineering reicht eine ausschliesslich rückblickende Assurance nicht mehr aus. Vertrauen entsteht zunehmend aus der Fähigkeit, die Arbeit zu verstehen, während sie geschieht – Entscheidungen nachzuverfolgen, die Anwendung von Kontrollen zu beobachten und Abweichungen zu erkennen, bevor sie systemisch werden.

Der Trust Loop ist wichtig, weil Nachweise nicht das Ende des Prozesses darstellen. Nachweise machen Adherence beobachtbar. Adherence erzeugt Feedback. Feedback verbessert Architektur, Prozesse, Leitplanken und organisatorische Intention. Das Engineering-System selbst wird leistungsfähiger – nicht unbedingt, weil sich die zugrunde liegenden KI-Modelle verändert haben, sondern weil die Umgebung, in der Menschen und autonome Agenten arbeiten, klarer, konsistenter und erklärbarer geworden ist.

• Audits werden zur Bestätigung statt zur nachträglichen Entdeckung
• Nachweise werden kontinuierlich statt aussergewöhnlich.
• Governance wird sichtbar statt implizit.

Letztlich könnte dies zu einem der prägenden Merkmale autonomer Engineering-Systeme werden. Das Ziel besteht nicht lediglich darin, Software schneller zu erstellen. Das Ziel besteht darin, Engineering-Organisationen zu schaffen, deren Entscheidungen transparent und erklärbar bleiben und kontinuierlich mit den Prinzipien übereinstimmen, auf denen die Organisation selbst aufgebaut wurde.

Vorheriges Kapitel Nächstes