The Day Coding Died

About a month ago I came across a blog post that hit hard. For me it was the day coding died, and it sat with me for days. It was obviously coming — the advancements in LLMs have been impossible to ignore — but actually seeing it, feeling it, that landed differently.

All the years of it. Writing tight code, solving maths problems, finding optimisations. Pointers. Assembly. Cracking games. Desktop apps, full-stack web apps, late nights where the solution finally clicked into place. Coding was how I solved problems, and solving problems was the best part. That doesn’t just quietly retire.

Ironic, really. The dumb kid from The Simpsons is the one who showed me where this is heading.

Everything Is a Ralph Loop

The blog post was Geoffrey Huntley’s “everything is a ralph loop.” If you haven’t watched the talk The Ralph Wiggum Loop from 1st Principles, go and find it. Worth the hour.

Geoffrey isn’t being dramatic. He’s just describing what he sees. And most of us haven’t noticed yet.

The idea of a ralph loop stuck with me. A single autonomous loop, one task per pass, watched and tuned until it does the work. Monolithic. Boring. Effective.

The Experiment

I’d always wanted an Android app that could feed me information while I’m driving. I’d never built an app before, so I thought I’d try it with ralph. Claude Code as the driver, Opus for planning, Sonnet for the build loop.

A day later it was running on my phone.

It worked. Properly worked.

What it unlocked: you have to refresh the context, constantly. The model doesn’t carry state the way a brain does. The longer the session goes, the more it fills with old attempts, abandoned directions, half-corrected mistakes — and it starts to drift.

Same thing happens to you at work. Don’t take a break between context switches and your brain stops analysing properly. The model isn’t any different.

What Changed

I stop more often now. Clearing the slate is part of the workflow, not a failure of it.

And somewhere in that shift, I could see the writing dropping off.

Not because I can’t. Not because the AI does it for me while I watch. The work itself is changing. I describe systems, make decisions, review output, redirect.

My Workflow

For larger features it goes like this:

• Research the delivery first — what’s the scope, what depends on what, what does a sensible PR look like? Get the shape before starting.
• Write the specs. Intent only — what and why, no code. Putting code in a spec locks you into an implementation before the model has even looked at it. A spec is a brief, not a blueprint.
• Make a dev branch and run the build loop on the first few specs.
• Stop and review. Every time, I find something — a vague spec, a case I didn’t think through, an assumption that doesn’t hold. Add specs (often a 3a, 3b, 3c between 3 and 4), tidy up, run the loop again.
• Break it into clean branches and PRs for pushing. The specs stay committed in the dev branch but don’t get pushed.

This is similar to how planning mode works in many models. I prefer to own the specs myself though. My favourite way is to have the model interview me — it asks the questions, I answer, and together we build out what each spec should say. It pulls ideas and alternatives, just like sparring with another developer about a task.

It sounds methodical because it is. But it doesn’t feel like overhead. It feels like building on solid ground instead of whatever the AI assumed I wanted.

Where That Leaves Me

The grief faded. What replaced it is deep quality reviews.

I can’t trust the code to be perfect. So I labour across the business logic and the tests, looking for the bits that look right but aren’t. That’s where the engineering lives now.

The thinking didn’t stop. When you’re not in the syntax, you spend more time on what you’re actually building and why.

That’s the part the model can’t do.

For now.

— Brad

Disclaimer: This project is conducted in my personal time. All thoughts and opinions expressed here are solely my own and do not represent any current or former employers.