A couple of years ago, I wrote an article about leadership and opened it by admitting that nobody needs another one about leadership. I am going to do the same thing here, except the odds are worse. There is roughly one article about AI published every time you blink, and a meaningful percentage of them are written from the perspective of people building or selling AI. Last week, I had to explain to engineers what AI actually means for their jobs. Preparing for it is what made me write this, because two numbers came up while I was checking my own assumptions, and I have not seen anyone put them next to each other.
The first one was about what happens to engineering work when AI doesn’t just assist with code, but produces it.
The second was about something much bigger: why some companies are getting real business value from AI while most are still struggling to show it.
I will get to both. No new framework, no five pillars, no maturity model. But first I want to start somewhere less comfortable, because everything else follows from it.
The cost
Every tool we had before this one helped us write code. Compilers, IDEs, frameworks, the cloud. They all supported the act of producing the work. AI Coding tools produce it. That is not a faster tool, it is a different kind of tool, and the daily consequence is that a lot of engineers now spend their time reading instead of writing.
You open a pull request and there are four hundred lines you did not write, and you are the first human being to look at them. You send a prompt, you go back to a review, you return to the agent, you read what it produced, you tell it what you do not like, you go back to the review. Meanwhile, you still do everything you did before: the meetings, the questions from your colleagues, the client on Slack. The work hasn’t disappeared. It has changed shape.
Faros measured this across two years of telemetry from 22,000 developers and more than 4,000 teams. Median time in code review is up 441% between each organisation’s lowest and highest AI adoption periods. That is not a rounding error. That is a different job.
And then there is the part that is harder to say out loud. Most of us chose this work because writing code is satisfying. That is the part that got automated first. This is not an argument against the tools. It is an argument for saying it out loud, because the alternative is a room full of people who privately believe they have become slower or worse at their job, when what actually happened is that the work changed shape underneath them, everywhere, at the same time.
The gap
The gap isn’t between companies that use AI and companies that don’t. It’s between companies that use AI as a tool and companies that redesign how work gets done around it.
Stack Overflow surveyed 33,000 developers. 78% use AI tools. 3% highly trust what comes out of them. Widen the scale and it does not get better: 46% actively distrust the output, against 33% who trust it at all. Counting those who plan to adopt as well, that figure has gone from 76% to 84% in a year. Sentiment went the other way, from above 70% positive in 2023 and 2024 down to 60% last year. More people using them, fewer people happy about it, and nobody seems especially alarmed.
The second number is the same shape one level higher. McKinsey surveyed 1,700 executives across 97 countries in May and June. 89% of companies use AI somewhere in the business. 37% can point to any effect at all on profit. 6% attribute more than five percent of profit to it.
89%, 37%, 6%. Before anyone tells me their sales funnel looks worse, mine does too. But a sales funnel is full of people who have not committed to anything yet. Every company in that 89% has already adopted AI and is running it in the business. The narrowing happens after the decision, not before it.
And what separates the 6% from everyone else is not what you would expect. Nearly three-quarters of them fundamentally redesigned how the work gets done. About a quarter of everyone else did. Not better models. Not more licences. They rebuilt the process around what the tool is actually good at. Put that next to the first number: 441% is what happens when the tool lands in the process you already have. Which means the thing standing between an enterprise and a return is not technology. It is somebody who understands the business well enough to redesign it, and understands the tool well enough to know what to redesign it around. That person is rare. That is the whole story.
The role
The market already has a name for that person. Forward Deployed Engineer. And it is not a new name. Palantir popularised it, under their own variant of the title, Forward Deployed Software Engineer. Here is how they described the role on their own engineering blog in 2020: a software engineer who embeds directly with customers to configure the platform against their hardest problems. Not somebody who hands over a plan. Somebody who ships inside somebody else’s system. The practice is older than the title, and considerably older than AI. Anyone who has worked in software services for a decade has been doing a version of it the whole time.
What is new is the rush. In the same week in May, Anthropic and OpenAI each announced a separate company dedicated to implementation. Anthropic’s, announced on the fourth with Blackstone, Hellman and Friedman, and Goldman Sachs, launched in July as Ode. OpenAI’s came a week later as the Deployment Company, and bought Tomoro for its first 150 forward-deployed engineers rather than wait to hire. In June, AWS announced its own forward-deployed engineering organisation to embed thousands of engineers with customers.
These are companies that sell access to models. Nobody has more reason to tell you the model is what matters. All three are instead building organisations of people who sit inside somebody else’s business. To be clear about what I am not saying: building these models is extraordinarily hard, and nothing I do comes close to it. But it is a different hard problem from making one of them useful inside a particular company, with its data, its processes and its people. The industry has spent years discussing the first problem. The companies closest to it are investing in the second.
If you work in software services, embedded in a client’s systems, in their standups, under their security boundaries, in a relationship that has lasted years, you already have the part that cannot be bought or taught quickly. You are in the room.
What is missing is two things, and only one of them is a course. The AI half is learnable, and there are structured paths for it now. The other half is harder: knowing the client’s business well enough to have an opinion about what should be redesigned, rather than about how to build what you were asked for. Being in the room is not the same as understanding how the company makes money.
And the order matters. The AI half without the business half just ships faster code that nobody asked for.
So what?
I promised no framework and I intend to keep that promise, but I do want to leave three things.
If you are the one funding this: the 6% is the number I would want on my desk. What separates them is not which model they picked, it is that they changed how the work gets done. That has changed the question I ask my own teams, from “which tools do we need” to “what are we actually going to do differently”. It also changes the method and the timeline. You cannot plan a redesign of how work happens the way you plan a rollout. You find it by running a lot of small experiments on real work, which means disrupting things that currently function and waiting longer than anyone would like to see it in the numbers. Some of the experiments will not hold. That is the cost of the approach, and it is worth budgeting for alongside the licences. Each experiment needs to say what it is supposed to change before it starts. Otherwise you cannot tell a failed experiment from a wasted quarter.
If you write code for a living, the scarce skill just changed: Generating code became cheap, but checking and knowing whether it had the expected impact did not. When one half of the job becomes nearly free, the value moves to the half that did not. That half is judgment about whether what we are building is right for this user, right for this business, worth what it costs to run and maintain. Something that works perfectly and nobody needs is still waste, and the model will build it just as fast as the thing that mattered. Of course, getting genuinely good at these tools is not optional. They are part of the craft now, and using them casually is not the same skill as using them well. That part is assumed from here on.
And if you lead engineers, mostly what you owe them is honesty about the trade. The tools are genuinely good. The work genuinely got heavier in places. Both are true at the same time, and only the first one shows up in the metrics. What does not help is asking people to try harder. Effort is not the variable. Everyone is already working hard, and the 6% spent theirs redesigning the work rather than producing more of it. The other thing we owe them is access. The business understanding this whole article is asking for is not learned from a course, it is learned by sitting in the conversations where the client says what is worrying them this quarter, and those conversations are ours to open. If somebody has never been in one, it is not fair to expect them to have an opinion about what should be redesigned. That costs nothing to give and it is available immediately.
Anyway. That is my contribution to the never-ending stream. Back to the meetings, which nobody has offered to automate yet.
