AI in Physical Engineering: From Code Generation to Collaborative Hardware Prototyping

For much of the past several years, the value of AI in software engineering has centered on code completion, test generation, defect localization, document summarization, and log analysis. As multimodal understanding, tool use, and structured output capabilities improve, AI is beginning to enter heavier engineering workflows—from software interactions on a screen to the structural design, electronic design, prototyping, and manufacturing coordination of physical products.

This shift does not mean that models are replacing engineers. Instead, AI can bring forward and automate large portions of work involving candidate generation, cross-document retrieval, constraint checking, and review preparation. Human engineers still make the decisions at critical approval gates.

1. From Software to Hardware: Expanding the Boundary of Engineering Intelligence

Physical engineering differs from software engineering in several important ways. Its constraints are more complex, verification is more expensive, and the cost of errors is higher. A software defect can often be fixed through rapid iteration. Hardware problems may involve dimensional tolerances, material properties, thermal design, electrical safety, electromagnetic compatibility, manufacturability, and supplier lead times.

For this reason, AI in hardware engineering cannot focus only on generating results quickly. Its outputs must also be inspectable, traceable, and reviewable.

From a workflow perspective, AI can support four major areas:

1. Requirements clarification: Convert natural-language requirements into a functional matrix, constraint list, acceptance criteria, and risk register.
2. Concept design: Generate interaction sketches, structural layout options, interface assumptions, draft electrical relationships, and an initial bill of materials.
3. Verification preparation: Assist with simulation conditions, design-for-manufacturing checklists, assembly sequences, and test plans.
4. Prototype feedback loops: Consolidate build issues, classify failure modes, generate change recommendations, and track regression verification.

The real value comes from connecting these stages into a closed loop, rather than asking a model to independently “draw a picture” or “write a description.”

2. Case Study: Rapid Prototyping of a Voice-Interactive Desktop Device

Publicly available information describes a representative internal hardware experiment. The team wanted to design a desktop voice-interaction device that would allow users to communicate with an intelligent coding assistant without opening a computer. The device included a display and physical buttons, with a virtual character shown on the screen. After pressing a button, a user could ask a question by voice, and the device would respond verbally.

In a demonstration, a user asked how many intelligent agents were currently running. The device provided the number and proactively asked whether the user wanted it to read them out one by one. The team completed an initial design in less than a week, after which a contract manufacturer produced a prototype.

The important point is not simply that the prototype was developed quickly. It is how engineering information was organized.

First, the interaction goal was clearly defined: voice input, physical-button activation, screen feedback, and character-based presentation. Second, the constraints were relatively contained. Factors such as desktop form factor, power supply, button lifetime, voice latency, and manufacturability could be described in a structured way. Third, the team could treat requirements, sketches, 3D assemblies, electrical connection tables, bills of materials, and test plans as a set of structured artifacts. The model could generate candidates from these artifacts, while engineers conducted a focused review.

The shorter development cycle was likely the result of several factors, including component reuse, clearly defined constraints, faster candidate generation, concentrated human review, and access to prototyping resources. It should not be attributed to the capability of a single model alone.

A representative task-orchestration pseudocode example is shown below:

task = {
  "goal": "Design an initial desktop voice-interaction device",
  "constraints": ["dimensions", "power supply", "button lifetime", "voice latency", "manufacturability"],
  "artifacts": ["interaction sketch", "3D assembly", "electrical connection table", "bill of materials", "test plan"],
  "review_gates": ["structural interference", "electrical safety", "thermal design", "privacy", "maintainability"]
}
for stage in ["requirements clarification", "concept design", "multimodal review", "simulation and verification", "prototype fabrication"]:
    candidates = model.generate(stage, task, context)
    reviewed = human_review(candidates, checklist)
    task = update(task, reviewed)
    log_version(task, reviewed)

This pseudocode illustrates three principles:

• Model outputs should be structured.
• Each stage should include a human review gate.
• Every change should be recorded with version information.

For hardware engineering, traceability is as important as generation speed.

3. Evaluating Engineering Capability: Understanding 3D Models and Circuit Relationships

To determine whether a model can genuinely support engineering collaboration, organizations need to assess whether it can understand 3D components, assemblies, and circuit-board relationships.

Publicly disclosed engineering benchmarks have focused on two categories of tasks:

• Reconstructing 3D components and assemblies
• Identifying circuit-board connection relationships

The first category involves geometric topology, assembly constraints, ambiguous views, and dimensional inference. The second involves net connectivity, component names, pin relationships, drawing noise, and consistency across documents.

In the disclosed test results, an internal model achieved an average score of 0.875, while a high-reasoning configuration of another model achieved 0.594. This comparison indicates that, under that particular engineering task set and scoring system, the internal model performed better on average.

