What to ask instead to get better outcomes
A few years ago, when enterprise organizations approached a software challenge, the question was "What are we trying to build?" Now it's "How are we using AI?"
This reflects a larger trend, with global corporate investment in AI soaring past $250B in 2024 alone. In fact, global AI spending is forecast to exceed $2T this year. Amid what feels like a gold rush, enterprise leaders don't want to miss the moment.
Project roadmaps get reshuffled. RFPs start including AI requirements by default. And the processes by which companies evaluate their needs, including potential developer shops, shift. They start asking the wrong questions, which can set them off on the wrong course from the jump.
In this article, we explore what AI is good at, what questions companies get in trouble by asking, and what better questions they can ask to drive the outcomes they need.
The "AI-first" trap
"AI-first" is typically thought of as a strategy, but viewed through a different lens, it's actually a constraint.
It narrows the solution space before the problem is fully understood. And once that happens, every decision that follows is shaped around justifying the premise instead of challenging it. This is a signal that teams are starting with the solution instead of the problem.
Not every problem needs AI. Not every solution is AI. But in the current hype cycle, there's a pattern of misapprehension steering project development.
Picture this: A client approaches a development partner having already defined what they believe to be the solution. "We need AI," they say. "Specifically, we need THIS KIND of AI."
The development partner says yes, and work begins. But the foundation is already shaky, because this approach assumes that the problem actually requires AI, AND that AI is an inherent upgrade over other solutions.
In reality, neither is guaranteed, and failing to interrogate that position is partly to blame for the fact that somewhere north of 80% of AI projects fail. Business leaders think the problem to be solved is adding AI. In reality, it may have been a solution in search of a problem.
Making a user-centric product means identifying specific features that need improvement, and then evaluating the best approach to do so—which may or may not involve AI.
Instead of asking:
- Should we use AI?
- Can this feature use AI?
- Can this partner build AI?
You should ask:
What feature(s) make our product better for our users?
What AI is actually doing under the hood
Part of the issue is definitional.
Right now, "AI" is doing too much work as a concept. It's used to refer to everything from basic automation to complex machine learning systems. Those are very much not the same thing.
Automation has existed for decades. Think: rules-based systems, deterministic workflows, structured pipelines. These are, generally, reliable and scalable.
There's a common misconception that AI is a universal upgrade; a kind of "improvement layer". This is, of course, a damning oversimplification that can have real consequences.
Implementing AI isn't like upgrading your CPU; it doesn't translate to immediate, measurable performance improvements across the board. But it IS very good at specific types of problems.
At a high level, AI systems have advantages when the task involves:
- Parsing unstructured data (text, images, messy inputs)
- Pattern recognition across variation
- Probabilistic judgment rather than certainty
One way to think about it: AI is good at approximating. It doesn't "know" things in a deterministic sense. It recognizes patterns across large volumes of data and makes probabilistic judgments based on those patterns.
If you ask a traditional system to identify a picture of a cat, it relies on rigid logic. Unless a programmer has written a specific rule for that exact angle, lighting, and pose, the system will likely fail.
AI works differently. It learns what a "cat" looks like across thousands of variations—angles, sizes, lighting—and can make a reasonable guess when it sees a new one.
AI systems, especially those built on large-scale machine learning, are powerful specifically because they approximate. They don't "know" things in a deterministic sense. They recognize patterns across large volumes of data and make probabilistic judgments based on those patterns.
That ability to generalize is what makes AI both powerful and unprecedented, but it's also what makes it risky in the wrong context. Jamming it into your workflow can result in problems that are fundamentally deterministic being reframed as probabilistic ones. Systems that require precision get layered with tools that introduce variability. The result is greater complexity at the cost of reliability.
If your system needs to produce a consistent, verifiable output every time, approximation is a liability.
Instead of asking:
"Is our technology the latest and/or greatest thing?"
You should ask:
"Is the technology solving the right problem?"
What does AI really cost?
Even when AI does improve a system, many companies make the mistake of underestimating the actual cost. Not just the upfront costs to stand up a solution, but the ongoing structural costs.
Most companies aren't building AI from scratch. They're integrating with third-party models. Which means they're effectively building a house on rented land. There's nothing inherently wrong with this approach. Using third-party technology is a tried and true way to leverage specific capabilities without the need to develop them yourself, but it comes with certain risks.
With AI in particular, pricing volatility should be a real concern. Most models already have baked-in usage pricing (tokens, API calls, rate limits). Beyond that, however, is the fact that many AI providers are currently operating at a loss as they attempt to grow capabilities and market share. It's reasonable to expect pricing models to shift as the market matures.
Pricing volatility in AI models isn't the only cost, however. There's also operational volatility. AI models are subject to change over time. Behavior can change, or they can be outright deprecated.
The system that works reliably today will NOT do so in the future—at least not without intentional maintenance on your end.
Is this kind of ongoing, proactive maintenance doable? Most definitely. But it requires an investment of time and money.
Instead of asking:
"Can AI improve this product/system/output?"
You should ask:
"Is the improvement worth the long-term costs and complexity, and are we prepared to make that investment?"
A lot of AI problems are actually data problems
Organizations often fall into the trap of trying to implement AI before they're ready. Not just conceptually, but structurally, as it relates to data. Crucially, AI is only as good as the data it receives.
Good outputs require good inputs. Yet, in the rush to "do AI," many companies jump in before their data is clean, structured, or even accessible. Without that foundation, even the best models will produce inconsistent or low-quality results, which is partially why so many AI projects get shut down.
Data readiness is a prerequisite for any scalable, sustainable AI project. And although it's a separate undertaking, a good development partner will not only flag the need for data preparation, they can help you design a plan to achieve it.
Instead of asking:
- What data do we want to process?
- What data do we want to output?
You should ask:
- Do we have usable data?
- Is it structured in a way that supports this use case?
- Can we reliably access and maintain it?
AI works best as part of a system
A true development partner will help you build systems, not features.The most effective implementations of AI don't treat it as a standalone capability, they treat it as a component.
Such a system might use AI to:
- Interpret unstructured inputs
- Classify or summarize information
- Generate a first pass of content
But that output is then:
- Validated by deterministic logic
- Constrained by rules-based systems
- Fed into more traditional processing layers (e.g., humans)
AI is great at processing large volumes of ambiguity. When AI is given too much unchecked responsibility, however, the system becomes harder to test and harder to trust. It doesn't have taste, context, or discernment. For this, we need good old human insight. Choreographing the interplay between human intelligence and AI is what we call Collective Intelligence, looping human intuition with machine synthesis. This is how to turn AI into an engine for better decisions and faster outcomes.
That balance is what makes the whole thing work.
The most effective human–machine systems prioritize real-world problem-solving over the reactive impulse to adopt AI simply because it is accessible and trending.
Instead of asking:
"What systems can we accelerate with AI?"
You should ask:
"What systems do we need to put in place to effectively harness AI capabilities?"
The difference between a vendor and a partner
This is where the role of a development partner becomes critical. If you approach a developer asking for AI and the answer is always "YES", you're not getting advice, you're just getting execution.
A vendor may simply build what you ask for, no questions asked. A partner, on the other hand, will explore, question, and push back, because they're trying to find the right solution to your problem. You want a partner who will pressure test your idea, and bring their experience and expertise to bear to figure out how to help you meet your goals, possibly even in ways you hadn't predicted.
And sometimes, the outcome of that process is not a better AI solution – it could even be a no-AI solution.
Instead of asking:
"What do you want and what's your budget?"
Your development partner should ask:
- What problem are we actually solving?
- Where does this break?
- What happens when this scales?
- What does this cost six months from now?
Conclusion
The rush toward AI isn't itself a problem, it's the misalignment that can grow out of it. When organizations start by asking "How do we use AI?" instead of "What are we trying to solve?", they trade clarity for momentum and often end up with systems that are more complex, less reliable, and harder to sustain.
The companies seeing real value aren't treating AI as a shortcut or a signal of innovation. They're treating it as one component in a broader system that still depends on structured logic, clean data, and human judgment. In that sense, the real shift isn't technological, it's operational. Success with AI requires better questions, stronger foundations, and partners willing to challenge assumptions.