Breng een paar minuten door op ontwikkelaar Twitter en je zult het volgende tegenkomen: ‘vibe coding’. Met zo’n naam lijkt het misschien een internetrage, maar het is een echt en zichtbaar onderdeel van de softwarecultuur geworden. Het is een kortere weg naar huren NAAR DE genereer code uit eenvoudige taalinstructies in plaats van deze handmatig te schrijven.
In veel opzichten is het geweldig. AI heeft de toegangsdrempel voor coderen verlaagd, en dit heeft een golf van hobbyisten, ontwerpers en zijproject-knutselaars aangetrokken die misschien nog nooit eerder een codebasis hebben aangeraakt. Tools als Warp, Cursor en Claude Code maken professionele ontwikkelaars ook beter door het mogelijk te maken iets binnen enkele uren in plaats van weken te verzenden.
Maar hier is de keerzijde: als AI sneller kan bewegen dan je zou denken, is het gemakkelijk om over vangrails te rennen. We hebben al gezien hoe dit fout kan gaan, zoals bij de recente inbreuk op de Tea-appwaaruit blijkt dat zelfs verfijnde, volledig geteste code kritieke kwetsbaarheden kan verbergen als mensen deze niet zorgvuldig onderzoeken. Door te optimaliseren voor snelheid in plaats van voor duidelijkheid kan de AI iets produceren dat op dat moment werkt, maar zonder het te begrijpen kun je niet weten wat er later kapot kan gaan. Dit zijn niet langer alleen maar technische schulden; het is een risico voor het vertrouwen van de klant.
De reflexmatige reactie om deze afweging op te lossen is om meer technologie te gebruiken om het probleem op te lossen: voeg geautomatiseerde scans toe, voeg een ‘standaard beveiligd’-instelling toe. Deze dingen zijn belangrijk. Maar ik zou willen stellen dat het onvermogen om trillingen te coderen niet begint met hulpmiddelen, maar met leiderschap. Als u uw team niet door deze nieuwe manier van werken leidt, zullen ze óf te langzaam handelen om te profiteren van AI, óf ze zullen zo snel handelen dat ze dingen gaan breken op manieren waar een beveiligingschecklist u niet van kan redden.
Het echte werk is sturen, niet vertragen
Toen we de Warp 2.0-codeeragent bouwden, hebben we een eenvoudig mandaat ingevoerd: “Gebruik Warp om Warp te bouwen.” Dit betekent dat elke codeertaak begon met het verzoek van een AI-agent. Soms lukte het hem in één klap; soms moesten we teruggaan naar handmatige codering. Maar het punt was geen dogma, maar eerder dat we onszelf dwong om als team te leren werken in een door agenten gedomineerde wereld.
We kwamen er al snel achter dat ‘meer AI’ niet automatisch ‘beter’ betekent. AI kan duizenden regels plausibel ogende code schrijven voordat u uw koffie op heeft. Zonder structuur is dit een recept voor fragiele, niet-onderhoudbare systemen. De echte uitdaging was om mensen de door AI gegenereerde code met dezelfde discipline te laten behandelen als de code die ze zelf schreven.
Dit is een leiderschapsprobleem. Het gaat erom culturele normen vast te stellen en ervoor te zorgen dat ze zich daaraan houden.
Drie dingen die leiders nodig hebben om het goed te doen
1. Houd ontwikkelaars verantwoordelijk
De grootste mentale valkuil is dat we AI behandelen als een tweede ingenieur die ‘eigenaar is’ van wat hij heeft geschreven. Zo is het niet. Als iemand code aan een project bijdraagt, is hij/zij eigenaar van die code. Ze moeten het net zo diep begrijpen alsof ze het regel voor regel hadden getypt. “De AI heeft het geschreven” mag nooit een excuus zijn voor een bug.
Leiders kunnen het niet slechts één keer zeggen; ze moeten het vormgeven. Wanneer u code beoordeelt, stel dan vragen die duidelijk maken dat u begrip verwacht, en niet alleen functionaliteit: “Waarom duurt het zo lang om deze query uit te voeren?” “Wat gebeurt er als de invoer nul is?” Zo zet je de norm dat begrip onderdeel is van de expeditie.
2. Begeleid de AI met specifieke details
Het gebruik van grote, eenmalige instructies is als koken zonder onderweg te proeven: soms werkt het, maar meestal is het een ramp. AI is veel effectiever als je kleine, testbare wijzigingen aanvraagt en deze stap voor stap bekijkt. Het gaat niet alleen om kwaliteit, maar het creëert ook een feedbacklus waardoor uw team in de loop van de tijd beter wordt in het doen van suggesties.
In de praktijk betekent dit dat je je team leert AI te begeleiden zoals ze een junior engineer zouden begeleiden: de architectuur uitleggen, specificeren waar testen moeten plaatsvinden en het onderhanden werk beoordelen. Je kunt van AI-schrijftests ook een manier maken om kleinere, testbare werkeenheden af te dwingen.
3. Bouw nu een beoordelingscultuur op
In door AI aangedreven workflows gaan teams sneller wanneer AI en mensen zij aan zij werken, waarbij ze in kleine stappen genereren en beoordelen. De eerste versie van een feature is de belangrijkste om in de gaten te houden. Laat iemand het door AI gegenereerde werk vooraf beoordelen en concentreer u eerst op de grote vragen, zoals of het veilig en betrouwbaar is en het juiste probleem oplost.
De uitdaging voor leiderschap is om van beoordelingen een prioriteit te maken zonder iemand te vertragen. Vraag teams ernaar te streven om binnen uren en niet binnen dagen feedback te geven, en moedig hen aan manieren te vinden om het werk gaande te houden terwijl er beoordelingen plaatsvinden. Dit zorgt voor momentum en creëert tegelijkertijd een cultuur die waarde hecht aan zorgvuldig en tijdig toezicht boven haasten om iets gedaan te krijgen.
Vangrails werken alleen als mensen er gebruik van maken
Beveiligingstools en -controles kunnen fouten helpen opsporen, maar zijn geen vervanging voor goede gewoonten. Als een team snelheid belangrijker vindt dan curatie, zullen AI-vangrails in de weg staan en zullen mensen manieren om hen heen vinden.
Daarom is de focus van leiderschap in het tijdperk van AI cultureel: je moet mensen leren hoe ze AI in hun workflow kunnen integreren zonder de fundamenten uit het oog te verliezen. Teams die dit goed doen, kunnen profiteren van de snelheid die AI mogelijk maakt, zonder kwaliteit of vertrouwen te verliezen. Degenen die dat niet doen, zullen een tijdje snel bewegen, totdat ze iets sturen dat hen neerhaalt.
Trillingscodering verdwijnt niet en ik denk dat dat een goede zaak is. Zolang teams leidinggeven met mensen en niet alleen met technologie, zullen ze voorop blijven lopen en gaandeweg betere ervaringen voor gebruikers creëren.
