Blake Courter

Geometry as Code

Includes contributions from Luke Church, Dan Rubel, Keegan McNamara, and the extended Gradient Control team.

Executive summary

  • Traditional “geometry as data” challenges AI and ML engineering applications because the model needs to anticipate the behavior of quirky geometry kernels.
  • Geometry as code replaces the kernel with programmatic functions that encode geometric behavior and are much more amenable to AI and ML tools.
  • Gradient Control Laboratories announces Omega, the world’s first and only geometry as code development system for engineering applications.

Background

Almost three years ago, Jeremy Herrman introduced me to the founders of Cursor, who eventually made what we now know as a wildly popular AI-powered IDE. In those days, however, they were attempting to create a “GitHub CoPilot for CAD” by training their tech on feature-based CAD models from OnShape and GrabCAD. They wanted to know why their models weren’t converging. Why weren’t there enough patterns in the CAD models’ construction to predict the next feature?

Within six months of starting my career at PTC three decades ago, I became aware that there was little engineering in CAD. I had joined PTC because I thought that by selling Pro/E, I’d survey the engineering disciplines and learn how engineers design. Instead, I learned what drafters do: create technical drawings that get passed downstream for manufacturing and archival. The actual engineering knowledge, the why behind the design, was nowhere to be found. Where did it live?

Thirty years later, we’re still searching for this mystical “design intent.” Our most sophisticated 3D models are still just collections of lines and curves with no understanding of their purpose. They’re documentation tools, not intelligent systems. Meanwhile, engineering knowledge remains inaccessible in Matlab and Python scripts, FEA decks no longer run in the latest codes, and the real knowledge is spread over a diaspora of Office documents. Perhaps it even haunts the tombs of PLM.

The team at Cursor reapplied their LLM tech to IDEs and built one of the most successful startups in recent memory. If we could represent geometry as code, could we perhaps achieve a Cursor for CAD?

At Gradient Control Laboratories, we are building Omega: a new suite of modeling tools for CAD that manipulate geometry as code. With Omega, engineering knowledge becomes portable, reusable, and understandable by AI. CAD models become free and open software that places equity with creators, just as IDEs do for software developers.

Read more

Joining Spectulative Technologies' Brains Accelerator

Speculative technologies

As Gradient Control Laboratories has become fully consumed with projects, we’ve started to consider how we might broaden our impact. With the future of engineering software in mind, we’ve joined the Speculative Technologies “Brains” accelerator program for feedback on some of our more ambitious thoughts.

Speculative Technologies Newsletter: Meet the 2025 Brains Fellows

Am thrilled to become part of such an inspiring peer group and mentor team.

Read more

Agentic Engineering: how AI automata will participate in engineering in 2025

At Gradient Control Laboratories (GCL), we have the privilege of seeing patterns emerging among the most innovative engineering software startups. Last year, we tracked the rise of differentiable engineering as the first differentiable CAD and CAE APIs appeared. Now, as we wire AI agents into PLM and BIM architectures, we’re ready to share our expectations for 2025 and beyond.

This post originated from conversations with Luke Church, GCL and Brad Rothenberg, nTop. It now includes significant contributions and feedback from: Mark Burhop, Sciath aiM (from whom we anticipate a nuanced paper on this topic); Jacomo Corbo, PhysicsX; Kiegan Lenihan, xNilio; Peter Harman, Infinitive; Saigopal Nelaturi, C-Infinity; Hugo Nordell, Encube; Alex Huckstepp, Uptool; Neel Goldy Kumar, Intact Solutions; Blake Reeves, Pasteur Labs; Andy Fine, Fine Physics; Kyle Bernhardt, Collectiv; and Claude 3.5 Sonnet.

Executive Summary

The future of AI in engineering won’t arrive as a single superintelligent design system. Instead, 2025 will see the rise of specialized AI agents that work alongside engineers throughout the product lifecycle — simulating assemblies, automating documentation, optimizing components, and configuring supply chains. These agents, operating both within existing tools and through new platforms, represent a fundamental shift in how we develop products, one that promises to dramatically accelerate and enhance the engineering process. Success will require solving key technical challenges around security and agent coordination. GCL is convening industry leaders this spring to tackle these challenges together.

Vision

The engineering industry’s vision for AI-powered design tools seems to mirror science fiction, from Star Trek’s Holodeck to Tony Stark’s workshop. The narrative follows three steps:

  1. An engineer declares intent, describing a design objective, its constraints, and performance goals;
  2. The computer synthesizes a complete design proposal, from geometry to materials to manufacturing; and
  3. Through rapid iteration and feedback, the engineer and AI converge on an optimal solution.

Star Trek Scene

The crew of the Enterprise collaborates with The Computer to reconstruct a medical table in the Holodeck. Although this episode of TNG jumped the shark, this scene influenced me greatly.

Read more

Differentiable Engineering

Executive summary

  • By including differentiable, parametric models in engineering processes, engineering software can better interoperate between human and artificial designers.
  • Existing CAD, CAM, and CAE tools can speak this language by adding differential interoperability to their APIs.
  • We provide a visual introduction to differential engineering using a cantilevered beam.
  • By examining the derivative of a rotation, we briefly unlock some deep math beauty and an application of Unit Gradient Fields (UGFs).
  • Differentiable engineering scales to product-level systems engineering.

✏️ Math advisory: this post assumes you’re okay with derivatives, the chain rule from basic calculus, and a little vector math. We will introduce intuitive visual tools to illustrate such concepts in design engineering. While I feel compelled to show the work, you can probably skim and glean the concepts from the illustrations.

👥 Lots of credit: These ideas came from discussions with many people, including:

Introduction

Today, we practice three paradigms of computer-aided design (“CAD”), manufacturing (“CAM”), and engineering (“CAE”):

  • One-off design, where the focus is producing individual parts or products;
  • Parametric generative design, where the result is recipe to produce variants of similar parts or products; and
  • Computational generative design, where the final geometry is guided by simulation, often iteratively and with spatially-varying parameters.

As each of these generations has built on earlier technology, the emerging generation of engineering software powered by artificial intelligence and machine learning algorithms (“AI/ML”) is being trained on existing empirical, simulated, and textbook knowledge. However, while this new generation of tools promises ease-of-use, more accurate results, and orders of magnitude faster performance, it does not yet offer a meaningful shift in interaction paradigm. As these new tools become increasingly sophisticated, will new interaction paradigms emerge? Will we realize the sci-fi vision of product-level generative co-designers?

Let’s examine how AI and ML can blend with today’s optimization tech to expand engineers’ navigable design space. As generative design scales to the subsystem and product level, we’ll demonstrate how to delegate tasks to AI and ML without the meaning becoming hidden in a nonintuitive latent spaces, as with LLMs and generative art. We’ll focus on the role of a designer, human or automated, expressed in the language of optimization and machine learning: a differentiable approach to design engineering.

Abstracting the design engineer

Let’s propose a model for a design engineer, human or automated, which we’ll call “Mechanical Design Automation (MDA)”:

Read more