Your AI Setup Isn't the Product
I'm so happy to have you here in the Frazcave. This is my little place on the web, kind of like the Batcave but with more colors! I write here mainly to relax and share what I like, hoping to create a cozy place for anyone who visits.
If you want to chat, my contacts are below.
Hello again, cave dwellers!
It’s been a while since I wanted to talk about the hype around AI optimization. Lately my feed is full of it. Ton of people sharing the mantra of “saving tokens” and giving convoluted advice on how to find the sweet spot to save money while keeping the tool effective.
To me they all sound like the same recipe: keep the context tiny, plan before you execute, spec-driven whatever, multiple CLAUDE.md files located near the specific folder they impact, and so on.
And just to be clear, I’m not saying it isn’t effective. Some of these concepts are actually documented on the pages of the different companies that build these products. The advice itself is fine, but sometimes I worry that it’s easy for us to get caught up in these kinds of distractions, making the perfect setup your first job instead of focusing on actually building the product.
Closing this parenthesis, I’d like to focus on a sentence I heard today:
The ideal setup is a small
CLAUDE.mdplus very specific skills, combining the planning ability of Opus and implementation from Cursor, because otherwise you’ll burn through all your credits too fast.
I felt kind of triggered by this sentence.
I use Claude heavily for work, and my personal plan runs about €100 a month. For a company, that’s pocket change. I’m mostly talking about people in that boat. I work on large, fragmented codebases with proper guidelines, and I still don’t even come close to exhausting my monthly allowance.
The funny thing is that my CLAUDE.md is… not small. It’s the opposite of a haiku. I know the best practices say to keep it lean, but actually even with a non optimal CLAUDE.md like I have, I’m way more than happy. I get to spend more time on the product and less on checking that we’re following the guidelines and so on. Maybe that’s costing me some tokens. I’m okay with that trade.
Hyper-optimization theatre aka 80/20 rule
So I wonder if we’re building a little industry around hyper-optimizations that nobody measured properly. Tweaking context windows feels productive. Writing the perfect skill pack feels productive. But setup time is still time. Sometimes I think we forget that the actual goal is building the product, not the toolchain.
If you’re building something real, the AI layer should be a bonus: helpful, invisible, cheap enough not to matter. Not a second job.
There’s an 80/20 thing here. We’re already in the fun part of the curve. AI already gave us a ridiculous multiplier on output.
At the end of the day it’s still revenue minus cost. If the tool costs more but the output is worth much more, maybe the more useful question isn’t “how do I spend fewer credits?” but “how can I spend credits in ways that let me build even better stuff?”
And if you really need to pick a direction, in my opinion you optimize for quality first and worry about saving later. Get the output right. Get the team speaking the same language. Get the thing shipped. Then look at what’s actually eating your credits, with real numbers in front of you, not a hot take from someone else’s setup.
So here’s my unpopular-ish take: use the tools, enjoy the boost, keep the setup good enough. Not perfect. Good enough. Then go build the thing people actually want. The credits will probably be fine. And if they’re not, that’s a budget conversation, not a reason to shrink your brain into a tweet-sized context window.