The original idea sounds almost like a holiday project that got slightly out of hand: design a roughly 30-inch humanoid robot to build with kids.
Then AI enters the room.
Amy Sterling says several models spent nearly three days working through the design with more than 150 review passes: an initial specification, independent critiques, corrections sent back to the original model, then another loop.1
The result is not a tiny README containing three STLs and a final line saying “good luck.”
The humanoid-robot repository has become a remarkable pile of specifications, bills of materials, KiCad schematics, STEP models, risk matrices, test procedures, decision registers, collision analyses, review dossiers and traceability files.2
It would be easy to look at that and conclude that agents can now design a humanoid robot.
The repository itself says almost the opposite.
At the top of its README, the status is explicit: concept systems baseline, not approved for fabrication, procurement, or energization.2
That apparent contradiction makes the project much more interesting than the promise of a kid-sized humanoid.
150 reviews do not make a robot
A document can be reviewed 150 times and still contain an assumption nobody has tested against a physical part.
The project has apparently learned this lesson deeply enough to formalize it.
Its evidence-maturity.md file separates design intent from evidence.3 It defines six levels from E0 to E5. E0 means a requirement or hazard has merely been identified. E1 is a documented, internally checked concept. E2 adds primary-source-backed selections or released calculations. E3 requires a bench or component test. E4 requires an integrated subsystem test with fault injection. E5 means a release test has passed and been independently reviewed.3
That scale sounds bureaucratic until you inspect the dashboard.
A huge amount of the project remains at E1.
There are thousands of lines of documentation, 3D models, automated checks, simulations and reviews. Yet the repository repeatedly states that a clean parser, a clean KiCad ERC result, a simulation or a reviewed concept is not physical validation.3
That may be the most important sentence all this AI produced.
The first robot is not even a walking humanoid
The project also changed strategy.
Instead of immediately building the complete small humanoid, the current plan begins with HR-V0, a fixed bench rig with one shoulder axis, one elbow axis and a gripper.2
Its mission is deliberately boring: pick up a foam block weighing no more than 100 grams from a fixed location and transfer it into an instrumented receiver. No walking. No child inside the test area. No voice-triggered motion. No AI-originated direct actuator commands. No learning on hardware.2
The verification plan then climbs through stages: power-off inspection, safety-circuit energization, single-joint characterization, guarded integrated motion, and finally 100 fixture transfers.4
Only later does the program propose an upper body on a pedestal, supported legs, powered stance, tethered walking and eventually untethered walking inside a controlled test area.2
A project that started as “a robot to build with kids” has discovered something wonderfully adult: before building the cute robot, build the boring rig that proves the cute robot will not do something stupid.
AI is extremely good at multiplying questions
It would be unfair to dismiss the 150 passes as documentation theater.
The review ledger records several cases where model reviews found concrete inconsistencies.2
An early electrical review found a package with no real schematic symbols, no real nets and hundreds of ERC violations. Later passes raised problems involving mass allocation, torque, speed, watchdog behavior, restart paths, sensing, restraint and power-loss behavior.2
Successive corrections produced more structured artifacts: connected schematics, executable checks, candidate firmware, CAD models, risk registers and procedures.
AI therefore appears genuinely useful at one job: expanding the surface area of criticism very quickly.
A person designing a small robot alone may forget to ask what happens when the watchdog returns at the wrong time, when real moving mass exceeds the estimate, when an unpowered arm falls, or when separately designed parts leave no room for a cable after assembly.
A group of models can keep asking those questions until the local coffee supply fails.
Asking the question is still not measuring the answer.
The circular-verification trap
The dangerous pattern appears when the same class of system produces the design, produces the critique, fixes the design and then declares the critique resolved.
The project's own ledger tries to distinguish a correction pass from an independent review.2 A clean pass closes only the specific issue and configuration it examined. It does not magically validate the entire robot.
That discipline matters enormously with agents.
Three models can be independent because they run in three separate conversations. They are not necessarily independent in the engineering sense. They may share training data, reasoning habits, incomplete source documents and, most importantly, the same absence of a physical part in front of them.
If a supplier dimension is wrong in the source, ten reviewers can become ten highly consistent witnesses to the same mistake.
Sometimes real independence looks much less impressive: a caliper.
Robotics forces the issue
In software, much of verification can remain inside the same world as production. Code produces code, tests execute code, builds inspect code.
A robot eventually collides with reality.
A motor gets hot. A cable pinches. A fastener loosens. A printed part fails differently depending on orientation. A sensor saturates. An unpowered arm drops faster than expected. A theoretically clean tolerance stack becomes two millimeters of misalignment because three suppliers were each correct in isolation.
HR-V0's verification plan is full of these moments.4
It calls for measuring temperature, current, stopping distance, real mass, play, deformation, contact behavior and injected faults. It explicitly says raw test data should never be overwritten by a rerun.4
At that point the robot becomes an excellent teaching machine, but for a different reason than the original pitch.
It teaches the difference between having an answer and having evidence.
Building with children or showing children a robot?
That distinction arrives at an interesting moment for educational robotics.
In late July, a New York school district paused a roughly $60,000 Realbotix humanoid purchase after concerns from parents, teachers and state education officials.8 The district had planned to use the machine around programming and technology education. The debate quickly expanded into privacy, the robot's classroom role and fears of replacing human relationships with a machine.8
The contrast with a build project is substantial.
In one model, the robot arrives as a finished product that is supposed to teach.
In the other, the robot becomes the thing through which learning happens.
The question changes from “what can the robot explain to a child?” to “what does a child need to understand before this piece of metal can move without breaking something?”
Mechanics, electronics, programming, safety, geometry, materials, documentation and scientific method all meet inside one object.
The robot stops being the teacher. It becomes the problem.
Problems are often excellent teachers.
The idea is old; the scale is changing
Poppy Humanoid, which grew out of Inria research in the early 2010s, already used an open-source 3D-printed humanoid as a research and education platform.9
What is different in 2026 is how much a small team can attempt around this kind of hardware.
Menlo Research now offers Asimov 1 as a DIY kit: 1.2 meters tall, 35 kilograms, more than 25 degrees of freedom, with a $15,000 target price.5 The team says it built and walked its humanoid legs in under 100 days with less than $30,000 in R&D before open-sourcing the work.6
At the other end of the commercial spectrum, 1X is preparing NEO for homes, with US deliveries advertised for 2026 and a $20,000 Early Access ownership option.7
Sterling's project is not comparable to those companies in maturity or resources. It lives inside the same shift, though: available actuators, digital fabrication, simulation, open-source code and generative AI all reduce the cost of attempting a complicated robot.
They do not automatically reduce the cost of making one safe.
AI shortens the path to the prototype, not past the prototype
That is probably the best way to read this repository.
An agent can generate a first BOM in minutes. Another can criticize it. A third can write a checker that keeps references synchronized. Another can generate parametric CAD. Another can turn a discovered mistake into a new verification procedure.
Those are real gains.
They push the work toward the next boundary.
If producing ten bracket variants becomes nearly free, selecting the right one requires more discipline. If generating a hundred pages of specification becomes easy, tracking which sentences were physically verified becomes more important. If a model can suggest twenty hazards in a minute, somebody still has to determine which hazards can actually injure a person.
Abundant design creates scarce validation.
The project's best artifact may be E0 through E5
The idea transfers beyond robotics.
An agent says a migration is safe: perhaps E1. The migration succeeds against a production copy: something closer to component evidence. A complete restore is tested. The procedure is independently replayed. Confidence climbs through evidence rather than prose.
A model generates a part: intent.
A simulation passes: digital evidence.
The CNC part matches the drawing: physical evidence.
The assembly survives its real load: system evidence.
This vocabulary prevents a very human, and increasingly agentic, mistake: confusing the amount of visible work with the amount of certainty obtained.
The humanoid-robot repository contains an almost comic quantity of visible work.
Its strongest quality is that it keeps saying this is not enough.
What about the kids?
For now, they should stay away from the energized rig. The project says so explicitly.2
That is less photogenic than the original tweet. It may also be much better education.
Building something with children does not mean putting an Allen key in their hand next to a high-torque actuator. It can mean showing why the project begins with a foam block, why measurement comes before claims, why an emergency stop should not depend on a Linux process, why simulation is not a test, and why you do not start walking before understanding what happens when power disappears.
AI can make design accessible earlier.
Reality still gets the final review.
For an educational project, that may be exactly the lesson worth building.