ChatGPT for Mechanical Engineers: A Practical Playbook

On September 3, OpenAI released GPT-6 Astra, its newest frontier model. For mechanical engineers, the important change isn’t simply another jump in benchmark scores. It’s that ChatGPT can increasingly carry technical tasks across files, datasets, code, research, and software instead of stopping at an answer in a chat window.

Astra can use computers, analyze technical files and datasets, conduct multi-source research, write and run code, and carry out longer sequences of actions across software. OpenAI also reported a 95.9% score on a benchmark for reconstructing 3D objects by generating CAD code, up from 83.3% for GPT-5.6 Sol.

That makes a wider range of engineering applications more credible. An AI system can take test results through analysis and visualization, inspect a drawing alongside supporting documentation, research components across several manufacturer sources, or perform bounded tasks inside technical software. Less of the engineer’s time has to go toward moving information between systems and re-explaining context just to make the AI useful.

But that doesn’t remove the fundamental engineering challenge. Artificial intelligence can generate geometry without knowing whether it satisfies your requirements, or recommend a component without knowing a failure mode on the previous program. And if AI lets teams produce more CAD and other outputs in less time, it can also increase the amount of outputs that still have to be reviewed for approval.

So as large language models become more capable, we are left with some important questions. What information are they reasoning from? What have my colleagues already learned about the problem I’m working on? Who determines whether the result is technically sound? And how does a useful finding become part of an actual engineering decision?

Astra is a bold step forward, but it doesn’t take us all the way toward a better engineering workflow. And that’s where the next phase of engineering AI gets really interesting.

What is GPT-6 Astra, and what actually changed? ^{What is GPT-6 Astra?}

GPT-6 Astra is OpenAI’s most capable model for complex reasoning, coding, research, computer use, and other longer-running tasks. The model also has a context window of roughly 1.05 million tokens, which allows it to consider much larger collections of source material during an analysis.

For an engineer, though, the headline is less about context-window size than about what the model can do with the information in front of it.

ChatGPT has been able to analyze uploaded documents and spreadsheets for some time. Its current data-analysis tools can run Python-based calculations, transform datasets, perform statistical analysis, and create tables and charts from uploaded files. That means an engineer can provide several test runs and ask the system to calculate margins, compare conditions, investigate an anomaly, or create plots without relying on a language model to perform the arithmetic in prose.

Astra pushes further into software use. OpenAI reports a score of 72.6% on OSWorld 2.0, a benchmark for carrying out tasks on a computer, compared with 65.7% for GPT-5.6 Sol, while completing the evaluated tasks in substantially less time. In one of its launch demonstrations, Astra lays out a printed circuit board in KiCad by placing components and routing connections from an electronic schematic.

PCB layout is not mechanical engineering, but the example is relevant because of what the model is doing. It is operating technical software and producing an engineering artifact rather than explaining the sequence of clicks another person should make.

That distinction opens the door to a much broader class of applications. An AI system that can reason about technical information and act inside software could eventually take on more of the repetitive activity around simulation, data processing, document preparation, model interrogation and analysis, and CAD. The engineer moves from asking for instructions toward assigning a bounded technical task and inspecting what comes back.

That is a meaningful change.

‍

How close is Astra to doing CAD? ^{How close is Astra to doing CAD?}

The Astra announcement is particularly interesting for mechanical engineers because of its result on BenchCAD.

BenchCAD is a 2026 benchmark designed to test industrial CAD reasoning. Its dataset contains 17,900 executable CadQuery programs spanning 106 industrial part families, including gears, springs, drills, and other recognizable mechanical components. The benchmark tests several abilities, including understanding rendered geometry, reasoning about CAD code, reconstructing a model from rendered views, and editing CAD code from instructions.

OpenAI reports a 95.9% geometric-overlap score for Astra on the image-to-CAD portion of the benchmark when tools are available. GPT-5.6 Sol scored 83.3% in OpenAI’s comparison.

That is a substantial result. It is not the same as saying Astra is “95.9% accurate at mechanical design.”

The distinction matters because BenchCAD is testing whether the generated program can reproduce the target geometry. The researchers found that frontier models could often recover the coarse outer shape of a part while still struggling with the parametric construction underneath it. Fine geometric details went missing, engineering parameters were misunderstood, and operations such as sweeps, lofts, and twist extrusions were sometimes replaced with simpler constructions that approximated the appearance of the final part. Performance also dropped on unfamiliar part families.

A mechanical engineer sees the problem immediately. Two models can look almost identical in a rendered view while behaving very differently when the design changes.

