KI in der Konstruktion: Demos vs. echte Workflows

Wo KI in der Konstruktion heute schon funktioniert, wo nicht, und wer das Fehlende entwickeln wird.

KI generiert ein 3D-CAD-Modell aus einem Text-Prompt

Wo funktioniert KI in der Konstruktion heute tatsächlich, wo nicht – und wer entwickelt, was noch fehlt?

Multimodale LLMs sind überraschend gut darin geworden, technische Artefakte zu verstehen: Spezifikationen, 3D-Geometrie und Zeichnungen. Das eröffnet Möglichkeiten, Konstruktionsworkflows neu zu denken. Einige profitieren schon heute von KI. Andere scheitern am Datenzugang. Und manche der gehypten Anwendungsfälle halte ich schlicht für überschätzt.

Dieser Beitrag ist meine Einschätzung: Wo verändert KI den Konstruktionsprozess, wo nicht, und wer baut die Konstruktions-KI-Software – Startups oder CAD-Konzerne? Ich konzentriere mich auf multimodale LLMs wie GPT und Gemini, nicht auf klassisches ML.

Artefakt-Erstellung

3D-CAD-Generierung

Das ist der Bereich, der die meiste Aufmerksamkeit und die beeindruckendsten Demos bekommt. Aber die Diskussion geht oft am Kern vorbei.

KI kann heute 3D-CAD-Modelle generieren. Es gibt funktionierende Ansätze: KI schreibt OpenSCAD- oder CadQuery-Skripte oder ruft CAD-APIs auf, um parametrische Modelle durch Operationen wie Extrudieren, Ausschneiden und Verrunden zu erstellen [1-4]. Für einfache bis mittelkomplexe Teile entsteht dabei echte, nutzbare Geometrie.

Claude Code konstruiert einen Roboterarm über die FreeCAD-API
Claude Code konstruiert einen Roboterarm über die FreeCAD-API. Bild von Roman Likhachev [4].

Ich habe damit herumgespielt, es funktioniert. Aber die eigentliche Frage ist eine andere: Ist das tatsächlich ein besserer Workflow?

Wenn man eine Spezifikation hätte, die das Teil vollständig beschreibt – jedes Maß, jede Toleranz, Material, Schnittstellen – dann wäre KI-Generierung überzeugend. Spezifikation rein, Modell raus. Warum nicht? Aber in der Praxis sind Spezifikationen selten so vollständig. Ingenieure treffen viele Entscheidungen erst beim Modellieren. Welche Geometrie bei welchem Fertigungsverfahren funktioniert, wie das Teil mit angrenzenden Bauteilen zusammenwirkt, welche Kompromisse zwischen Kosten und Leistung sinnvoll sind. Das klärt sich während der Modellierung, nicht davor.

Und für diese Art von iterativer, explorativer Arbeit ist das CAD-Userinterface maßgeschneidert. Auf eine Kante klicken, um eine Abrundung hinzuzufügen, eine Fläche zur Extrusion auswählen, Geometrie verschieben, um zu sehen wie sie sich verhält – diese Interaktionen sind für das Arbeiten mit 3D-Geometrie optimiert. Dieselben Operationen in Text zu beschreiben, ist schwieriger, nicht einfacher. “Runde die Kante ab, an der die Oberseite auf die linke Rippe trifft” ist langsamer und mehrdeutiger als einfach auf die Kante zu klicken. Und wenn die Spezifikation nicht vollständig ist, trifft die KI eigene Entscheidungen: Eine Wandstärke von 3 mm statt 4 mm, ein Radius von 2 mm statt 5 mm. Im CAD tippt der Ingenieur den Wert bewusst ein und sieht sofort das Ergebnis. Per Text müsste er der KI jeden Wert einzeln mitgeben. Das ist aufwändiger, nicht einfacher.

Interessant wird KI-getriebene CAD-Generierung in anderen Bereichen, zum Beispiel bei der Konzeptexploration. Angenommen, man ist ganz am Anfang der Konzeptphase: funktionale Anforderungen und grobe Randbedingungen stehen, aber Wirkprinzip und Geometrietyp sind noch offen. Gleitlager oder Wälzlager? Verschrauben oder Schweißen? Man könnte der KI die Anforderungen geben und ein Dutzend konzeptionell unterschiedlicher Lösungen generieren lassen – keine ausgefeilten, produktionsreifen Modelle, sondern grobe 3D-Konzepte, die grundlegend verschiedene Ansätze darstellen. Wie ein Ingenieur, der Alternativen ans Whiteboard skizziert – nur schneller und vielfältiger.

