OpenAI and Mazda Explore AI-Powered Engineering Design: From CAD Drawing to Actual Manufacturing—What Steps Are Still Missing?

There is a long way to go between having AI generate a beautiful product image and having a factory manufacture a product from those drawings that can be assembled and used. On November 3, 2026, OpenAI announced progress in its physical engineering research and revealed a research partnership with Mazda to expand its exploration into aerodynamics and crash safety design. This raises a more practical question: Now that AI has entered the engineering field, which tasks should it actually take on—and where should it draw the line?

The focus of this progress report is on the engineering process.

OpenAI has disclosed that its work involves CAD, manufacturing drawings, and simulation. Its collaboration with Chip Ganassi Racing includes converting scanned part data into editable models, while its partnership with Mazda focuses on vehicle design and simulation evaluation. Engineers from the partner companies still need to review the output.

Officials also acknowledged that an internal hardware prototype underwent multiple rounds of review prior to entering production, but the model did not always fully account for manufacturing constraints, tolerances, and assembly details. Therefore, this announcement should be understood as progress in engineering support capabilities and research collaboration, and should not be directly equated with the AI’s ability to independently deliver mass-production designs.Official Announcement from OpenAI

A model that can be opened does not necessarily mean a design that is ready for delivery.

To understand these types of tools, we can divide project delivery into three levels.

The first level is correct representation. Are the units of measurement correct? Are the sketch constraints complete? Are there any obvious interferences between parts? These issues can be partially checked using rules, scripts, and engineering software, making them suitable for inclusion in automated workflows.

The second layer involves correct conditions. Even for the same shape, the conclusions may be entirely different depending on the material, load, manufacturing method, or operating environment. The model must know which dimensions are variable, which interfaces must remain fixed, and what acceptance criteria the design must meet. Simply entering “make it a little lighter” makes it difficult to hold the results accountable for engineering responsibilities.

The third layer is delivery accuracy. Can the procurement team source parts that meet the specified requirements? Does the factory have the necessary processing capabilities? Can the assembly tools reach the required areas? Can the inspection plan detect critical defects? This information is scattered across the process engineering, procurement, quality assurance, and after-sales service departments. Even if AI generates the correct geometric shapes, it may not have access to the complete set of constraints.

From this perspective, the first thing a company typically needs to organize is the project input: clearly defined versions of drawings, material requirements, manufacturing specifications, and acceptance criteria. When document versions are inconsistent, faster production may actually cause errors to spread more quickly.

Repetitive tasks with clearly defined boundaries are better suited for trying out first.

For small manufacturing teams, a prudent pilot project could start with drawing checklists, organizing information on standard parts, design change specifications, or modeling assistance for non-critical parts. The clearer the scope of the task, the easier it is to compare the differences between manual and AI-driven processes.

For example, the AI is instructed to list the affected drawings, materials, and inspection items based on approved change orders, citing the source and version for each determination. Engineers review this information before implementing the changes. Tasks like this do not require the AI to make decisions regarding structural safety from the outset, yet they can still reduce the time spent searching for information and cross-checking details.

If the pilot test involves CAD modifications, it should be run on a copy or a controlled branch, and the differences between the original and modified versions should be saved; directly overwriting the official version is prohibited. When running the simulation, also check the material parameters, boundary conditions, and mesh settings. A successful solver run merely indicates that the calculation process has completed; it does not replace an assessment of the modeling assumptions.

Cost estimates should include the costs of reviews and rework.

When evaluating engineering AI, it’s not enough to simply record how many minutes it took to generate a single model. What’s more meaningful is the total time from when a task is assigned to when an engineer signs off on it, as well as how many additional checks and reworks were required during the process.

Select a set of representative tasks and record the first-pass success rate, manual revision time, version tracking completeness, and final delivery time. High-risk tasks should be tracked separately to ensure that critical errors are not masked by the average performance of a large number of simple tasks. Core tasks should also be revalidated whenever there are changes to the model, prompts, or engineering software versions.

This will shift the focus of tool procurement. While a polished demo is certainly appealing, the ability to integrate with existing document management systems, maintain a change history, restrict write access, and allow engineers to easily review documents is typically more closely aligned with day-to-day practical value.

Engineers' judgment should remain at the heart of the process.

Our assessment is that, in the near term, the area worth investing in is enabling AI to expand the number of options engineers can compare while reducing routine organizational and operational tasks. For conclusions involving safety, reliability, and manufacturing commitments, there must still be clearly designated human responsible parties and corresponding verification processes.

The research by OpenAI and Mazda is worth noting, but the more important points to watch for will emerge later: which tasks can be consistently replicated, how to handle conflicting constraints, how much engineers need to modify the code, and whether the improvements can be reflected throughout the entire development cycle. Only as these questions are gradually answered will the ability to “design” move closer to the ability to “deliver.”