I've started to become skeptical of teams that talk almost too fluently about AI. Which might be strange to hear from someone in my line of work and focusing on the types of projects I build… but let me explain.
It’s nothing to do with whether I feel they do or don’t know what they’re talking about. In some cases they usually know more than I do about the technical details.
It feels more to do with a sense that fluency in a subject and making it operational can move in opposite directions. The more sophisticated someone’s understanding of AI capabilities, the less likely - in the day to day - they are to build something that actually gets used.
Sure, it’s not always the case. But with a barrier to entry so low, the probability is there.
And this bothers me because I used to think that knowledge was the constraint. That if people just understood what AI was in layman's terms and knew what it could do, they’d naturally figure out how to apply it.
But I’m seeing more cases of the opposite happen.
Those that are experimenting and learning on the fly - and actively building - are shipping stuff that’s good. It’s not sexy or brilliant, but it gets the job done. And then there are people who can explain larger architectures but we never see anything built.
And I think the difference here is being comfortable with simplicity.
When you get what AI can do, get a practical feel for understanding it, and see some output, simple solutions seem almost insulting. You hear of cases where someone spent an hour building a relatively simple AI agent workflow and selling it for far more than you’d expect and it feels wrong.
Why automate one manual process when you could redesign the entire system that it’s part of?!?
But then I have to think about what happens in reality. Complexity means you’re likely taking on expensive risks. Maintenance. Breaks. Explanations to others. And the biggest of them all - building something complex that’s for a complex problem that isn’t even a real problem in the first place.
Simple systems can be boring. But they work. And if they don’t, you know quickly (and at a lower cost).
A lot of this comes at a moment where I’ve been rethinking my own business model. Specifically, what is it that I do that brings me joy, can be sustainable for work, and can address a need in the market.
The answer is simple solutions that work fast and let teams get a grip on the potential around AI in ways that create ROI.
But simple solutions, in my mind, felt inadequate. Part of it was the intellectual challenge mentioned earlier.. if you know what’s out there, basic applications feel like you’re not using the tech properly. It’s too good to be true.
But I think something else is going on in those cases where we hear 90+% of AI implementations fail.
Sophistication and overcomplicating a solution give you permission to avoid the uncomfortable, difficult conversations.
This has happened now for years in SaaS (particularly in Product teams). And the same pattern is playing out with AI - the people and teams that get overwhelmed by the possibility of AI have yet to figure out what makes their business actually different from their competitors.
Simply put, they can't answer 'what are we uniquely good at?' with enough specificity to guide their AI decisions.
When you don’t know what you’re optimizing for, every AI capability looks equally promising. That’s what we’re being told from every vendor and the horizontal, flat, multi-vertical nature of AI makes it hard to go against. Every efficiency gain seems worth a test. Every integration feels like it “might be the game-changer.”
So you end up trying to build systems that do everything instead of systems that do one important thing really well.
It’s those that know that business clarity problem first that win. They know the constraints, the focus, the goals, and the distractions. They know what creates a competitive advantage and those that don’t. It becomes a literal filter for every investment decision.
Dare I say, they have a strategy.
Without that filter, technical sophistication becomes a way to avoid admitting you're not sure what you're trying to solve.
So instead of showing a bad example, here’s a good one from a team I talked to that’s approaching this well:
They’re a small team and are in an old-school space. They are battling lots of larger, more traditional, and well-respected competitors. Each - including themselves - has their unique toolkit: a product/service, a network, and a message.
But when I asked them about what is the one thing that’s going to help them outlast and win, they said their human-centered approach. Their communications are deeply empathetic, most of their time is spent talking to customers, and they have ambitions to be far more customer-centric in the future.
While this doesn’t scream like a fit for AI off the bat, their deeper reason for leaning into AI is a perfect use case. They want to find even more ways to amplify their unique, winning approach.
And not in the ways most would think.
Where some teams would use AI to replicate their communications at scale, they want to find other parts of their back office work to automate so they can spend more time on calls with customers. Where some teams would look for AI to identify and chase new leads and expand their base, they’re building products with AI to create deeper relationships with their existing customers.
Teams like them with clear business focus for AI describe what the tool will help them stop or start doing. Teams without that focus describe technical architecture - what models they’re using, how the agents interact, what the workflow looks like. And are probably explaining workflows that can be explained rather than starting with a real problem to solve and uncovering a solution as you go.
Technical architecture is much easier to discuss than business strategy. It feels concrete, more measurable, more like progress. I can go on about how much I enjoy using Claude Code, but without purpose behind it it’s just experimentation.
That’s ok in the space I’m in (and required at times). But for other teams it’s a cost.
So all of that is to say that this has made me reconsider how I think about AI expertise and how I defined it for myself. I used to assume that understanding all the bells and whistles and capabilities would naturally lead to better solutions (and help me be a better engineer).
But maybe the opposite is true. Maybe understanding capabilities makes it harder or more distracting to choose a capability that’s going to work.
The biggest constraint for most will be having business clarity of what actually matters and being able to say no to complex, sophisticated solutions when there’s a simple one right in front of you.
I believe this is why all these massive AI implementations aren’t going well, but the scrappy few that work for small teams do. The pressure to find something that works today is the constraint we all need to work in.
It now feels like the time we should start focusing on figuring out what AI should do for a specific situation, even when that means ignoring most of what it could do.
It’s a bit of a different kind of expertise. It’s not necessarily technical, but it makes it really clear what matters to your business and what’s going to get you the ROI we’ve been promised.
Maybe that’s why I’m getting suspicious of AI sophistication in some areas. Again, it’s not wrong, but it often finds itself solving the wrong problem.