The feature tree may not preserve design intent. A hole pattern may be dimensioned from the wrong reference. A geometrically correct wall thickness may be unsuitable for the molding process. A change that satisfies the literal instruction may interfere with another part, invalidate an earlier test result, or violate a company-specific design rule that was never supplied to the model.

For that reason, Astra’s BenchCAD performance is best understood as evidence that AI is getting much better at creating and manipulating engineering geometry. It is not evidence that the surrounding mechanical-design problem has disappeared.

If you want to go deeper on that distinction, our article on agentic CAD looks specifically at where autonomous CAD is useful today and where design intent, manufacturability, requirements, and engineering judgment still limit the technology.

‍

What can mechanical engineers use ChatGPT for now? ^{What can mechanical engineers use ChatGPT for now?}

Even before autonomous CAD is mature enough for broad production use, ChatGPT has become useful across a much wider range of engineering activity than the writing and brainstorming applications that dominated the conversation a few years ago.

Technical research is one obvious example. An engineer investigating a bearing, seal, polymer, coating, manufacturing process, or failure mechanism can use ChatGPT to collect information across several sources, compare published values, identify conflicting recommendations, and narrow the questions that require deeper investigation.

Data analysis has also become a more credible application. With code execution available, ChatGPT can manipulate test data, generate plots, compare experimental runs, apply equations across a dataset, or help troubleshoot an analysis script. The engineer still has to establish that the source data, method, assumptions, and acceptance criteria are appropriate, but there is less reason to spend time manually formatting every intermediate step.

The same applies to technical documentation. Specifications, test reports, supplier responses, requirements, and other documents can be compared or interrogated directly rather than summarized manually before the model can use them.

And then there is the growing middle ground between analysis and software operation. Astra’s computer-use capabilities suggest that AI will increasingly be able to carry a technical task across several applications rather than stopping whenever a person needs to click something.

For a broader view of the software landscape, our guide to the best AI tools for mechanical engineers covers engineering knowledge, generative design, simulation, design review, PLM, and other categories where more specialized tools may make sense.

‍

Do mechanical engineers still need to learn prompt engineering? ^{Do mechanical engineers still need to learn prompt engineering?}

Yes, although probably not in the way that term was used a few years ago.

The original version of this guide recommended giving ChatGPT three things: context, a deliverable, and a defined scope. That advice has held up reasonably well. What has aged is the emphasis on elaborate personas, “expert panels,” or carefully engineered sequences intended to coax the model into better reasoning.

Modern models are better at following natural instructions, and engineers can increasingly provide the source material itself rather than paraphrasing everything into the prompt.

Suppose you are preparing a drawing for review. A useful request might say:

Review the attached drawing against the supplied requirements and identify items that deserve closer inspection. Separate issues supported by the supplied information from questions that require additional context. Do not assume design intent where it is not documented, and identify the source behind each concern where possible.

What makes that request useful is not a prompting trick. The model has the drawing, knows which requirements should govern the analysis, understands what you want back, and has been told not to fill gaps with plausible engineering-sounding guesses.

The same principle applies to calculations, revision comparisons, technical research, and other engineering tasks. If the information that determines the answer is not available to the model, better wording probably will not make up for it.

That becomes increasingly important as the questions get closer to a real product decision.

Better AI does not remove the engineering review problem ^{Engineering review problem}

Engineering organizations have spent decades improving the tools used to create and analyze products. CAD became more capable, simulation became more powerful, and PLM and PDM systems became better at controlling product information.

Yet many engineering teams still rely on a comparatively small group of experienced people to review designs and make difficult technical decisions.

There is a good reason for that. Only part of what makes an experienced engineer valuable is contained in a handbook or requirements database.

A senior manufacturing engineer may have seen the same machining problem across several programs. A subject matter expert may remember why a particular tolerance was tightened years ago. A supplier-quality engineer may know that a nominally acceptable process has produced inconsistent results at a particular source. Those lessons shape engineering decisions even when they were never turned into a formal standard.

This problem predates generative AI. Astra makes it more consequential.

If engineers can produce CAD, requirements, analyses, specifications, test summaries, and other technical material more quickly, the amount of information requiring evaluation can increase as well. Faster generation does not automatically create faster product development if the same experienced engineers still have to review every consequential output before the program can move forward.

Put differently, AI can move the constraint.

An organization may save hours producing the first version of a drawing only to add another item to a queue waiting for a chief engineer or subject matter expert. It may generate three credible design alternatives in the time it previously took to create one, but somebody still has to evaluate the tradeoffs among all three.

