Chi-chi Armstrong รีทวีตแล้ว
IMO, unsupervised coding agents are still in the "uncanny valley" of software development.
Given the recent hype of AI writing "a browser with 1 million lines of code from scratch", I have been trying to give it more open-ended tasks, and every time it delivered seemingly working software but with large flaws in the implementation.
Last week it was a "download manager in Rust" that completely failed at concurrent downloads. This week was a port of the Ryu algorithm for pretty-printing floating points with different precisions (f32/f16/bf16/f8). Both times the software seemed to work but had deal breaker bugs lurking. Fixing those required me to become part of the loop and supervise the agent.
Here is a breakdown of the latest experiment, for those who may be interested. TL;DR: github.com/elixir-nx/nx/p… (it says 66k lines added, but 65.5k is a generated fixture file, so the diff is more like +800/-300).
---
The goal was to implement pretty-printing of floating points (f32/f16/bf16/f8) in Numerical Elixir. I created a blank repository, wrote the problem statement, and mentioned I specifically wanted the Ryu algorithm, linking to a reference implementation in Erlang (github.com/erlang/otp/pul…) and to the paper (dl.acm.org/doi/10.1145/31…).
I did one attempt with Sonnet, another with Opus, and while they both delivered a project with a passing test suite, both implementations were wrong and incomplete.
In the first attempt, many of the tests were fabricated, to match the faulty implementation. With wrong code and wrong tests, there was not much to salvage. Time to start over.
In the second attempt, now with Opus, I suggested it could generate all possible printable values for f16 from the canonical Ryu implementation in C (since there are only 65k of them), and use that to validate the algorithm. Once again, it delivered a passing suite, but it made one crucial mistake early on: when generating the reference table, they cast f16 to f32 before printing (a subtle mistake many would make), which led to wrong reference values. And because the reference table was wrong, it lead to all sorts of wrong decisions downstream, such as adding casting and deltas.
That's when I decided to be in-the-loop and break the problem into smaller ones:
1. I asked Claude to create a f16 reference table and made it clear in the prompt that any sort of casting would lead to the wrong solution. That's the reference table you can find in the PR
2. Then I asked it to explicitly port the Erlang algorithm, as is, and then parameterize the constants in the algorithm to make it generic (so it works for f16/f32/etc). Then write a test comparing all reference f16 values
3. Then I moved the algorithm to Nx. Since pretty printing is now precise, it broke 150 tests, which I used Claude to fix (with specific instructions to change only the precision in numbers and not touch anything else)
Claude still made mistakes but because I broke the problem into small steps, and verified their correctness each step along the way, I avoided bad decisions cascading through the whole implementation. And yes, using Claude was still extremely helpful (honestly, if I used Claude only on step 3, it would have already been worth the price tag).
Those two experiments have been orders of magnitude smaller than the browser one, both they seemed to work, but were flawed upon deeper inspection. For now, I'd still advise staying in the loop and avoiding falling into this trap.
English
