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.

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.