> blog
Notes on code, tools, and things I'm making. Occasionally something less technical.
When to throw an LLM at it
I used an LLM to do two sprints of work in an afternoon. Then nobody looked at it. What the giant PR taught me.
·1 min read#ai#engineeringCode is cheap, outcomes are expensive
The best code I wrote last year was the code I talked the team out of writing. Why refusing to build was the right call.
·1 min read#engineeringWhy I built my website
How a Final Fantasy notification tone turned my portfolio into a playable RPG, and why the weird, personal web is still worth building.
·1 min read#meta#creativity#rpgHello, world
Why this blog exists, what I plan to write here, and how to walk the little guy around.
·1 min read#meta
I used an LLM to do two sprints of work in an afternoon. Then nobody looked at it.
We’ve all been there. You know you need to upgrade that library or migrate that framework, but the time isn’t there. Something more pressing, or just more exciting, always wins.
That is exactly the job to hand an LLM.
I tried it on a CSS framework migration proof-of-concept. Over 30 components moved from vanilla-extract to PandaCSS in an afternoon, seamlessly.
The result? A PR so large GitHub struggled to load it. Nobody looked at it. Everyone could see the benefit, but the sheer size was offputting enough that no one wanted to touch it. Lesson logged for next time.
Next time came fast. A few weeks later we decided to migrate off Radix UI to Base UI, another job estimated at multiple sprints. I handed it to Claude again, with one rule the PoC taught me: no PR over ~10 files.
That single constraint changed everything. The PRs stayed focused, and developers could review them properly, without the fear they’d miss something buried in the noise.
An LLM can speed up your work, but it doesn’t erase it. It moves it down the line, to whoever has to review what the machine produced.
Keeping that person in mind is a prerequisite, not an afterthought.
The best code I wrote last year was the code I talked the team out of writing.
It was a greenfield project with a good seed: get a delivery team off scattered spreadsheets and python scripts onto something structured and scalable. But the scope was gargantuan. Nothing short of “everything” was acceptable, which is never a real goal.
Stakeholders wanted to see data over time to make informed trades. After three months trying to shape something buildable, I suggested the boring answer: use Grafana.
The data was already there. Backend engineers used Grafana to monitor systems, so the graphs were battle-tested, better than anything I’d build, and almost no maintenance on our side. Configure a graph and go.
That is the whole point. Writing the code is the easy part. The expensive part is what comes after: the changes, the repairs, the upkeep that turns a shipped project into an albatross around the team’s neck.
Code is cheap. Outcomes are expensive.
So before you build, ask three questions:
- Do we need this?
- Is there a way to solve it without writing code?
- What does this look like in a year?
The best engineers I know write less code, not more.
I’d procrastinated building my own website for months. Every example I found was the same header, footer, scroll template that’s been the norm for at least a decade. Then, while I was banging my head against the wall, my phone buzzed with a sound effect from Final Fantasy 8.
My mind started to race. I loved those games growing up. They shaped a huge part of who I am, so why not reflect that in a website built by me, about me, for me?
I used AI to sketch ideas fast. The obvious one: make the landing page a start menu you navigate with the arrow keys, replicating the look and sound of a 90s RPG. Seeing how well it worked spurred me on.
I had two screens left. An about page that fit perfectly as an RPG character screen, complete with Class, Level and an HP/MP bar. And a blog, which was trickier. Cycling through menus gets boring fast, so I went further: I built a fully interactive RPG, with a character, NPCs and objects to find and collect.
This was the most fun I’ve had building anything in a long time.
So don’t build the rote site. The weird, personal web of yesteryear is still yours to make. As Eames says in Inception;
You mustn’t be afraid to dream a little bigger, darling.
Go make something strange. I really want to see what you dream up.
Well, here we are. First post on the new version of my blog. If you’re reading this, CONGRATULATIONS! you’ve found the part of the internet where I keep the stuff I write about.
Why a blog at all
Honestly? Writing things down is good for me. I have a terrible habit of skips from A to G while talking at a normal Irish pace, which turns out is about two-hundred times faster than normal. So putting pen to computer keyboard helps me get my ideas across better, not perfect but definitely better.
What you’ll find here
- Thoughts on Ai: Worries and praise for this clearly hyped-up but still slightly useful bit of technology.
- Philosophical viewpoints: I read a lot and sometimes you need to breakdown and build back up those thoughts you had about something you read.
- Standup Comedy stories: Strange tales and even stranger jokes are abound so there might be a few stories worth telling from all that.
- Project updates: I have a habit of starting projects and then never keeping track of their
Oh, and there’s a little guy
That’s you. Well, it’s meant to be me but now he’s controlled by you.
Go on bump into things, explore, see what’s hiding in the corners:
- Arrow keys or WASD to walk around.
- Press M for a menu.
- Press Enter to interact with stuff.
That’s the whole tutorial. There’s no starting fight…. yet. Got to have reasons for you to come back.
More soon.