Ankit Agrawal, Chief Technology Officer for Equifax's USIS business.
getty
Let me tell you how most AI adoption goes inside a large enterprise. Someone buys the tools. The teams start using them. Velocity goes up, at least on paper. Six months later, leadership is asking why the ROI isn't showing up in the numbers, and the engineering org is even more stressed than before.
I've lived that. We lived that.
I run a technology organization for a $2 billion business, and we made every version of this mistake before we figured out what was truly going on. And what was going on had nothing to do with the technology. The models work. The tools are genuinely capable. The problem was that we kept trying to fit AI into an operating model that was designed for a completely different set of constraints.
And we're hardly alone in this. I've been following the research closely, and the numbers are pretty sobering. MIT researchers studied enterprise AI deployments and found that the vast majority of pilots moved the needle on exactly nothing when it came to actual business outcomes. I'm not talking about underperforming—I mean nothing. Around the same time, S&P Global found that nearly half of the companies had walked away from most of their AI initiatives. I'd bet most of those weren't killed because the technology failed. They were killed because the organization around the technology never changed, and eventually, someone did the math.
For a long time, the whole game in engineering was throughput. Can we build it, and how fast? That was the question everything else got organized around. And then, almost overnight, that stopped being the hard part. The engineers I have who use these tools well are producing at a pace that would have seemed unrealistic three years ago. That's not an exaggeration.
So, you'd think that's just good news. It's not that simple.
Because above that, there's a review process, an approval chain, a risk function and a release process. None of that got faster. None of that was designed for the scale that AI enables. So, what actually happened in our organization, and I suspect in a lot of them, is that the output flooding in just backed up somewhere else. More pull requests are sitting in review. More changes are going out with less scrutiny than they deserve. There are more incidents and more rework.
We had strong adoption numbers but declining confidence in what we were shipping. That took us longer to admit than I'd like.
The fix wasn't a better tool. It was rebuilding how work moves.
What we built was basically a pipeline where the agents do the heavy lifting: scoping, writing code, running tests and deploying to pre-production. By the time one of my engineers looks at it, most of the work is already done. Their job at that point is just to make a call. Does this make sense? Does it fit what we've built? Are we comfortable shipping it? This sounds simple, but it's a pretty significant shift in how engineers think about their role.
Some people adapted to it faster than others. The engineers who struggled were the ones who'd always processed ambiguity themselves as part of the job, because the other thing we learned is that AI doesn't handle ambiguity gracefully. A vague ticket from a human yields a confident, well-structured and completely wrong response from an agent. Garbage in has always meant garbage out, but AI makes it faster and more expensive.
Nobody warned us that the most important work would be the most boring work. Getting requirements tight enough that an agent doesn't go sideways with them isn't in any implementation guide. We figured it out after a few expensive mistakes in which the output looked completely reasonable but was completely wrong. An agent doesn't pause and ask for clarification. It just builds whatever it interprets.
Ops was the part we got wrong for a long time. We had solid support engineers and SREs who knew the systems inside out. We confused that with having a real process. Those are very different things, and you don't find out which one you really have until something breaks when the people who usually fix it aren't around.
I have some version of this conversation probably twice a month. A rollout looked great in the pilot, but during scale-up, it got messy, and nobody could quite explain why. It's almost never the technology. The organization just kept running the same playbook and expected different output.
Before you buy or build anything new, spend an afternoon mapping how work moves through your organization. We'd never written that down anywhere. That kind of thing matters more than which model you pick.
I've watched a lot of these rollouts now, and the teams getting real results weren't doing anything exotic on the technology side. They just knew their own organization well enough to know where things would break before they broke. Everyone else found out the hard way, usually six months in, usually expensive.
The ones struggling are still buying tools, hoping the organization figures itself out around them. It won't. In my experience, the technology is almost never what fails. It's everything that technology exposed that was already broken, and nobody had gotten around to fixing.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。