That is why our view of engineering AI is closely tied to engineering design review. If AI helps accelerate creation but does little to improve how engineering knowledge is applied during review, the decision backlog can become more difficult rather than less.

The opportunity is to use AI on both sides of the equation.

‍

Company context matters long before the final decision ^{Context matters}

Consider a straightforward question: What gasket should we use here?

ChatGPT can research elastomer compatibility, temperature limits, pressure ranges, compression behavior, and manufacturer specifications. With the right information in the prompt or attached files, it can produce a thoughtful comparison.

A real component selection may also depend on the current groove geometry, a company material standard, an approved-parts list, a preferred supplier, previous test results, cleaning requirements, an earlier field failure, or a decision made on another program.

That does not make public engineering knowledge unimportant. It means that public knowledge is only one part of the information an engineer brings to the decision.

The same pattern appears almost everywhere.

A stress equation may be standard, while the applicable load case and allowable are specific to the program. A tolerance may look reasonable until the engineer considers the rest of the stack-up. A manufacturing recommendation may be valid in general but incompatible with a supplier’s actual process capability. A model change may look harmless until somebody remembers that the previous geometry was introduced to solve a test failure two revisions ago.

Some of this knowledge is explicit: requirements, standards, drawings, calculations, specifications, test records, bills of material, approved components, supplier capability matrices.

Some accumulates through engineering itself: review comments, design rationale, accepted exceptions, manufacturing feedback, lessons learned, and the experience of people who have watched similar decisions play out before.

Our AI Office Hours article on engineering data readiness gets into this problem in more detail. An engineering team does not need perfectly organized data before it can use AI, but it does need to understand which sources are authoritative for the use case in question and how those sources reach the model.

For leaders making that decision at an organizational level, our guide to building an engineering AI strategy looks at how validation, source information, subject matter expertise, and measurable outcomes should shape the choice of AI use case.

‍

Where ChatGPT starts to become an awkward center for engineering

Astra can consider far more information than earlier models, and general-purpose AI systems can increasingly connect to enterprise sources. So the argument for dedicated engineering AI cannot simply be that ChatGPT only knows what is on the public internet.

The problem is subtler.

Engineering information has relationships that affect whether it is relevant.

A drawing belongs to a revision. A test result belongs to a configuration. Feedback may refer to a specific feature on a specific version of a model. A standard has scope. A supplier limitation may apply to one manufacturing process, plant, or material combination and not another. A previous decision becomes much more useful when the engineer can see what design was under review, what concern was raised, how the team resolved it, and why.

For an occasional question, an engineer can assemble that context manually. Find the drawing, attach the requirement, locate the right standard, add the previous test result, explain the history, and start the conversation.

As that pattern becomes routine, the engineer starts spending a surprising amount of time preparing the AI to be useful.

They also remain responsible for what happens after the answer appears. If the analysis identifies a real design concern, somebody has to capture it against the design, determine who owns it, update the relevant model or drawing, review the new revision, and confirm that the issue is actually closed.

A chat transcript is useful information. It is not, by itself, a design-review process.

‍

Why CoLab is approaching engineering AI differently

CoLab is built around the iterations that happen between the first design created in CAD and the controlled product definition that ultimately lives in PDM or PLM.

That is the part of product development where engineers inspect models and drawings, involve subject matter experts, raise concerns, discuss tradeoffs, incorporate supplier input, resolve issues, and decide whether a design is ready to move forward.

Our design review platform was built to keep those conversations attached to the technical data rather than scattered across slide decks, spreadsheets, screenshots, emails, and meetings.

The activity produces something else as a byproduct: a record of how the organization makes engineering decisions.

When an experienced machinist explains why a feature is difficult to manufacture, or a senior engineer documents why an exception is acceptable, that information can remain connected to the design where the decision occurred. Over time, review history starts to capture some of the implicit engineering knowledge that has traditionally lived in people's heads alongside the explicit knowledge already contained in standards, guidelines, requirements, and other technical sources.

That matters for AI because a more capable model can do much more when it has access to the information the organization actually uses to make decisions.

CoLab’s strategy is therefore not to bolt a chatbot onto CAD and call the problem solved. Design review provides the human decision process. The engineering knowledge accumulated through those reviews provides context. Operator and AutoReview apply AI on top of that foundation.

That is a much closer match for the complexity of real mechanical engineering.

Where Operator fits

Operator is CoLab’s AI interface for engineering data and AI agents.

It can search across information in CoLab, including feedback, reviews, standards and guidelines, workspaces, and file information, while also analyzing technical files and generating content. Where an answer draws on existing material, engineers can follow the source back to the underlying information rather than treating the generated response as a new system of record.

