This article was written and contributed to Engineering.com by Maor Farid, co-founder and CEO of Leo AI. All opinions are his own.
In October 1950, Alan Turing, considered the founding father of computer science, posed a question he had no intention of answering: Can machines think? In his paper, “Computing Machinery and Intelligence,” he approached this question not using a numerical or quantitative threshold but with an experience, with a game: put a person on one end of a teleprinter and a machine on the other, and if the person cannot reliably tell which is which, the philosophical argument has been settled by other means. The Turing test was born—a human litmus test for classifying another entity as intelligent.
Today, 76 years later, we still have no good quantitative measure of intelligence—neither artificial nor human (my Ph.D. supervisor used to say that intelligence is like pornography; no one can define it, but when you see it, you know). But AI is progressing all the same. In software engineering, we see AI tools building full software products, websites, and videos from a single prompt. Usually, we cannot distinguish if it was created by a human or a set of AI agents—it passes our Turing test.
As a mechanical engineer myself, inspired by Turing and the AI revolution in software engineering, I have spent the last three years building Leo AI and asking what the equivalent moment looks like for physical products. Today, I believe AI can finally build physical products in a way indistinguishable from humans.
The mechanical Turing test has been passed.
How do we evaluate the mechanical Turing test?
Without a rigorous mathematical definition of the Turing test, we are left with subjective human experience as the evaluation tool. But subjective experience can still be measured in aggregate. Since opening Leo to general access we have surveyed and interviewed hundreds of mechanical engineers using it in production, watching for one specific signal: the point at which they report they can no longer tell whether an assembly was built by a human engineer or an AI. In July, positive responses on that measure rose 791 percent. That is when we concluded the test had been passed.
Below is a video of a typical user workflow.
I start with a prompt: “Design me a coaxial contra-rotating propeller drive for a marine environment.” Like a human engineer, Leo asks leading questions to make sure it has understood the task. It then pulls the governing equations only from high-fidelity sources, since knowing how to rank a source by accuracy is itself part of knowing the domain.
From there Leo solves the equations, derives the relevant dimensions, pulls parts from my own inventory and from trusted vendor catalogs, generates the remaining geometry, and returns a DFM-compliant, manufacturing-ready assembly that reflects both my organization’s accumulated practice and my industry’s standards.
As a mechanical engineer, when I walk through the finished design, I cannot tell whether a human or Leo built it. That is the mechanical Turing test, and I think Leo passes it.
Defining the mechanical Turing test
Now, let’s break down this experience rigorously.
Generating a 3D model from a text prompt is not the test. That has been possible in some form for a while, and the output is usually a mesh, which is to a manufacturable part roughly what a screenshot of code is to a codebase. If we are going to borrow Turing’s structure, the bar has to be the experience of working with the system, not the artifact it hands back.
Here is the version I would put forward, drawn from about 900 interviews my team conducted with practicing mechanical engineers in the United States before we wrote a line of product code.
The input is functional, not geometric. You state what the thing has to do and the conditions it has to do it under. You do not describe the shape you already have in your head.
It asks the right questions when you are vague. Ask for a coaxial contra-rotating propeller drive for a marine environment and any competent engineer stops you immediately: what transmission configuration, bevel or epicyclic? If the system does not push back on an underspecified brief, it is not reasoning, it is guessing politely.
It reasons from sources it can name. The governing equations come from the handbooks and standards our profession has spent two centuries writing down, plus whatever internal guidelines your organization has accumulated. The calculation is shown. The sources are cited. An engineer can audit the chain from requirement to dimension.
It sources parts the way an experienced engineer sources parts. Reuse first, catalog second, design last. We do not manufacture our own ball bearings. If a 50 mm bore bearing already appears in three shipping products, that is the bearing to pick. This is the least glamorous criterion and probably the most diagnostic, because it is where domain judgment lives.
The output survives review. Native solid geometry with a feature tree, editable, with material properties attached, opening in the CAD system your team already uses. If a reviewer cannot tell whether a colleague or a machine built it, that is Turing’s condition, restated for our discipline.
We released a major update to Leo’s assembly generation capability on July 1. Usage of that capability grew close to tenfold over the following weeks, which is a signal I actually trust, because it means engineers are choosing to route real work through it rather than being impressed by a demo.
The inspection side of the same coin is further along and less discussed. One customer of ours, a large oil and gas operator in Texas, releases on the order of 200,000 new parts a year and has to audit them twice annually against API standards. That sweep used to consume dozens of people for months. It now runs across the model library in hours, with the long tail of legacy geometry taking a day or two. Nobody had to pass a Turing test to make that useful. It just had to be right.
Passing the test does not transfer the responsibility
This is where I part company with the more excitable version of this story.
Strip the AI out of the picture for a moment. Imagine that behind the system there is simply Joe, a brilliant engineer down the hall. You ask Joe what alloy to use for a structural fitting and he says 316 stainless. You think it should be 6061 aluminum. You can argue with Joe from now until March, but you are the one who signs the drawing, and the responsibility is yours and stays yours. That is not a limitation of the tool. That is the profession.
The legal question, which came up constantly two years ago, has largely been settled. The terms of service across the major model providers, and our own contracts, are unambiguous: what you design with these tools is yours. The harder question is cultural. Mechanical engineers work under a premise software engineers mostly do not share: if we are wrong, someone can die. Not only in aerospace. A chair fails and a child falls. We are not artists rendering shapes in three dimensions. We are decision makers, and the value of a very fast, very well read collaborator is that it gives us more time to decide well, not permission to stop deciding.
Can you point one of these systems at 200,000 parts and tell it to fix everything without looking? Technically, yes. I would ask you not to.
The part that should keep you up at night, in a good way
What has been passed is a test on sub-assemblies and mechanisms. Gearboxes. Drives. Fixtures. Brackets and housings that carry real load. Nobody is handing over a complete aircraft, and anyone who tells you otherwise is selling something.
But look at the shape of the curve rather than the point on it. Software crossed from function-level assistance to product-level agency in about four years. Physical design starts that same climb with an advantage software did not have, which is a body of codified engineering knowledge going back centuries, and a disadvantage software did not have, which is that our artifacts have to survive contact with the physical world.
Assume the climb takes twice as long. That still puts a Class II medical device, a satellite bus, an unmanned ground platform inside the working lifetime of every engineer reading this. The interesting implications are not about headcount. They are about what becomes the bottleneck when design stops being one. Certification and physical test are already the long pole on most serious programs. Compress the design loop by an order of magnitude and you do not get products ten times faster, you get a discipline reorganized around validation, standards bodies asked to move at a speed they have never moved at, and a generation of engineers whose skill is judgment rather than execution.
To me, the most interesting part of Turing’s test was never the machine. It was the position it puts us in once we can no longer tell the difference. Our profession is about to find out what that feels like.
About the author
Dr. Maor Farid holds a BSc, MSc and PhD in mechanical engineering and served as a mechanical engineer and later as an AI researcher in Unit 8200 of the Israel Defense Forces. He was a Fulbright postdoctoral researcher at MIT working on applications of machine learning to mechanical systems, and was the top ranked lecturer in the Technion’s Faculty of Mechanical Engineering. He is a graduate of Harvard Business School’s executive program and a Forbes 30 Under 30 honoree. He is co-founder and CEO of Leo AI.
The post Opinion: AI has passed the mechanical Turing test appeared first on Engineering.com.