KI im Ingenieurbüro: Eine Dienstleistung mit Agenten skalieren – geht das?
Podcast anhören auf:
Was ist das Ziel?
Kurz zur Vorgeschichte: 2021 habe ich mein Ingenieurbüro an Björn verkauft. Mit dabei war mein Productized Service „Lastenheft in zwei Wochen“ – einerprobtes Vorgehen in fünf Phasen: Erfassen, Sortieren, Füllen, Prüfen, Freigeben. Seit gut einem Jahr begleite ich Björn als Mentor, und in unseren Calls kam immer wieder dieselbe Frage auf:
Was geht eigentlich mit KI – und was ist Bullshit?
Statt darüber zu philosophieren, haben wir ein Experiment gestartet: In vier Wochen wollten wir durchspielen, wie wir ein Lastenheft mit KI bauen. Als konkretes Projekt diente eine Wallbox – die Ladestation fürs Elektroauto, die viele schon zu Hause haben. Ein dankbares Beispiel, zu dem Björn aus einem früheren Konferenzvortrag bereits Material hatte.
Die wichtigste Erkenntnis!
Wir haben relativ schnell etwas gelernt, das alles andere bestimmt hat:
Du kannst nicht das gesamte „Sternekochrezept“ in eine KI stecken. Das ist Quatsch.
Den kompletten Workflow in einen einzigen Prompt zu kippen funktioniert nicht – die Kapazitätsgrenze ist schnell erreicht, und das Ergebnis wird unbrauchbar. Der richtige Weg ist das Gegenteil:
Mach dir bewusst, was dein meisterliches Handwerk ist. Zerlege es in seine einzelnen Schritte. Und bau dann für genau die Tätigkeiten, wo es Sinn ergibt, einen hoch spezialisierten Agenten – einen Agenten für eine kleine Aufgabe, mit einem richtig guten Master-Prompt für genau diese Aufgabe.
So ein Agent performt in seiner einen Aufgabe hervorragend – aber eben auch nur dort. (Was wir heute Agent nennen, hieß vor ein paar Jahren noch GPT. Im Kern ist es dasselbe.)
Genauso wichtig ist die andere Seite der Medaille: Nicht alles lässt sich durch KI ersetzen. Manche Schritte gehören bewusst in Menschenhand. Die Kunst liegt darin, sauber zu unterscheiden: Wo kann eine KI ran, wo reicht eine simple Automatisierung – und wo braucht es zwingend den Menschen?
Wie wir das Lastenheft Schritt für Schritt gebaut haben
Erfassen: vom Workshop-Foto zur ersten Struktur
Den Einstieg in jedes Projekt bildet der System-Footprint-Workshop. Hier visualisieren wir mit dem Kunden den Inhalt auf einer Art Canvas – Themenfelder mit gelben und orangenen Post-its. Diesen Schritt moderiert ein Mensch, daran ändert sich nichts.
Das Ergebnis war in unserem Fall schlicht ein abfotografiertes Workshop-Board. Dieses Foto haben wir dem ersten Agenten gegeben mit der Anweisung: Erkenne die Felder und die Post-its und mach daraus die ersten Kapitel des Dokuments.
Das war das erste Aha. Denn der Footprint bildet die Lastenheft-Struktur auf Kapitelebene ab – und jeder Post-it-Zettel wird zum Unterkapitel. Heraus kam die Version 0.1 des Lastenhefts: noch ohne Inhalte, aber mit einer sauberen Struktur, die man jetzt befüllen kann. Genau diese Übertragung habe ich früher mühsam per Hand gemacht.
Sortieren, Teil 1: „Dieter Dokumentenfresser“
Jetzt musste Inhalt in die Struktur. Der klassische Ablauf: Man holt sich die ganzen Dokumente, die der Kunde irgendwo liegen hat, liest sie durch und überträgt die relevanten Inhalte in die passenden Kapitel. Eine echte Sisyphus-Arbeit – wie geschaffen für einen Agenten.
Der erste Versuch ging schief: Wir wollten alle ~20 Dokumente auf einmal in einen Agenten kippen. Kapazitätsgrenze überschritten, zurück auf Start.
Die Lösung war ein Agent, der die Dokumente einzeln verarbeitet. Wir haben ihn Dieter Dokumentenfresser getauft – seine Aufgabe war, sich durch teils hunderte Seiten zu fressen. Sein Master-Prompt war bewusst straff:
- Rolle: Experte für Requirements Engineering
- Pro Durchlauf bekommt er ein Dokument, bestätigt die Aufgabe, dann legt er los
- Klare Vorgaben, wie er bewertet und ausgibt
- Keine Halluzinationen: Findet er etwas nicht, soll er das sagen – und sich die Information nicht irgendwo zusammensuchen
- Als Kontext bekam er das Ergebnis des Footprint-Workshops mit
Und dann passierte etwas Spannendes. Bei einem Dokument von MAN kam Dieter zurück und meldete: Die haben hier fossil betriebene Systeme, gar kein Ladevorgang vorgesehen – seid ihr sicher, dass das zum Projekt gehört? Genau dieses Problem kenne ich aus dem Alltag: Kunden schieben einem palettenweise Dokumente rüber, und nach dem Motto „viel hilft viel“ landet dann auch eine Norm für einen Verbrennermotor im Stapel, die mit der Wallbox nichts zu tun hat. Früher musste ich jedes davon überfliegen. Dieter hat uns hier echt Zeit gespart.
Sortieren, Teil 2: bewusst manuell
Dieters Ergebnisse kamen als Prosa-Text im Chatverlauf zurück (Tabellen hatte er teils sinnvoll in Fließtext umformuliert). Das Einsortieren in die richtigen Abschnitte haben wir komplett von Hand gemacht – ganz bewusst.
Diesen Schritt machen wir auch klassisch so: durchlesen, bewerten, und nur das von links nach rechts rüberkopieren, was wirklich sinnvoll ist. So finden wir Lücken, erkennen Fragliches und stimmen im Zweifel mit dem Kunden ab, ob etwas ins Lastenheft gehört oder nicht. Dieter hat es so aufbereitet, dass wir entscheiden konnten – die Entscheidung blieb beim Menschen.
Füllen: „Richard Anwort“ macht echte Anforderungen daraus
Jetzt stand viel Inhalt in den Kapiteln – aber als Prosa, nicht als Anforderungstext. Dafür entstand der nächste Agent: Richard Antwort.
Sein Master-Prompt war deutlich umfangreicher, weil hier das eigentliche Handwerk steckt. Wir haben ihm mitgegeben:
- die Rolle des Requirements Engineers
- die Schablonen, nach denen Anforderungen geschrieben werden („Das System muss …, um … zu erreichen“)
- die Verbindlichkeiten muss / soll / kann
- ein konkretes Beispiel einer fertigen Anforderung
- eine Arbeitsanweisung: erst dies, dann das, dann nochmal prüfen – also genau der Ablauf, den wir selbst im Kopf abspulen
Das ist der Punkt, der oft unterschätzt wird: Der Master-Prompt ist selbst eine Kunst für sich. Du musst dir überlegen, was du selber tun würdest, um ans Ziel zu kommen. In vielen Unternehmen steht genau das übrigens schon im Requirements Management Plan.
Wir haben dann pro Kapitel alle zugehörigen Post-its hineingegeben, und Richard hat saubere Anforderungen daraus erzeugt – inklusive der handwerklichen Regeln: jeden Satz vereinzeln, mit muss/soll/kann einstufen, Dopplungen und Widersprüche vermeiden. Das hat richtig gut funktioniert.
Prüfen: „Conny Consistent“ – und warum IDs alles verändern
Als Nächstes sollte ein Agent prüfen, ob die Anforderungen in sich konsistent sind. Klassisches Beispiel: An einer Stelle steht „weniger als 100 Kilo“, drei Kapitel weiter „weniger als 80 Kilo“. So etwas wollen wir sicher finden. Dieser Agent heißt Conny Consistent.
Bei der Entwicklung fiel ein blinder Fleck auf: Conny konnte zwar Widersprüche erkennen, aber nicht eindeutig benennen, welche Anforderung gemeint ist – es fehlten die IDs.
Hier lohnt ein kurzer Blick hinter die Kulissen: Jede vereinzelte Anforderung bekommt eine eindeutige Nummer. Diese ID zieht sich später durch die gesamte Arbeit – von der Systemanforderung über die Architektur bis zu Hardware, Software und Konstruktion. Sie ist die Grundlage für Traceability, also die Nachverfolgbarkeit jeder einzelnen Anforderung.
Sobald wir die IDs nachgezogen und das komplette bisherige Lastenheft geladen hatten, lieferte Conny saubere kleine Tabellen: Anforderung Nummer X und Y passen nicht zusammen, bitte nochmal prüfen. Damit stellte sie im Grunde die Arbeit von Richard auf den Prüfstand.
Wo wir den Mensch bewusst im Spiel lassen
Bei einigen Phasen ist die Antwort eindeutig: Das macht nur der Mensch.
- Lücken füllen: Wenn beim Workshop etwas besprochen wurde, Dieter aber in keinem Dokument etwas dazu findet, gehen wir auf den Kunden zu. Einen Telefon-Agenten, der beim Projektleiter anruft und sagt „Klaus, hör mal, da fehlt was“ – den bauen wir nicht.
- Prüfen und Freigeben sind hoch iterativ und interaktiv: Reviews, moderierte Workshops, Gespräche. Das bleibt Menschenarbeit.
Was sich an dieser Stelle trotzdem gut automatisieren lässt, sind die Kleinigkeiten. Mein Klassiker früher: vor der Auslieferung die Dokumentenversion auf dem Titelblatt zu erhöhen vergessen. Heute steht da ein kleiner Release-Agent, der vor jeder Übergabe an den Kunden die Checkliste durchgeht.
Der Blick nach vorne: mit dem Dokument reden
Wir sind noch nicht durch – und gerade das macht es spannend. Zwei Ideen für einen Agenten stehen schon auf dem Zettel:
Der Vorleser. Im Review lesen wir das Dokument live mit dem Kunden durch, Notar-Style: Solange keiner protestiert, geht es weiter. Das Anstrengende dabei: Man liest stundenlang vor und führt parallel Protokoll und achtet die ganze Zeit auf die Gruppe – das Grummeln, das Kopfkratzen, die nonverbalen Signale, die gerade bei introvertierten Nerds am Anfang stehen. Ein Agent mit eigener Stimme könnte das Vorlesen übernehmen, während wir auf der Stopptaste sitzen und den Raum lesen. (Dass das geht, weiß ich: Schon 2024 habe ich vier KIs zusammengeschnallt, mein Buch eingespeist – und dann konnte man mein Buch anrufen und mit ihm telefonieren, in meiner Stimme.)
Der Protokoll-Umsetzer. Im Review-Protokoll steht ja bereits, welche ID sich wie ändern soll – etwa ein „soll“, das zum „muss“ wird. Ein kleiner Agent zieht sich dieses Protokoll, sucht die betroffene Anforderung über die ID heraus und ändert genau diese eine Stelle.
Und dann ist da noch das Forschungsprojekt, das mich am meisten elektrisiert: Björn hat ausprobiert, die Anforderungen nicht nur in Markdown, sondern in SysML v2 (System Modeling Language) generieren zu lassen – die textuelle Beschreibung einer Systemarchitektur. Daraus lässt sich eine grafische Repräsentation erzeugen. Und über das MCP-Protokoll kann man das Modell sogar andocken und mit ihm sprechen: „Wofür wurdest du gebaut? Welche Anforderungen fehlen dir noch?“ Da steckt mehr Potenzial drin, als wir uns heute vorstellen können.
Tipps aus unserer Praxis
Wenn du selbst eine freiberufliche Dienstleistung mit KI skalieren willst, sind das die Punkte, die bei uns den Unterschied gemacht haben:
- Zerlege dein Handwerk, bevor du automatisierst. Erst klar machen, was die einzelnen Schritte und Phasen sind. Dann pro Schritt entscheiden: Mensch, Automatisierung oder Agent? Nur das macht spezialisierte Agenten überhaupt möglich.
- Ein Agent, eine Aufgabe, ein guter Master-Prompt. Gib dem Agenten dein meisterliches Handwerk mit – Rollen, Regeln, Schablonen, ein Beispiel und eine klare Arbeitsanweisung. Und sag ihm ausdrücklich, was er nicht tun soll (Stichwort Halluzinationen).
- Denk an Datensicherheit und Formate. Wir arbeiten bewusst in einer Umgebung mit Sitz in Europa, statt sensible Lastenhefte – in denen Technologie von übermorgen steckt – irgendwohin abfließen zu lassen.
- Wir schreiben in Markdown: reine Textdateien, die beim Anbieter keinen Vendor-Lock-in erzeugen, lokal auf dem Rechner bleiben und genau das Format sind, mit dem die KI ohnehin am liebsten arbeitet.
- Gib der KI kein PDF oder Excel. Das muss sie erst umständlich konvertieren – gib ihr mit Markdown im vornherein das Format, in dem sie sowieso zu Hause ist.
Das war ein Zwischenstand aus einem laufenden Experiment. Zwei weitere Agenten und das SysML-Thema heben wir uns für eine der nächsten Episoden auf. Wenn dich Lastenhefte und Systems Engineering interessieren, findest du Björn Schorre auf seiner Website und auf LinkedIn
Eine Blogparade mit Erfahungs über künstliche Intelligenz im Berufsalltag
Michael Schenkel hat eine Blogparade gestartet: Kein Algorithmus kuratiert die Beiträge, kein Redaktionsteam glättet die Kanten. Es schreiben nur Menschen, die von ihren eigenen Erfahrungen berichten. Ich finde, es ist einen Versuch wert.
Welches Thema verdient das gerade mehr als dieses: Künstliche Intelligenz und die Frage, was sie mit unserer Arbeit und mit uns macht? Künstliche Intelligenz und die Frage, was sie mit unserer Arbeit und mit uns macht.
Aus der Praxis, für die Praxis.
Deshalb ich gerne mit dieser Podcast Episode was bei und empfehle dir die Blogparade „KI und mein Job” mit vielen spannenden Beiträgen.
