KI-Agenten Mehrwert statt Mythos – das 500-Seiten-Experiment

KI-Agenten haben einen zwiespältigen Ruf. In vielen Ingenieurabteilungen gelten sie als nette Helfer für die Routine: Sie fassen Texte zusammen, erleichtern das Onboarding, beantworten einfache Fragen. Dabei können sie viel mehr. 

Sobald es um die eigentliche Wertschöpfung geht, wie beispielsweise die systemnahe Modellbildung, komplexe Analysen oder die kritische Bewertung von Simulationsergebnissen, lautet die landläufige Annahme: Hier muss der Experte ran, von Hand. Genau diese Annahme wurde mit dem KI-Agenten Dyad von JuliaHub auf die Probe gestellt: Wie ein Dyad-Agent ein NASA-Raumgleitermodell aus unstrukturierten Rohdaten rekonstruiert.

Das Grundproblem: Informationen als heterogene Artefakte

Wer in der Luft- und Raumfahrt ein belastbares Simulationsmodell aufsetzt, kennt den eigentlichen Engpass: nicht das Rechnen, sondern das Übersetzen. Die relevanten Informationen liegen als heterogene Artefakte vor: PDF-Spezifikationen, technische Dokumentationen, Notizen, Nachschlagetabellen. Diese Quellen sind für Menschen lesbar, aber nicht direkt ausführbar. Ein Ingenieur muss sie sichten, interpretieren, Koeffizienten und Einheiten herausziehen und das Ganze in ein konsistentes, lauffähiges Modell überführen. Dieser Schritt ist langsam und fehleranfällig; er verschlingt regelmäßig Tage an Ingenieurarbeit, bevor überhaupt die erste sinnvolle Simulation läuft.

Hier nun setzt das aktuelle Beispiel an. Statt theoretisch über die Grenzen von KI-Agenten zu streiten, wurde dem Dyad-Agenten eine anspruchsvolle, realitätsnahe Aufgabe gestellt.

Der Prüfstein für den KI-Agenten: NASA HL-20

Als Benchmark dient die HL-20, ein Lifting-Body-Konzept der NASA aus den frühen 1990er-Jahren. Der Raumgleiter war als sichere, flexible Alternative für den Crew-Transport zur und von der geplanten Raumstation Freedom gedacht. In Serie ging er nie, für diese Zwecke ist er dennoch ideal, weil die NASA umfangreich dokumentiert hat, wie sich das Fahrzeug simulieren lässt.

Die HL-20 ist ein klassischer Lifting Body, gesteuert über eine Kombination aus Body-Flaps, Seitenruder und Wing-Flaps. Diese Architektur macht das Fahrzeug zum anspruchsvollen Testfall: Sie erfordert ein komplexes Mapping von Pilotenkommandos auf Steuerflächen. Die NASA-Dokumentation enthält dafür einen sogenannten Control Mixer. Ihn nachzubilden, ist eine der Kernaufgaben des KI-Agenten und ein Bereich, in dem sich handgeführte Übersetzungsfehler besonders teuer rächen, denn es geht hier um ein sicherheitskritisches System für die bemannte Raumfahrt.

Drei Rohdaten, ein Auftrag

Der Agent erhält exakt die Informationsquellen, die auch ein menschlicher Ingenieur bekäme:

1. README: definiert den Rahmen. Was soll das Modell abbilden, und woran misst sich Erfolg? Etwa daran, dass das erwartete aerodynamische Verhalten reproduziert wird.
2. PDF-Spezifikation: die Quelle der Wahrheit für das Fahrzeug – aerodynamische Koeffizienten, Geometrie, Masseneigenschaften. Unstrukturiert, menschenlesbar, nicht ausführbar.
3. DML-Datei: enthält Nachschlagetabellen mit aerodynamischen Daten, die der Agent prüfen, gegen die Spezifikation validieren und in ein Gesamtmodell integrieren muss.

Entscheidend ist die Art der Aufgabenstellung. Der Prompt ist bewusst hochrangig gehalten. Dem Agenten wird nicht Schritt für Schritt vorgeschrieben, wie er vorzugehen hat. Er soll die Eingaben lesen, ein dynamisches Modell der HL-20 konstruieren und sicherstellen, dass es sich gemäß Spezifikation verhält. Das Wie bleibt ihm überlassen.

Im Inneren der Reasoning-Trace

