The AI Productivity Illusion: Why Ralph Loops Won’t Save Us

In the age of Ralph loops for making code work, I have the feeling it’s all designed to just burn more tokens and increase revenue for model peddlers.

A Ralph loop is an iterative process where an LLM keeps generating and refining code until it passes some validation—burning tokens each cycle. It keeps iterating until, hopefully, it’s done. Before, we heard about small-time devs exposing secrets or deleting their code or database. Now big multinationals are having outages related to AI-generated code.

The solution? Ralph loops?

Right now I have a spec builder, code reviewer, spec reviewer vs code for adversarial checking—verifying my spec was implemented. We have Dependabot on GitHub and some scanning with SonarQube. All in the name of automating my work. Guess what... I still need to review it all because I cannot guarantee, even with this setup, that no mistakes will happen.

If mistakes happen, I cannot have cognitive debt. Cognitive debt is what you owe when you don’t understand the code you shipped. It accumulates silently. You only notice it when something breaks and you can’t explain why.

I need to understand the codebase and what we’re trying to do. I still need to use my actual brain and walk through it.

Meanwhile, companies like Amazon are massively shedding software engineers. They’re putting a lot of review load on their seniors. I assume their end goal is that they train the system doing this so seniors can be replaced eventually.

Got news for you: it will not happen with LLMs. LLMs are not made for thinking—they brute-force patterns and will always carry the risk of hallucinations. Studies from 2024 claim it will not be solved using LLMs: Formalizing the Gap between Validating and Verifying Hallucinations in LLMs.

If LLMs fundamentally brute-force patterns rather than reason, more iterations don’t fix the root problem—they just make you pay for more failed attempts. No matter how many iterations a Ralph loop does, or how many adversarial model reviews I run, there will always be risk.

Meanwhile, companies are just trying to get rid of engineers. They’re putting enormous load on their seniors. As I wrote before in The AI Productivity Illusion, IBM is even re-hiring juniors because they realize: once there are no seniors left and we haven’t fed the talent pipeline, there’s no one looking over the shoulder of the LLM.

Of course, short-term focused quarter-result markets don’t care about the long term. Most executives’ bonuses aren’t tied to the long term anyway.

Learn how LLMs work. Like a nail gun, they can be efficient tools when you know when and how to use them. A roadmap to become a senior developer is still a good goal. This is a good example: Senior Developer Roadmap. I’d update it a bit and add an AI layer to it:

• Know what to delegate

• Understand how to tweak an LLM to get the best result out of it

Don’t despair. I’ve been off the market after the dot-com boom too. Thought I would never work as a software engineer again, and now 25 years later I’m still here. While executives are supposedly paid for anticipating the future, it’s only the immediate future of the next quarter.

Look at GitHub’s downtime. 90% uptime at the moment. That means it’s down every day for 30+ minutes. But software engineering is solved by AI. Just throw more Ralph loops at it. You’re an idiot—you don’t know how to prompt it properly. Wait for the next model release. That will solve all the problems.

Let’s keep it real. While I love using agentic coding, I’m still a software engineer. We will always need software engineers. While entry-level coding is done by LLMs with a good training set, we still need to train juniors to steer and validate LLMs’ work.

Recently I spent 45 minutes debugging a state machine with an LLM. It walked through callbacks, caught edge cases I missed. The tedious work was automated. But I designed the state machine. I wrote the spec. The LLM was a collaborator, not a replacement. Meanwhile, I could focus on designing and architecting the system.

This is what productive AI-assisted engineering actually looks like—not replacing engineers, but changing what work they do.

The bubble needs to pop first before the sane-minded people can start doing actual work in creating value. The “throw more AI at it” crowd will move on to the next hype cycle. The engineers who understand how these tools work—and where they fail—will still be here, building systems that actually run.

The next generation of engineers won’t be “prompt engineers.” They’ll be engineers who understand systems, constraints, and failure modes—and use LLMs as one tool among many, not the solution to everything.