I was sitting with Blake Eastman a few months ago, and I made a comment that surprised even me when I said it out loud.
“I really believe that people are now going a little bit too crazy on workflows and tools — and not actually getting any output.”
I'd been watching it for months. People in the AI space sharing their setups: MCPs stacked on top of each other, custom tool libraries, automations chained across six platforms. Beautiful, intricate systems. And I kept asking the same question: “What have you shipped recently?”
The answer was usually more workflow.
The Tool Collector Trap
There's a particular kind of activity that feels productive but isn't. You're making decisions. You're learning new systems. You're integrating things. It has the texture of work — it uses your brain, it takes time, it produces something you can show people.
But at the end of it, you haven't shipped anything. You've configured something.
Tool collecting in AI has become a version of this. Every new MCP is a small dopamine hit. Every integration feels like progress. Every new service added to the stack seems to expand what's possible. And technically, it does. But expanding what's possible and actually producing something are different activities, and they can crowd each other out.
The people who are most obsessive about their setups are often the people with the least to show for it.
What I Did About It
A few months ago, I ran an experiment on myself. I stripped everything down.
No MCPs. No third-party services layered on top. No custom tool configurations. Just native Claude Code, nothing else. And then I made a rule: I would add something back only when I hit a specific, real problem in actual work that genuinely required it.
Here's what I ended up keeping: Figma's MCP, which I use for front-end design work, and Playwright for browser automation when I'm building and testing interfaces. Two tools. Both kept because they solved concrete problems I ran into repeatedly in real projects, not because they seemed useful in theory.
Everything else stayed stripped.
What Happened
I shipped more in the three weeks after that than in the three months before.
Part of this is simple: removing friction. When you have fewer things to configure, you spend less time in configuration mode. You hit a problem and you solve it with what you have instead of thinking “maybe if I add X I could handle this better.” The constraint forces a different kind of thinking.
Part of it is also about clarity. A lean setup creates less noise. When something isn't working, there are fewer variables. You can see the problem more directly and fix it faster.
And part of it is just honesty. Stripping back forced me to admit that a lot of what I'd built was elaborate rather than effective.
The Distinction That Matters
I'm not arguing against using tools. I'm arguing for using them because you need them, not because they're interesting.
There's a concept I come back to — start small, iterate. The preferred path for building anything is small reliable wins first, then deeper complexity later. Most failures in AI systems happen not from lack of sophistication but from too much complexity too early, before you know what actually needs to be complex.
This applies directly to tool stacks. The right starting point isn't “build the best possible setup.” It's “what's the minimum I need to do the thing I'm trying to do?” Start from nothing. Add only when you hit a real wall.
This is harder than it sounds, because the instinct when building with AI is to reach for every available resource. More context is better. More tools unlock more. More integrations create more capability. And sometimes this is true. But more often, the simplest version that actually runs is more valuable than the sophisticated version that doesn't.
How to Apply This
The test I run now before adding anything to my stack:
1. Have I hit this problem before? Not “will I probably hit this problem someday” — have I actually hit it, recently, in real work?
2. Would native Claude not solve it? Most things that seem like they need a special tool can be handled with good prompting and clear context. If the native tool can do it, the native tool wins.
3. Is it going to stay useful? Tools have a habit of becoming liabilities. You add something because it's useful for one project, and then it clutters the stack for everything after. If I can't see myself using this in three different projects, it probably doesn't belong.
If something clears all three tests, I add it. Otherwise I keep looking for a way to solve the problem with what I already have.
The Bias That Actually Matters
The people doing the most interesting AI work right now are not the ones with the most sophisticated setups. They're the ones who have an overwhelming bias toward actually putting something out — even if it's rough, even if it's not optimized, even if the system behind it is janky.
Tool literacy matters. Knowing what's available, what different models are good at, when to reach for what — these are real skills.
But tool discipline matters more. The ability to resist adding complexity. The willingness to ship something imperfect. The habit of asking “what have I actually made?” instead of “what am I building toward?”
Start from nothing. Add only what you actually need.
And then show me what you've shipped.
I help founders and operators build AI systems that actually produce output — not just architecture diagrams and workflow screenshots. If you're building with AI and want a clearer path from setup to results, reach out or check out my AI consulting and workshop programs.