However, average scores should not be treated as equivalent to real-world engineering capability. Evaluation should also consider dataset coverage, scoring criteria, reasoning configuration, failure modes, and whether a model received task-specific optimization.

Organizations should pay close attention to error types. For example:

• Did geometric reconstruction introduce dimensional drift?
• Did assembly constraints conflict?
• Were circuit connections missed?
• Could the model’s explanation be independently reviewed?

Companies should build small, high-value internal evaluation sets covering dimensions such as geometric fidelity, constraint consistency, connection accuracy, manufacturability, explainability, and traceability. Results should be separated by task type rather than reduced to a single overall score.

For safety-critical or high-cost prototyping work, model outputs should be treated only as candidates. They must pass rule-based checks, simulation validation, and formal engineer approval.

4. Organizational Signals: How Rising Usage Changes Collaboration

Public information also indicates that model usage within one hardware team increased by approximately 23 times from the beginning of the year. Increased usage is a signal of adoption, but it does not necessarily mean that output or productivity improved.

Organizations need a broader measurement system. Relevant metrics may include:

• Whether design cycles have become shorter
• Whether the number of review issues has declined
• Whether rework rates have decreased
• Whether fewer prototype iterations are required
• Whether knowledge reuse has improved
• Whether defect escape remains under control

Roles and responsibilities should also be explicit:

• Engineering leaders define task boundaries and acceptance criteria.
• Data administrators maintain drawings, models, bills of materials, and change records.
• Model reviewers check output consistency and explainability.
• Security and compliance teams manage privacy, intellectual property, and supply-chain data.

The workflow should form a closed loop:

Requirements → Data → Candidates → Review → Simulation → Prototyping → Retrospective

Every failed attempt should be preserved as a future evaluation example.

5. Industry Opportunities: Automotive and Racing Engineering

In automotive manufacturing and racing engineering, common opportunities for AI include:

• Generating multiple design options
• Searching across engineering documents
• Checking bill-of-materials consistency
• Assisting with harness and connection verification
• Supporting fault-tree analysis
• Summarizing test reports
• Analyzing the impact of engineering changes

Racing engineering emphasizes rapid iteration, lightweight design, and reliability. The automotive industry places greater emphasis on regulations, functional safety, and supply-chain coordination. Both environments require model outputs to be absorbed into established engineering systems rather than remaining at the demonstration stage.

The limitations are equally clear. Materials and process knowledge require enterprise-specific data. Safety-critical components cannot be released automatically. Supplier information may be confidential. Models may also produce designs that appear reasonable but cannot actually be manufactured.

AI is therefore better suited to serve as a candidate generator and checking assistant than as the final party responsible for engineering decisions.

6. Implementation: Building a Traceable Human-AI Workflow

Organizations should begin with high-value, lower-risk tasks, such as:

• Generating requirements matrices
• Preparing review checklists
• Checking bill-of-materials consistency
• Summarizing test reports

At the data layer, organizations should create unified indexes for drawings, 3D models, bills of materials, change records, and test reports. Access control, version management, and data redaction should be handled as part of the foundation.

For engineering data and computing infrastructure, general capabilities such as object storage, container platforms, logging, and monitoring from Baidu AI Cloud can be used to build a traceable data pipeline.

At the model layer, systems should support multimodal understanding, tool use, and structured output. They should also connect to rule checkers and simulation interfaces.

The workflow must retain human approval gates. Any safety-critical change should require confirmation from a qualified engineer.

7. Risk and Governance: Turning “Can Generate” into “Can Be Verified”

The main risks include:

• Errors in dimensions and tolerances
• Incorrect assumptions about materials and manufacturing processes
• Missed electrical-safety issues
• Privacy and intellectual-property leakage
• Excessive trust in model output
• Model-version drift

Recommended governance measures include:

• Tiered review processes
• Prohibiting automatic release of safety-critical components
• Retaining complete logs
• Conducting red-team testing
• Enforcing least-privilege access
• Redacting sensitive data
• Establishing confidentiality agreements with suppliers

The allocation of responsibility must remain clear: the model provides candidates and explanations, while engineers remain responsible for the final design.

8. Conclusion and Recommendations

AI entering physical engineering represents the expansion of engineering intelligence from code space into a world governed by physical constraints.

Its value does not lie in the narrative of “fully automated design.” Instead, it lies in shortening the loop between candidate generation and engineering review, while turning cross-document and cross-disciplinary information management into structured, inspectable artifacts.

For developers, the priorities should be structured outputs, rule-based checks, evaluation datasets, and version traceability. For enterprises, the recommended sequence is to govern data, define approval gates, measure outcomes, and then gradually expand the scope of tasks.

Only when generative capabilities are integrated into a verifiable engineering process can AI deliver stable value in physical product design and manufacturing.