Das ist wertvoll, weil Ingenieure dazu neigen, sich auf das erste Konzept festzulegen, das zu funktionieren scheint. Wenn KI vielfältige Kandidaten generiert – ein Gussgehäuse vs. eine Schweißkonstruktion vs. ein Blechgehäuse für dieselbe Funktion – können Teams jede Option genauer untersuchen, bevor sie sich festlegen.

Ein weiterer sinnvoller Einsatz sind CAD-Konfiguratoren. Viele Unternehmen nutzen regelbasierte CAD-Programme, um Produktvarianten zu generieren, zum Beispiel Hersteller, die Fertigungslinien oder Prüfstände aus Bosch-Rexroth- oder 80/20-Profilen zusammenstellen. Teile dieses deterministischen Konfigurationscodes durch ein LLM zu ersetzen, könnte mehr Flexibilität ermöglichen. Die nutzbaren Bauteile bleiben weiterhin streng limitiert, doch das LLM kombiniert diese freier als die Wenn-Dann-Logik.

Spekulativer ist Bild-zu-CAD: Ein Ingenieur an der Produktionslinie fotografiert ein defektes Teil, das er nicht identifizieren kann, und bekommt eine Ausgangsbasis für die Konstruktion eines Ersatzteils. Ob das in der Praxis wirklich etwas bringt, muss sich zeigen.

Damit KI-getriebene CAD-Generierung gut funktioniert, muss sie eine parametrische CAD-API aufrufen. CAD-Hersteller sind hier am besten positioniert, weil sie die Dateiformate und parametrischen Modellierkerne kontrollieren. Siemens NX, Dassaults SolidWorks und CATIA sowie PTCs Creo und Onshape haben jeweils proprietäre Feature-Tree-Strukturen, in die sie KI direkt integrieren können. Aber einige Anwendungsfälle wie Bild-zu-CAD oder Konfiguratoren sind möglicherweise nicht das, wonach traditionelle CAD-Kunden fragen, sodass die großen Hersteller sie nicht priorisieren.

Das lässt Raum für andere Unternehmen, auf bestehenden CAD-Plattformen aufzubauen. Dafür sind gute öffentliche APIs wichtig. Wenn ein Newcomer auf einer etablierten Plattform statt auf Open-Source-Lösungen aufbauen will, sticht Onshape als eines der wenigen von Anfang an für die Cloud gebauten CAD-Systeme hervor.

Das erzeugt aber ein Spannungsfeld für Produkte wie Onshape: Die Geschäftsmodelle der Etablierten basieren auf dem Verkauf von Arbeitsplatzlizenzen (Seats). Wenn ein KI-Agent die API aufruft und Ingenieure die Oberfläche kaum noch öffnen, warum dann für die Lizenz bezahlen? Das ist ein klassisches Innovator’s Dilemma. Ein cloudbasierter Headless-CAD-Kernel – Bezahlung nach Nutzung statt pro Seat – könnte in den kommenden Jahren deutlich interessanter werden. Und das ist genau die Art von Produkt, bei dem die großen CAD-Hersteller zögern werden, weil es mit ihrem traditionellen Geschäftsmodell konkurriert und ihre bestehenden Kunden es nicht brauchen.

Meine Einschätzung: 3D-CAD-Generierung wird ihre Nische finden, zum Beispiel in der Konzeptexploration und in modularen CAD-Workflows, die derzeit auf komplexen Wenn-Dann-Regeln basieren. Aber den traditionellen Modellierungs-Workflow wird sie nicht so bald ersetzen. Nicht weil die KI nicht fähig genug ist, sondern weil der traditionelle Workflow oft schlicht das richtige Interface ist.

Zeichnungserstellung

Fertigungszeichnungen werden größtenteils aus 3D-Modellen abgeleitet. Das kann mit KI vollständig automatisiert werden, und die CAD-Hersteller bauen diese Funktionalität. Autodesks automatische Zeichnungserstellung in Fusion [5] ist ein Beispiel dafür. Man hat ein 3D-Teil, und die KI generiert eine 2D-Zeichnung mit Ansichten und Bemaßungen – nur ein wenig Detailarbeit durch den Menschen am Ende. Das ist eine natürliche Aufgabe für einen CAD-Hersteller: Er hat das 3D-Modell, er kennt die Geometrie, und die Zeichnung ist ein direktes Derivat. Das setzt Autodesk gut um, und es ist ein klarer Fall, in dem ein Etablierter KI in einen bestehenden Workflow integriert, wo es sofort Sinn ergibt.

