OpenAI announced research with Mazda on November 3, 2026, involving aerodynamics and crash-safety engineers exploring AI-assisted vehicle-design simulations. For manufacturers and hardware startups, it raises a practical question: which design tasks are useful to delegate, and which checks must remain with engineers?
The practical lesson for manufacturers is to separate AI-assisted design from expert review before manufacturing. A useful pilot should produce something an engineer can inspect against agreed requirements—not just an impressive-looking object.
A fast prototype still needed manufacturing review
In the same report, OpenAI says two employees used Astra to design a Codex voice-device prototype in under a week; a manufacturer made a small batch in under a month. Production constraints, permitted dimensional variation—known as tolerances—and assembly requirements still needed repeated review and revision.
OpenAI also describes trials with Chip Ganassi Racing that turn scans into editable computer-aided design (CAD) models and drawings, with engineers checking their suitability for manufacture. These accounts do not establish independently audited savings or improved vehicle safety.
The distinction between a convincing shape and a usable design also appears in an October 17 research preprint by Qiang Zou and colleagues. Its case study of GPT-6 Astra reports useful CAD results alongside errors in geometry, relationships between adjustable dimensions and how parts fit together. Repeated AI-led refinement did not consistently remove critical errors. That finding describes the study’s cases, not an error rate for every engineering task.
What a design score leaves out
OpenAI reports a higher BenchCAD 2.0 score for an unnamed internal model than for Astra. But BenchCAD’s authors explain that the score measures agreement with reference designs across geometry, part placement and circuit connections. It does not assess manufacturability or physical performance. A high average is not the percentage of products ready to build.
Comparisons also need matching evaluation conditions. The BenchCAD 2.1 release notes warn that its scores cannot be compared with 2.0 or 2.1-beta. Before using benchmark gains in a purchasing decision, ask which test version and settings were used. That caveat does not show that OpenAI’s comparison is invalid.
For simulations, running the software successfully is only part of the job. NIST’s established guidance on airflow and other fluid simulations identifies the quality of the physical model, analyst expertise, verification, validation and assessment of uncertainty as necessary ingredients for credibility. It is not an AI-specific certification. Applied here, the implication is that an engineer must assess whether the assumptions and results represent the intended physical problem.
Choose a task you can check
A sensible first pilot would be a bounded drawing-preparation or candidate-model task, with known inputs and a named reviewer. This is a proposed evaluation approach, not a promise that a particular CAD package or model will deliver savings. Three decisions would make the result more informative:
Define acceptance before generation. Specify the dimensions, materials, tolerances and assembly requirements the output must meet. Keep those criteria separate from the AI’s explanation of why its answer is good.
Choose a reviewable handoff. Require an editable design and the inputs needed to examine it, rather than treating a rendered image as the deliverable. Retain engineering approval before any manufacturing step.
Count the whole job. Record preparation, AI operation, expert checking and corrections through to an accepted deliverable. A quick first draft is useful only if it does not shift more work into later stages.
Defining success before seeing a recommendation also helps preserve reviewer independence, a related issue explored in RohitAI’s analysis of human review of AI-assisted work. That article concerns analytical decisions, not manufacturing performance.
For a pilot, an illustrative accounting rule is: net labor hours saved = baseline hours for an accepted deliverable − total preparation, operation, review and rework hours in the AI-assisted workflow. This assumes comparable tasks, the same acceptance standard and complete time records. Track software charges and discarded-prototype costs separately; the equation alone establishes no saving.
Software access is not research participation
OpenAI’s Computer Use documentation describes desktop-app operation on macOS and Windows in supported regions, through ChatGPT Work or Codex with the Computer Use plugin and required permissions. That is a general interface capability, not a guarantee that a team’s engineering software will work reliably with it.
The linked research-collaboration form is more selective: it invites a small number of software companies with a concrete task that agents struggle to complete, clear success criteria, domain experts and a secure test environment. It tells applicants not to submit confidential or proprietary information. Applying does not guarantee participation, and the form gives no collaboration price or start date.
As of November 3, general Business pricing is US$20 per user per month with annual billing and at least two users, or US$25 with monthly billing. Those subscription figures are not a quote for an engineering project or research collaboration. The announcement does not establish public access to the unnamed internal model.
Before committing to a pilot, confirm the model and software integration actually available to the team, applicable data-handling arrangements and who will approve the result. Then judge the pilot by accepted engineering work and total effort—not by how quickly the first design appears.