The real project was adoption

This week Sonetel launched a new mobile app. Carrier-grade calling across two platforms -- the kind of system a conservative estimate puts at four or five engineers for well over a year to rebuild. We did it with one or two people steering AI. That gap is the whole point. But it is not where the lesson sits.

The easy conclusion would be that the hard part was getting AI to write software. It never was. AI writes code all day. The hard part was something else entirely, and it had nothing to do with code.

The real problem

The real problem was getting experienced people to change how they work -- on top of systems and habits built over many years. To let AI do the execution, not just assist, while keeping the judgment.

A team that has run a telephony backend for over a decade does not change how it works because a tool is clever. Mature, battle-tested systems and the people who know them inside out do not change their habits on the strength of a demo. They have seen tools come and go. They know what actually breaks at three in the morning, and they know that knowledge does not live in a model.

That is not technical resistance. It is reasonable resistance. And it is that resistance, not the code, that decides whether a transformation becomes real or stalls as a pilot everyone praises and no one uses.

It does not spread bottom-up

Here is the part most people underestimate. Adoption does not spread from the bottom up.

A team changes how it works for two reasons, and both have to be present at once. The first is that it is trusted from the top -- that the people who carry the risk have said this is the way, not a side project some enthusiast is pushing on their own. The second is that it visibly makes their own judgment go further. A veteran does not adopt a tool that threatens to replace him. He adopts a tool that takes his hard-won instinct -- how this system actually fails -- and applies it on every call, so that knowledge stops being locked in one person's head.

Without the first, the second never gets tested. Without a mandate, the AI question can always be deferred: we'll get to it, we'll take it with someone else, we'll do it when there's time. And then nothing happens.

The mandate was the precondition

Ours had one. The people who carry the ultimate risk for the company backed a genuinely new and unproven way of working before it was obvious it would pay off -- at the point where no would have been the safe answer. They carried the risk so the rest of us could do the work.

That is not a footnote to this story. It is the precondition for everything in it. Without that mandate, no one rebuilds a carrier-grade system with a fraction of the team, because no one is allowed to truly begin.

It is exactly the pattern I have written about before: transformation succeeds almost exclusively when it is owned by someone with real mandate at the top. The difference this time is that I was not reporting on it from the outside. I was in the room, carrying it.

What it is really about

AI did not replace the engineers. It collapsed the distance between a question and an honest answer -- what does this code really do, where did this call die, is this plan real. That moved the hard part up the stack, from typing to judgment. And judgment is still ours to carry.

AI executes. People decide what good looks like. We did not learn that in a workshop. We learned it shipping a real product, the hard way, together.

The tools were the easy part. Adoption was the hard one -- and it was the real project.

The full long-form version of this story is on LinkedIn: We shipped a year of work to the App Store this week.