Er kwam een reel voorbij op Instagram waar ik langer over nagedacht heb dan de bedoeling was. Twee mannen staan op de tweede dag van een hackathon van Y Combinator in San Francisco en doen een voorspelling. De caption eronder verkoopt een product, dus die sloeg ik over. De gesproken tekst bleek een ander verhaal te vertellen, en daarom haalde ik de audio eruit en liet die transcriberen.
Wat een van de twee zegt is dit: “we figured out how to automate the code creation and the implementation part.” Het ontbrekende stuk is volgens hem niet meer hoe je bouwt, maar wat je moet bouwen. Zijn voorspelling voor het komende jaar is software die per gebruiker meebeweegt. Gebruikt een klant één functie voortdurend, dan bouwt het systeem daarop door en ziet een andere klant een andere interface. Als bewijs noemt hij een bedrijf dat bij Y Combinator binnenkwam met een landingspagina die zich aanpast aan de bezoeker, zodat een tandarts andere teksten ziet dan een loodgieter.
Mijn eerste reactie was dat ik dit ergens van kende. Eén product bouwen, bij elke klant een schil eromheen, per klant functies aan en uit. Dat heet multi-tenant SaaS met feature flags en dat bestaat al twintig jaar. Toch zit er iets nieuws in die voorspelling, en dat gaat over wie de code schrijft.
Vier niveaus, en ze worden constant door elkaar gehaald
Om te kunnen beoordelen wat een leverancier belooft, helpt het om vier niveaus uit elkaar te houden. Ze verschillen op één punt, namelijk wie de functionaliteit schrijft en waar die terechtkomt.
| Niveau | Wat er gebeurt | Wat er verandert per klant |
|---|---|---|
| 1 | Per-tenant feature flags | Alleen welke bestaande code aan staat |
| 2 | AI genereert configuratie voor een stabiele app | Instellingen, workflows, schermen |
| 3 | AI genereert een losse applicatie per klant | Een eigen codebase, een fork |
| 4 | Agents wijzigen de gedeelde productcodebase zelf | De broncode van het product zelf |
Niveau 1 is dagelijkse praktijk bij elk SaaS-bedrijf. Bij niveau 2 eindigen de serieuze verhalen. De meeste app-builders zitten op niveau 3, terwijl hun marketing niveau 4 suggereert.
Het zuiverste voorbeeld van niveau 2 komt uit de zomerbatch van Y Combinator zelf. Vendo laat gebruikers eigen functies en micro-apps bouwen binnen andermans product, op de bestaande API en binnen de bestaande beveiliging. De bepalende zin staat in hun eigen aankondiging: de agent krijgt alleen de toegang die de ingelogde gebruiker al heeft, en de broncode wordt nooit aangeraakt. Alles draait in een sandbox. Dat is de enige vorm die je kunt verkopen aan een bedrijf dat zelf klanten heeft.
Y Combinator vraagt in de Requests for Startups van de zomer van 2026 ook expliciet om deze richting, onder de titel “Dynamic Software Interfaces”. Ankit Gupta schrijft daar dat coding agents goed genoeg zijn geworden om gebruikers hun eigen forward deployed engineer te laten zijn, met als voorbeeld een e-mailclient die er voor hem uitziet als een takenlijst en voor een student als een agenda. Onderliggend delen die twee interfaces dezelfde primitieven, en die primitieven bouwt en levert het softwarebedrijf.
Wat mij opviel is waar die tekst stopt. Gupta stelt de vervolgvragen zelf, als openstaande problemen: moet een ontwikkelaar dan broncode leveren in plaats van een gebouwd pakket, en mag een gebruiker alleen visuele elementen wijzigen of ook de middleware. Zelfs de partij die deze these financiert houdt het bij de interface en zet er een vraagteken achter zodra het dieper de stack in gaat.
Wat ik wél gecontroleerd heb
Eén project wordt in de rapporten die ik las opgevoerd als bewijs dat niveau 4 bestaat: Neo.mjs, een JavaScript-framework dat zichzelf een zelf-evoluerend software-organisme noemt. Ik heb de GitHub-API bevraagd in plaats van de website te geloven. In juni 2026 zijn daar 978 pull requests gemergd, in mei 736. De lijst met bijdragers bevat naast de maintainer een reeks bot-accounts per model, met namen die verwijzen naar verschillende aanbieders. Die cijfers kloppen dus, en de opzet met concurrerende modellen die elkaars code beoordelen bestaat echt.
Alleen is het een framework en geen SaaS met klanten. Er zijn geen tenants, dus er is ook geen per-klant functionaliteit en geen terugvoer. Een repository die zichzelf verbouwt is iets anders dan een product dat zich per klant verbouwt. Wie het eerste als bewijs voor het tweede opvoert, telt een stap over die de hele belofte draagt.
De halve fabriek
Denk aan het model als een fabriek met kleine deelfabrieken eromheen. Bij elke klant staat zo’n deelfabriek, met functies die aan of uit staan. Je kijkt wat een klant echt gebruikt, bouwt dat uit, geeft het een andere schil. En wat daar werkt, gaat terug de hoofdfabriek in, zodat de volgende klant het meekrijgt.
Die laatste stap heb ik nergens gevonden. Niet bij de leveranciers die niveau 4 claimen, niet bij Vendo, niet in de Requests for Startups, niet in de papers. Iedereen levert de heenweg, van gedeeld product naar iets wat bij deze ene klant past. Niemand levert de terugweg, waarin een functie die zich bij één klant bewezen heeft wordt gepromoveerd naar het gedeelde product.
Zonder die terugweg werkt dit als een kopieermachine. Elke klant krijgt een eigen versie die daarna zijn eigen kant op drijft. Dat patroon heeft een naam in de literatuur over softwareproductlijnen, waar het al sinds de jaren negentig wordt bestudeerd: clone-and-own. Kopiëren is goedkoop en snel, en de rekening komt later, wanneer elke beveiligingspatch en elke migratie in tientallen uiteengelopen versies moet landen.
Een paper van Xhevahire Tërnava uit juni 2026 onderzocht tien projecten die volledig door een taalmodel waren geschreven. Zij vond vrijwel geen variabiliteit in de code zelf, en geen configuratie-opties. Alle keuzes worden gemaakt op het moment dat het model de code genereert. Zij trekt daar een andere conclusie uit dan ik verwachtte. In plaats van dit een defect te noemen dat gerepareerd moet worden, stelt ze voor om het als een eigen aanpak te behandelen, waarbij het model de varianten afleidt en een verdeler gebruikers naar de juiste versie stuurt. Dat is een voorstel en geen aanklacht, en het is eerlijker dan hoe ik het zelf aanvankelijk las.
Wat het niet oplost, is dat je dan honderden versies onderhoudt in plaats van één product. Voor een fabriek met terugvoer heb je één gedeelde codebase nodig waarin een verbetering ook echt landt.
De kanttekening
Drie dingen verschuiven hier stilletjes, en ze verdienen het om benoemd te worden voordat iemand dit gaat bouwen.
De standaard verschuift van “wat is goed” naar “wat wordt geklikt”. Als gebruikssignalen bepalen welke functies worden uitgebouwd, groeit wat vaak wordt aangeraakt en verschrompelt de rest. Precies daar zitten de dingen die weinig gebruikt worden en toch moeten bestaan: de toegankelijke route en het scherm dat de moeilijke aanvraag afhandelt.
De verantwoordelijkheid landt op een plek die er niet op gebouwd is. Bij niveau 1 en 2 is te reconstrueren wie een wijziging heeft goedgekeurd. Zodra een agent de gedeelde code aanpast, moet iemand kunnen uitleggen waarom die regel daar staat, ook een jaar later tegenover een auditor. De change-management-eisen uit ISO 27001 en SOC 2 gaan uit van een menselijke aanvrager en een menselijke beoordelaar.
Wat er van de gebruiker wegstroomt is het vermogen om het product te herkennen. Als mijn scherm anders is dan dat van mijn collega, kan die me niet meer helpen, kan de helpdesk niet meer meekijken, en is documentatie niet meer waar. Dat is een reële kostenpost die in geen enkele demo terugkomt.
Wat ik zelf doe
Ik houd het bij niveau 1 en 2, en ik zeg er hardop bij waarom. Wat ik met agents bouw genereert configuratie, teksten en schermen binnen een codebase die ik zelf beheer en lees. De agents in mijn eigen publicatiestraat schrijven wel code, maar elke wijziging gaat langs geautomatiseerde controles die ik zelf heb geschreven, en langs mij. Voor iets dat klanten raakt zou ik de terugweg eerst willen zien werken voordat ik de heenweg automatiseer.
En bij elke leverancier die “self-evolving” op de website zet, stel ik voortaan één vraag: laat zien hoe een functie die bij één klant werkt terechtkomt in het product van alle anderen. Komt daar een demo op in plaats van een changelog, dan is het niveau 3 met een duurdere naam.
Veelgestelde vragen
Is self-evolving SaaS hetzelfde als feature flags?
Nee, al lijken de beloftes op elkaar. Bij feature flags bestaat alle functionaliteit al en bepaalt een instelling per klant wat er aan staat. Bij self-evolving software zou nieuwe functionaliteit ontstaan zonder dat een ontwikkelaar die schreef. Het verschil zit in de vraag of er iemand is die de code heeft gezien.
Wat betekent “terugvoer” precies in dit verhaal?
Dat een functie die voor één klant is gemaakt en daar goed werkt, wordt opgenomen in het gedeelde product, zodat andere klanten die ook krijgen. Zonder die stap levert elke aanpassing een eigen versie op die apart onderhouden moet worden. Met die stap wordt elke klant een bron van verbetering voor de rest.
Kan ik dit vandaag veilig inzetten?
Op niveau 1 en 2 wel, want daar raakt de gegenereerde output nooit de broncode en blijft de schade beperkt tot instellingen binnen een applicatie die je zelf hebt getest. Voor niveau 3 en 4 zou ik eerst willen weten hoe een foute wijziging teruggedraaid wordt voor één klant zonder de anderen te raken. Ik heb daar nog geen werkend voorbeeld van gezien.
Bronnen
- Instagram, reel van sorhan.hq over self-evolving SaaS, geplaatst 26 april 2026. Transcriptie van de audio door mijzelf gemaakt op 21 augustus 2026.
- Y Combinator, Requests for Startups, Summer 2026, “Dynamic Software Interfaces” door Ankit Gupta. Geraadpleegd 21 augustus 2026.
- Y Combinator, bedrijfspagina en launch-post van Vendo (S26). Geraadpleegd 21 augustus 2026.
- GitHub API, repository neomjs/neo, telling van gemergde pull requests over mei en juni 2026 en de lijst met bijdragers. Opgevraagd 21 augustus 2026.
- Xhevahire Tërnava, “Where Did the Variability Go? From Vibe Coding to Product Lines by Regeneration”, arXiv:2606.19042, ingediend 17 juni 2026.
- Liyi Cai, Yijie Ren, Yitong Zhang en Jia Li, “AI-Driven Self-Evolving Software: A Promising Path Toward Software Automation”, arXiv:2510.00591, ingediend 1 oktober 2025.
Gecontroleerd op 21 augustus 2026. De transcriptie van de reel, de tekst van de Requests for Startups, de aankondiging van Vendo en de cijfers uit de GitHub-API heb ik zelf opgehaald en gelezen. De twee papers heb ik gelezen op abstractniveau en niet in hun geheel; de omschrijving van het voorstel van Tërnava komt uit de samenvatting van de auteur zelf. De uitspraak dat nergens een terugvoermechanisme bestaat, is een bewering over afwezigheid en dus zwakker dan de rest: ik heb het niet gevonden in de bronnen hierboven en in twee uitgebreide onderzoeksrapporten die ik liet maken, maar afwezig bewijs blijft iets anders dan bewijs van afwezigheid. Wie een werkend voorbeeld heeft, houd ik me aanbevolen.