An AI-generated CAD feature can pass every internal demo and still fail at the factory because the model has not seen the constraints that govern how the part will be made. The safest test is to involve the manufacturer before the team treats a clean render, valid geometry, or successful simulation as production evidence.
At 4:17 on Friday afternoon, Kojo was holding his laptop open beside a half-finished coffee in a small workshop outside Accra. He had spent the week demonstrating a custom CAD feature that generated a mounting bracket from four inputs. Every run looked right. The geometry rebuilt without errors, the assembly accepted it, and the part survived the load assumptions his team had entered.
Then Mensah, the manufacturing lead, rotated the model and pointed at the inside corner.
“The tool cannot reach that face.”
Kojo first thought the issue required a minor dimension change. It did not. The feature had created a cavity that looked ordinary on screen but could not be cut using the planned process without another setup, different equipment, or a redesign.
A pilot assembly was due the following week. If the bracket changed, two connected parts might also change. If it stayed, the manufacturer could decline the job or quote a process the pilot budget could not carry.
The feature had worked until Friday because Friday was the first time someone tested it against production.
The model knew geometry, not the manufacturing decision
Kojo’s mistake began earlier than the generated bracket.
He had framed the task as a geometry problem: take four dimensions, preserve the mounting points, and generate a valid part. The AI-assisted feature did exactly that. It produced a model the CAD system could rebuild and the team could inspect.
The manufacturing constraint lived outside that definition.
Tool access, setup choices, stock dimensions, tolerances, fastening order, and available equipment shape whether a part can leave the screen. A CAD model can be internally consistent while asking a workshop to perform an impractical operation.
This matters as more product teams use AI to create custom CAD features. Recent work such as PTC adding AI-powered FeatureScript capability to Onshape makes it easier for engineers to describe and generate specialised design behaviour. That can shorten the distance between an idea and a working feature. It also shortens the distance between an incomplete assumption and dozens of confidently generated parts.
Kojo had automated a decision before he had mapped everyone who carried its consequences.
A successful demo answered the wrong question
Each demonstration asked, “Can the feature generate the bracket we described?”
The production question was different: “Can this manufacturer make the generated bracket using the process, equipment, cost range, and assembly sequence we expect?”
Those questions overlap, but one cannot stand in for the other.
This is a pattern I recognise from software products. A checkout can work in the environment where the team built it, then fail when a buyer in another market uses a different payment path. That was the central issue in the failed Accra checkout Daniel had to investigate. The interface performed correctly inside the team’s definition of the transaction. Reality carried another definition.
CAD raises the cost of discovering that gap late. A software team may patch a validation rule after release. A physical product team may already have ordered material, booked machine time, or designed adjacent parts around the output.
Kojo’s green checks had become a substitute for evidence. Valid geometry proved that the feature could create a model. It said nothing about whether the chosen factory could produce it within the pilot’s limits.
The constraint became part of the feature
With the pilot at risk, Kojo stopped trying to rescue the existing output. He asked Mensah to describe the failure as a rule.
They worked backwards from the unreachable face. Which direction did the tool need to approach from? What clearance did it require? Which shapes would force another setup? At what point should the feature refuse to generate a part instead of returning geometry that looked complete?
The answer was partly code and partly process.
The team added a check for the known access condition and made the feature flag outputs that required manufacturing review. They also changed the approval sequence. A generated part could pass the CAD review and still remain unapproved for production until the manufacturer had examined the relevant surfaces and process assumptions.
This was less satisfying than declaring the feature fixed. Some constraints could be encoded. Others depended on the workshop, material, quantity, or equipment selected for that run. Kojo had to leave part of the decision with a person.
That boundary improved the product. The feature stopped pretending every valid model was ready to make.
Test the handoff before scaling the output
On Monday morning, Kojo generated the bracket again. The revised feature rejected the old cavity and identified the access condition. Mensah reviewed the new version before Kojo updated the connected parts.
The pilot still had little room. At least the team now knew where the uncertainty lived.
Before using AI to generate more designs, take one representative output to the person responsible for making, assembling, buying, or maintaining it. Ask them to mark the first point where the design becomes expensive, awkward, unsafe, or impossible. Convert repeatable objections into rules. Keep variable judgments visible as human approval gates.
The most dangerous AI feature may be the one that produces plausible work faster than the team can test its assumptions.
Kojo closed the Friday demo with a bracket on screen. He started Monday with something more useful: a feature that knew when to stop.
Comments
No comments yet.