AI Is Easy. Adoption Is Tough.
Lessons on context, cost, and conflicting intelligence from our conversation with Ashish Kumar Jha in Hyderabad.
Open any AI assistant and look at the bottom of the screen. There's a small line telling you the AI can be wrong.
Most people stopped seeing it months ago. Ashish still reads it every time. "That grabs my attention," he told us, "because the superpower LLMs can also go wrong without context."
The tools have never been more capable. The output has never been easier to produce. And the gap between producing something and producing the right thing has never been wider.
The sprint got shorter. The requirements didn't get better.
A few months before we spoke, Ashish was scoping a new product idea. His engineer's instinct went straight to the SDLC (Software Development Life Cycle). Then, experimenting with Claude, he came across the idea of an AI development lifecycle, and his team decided to vibe code and see where it went.
Work that used to take 10 to 12 sprints landed in 2. Open APIs and MCP integrations meant the team could connect to multiple sources without months of plumbing. The long chain of BRDs and specification documents mostly disappeared.
That speed matters, especially in a GCC. Many Global Capability Centers in India serve customers on another continent, so the team building the product rarely sits next to the people using it. Faster shipping means faster feedback: you learn in two weeks, not twelve, whether something is spot on or rubbish.
But speed exposes a problem it doesn't solve. Most GCC work is transitioned in from somewhere else, and when work moves, knowledge gets lost. Some of it lives in Word files. Some lives in Excel. Some lives only in the heads of people who never moved. Ashish calls this the SOP (Standard Operating Procedure) problem: you're building without the full picture, at a pace that makes the missing picture easy to ignore.
His workaround is to use AI to probe for the missing context rather than to skip it. Building a dashboard fed by a CRM or a system of record? Prompt the model to act as the CFO and ask for the financial health of a line of business. Then step down a level to the operators who care less about the top and bottom line and more about running the floor. The result is a persona-level view of what each audience actually needs to see.
Why does context still beat speed?
Logan pushed on this. Before founding Datalogz, he worked on analytics at a large airline and spent hours interviewing stakeholders, like the flight attendant group, before he understood what they needed. Could he now just tell an AI to pretend to be the flight attendant manager and skip the interviews?
Ashish's answer was short: context is king. He has seen drift and hallucination when teams rely on AI alone. Hand the tools to an engineer, a business analyst, or a product manager, and they'll think about the problem in product and technical terms. That's useful, but it isn't the whole picture.
His example is invoice processing. A financial analyst looks at an invoice very differently from an engineer or a BA looking at the same invoice. Put that analyst in the squad and the product changes. Leave them out and you get what he calls "a very fancy product" with the context missing.
The cost of that gap isn't just rework. You fix it, fix it, and fix it again, and every round chips away at stakeholder trust. That's why Ashish keeps repeating a line he hears everywhere: AI is easy, adoption is tough. Adoption comes from trusting that the product does what the business really wants, and that trust is built by pulling the right people in from day one.
He saw the same thing in a classroom. On his Chief Data and AI Officer program at ISB in Hyderabad, his capstone team was asked to take a hypothetical company from $2 billion to $5 billion as a digital native. Each person prompted their way to a strategy. Six people got six different strategies, and the team couldn't reconcile them. Same tools, same brief, different prompts, different answers.
The lesson travels straight back to the office. If two people with the same question can get two answers, the problem isn't the model. It's the missing shared context underneath it.
The dead enterprise theory
Logan calls it the dead enterprise: so much vibe-coded, hallucinated, self-served material piles up that nobody can find what's actually worth trusting. In the analytics layer, he estimates that for every one thing that's accurate, there are probably ten that aren't.
This isn't hypothetical. Logan described a large CPG company that asked a simple question: how many ways do we track revenue for this one product line? The answer was 60 different versions. And with leaders now asking AI tools for derivative cuts on demand, five to ten new versions were appearing every week.
The irony is that the data literacy problem has largely been solved. Junior analysts and CFOs alike now work with data like they have a data science background. A dashboard that once took six months to build now takes an afternoon. But a world that used to align on a couple dozen metrics now has hundreds or thousands, and patience has gone with it. The CEO wants a number now, someone asks an AI tool, gets an answer, and the fire drill begins.
Ashish frames this as an awareness problem before it's a governance problem. Vibe coding, he says, is good for moving fast and testing hypotheses. Relying on it alone is dangerous because it doesn't scale. You can spend $15 on Bolt and get a beautiful UI, or $20 on n8n and wire up AI workflows in plain English. What gets forgotten is drift, failure points, and edge cases. Prototypes rarely consider edge cases, and that's exactly where products fail.
His fix is a mix: AI-assisted speed plus enough coding from scratch to keep basic standards in place, rather than pushing AI-written code straight to production.
Can AI be used, or should it be?
This is the line Ashish says he quotes everywhere. The question for leaders isn't whether AI can be used. It's whether it should be. Once the euphoria settles, every conversation turns to return on investment, and buying every shiny tool on the shelf doesn't survive that conversation.
He's seen small startups paying for Gemini, ChatGPT, and Claude at the same time. Someone has to pay that bill. "The token commerce is real," he said, "and people are realizing that now."
His rule of thumb is to match the tool to the problem:
- Simple, rule-based automation belongs in tools like n8n or Power Automate. Throwing agents at a primitive use case is waste.
- Reasoning work, the loops of if, else, and why, is where AI and agents earn their cost.
- Model choice should follow the task. You don't need the most powerful model to work out 2 + 2. Smaller models handle a lot of everyday analysis, and switching models by use case is a sign of maturity.
There's a hidden cost here too. When someone asks an AI assistant a question that requires querying legacy tables, Snowflake, or Databricks, the agent often takes many iterations to find the right source. Every one of those queries burns compute and tokens. Logan compared it to a cab driving block by block looking for an address, versus a map that takes you from point A to point B. Better context about where the right answer lives shortens the trip.
Ashish also noted that some SaaS providers are reshaping their commercials around this. Instead of charging $100,000 and passing token costs through, they'll charge $120,000 and absorb the token risk. For buyers, that predictability matters. You can't democratize AI and then control it with a stick: if users wait every day for their limits to reset, they lose interest. But you can't make it free for everyone either. Leaders need to negotiate in those terms, protecting their interests while still getting access to the best tools.
With intelligence comes conflict
Near the end, Ashish turned the question around. When intelligence comes from two or three sources at once, how do you manage the conflicts? User A says this metric is correct. User B says theirs is. Two people in the same department configure the same thing in completely different ways. Who wins, and how does anyone know?
Logan's view is that this is where the real risk sits. For plenty of exploratory analysis, a small disagreement doesn't matter. For numbers reported publicly, or in a regulated industry, they cannot be wrong and they cannot differ across the company. He described an exercise comparing customers' annual filings against the metrics in their analytics stack. No company had perfect alignment, and some had dozens of conflicting versions. Layer on who was viewing which version, from executives to managers to subject matter experts, and the picture gets worse: the company tells the market one number while every stakeholder inside looks at a different one.
This is also why both of them were skeptical of the usual fixes. Logan argued that semantic layers struggle because the business changes faster than the layer can be maintained; even a near-perfect one rarely covers more than a few golden metrics. Ashish added a practical constraint from regulated firms: many won't let smart tools write back to their databases at all and will want them operating at the presentation layer instead. The more interesting prize, in his view, is clean, deduplicated data at that layer that autonomous agents can trust enough to complete a transaction, such as a financial reconciliation.
That trust question connects to where GCCs are heading. Cost arbitrage is still the first reason work comes to India. But the smarter GCCs, Ashish says, are moving along a maturity curve from cost arbitrage to product development to value creation, and agentic AI is a key factor in that shift. Hyderabad's ecosystem helps: deep talent, close ties between academia and industry, and the chance to learn from each other's mistakes. As he put it, he's fine not being the first to do something, as long as he's the first to do it right.
Logan echoed this from the vendor side. Most first conversations with GCCs focus on cost savings: a million dollars here, ten million there, a smaller infrastructure or token bill. That's real value. But one CEO on the Datalogz advisory board put it bluntly: no decision gets him out of bed for less than $10 million. What moves leadership is better, aligned decisions across the business, not just a smaller bill.
The takeaway
Nothing in this conversation argues for slowing down. Ashish's 12-sprints-to-2 story is the opposite of caution. The argument is that speed without context produces work nobody trusts, and work nobody trusts never gets adopted.
That small line at the bottom of every AI chat, the one that says the AI can be wrong, isn't a disclaimer to scroll past. It's a reminder that the model brings the speed, and the business still has to bring the context.
Listen to the full conversation. This episode is the first in a series of Seize the Data conversations we recorded in Hyderabad on the sidelines of the Datalogz India roadshow. More are on the way.
Views shared by Ashish Kumar Jha are his own and not attributed to any organization. Connect with Ashish on LinkedIn.
Frequently Asked Questions
What is AIDLC, and how is it different from SDLC?
AIDLC, or the AI development lifecycle, is an approach to building software in which AI tools generate and iterate on much of the code, compressing work that once took many sprints into a few. Unlike a traditional SDLC, it relies less on long upfront documents such as BRDs and specifications. It still requires guardrails, scalability checks, and coding standards to be production-ready.
Why do AI-built products fail to get adopted?
The most common reason is missing business context. Products built only by engineers, analysts, or product managers often look polished but miss how the work is actually done. Each round of fixes erodes stakeholder trust, and adoption depends on that trust.
What is the dead enterprise theory?
The dead enterprise theory holds that vibe-coded, AI-generated, and self-served assets will accumulate faster than anyone can verify them, making it increasingly hard to tell which reports, metrics, and tools can be trusted.
How can enterprises control AI token costs?
Start by matching the tool to the task: use workflow automation for rule-based work, reserve agents for reasoning, and choose smaller models where they are sufficient. Reducing the number of query iterations an agent needs to find the right data source also cuts compute and token spend. Some organizations also negotiate commercial terms that make token costs predictable.
How are GCCs in India changing in the AI era?
Many Global Capability Centers began as cost arbitrage operations. More mature GCCs are moving toward product development and value creation, using agentic AI, local talent, and close academia and industry collaboration to deliver work that headquarters relies on rather than just work that costs less.