Grundsätzlich braucht man kein 3D-Modell, um eine Zeichnung zu erstellen. Ich habe zum Beispiel simple Blechteile direkt von Hand gezeichnet. Oder schnelle Zeichnungen am Computer erstellt und an einen Zulieferer geschickt – mit der Bitte, daraus auf Basis seiner Standardbauformen ein komplettes Gehäuse zu konstruieren. Für solche Fälle könnte es sinnvoll sein, einen ersten Entwurf einer Fertigungszeichnung aus einer Textbeschreibung zu generieren. Text-zu-Zeichnung [6] funktioniert heute für einfache Geometrien: Winkelbleche, Flansche, Flachprofile. Man beschreibt das Teil, und die KI erstellt eine bemaßte Zeichnung. Wie bei 3D-Teilen ergibt das nur Sinn, wo eine Textbeschreibung schneller geht als die Arbeit mit Maus und Zeichnungsoberfläche. Bei komplexen Teilen will ich lieber klicken statt Geometrie in Worten zu beschreiben.

Insgesamt kann KI die Zeichnungserstellung deutlich verbessern. Aber es wird keine Disruption, sondern eine Verbesserung. Das Muster ist Mensch-KI-Mensch: Der Ingenieur entscheidet, welche Art von Zeichnung gebraucht wird, die KI erstellt einen vollständigen ersten Entwurf, und der Ingenieur gibt den letzten Feinschliff – achtet auf die richtigen Schwerpunkte und entscheidet, wann die Zeichnung fertig ist.

Prüfung und Analyse

Zeichnungsprüfung

Das ist der Bereich, den ich am besten kenne, und einer, in dem KI ebenfalls sofort nützlich ist. Moderne multimodale LLMs können eine Fertigungszeichnung betrachten und echte Probleme identifizieren: fehlende Maße, fragwürdige Toleranzen, DFM-Probleme, Fehler im Schriftfeld.

Perfekt ist es nicht: Mit zunehmender Komplexität – der einfachste Gradmesser ist die Anzahl der Elemente auf der Zeichnung – wird die Leistung schlechter. Außerdem muss der richtige Kontext mitgeliefert werden. Aber bei richtigem Einsatz ist die Genauigkeit hoch genug, um als erster Prüfschritt praktisch nützlich zu sein. Eine Art Rechtschreibprüfung für Zeichnungen: Sie fängt nicht jede Nuance ab, die ein erfahrener Ingenieur sehen würde, aber sie fängt die offensichtlichen Fehler ab, die im Review unnötig Zeit kosten.

Das schließt DFX-Prüfungen ein: fertigungsgerechte Konstruktion (DFM), montagegerechte Konstruktion (DFA), kostengerechte Konstruktion (DTC), normgerechte Konstruktion (DTS). Interessant dabei: KI braucht dafür keine fest codierten Regeln. Sie hat ein allgemeines Verständnis von Konstruktion und Fertigungsprozessen und kann Probleme wie “Diese Wandstärke wird im Spritzguss schwierig” oder “Diese Toleranz treibt die Kosten deutlich hoch” markieren, ohne dass jemand jede Regel manuell codiert. Eine echte neue Fähigkeit, die vor LLMs nicht existierte.

Foundation Models decken ein riesiges Spektrum an publiziertem Ingenieurwissen ab. Das Modell wird einem sagen, dass es unpraktisch ist, eine allgemeine Oberflächenrauheit zu spezifizieren, die Schweißnähte einschließt, oder dass die ISO-Toleranznorm im Schriftfeld im Widerspruch zur ASME-Notation in den Eintragungen steht. Wer weiß, wie LLMs funktionieren, wundert sich darüber nicht. Das steckt alles in den Trainingsdaten.

KI erkennt, dass die globale Oberflächenrauheit Ra 6.3 für ein Schweißteil problematisch ist
KI-Zeichnungsprüfung erkennt, dass die globale Oberflächenrauheit Ra 6.3 für ein Schweißteil problematisch ist.

