Vor einiger Zeit sah ich, wie jemand mit ein paar KI-Agenten einen Fabrikentwurf erstellte – Fließbilder, R&I-Schemata, Grundriss, alles aus mittels Prompts. Mein erster Gedanke war der eines Ingenieurs: Hübsch, aber das hält niemals einer Prüfung stand. Vibe Engineering nennt man das. Als Ingenieur dachte ich sofort: Hübsch, aber das hält keiner Prüfung stand. Und gleichzeitig ließ mich die Frage nicht mehr los, wie viel davon wohl wirklich stimmt. Es gab nur einen Weg, das herauszufinden.
Also habe ich es ausprobiert – an einem Wochenende, mit einem KI-Agenten, einem Werkzeugkasten, der zusammen null Euro kostet, und einer Firma, die es nicht gibt – oder besser, gab: der Chocolaterie Schokittel AG aus Appenzell. Sie wollte eine Linie für 2.000 gefüllte Schokoriegel pro Stunde, nachts ohne Personal, weil sich in Appenzell niemand für die Nachtschicht findet. Die Riegel gab es am Ende nicht. Dafür ein paar Stunden später nach dem ersten Prompt, Fließbilder, R&I-Schemata, Equipmentlisten, Grundriss, 3D-Modell, Energiebilanz und eine Kostenschätzung – für etwas, das nach meiner Erfahrung sonst Monate und ein spezialisiertes Ingenieurbüro gebraucht hätte.
Dieser Artikel erzählt, was dabei herausgekommen ist: die Zahlen, die Fehler, die Stellen, an denen der Agent klüger war als ich – und die, an denen er ein Rohr ins falsche Ende entleert hätte. Und er fragt, was es für Planungsprozesse bedeutet, wenn der Engpass in Zulunft nicht mehr das Zeichnen ist.
Was Vibe Engineering ist – und was nicht
Der Begriff leitet sich von „Vibe Coding“ ab, dem Programmieren per Zuruf, bei dem man den Code der KI akzeptiert, ohne ihn zu lesen. Simon Willison setzte dem im Herbst 2025 „Vibe Engineering“ entgegen: dieselben Agenten, aber mit voller Ingenieursdisziplin – Tests, Review, Verantwortung. Auf die Anlagenplanung übertragen heißt das: Ein Ingenieur beschreibt die Anlage in natürlicher Sprache, ein Agent erzeugt die Planungsartefakte, und der Mensch prüft, korrigiert und verantwortet.
| Vibe Coding | Vibe Engineering | |
|---|---|---|
| Haltung | Output akzeptieren, nicht lesen | Output prüfen, verantworten |
| Artefakt | lauffähiger Code | konsistentes Anlagenmodell |
| Qualitätssicherung | „Es funktioniert“ | Normen, HACCP, Sicherheitsabstände |
| Rolle des Menschen | Auftraggeber | Spezifizierer und Prüfer |
Der entscheidende technische Unterschied zu den Bildgeneratoren, die wir alle kennen: Der Agent zeichnet nicht, er modelliert. Er schreibt strukturierte Daten – Graphbeschreibungen, XML, Python-Skripte, OpenUSD, dann rendert er. Ein R&I-Schema ist bei ihm keine Grafik, sondern eine Datenstruktur, aus der sich die Grafik ergibt. Dadurch taucht ein Pumpen-Tag in Stückliste, Grundriss, 3D-Modell und Datenpunktliste identisch auf, und eine Änderung an einer Stelle läuft durch alle anderen. Wie weit das trägt, war die eigentliche Frage meines Tests.
Wie heute geplant wird
Eine Anlagenplanung läuft in Stufen: Lastenheft, Grundfließbild, Verfahrensfließbild, R&I-Schema, Aufstellungsplanung, Detailplanung. Jede Stufe hat ihr Gewerk, ihr Werkzeug und ihr Dateiformat. Der Verfahrensingenieur zeichnet das R&I in einem CAE-System, der Aufstellungsplaner baut das 3D-Modell in einem anderen, die Stückliste lebt in Excel, die Energiebilanz in einem dritten Programm. Zwischen den Stufen stehen Übergaben, und an jeder Übergabe geht Information verloren oder wird neu eingetippt. Sogenannte Medienumbrüche und der Tot eines jeden vollautomatisierten Prozesses.
Das eigentliche Problem ist nicht die Dauer der einzelnen Stufe, sondern die Schleife. Eine Änderung in der Aufstellung – ein Tank passt nicht durch die Tür – läuft zurück ins R&I, von dort in die Listen, von dort in die Kostenschätzung. Jede Revision braucht Wochen, weil sie durch alle Gewerke muss, und jede Revision ist eine Gelegenheit für neue Inkonsistenzen: Der Tag, der im R&I geändert wurde, steht in der Stückliste noch alt.
Aus Konzernsicht kommt dazu: Die Projekt-Initiationsphase eines Anlagen-Grossprojekts dauert typischerweise bis zu 12 Monate. In dieser Zeit sitzen mehrere Fachexperten mit spezialisierten Ingenieurbüros zusammen, und das Ergebnis ist eine Vorplanung, die als Grundlage für weitere Angebote taugt. Für den reinen Prozessteil, ohne Gebäude und Genehmigungen, rechne ich mit mindestens drei Monaten. Das ist der Referenzwert, gegen den ich meinen Test gemessen habe.
Der Selbsttest: eine Riegellinie an einem Tag
Das Szenario. Um keine Nähe zu meiner jetzigen Arbeit zu haben, erfand ich die Chocolaterie Schokittel AG in Appenzell – der Name ist ein Tippfehler meines eigenen, der zur Marke wurde. Sie braucht eine Linie für 2.000 gefüllte Schokoriegel pro Stunde, zwei Sorten, Alpkräuter-Creme als Füllung, Dreischichtbetrieb ohne Bedienpersonal, Strom und Quellwasser als einzige Medien. Das Lastenheft mit 87 nummerierten Anforderungen entstand in zwei Stunden Dialog mit Claude Fable 5.1, die mir mehrere Fragen stellte und daraus den Text schrieb.
Die Werkzeuge. Claude Code als Agent in VS Code auf Linux Mint, dazu Graphviz für Fließbilder, draw.io für R&I-Schemata, Python mit ezdxf und CadQuery für Grundriss und 3D-Modell, Git für alles. Alles außer dem Sprachmodell ist Open Source und kostenlos. Das Repository hatte eine Arbeitsanweisung für den Agenten (Rolle, Normen, Tag-Konvention, Pflicht zum Konsistenz-Check) und ein Prüfskript, das jeden Tag im R&I gegen Listen und Datenpunkte abgleicht.
Der Ablauf. Vier Phasen mit festem Zeitbudget, nach jeder Phase ein Review durch mich mit Protokoll, dann eine Änderung des Lastenhefts mit Stoppuhr. Ich habe nie selbst in die Dateien eingegriffen – jede Korrektur lief als Prompt, damit die Iterationen zählbar bleiben.
Die Zahlen.
| Heute (Erfahrungswert) | Test (gemessen) | |
|---|---|---|
| Dauer der Vorplanung (Prozess) | mind. 3 Monate | 1 h 51 min Agentenzeit, 4 Phasen |
| Beteiligte | mehrere Experten + Ingenieurbüro | ein Ingenieur + ein Agent |
| Mein Aufwand | – | 60 min Prompten, 60 min Sichten, 40 min Korrigieren |
| Fachliches Review der Ergebnisse | laufend über Wochen | geschätzt ein Tag mit einem Prozessexperten |
| Änderungsdurchlauf durch 8 Artefakte | Tage bis Wochen | 6 Minuten |
| Lieferobjekte | PFD, R&I, Listen, Grundriss, 3D, Energie, Kosten | dieselben, dazu 300 Datenpunkte, 14 dokumentierte Entscheidungen, 34 gekennzeichnete Annahmen |
Die Änderung. Nach Phase 5 ergänzte ich das Lastenheft um ein Kapitel: Die Linie wird nicht mehr von Menschen betreut, sondern von drei humanoiden Robotern – Ladestationen, Reinigungsschleusen, Greifhöhen, Sicherheitskonzept nach ISO 10218. Ich gab dem Agenten 45 Minuten. Er brauchte sechs. In dieser Zeit änderte er Fließbild, R&I, Listen, Datenpunkte, Grundriss, 3D-Modell und Energiebilanz und legte eine Kostenschätzung neu an. Das ging nur, weil er in Phase 4 ungefragt etwas gebaut hatte, das ich nicht bestellt hatte: einen Generator, der R&I, Listen und Datenpunkte aus einer gemeinsamen Quelle erzeugt. Drei Roboter sind in dieser Quelle ein Dutzend Zeilen; alles andere folgt. Die Geschwindigkeit kam nicht aus dem Sprachmodell, sondern aus einer Architekturentscheidung, die der Agent selbst getroffen hatte.
Was der Agent gefunden hat, das ich übersehen hatte.
Drei Widersprüche hatte ich im Lastenheft: Die geforderte Verweilzeit der Füllung passte nicht zur geforderten Puffergröße; die Formenwäsche „außerhalb der Produktionszeit“ ist im Saisonbetrieb rund um die Uhr unerfüllbar; und „die Roboter übernehmen alle Tätigkeiten“ kollidierte mit einigen von mir selbst vorgegebenen Dingen. Dazu eine Lücke: Kakaobutter stand nicht in der Rohstoffliste, wurde aber für den Sortenwechsel gebraucht. Jeden Punkt meldete er mit Lösungsvorschlag, ohne eigenmächtig zu ändern. Er las das Lastenheft wie ein Prüfer, nicht wie ein Zeichner.
Was ich gefunden habe, das der Agent übersehen hatte.
Er plante, Kakaobutter-Pastillen „von Hand“ nachzufüllen – in einer Anlage, deren Leitbild „Lights-out“ in der ersten Zeile steht. Er löste die Formenwäsche mit einem wöchentlichen Stillstand, den der 24/7-Betrieb nicht hergibt. Beides hätte ein Planer sofort gesehen. Der Agent kennt die Norm, aber nicht immer ihre Konsequenz: In Phase 8 gab er allen Schokoladenleitungen das geforderte Gefälle von zwei Prozent und stellte dann selbst fest, dass der tiefste Punkt oft am Startanschluss liegt – das Rohr entleert sich in den Tank statt in die Gießstation.
Was mich überrascht hat.
Die Ehrlichkeit: Die Massenbilanz kennzeichnete er als „konstruiert“, die Energiekennzahl, die mit 0,9001 kWh/kg exakt auf meinem Zielwert von 0,9 kWh/kg landete, als Zufallstreffer, und von 16 Tätigkeiten, die die Roboter übernehmen sollten, beließ er sieben beim Menschen, statt die Anforderung als erfüllt zu melden. Zweitens der Fortschrittsbias: Eine Zeitvorgabe für das 3D-Modell ignorierte er „wegen anhaltender Fortschritte“; erst eine ausdrücklich harte Grenze hielt. Er hat alle Layout- und Kollisionsprüfungen selbst definiert und selbst bestanden. Das ist kein Nachweis, nur eine Behauptung mit Skript – und genau die Stelle, an der der Mensch nicht wegsehen darf.
Mein Urteil. Die Entwürfe taugen als Grundlage für ein erstes Gespräch mit einem Planungsbüro und für weitere Iterationen. Die Instrumentierung mit 142 Messstellen und die Halle mit 1.010 Quadratmetern halte ich für plausibel; die Kostenschätzung von 14,5 Millionen Franken reicht für eine erste Iteration aber kann ich ohne detaillierte Angebote natürlich nicht verifizieren – und das sagt der Agent über seine eigene Zahl auch.
Was sich für Planungsprozesse ändert
Drei Verschiebungen zeichnen sich ab, und keine davon betrifft in erster Linie die Technik.
- Vom Zeichnen zum Spezifizieren. Von meinen 160 Minuten entfielen null auf das Zeichnen und 60 auf das Formulieren von Anforderungen und Korrekturen. Die Qualität des Ergebnisses hing fast vollständig daran, wie präzise das Lastenheft war – und der Agent fand drei Stellen, an denen es das nicht war. Wer künftig Anlagen plant, muss vor allem eines können: prüfbare Anforderungen schreiben. Das ist eine Fähigkeit, die in vielen Planungsabteilungen heute im Kopf des erfahrenen Kollegen liegt und nicht auf Papier.
- Vom sequenziellen zum iterativen Prozess. Wenn eine Revision sechs Minuten statt zwei Wochen dauert, lohnt es sich, Varianten zu rechnen statt zu diskutieren. Elektroheizer oder Hochtemperatur-Wärmepumpe? Der Agent hat beides bilanziert und die Entscheidung mit Amortisationszeit dokumentiert. Getrennte oder gemeinsame Kälteerzeugung? Ebenso. Die Planungsbesprechung der Zukunft sieht nicht ein R&I, sondern drei, und entscheidet zwischen ihnen.
- Vom Gewerk zum Repository. Das, was in meinem Test in der Mitte stand, verdient einen eigenen Namen. Ich nenne es Centralized Engineering Repository (CER): ein Git-Repository, in dem Lastenheft, Entscheidungen, Annahmen und die Quellen aller Zeichnungen und Modelle als Text liegen, verbunden durch gemeinsame Namen – Anforderungs-IDs, Tags, Leitungsnummern. Das Wort ist mit Absicht aus der Softwareentwicklung geliehen: Ein Repository ist nicht irgendein Datenspeicher, sondern einer mit Historie, Verantwortlichkeit und Review. Das CER ersetzt die Übergabe zwischen Gewerken durch eine gemeinsame Quelle: R&I, Listen, Grundriss, 3D-Modell und Datenpunkte werden aus ihm erzeugt, nicht nebeneinander gepflegt. Der Konsistenz-Check, der bei mir nach jeder Phase lief, ist das, was heute ein Prüfingenieur über Tage macht: Tag für Tag abgleichen.
CER und UNS gehören zusammen. Der Unified Namespace ist der Ort, an dem die laufende Anlage ihre Daten veröffentlicht – jeder Messwert unter genau einer Adresse. Das Centralized Engineering Repository ist der Ort, an dem dieselbe Anlage entworfen wird – jede Anforderung, jedes Equipment unter genau einem Namen. Beim Übergang in den Betrieb wird aus dem Tag der Planung das Topic des Betriebs: TIC-101 im CER wird zu schokittel/appenzell/riegellinie/m1/T-101/TIC-101 im UNS, und der digitale Zwilling, der aus dem 3D-Modell des CER entsteht, bekommt seine Messwerte aus dem UNS. Planung und Betrieb teilen sich die Namen, und die Datenströme der echten Anlage fließen in ein Modell, das sie schon kennt. Die Grafik zeigt, wie sich das Bild dreht – vom Staffellauf der Gewerke zum CER als Nabe.
Links wandert jede Änderung durch alle Stufen zurück an den Anfang; rechts ändert sich das Repository, und die Sichten werden neu erzeugt – in meinem Test in sechs Minuten.
Documents as Code – was sich an der täglichen Arbeit konkret ändert. Heute schreibt ein Ingenieur sein Lastenheft in Word. Die Zeichnungen entstehen getrennt in CAD und werden als Bild eingefügt; ändert sich das R&I, ist das Bild im Lastenheft veraltet, und niemand merkt es, bis ein Lieferant danach baut. Die Anforderung „Rücklauftemperatur mindestens 80 °C“ steht in einem Fließtext auf Seite 14, und ob das Regelventil im R&I sie erfüllt, prüft ein Mensch mit dem Finger auf dem Papier. In meinem Test war alles davon Text in einem Git-Repository, und das verändert die Arbeit an jeder Stelle:
| Arbeitsschritt | Heute | Im Test |
|---|---|---|
| Anforderung schreiben | Fließtext in Word, Seite 14 | PRC-04: Alle schokoladeführenden Leitungen beheizt, 40–45 °C, Gefälle ≥ 2 % – ein Satz, eine ID, prüfbar |
| Zeichnung ins Lastenheft bringen | Screenshot aus CAD einfügen, bei jeder Revision neu | R&I ist eine Datei im selben Repository; jedes Artefakt nennt die REQ-IDs, die es erfüllt |
| Anforderung prüfen | Reviewer liest Seite 14 und sucht im R&I | Prüfskript: jeder Tag genau einmal in R&I, Listen und Datenpunkten – nach jeder Phase, in Sekunden |
| Lastenheft korrigieren | neue Word-Version per E-Mail, Änderungen im Modus „Nachverfolgen“ | ein Commit: spec: RAU-06 angepasst (L-2) – wer, wann, warum, für immer nachvollziehbar |
| Entscheidung dokumentieren | Protokoll der Planungsbesprechung, irgendwo im Projektlaufwerk | ADR-011: Elektroheizer statt Wärmepumpe, Amortisation 30 Jahre, neben dem Artefakt, das davon abhängt |
| Revision freigeben | Unterschrift auf dem Deckblatt (maximal „elektronisch“) | Pull Request mit Diff: man sieht die drei geänderten Leitungen, nicht 40 Seiten PDF |
Zwei Beispiele aus dem Test zeigen, was das in der Praxis heißt. Als der Agent feststellte, dass Kakaobutter in meiner Rohstoffliste fehlte, hätte in einem Word-Lastenheft jemand eine E-Mail geschrieben, und die Antwort wäre in Version 1.3 eingearbeitet worden – oder auch nicht. Im Repository wurde daraus eine Annahme mit Nummer, ein Eintrag in der Annahmenliste und nach meiner Bestätigung ein Commit, der genau die eine Zeile änderte. Und als in Phase 8 die Rohrlängen aus dem 3D-Modell vorlagen, zog der Agent die Kostenschätzung nach, weil beide aus denselben Listen gespeist werden; der frühere Prozentaufschlag für Verrohrung wurde durch 994 gemessene Meter ersetzt, und der Unterschied stand mit Begründung im Dokument. In einem Excel-Blatt, das jemand vor drei Wochen ausgefüllt hat, passiert das nicht von selbst.
Das Lastenheft wird damit lebendig: kein Dokument, das man einmal schreibt und dann verwaltet, sondern Teil der Quelle, aus der die Anlage entsteht – Plant as Code, wenn man so will. 42 Commits in meinem Test, 17 davon mit dem Agenten als Mitautor, jeder mit den Anforderungs-IDs im Betreff – der Git-Log beantwortet die Frage, die in jedem Projekt irgendwann gestellt wird: Wer hat wann was geändert, und warum?
Was das für Rollen heißt. Der Zeichner verschwindet nicht, er wird Modellpfleger. Der Verfahrensingenieur zeichnet nicht mehr, er spezifiziert und prüft – und er muss schneller prüfen, als der Agent produziert. Das Ingenieurbüro verkauft nicht mehr Stunden fürs Zeichnen, sondern Fachwissen fürs Prüfen und Verantworten. Und der Auftraggeber, der heute ein Lastenheft in Prosa liefert, wird lernen müssen, in nummerierten, prüfbaren Sätzen zu schreiben, weil der Agent sonst erfindet, was fehlt – und das kennzeichnet, aber nicht immer richtig.
Grenzen und Voraussetzungen
Mein Test zeigt Vorplanungsqualität, keine Ausführungsplanung. Kein erzeugtes Dokument ist freigabefähig, und das wird sich nicht ändern, solange ein Ingenieur mit seiner Unterschrift haftet. Die Frage ist nicht, ob der Agent die Verantwortung übernimmt, sondern wie viel schneller der Mensch sie übernehmen kann, wenn die Grundlagen in Stunden statt Monaten vorliegen.
Einige Dinge muss man dabei ehrlich benennen. Die Kostenschätzung beruht auf Richtwerten ohne ein einziges Angebot. Der Unified Namespace, den das Lastenheft verlangt, existiert als Liste von 300 Datenpunkten mit MQTT-Topics – angeschlossen war nichts; ob die Datenarchitektur trägt, zeigt erst ein Betrieb. Und das Fachwissen, das in meinem Lastenheft steckte – Temperierkurven, Hygienezonen, Doppelmantelleitungen –, musste ich mitbringen; der Agent hätte es aus dem Internet geraten, und ich hätte es ihm nicht angesehen.
Auf der Werkzeugseite bleibt die Brücke zu den Systemen der Planungsbüros offen. Mein Modell exportiert nach STEP, glTF, OpenUSD und IFC, aber nicht nach DEXPI, dem Austauschformat für R&I-Schemata, und kein Planungsbüro wird draw.io-Dateien annehmen. Dass Markdown, Git und Python in meinem Test die Arbeit erledigt haben, während die Normen der Branche an den Rändern stehen, sagt etwas über den Zustand der Standardisierung.
Es sagt vor allem etwas über den Zugang zu Wissen. Markdown, Git und Python sind frei verfügbar, vollständig dokumentiert und in Millionen Zeilen Code auf GitHub zu finden – der Agent kennt sie, weil er sie lesen konnte. EHEDG-Leitlinien, DIN EN 1672-2, ISO 10628 und ISA 5.1 kennt er nur aus zweiter Hand: aus Zusammenfassungen, Lehrbüchern, Forenbeiträgen. Der Text selbst liegt hinter einer Bezahlschranke, Dokument für Dokument. Genau dort lagen seine Fehler: Er wusste, dass Schokoladenleitungen Gefälle brauchen, aber nicht, in welche Richtung; er kannte die Hygienezonen, aber nicht die Konsequenz für die Formenwäsche. Ein Agent mit vollem Zugriff auf die Normtexte hätte diese Fehler vermutlich nicht gemacht – und ein Ingenieur, der ihn prüft, braucht denselben Zugriff, um die Fehler in Minuten statt Tagen zu finden. Auch SOPs (Standardized Operating Procedures) werden zunehmend Wissensquelle für Agenten werden, um firmenspezifische Vorgaben direkt berücksichtigen zu können.
Das verschiebt, was ein Ingenieur wissen muss. Bisher war er Experte für seine Norm, die sein Arbeitgeber einmal gekauft hat, und für das Gewerk daneben hat er einen Kollegen gefragt. Wenn der Agent in sechs Minuten Hygiene, Energie, Robotik und Kosten gleichzeitig anfasst, muss der Mensch, der das prüft, in allen vier Feldern wenigstens so weit sehen können, dass er den Fehler erkennt. Das geht nur mit Wissen, das für Mensch und Maschine gleichermaßen verfügbar ist – maschinenlesbar, verlinkbar, zitierbar. Eine Branche, die ihr Wissen in PDFs zu 180 Euro das Stück verkauft, wird von Agenten nicht beschleunigt, sondern umgangen. Warum das so ist und was die Branche daran ändern könnte, ist ein eigener Artikel.
Und eine Einschränkung, die oft vergessen wird: Ich habe ein Frontier-Modell benutzt. Der Kontrolllauf mit einem lokalen Open-Source-Modell steht noch aus; ich erwarte, dass er zeigt, wie viel vom Ergebnis am Modell hängt und wie viel an der Methode.
Fazit
Monate gegen Stunden ist nicht die Pointe. Die Pointe ist, dass sich in diesen wenigen Stunden entschieden hat, was ein Planer künftig können muss: prüfbare Anforderungen schreiben, Varianten vergleichen statt eine zeichnen, und ein Ergebnis in der Zeit prüfen, in der es entsteht. Der Agent hat mein Lastenheft dreimal korrigiert, bevor er es umgesetzt hat.
Für Entscheider in Engineering und Digitalisierung heißt das: Wartet nicht auf eine Studie. Ein Pilot kostet ein Wochenende, ein Lastenheft und ein Git-Repository. Er liefert keine fertige Anlage – aber er zeigt zwei Dinge, die keine Studie zeigt: wie viel Zeit heute im Zeichnen und Übergeben steckt statt im Entscheiden, und ob Ingenieure Anforderungen so schreiben können, dass ein KI-Agent sie umsetzen kann. In meinem Fall hat der Agent das Lastenheft an drei Stellen besser und schneller gelesen als ich selbst und noch viel beeindruckender: Eine Änderung war in nur 6 min durch alle Dateien hinweg, nachgezogen worden und stünde somit als weitere Diskussionsgrundlage zur Verfügung.
Das Repository mit Lastenheft, Arbeitsanweisung, Prüfskript und allen Artefakten ist öffentlich.
