Noted on 22 Oct 2026

In June the FT reported that Bain has started testing software takeover targets by building rough copies of them. Bain says it has vibecoded hundreds of these replicas since 2023, first with a dedicated team of engineers and now with ordinary consultants, to see whether the code is the defensible part of a business or something else.

I think the more useful version is to point the same test at the company's own engineering. If an outsider can rough out the core of a product in days, the gap between that and the company's own estimates for its roadmap is something the team should be able to explain. A team that knows its system can usually say why: the integrations, the data, the odd cases customers depend on. One that can't is telling you how well it understands what it's built.

I've seen a small version of this myself. My daughter's revision app took an evening to get from an exam paper PDF to a question on a phone, and about six days of work to cover the whole science archive. Most of that went on the awkward bits: ticks that turn out to be a symbol font, mark scheme columns that wander from page to page, and deciding what to leave out. None of that shows up in a replica. Neither does who owns the papers, which is the exam board, however cheap the code is to write.

It's also where the method runs out. A replica is a prototype, with nobody maintaining it and no customers leaning on it. It can tell you how much of a product is code, and very little about whether the company can keep running the rest.

So when I read a codebase these days, I ask what a week of an outsider's effort would reproduce and what it wouldn't, and then whether the team can explain the difference.

If your company were being bought tomorrow, what would a replica built in a week leave out about you?