Was dann folgt, ist als vollständige Argumentationsspur sichtbar. Der Agent liest zunächst quer über alle drei Eingaben hinweg und unterscheidet, was bereits strukturiert vorliegt, wie zum Beispiel die Lookup-Tabellen, und was er erst aus dem PDF extrahieren muss: Koeffizienten, Variablendefinitionen, Einheiten.

Daraus baut er das Modell auf. Er definiert die Systemzustände – Geschwindigkeit, Anstellwinkel, Nickrate – und überführt die aerodynamischen Daten in nutzbare Formen. Die Tabellen aus der DML-Datei werden interpretiert und in die Gleichungen eingebunden, die Kräfte und Bewegungen beschreiben.

Bemerkenswert ist, dass der Agent Dyad-Modelle direkt liest und schreibt. Er erzeugt nicht isoliert Code, sondern modifiziert eine native Modellrepräsentation, verbindet Komponenten und baut ein vollständiges System. Parallel schreibt und führt er Julia-Code inline aus, etwa um Interpolationsfunktionen aus den Tabellendaten zu erzeugen, Zwischenergebnisse zu prüfen oder die Konsistenz von Einheiten und Größenordnungen zu kontrollieren.

Dieser Ausführungsschritt ist der eigentliche Hebel. Er erlaubt dem Agenten, die eigene Arbeit zu verifizieren, statt nur statische Ausgaben zu produzieren. Stößt er auf Unstimmigkeiten, zum Beispiel einen Einheitenfehler, einen fehlenden Parameter oder einen Widerspruch zwischen PDF und DML, erkennt er diese und korrigiert den Kurs. Diese Schleife aus Schreiben, Ausführen, Prüfen und Verfeinern läuft kontinuierlich.

Während das Modell Gestalt annimmt, verdrahtet der Agent zugleich die Steuerungskette: Er verbindet Kommandos, Aktuatorzustände und die resultierende Fahrzeugdynamik zu einem kohärenten System. Was sonst mehrere Werkzeuge und viel manuelle Arbeit erfordert, geschieht hier in einem einzigen, durchgängigen Workflow.

Der Beweis: ein Nickpuls gegen die NASA-Referenz

Ein Modell, das nur läuft, beweist wenig. Deshalb folgt die Validierung. Die PDF-Spezifikation enthält nicht nur die Fahrzeug- und Aerodynamikdaten, sondern auch Referenzergebnisse für konkrete Testfälle. Verwendet wird der Fall Trim K0, der einen Nickpuls des Piloten aufprägt. Dieser Puls wird zur Eingabe des Modells; der frisch erzeugte HL-20-Simulator berechnet die Fahrzeugreaktion über die Zeit.

Die entscheidende Frage lautet nicht, ob das Modell rechnet, sondern ob seine Ausgaben (Nickrate, Höhenruderausschlag und weitere Reaktionsgrößen) mit den Referenzwerten aus dem NASA-Dokument übereinstimmen. Und das tun sie. Wenn die Kurven zur Deckung kommen, ist belegt: Das vom Agenten gebaute Modell ist mit der ursprünglichen Spezifikation konsistent.

Vom Bauarbeiter zum Piloten

Damit schließt sich der Kreis von der Spezifikation bis zum validierten Modell, ohne eine einzige manuelle Übersetzung. Der Agent liest die Quell-Artefakte, baut und führt das Modell aus und weist nach, dass es das erwartete physikalische Verhalten reproduziert. Was traditionell Tage an Ingenieurarbeit kostet, schrumpft auf einen durchgängigen Arbeitsablauf.

Das ist mehr als ein Produktivitätsgewinn; es ist eine Verschiebung im digitalen Engineering. Der Experte verschwindet nicht, vielmehr verwandelt sich seine Rolle. Aus dem manuellen Modellbauer wird ein strategischer Pilot, der Ziele setzt, Randbedingungen vorgibt und das Ergebnis kritisch prüft, während der Agent die mühsame Übersetzungsarbeit übernimmt. Der Mensch bleibt dort in der Schleife, wo es zählt: bei der Verantwortung dafür, dass am Ende alles zusammenpasst. (anm)

Der Autor, Dr. Michael Hoffmann, ist Head of Business Development, Europe, JuliaHub.

Weitere Informationen: https://juliahub.com/

Design Automation Conference DAC 2026

Wie Agentic AI die autonome Chip-Entwicklung vorantreibt