Ich wollte eigentlich nur eine bessere Sonnenbrille.
Das Problem: Ich bin Brillenträger.
Normale Sonnenbrillen funktionieren deshalb für mich schlecht. Ich hatte bereits eine Überzieh-Sonnenbrille, die über meiner normalen Korrekturbrille getragen werden konnte. Das Prinzip funktionierte – die konkrete Umsetzung aber nicht wirklich.
Der ursprüngliche Rahmen war mir zu klobig. Er wollte zusätzlich auf meiner Nase aufliegen, obwohl dort bereits meine normale Brille sitzt. Unter meinen Fahrradhelm passte er ebenfalls schlecht.
Und trotz des ziemlich grossen Rahmens gab es noch ein weiteres Problem: Seitlich konnte die Sonne weiterhin direkt ins Auge scheinen, weil dort praktisch keine Abdeckung vorhanden war.
Also wurde aus einem kleinen Alltagsproblem plötzlich eine ziemlich typische Engineering-Aufgabe.
Mach mir eine Sonnenbrille für Brillenträger, die über meine normale Brille passt, nicht zusätzlich auf meiner Nase aufliegt, unter meinen Fahrradhelm passt, weniger klobig ist und gleichzeitig die Sonne auch von der Seite abschirmt.
Das Interessante daran: Ich habe den neuen Rahmen nicht klassisch im CAD konstruiert.
Ich habe Claude Code über ein MCP mit einem CAD-System verbunden und das LLM die Konstruktion übernehmen lassen.
Das eigentliche Problem war nicht CAD
Wenn ich den Rahmen klassisch konstruiert hätte, hätte ich vermutlich zuerst das bestehende Modell vermessen, Skizzen angelegt, Abstände definiert, Flächen aufgebaut, Radien verändert und mehrere Varianten ausprobiert.
Dieses Mal konnte ich mich stattdessen viel stärker auf die eigentlichen Anforderungen konzentrieren.
Der neue Rahmen sollte:
- über meine normale Korrekturbrille passen,
- möglichst wenig zusätzlich auf der Nase aufliegen,
- schmal genug sein, um unter meinen Fahrradhelm zu passen,
- nicht unnötig klobig wirken,
- die vorhandenen Sonnengläser aufnehmen,
- und seitlich deutlich besser gegen einfallendes Sonnenlicht abschirmen.
Das sind eigentlich genau die Fragen, um die sich Engineering drehen sollte.
Nicht:
Wo ist jetzt noch einmal das Fillet-Werkzeug?
Sondern:
Was muss dieses Bauteil können?
Von der Idee direkt ins CAD
Ich habe Claude Code Zugriff auf mein CAD-System gegeben.
Dadurch konnte ich Änderungen zunehmend in natürlicher Sprache beschreiben.
Der Rahmen ist hier zu breit.
Diese Stelle muss näher an meiner normalen Brille vorbeilaufen.
Die Bügel müssen unter einen Fahrradhelm passen.
Hier brauche ich seitlich mehr Fläche gegen einfallendes Sonnenlicht.
Die Nase soll möglichst frei bleiben.
Das LLM übersetzte diese Anforderungen in konkrete Operationen im CAD.
Ich selbst musste das CAD dabei kaum noch aktiv bedienen.
Und genau das war für mich der spannendste Teil des Experiments.
Meine Rolle veränderte sich.
Ich war weniger derjenige, der jeden einzelnen CAD-Befehl ausführt, und zunehmend derjenige, der Anforderungen definiert, Varianten beurteilt und Entscheidungen trifft.
Das ist eigentlich näher an Engineering
Der ursprüngliche Rahmen hatte mehrere Nachteile gleichzeitig.
Und sobald man versucht, einen davon zu lösen, entstehen neue Zielkonflikte.
Wenn ich den Rahmen einfach schmaler mache, passt er vielleicht besser unter den Helm – aber möglicherweise verliere ich seitlichen Sonnenschutz.
Wenn ich grosse Seitenflächen hinzufüge, wird der Rahmen wieder klobiger.
Wenn ich die Nasenauflage reduziere oder entferne, muss der Rahmen anders stabil geführt werden.
Wenn er über eine vorhandene Brille passen soll, muss deren Geometrie ebenfalls berücksichtigt werden.
Das sind klassische Engineering-Probleme.
Es gibt nicht einfach eine einzelne perfekte Dimension.
Es gibt mehrere Anforderungen, die teilweise gegeneinander arbeiten.
Und genau hier liegt für mich eines der grossen Potenziale von LLMs im Engineering.
Nicht darin, dass ein Modell einfach irgendeine Geometrie erzeugt.
Sondern darin, dass wir ihm Anforderungen und Randbedingungen geben und es anschliessend dabei helfen kann, den möglichen Lösungsraum zu erkunden.
In Zukunft beschreiben wir vielleicht primär Anforderungen
Heute lernen Ingenieure sehr viel darüber, wie man Engineering-Software bedient.
Wie erstelle ich eine Skizze?
Wie setze ich Constraints?
Wie erzeuge ich eine Extrusion?
Wie konstruiere ich eine Fläche?
Wie lege ich eine FEM-Analyse an?
All diese Fähigkeiten sind nützlich.
Aber sie sind nicht das eigentliche Ziel.
Das Ziel ist das Produkt.
Ich könnte mir deshalb vorstellen, dass ein zukünftiger Workflow beispielsweise so aussieht:
Konstruiere einen Sonnenbrillenrahmen für diese vorhandene Korrekturbrille.
Verwende diese vorhandenen Gläser.
Der Rahmen darf meine Nase nicht zusätzlich belasten.
Er muss unter meinen Fahrradhelm passen.
Seitlich soll möglichst kein direktes Sonnenlicht ins Auge fallen.
Das komplette Teil soll mit meinem FDM-Drucker herstellbar sein.
Maximales Gewicht: 35 Gramm.
Das System könnte daraus mehrere Varianten erzeugen.
- eine besonders schmale Version,
- eine Variante mit maximalem seitlichem Sonnenschutz,
- eine besonders leichte Version,
- eine speziell fürs Fahrrad optimierte Variante.
Ich suche dann nicht mehr mühsam eine Geometrie zusammen.
Ich definiere zunehmend den Design Space.
Das lässt sich auf wesentlich grössere Engineering-Aufgaben übertragen
Eine Sonnenbrille ist natürlich ein relativ überschaubares Produkt.
Aber der gleiche Workflow lässt sich weiterdenken.
Ich könnte beispielsweise sagen:
Dieser Fahrradhalter bricht bei ungefähr 120 Newton. Er soll 300 Newton aushalten und maximal zehn Prozent schwerer werden.
Ein zukünftiger Agent könnte daraufhin:
- das CAD-Modell analysieren,
- eine FEM-Simulation starten,
- kritische Spannungsspitzen finden,
- mehrere Geometrievarianten erzeugen,
- diese erneut simulieren,
- Materialverbrauch und Gewicht vergleichen,
- die Druckbarkeit überprüfen,
- und am Ende die besten Varianten präsentieren.
Oder ich sage:
Konstruiere mir einen leichten Fahrradanhänger aus Bambusrohren und 3D-gedruckten Muffen für 40 Kilogramm Nutzlast.
Dann könnten mehrere spezialisierte Werkzeuge zusammenarbeiten.
CAD für die Geometrie.
FEM für die Festigkeit.
Materialdatenbanken für Werkstoffkennwerte.
Ein Slicer für die Fertigbarkeit.
Ein Kostenmodell für Material- und Produktionskosten.
Das LLM müsste all diese Systeme nicht ersetzen.
Es müsste sie orchestrieren.
MCP könnte dafür ein wichtiger Baustein sein
Genau deshalb finde ich das Model Context Protocol, kurz MCP, in diesem Zusammenhang so interessant.
Ein LLM alleine kann keine reale Maschine konstruieren.
Es braucht Werkzeuge.
- CAD-Systeme
- Simulationen
- Materialdatenbanken
- Slicer
- Compiler
- Messgeräte
- 3D-Scanner
- vielleicht später sogar CNC-Maschinen, Roboter und Prüfstände
Wenn ein Sprachmodell auf diese Werkzeuge zugreifen kann, verändert sich seine Rolle.
Aus einem Chatbot wird zunehmend ein technischer Agent.
Das CAD muss dann nicht mehr zwingend die primäre Benutzeroberfläche sein.
Das CAD wird zu einem Werkzeug, das der Agent benutzt.
Die eigentliche Benutzeroberfläche wird zunehmend Sprache.
Das CAD verschwindet nicht – es rutscht eine Ebene tiefer
In der Softwareentwicklung ist etwas Ähnliches bereits mehrfach passiert.
Maschinencode.
Assembler.
C.
Python.
Frameworks.
APIs.
Mit jeder neuen Abstraktionsschicht konnten wir komplexere Systeme bauen, ohne ständig sämtliche darunterliegenden Details direkt kontrollieren zu müssen.
Die unteren Schichten sind dadurch nicht verschwunden.
Sie wurden abstrahiert.
Vielleicht passiert im Engineering gerade etwas Ähnliches.
Heute:
Sketch → Constraint → Extrude → Fillet → Boolean
Zukünftig vielleicht:
Der Bereich muss dünner werden, darf sich unter 200 Newton aber maximal einen Millimeter verformen.
Das System entscheidet anschliessend selbst, welche geometrischen Operationen dafür sinnvoll sind.
Das wäre eine deutlich höhere Abstraktionsebene.
Der Ingenieur wird dadurch nicht unwichtig
Im Gegenteil.
Wenn Computer immer mehr von der Bedienung der Werkzeuge übernehmen, wird es noch wichtiger, gute Anforderungen zu formulieren.
Bei meiner Sonnenbrille war beispielsweise überhaupt nicht offensichtlich, was «besser» bedeutet.
Kleiner?
Leichter?
Mehr Sonnenschutz?
Bequemer?
Helmkompatibel?
Mehr Abstand zur Korrekturbrille?
All diese Anforderungen müssen gegeneinander abgewogen werden.
Ein LLM kann Varianten erzeugen.
Aber jemand muss beurteilen, ob sie in der realen Welt tatsächlich funktionieren.
Und spätestens bei belasteten Bauteilen, Maschinen oder sicherheitsrelevanten Konstruktionen braucht es technische Erfahrung, Tests und saubere Verifikation.
Der Unterschied ist nur:
Wir könnten einen immer grösseren Teil der mechanischen Routinearbeit delegieren.
Besonders spannend wird der geschlossene Engineering-Kreislauf
Meine Sonnenbrille war bereits ein kleiner iterativer Prozess.
Konstruktion.
Drucken.
Anprobieren.
Feststellen, was nicht passt.
Ändern.
Erneut drucken.
Aber auch dieser Ablauf könnte in Zukunft stärker automatisiert werden.
Ein 3D-Scan könnte beispielsweise messen, wie meine normale Brille im Gesicht sitzt.
Ein Scan des Fahrradhelms könnte den verfügbaren Bauraum definieren.
Eine Kamera könnte erkennen, wo Rahmen und Helm kollidieren.
Messwerte könnten zeigen, wo sich der Rahmen zu stark verformt.
Die Geometrie könnte anschliessend automatisch angepasst werden.
Dann hätten wir einen geschlossenen Kreislauf:
Anforderung → Konstruktion → Simulation → Fertigung → Messung → Optimierung
Ein LLM-Agent könnte diesen gesamten Prozess koordinieren.
Das verändert auch, wer Dinge entwickeln kann
Vielleicht ist das langfristig sogar der grösste Effekt.
CAD und Engineering-Software haben eine ziemlich hohe Einstiegshürde.
Wenn jemand eine gute technische Idee hat, aber keine Erfahrung mit parametrischem Modellieren, FEM oder CAM besitzt, kommt er heute oft nur schwer vom Gedanken zum funktionierenden Produkt.
LLMs könnten diese Hürde deutlich senken.
Nicht jeder wird dadurch automatisch Ingenieur.
Aber viel mehr Menschen könnten technische Ideen tatsächlich ausprobieren.
- Maker
- Handwerker
- Designer
- Programmierer
- Velomechaniker
- kleine Unternehmen
- Schüler und Studenten
Ein Handwerker könnte eine spezielle Vorrichtung beschreiben.
Ein Velomechaniker eine neue Halterung.
Ein Fotograf einen Adapter.
Und ein Brillenträger eben eine Sonnenbrille, die exakt zu seinem Problem passt.
Mit einem 3D-Drucker kann wenige Stunden später bereits ein physisches Objekt auf dem Tisch liegen.
Meine Sonnenbrille ist deshalb nur der Anfang
Das eigentlich Interessante an diesem Projekt ist für mich nicht, dass AI eine Sonnenbrille konstruieren kann.
Interessant ist die Veränderung des Workflows.
Ich hatte ein konkretes Problem in der realen Welt.
Der bestehende Rahmen war zu klobig.
Er wollte zusätzlich auf meiner Nase sitzen.
Er passte schlecht unter meinen Fahrradhelm.
Und seitlich konnte mich die Sonne trotzdem noch blenden.
Ich habe diese Probleme beschrieben.
Das LLM hat das CAD bedient.
Ich habe das Resultat beurteilt.
Dann kam die nächste Iteration.
Das fühlt sich für mich nach einem kleinen Vorgeschmack darauf an, wie Engineering in einigen Jahren aussehen könnte.
Wir verbringen weniger Zeit damit, jedem Werkzeug jeden einzelnen Schritt vorzugeben.
Stattdessen definieren wir Ziele, Randbedingungen und Prioritäten.
Die Maschinen übernehmen einen immer grösseren Teil der Umsetzung.
Die entscheidende Frage lautet dann vielleicht nicht mehr:
Kannst du dieses CAD bedienen?
Sondern:
Kannst du präzise beschreiben, welches Problem wir eigentlich lösen müssen?
Meine 3D-gedruckte Sonnenbrille ist dabei nur ein kleines Beispiel.
Aber vielleicht ist genau das der Anfang einer ziemlich grossen Veränderung im Engineering.