A client of mine, a services company of around 100 people, told me in our first session that they were “quite advanced” with AI. They had bought about 30 licences: marketing, developers, designers.
So I asked what they had connected.
One MCP connector. Their ticketing system. That was all of it.
They weren’t bluffing. From the inside it looked like real progress: a year earlier they had nothing, and now their support team could ask questions about tickets in plain English. But a single connector is a demo. The whole point of MCP is that you can put a model in front of your CRM and your ticketing system and your data warehouse at the same time, and ask a question that none of those three systems can answer on its own. One connector just gives you a nicer search box.
That meeting is why I now start every engagement by mapping where people actually are. Not because a score matters. Because the conversation before the score is the same conversation every time, and it is always wrong in a direction the company cannot see from where it is standing.
Every organisation is climbing two different ladders at once, and almost nobody looks at both.
The first is the leadership ladder. When I sit down with a CTO or a CEO, I check five things, roughly in this order:
Your own use. Do you personally use AI for real work, every day, on things that matter? Not summarising a PDF. Actual work you’d otherwise have done yourself.
Autonomy. Can you hand over a whole task and get it back finished? Or does every interaction end with you doing the last 40%?
Integration. Is any of this connected to your data and your systems, or does it live in a browser tab where you paste things in by hand?
Adoption. How many people in the company work this way, and in which functions? Engineering only is a very common and very bad answer.
Competitive position. Against the companies you lose deals to, are you ahead or behind? And what is that judgement actually based on?
Question one is the one leaders skip. A CTO who does not use this stuff daily cannot evaluate a proposal about it, cannot spot when a team is bluffing, and cannot tell the difference between a real constraint and a comfortable excuse.
The second is the practitioner ladder, and here I don’t need my own version, because Steve Yegge already wrote the best one in Welcome to Gas Town. His eight stages, compressed:
Zero or near-zero AI. Code completion, the occasional chat question.
Coding agent in the IDE, permissions on. It asks before it does anything.
Agent in the IDE, YOLO mode. Permissions off. Trust has gone up.
Wide agent in the IDE. It fills the screen. You look at the diff, not the code.
Command line, single agent, YOLO. Diffs scroll past. You may or may not read them.
Command line, multiple agents, YOLO. Three to five in parallel. You are fast now.
Ten or more agents, hand-managed. You are at the limit of what a human can coordinate by hand.
You build your own orchestrator.
I find these ladders useful together because they measure different things. The leadership ladder measures the organisation. Yegge’s measures one person’s practice. A CEO at leadership level four with an engineering team sitting at stage two is a company that will buy a lot of licences and get almost nothing back.
Here is the part that makes this hard to fix.
If everyone over-estimated themselves, you could just apply a discount. But the misjudgement runs in both directions at once, and it runs in opposite directions inside the same building.
The C-levels I talk to are usually closer to right than their own engineers. That sounds like a compliment and it isn’t. They are closer to right by accident. Their sense of being behind comes from a competitor’s launch post, from something a peer said over dinner, from the general noise. It is FOMO, not measurement. Ask which number told them, and there is no number.
And on the detail that actually determines what to do about it, they are almost always wrong. When a leadership team tells me they’re slow, they point at engineering: code output, ship rate, sprint velocity. Nine times out of ten the delay isn’t there. It’s in the decision process. The two weeks between a proposal and an answer. The meeting that needs three people who are never free in the same week. The approval nobody is willing to give alone. You can double the rate at which your company writes code and move your launch date by zero, because writing the code was never the constraint.
Their technical teams do the opposite. They are, on average, further from the frontier than they believe. Not because they’re lazy. Because the frontier moved and nothing in their week forced them to notice. Ask a senior engineer who is confident about AI whether they have ever built a RAG system over the company’s own documentation. Whether they routinely test the same task across three different models. Whether they’ve written a custom skill, rather than pasting the same three paragraphs into a chat box for the fifth month running. In small and mid-size companies, the answer to all three is usually no. Meanwhile a handful of them will have fine-tuned an open-source model on a laptop, which is genuinely harder and almost never the thing the business needed.
There’s a study I keep coming back to on this. METR ran a proper randomised controlled trial in 2025: sixteen experienced open-source developers, 246 real issues in their own repositories, randomly assigned to allow or forbid AI tools. The developers expected AI to make them about 24% faster. Afterwards, they reported it had made them about 20% faster. Measured, they were 19% slower.
Read that again as a leader, not as an engineer. It isn’t a story about AI being useless. It’s a story about a group of highly competent people being wrong about their own throughput by roughly forty percentage points, in real time, on their own code. If they can’t self-assess, your quarterly survey asking “how much is AI helping you?” is measuring mood.
So you get the standard scaleup configuration: executives pushing hard because they feel behind, engineers pushing back because they feel fine, and neither side holding the evidence to settle it.
Back to the services company, because their gap is the most common one I see, and it’s specific enough to be fixable.
Three things separate a company that uses AI from a company that has integrated it:
More than one system in the same question. Value comes from crossing sources. Support tickets against deployment history. Ad spend against activation rates. A single connector cannot produce an answer that surprises you, because everything it knows was already in one place.
Tasks that finish without you. Not “draft this and I’ll fix it.” A task with a defined output that runs end to end. Most teams never cross this line, because crossing it requires admitting in advance what “done” looks like, and that’s an organisational problem wearing a technical costume.
Things that run on a schedule. This is the one almost nobody has. A report that rebuilds itself every morning. A dashboard that updates as data arrives rather than when someone remembers. An artifact that is alive instead of a document that was true on the day it was written.
That last category is where the compounding is. A one-off answer saves you an hour. A recurring one changes what your Monday looks like, permanently.
DORA’s 2024 report found something that ought to worry every engineering leader: AI adoption significantly increased individual productivity, flow and job satisfaction, while making delivery throughput and stability worse. The 2025 report put it more bluntly: AI’s primary role is as an amplifier, magnifying whatever strengths and weaknesses you already have.
I wrote a whole issue about this last year and I’ll keep saying it: the tool doesn’t fix the system, it reveals it at speed.
Look at what happens to a normal product team when the practitioners actually climb the ladder.
Designers get to a clickable, working prototype in an afternoon instead of a fortnight, with something like Claude Design, or Claude Code straight to a running app. Not a mockup — something you can hand to a customer. That alone breaks most discovery processes, which were designed around the assumption that building anything was expensive.
Engineers produce far more code, and far more pull requests. And this is where I’ll say the uncomfortable thing: at that volume, does a careful human code review still make sense? I’m not sure it does. Review capacity does not scale with generation capacity, and a queue that never drains is a bottleneck no matter how virtuous the work inside it feels. My current bet is that the answer is fewer deep reviews and dramatically more testing: automated, and human testing of the actual product, which is the part teams cut first and should cut last.
I want to be honest that this is a bet, not a proven position. The counter-argument is strong: review is where junior engineers learn, where architectural drift gets caught, and where someone who understands the business notices that the requirement was wrong. Lose all three at once and you’ll ship faster into a wall. If you take this route, you need a deliberate replacement for each of those three functions, not a shrug.
Then there’s product management, which changes more than anyone expects. A PM working from real data (PostHog, BigQuery, ad platforms, Datadog) can go from a signal to a written issue in Linear or Jira in minutes. And those issues split cleanly into two piles. A bug fix with a clear reproduction can be picked up and completed autonomously, start to finish. A new feature cannot; a human has to sit down and specify exactly what the system should build, which turns out to be the same skill as writing a good spec, which is the same skill it always was.
String those together and you get a different shape of company: a conversation in Slack, backed by data pulled from four systems, turning into a task, picked up by agents that a person orchestrates, producing code that is heavily tested rather than heavily reviewed, against a prototype a designer built on Tuesday.
That is not “adding AI to your workflow.” That’s a different workflow.
The fastest way to get a team there is also the one that makes executives most uncomfortable: give them a large amount of room to experiment, and accept that a good share of it will be wasted.
Not a pilot with success criteria. Not a centre of excellence. Room. Then, once something in that mess works twice, you change the process around it, one step at a time, with the people who found it.
The alternative is what I watch happen every quarter. Leadership mandates adoption, buys licences for everyone, sets a target, and the organisation produces exactly enough visible activity to satisfy the target and not one thing more. The tools land in a company where nobody was allowed to be wrong, so nobody tries anything they might be wrong about.
Small and mid-size companies are falling behind large ones here, and it isn’t about budget — the tools are cheap. It’s that a 3,000-person company has enough engineers that a few of them will do this on their own time regardless of policy, and a 100-person company doesn’t. If you’re mid-size, the experimentation has to be granted, because it will not happen by accident.
Not next quarter. This week.
Rate yourself on the five leadership questions. Write the numbers down before you ask anyone else. You’ll want to revise them afterwards; don’t.
Ask your three strongest engineers which of Yegge’s eight stages they’re on. Ask separately, don’t discuss it as a group first. The spread between their answers matters more than the average.
Count your connectors. If the number is one, you don’t have an integration problem, you have a demo.
Find one recurring task and make it recurring in the system, not on someone’s calendar. One. Weekly report, competitor check, error digest, anything.
Give one team explicit permission to spend a fifth of the next two weeks getting this wrong. In writing, from you, with no deliverable attached.
The companies that pull ahead over the next two years won’t be the ones that adopted earliest. They’ll be the ones that knew where they actually stood.
Welcome to Gas Town — Steve Yegge’s eight stages, plus his argument for building your own orchestrator. Read it for the ladder even if you think stage 8 is madness.
Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — METR’s RCT. The 19% slower / 20% faster gap is the most useful single fact in this whole debate.
DORA Accelerate State of DevOps Report 2024 — where the throughput and stability finding comes from. The 2025 edition frames AI as an amplifier, which is the same argument I’ve been making about OKRs for years.
Model Context Protocol — the actual spec. Worth twenty minutes if the word “connector” is currently doing a lot of undefined work in your strategy deck.
If your leadership team and your engineers would give different answers to the questions above, that’s the thing to fix first. I put a short version of this assessment on my site if you want the numbers before the argument. And if you’d rather have the argument, find me on LinkedIn.
Ciao,
Luca
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.