Was mich wirklich überrascht: das geometrische Verständnis und Schlussfolgern. Wenn man sich ein Vision-Modell als Kombination aus OCR, Bilderkennung und LLM vorstellt – Texterkennung, “Hund oder Katze?”, Sprachverarbeitung – müsste es an Fertigungszeichnungen eigentlich scheitern. Eine Fertigungszeichnung zu lesen bedeutet, Maßlinien auf Merkmale zu beziehen und sich über mehrere Ansichten hinweg eine 3D-Vorstellung im Kopf zu halten. Und das Modell hat blinde Flecken: Bei Tests, die wir durchgeführt haben, hat das Vision-Modell ein benachbartes Maß fälschlicherweise auch einer unbemaßten Bohrung zugeordnet. Aber meistens stimmt es. Für mich ist das der überraschendere Teil.

KI ist in der Zeichnungsprüfung bereits jetzt gut genug, um nützlich zu sein. Aber für den nächsten Schritt lohnt ein Blick auf KI in der Softwareentwicklung: Tool-Nutzung. Genauso wie Coding-Agents Linter, Versionskontrolltools und Testsuites aufrufen, kann ein KI-Agent für Zeichnungsprüfung spezialisierte Engineering-Tools aufrufen – Blechfertigungssimulation (kann diese Biegung tatsächlich geformt werden?), Toleranzanalyse, Kostenberechnungsmodelle. Die KI übernimmt das allgemeine Schlussfolgern und die Orchestrierung, die spezialisierten Tools liefern Determinismus und Präzision. Diese Kombination bringt die höchste Qualität. Und sie muss noch gebaut werden.

Die Zeichnungsprüfung ist oft ein Flaschenhals im Freigabeprozess. Das sehe ich bei den Unternehmen, mit denen ich spreche. Manche verlangen zwei Freigaben pro Zeichnung, was zu einem langsamen Prozess führt und erhebliche Senior-Engineering-Zeit kostet. Andere machen gar kein Peer-Review. Um Verzögerungen zu vermeiden, gibt der Konstrukteur die Zeichnung direkt frei, mit dem Ergebnis, dass mehr Fehler in der Fertigung landen. In beiden Fällen hilft eine KI-Vorprüfung: Sie markiert Probleme, bevor das menschliche Review beginnt, beschleunigt den Prozess und fängt Fehler ab, die Ingenieure übersehen.

Wer sollte KI-Zeichnungsprüfung entwickeln?

CAD-Hersteller wie Siemens, PTC und Dassault könnten dies in ihre bestehenden Tools integrieren, und sie sind gut positioniert für Kunden, die bereits in ihrem Ökosystem sind. Ich glaube, Startups wie wir [7] haben hier ebenfalls eine Chance, weil dieser Workflow keine tiefe CAD-Integration erfordert – man braucht nur die Zeichnung als Bild oder PDF, was es ermöglicht, ein eigenständiges Produkt zu bauen, das über CAD-Plattformen hinweg funktioniert. Das ist besonders an der Schnittstelle zur Fertigung relevant, wo Zeichnungen von Zulieferern geprüft werden, die oft ein anderes CAD-System nutzen als der OEM.

Design Reviews in der Konzept- und Entwurfsphase

In Branchen wie Automotive oder Medizintechnik durchläuft ein neues Design typischerweise formale Design Reviews, lange bevor finale Fertigungszeichnungen erstellt werden. In der systematischen Produktentwicklung stellen solche Reviews Gates in der Konzept- und Entwurfsphase dar [8]. Können wir dieses Material verwenden? Erfüllt dieses Konzept die Anforderungen? Treffen wir die richtigen Kompromisse?

KI kann hier schon helfen, aber anders als bei Fertigungszeichnungen. In dieser Phase sind die Eingaben weniger strukturiert: Besprechungsnotizen, Skizzen, Anforderungsdokumente, in Arbeit befindliche CAD-Baugruppen, Simulationsergebnisse, informelle Berechnungen. LLMs sind gut darin, solche unstrukturierten Informationen zu verarbeiten. Sie können ein Designkonzept mit einer Anforderungsliste abgleichen und Lücken markieren, Kompromissanalysen zusammenfassen und Inkonsistenzen aufzeigen.

DFX-Überlegungen passen hier ebenfalls. In der Konzeptphase kann KI bereits auf Konstruktionsrichtungen hinweisen, die teuer in der Fertigung oder schwer zu montieren wären – nicht mit präzisen Berechnungen, sondern mit dem gleichen Erfahrungswissen, das ein erfahrener Ingenieur in ein Design Review einbringt. “Ist euch bewusst, dass diese Geometrie ein 5-Achs-CNC-Bearbeitungszentrum erfordert?” ist in der Konzeptphase wertvoller als jede detaillierte DFM-Analyse später.

