You Don't Need More AI Tools. You Need an Opinion About AI.

I've watched a pattern repeat itself enough times that it's stopped surprising me. Someone gets serious about AI, starts paying attention, and within a few months they're juggling six tools, spending more time managing integrations than actually building, and quietly wondering why it still doesn't feel like they're ahead. Meanwhile, someone else on a smaller team with a narrower setup is shipping things faster and thinking more clearly. The difference isn't resources. It's not access. It's that the second person has an actual opinion about what AI is for in their work.

That opinion sounds simple. It isn't. Most people, if you ask them directly, will give you a general position on AI. They'll tell you it's important, that it's changing everything, that they're experimenting. That's not an opinion. That's a posture. An opinion is specific: this is what AI does well in my context, this is where I've built it into how I work, and this is what I've deliberately decided it won't do for me. That specificity changes everything about how you make decisions.

The Bookmark Problem, Revisited

There's a version of this I recognize from the early web. Browser bookmarks. Everyone had hundreds of them. Each one felt useful at the moment of saving. They pointed at genuinely interesting things. But they didn't form a system. They didn't connect. They just accumulated, and eventually the folder became so unwieldy that nobody looked at it anymore.

AI tool subscriptions are doing the same thing. Cursor for code. Perplexity for research. Claude for writing. ChatGPT because it's still the default. Notion AI because it's already where the docs live. Some specialized thing for images, another one for meetings, another one that someone in a Slack channel said was great. Each tool solves something locally. None of them form a system. The result is fragmented context, split attention, and a monthly bill that doesn't connect to any outcome you could actually measure.

The uncomfortable part is that this isn't ignorance. It's anxiety. Adding a new tool feels like staying current. It feels like you're not falling behind. It's the same psychological mechanism that makes you open Twitter when you're bored: not because you expect something valuable, but because the act of checking soothes something. Tool adoption without an opinion is just anxiety management dressed up as strategy.

What an Opinion Actually Does

A new model drops. A new tool goes viral on Hacker News. A newsletter you respect publishes a comparison of seven different options for the thing you vaguely feel like you should be doing better. Without an opinion, you have to evaluate all of it. Every release is potentially relevant. Every comparison is a decision you might need to make. You can spend an enormous amount of cognitive energy just staying oriented, and still feel like you're one announcement away from needing to reconfigure everything.

With an opinion, most of that resolves quickly. My setup is built around a specific thesis: AI in my work should reduce the time between a decision and the artifact that represents it. Code, copy, a structured analysis, a draft specification. The thing I actually need to hand off or ship. If a new tool doesn't shorten that path in a way my current setup doesn't already, it's not relevant to me right now. That's not closed-mindedness. That's a filter. And having a filter is what makes it possible to keep moving instead of constantly re-evaluating.

I run a multi-agent system in production. The opinion I have about AI is literally encoded in how that system is structured: which tasks get routed to which models, what context travels with a request, where human review sits in the loop. None of that infrastructure exists because I evaluated everything available and picked the best combination. It exists because I had a thesis, made decisions from it, and built something that reflects those decisions. The thesis came first. The tooling followed.

Three Questions Before You Add Anything

I've settled on a short filter I run before adopting anything new. Not a formal process, not a scoring rubric. Three questions, asked honestly.

The first: does my current setup already do this, just less conveniently? Most of the gaps people feel when they look at a new tool aren't actually gaps in capability. They're friction points in tools they already have. Something that takes four steps could take two with a better prompt or a custom instruction. A workflow that feels slow could be streamlined without adding a new surface. The new tool looks like a solution because it's optimized to look like a solution. But a new tool doesn't fix friction; it adds a new surface to manage, one that you'll need to maintain, keep context in, and integrate with everything else.

The second: can I get this capability with a small extension to what I already use? A skill. An MCP server. A custom instruction set. A project with the right files and context already loaded. Most people never stop to ask this question. They go straight from "this looks useful" to "new account, new subscription," skipping the step where they check whether their existing setup is one configuration away from doing the same thing. The answer is more often yes than people expect, especially if you're already using a capable foundation model. The incrementally better specialized tool frequently isn't worth the context switch.

The third, and this is the one that cuts deepest: do I have a clear job-to-be-done for it, or am I just keeping up? "I want to stay current" is not a job-to-be-done. "This seems like it'll be important" is not a job-to-be-done. If you can't name the specific recurring task this tool will own, the concrete thing it will do on a regular basis that you currently do some other way, you don't have a use case. You have FOMO dressed up as evaluation.

The person who can run through all three and still justify the new tool? They have an opinion. They know what they're solving for. They're making a real decision. Everyone else is collecting.

What an Opinion Looks Like in Practice

I want to be precise about what I mean by "an opinion," because it's easy to hear this and think it means having a general stance, being pro-AI or skeptical-AI or thoughtfully-balanced-AI. That's not it.

An opinion about AI is a specific claim about what AI is for in your work. Not in general. In your specific work, given what you actually do and what slows you down and what you're trying to produce. It's something you could write in two sentences that a colleague could read and understand immediately. Something concrete enough that you could look at any new tool and know within a few minutes whether it fits.

For some people that opinion is: AI is for first drafts. I use it to get something on the page fast, then I own the refinement. That's a real opinion. It tells you exactly which tools matter and which don't. For someone else it might be: AI is for staying close to documentation and API references so I stop context-switching to a browser while I'm coding. Also a real opinion. For someone else: AI handles the structured extraction work I used to spend hours on, the kind of thing where the logic is clear but the execution is tedious. Real opinion.

What all of these have in common is specificity. They identify a real thing that happens in someone's actual work. They're not aspirational. They're not broad. They connect directly to a recurring problem and a recurring outcome. You can test whether a given tool serves that opinion or doesn't. That testability is the point.

Notice what these opinions don't include: a list of all the things AI might be useful for. A commitment to explore every capability. An intention to stay current across the full range of what's available. That's not an opinion. That's a way of avoiding one.

Your Opinion Is Your System

There's a version of "getting good at AI" that looks like accumulation: more tools, more prompts saved somewhere, more integrations running in the background, more capability theoretically available. I've seen smart people spend a year doing this and end up slower than when they started, because maintaining all of it became its own job.

The people I watch who are actually effective aren't minimalists. They're not making a principled statement about doing more with less. They've just done the harder work of forming a view, and their setup reflects that view directly. When something new comes out, they don't have to spend much time on it. They know whether it fits. If it does, they add it. If it doesn't, they note it and move on.

Without an opinion, you're not evaluating tools. You're reacting to them. Every announcement is a small emergency, every comparison thread is homework, every gap in your setup is a potential new subscription. The tools don't become a system because there's no organizing principle asking them to. They just stack up next to each other, each one doing its small useful thing, none of them adding up to leverage.

Form the opinion first. Write it down in two sentences. Be specific enough that you could use it to say no to something. Then build toward it. The tools are fine. There are plenty of good ones. But good tools in the absence of a thesis are just an expensive way to feel busy.