Ralph Wiggum is forcing software engineering to look in the mirror. Some engineers don't like what they see.
For the uninitiated: Ralph Wiggum is a technique where you wrap a bash loop around an agent execution and let that agent drive toward working software. It's named, built, and popularized by Geoff Huntley, who made a provocative claim in a recent podcast: software development is dying. Software engineering is alive and well.
He's right. And the implications are bigger than most engineers want to admit.
The slop argument misses the point
Yes, Ralph Wiggum produces slop. Code that doesn't always work. Solutions that miss the mark. Nobody's debating that.
But here's what the critics miss: slop is the current state, not the ceiling. The economics of agent orchestration are too compelling. Innovation will pour into these systems until they outperform humans. The Fly.io Essay "My AI Skeptic Friends are All Nuts" that garnered backlash on Hacker News complained about sloppy AI code - meanwhile, practitioners leaning into tools like Claude Opus 4.5 are pulling ahead of those still in denial.
The people who learn to drive a fleet of Ralph Wiggum agents effectively will outperform the skeptics. That's not a prediction. It's already happening.
Why software is uniquely vulnerable
LLMs produce images, sounds, and other forms of art - but quality in those domains requires human judgment. Code is different. Code offers something rare: verifiability of correctness.
Software compiles or it doesn't. Tests pass or they fail. The output works or it breaks. This verifiability makes software the perfect medium for agent-driven creation. And it's why the art of software is shifting - from the shape of the code to the outcome of the code.
Development is dead. Engineering remains.
Software development is what agents have eaten. Software engineering remains firmly human.
We spent so much time writing code that we didn't spend enough time engineering solutions. That ratio is inverting.
Crossing the chasm
The new art is defining problems. Understanding how pieces fit together. Building experience with agent orchestration - and learning that specificity wins.
General-purpose agent fleets underperform purpose-built ones. I work in Elixir. The agent orchestration I've shaped for my Elixir codebase - tuned to the peculiarities of Opus 4.5 - doesn't directly transfer to Rust or TypeScript because I've tuned to my context. That specificity drives better outcomes.
The engineers who thrive will step into higher agency: defining the problem space, shaping the orchestration, engineering the solution. The ones who cling to elegant code as craft will find their art no longer matters.
The chasm hasn't been crossed yet. But the path is clear. The only question is whether you'll walk it - or get left behind.