Vorige week heeft een van onze productmanagers (PM’s) een functie gebouwd en verzonden. Het is niet gespecificeerd. Heb daar geen ticket voor ingediend. Bouw het, test het en stuur het naar productie. Binnen een dag.
Een paar dagen eerder merkte onze ontwerper dat het uiterlijk van onze IDE-plug-in was afgeweken van het ontwerpsysteem. In de oude wereld betekende dat screenshots, JIRA-tickets, gesprekken om het punt uit te leggen en sprintslots. In plaats daarvan opende hij de agent, paste zijn eigen lay-out aan, experimenteerde, herhaalde en stemde in realtime af, en bracht vervolgens verbeteringen aan. Mensen met de sterkste ontwerpintuïtie verbeteren hun ontwerpen onmiddellijk. Geen vertaallaag vereist.
In theorie is dit allemaal niets nieuws. Vibe-codering opent de poorten van softwarecreatie voor miljoenen mensen. Dat is een streven. Toen ik deel de gegevens over hoe onze ingenieurs resultaten repliceren, van coderen naar validatie gaan, ontwerpen naar snelle experimenten brengen, het is nog steeds een technisch verhaal. Wat er is veranderd, is de theorie in de praktijk. Hier ziet u hoe het eigenlijk werkt.
Het knelpunt is verplaatst
Omdat we in 2025 prioriteit geven aan AI, dalen de implementatiekosten. Agenten nemen de repetitieve steiger-, test- en lijmcode over die doorgaans de helft van de sprint in beslag neemt. Cyclustijden nemen af van weken naar dagen, van dagen naar uren. Ingenieurs beginnen minder na te denken over bestanden en functies en meer over architectuur, beperkingen en uitvoeringsplannen.
Maar toen de engineeringcapaciteit niet langer het knelpunt was, beseften we iets: de snelheid van besluitvorming werd het knelpunt. Alle coördinatiemechanismen die we hebben gebouwd om de engineeringtijd te beschermen (specificaties, tickets, overdracht, voorbereiding van backlogs) zijn nu de langzaamste delen van het systeem. We optimaliseren beperkingen die niet langer bestaan.
Wat gebeurt er als bouwen goedkoper is dan coördineren?
We zijn verschillende vragen gaan stellen: Hoe zou het zijn als de mensen die het dichtst bij het doel staan de software direct zouden kunnen leveren?
PM heeft al nagedacht over de specificaties. Ontwerpers hebben de structuur, indeling en gedrag al bepaald. Ze denken niet syntactisch. Ze denken na over resultaten. Wanneer de kosten voor het omzetten van intentie in werkende software drastisch dalen, hoeven deze rollen niet meer te ‘leren coderen’. De implementatiekosten dalen eenvoudigweg naar hun niveau.
Ik vroeg een van onze premiers, Dmitry, om uit te leggen wat er vanuit zijn perspectief veranderde. Hij vertelde me: “Als een agent een taak in Zenflow aanmaakt, zijn er een paar minuten inactieve tijd. Gewoon onzin. Ik wilde een klein spel maken, iets om mee te communiceren terwijl je wacht.”
Als u ooit een productteam heeft geleid, bent u bekend met dit soort ideeën. Het verandert de KPI’s niet. Het is onmogelijk om dit te rechtvaardigen tijdens een prioriteringsvergadering. Het zal voor altijd worden uitgesteld. Maar het voegt persoonlijkheid toe. Het geeft het product het gevoel dat iemand om de kleine details geeft. Dit zijn de dingen die tijdens elke backlog-onderhoudssessie worden geoptimaliseerd en de dingen die gebruikers onthouden.
Hij heeft het in een dag gebouwd.
In het verleden gingen die ideeën verloren in het prioriteringsspreadsheet. Niet omdat het slecht is, maar omdat de kosten van de implementatie ervan het onredelijk maken. Wanneer deze kosten tot bijna nul dalen, verandert de berekening volledig.
Verzenden wordt goedkoper dan uitleggen
Naarmate steeds meer mensen direct gaan bouwen, verdwijnen hele lagen van het proces stilletjes. Minder kaartjes. Minder overdrachten. Minder ‘kun je uitleggen wat je bedoelt met…’ gesprekken. Minder verloren-in-vertaalmomenten.
Voor de klasse van betekenisvolle taken is iets bouwen sneller dan beschrijven wat je wilt en wachten tot iemand anders het maakt. Denk er even over na. Elke moderne softwareorganisatie is gestructureerd rond de veronderstelling dat implementatie het dure onderdeel is. Wanneer deze aannames worden geschonden, moet de organisatie dienovereenkomstig veranderen.
Onze ontwerpers die de gebruikersinterface van de plug-in verbeteren, zijn daar een perfect voorbeeld van. De bestaande workflow (probleem met screenshot, ticket verhogen, kloof tussen intentie en implementatie uitleggen, wachten op sprintslot, resultaten beoordelen, aanpassingen aanvragen) bestaat volledig om de technische bandbreedte te beschermen. Wanneer mensen met ontwerpintuïtie direct kunnen handelen, verdwijnt die hele achterstand. Niet omdat we processen elimineren omwille van de processen zelf, maar omdat ze problemen oplossen die niet meer bestaan.
Compoundeffect
Dit is wat mij het meest verraste: het klopt.
Naarmate PM’s hun eigen ideeën ontwikkelen, worden de details scherper, omdat ze nu begrijpen wat agenten nodig hebben om goed uit te voeren. Scherpere specificaties resulteren in een betere agentoutput. Betere output betekent minder iteratiecycli. We zien de snelheid week na week toenemen, niet alleen omdat de modellen steeds beter worden, maar ook omdat de mensen die ze gebruiken steeds dichter bij de taak komen.
Dmitry legt het goed uit: de feedbacklus tussen intentie en resultaten duurt weken tot minuten. Wanneer u de resultaten van uw specificaties direct kunt zien, leert u welke nauwkeurigheid het systeem vereist en gaat u instinctief aan de slag.
Er is een tweede niveau van impact dat moeilijker te meten is, maar onmogelijk te negeren: eigenaarschap. Mensen stopten met wachten. Ze stoppen met het indienen van kaartjes voor dingen die ze kunnen oplossen. ‘Bouwer’ is niet langer een titel. Dit wordt 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 individuele oprichters en kleine teams. Wat wij hebben meegemaakt was anders. We hebben ~50 ingenieurs die werken in een complexe brownfield-codebasis: meerdere oppervlakken en programmeertalen, bedrijfsintegraties, volledige echte productiesystemen.
Ik denk niet dat wij uniek zijn. Ik denk dat we vroeg kwamen. 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 zal zich realiseren dat hun PM’s en ontwerpers over een niet-gerealiseerde ontwikkelingscapaciteit beschikken, niet gehinderd door vaardigheden, maar door implementatiekosten. Nu deze kosten blijven dalen, zijn de organisatorische implicaties enorm.
We zijn begonnen met als doel de software-engineering te versnellen. Nu zijn we iets anders: een bedrijf waar iedereen levert.
Andrew Filev is de oprichter en CEO van Zencoder.
Welkom bij de VentureBeat-community!
In ons gastenprogramma delen technische experts inzichten en geven ze onpartijdige, diepgaande uitleg over AI, data-infrastructuur, cyberbeveiliging en andere geavanceerde technologieën die de toekomst van ondernemingen vormgeven.
Lees meer uit ons gastenpostprogramma — en bekijk het eens richtlijnen als u geïnteresseerd bent om uw eigen artikel bij te dragen!
