Shite Code That Works Is Still Shite Code

"Shite code that works is still shite code."

I've been saying that for years. This week I had to reckon with it.

I built a bot for Hearts n' Tales, my craft distillery podcast. The job: find distilleries in Florida, contact them, book them as guests. I wrote a solid design document, answered about fifteen questions, and turned GitHub Copilot and Claude Sonnet loose on it. V1 shipped. It's in production. It works.

This week I started V2 and took my first real look at the V1 code.

Holy crap.

PHP 5.x. Full procedural. No classes, no namespaces, no modern anything. The kind of code that would earn a junior developer a very serious conversation.

My first instinct was "we rewrite this." Then I stopped.

Because it works. It's secure. It's fast enough. It does exactly what I asked it to do.

And then the reframe hit me: I wasn't the coder on this project. I was the client.

I bought the tokens. I wrote the spec. I got a working product. The AI made technical choices I never would have made, but the product delivered on every requirement I gave it.

So here's the question I'm sitting with, and I'm genuinely asking: if you're the client and not the coder, does code quality matter beyond works, secure, and fast enough?

Because if the answer is yes, I need to write better design documents. And if the answer is no... that changes a few things about how I think about AI-assisted development.

I'm still not sure which answer I'm rooting for.

Originally posted on Linkedin: Shite Code That Works Is Still Shite Code.