Last week was busy for me – I attended Autodesk University 2026 in Las Vegas. Before I dive into a summary of what I learned there, I want to discuss the previous week’s big news and my thoughts about OpenAI GPT-6 Astra.
From my perspective, this was a major event for engineering software, demonstrating the progress of frontier AI models and their growing ability to control engineering tools. Looking back at several decades of engineering software, I’ve concluded that every new generation promises to eliminate another layer of manual work.
Let’s examine this evolution in greater depth.
The first wave of 2D CAD replaced the drafting board. Engineers no longer needed to create every line with pencils, rulers, and templates. The drawing remained the primary engineering artifact, but producing, editing, copying, and distributing it became dramatically faster.
The second wave introduced 3D parametric CAD. Instead of automating only the drawing, software began capturing dimensions, constraints, features, relationships, and elements of design intent. Change a parameter and the model, and eventually its drawings, could regenerate. Engineering automation moved from drawing geometry to defining how geometry should behave.
We are now in the third wave: natural language driven CAD and engineering agents. Instead of creating every sketch, feature, constraint, and assembly relationship by hand, an engineer describes an objective and lets an agent operate the tools. The GPT-6 Astra demonstrations in FreeCAD, KiCad, Blender, and SOLIDWORKS make it clear this is no longer theoretical.
Most of the commentary I have read treats this as a question about whether engineers get replaced. I think that is the wrong question, and the history of our own industry tells us why.
Each Wave of Automation Created a New Data Problem, and Each One Produced a New System Category
Here is the pattern I keep coming back to.
2D CAD made drawings cheap. Within a few years, organizations discovered they had thousands of files, no reliable way to know which one was current, and no way to control who changed what. Cheap drawings created a file and revision problem that CAD itself could not solve. The industry built PDM.
3D parametric CAD made geometric change cheap. Change a parameter and the model regenerates. But now a change propagated through assemblies, configurations, variants, and released products in ways nobody could trace by hand. Cheap change created a structure and configuration problem that CAD could not solve. The industry built PLM.
Notice what happens each time. The automation succeeds completely at the thing it targeted. Then the success creates scarcity somewhere else, and the new scarcity requires a different kind of system, built by different companies, on a different data model.
Agents make tool operation cheap. So what becomes scarce?
My answer is decision provenance. When a human engineer spends three weeks modeling an assembly, the reasoning lives in their head, in review meetings, in email threads, and in the marked-up drawings on their desk. It is badly captured, but it exists somewhere. When an agent produces 41 parts in 57 minutes, the reasoning exists nowhere at all unless something captures it deliberately. The artifact arrives without its history.
That is the new data problem. And based on the pattern, it will require a new system category.
The Astra Demonstrations Are Better Than the Skeptics Want to Admit
Dr. Dirk Alexander Molitor brought several of these examples together in a post asking whether OpenAI is moving into territory traditionally controlled by engineering software vendors.
OpenAI’s launch materials show Astra laying out a printed circuit board in KiCad, turning a schematic into a routed board by placing components and routing copper connections, in under three minutes. A written brief becomes a detailed five-speed transmission concept in FreeCAD, and the same design moves into Blender with the gears animated in motion. The same model builds a 3D city scene in Unity and fills out a tax return draft from a W-2.
Separately, Alexandre Senet of MecAgent published a run using Astra inside their own harness against SOLIDWORKS 2026. A single prompt produced 41 parts, 2 subassemblies, and 1 main assembly in 57 minutes. The output is parametric, includes a feature tree, and is fully editable.
These are not toy results. Anyone who has manually routed a board or built a gear train knows what those numbers represent.
The significance is also not really about geometry. It is that a general purpose model can open specialized engineering applications, operate them through the same interface a person uses, inspect what happened, and continue. Historically, software vendors controlled automation through their own APIs, scripting environments, file formats, and partner programs. An agent that can operate a graphical interface does not need permission from that ecosystem. It can work with applications that were never designed for AI at all.
I do not think this means APIs disappear. Computer use is a compatibility mechanism, and a powerful one, especially for older tools. Dependable production processes will still need structured data access, transactions, permissions, error handling, and auditability. But the boundary of engineering software just moved, and it moved without asking any of the incumbents.
The CAD Benchmark Everyone Is Quoting Measures Shape, Not Engineering
Here is the part that almost nobody in our industry has looked at carefully, and it is the most important detail in the entire release.
The headline CAD number is BenchCAD, where Astra scores 95.9% against 83.3% for the previous model. That figure is now circulating across LinkedIn as proof that AI has learned CAD.
Read OpenAI’s own description of what the benchmark does. BenchCAD tests whether models can reconstruct 3D objects from multi-view renders by generating CAD code. The score is geometric overlap.
So the benchmark measures this: given pictures of an object from several angles, can the model produce code that generates a shape closely matching the original?
There is no requirement in that task. No tolerance, no datum scheme, no material, no manufacturing process, no fit, no feature ordering rationale, no revision, no BOM, no supplier, no cost. It is reverse engineering shape from images, scored on how well the shape matches. It is a genuinely hard computer vision and code generation problem, and Astra is very good at it.
It is also, precisely, a measurement of the one layer that was never the hard part of engineering.
The industry’s flagship evidence that AI does CAD is a shape-matching score. When Chris Leigh-Lancaster wrote on LinkedIn that a CAD model can look right and still be wrong, very wrong, he was describing exactly the gap between a geometric overlap score and an engineering result.
The rest of the scorecard makes the point even sharper. Astra reaches 97.6% on FrontierMath Tier 4 and 99.9% on ARC-AGI-3. Abstract reasoning is close to saturated. But AutomationBench, which measures computer workflow tasks across professions, sits at 41.4%. Agents’ Last Exam, which tests complex professional tasks in real software including engineering, sits at 59.3%.
Read those four numbers together and the story writes itself. Mathematics is solved. Geometry reconstruction is nearly solved. Professional work inside real tools is under half.
Geometry is not the bottleneck. It has not been the bottleneck for a long time. We just got a very expensive benchmark confirming it.
Cheap Geometry Makes Everything Downstream More Expensive
The usual reading of automation is that the whole cycle gets faster. I think the opposite happens, at least initially, and this is where engineering differs most sharply from software.
Before agents, geometry creation consumed a large share of the engineering cycle. Review, validation, sourcing, change impact analysis, and approval consumed the rest. Now collapse geometry creation from three weeks to one hour. Nothing else compresses. Review does not get faster because a machine produced the model. If anything, review gets harder, because the reviewer now has to reconstruct intent that was never written down.
The share of the cycle occupied by everything that is not geometry does not shrink. It grows. And the absolute volume grows too, because cheap generation means more candidate designs, more variants, more revisions, more things to check.
Senet was careful to note that the SOLIDWORKS output, while parametric and editable, is not yet perfectly constrained. That single qualification is the whole problem in miniature. An under-constrained model is not a model that is slightly wrong. It is a model whose behavior under change is unknown, which means every downstream decision built on it carries unquantified risk.
A routed PCB may satisfy electrical connectivity while failing thermal, signal integrity, packaging, sourcing, testability, or manufacturing requirements. An assembly can rotate beautifully on screen using incorrect materials, tolerances, fits, bearings, or fasteners. The demo is complete. The engineering has not started.
To participate in an actual engineering process, an agent has to answer a different class of question. Which requirements does this design satisfy, and what assumptions did it make? Are these components approved and available? What is the resulting BOM, and which parts are standard, purchased, or manufactured? What revisions and configurations are affected? What are the cost and lead time consequences? Which existing orders and inventory are affected? Who must review and approve? What evidence supports the recommendation?
None of those questions are about geometry. All of them are about everything the geometry is connected to.
Summaries Are Not Memory, and OpenAI Just Demonstrated It
There is a detail in the Astra release that has nothing to do with CAD and everything to do with this argument.
OpenAI shipped a change to how Codex handles long sessions. Their explanation is that models historically used compaction to summarize work during long sessions, and each compaction can leave out details about why a fix failed or how a component behaves. So Astra can now keep notes across context windows, preserving accumulated details instead of repeatedly compressing them into a single summary, with earlier context remaining searchable.
Read that as an engineering statement rather than a coding one. They found that summarizing loses the reasoning. Not the facts, the reasoning. Why something failed. How a component actually behaves. So they stopped summarizing and started remembering.
This is the distinction I have been arguing, and I want to emphasize this. Context is what an agent has available right now. Memory is what preserved. Context cannot be lost, because it is either present or it is not. Memory can be lost, and in engineering organizations it is lost constantly.
OpenAI solved this inside one agent’s working session. The engineering version of the same problem spans twenty years, six systems, four companies, and several generations of people who no longer work there. That is a different problem, and it is not one a foundation model can solve by holding more tokens.
This is what I call Product Memory: a persistent, connected, explainable, attributed, and recoverable layer of product context that preserves not only what was decided, but why, by whom, under what constraints, and with what alternatives are considered.
CAD tells an agent what the product looks like. The BOM tells it what the product is made of. PLM tells it what was released and how the process was controlled. ERP tells it what was purchased and at what cost. Quality and manufacturing systems tell it what was built, tested, and rejected. Product Memory is the layer that explains why one component replaced another, whether it was cost or availability or a field failure, whether the substitution was approved for every configuration or only one, and whether it required a new drawing, a new test, or a supplier qualification.
Without that layer, an agent can automate an operation without understanding its consequence. That is not a capability gap in the model. It is a missing system.
The Harness Is Where Engineering Knowledge Enters, and It Will Be Built Vertically
Something worth noticing in how these demonstrations were actually produced: the word that keeps appearing is harness.
OpenAI updated the Codex harness to speed up computer use. MecAgent ran Astra through the MecAgent harness to produce the SOLIDWORKS assembly. The benchmark results themselves are reported with harness configurations attached.
The harness is the layer between a general model and a specific domain. It supplies the tools, the sequences, the guardrails, the domain conventions, and the definition of what a good result looks like. The same model produces very different output depending on the harness wrapped around it.
Which raises the question I find most interesting: who builds the engineering harness?
My hypothesis is that it will not come from the foundation model layer. Not because those companies lack the capability, but because the engineering harness has to be built on top of product data that is specific, governed, messy, organizationally owned, and different at every company. That is not a horizontal problem. It is the definition of a vertical one.
This is also exactly how the pattern played out twice before. CAD vendors did not build PDM, at least not first. PDM vendors did not build PLM in its mature form. Each new data problem produced companies that specialized in it, and the incumbents either acquired them or built toward them after the category was already defined.
So I expect the engineering harness, and the Product Memory underneath it, to come from vertical vendors. PLM companies have a structural claim on it because they already hold product structure, change, and release control, even if their architectures make the connected version hard. The pattern says the category arrives after the automation, because the automation is what creates the scarcity. The automation just arrived.
What Is My Conclusion?
The GPT-6 Astra demonstrations are a real milestone, and I do not want to dismiss that. Astra can operate professional engineering software well enough that the boundary of what CAD vendors control has genuinely moved.
A 95.9% score on reconstructing shapes from pictures tells us that geometry generation is close to solved. It tells us nothing about whether a design is manufacturable, sourceable, compliant, or consistent with decisions made three years ago. The numbers that measure actual professional work inside real software are still sitting under 50%.
Each wave of engineering automation has followed the same scenario. It succeeds at what it targeted, creates a new scarcity, and the industry builds a system category to manage what became scarce. Automating massive drawings gave us PDM. Simplifying 3D design together with electronics and software triggered building more sophisticated PLM and digital thread. Cheap tool operation is giving us a decision provenance problem, and I believe the answer to it is a new layer – Product Memory.
AI operating CAD is an impressive milestone. AI understanding the product, and remembering why it became what it is, will be the real engineering transformation.
Just my thoughts…
Best, Oleg
Disclaimer: I am the co-founder and CEO of OpenBOM, a collaborative Product Memory platform connecting engineering and manufacturing teams. My opinion can be unintentionally biased.