Die Herausforderung ist der Datenzugang. Unstrukturierte Eingaben verarbeiten – Besprechungsnotizen, Skizzen, informelle Berechnungen – das können LLMs von Haus aus gut. Aber die Daten müssen dem Modell erst zur Verfügung gestellt werden. Und in früheren Designphasen, wo vieles noch im Fluss ist, ist auch der Kontext weniger zuverlässig. Dazu kommt, dass Unternehmen diese Reviews sehr unterschiedlich durchführen – manche arbeiten mit PowerPoint-Präsentationen, andere mit CAD-Modellen, wieder andere mit frühen Zeichnungen. Jede KI-Lösung muss entweder den Prozess definieren oder sich an den bestehenden Prozess jedes Unternehmens anpassen. Auch hier gilt: CAD- und PLM-Hersteller sind prinzipiell gut geeignet, da sie auf den Daten sitzen. Aber traditionell haben sie sich nicht auf cloudbasierte Zusammenarbeit über Unternehmensgrenzen hinweg konzentriert. CoLab [9] ist ein Startup, das in diesem Bereich entwickelt.

Es gibt weitere Workflows, in denen KI eine Rolle spielen wird, die ich hier nicht behandelt habe: Stücklistenmanagement, Teilwiederverwendung und -rationalisierung [10], Simulation, Änderungsfolgenanalyse, Anforderungsverfolgung und technische Dokumentation.

Wer orchestriert das Engineering?

Über einzelne Workflows hinaus stellt sich auch die Frage nach der darüberliegenden Schicht: eine KI-Orchestrierungsebene für das Engineering. Kein Tool, das eine Zeichnung prüft oder ein Teil generiert, sondern ein System, das den End-to-End-Prozess steuert – “nimm diese Anforderungsspezifikation, gleiche sie mit dem bestehenden Design ab, entwirf eine erste Version des Teils, analysiere es und markiere Probleme, führe eine DFM-Analyse durch, erstelle bei Bedarf ein Update v2, erstelle eine Fertigungszeichnung.”

Ein Engineering-Agent erhält eine Aufgabe und ruft PLM, CAD, FEA und DFM-Tools auf
Ein KI-Agent orchestriert Engineering-Tools, um eine Aufgabe durchgängig zu bearbeiten.

Die Softwareentwicklung gibt eine Vorschau, wie das aussehen könnte. Claude Code, aber verbunden mit CAD und PLM. Oder autonomer: OpenClaw [11] führt Engineering-Aufgaben aus, die durch Events ausgelöst werden, ohne einen Menschen in der Schleife.

Einige bauen das bereits direkt fürs Engineering. Zoos Zookeeper [12] bettet einen KI-Agenten direkt in ihre CAD-Plattform ein. Synera [13] und bananaz [14] verbinden CAx- und PLM-Tools, um Workflow-Orchestrierung zu ermöglichen. Wer die dominante Orchestrierungsebene entwickelt – CAD-Hersteller, die die Daten besitzen, KI-Labore, die Engineering als nächste Branche nach Software sehen, oder Startups, die keiner einzelnen CAD-Plattform verpflichtet sind – ist eine der interessantesten offenen Fragen in diesem Bereich.

Was sich abzeichnet

Wenn man alle diese Workflows betrachtet, zeichnen sich einige Muster ab:

KI prüfen lassen. Oder prüfen und fertigstellen, was KI begonnen hat. KI macht Fehler – das liegt in ihrer probabilistischen Natur. Deshalb ist ein Erstprüfen durch KI ein einfacherer Weg zum Mehrwert als die Erstellung durch KI. Eine KI, die auf einige wichtige Probleme hinweist, ist bereits wertvoll. Bei der Generierung ist das anders: Wenn einiges richtig, aber anderes komplett falsch ist, kann das Ergebnis schlimmer als nutzlos sein, weil das Nacharbeiten länger dauert als alles von Grund auf zu machen. Grob gesprochen denke ich, dass KI erst Prüfer und Berater wird. Und erst später Ersteller.

