Self Evolving Coding Agents: From Digital Programs to Physical World Intelligence

Masonry The weird part is they’re not selling a smarter action policy first. They’re basically saying the action policy is the wrong place to hide the important stuff, which, okay, that is annoyingly plausible.

Eyre Yeah, because once you cram task state, progress, constraints, and recovery into action chunks, you can’t inspect any of it. A tiny viewpoint shift or layout change blows up the whole thing, and the model has no clean place to say, "wait, I’m missing a relation here."

Masonry Right, and that’s the move I actually like. They take the coding-agent pattern we already know from software — call tools, check outputs, revise from evidence — and try to make robots live in that same loop instead of pretending the policy is the whole system.

Eyre Exactly. The paper calls it Physical Coding, and the key split is Code as World versus Code as Policy. One side stores objects, relations, constraints, and progress. The other side stores planning, verification, recovery, and execution. That’s the whole thesis in a form you can actually poke at.

Masonry Mm-hm.

Eyre And the reason that matters is production, not poetry. If the world state is explicit, you can version it, roll it back, compare traces, and decide what failed for a real reason instead of just saying the robot was "confused." That’s a lot closer to something a team could debug.

Masonry So HexaAnything is the harness around that idea, right? It calls perception, planning, and control tools, including VLA and WAM policies, then makes in-the-loop decisions from external feedback. That sounds a lot less like a monolithic robot brain and a lot more like a workflow I can imagine somebody shipping.

Eyre Yeah, with one important caveat: the tooling is doing a ton of the work. The system is not claiming the model magically learned embodiment from vibes. It’s using the harness to decide when to accept a step, when to recover, and what evidence gets written back into the record.

Masonry That’s the part that makes me sit up. If verified traces become data and memory, then the system is not just completing one task, it’s building the next task’s starting point. That’s the kind of boring accumulation that actually turns into a product.

Eyre And it’s also the part where I’m less impressed by the headline and more by the mechanism. The paper is basically saying physical experience should return as reusable programs, memory entries, or structured evidence. That’s sane. It’s also a lot harder than just logging rollouts.

Masonry Okay, but the results are not nothing. On RoboCasa365 they say HexaAnything improves Composite-Unseen and overall success over XR-1 VLA, and the Harness-trained HexaModel beats the base on every split. That’s a pretty clean sign that the traces aren’t just decorative.

Eyre I agree, though I’d keep the scale in view. The gains sound real, but the interesting bit is that the harness-trained model outperforming the base on every split suggests the representation itself is internalizing something useful. That’s stronger than "the agent got lucky on a benchmark."

Masonry And then they push it onto PhyBench and a dual-arm AgileX robot, which is where this stops feeling like a simulation-only idea. If it can autonomously finish physics experiments and most tabletop tasks, that starts to smell like a stack people could build on.

Eyre Sure, but I’d still ask what gets lost when you move from a clean benchmark harness to a messy real deployment. The method depends on external feedback and typed traces. If those verifiers are weak, the whole loop can become very confident about the wrong thing.

Masonry Fair. Still, that’s not a knock against the architecture so much as the actual hard part of the product. The value is that the failure is legible now. You know whether the issue is perception, planning, recovery, or the verifier itself.

Eyre That legibility is the real win. It’s the same reason coding agents got useful before anyone pretended they were general intelligence. You make the intermediate state inspectable, and suddenly revision becomes a system property instead of a prayer.

Masonry Okay, this is going to sound insane on a podcast, but this feels like robots finally getting a version history. Not sentience, not magic — just the ability to keep a record of what happened and use it next time.

Eyre No, that’s actually the right way to put it. And honestly, it’s more interesting than another paper trying to make a single policy bigger and hoping the layout stops mattering. That trick has been tried.

Masonry I’m tempted to say this is the same old harness thesis wearing a robot costume, but that would be rude and also kind of wrong. The physical setting forces a better answer because recovery, partial observation, and irreversibility are all sitting there glaring at you.

Eyre Right. The physical world makes the control layer impossible to hand-wave. And once you admit that, the paper’s future direction makes sense too: evolve the harness, then the model, then maybe the task and representation itself. That’s a much more honest ladder than pretending one checkpoint solves embodiment.

Masonry And that is such an Exploring Next take, by the way. "Maybe the interface is the product" has been our whole personality for nearly a year now.

Eyre Hey, you started it with the haunted backpropagation thing. I just keep showing up for the part where the system finally has somewhere to put the evidence.

Masonry Yeah, and I think that’s the line I’d keep. This is not a demo of robot vibes. It’s a proposal for how physical work becomes reusable software.

Eyre That’s enough of a reason to care. The mechanism is coherent, the benchmark story is decent, and the production shape is obvious enough that I can imagine somebody actually building on it.

Masonry Alright, Eyre, I’m going to let you keep your suspicious little architecture notes for the afternoon. I’m just happy somebody finally gave the robot a notebook instead of another slogan.