
A developer under the nickname SpeedyBrowser45 presented the result of three months of work on MechFaber – a desktop application that transfers AI agents from the programming environment to a full cycle of designing physical devices. In a demonstration scenario, Claude Code created the design of a quadruped robot, including 99 complex parts and 12 actuators, prepared the firmware, and then launched it in a simulation. The system forms not only the geometry of the device but also the power scheme, electronic connections, list of components, energy consumption parameters, and estimated battery life. The project included a battery assembly, microcontrollers, separate motors for joints, cooling, and lidar. For wiring, the AI also calculates the cross-sections and lengths of cables, and the final diagram shows the connections between buses, actuators, and sensors.
The architecture of MechFaber is not built on a single universal model attempting to perform all operations simultaneously. The developer distributed the work among several specialized agents: one handles research and calculations, another is responsible for CAD modeling, and separate components of the system work with electronics, firmware, and simulation. According to the author, this approach provides more stable results than attempting to assign the entire process to one agent. At the same time, the system is prohibited from independently guessing the sizes of parts: it receives the necessary dimensions directly from the CAD core, takes component characteristics from technical documentation, and performs engineering calculations using built-in modeling tools, including the finite element method. In the demonstration project, Raspberry Pi 5 was chosen for lidar data processing, and the Teensy microcontroller is responsible for controlling the actuators. This allows the integration of mechanical design, electronics selection, and software development into a single sequence.
The robot's testing also takes place in a digital environment. The firmware operates in a closed loop with a physics engine that simulates the movement of the structure and allows evaluating its behavior under different conditions. A flat surface is provided for basic testing, but the developer can create additional tests using simple text requests. For example, the system can add a ramp, a narrow passage, or a set of obstacles to the scene, after which the same version of the firmware is run in the new environment. This approach allows testing the program logic before manufacturing physical parts and identifying issues at the simulation stage. However, the project has not yet passed the main practical test: the real prototype of the robot has not been assembled. Therefore, it remains unknown how accurately the digital model conveys the behavior of the actual structure, including mechanical tolerances, material properties, vibrations, friction, and other factors that are difficult to fully reproduce in a virtual environment.





