When Anthropic shipped skills, and agents like OpenClaw arrived within weeks of it, I stopped sleeping properly for a while. The thought I kept returning to was simple and unpleasant: our company may not be needed any more. A model can now do the thing we have sold for fifteen years.
The sense that the market was moving faster than we were had been with me long before that. A year or two earlier, plenty of teams were already shipping AI-written code. It was raw, we had no pressing need to change, and we watched. That option has closed.
A year ago I wrote here that AI does not save a weak product, it exposes it faster. That piece was about features. This one is about the build itself, because producing software has become dramatically cheaper, and every leadership team I speak to is holding the same question: what does that actually change about our risk?
One thing. It changed the price of writing code. It did not change the price of being wrong about what to write.
Production got cheaper. The result stayed where it was
The clearest number on this came out of McKinsey’s State of AI survey in August: 1,719 respondents, 97 countries. Eighty percent said AI had improved their individual productivity. Thirty-seven percent said AI had contributed anything at all to their organisation’s EBIT, which is roughly where that figure sat a year earlier, even as more organisations scaled their deployments.
Self-reported, so read it as perception rather than audited return. The gap is still the most honest description of where we are.
An old mechanism sits underneath it. Clayton Christensen called it the conservation of attractive profits: when one part of a system becomes abundant and cheap, value migrates to whatever adjacent part is still scarce.
For two decades the scarce part was the building. In banking it was scarce in a specific way. Writing a payment flow is ordinary work, while making that flow survive contact with a core ledger, a fraud engine and a regulator’s expectations is not, and that second difficulty is what agencies were paid for. Some of it remains. It has stopped deciding outcomes.
The same has happened to the rest of the work. Research synthesis, first-pass design exploration, competitive analysis, documentation: most of what used to fill a discovery phase now costs a fraction of what it did two years ago.
What is scarce now is knowing which product decision is worth making.
Why a wrong decision costs more than all the work
A wrong product decision costs the whole investment attached to that product, and engineering is usually the smaller share of it.
The mechanism is unforgiving. You find out a decision was wrong when it reaches production and meets real people, not one hour earlier, because until then everything you hold is an argument: design reviews, steering committees, competitor benchmarks, each producing confidence rather than evidence. Confidence is cheap.
The base rate is also worse than most teams assume. Across experiments run at Microsoft, roughly a third of ideas improved the metric they were designed to improve, a third made no statistical difference, and a third made the metric worse. On Airbnb’s relevance team, the share that worked was 8%.
These were well-designed features aimed at defined metrics. Human intuition about what users want is a weak instrument, and the only reliable corrective is contact with real behaviour.
Which is why rewriting code rescues nothing. A cleaner implementation of a product nobody needs solves the same absent problem, faster and for less money.
Inside a bank
A Swiss private bank, FINMA-regulated, came to us with a set of fragmented systems that had to become one coherent whole without raising operational risk inside a live institution. Growing on the old foundation would have raised that risk. A previous agency had already attempted the work and failed. Every piece was delivered. Nobody owned the integration as a whole.
The code was fine. The bill was paid twice.
Halyk Bank, Kazakhstan’s largest, arrived at the opposite end of the same question. They wanted to move beyond core banking, and nobody inside the bank could prove that non-banking services would work there. Building travel straight into the main app would have put that bet on the core product, with millions of users already in it.
So the test came first. Alty designed and built travel as a separate application, where the hypothesis could be checked without touching the thing that already worked. It held: travel GMV moved from 3.9bn to 4.6bn tenge, around 18%. Only then did the bank integrate it into the main banking app, running on the authentication, payment instruments and credit infrastructure already in place.
The expensive decision was taken last.
Smaller granularity, same logic: for a leading Nigerian bank, tier-1, moving account opening into the app in August 2025 raised the monthly average of accounts opened by 286%.
The trap
Most new products rest on a hypothesis nobody has tested: that someone wants this.
I have had dozens of these conversations over fifteen years. We rarely tell anyone their idea is bad. We ask why they believe this solution is needed by anyone at all, and the answer arrives in a recognisable shape almost every time: the founder’s own experience, plus genuine excitement about the idea itself. I would use this, so other people will.
That sentence is where the money goes. It feels like evidence and it is a sample of one. The trap is structural: the same conviction that gets someone to quit a job, raise money and hold a team together through two hard years is the conviction that makes their own judgement feel like market research.
The pattern holds inside large organisations, with the ego distributed differently. The hypothesis rarely belongs to one person. It belongs to a committee, it has a budget line, and by the time anyone can test it properly, several careers are attached to it being right. Which makes it considerably harder to kill.
Four years ago a man came to me certain that every household with a reverse-osmosis water filter needed a mobile app. He had the domain expertise, he had the filter, he used it daily. We spent two conversations on who else would open that app, how often, and what they would do once inside it. He decided not to build.
He thanked me for it recently.
Where AI is genuinely enough
For testing a value proposition, AI beats hiring us. A strong product person can now validate a hypothesis without a team at all, in days, for the price of a subscription. The old route ran through a designer and a developer, or freelancers, or an agency, depending on the budget available for the test. That route is obsolete for this purpose, and I would not argue against its replacement.
The break comes when something works and has to scale. That is the point where teams start looking for a partner who has already done it inside a regulated core, because the problem stops being whether the idea is right. DORA’s 2025 research found AI adoption correlating with higher delivery throughput and, at the same time, with higher instability: more failed changes, more rework, longer recovery. Ninety percent of organisations had adopted AI in development, up fourteen points in a year. Speed arrived. The control systems did not arrive with it.
Three hypotheses, in order
One distinction before the list. McKinsey’s argument that AI’s real value sits in faster, cheaper decisions describes operational decisions at volume: scoring, pricing, routing, thousands a day, each one reversible by lunchtime. The decisions I am describing are structural. Made once, they set the next two years, and no configuration change undoes them. AI made the first kind cheap. The second still costs what it always did.
Every product decision carries three hypotheses. Test them early, cheaply, and in this order.
Desirability. Does anyone need this, judged by what people do rather than what they say in an interview? This is the hard one, and it comes first because every other question is irrelevant if the answer is no. The largest version of it I have seen was monobank. We designed the first version of the app; development was carried out by the client’s in-house team. The decision underneath all of it was whether Ukrainians would trust a bank with no branches at all, in a market where trust lived in the branch. The product passed 11 million clients in August 2026.
Feasibility. Can you build it inside this core, under this regulator, with these teams? Your own engineers can usually answer that in a week.
Viability. Will the business earn from it? What value does the decision create for the customer, will they pay for it, and will enough of them pay enough that acquisition cost still leaves a margin? Sometimes this one goes first: if unit economics cannot work at any realistic scale, there is no reason to spend money proving that people want it.
Sources
McKinsey & Company (2026). The state of AI in 2026: On the road to ROI. QuantumBlack. 1,719 respondents across 97 countries, fielded May–June 2026. Self-reported.
Kohavi, R., et al. Online Experimentation at Microsoft; Trustworthy Online Controlled Experiments (Cambridge University Press).
DORA (2025). State of AI-assisted Software Development. Google Cloud.
Christensen, C. (2003). The Innovator’s Solution.