Datenzugang und -formate sind oft der limitierende Faktor, nicht die KI-Fähigkeit. Viele dieser Workflows werden nicht durch Modellbeschränkungen gebremst, sondern durch die Schwierigkeit, Engineering-Daten zugänglich und verarbeitbar zu machen. CAD-Dateien liegen in proprietären Formaten vor. Anforderungen leben in getrennten Systemen. Teiledatenbanken sind unordentlich. Das Datenintegrationsproblem zu lösen ist wichtig und schwierig. Wir werden möglicherweise auch neue Datenformate sehen, die für LLMs einfacher zu handhaben sind. Das gängigste Zeichnungsaustauschformat, DXF, ist ein kryptisches Format, das erstmals in den 80ern veröffentlicht wurde, mit einer Spezifikation als PDF. Als ich unser Zeichnungstool entwickelt habe, habe ich stattdessen ein JSON-Schema als Format genutzt. Das war nicht geplant, aber JSON hat sich als deutlich LLM-freundlicher erwiesen.

Die großen CAD-Unternehmen werden entwickeln, was ihre Kunden verlangen. CAD- und PLM-Hersteller sind stark, wo KI-Features in ihre bestehende Software integriert werden können und ihre Kunden bereits nach Lösungen fragen – Zeichnungsgenerierung aus dem 3D-Modell oder Stücklistenmanagement und Teilwiederverwendung. Sie haben die Dateiformate, die Daten und die Kundenbeziehungen. Für alles andere – Zeichnungsprüfung und Übergabe an Zulieferer, Agenten, die systemübergreifend arbeiten, Dokumentationstools unabhängig von einem bestimmten CAD – werden kleinere Unternehmen die Lücken füllen.

APIs sind wichtiger denn je. In der gesamten Softwarebranche findet gerade ein grundlegender Wandel statt: Zunehmend interagieren Nutzer mit KI-Agenten, die außerhalb einer einzelnen Anwendung sitzen und über APIs spezialisierte Tools aufrufen. Coding-Agents rufen CLIs, Linter, Test-Runner und Versionskontrollsysteme auf, um Arbeit zu erledigen. Dasselbe Muster werden wir in der Konstruktion sehen. Ein KI-Agent, der an der Erstellung eines Angebots für einen Kunden arbeitet, der eine Anpassung seiner Maschine wünscht, muss möglicherweise ein CAD-System aufrufen, um Geometrie abzufragen, ein PLM-System, um zu prüfen, welche Revision in Produktion ist, ein ERP-System, um Lieferantenlieferzeiten zu erhalten, und eine DFM-Simulation, um die Fertigbarkeit zu validieren – alles in einem Workflow. Engineering-Software, die saubere APIs anbietet, wird Teil dieser Workflows sein. Software, die das nicht tut, wird umgangen.

KI in der Konstruktion steht noch ganz am Anfang. Viele Unternehmen haben ihre Engineering-Tools noch nicht einmal in die Cloud verlagert. Auch bei den Fähigkeiten der Modelle sind wir noch früh: Foundation Models und die darauf aufbauenden Engineering-KI-Tools werden in zwei Jahren deutlich besser sein als heute. Aber die Richtung ist bereits erkennbar: KI wird Teil des Entwicklungsworkflows, nicht als Ersatz für Ingenieure, sondern als Werkzeug, das repetitive Aufgaben übernimmt, enorm breites Wissen mitbringt und Ingenieure dort entlastet, wo es nicht auf Richtungsentscheidungen, Urteilsvermögen und Verantwortung ankommt. Die beeindruckenden Demos haben wir gesehen. Jetzt beginnt der interessante Teil: sie in echte Workflows einzubauen.

Quellen

[1] Text-to-CadQuery: A New Paradigm for CAD Generation
[2] Generating CAD Code with Vision-Language Models for 3D Designs
[3] CAD-Coder: An Open-Source Vision-Language Model for CAD Code Generation
[4] Roman Likhachev’s post on LinkedIn on Claude Code for CAD
[5] Autodesk Fusion: AI Drawing Automation
[6] ClearHandoff: Text to Drawing
[7] ClearHandoff — KI für Zeichnungsprüfungen
[8] Pahl, G. and Beitz, W. (1977). Engineering Design: A Systematic Approach. Springer. — Das Standard-Lehrbuch für Konstruktionslehre.
[9] CoLab AutoReview — KI für Design Reviews
[10] PTC Launches New Windchill AI Parts Rationalization Capabilities
[11] OpenClaw
[12] Zoo — CAD-Plattform mit integriertem KI-Agenten
[13] Synera
[14] bananaz

Andreas Haselsteiner

Andreas Haselsteiner

Maschinenbauingenieur und Gründer von ClearHandoff. Hat Bauteile konstruiert, Technisches Zeichnen an der Universität gelehrt und mit Fertigern zusammengearbeitet. Hat ClearHandoff gegründet, weil er weiß, wie viel zwischen Konstruktion und Fertigung verloren geht.