Anthropic put Claude to work training a robot dog

What happens when you lock eight software engineers in a warehouse, hand them quadruped robot dogs, and ask them to play fetch?

Anthropic just ran a fascinating internal uplift test called Project Fetch to see how much Claude helps people bridge the gap between pure code and the messy physical world. They took eight Anthropic researchers and engineers—none of whom were robotics specialists—and split them into two teams of four. One team had Claude. The other had to build everything by hand.

Rogue robodogs and messy hardware

The teams were tasked with programming their robodogs to fetch beach balls across three escalating stages. Stage one was just driving the dog with an off-the-shelf gamepad. Stage two forced them to ditch the controller, establish a direct laptop connection, read video and lidar feeds, and drive the robot with custom code. Stage three was fully autonomous target detection and retrieval.

Things went sideways almost immediately. While Team Claude-less was stuck trying to establish a basic connection, Team Claude quickly spun up code with the AI and took their dog for a spin.

Then came a very human math mistake. Team Claude told the robot to charge forward at one meter per second for five seconds, forgetting that the other team was sitting less than five meters away. The mechanical beast barreled straight at the rival table, forcing an organizer to tackle the dog and kill the power before anyone lost a shinline.

High velocity vs deep understanding

When the dust settled, the AI uplift was undeniable. Across every task both groups finished, Team Claude got it done in roughly half the time. By the end of the day, only Team Claude made serious progress on the autonomous stage: their dog could spot the ball, walk over to it, and nudge it around, though it was not quite nimble enough to actually haul it back.

Claude’s biggest advantage was surprisingly mundane: hardware integration. Robotics documentation is notoriously buggy, and Team Claude-less fell down internet rabbit holes and gave up on viable setup paths, needing hints from organizers just to pull lidar data late in the day. Claude guided its team through the noise effortlessly.

Yet Claude also introduced new failure modes. Team Claude wrote substantially more code, but a lot of it was pure thrash. Because generating code was frictionless, members chased multiple parallel solutions instead of debugging what was already there. When a coordinate system was inverted, rather than fixing the flip, they ditched it for a completely different approach that went nowhere.

Both teams joked afterward that if tested on the underlying robotics library, the AI-less team would probably score higher because they were forced to deeply understand every broken line.

Why it matters

This trial offers an unvarnished preview of how frontier models interact with physical machines. For developers, the real unlock right now is not magical physical reasoning, but blasting through the miserable boilerplate of hardware protocols and contradictory APIs. An engineer with zero robotics background can get unfamiliar sensors streaming in an afternoon with an AI sidekick.

However, we think the runaway robodog incident is a serious cautionary tale. In pure software, a sloppy five-second loop throws an error in your terminal; in the physical world, it sends metal paws crashing into your coworkers. The margin for sloppy arithmetic shrinks dramatically once code has mass and velocity.

There is also a clear capability trade-off brewing. Team Claude delivered a slicker video streaming UI and moved twice as fast, but they understood the stack far less. If frontier models become the primary abstraction layer for real-world robotics, we risk creating an entire generation of engineers who can deploy complex autonomous machines at breakneck speed, yet lack the fundamental comprehension to diagnose them when they go rogue.