Coding Agents Just Beat Hand-Built Robot Planners
98,000 evaluation episodes. That is how much testing sits behind a quiet paper that should bother anyone who spent a career hand-engineering robot planners. Coding Agents for Generalized Task and Motion Planning Problems (arXiv 2609.30233) asks whether Claude Code and Codex can replace the specialized engineering that generalized TAMP usually needs. The answer is yes, and not narrowly.
The setup is clean. Each agent gets a task description and simulator access, a fixed synthesis budget, and has to write a program. Then the program is frozen and run on 100 unseen instances, with more objects than the original benchmarks ever used. Three configurations were tested: Claude Code on Opus 5, Codex on GPT-5.6 Sol, and Codex on GPT-6 Astra. 28 environments from KinDER and PDDLStream, 980 generated programs.
On the 16 environments where a hand-engineered planner exists, the agents hit 56 to 95 percent mean success against 47 percent for the planners. They also beat one-shot generation and an LLM-based generalized planning baseline. As object counts grow, the agent-written programs hold their success rate better than the planner and use roughly an order of magnitude less compute per instance.
The logs are the interesting part. The agents use the simulator the way a good engineer would: they poke it to calibrate physical models, test edge cases, and revise their strategy before committing. That is the difference between one-shot code generation and an agent. Give it an environment to interact with and a budget, and it builds its own understanding before writing the thing that ships.
The broader point is the one to take away. The expensive part of robotics has never been the robot, it is the months of problem-specific engineering between a task and a working plan. If a general coding agent with a simulator and a budget clears that bar on most environments, the planner becomes something you generate, not something you build. All code and the full agent prompts are released, which makes this easy to check.
← Back to all articles
The setup is clean. Each agent gets a task description and simulator access, a fixed synthesis budget, and has to write a program. Then the program is frozen and run on 100 unseen instances, with more objects than the original benchmarks ever used. Three configurations were tested: Claude Code on Opus 5, Codex on GPT-5.6 Sol, and Codex on GPT-6 Astra. 28 environments from KinDER and PDDLStream, 980 generated programs.
On the 16 environments where a hand-engineered planner exists, the agents hit 56 to 95 percent mean success against 47 percent for the planners. They also beat one-shot generation and an LLM-based generalized planning baseline. As object counts grow, the agent-written programs hold their success rate better than the planner and use roughly an order of magnitude less compute per instance.
The logs are the interesting part. The agents use the simulator the way a good engineer would: they poke it to calibrate physical models, test edge cases, and revise their strategy before committing. That is the difference between one-shot code generation and an agent. Give it an environment to interact with and a budget, and it builds its own understanding before writing the thing that ships.
The broader point is the one to take away. The expensive part of robotics has never been the robot, it is the months of problem-specific engineering between a task and a working plan. If a general coding agent with a simulator and a budget clears that bar on most environments, the planner becomes something you generate, not something you build. All code and the full agent prompts are released, which makes this easy to check.
Comments