AI Can Write Code, But It Still Cannot Design a Machine: The Missing Knowledge That Could Change That

Artificial intelligence has quietly transformed how software is made. By company accounts, AI now writes as much as 30 percent of the code at Microsoft and more than a quarter at Google, and industry observers expect that by 2030 large software engineering teams will give way to smaller, AI-augmented ones. Yet the machines that software runs on—the cranes, vessels, turbines, and industrial systems that keep the physical world moving—remain designed almost exactly as they were decades ago. A new hypothesis-and-theory article published in Frontiers in Mechanical Engineering argues that this is not simply because physical design is harder. It is because the knowledge that conceives and sizes a physical machine was never written down in a form AI could learn from, and the engineers who hold that knowledge are now leaving the field.

The article’s author, Daniel Hagen of the Department of Engineering Sciences at the University of Agder in Norway, spent more than ten years as a systems engineer in offshore oil and gas before earning a doctorate in mechatronics. His argument begins with an asymmetry that has received surprisingly little attention. Software’s design reasoning was, to an unusual degree, already recorded: decades of public code came with documentation, code reviews, and discussion threads, forming a substantial corpus that AI models could learn to design from. Physical-systems design has no comparable record. The reasoning that resolves how a structure is sized to a duty, how hydraulic actuation is weighed against electro-mechanics, and how sensing, control, and software are specified alongside the hardware is held tacitly by experienced engineers and rarely written down anywhere.

Physical design is genuinely harder in one sense: its errors are costly and often irreversible, where software can be tested and revised cheaply. That forgiving test loop is one reason software came first. But Hagen insists it is not the whole explanation. The recorded-reasoning advantage, he argues, is what allowed AI’s reasoning and agent layers to gain a foothold in software at all. As the design bottleneck shifts toward physical systems—just as the engineers who hold the integrative design knowledge are retiring—the capture of that knowledge becomes what he calls a binding constraint on AI-assisted physical design, and the most neglected of the constraints that bind it.

To ground the claim, Hagen examined how the field of mechatronics—the engineering of machines that integrate mechanical, electronic, control, and software components—actually uses the word intelligent. He classified twelve of the field’s defining sources, from the founding editorial of the joint IEEE/ASME Transactions on Mechatronics to the French standard NF E 01-010, the VDI 2206 guideline, textbooks, journal scope statements, and recent AI reviews. The pattern was uniform. Of the twelve sources, four use the term in neither their product nor their process definitions. Of the remaining eight, seven place the intelligence they invoke in the product or its control—intelligent sensing, intelligent control, intelligent runtime adaptation—and the eighth attaches it to the discipline itself. None places it in the design process. Intelligence, in current practice, resides in the machine, not in the making of the machine.

This intelligence bias matters because the design knowledge at risk is not the kind existing AI research addresses. A bibliometric review identified 126 publications on AI-enabled tacit knowledge spanning 1985 to 2025, but that body of work centers on operational knowledge—best practices for running, maintaining, and troubleshooting existing systems. A recent review of large-language-model tacit-knowledge elicitation covers elicitation from operators on the shop floor and excludes product design from its scope altogether. The knowledge of how to conceive, size, and validate a new machine from requirements to a manufacturable design—the cross-domain reasoning that exceeds what any individual design engineer typically holds—has been almost entirely absent from the AI research agenda.

The demographic evidence makes the situation urgent. Despite decades of better tools, new-product-development success rates remain largely unchanged, while an aging, shrinking engineering workforce is documented across the United States, Japan, and Germany. In Norway, where Hagen works, STEM fields account for only 16 percent of bachelor’s graduates against an OECD average of 23 percent, and 72 percent of firms report unmet engineering and technical competence—the highest share of any field. Manufacturing is approximately 6 percent of GDP against an EU average near 14 percent. Meanwhile, demand for new machines has not gone away: DNV forecasts demand for ocean space to grow nine-fold by mid-century, 82 percent of it for offshore wind, including roughly 45,000 square kilometers of floating wind farms. Energy-transition infrastructure and autonomous marine systems are new machines, not life-extended ones, and they need exactly the cross-domain design capability that is thinning.

