4lbert Logo~/4lbert
HomeProfileSkillsPortfolioBlogGalleryContact
$ echo "© 2026 Torsten Albert · 4lbert.com"
ImpressumDatenschutz
Back to blog

I would fire this lazy guy

TorstenMay 1, 20262 min read

I assigned Claude Code a large task with a fixed goal and forced it to stay on course. Even with nested Ralph Loops, a queue, and finally an hourly cron job, the agent repeatedly stalled before completing the work. It runs for now, but the experiment exposed a laziness for LLM-based agents.

Lately, I gave Claude Code a large task with a fixed goal and wrapped the process in a Ralph Loop. Its first response was: it asked whether I really wanted to proceed, because the task was huge and would likely take weeks. I answered, without mercy, that it should just get it done.

For a while, it worked. Then it stopped without reaching the goal. It did not redefine the objective — I had explicitly forbidden that — but it did change its approach, apparently deciding that an interactive session would be better. To counter that, I wrapped the first Ralph Loop in a second one. Later, when it stopped again, I added a queue to keep both loops fed so the process would not stall.

Still, it stopped. At that point, I started to suspect this was not just a tooling issue, but a built-in behavior: some mix of efficiency, or laziness.

My latest workaround was to add an hourly cron job. After typing only “Continue,” automation felt like the more honest solution. And for now, it actually works — although I am not sure for how long.

The whole thing reminded me of something a professor once told us at university: the best software developers are lazy, but smart. The worst — and most dangerous — are hardworking idiots who produce endless garbage.

Watching an LLM repeatedly stop and invent its own workflow, I honestly feel like I would fire this lazy guy if it tries something else again.

PreviousAgentic Coding changes more than Implementation SpeedNextI fell asleep while you told the Fable