Claude

We named a skill after the first people who did it, and the mistake is keeping AI stuck in one department.

I built a tool to feed my engineering team faster. What I actually built was a business analyst.

A companion essay for "Claude Codes on Classics"

Last week I was digging through a music licensing library, trying to find the sound for a show about teaching an AI to program forty-year-old computers. I knew what I wanted. I couldn't name it. I typed genres. I typed moods. I typed increasingly desperate combinations of both.

I had a spreadsheet budget that worked. What I didn't have was a monthly reset that wasn't manual, a way to bring my wife into it, or any hope of querying a few years of my own history. So I went shopping. YNAB wanted envelopes. Monarch wanted my bank logins. Copilot wanted a subscription. Every option wanted me to trade a method that worked for its interpretation of how budgeting should feel.

A day and a half later I had my own, built around my spreadsheet logic, connected to nothing and hosted nowhere. That's the piece: not that vibe coding kills SaaS, since I run a SaaS company and would rather not announce my own funeral, but that the personal layer of software, the one the 80s took for granted, is coming back to the user.

A CSV import that reported failure but had actually succeeded, a 60-second load balancer timeout, and fifty sequential calls to the Mailgun API stacked up inside a loop. The old version of this debugging session takes two hours on a good day: dashboard to codebase to database client and back, assembling the picture piece by piece and holding it all in your head.

With New Relic's MCP server, MongoDB's, and the full codebase live in one Claude Code session, the picture assembles itself. Diagnosed, fixed, and deployed in a single sitting, along with a silent behavior gap no alert would ever have flagged, because from the system's perspective nothing was wrong.