Toen Bain aankondigde dat ze "vibecoding" gebruiken als onderdeel van hun due diligence, riep dat vragen op over hoe goed het klassieke consultingmodel softwarebedrijven eigenlijk begrijpt. Software is fundamenteel iteratief, en het feit dat je een eerste prototype kunt bouwen, zegt nog weinig over de onderliggende technische en/of zakelijke fundamenten.
De lakmoesproef
Voor we ook maar iets bekritiseren, beginnen we met een voorbeeld en proberen we het zelf eens uit. We doen dat voor een goed te begrijpen bedrijf dat niet afhankelijk is van netwerkeffecten om te slagen. In ons geval wordt dat Ramp. Met Lovable en de prompt: "Maak een onkostenapp waar ik een foto kan uploaden, AI het bedrag en het type herkent en het opslaat in een database." Na 5 minuten kwam het onderstaande eruit.

Ik was onder de indruk van hoe goed het werkte. Het resultaat doet precies wat ik vroeg, maar er ontbreken nog heel wat functies, die ik er met wat moeite waarschijnlijk wel zou kunnen bijbouwen. Het punt is dat Ramp als bedrijf perfect gepositioneerd is om die functies te begrijpen en te bouwen. Je kunt hun eenvoudigste functieset wel kopiëren, maar zij kunnen blijven opschalen met integraties, virtuele kredietkaarten, hun eigen AI-bots, enzovoort. Dus ja, je zou een eenvoudigere versie van Ramp kunnen bouwen, maar volledige functiepariteit zou veel middelen kosten om uiteindelijk niet meer te zijn dan een fast follower. De echte innovatie zou nog steeds bij Ramp liggen, en in de regel winnen fast followers zelden. In wat volgt zet ik uiteen waarom dit nieuwste idee van Bain misschien niet zo slim is.
Niets nieuws onder de zon
Software klonen is niets nieuws. Ontwikkelaars doen het al lang, soms om te leren en soms als onderdeel van een sollicitatie, en er zijn duizenden YouTube-video's die laten zien hoe je in minder dan drie uur een werkende Instagram-kloon bouwt. Dus waarom is het nog nooit iemand echt gelukt om er een succesvol te lanceren? Netwerkeffecten zijn daar natuurlijk een groot deel van, maar de diepere reden is dat Instagram veel meer is dan een front-end en een back-end die via HTTP met elkaar verbonden zijn. Het draait een volledige infrastructuur die miljarden gebruikers tegelijk kan bedienen. Het heeft een van de beste aanbevelingsengines ooit gebouwd, het soort dat mensen urenlang aan het scherm gekluisterd houdt. En het verdient aan al die gebruikers via een advertentieplatform dat echt werkt. Zelfs als je op de een of andere manier een miljard gebruikers had, zou je duizenden engineers, datawetenschappers en accountmanagers nodig hebben om dat bedrijf draaiende te houden. Dat kopieer je niet even met Lovable.
En het zijn niet alleen start-ups die hier tegenaan lopen. Zelfs de grootste bedrijven worstelen ermee. In 2023 probeerde Meta zelf X te kopiëren met Threads, en eerst werkte het: de functie groeide bijna van de ene op de andere dag uit tot een enorm platform. Maar het hield geen stand. Tegen 2026 zijn de meeste mensen vergeten dat Threads überhaupt bestaat, en Meta is overgestapt op het uitrollen van AI-functies in al zijn producten. Zelfs met netwerkeffecten en serieuze engineeringcapaciteit erachter konden ze het niet doen beklijven. Producten zijn veel meer dan hoe ze er aan de oppervlakte uitzien.
Bouwen op schaal
Bouwen op schaal bestaat uit twee delen: de juiste dingen bouwen, en ze goed bouwen. Het eerste is productmanagement: weten welke functies je gebruikers echt willen. Gevestigde spelers hebben hier een streepje voor, omdat ze voortdurend feedback krijgen en het bedrijf door en door kennen. Ze worden gedisrupteerd wanneer ze zich niets meer aantrekken van het eerste deel en alleen nog het tweede optimaliseren.
Voor het tweede deel helpt het om te kijken naar een bedrijf dat echt een immense schaal heeft bereikt: Discord. In het afgelopen decennium hebben ze hun database niet één maar twee keer gemigreerd, eerst van MongoDB naar Cassandra en daarna van Cassandra naar ScyllaDB, waarbij ze onderweg van miljarden berichten naar biljoenen gingen. MongoDB was in de begindagen perfect om snel te bewegen (ze bouwden Discord in 2015 in slechts twee maanden, zonder enige vibecoding), maar uiteindelijk ontgroeiden ze het. Gelukkig hadden ze daar vanaf het begin precies op geanticipeerd, zodat de overstap toen het zover was relatief soepel verliep. Zes jaar later deden ze hetzelfde opnieuw om bij Scylla uit te komen, een migratie die ze al bij naam hadden genoemd in de oorspronkelijke Cassandra-blog. Het punt is dat verschillende schalen om verschillende technologie met verschillende afwegingen vragen, en dat je daar pas komt met echte planning, lang voordat de schaal er daadwerkelijk is.
Wanneer je een snelle kloon vibecodet, doe je geen van beide. Je roadmap zegt gewoon "kopieer X." Je staat nooit stil bij wat klanten echt belangrijk vinden, en je denkt ook niet aan schaal, want je hebt sowieso nog geen gebruikers. Je structuur is er niet op gebouwd, dus elke nieuwe functie wordt het soort migratie waar zelfs de beste engineers koude rillingen van krijgen.
Goede producten verbinden beide delen van schaal met een structuur die het makkelijk maakt om de juiste dingen op de juiste manier te bouwen. Als Discord een nieuwe functie wil, kunnen ze die afbakenen, bouwen en de migraties uitvoeren. Ze bewegen snel zonder te veel kapot te maken.
Advocaat van de duivel
Laten we de advocaat van de duivel spelen en stellen dat sommige software niet gebouwd hoeft te worden voor miljarden gebruikers of duizenden organisaties. Neem bijvoorbeeld Slack, het berichtenplatform van Salesforce. Het wordt gebruikt door veel organisaties en moet bij zijn engineeringbeslissingen rekening houden met die schaal. Organisaties zouden in plaats daarvan een kleiner alternatief kunnen bouwen, alleen voor hun eigen organisatie. Dat is perfect haalbaar (of dat denk je toch) en zou inderdaad een serieuze bedreiging voor Slack vormen.
Laten we eens opsommen wat ze dan zouden missen:
Beschikbaarheid op alle platformen
Integratie met Google, Zoom, Microsoft…
SSO; al kan dit geïmplementeerd worden
SOC2-, ISO27001-compliance
Garantie dat er geen chatdata lekt
…
Veel hiervan zou je met engineeringinspanning kunnen oplossen. Maar het komt terug op een oude productvraag: maakt het je bier lekkerder? Met andere woorden: kan de klant het eigenlijk wat schelen? Klanten kan het niet schelen dat je je eigen Slack draait, ook al zou het de SaaS-rekening kunnen drukken. Sommige organisaties zullen het proberen, maar dat zal de minderheid zijn. Kmo's hebben de expertise niet, en grote ondernemingen kunnen de verandering niet absorberen (en zouden moeten omgaan met opschalen naar 100.000 gebruikers, zie hierboven).
Geloof je me niet? In 2024 probeerde Klarna precies dat. Als softwarebedrijf hadden ze er zeker de capaciteit voor. Een jaar later hadden ze een aantal van die beslissingen teruggedraaid. Je eigen enige klant zijn betekent dat je nooit profiteert van wat alle anderen geleerd hebben.
Software is moeilijk (te begrijpen)
Software is moeilijk te begrijpen omdat complexe software bedrieglijk veel op eenvoudige software lijkt. De principes lijken hetzelfde, de code die je schrijft lijkt hetzelfde, en ook de architectuur kan er hetzelfde uitzien. De moeilijke stukken zijn vanaf de buitenkant simpelweg onzichtbaar.
Dit is niet de eerste keer dat een groot consultingkantoor kritiek over zich heen krijgt door sterke meningen over AI te verkondigen. De vorige keer was het McKinsey (en eerlijk is eerlijk, mijn "alma mater" BCG heeft ook zijn missers gehad). In wat volgens mij een van de zwakkere stukken over software is die ik gelezen heb, betoogden ze dat je de productiviteit van ontwikkelaars kunt meten door een reeks metrics te combineren. Vandaag zouden ze daar waarschijnlijk tokenverbruik aan toevoegen. Maar de beste ontwikkelaars zijn degenen die de moeite nemen om zaken te vereenvoudigen en technische schuld weg te werken, niet degenen die simpelweg de meeste code schrijven. Software moet lang meegaan, en productiviteit is niet hetzelfde als kwaliteit. Magische metrics bestaan niet, en welke metric je ook kiest, hij zal mensen uiteindelijk gewoon naar het verkeerde gedrag duwen (zie ook de wet van Goodhart). De reacties op YouTube spraken boekdelen. Het laat nog maar eens zien dat software moeilijk is.
Relevant blijven in het tijdperk van AI
Dit gaat natuurlijk dieper dan Bain die even een app vibecodet. Consultingorganisaties hebben moeite om te vinden waar ze nog waarde leveren voor hun klanten. Frontier-modellen worden steeds beter, niet alleen in software, maar ook in het maken van slides en het adviseren over deals en businessmodellen. Vooral voor Bain, waar due diligence een van hun sterkste gebieden is geweest, is het lastig concurreren geworden. AI kan miljoenen bronnen doorlezen en zelfs interviews afnemen, voor een fractie van de kosten. In een recent artikel van de FT gaven veel van de consultingbedrijven aan dat er een einde komt aan het huidige model, waarbij het hoofd AI van McKinsey zelfs zo ver ging te zeggen: "De aard van wat consulting is . . . moet natuurlijk veranderen."
Toch denk ik niet dat deze bedrijven hun waarde zullen verliezen. Ze zijn juist perfect gepositioneerd om adviseur te zijn: begrijpen waar AI voor bedrijven kan werken, en een kritische kracht zijn die organisaties uitdaagt om die tools goed te gebruiken. Deze zet van Bain is dat niet. Het wijst op een hiaat in het begrip dat de moeite waard is om serieus te nemen.