A Blog Experiment Finds That Asking an LLM to “Write Better Code” Can Help, Up to a Point

# A Blog Experiment Finds That Asking an LLM to “Write Better Code” Can Help, Up to a Point

*Event date: 2025-01-03*

A new blog experiment asks a deliberately silly question with a serious edge: if you keep telling an LLM to “write better code,” does the code actually improve? The answer from the post is yes, at least for a while. The author builds the test around a Python function that filters numbers whose digits sum to 30 and then measures how quickly different Claude-generated versions run on an M3 Pro MacBook Pro.

The first result is a plain baseline. The initial implementation is correct but unglamorous, and the author says it takes about 657 milliseconds to run on average. That starting point matters because the rest of the post is not about whether an LLM can write code at all. It is about whether repeated prompting produces real, measurable improvement instead of cosmetic churn.

On the first rewrite, Claude returns code that the author describes as an “optimized version” with several improvements. The new version reorganizes the logic and lands at roughly 2.7 times the speed of the baseline. The author’s point is not just that the output is faster, but that the model appears to be responding to the prompt in a way that affects algorithmic structure rather than merely polish.

The next round pushes harder. The author feeds Claude the previous solution and asks again for better code. This time the model adds more aggressive optimization, including a parallelized approach. That version creates its own problems, including subprocess and pickling issues that have to be fixed before it can run cleanly. Once those fixes are applied, the code is about 5.1 times faster than the starting implementation.

The third iteration shows the trap hidden inside the prompt. Claude returns something more elaborate, but the author says the performance actually slips a little, dropping to about 4.1 times faster than the baseline. In other words, repeated “improvement” does not guarantee monotonic gains. At some point, the system can get more complicated without getting proportionally better.

The post’s final stage pushes into heavier tooling, including numba and JIT compilation. That is where the experiment becomes less like a novelty and more like a cautionary tale about what counts as optimization. The model can still produce faster code, but each new round asks the human to judge whether the extra complexity is worth the speedup, and whether the speedup itself is coming from the model or from the widening toolbox the model has been allowed to use.

The broader takeaway is practical rather than mystical. Iterative prompting can surface better code, but the gains are uneven and the process can drift into diminishing returns. The author also makes clear that the mental overhead of steering an LLM is part of the cost: every improvement has to be checked, benchmarked and debugged. That means “write better code” is not a free productivity spell. It is a workflow with tradeoffs, where the fastest answer is not always the cleanest one.