The article proposes a three-layer model to locate the missing element. Layer 1 is engineering design knowledge in a form that AI can use: design rules, physics-informed constraints, trade-off heuristics, and the ability to translate application needs into formal specifications accounting for environmental conditions, regulatory standards, and cross-domain interactions. Layer 2 is general AI reasoning, now widely available through large language models. Layer 3 is agent infrastructure—platforms that let agents plan, execute, and iterate. The layering orders dependency: agents invoke general reasoning, and both must be grounded in domain knowledge. Nothing above functions for design without the layer below. Software had a partial Layer 1 in its commit histories and code reviews; physical-systems design has no comparably forgiving substrate.

To make the argument concrete, Hagen reconstructed the reasoning behind a real actuation decision for an offshore crane built for autonomous load handling, a case from his own doctoral work and industry practice. Using the question-options-criteria method, a design-rationale formalism, he traced how choosing among actuator topologies—a valve-controlled cylinder, a self-contained electro-hydraulic cylinder, or an electro-mechanical cylinder—fixes the mechanics, electrics, control architecture, and software at once. The electro-mechanical option provides high drive stiffness, so a standard cascade controller suffices; the self-contained electro-hydraulic option has low natural damping, so the design then needs an added position transducer, pressure sensors, and active-damping firmware to reach the motion performance that autonomous operation demands. The hardware choice is a software choice. No single-domain format holds the reasoning that resolves it. Some of the knowledge behind the gradings is codified—buckling sizing to a safety factor of four under DNV classification rules, cylinder dimensions to ISO, continuous power above roughly 2 kilowatts. Some is contextual: no off-the-shelf electro-mechanical actuator certified for potentially explosive atmospheres could be found in his feasibility study, so a design that meets performance requirements may still fail to comply. And some is experiential: that reliability outweighs efficiency because offshore downtime is expensive. A STEP file holds the chosen cylinder’s geometry, and a simulation model holds its dynamics, but neither holds why a stiff electro-mechanical drive is wrong for a shock-loaded, certification-constrained offshore duty, nor how that one choice propagates into the sensor suite, the control software, and the intelligent twin.

The article sets out a four-question research agenda. First, how can tacit design knowledge be captured? Hagen judges AI-assisted co-design the most promising route, where the agent observes the engineer’s choices and asks about them as they are made, adding no separate documentation burden. Evidence from interface design shows that an assistant asking lightweight questions in situ and inferring missing rationales raised the share of decisions with strong recorded explanations from 14 percent to 83 percent without adding measured cognitive load. Second, how can design knowledge be represented for AI agents? Candidate formalisms include constraint hierarchies encoding hard physical limits and soft preferences, causal graphs tracing how requirement changes propagate, and case-based libraries indexing past solutions by context. Third, how can human-AI co-design be validated? The article proposes blinded component-level evaluations where an agent proposes a topology for a new duty and generates the intelligent twin from the same captured source, judged by a blinded panel on justified fitness rather than agreement with the original expert choice. Fourth, does the concept generalize beyond mechatronics to civil, structural, renewable-energy, and naval engineering?

The hypothesis is stated as falsifiable. If general-purpose AI agents, supplied with no captured design knowledge, were shown to take a safety-critical, cross-domain physical system from requirements to a validated, manufacturable design—with an inspectable design justification and a safety case that holds for the operating environment—the claim that captured design knowledge is a binding constraint would not hold. Public corpora, retrieval, and simulation are all permitted in the test; what is excluded is any new elicitation of rationale from practicing or former engineers. The current frontier illustrates the distance: a pipeline that turns a text prompt into a walking quadruped within a day does so for toy-scale robots within a fixed single-domain morphology, with no safety case. What is at stake, Hagen concludes, is capability rather than efficiency: whether a field with fewer engineers can still design new machines rather than only maintain the ones it has. The machines of the future will be intelligent. The question is whether the engineering that creates them will be intelligent too.

Subject of Research: AI, Engineering, Mechatronics, Design Knowledge

Article Title: Intelligent Mechatronics: intelligence in the design process, not only the machine

Article References: Hagen, D. (2026). Intelligent Mechatronics: intelligence in the design process, not only the machine. Frontiers in Mechanical Engineering, 12, Article 1968837. https://doi.org/10.3389/fmech.2026.1968837

Image Credits: AI Generated

DOI: 10.3389/fmech.2026.1968837

Keywords: AI, mechatronics, design rationale, tacit knowledge, intelligent engineering, physical design, engineering workforce, Intelligent, intelligence, design, process, only