Technology Is Solved. What’s Left Is the Business.
Why the real bottleneck in AI transformation isn’t code, but understanding the work
For the past two years, wherever I go, I run into the same question: “AI is amazing, we’re all convinced. But where exactly are we going to use it?”
The question already contains its own answer. Nobody has doubts about the technology anymore. The doubt is about where the technology actually touches the business.
Here’s what I believe: AI is largely taking care of the technology side. What remains, and what is genuinely hard, is getting a grip on the business side.
Technology can be formulated. Business can’t, at least not yet.
Technology is a domain you can describe with math. Its inputs, outputs and rules are well defined. That’s exactly why it’s where AI has advanced fastest. Today, the cost of digitizing something has dropped to nearly zero. Work we used to debate (“Are we really going to write code for this? Is it worth it?”) can now be stood up in a few hours with coding agents.
The business side isn’t like that yet. What is a company’s value proposition? Where does it actually make money? In which process does its profitability quietly erode? Which task is the chronic pain everyone has shrugged off for years with “that’s just how it’s always been”? None of this has been reduced to a formula. It lives in people’s heads, in their habits, in unwritten rules.
The biggest gap I see in the field today is right here. On one side, there are AI people who think “IT only.” On the other, there’s a business asking, “What can we do with AI?” The gap between them is enormous, and technology isn’t what closes it.
75% digitalization, 25% agents
Treating digitalization and agentic transformation as two separate things feels wrong to me. They’re really chapters of the same story.
I’ve been in this industry for thirty years. When I started, we were moving bank accounts that lived on paper onto mainframes. Ever since, we’ve been doing the same thing: we can digitize this part, and we can digitize that part. But we can’t connect the two. Getting from one island to the next was done by hand, practically with a shovel, because that crossing required interpretation, judgment, a decision.
This is where agents make the real difference. When we take a process end to end today, maybe 75% of the work is still classic digitalization. But without agents in the remaining 25%, we can’t glue the pieces together. Agents are the glue of the process. They take over exactly those transitions that require interpretation and judgment, the ones where we used to ask, “How on earth do we explain this to code?” More precisely, they take over as much autonomy as we’re ready to hand them. So the real question isn’t “What can an agent do?” but “How much are we willing to let go of?” And that’s not a technical decision. It’s entirely a business decision.
Which is why I’ll say this plainly: if you don’t need AI, don’t use it. If you can solve something with a formula, why have AI do it? It’s both more expensive and more fragile. AI isn’t a fetish. It’s one of the tools in the toolbox (and yes, one of the most important ones).
When gravity disappears, you can’t keep the same design
When building something becomes this cheap, the question changes too. It’s no longer “How do we digitize the existing process?” but “How should this work actually function?”
I explain this with gravity. Any design you make while gravity exists is shaped by gravity. Stairs, load-bearing columns, cables: they’re all there because of it. If gravity disappears and you keep building the same building, all you’ve done is mechanize old constraints.
The cost of writing code, of integration, of answering “Who’s going to build this?” was our gravity. And it’s going away. That’s why we need to go beyond digitizing what exists and move toward zero-based design.
There’s a side effect, too: the word “tailor-made” has lost its meaning. CRM tools, for instance, are among the first casualties (RIP). Small needs that nobody would ever have considered building something custom for can now be solved without a second thought. The time you lose bending yourself to an off-the-shelf solution that doesn’t fit you is far more expensive than having it built your way in half a day. Tailor-made shouldn’t be the exception anymore. It should be the default.
The pain point you’re told is probably wrong
When we go to a client and ask, “What’s your problem?”, the pain point we hear turns out to be wrong, in my experience, about 90% of the time. Nobody is misleading us on purpose. But people often don’t even notice where they lose the most time, because the work has always been done that way and they were born into that process.
The classic request: “Summarize my emails every morning and send me a report.” The human brain could scan and filter fifty emails in forty seconds. Now you’ve created report-reading time on top of that. And then the second round begins: “Wait, what did they say? Let me go back to the email.” Far from creating value, it’s outright harmful.
This is where you need to act a bit like a good educator. A good educator doesn’t do exactly what the child says. They read the real need behind the words. We, too, are more curious about what clients don’t tell us than what they do. The things they accept “by default,” the things they no longer notice, the invisible costs everyone owns but no one measures. That’s where the real transformation lies.
There’s another trap: building function-based solutions around a single department’s request. The moment you optimize one piece of a process and lose sight of the end-to-end picture, the people inside that process start getting thrown around. You end up with something that automates unrelated parts, adds intelligence, and accomplishes nothing. That’s why you need to start with a small but end-to-end slice and, within a few weeks, put something tangible in the team’s hands that they can play with.
This also breaks down the biggest source of resistance to transformation: fear of the unknown. The moment people see not that their jobs are being taken away, but that something making their daily lives harder has been solved, their attitude changes.
Why FDE is a bigger deal than its hype
It’s no coincidence that the Forward Deployed Engineer concept has been talked about so much lately. No matter how powerful a technology is, as long as it doesn’t reach the field, it stays a hobby. That’s why the big players are turning toward teams that can carry technology into the field.
But there’s a critical nuance: an FDE’s center of gravity should be in business, not technology. AI is already taking care of most of the technology. Walk into an organization with a purely software-engineering mindset and you’ll see a machine. But what’s actually there is an organism. You need a profile that can read that organism and, when needed, ask a different question from the one you were asked.
And that only happens by staying in the field. Engineers spending hours on-site with the client isn’t a common practice in traditional consulting. Yes, some of that time may be wasted. But the rest is valuable in a way you can’t get any other way. Especially the unguarded stories you hear over a coffee break together, which can sometimes teach you more than an entire meeting.
What we need are people who can connect these two worlds. Connecting the digital world to real life. I think that has been the real story of the past two years, and perhaps of the years ahead.
In short: the problem isn’t technology. Technology was always there, and now it’s practically free. As long as we don’t understand the business, as long as we can’t interpret it on their behalf better than they can themselves, what we do will remain old work with an “AI” label on it.
Comment(s)