Vorige week heeft een van onze productmanagers (PM’s) een functie gebouwd en verzonden. Niet gespecificeerd. Heb er geen ticket voor ingediend. Bouwde het, testte het en stuurde het naar productie. Binnen een dag.
Een paar dagen eerder merkte onze ontwerper dat de visuele weergave van onze IDE-plug-ins uit het ontwerpsysteem was verdwenen. In de oude wereld betekende dat screenshots, een JIRA-ticket, een gesprek om de bedoeling uit te leggen, en een sprintslot. In plaats daarvan opende hij een agent, paste de lay-out zelf aan, experimenteerde, herhaalde en stemde in realtime af, en pushte vervolgens de oplossing. De persoon met de sterkste ontwerpintuïtie heeft het ontwerp direct vastgelegd. Geen vertaallaag vereist.
Niets hiervan is in theorie nieuw. Vibe-codering opende de poorten van softwarecreatie voor miljoenen mensen. Dat was ambitie. Toen ik deelde de gegevens over hoe onze ingenieurs de doorvoer verdubbelden, overgingen van coderen naar validatie, ontwerp voorop stelden voor snelle experimenten, het was nog steeds een technisch verhaal. Wat er veranderde is dat de theorie praktijk werd. Hier ziet u hoe het zich feitelijk afspeelde.
Het knelpunt is verplaatst
Toen we in 2025 AI-first gingen, stortten de implementatiekosten in. Agenten namen de steigers, tests en de repetitieve lijmcode over die vroeger de helft van de sprint opslokte. De cyclustijden daalden van weken naar dagen, van dagen naar uren. Ingenieurs begonnen minder in bestanden en functies te denken en meer in architectuur, beperkingen en uitvoeringsplannen.
Maar toen de technische capaciteit niet langer het knelpunt was, merkten we iets: de beslissingssnelheid was dat wel. Alle coördinatiemechanismen die we hadden gebouwd om de engineeringtijd te beschermen (specificaties, tickets, overdrachten, het opruimen van achterstanden) waren nu het langzaamste deel van het systeem. We waren aan het optimaliseren voor een beperking die niet langer bestond.
Wat gebeurt er als bouwen goedkoper is dan coördineren?
We begonnen een andere vraag te stellen: hoe zou het eruit zien als de mensen die het dichtst bij de bedoeling stonden de software rechtstreeks zouden kunnen verzenden?
PM’s denken al in specificaties. Ontwerpers definiëren structuur, lay-out en gedrag al. Ze denken niet in syntaxis. Ze denken in uitkomsten. Toen de kosten voor het omzetten van intentie in werkende software ver genoeg daalden, hoefden deze rollen niet meer te ‘leren coderen’. De implementatiekosten daalden eenvoudigweg tot hun niveau.
Ik vroeg een van onze premiers, Dmitry, om te beschrijven wat er vanuit zijn perspectief veranderde. Hij vertelde me: “Terwijl agenten taken genereren in Zenflow, is er een paar minuten inactieve tijd. Gewoon doodse lucht. Ik wilde een klein spel bouwen, iets om mee te communiceren terwijl je wacht.”
Als je ooit een productteam hebt geleid, ken je dit soort ideeën. Het verandert geen KPI. Het is onmogelijk om dit te rechtvaardigen tijdens een prioriteitenvergadering. Het wordt voor altijd uitgesteld. Maar het voegt persoonlijkheid toe. Het geeft het product het gevoel dat iemand om de kleine details geeft. Dit zijn precies de dingen die worden geoptimaliseerd tijdens elke backlog-opruimsessie, en precies de dingen die gebruikers onthouden.
Hij heeft het in een dag gebouwd.
In het verleden zou dat idee zijn gestorven in een spreadsheet voor het stellen van prioriteiten. Niet omdat het slecht was, maar omdat de implementatiekosten het irrationeel maakten om ermee door te gaan. Wanneer die kosten tot bijna nul dalen, verandert de berekening volledig.
Verzenden werd goedkoper dan uitleggen
Naarmate meer mensen direct gingen bouwen, verdwenen hele proceslagen stilletjes. Minder kaartjes. Minder overdrachten. Minder “kun je uitleggen wat je bedoelt met…” gesprekken. Minder verloren-in-vertaalmomenten.
Voor een betekenisvolle takenklasse werd het sneller om gewoon het ding te bouwen dan om te beschrijven wat je wilde en te wachten tot iemand anders het bouwde. Denk daar even over na. Elke moderne softwareorganisatie is gestructureerd rond de veronderstelling dat implementatie het dure onderdeel is. Wanneer deze veronderstelling niet meer wordt nageleefd, moet de organisatie mee veranderen.
Onze ontwerper die de gebruikersinterface van de plug-in repareert, is een perfect voorbeeld. De oude workflow (screenshot van het probleem, een ticket indienen, de kloof tussen intentie en implementatie uitleggen, wachten op een sprintslot, het resultaat bekijken, aanpassingen aanvragen) bestond uitsluitend om de technische bandbreedte te beschermen. Wanneer de persoon met de ontwerpintuïtie er direct naar kan handelen, verdwijnt die hele stapel. Niet omdat we het proces op zichzelf hebben geëlimineerd, maar omdat het proces een probleem oploste dat niet langer bestond.
Het samengestelde effect
Dit is wat mij het meest verraste: het werkt samen.
Wanneer PM’s hun eigen ideeën ontwikkelen, worden hun specificaties scherper, omdat ze nu begrijpen wat de agent nodig heeft om goed uit te voeren. Scherpere specificaties zorgen voor een betere agentoutput. Betere output betekent minder iteratiecycli. We zien de snelheid week na week toenemen, niet alleen omdat de modellen verbeterden, maar ook omdat de mensen die ze gebruikten dichter bij het werk kwamen.
Dmitry heeft het goed verwoord: de feedbackloop tussen intentie en uitkomst ging van weken naar minuten. Wanneer u direct het resultaat van uw specificatie kunt zien, leert u welke nauwkeurigheid het systeem nodig heeft en kunt u deze instinctief gaan leveren.
Er is een tweede orde effect dat moeilijker te meten is, maar onmogelijk te missen: eigenaarschap. Mensen stoppen met wachten. Ze stoppen met het indienen van kaartjes voor dingen die ze gewoon kunnen oplossen. ‘Bouwer’ was niet langer een functietitel. Het werd het standaardgedrag.
Wat dit betekent voor de sector
Een groot deel van het ‘iedereen kan coderen’-verhaal van vorig jaar was theoretisch, of gericht op solo-oprichters en kleine teams. Wat wij hebben meegemaakt is anders. We hebben ~50 ingenieurs die werken in een complexe brownfield-codebasis: meerdere oppervlakken en programmeertalen, bedrijfsintegraties, het volle gewicht van een echt productiesysteem.
Ik denk niet dat we uniek zijn. Ik denk dat we vroeg zijn. En met elke nieuwe generatie modellen wordt de kloof tussen wie wel en wie niet kan bouwen sneller kleiner dan de meeste organisaties zich realiseren. Elk softwarebedrijf staat op het punt te ontdekken dat hun PM’s en ontwerpers op ongerealiseerde bouwcapaciteit zitten, niet geblokkeerd door vaardigheden, maar door de kosten van implementatie. Nu die kosten blijven dalen, zijn de gevolgen voor de organisatie ingrijpend.
We zijn begonnen met de bedoeling om de software-engineering te versnellen. Wat we worden is iets anders: een bedrijf waar iedereen verzendt.
Andrew Filev is oprichter en CEO van Zencoder.
Welkom bij de VentureBeat-community!
In ons gastpostprogramma delen technische experts inzichten en bieden ze neutrale, niet-gevestigde diepgaande inzichten over AI, data-infrastructuur, cyberbeveiliging en andere geavanceerde technologieën die de toekomst van het bedrijfsleven vormgeven.
Lees meer uit ons gastpostprogramma — en bekijk ons richtlijnen als u geïnteresseerd bent om een eigen artikel bij te dragen!
