Wenn ein KI-Agent ein Produkt entwickeln soll, wird oft zuerst auf Modell und Werkzeuge geschaut. Also Welches LLM, welches CAD, welche Simulation? Nach ein paar Wochen Roboter-Challenge bin ich überzeugt: Über die Qualität des Ergebnisses entscheidet das Operating Model, in dem der Agent arbeitet. Also die Frage, wie gearbeitet, entschieden, geprüft und gelernt wird.
Zur Erinnerung: In der Next challenge habe ich mir vorgenommen, einen KI-Agenten einen kleinen DIY-Roboter autonom entwickeln zu lassen. Von den Anforderungen über Architektur, CAD und Firmware bis zur Simulation. Ich definiere Framework und Anforderungen, zusammenschrauben muss ich selbst. Ein erster Entwurf des Roboter ist inzwischen fertig entworfen und simuliert (gebaut noch nicht). Spannender ist, was es auf dem Weg dahin zu lernen gab.
Prozesstreu und trotzdem daneben
Mein erster Entwurf des Frameworks bestand im Wesentlichen aus Basisregeln und einem Tech-Stack. Das Ergebnis war so medium.
Das prägnanteste Beispiel: Der Agent hatte eigenständig als Basis einen Kauf-Bausatz ausgewählt, ein rundes Acryl-Chassis mit zwei Decks. In seinem CAD-Modell stand dann ein rechteckiger Alu-Rahmen. Das Produktfoto lag die ganze Zeit im Projektordner. Gemerkt habe ich es selber, beim bloßen Anschauen.
Das Bemerkenswerte: Der Agent hatte sich an alle Prozessregeln gehalten. Anforderungen abgeleitet, Entscheidungen dokumentiert, Recherche mit Quellen. Es fehlte schlicht ein Maßstab dafür, woran man gute Ingenieursarbeit erkennt — für ihn war der Alu-Rahmen überspitzt ausgedrückt ein “wird schon passen”. Und ich bin irgendwie wie selbstverständlich davon ausgegangen, dass es doch selbstverständlich sein müsse, dass das Modell dem entspricht, was nachher rauskommen soll.
Die zweite Lehre betraf mich selbst. Mir war von Anfang an klar, dass ich das Regelwerk (wie arbeitet der Agent?) vom Projekt (was baut er?) trennen will, damit ich es wiederverwenden kann. Auch das hatte ich nicht als Requirement aufgeschrieben. Klar wurde mir das, als ich die ersten Framework-Entwürfe angesehen habe: Nein, wir sind noch nicht am Ziel.
Implizite Erwartungen werden entweder zu expliziten Anforderungen, oder sie werden nicht erfüllt.
Mein Operating Model nimmt Formen an
Nach zwei, drei Überarbeitungsrunden ist daraus mein Operating Model in der aktuellen Form geworden.
Links geht der Intent hinein: Ziele, Anforderungen, Randbedingungen, Budget. Rechts kommen Build-Pakete, Prototypen und Testberichte heraus. Unten läuft ein Regelkreis zurück, mit Findings, Erfahrungen und Change Requests.
Im Agenten selbst stecken mehrere Ebenen. Der obere Teil (blau) hängt von Domäne und Organisation (oder in meinem Fall: von mir) ab: Werkzeuge wie SysML, CAD, ECAD und Simulation, dazu Design-Regeln, Lessons Learned und die Frage, was die Organisation (=ich) überhaupt fertigen und testen kann. In meinem “Ein-Mann-Unternehmen” heißt das: Löten ja, SMD nein, kein 3D-Drucker, ein Multimeter. Der Agent muss mit dem planen, was ich nachher auch leisten kann.
Die untere Bereich (gelb) ist der feste Kern des Operating Model. Es gilt projektübergreifend und besteht aus drei Schichten:
Governance & Conventions. Wer entscheidet was; wie laufen Änderungen; wann übergibt der Agent an den Menschen; wie werden Assets benannt.
Engineering Platform. Git, Container, Skills und automatische Checks. Könnte aber auch eine ausgewachsene PLM Landschaft wie Windchill oder Teamcenter sein.
Engineering Method. Modellbasiert und Architecture first. Erst Anforderungen und Architektur (bei mir in SysML v2), dann Konstruktion und Code. Jede Anforderung ist bis zum Testfall verfolgbar.
Wer in PLM zu Hause ist, wird dabei wenig Neues entdecken. Entwicklungshandbuch, Change Management, Freigabeprozess, Design Guidelines: All das gibt es für menschliche Teams seit Jahrzehnten. Ein Agent braucht dasselbe, nur deutlich expliziter und an vielen Stellen maschinell durchgesetzt.
Was am Anfang noch gefehlt hatte
Methode, Plattform und Spielregeln für Entscheidungen waren von Anfang an da. Gefehlt hat ein Maßstab für gute Ingenieursarbeit. Den hat das Framework in der zweiten Runde bekommen, in Form von Design-Richtlinien für die einzelnen Disziplinen, so wie sie jede Entwicklungsabteilung kennt. Die Lehre aus dem Chassis ist eine davon.
Genauso wichtig war mir, dass diese Richtlinien nicht auf dem Stand des ersten Tages stehen bleiben. Der Agent hält fest, was er gelernt hat, und schlägt daraus neue Regeln vor. Ich entscheide, was davon gilt.
Wann ich dem Agenten vertraue
In meinem Artikel „KI im Engineering braucht Regeln – und Vertrauen” ging es um die Frage, wann man der Arbeit einer KI trauen kann. Genau eine solche Vertrauenswürdigkeit soll das Operating Model begründen. Ich will mich auf das Ergebnis verlassen können, ohne jede Zeile selbst nachzuprüfen.
Dafür braucht es zuerst Nachvollziehbarkeit: Jede Entscheidung ist begründet, jede Anforderung bis zum Test verfolgbar. Dann klare Zuständigkeiten. Technische Fragen klärt der Agent allein, Ziele, Budget, Sicherheit und die Spielregeln selbst nur mit mir. Und diese Grenzen setzt die Plattform durch, eine Bitte im Prompt wäre über lange Sessions zu weich. Funfact: Als ich die Spielregeln einmal selbst direkt und ohne CR geändert hatte, hat der Agent das beim nächsten Start bemerkt und mir zugeordnet. Ertappt!
Agentic Engineering ist Kein Vibe Engineering
Andrej Karpathy hat Vibe Coding sinngemäß so beschrieben: Man gibt sich dem Vibe hin und schaut, was herauskommt. Und oft werden die Begriffe Vibe Engineering und Agentic Engineering durcheinandergeworfen. Doch: was hier passiert ist alles andere als “Vibe”. Es gibt ein klares Framework, das Anforderungen an einen Intent erfüllen soll, und zwar nachvollziehbar.
Im Aufbau dieses Frameworks steckt jede Menge Hirnschmalz und ziemlich wenig Vibe.
Dabei merke ich etwas, das ich aus langer Arbeit mit KI kenne. Für gezielte Einzelaufgaben funktioniert sie hervorragend. Bei größeren Vorhaben, wo vielleicht lediglich der Intent bekannt, die Richtung aber noch sehr unklar, und auch die Definition of Done nur schwammig in Worte zu fassen ist, klappt es nur im Dialog zwischen Mensch und KI. Ohne KI hätte es dieses Projekt nicht gegeben. Ohne mich aber auch nicht.
Und der Roboter?
Im Entstehen ist ein scheuer Wohnungsroboter. Er erschrickt bei Licht und Lärm und versteckt sich im Dunkeln, am liebsten unter unserem Sofa. Simuliert wird er in einem digitalen Abbild unseres Wohnzimmers, mit derselben Firmware, die später auf dem Mikrocontroller läuft.
Unter der Haube von „proto-1” stecken rund 50 Anforderungen, alle bis zum Testfall verfolgbar, 14 dokumentierte Entscheidungen, eine automatisch geprüfte SysML-v2-Architektur und eine Stückliste für knapp 75 Euro (bei gesetzten 100 Euro Budget). Drei Bugs hatte der Agent selbst in seine Firmware eingebaut. Gefunden hat er sie auch selbst, in Szenario-Tests und Simulation.
Als Nächstes wird gebaut. Dann zeigt sich, ob der Entwurf trägt und wie viel die Simulation wert war. Laut Anforderungen flüchtet der Kleine vor Licht und Lärm. Mich zu jagen, steht da nirgends. Ich bin gespannt, ob er sich daran hält 😉
Wink mit dem Zaunpfahl: Wer überlegt, wie ein Operating Model für KI-Agenten im eigenen Engineering aussehen könnte, mit Anforderungen, Change-Prozess und Digital Thread, dem helfen meine Kollegen von BHC und PROSTEP und ich gern weiter.
Fragen und Antworten
Was ist ein Operating Model für KI-Agenten im Engineering?
Der Rahmen, in dem ein Agent arbeitet, unabhängig vom einzelnen Projekt: eine Engineering-Methode (bei mir modellbasiert, Architecture first), eine Engineering-Plattform (Git, Container, Skills, automatische Checks) und Governance mit Konventionen (Entscheidungsrechte, Change-Prozess, Übergaben an den Menschen, Benennung). Dazu kommt ein Regelkreis, der Erfahrungen aus dem Projekt in neue Regeln überführt.
Worin unterscheidet sich agentisches Engineering von Vibe Coding?
Beim Vibe Coding beschreibt man grob, was man haben will, und lässt sich vom Ergebnis überraschen. Agentisches Engineering arbeitet gegen einen expliziten Intent: Anforderungen mit IDs, dokumentierte Entscheidungen, Änderungsanträge und Prüfungen, sodass jedes Ergebnis bis zu seiner Anforderung zurückverfolgt werden kann.