The difference becomes clearer if we return to component selection.

With ChatGPT, an engineer can assemble the drawing, manufacturer specifications, internal standard, approved component information, and any previous test results they believe matter. Astra may be very good at reasoning across all of it.

Operator is designed around a different starting point. The design, review history, company knowledge, and technical information already present in CoLab can become part of the investigation without requiring the engineer to reconstruct that package in a separate conversation every time.

That is useful for questions such as whether the team has encountered a similar problem before, why a previous design decision was made, which internal guideline applies to the current drawing, or what earlier review feedback may be relevant to the design now in front of the engineer.

These are not theoretical examples. Engineers are already using Operator for component selection, drawing analysis, searching previous design feedback, preparing Design Failure Mode and Effects Analysis (DFMEA) material, and developing inspection plans. Our Solutions Engineering team walks through those applications in 5 use cases of Operator for mechanical engineers.

Just as importantly, useful analysis does not have to end in the conversation. Operator sits in the same environment where engineers are already reviewing the design and resolving technical feedback.

‍

Where AutoReview fits

Not every review question needs to begin with an engineer asking an AI system what to look for.

Some checks are repeatable by design.

A drawing team may want every release candidate checked for missing information, conflicting dimensions and tolerances, GD&T problems, material or BOM inconsistencies, and deviations from company standards. A 3D model may need recurring manufacturability checks for wall thickness, draft, internal radii, rib geometry, tool access, or other process-specific concerns.

AutoReview is CoLab’s AI peer checker for those situations. It analyzes drawings and CAD, applies relevant standards, guidelines, checklists, and review patterns, and adds potential issues directly to the technical data for engineers to evaluate.

That last part matters. The output is not simply a list of observations in another window. Potential issues can enter the same review process where people inspect the design, discuss the concern, assign responsibility, make a change, and verify the next revision.

For 2D use cases, CoLab’s AI drawing review software is designed around drawing-specific checks and company review criteria. For 3D models, AI CAD review applies specialized analysis to native engineering geometry and manufacturability concerns.

Operator and AutoReview therefore cover different modes of engineering AI. Operator is flexible and driven by the question an engineer is trying to answer. AutoReview applies repeatable checks proactively as part of the review process.

Neither replaces engineering judgment. They are intended to make more of the information needed for that judgment available before an experienced reviewer has to start from scratch.
‍

So should mechanical engineers use ChatGPT or CoLab?

For many engineering organizations, the answer is both.

ChatGPT is becoming an exceptionally capable general-purpose technical tool. Astra strengthens the case for using it for research, coding, test-data analysis, document-heavy tasks, early exploration, and increasingly some bounded CAD activity. It would be a mistake to dismiss that progress simply because general-purpose AI is not an engineering system.

The closer a task gets to a consequential product decision, however, the surrounding environment begins to matter more.

Mechanical engineering decisions draw on revision-controlled product data, company standards, requirements, supplier capabilities, previous failures, test history, review feedback, and the accumulated judgment of experienced engineers. The resulting concerns then need to be discussed, resolved, and recorded against the design.

That is why we think dedicated engineering AI becomes the better fit as teams move from individual experimentation toward repeatable engineering processes.

ChatGPT gives an engineer a remarkably capable general-purpose model.

CoLab combines AI with the design-review process and the engineering knowledge produced through it. Operator gives engineers a way to interrogate that information and pursue open-ended questions. AutoReview applies specialized checks repeatedly before the human review begins.

Astra makes that combination more relevant, not less. As AI becomes better at generating and manipulating engineering information, engineering organizations will need equally capable ways to review what it produces and apply what their teams already know.

Guardrails for mechanical engineers using ChatGPT

One sentence from the original version of this guide remains worth preserving: AI is a tool, not a sign-off authority.

The specific validation required depends on what you asked the model to do. For a consequential calculation, inspect the equations, inputs, constants, boundary conditions, assumptions, and units. For a research task, check the underlying technical sources and whether they apply to your operating conditions. For drawing or CAD analysis, establish that the model is using the correct revision and the requirements or standards that actually govern the design.

Be explicit about units as well. The original guide used a deliberately simple example: “Stress of 200” is dangerous. “Stress of 200 MPa” is clear. The same discipline applies to temperatures, tolerances, loads, coordinate systems, material conditions, and safety factors.

Finally, follow your organization's policy for proprietary information and AI tools. CAD, supplier information, pricing, product requirements, unreleased designs, test results, and customer data may all carry restrictions that affect where they can be analyzed.

‍