Hand Cranking the Development Engine
Abstract
I've been building a little research environment inside the Hangprinter simulator repo, where AI agents can investigate engineering problems, run experiments, modify code, and leave behind research reports that future agents can build on. The simulator and real robot firmware give them a way to test ideas rather than just generate code. Multiple agents can work in parallel, with a separate reviewer checking their results. So far they've helped find physics bugs, improve simulated calibration, and speed up experiments. The accumulated research is becoming as important as the code itself. It's still far from autonomous, and simulation results don't necessarily survive contact with physical hardware. But it's changing what I can realistically investigate as a single developer. This post is about how that research loop works, what it's achieved so far, and what might remain valuable as AI development gets increasingly automated.
Contents
- Background: cheaper hardware through better software
- A research world inside the repo
- How the agents work and accumulate knowledge
- Parallel researchers and experimental results
- How do we know what's better?
- Related research and the human's role
- Trying it yourself
- What will remain worth building?
Introduction
I've been working on many things lately, but I keep getting dragged into further simulator development, as in hp-sim5. You can try its web frontend for humans at hp-sim-3d.hangprinter.org. The more interesting part, to me, is what happens inside the repo.
It's bringing a very old Hangprinter idea alive: very advanced and very cheap software, created in such an ergonomic way it almost feels automatic. Alongside the code, a body of numerical research is growing inside the repo, ready for each new researcher to read, cite and build on.
The old idea, in a vauge form, runs back to the days when Hangprinter was started in 2014, when I thought better, cheaper software could eventually make cable driven robotitcs practical.
Digression, Because I Love Historical Context
I arrived at cable driven robotics (CDPR) via another design principle, namely Reprap. It drove down cost, and I simply wanted to drive cost down further by combining Reprap with CDPR.
The software hype was at least 30 years old in 2014, so the idea of better, cheaper software was in the air. I even asked friends and family if there would be less or more software in the future. They all said "more". Nobody said "less".
So naturally, I wanted to stay as far to the right as I possibly could, in this imagined continuum of approaches to robotics:
2023: Chatbots
I coded and built and coded some more. Then came chatbots in 2023 and showed us they will probably do all the coding pretty soon. Hw design as well. Anything that can be stored and modified on a disk they will do.
I don't want the Hangprinter Project to die, but I don't make any money off it, so having it automated, or at least having my per-hour output strongly augmented, would be perfect. Replacing unpaid work with AI work is a pure upgrade.
It was time for me to learn to harvest generated code. In last year's post I described building a simulated Hangprinter for AIs to work on.
2023 and 2024's AI code was so terrible. Almost as bad as my ability to write simulators. I kept hitting "the wall", ie moments when the code base suddenly had grown beyond my understanding and their ability to juggle it. Upon hitting the wall, you could throw any amount of clever prompts at your code base, but you could not get any further.
Each time I hit the wall I had to manually inspect every line of code. Google things. Learn what the cute AIs had mistakenly let me ask it to build. This happened ca every 3 or 4 weeks. I had to build my own understanding manually, based on thousands upon thousands of vibe coded lines. Deleting it all was tempting. Reading it was arduous. It was soul draining. It made people and companies quit AI coding. But I was kind of desperate to get a simulator up and running.
You might notice here, at this point in the text, that the idea of why I needed that simulator is still pretty vague. I'm excited about hp-sim5 work right now because both the why and the how have just become much more concrete.
I have AI driven research agents working inside the repo now. The hp-sim5 repo has become a little research world with the simulator at the center.
A world in which research agents can work
I don't want to repeat last year's blog, but just briefly mention that a repo with everything is what enables the chatbot "researcher" to behave like a researcher. Sources, code for execution, results for inspection, machine definitions, requirements, development history, etc etc, it all improves the research agents. Everything a researcher would carry in their heads or in their computer file systems. Notes, goals, ideas for further experiments, you name it. Even a long list of the thousands of older prompts used to build it.
The physics engine is now pretty good and fast and all, and it's the center of this new world. But as a physics engine or codebase in itself, it's not really that special. This blog post is more about why we build it, and how. The symbiotic relationship with the repo's research agents is what makes the simulator more interesting than other simulators I've worked with. As long as physics engine is fast enough and close enough to reality, it enables the agentic researchers to maintain it and to do many experiments with it.
The research agents' world also need the firmware that will actually control the machine, with its planning, coordinate transforms, motor commands and encoder observations. The hp-sim5 repo contains versions of Klipper and RepRapFirmware that can run on the same machine as the AI researchers themself, as well as many integrations with those firmwares.
Again, there's nothing special with those firmwares, the important thing is what they enable the research agents to do. The agents are able to run the RepRapFirmware planner against simulated physics, and exposes a live command interface where the agents can send G-code one line at a time and examine the replies. They're able to very precisely record every little detail of the simulation, like forces, angles, positions, etc, and inspect those datasets efficiently through tools like Rerun.
Agentic Researchers in the Repo
The entry point is a script called hp-sim5-research-agent. This script is also sometimes called "the launcher". It is a collection of some custom skills, prompts, mcp servers, and settings basically. It starts a Codex or Claude conversation with access to the simulator and other research tools.
Given a research goal, a hp-sim5-research-agent works roughly like this:
- Explore the relevant code, earlier research reports and outside literature. Develop ideas about what could be improved.
- Reproduce and measure the current behaviour. Write down hypotheses, constraints and experiment budgets in a research notebook.
- Design and run experiments to test the hypotheses, preferably many small, cheap ones. Compare the results with the baseline, then decide what to investigate next. Revise the hypothesis or change approach when the evidence calls for it.
- Implement the best-supported changes and test whether they improve what matters, including checking for regressions.
- Add a research report and searchable abstract to the repo’s growing research corpus. Cite earlier work, link the supporting code, data and recordings, and update the research index. Document rejected hypotheses and inconclusive results too, so the next researcher can build on what was learned.
These steps repeat as the investigation develops. Afterwards, an external evaluator, for now an agent loosely assisted by me, reviews the evidence and code, decides what to keep or investigate further, and tests the combined changes.
A Research Corpus That Keeps Growing
Each completed investigation leaves a small research paper and some other resarch artifacts in the repo. The paper cites earlier research and links to the code revisions, datasets and recordings that support its conclusions. Failed ideas go into the pile too, with an explanation of where they failed.
So alongside the software there's a fast-growing pile of papers about numerical experiments on Hangprinter and the simulator itself. They cover physics bugs, calibration algorithms, performance, failed approaches and improvements to the research tools. For every magic number that gets tweaked in the code, there's a research paper describing the work that went into deciding that number. There are short abstracts and a research catalog to help the next researcher find its way into the pile.
A new agent can search that corpus, read the relevant papers, follow their citations and inspect the original numerical evidence. If it's investigating calibration, for example, it can find earlier cases where a lower fitting score produced worse anchor positions, examine those cases, and use them to test its own idea. Its new paper can then cite the old one and explain what it adds or changes. Findings become references for further findings.
This self-improving mechanism is an important part of what makes hp-sim5-research-agent feel so ergonomic and empowering to me as a researcher. The human as well as the agentic researchers' experiences persists in the corpus, and improvements to their methods and tools persist in the repo. The next session starts with more knowledge and better equipment. That improvement can survive a new conversation or a change of model. A useful contribution can be a better algorithm, a better way to run an experiment, or a finding that changes what the next research agent should try.
The corpus also connects to research outside the repo. I can give an agent a paper on cable robots, scientific computing or robotics and ask it to investigate whether the idea could make Hangprinter better. It can read papers and libraries online too, although I still tend to point it towards the work I want investigated. What it learns can become another local paper, with references back to its sources.
I've found that providing hints and pointers towards promising research directions is important to keep research quality and progress high. So deciding what I give the agents matters a lot. This is in line with Anthropic's findings on their Automated Weak-to-Strong Researcher.
Several Researchers at Once
The launcher's --worktree option lets us start multiple instances on the same machine with separate code checkouts.
Each can follow its own investigation, drawing on the accumulated research.
I ran six research agents at the same time on my machine the other day, when I first tested working with worktrees. Only two came back with the same improvement idea, so I was able to merge five quite large improvements in a few hours. Each agent could follow its own line of investigation while the others kept working.
I use a separate reviewer agent to assess the work and help decide what deserves to be kept. I haven't fully automated the orchestration and the whole review-and-merge process yet. For now I use a second agent that reads the research, tests it independently, including their combined effect. This helps catch misleading benchmarks and changes that interact badly. Useful findings and research tools are worth keeping alongside code changes, so they remain available to later researchers.
What Has Come Out Of It So Far?
One of the most useful abilities turned out to be improving and debugging the physics itself. The agents are surprisingly good at finding an unstable state, recording it in Rerun at intervals of a few milliseconds, and tracing oscillating forces or created energy down to a function, an equation or a particular solver pass. They can then change the implementation and replay the same state. I've seen them do this far quicker than I've ever managed to debug these bugs myself.
One example was an HP4 wobble with a period of about 24 milliseconds. The agent traced it to the damping calculation: on a second constraint-solver visit, it treated the position correction made by the first visit as fresh motion. The attempted damping fed the oscillation. Keeping that displacement fixed for the step made the same loaded state settle in matched recordings. Other investigations corrected repeated counting of motor loads and the coupling between mounted rotors and their carriers. These are changes to the mechanics being computed, with consequences throughout the simulated machine.
The calibration procedures have improved too. A consensus approach uses agreement between distinct fitted anchor sets when choosing the geometry to apply. On eleven distinct saved candidate sets from simulated HP3 runs, mean applied-anchor RMSE fell from 4.27 to 3.09 mm. A separate history-seeded fitting experiment reduced applied-anchor RMSE from 2.706 to 2.440 mm in matched simulated HP3 runs, with the same collection layout and number of iterations. The agent found a useful previous estimate instead of starting the fitting work from scratch each time.
Other work shortened encoder-settling waits, added recovery when a supposedly fixed motor slipped, and introduced stopping rules based on agreement between fits. One simulated HP3 stopping trial used about 11% less collection time for 0.21 mm more anchor RMSE. That is a tradeoff we can inspect and choose deliberately. These results come from particular simulated cases; reliable calibration across machines and on hardware remains a larger goal.
The AI models that drive the agents also improve all the time, and that alone improves mental ergonomics for me in many different ways. A current example is that it increases the scope and ambition of what feels reasonable to attempt. I don't have to shy away from stuff as often anymore. For example, I was originally struggling to keep JavaScript and Python versions of the physics engine up to date, and spent lots of time on that using the GPT-4 family last year. This year, with the GPT-6 family, getting a Rust version, based on a known good js version, took about two hours. I now have five different implementations of the physics engine, with slightly different purposes.
But I should probably prune most of them, since they're just one prompt away anyways. Hand tuned, manually observed behavior, marked as desirable, frozen into tests, is valuable. The code that implements them is really not valuable beyond the prompt that was needed to generate them and the time it took to carry the prompt through (which is falling with every new LLM model release, ca every 7-10 days). The prompt carries intent, which will always remain valuable, as long as humans are in control.
Time, and therefore speed will also remain important. The Rust Native engine has made the experiments faster. The full Rust/Wasm engine measured about 2.5 times the throughput of the earlier solver-only Wasm version across eight frozen workloads. In a later recorded HP4 collection comparison, wall time fell from 19.27 to 10.00 seconds, mostly through better logging. These measure different parts of the pipeline, so the speedup factors shouldn't be multiplied together. Faster feedback makes it practical to try more hypotheses.
I have invested a lot of time into developing hp-sim5 so I almost feel like I'm in a debt that hp-sim5-research-agent should make me able to pay back. Oh, what a stressful life I have chosen. So I'm not only excited that it's working so well, I'm also quite relieved.
The research tools have improved along with the algorithms. Calibration was split into replayable fitting, planning, evaluation and ranking stages, so a researcher can investigate a selector without collecting everything again. Extended recordings retain firmware commands, replies, encoder observations and calibration artifacts together with the motion. This makes it much easier to return to a surprising experiment and find out what actually happened.
The reviews have also caught changes that looked good locally and broke real workloads. A startup wheel-spin change made printing unstable; the correction now has a mandatory test using the actual HP4 Print Logo motion (ie the exact manual procedure I used to do as a smoke test after every change before). We get useful code out of these sessions, and better ways to catch the next mistake.
What Counts as Better?
Calling these changes "improvements" already implies an objective. Anyone wanting to improve anything needs a way to know whether they're getting better or worse. Research on unsupervised or lightly supervised AI development keeps returning to that need for feedback.
Chen, Wang, and Qu recently produced a wonderful overview of the related research field called Recursive Self-Improvement in AI: From Bounded Self-Refinement to Autonomous Research Loops. Their "verification hierarchy" sorts feedback mechanisms by their reliability and coverage. Here it is:
Beside "Execution feedback" is says "reliable but incomplete". For hp-sim5-research-agent, the simulator supplies feedback about the robot as well as the software. The researcher can investigate whether a change improves motion, calibration or the forces inside the machine. So hp-sim5-research-agent has access to broad execution feedback. Still incomplete, of course, but quite broad, compared to other AIs and coding agents.
The simulator might contain bugs or lack relevant physical phenomena. In general, a simulation can only capture a sliver of reality, so the exact sliver we want to investigate need to be planned and foreseen with precision. Difficulty of implementation also adds problems, even for those who have foresight to plan the perfect sliver. The finished simulation will always be too chaotic in some aspects (the simulator itself might crash), while being way too orderly in other aspects (eg springs being linear, hysteresis effects lacking, friction and noise being too simple etc).
However, in my experience, engeneers more often underestimate the usefulness of simulators than overestimate it. I will steelman them and always admit they have a point, though. Many have had bad experiences or heard stories about robots being trained directly in a simulator only to fail spectacularly when the code is later executed on a real-life robot. This is the story of the dreaded sim-to-real gap.
As long as we've not connected the research agent to a physical machine with ideal sensors, the human researcher will still need to manually:
- interpret results and make judgements about quality and usefulness of the output, and
- decide if it matches with their needs, ideas, and intentions.
But I do prefer the burden of doing those judgements over having to do what I did before. And for now I prefer it over having to build physical machines and tinker with lots of sensors, especially when I work with questions who are not about the sensors themselves.
The most convincing argument I've found for this workflow is the speed at which uncovers huge numbers of bugs that were almost impossible to find before, and how it adds a number of features that were previously almost impossible to develop. Once you've lived through it as a developer, you don't look back. It's just something else.
Neighboring CDPR Research
Hangprinter is a cable-driven parallel robot, or CDPR. There is already a substantial research field around these machines. CASPR, for example, is an older open platform for cable-robot kinematics, dynamics, control and design analysis.
Caverly and colleagues' self-calibration work uses covariance-based measures to decide which observations help calibration and when enough data has been collected. Their estimator works with robot pose and measurement biases. hp-sim5's autocal instead tries to recover unknown anchor positions using motor encoders.
Another related direction of CDPR research is to train a neural network to control the robot. CaRoSaC combines cable-sag simulation with reinforcement learning of cable-length commands. Their neural net replaces parts of a conventional controller, down to (but not including) the PID loops of their motors. In hp-sim5 we don't throw out the conventional controller, or even parts of it. Our contribution is rather to augment (and yes, partially replace today's form of) the coder, researcher, and developer. The approaches are compatible. A research agent could investigate a learned controller too.
I see hp-sim5 as a development environment joining cable mechanics, winches, firmware and calibration in experiments an agent can conduct. The useful comparison with other CDPR tools is whether it helps us answer engineering questions and produce results that survive physical testing.
Other People are Building Research Loops Too
DeepMind's AlphaEvolve searches over code using automated evaluators. Andrej Karpathy's autoresearch makes the loop small and concrete: edit a training script, train for five minutes, evaluate, keep or discard, repeat. The Darwin Gödel Machine explores changes to the coding agent itself and keeps an archive that later work can branch from. Anthropic's Automated Weak-to-Strong Researcher is particularly close to the way I want to work: parallel researchers, local access to previous findings, and freedom to choose experiments around a measurable objective. Its authors report strong results on their research task, but limited transfer of one method to their production setting. That makes testing ideas on new robot configurations feel especially relevant here.
Kirgis and colleagues' Can AI agents conduct open-ended AI research? gives a less optimistic result. Across two case studies, agents handled the research engineering but struggled to produce substantial answers to the research questions. Repeated AI review often produced more caveats instead of a better investigation. I take that as a useful warning for hp-sim5: review should sometimes cause us to change the question or the experiment, rather than merely polish the report.
My Part of the Research Process
During numerical research, there are many branches and holes to fall into, even in experiments that sound super easy in principle. There are so many buttons to push, versions of everything and trivial details to remember that humans often choose simpler and fewer experiments. The agents are great at the mundane stuff that overwhelm us humans. Keeping them as a layer between ourselves and the nitty-gritty details of setting up experiments, through all the practicalities and the surprises, is a large part of the point. I've spent years doing numerical experiments manually, and I'm glad I'll be doing less of it.
My experience so far is that my research ideas have become more useful after hp-sim5-research-agent started working. I have more time to think about them, I get more input on them faster, and so I get new, better ideas faster as well. Unfruitful directions are killed faster, since I can ask for exactly the experiment that will approve/disprove.
I'm starting to think this idea of "automating" thought work is misunderstood. You can't stop thinking or indending any more than you can "automate" getting up in the morning. All you can do is ease your load, lower your wants (unthinkable!), or augment your ability.
This is not me being nostalgic or inventing ways to make myself relevant. It's rather me realizing I've set myself an impossible, unrealistic goal of "full automation" of the Hangprinter Project. If it ever flies off on its own with machine power, it was still started by me, and will remain an augmentation of my idea. Otherwise, some other intent has changed it, and it has become an augmentation of their intent instead of mine. Let's hope it flies off some day regardless.
Trying it yourself
Codex and Claude Code are the harnesses I'm using at the moment. Support for any other harness is just a prompt away. I chose this setup initially because the subscription plans available made the experiments affordable.
The hardest part currently is getting used to the breadth and ambition of things I can ask for. "I want faster. Make it faster." can be a perfectly useful prompt. If I need to run for lunch, I can throw something simple like that to a few agents and have verified improvements to review when I get back to the keyboard. Or the smartphone.
Cloud development environments can keep the agents running and reachable from a phone. So Hangprinter research can run 24/7 if you want. Warning: Actually doing this from bed is detrimental to your health.
Some of the prompts are in the repo, as is the cloud development environment setup scripts. I'm keeping the reviewer prompt separate and private for now, and I expect to keep changing it as the research process develops.
If you want to use or build on hp-sim5, ask your agent to look through the current repo. The permalinks in this post show a snapshot at the time of writing. The project will keep changing.
What still makes sense to build?
More software features are becoming "just ask the AI to do it", without a special button or a dedicated procedure in between. Want a new parameter sweep, a comparison plot or an unusual diagnostic? Often the agent can make it on the spot. I expect this to continue, which raises the question of what is still worth building and maintaining.
The answer is of course some version of "whatever we want". But as an eternal engineering physics student I also want a more physics driven answer:
The real physics we're trying to simulate will not change. The need for good models might disappear, if we opt for pure evolutionary development. But I don't think we will. I think we'll keep wanting physics models of some form.
I think fast, inspectable engines like hp-sim will remain useful for at least a few months, while "World Models" and other new approaches still mature out there somewhere. When the new physics tools come, we throw away our hp-sim5 XPBD CableJoints Rust engine and swap it out for the wonderful new tech of the future.
Hopefully some of the new stuff will be inspectable, deterministic and fast, (sort of like the code we already have, no?). Physics calculations, firmware execution and repeatable experiments benefit from determinism and speed.
The idea of accumulating experience from a long sequence of experiments will not die either. So we keep growing the research corpus.
I'm still hand-cranking this hp-sim5-research-agent development a little bit. From what I see in the literature, everyone are. But it's fun and exciting. I like it better than I liked pulling the cart by hand.
- tobben
