Agents schrijven nu de code. Dit is wat het vak van de ontwikkelaar is geworden.

De vraag komt aan elke eettafel waar iemand een ontwikkelaar in de familie heeft: als de machine de code schrijft, wat blijft er dan over?

Het eerlijke antwoord is dat de vraag op het verkeerde deel van het vak is gericht. Code schrijven was nooit het hele vak. Het was het zichtbare deel, het deel dat eruitzag als werk voor iedereen die langs het bureau liep. Het was ook, in de meeste weken, het kleinste deel.

Wat er geautomatiseerd is, was nooit het hele vak

Alles wat wordt opgeleverd gaat door zes schakels:

1. Iemand wil iets, en zegt het slecht.
2. Iemand besluit dat het de moeite waard is, en wanneer.
3. Iemand maakt er een beschrijving van die precies genoeg is om op te handelen.
4. Iemand bouwt het.
5. Iemand controleert dat er niets anders is gesneuveld.
6. Iemand levert het op en laat het weten aan degene die het vroeg.

Agents hebben schakel vier overgenomen. Overtuigend, en ze worden er alleen maar beter in. Wat vrijwel niemand hardop zegt, is wat dat met de andere vijf doet: het maakt ze zwaarder, niet lichter.

Dat komt door de doorvoer. Toen bouwen twee weken duurde, hadden de vijf schakels eromheen twee weken de tijd. Ze waren traag omdat het midden traag was, en niemand die het merkte. Nu bouwen een middag duurt, wordt al het andere in één klap de bottleneck.

Eén schakel is ingeklapt. De vijf andere dragen nu het gewicht dat die schakel verborg.

Dat is het hele verhaal, en de rest van dit artikel gaat over hoe elk van die vijf eruitziet als je ze echt elke dag moet doen.

Schakel 1: horen wat er gebouwd moet worden, zonder de helft kwijt te raken

Het nieuwe faalscenario is specifiek en het is duur: je kunt alles bouwen, dus bouw je het verkeerde sneller.

Verzoeken komen overal vandaan. Een bericht in een supportgesprek. Een zin aan het eind van een call. Een klacht op social media. Een bugmelding die in werkelijkheid een vermomd featureverzoek is. Vroeger maakte dat weinig uit, want je kon toch maar één ding per twee weken bouwen, en het voor de hand liggende ding was meestal het juiste. Nu je er vijf per week kunt bouwen, is het verschil tussen de goede vijf en de verkeerde vijf het grootste deel van je jaar.

Er moeten twee dingen gebeuren, en het zijn twee verschillende dingen.

Ten eerste moet melden goedkoop zijn voor degene die vraagt. Moet een gebruiker eerst een account aanmaken, een formulier zoeken en zijn probleem twee keer beschrijven, dan doen de meesten het niet, en wie het wel doet is geen representatieve steekproef. Een publiek feedbackboard waar iedereen een verzoek kan indienen, er een screenshot aan kan hangen en kan volgen wat ermee gebeurt, haalt die wrijving weg. De mensen die het product gebruiken schrijven de verzoeken zelf, in hun eigen woorden, met de context eraan vast.

Ten tweede moet het sorteren automatisch gaan, want ruwe feedback blijft niet lang bruikbaar. Twintig berichten die ongeveer hetzelfde zeggen zien eruit als twintig problemen, tot iemand alle twintig leest en ziet dat het er één is. Dat is precies het werk waar niemand tijd voor heeft. Idea Radar is ons antwoord daarop: ruwe signalen landen onaangeraakt, groeperen zichzelf tot thema's, duplicaten worden aan elkaar gekoppeld voordat het twee bouwklussen worden, en elk idee draagt het aantal verschillende mensen dat erom vroeg. De letterlijke tekst wordt nooit herschreven, want de precieze woorden die iemand koos zijn de data.

Wat deze schakel oplevert is geen backlog. Het is een verzameling tekst die je kunt lezen.

Schakel 2: beslissen, en dat is nu de schaarse hulpbron

Een ideeënbord is geen plan. Het ene in het andere omzetten is de afweging die vroeger dun uitgesmeerd lag over een kwartaal en nu elke week moet gebeuren.

Twee zetten doen er hier toe.

Promoveren is een bewuste handeling. Een idee wordt pas een backlogticket als iemand besluit dat het gebouwd moet worden, niet op het moment dat het wordt ingediend. Al het andere blijft zichtbaar op de radar met het aantal mensen dat erom vroeg, en dat is de eerlijke stand van zaken: gehoord, niet ingepland. Een backlog waarvan tachtig procent van de regels nooit gebouwd wordt is geen plan, het is een archief met een misleidende opmaak.

Afbakenen gebeurt vóór het bouwen, niet tijdens. Vage feedback wordt een gevalideerde mockup waar degene die het vroeg naar kan kijken en die hij kan bevestigen. Vijf minuten bevestiging wint het van een middag het verkeerde scherm bouwen, en die ruil werd een stuk gunstiger toen die middag bouwen een middag agenttijd werd die je aan iets anders had kunnen besteden.

Schakel 3: briefen, het vakmanschap dat het typen heeft vervangen

Hier is het echte vakmanschap naartoe verhuisd.

Een agent duwt niet terug bij een dubbelzinnige instructie zoals een collega dat doet. Hij zegt niet "wacht, welke van de twee betaalflows bedoel je". Hij vult het gat met een plausibele gok en geeft je iets dat samenhangend en verkeerd is. Dubbelzinnigheid kostte vroeger een gesprek. Nu kost ze een diff.

Wat de mensen met goede resultaten scheidt van de mensen die de hele dag met hun agents vechten, is niet slimheid in prompts. Het is herbruikbare context. Vier soorten, op aflopende volgorde van wat ze terugbetalen.

Context die de agents lezen voordat ze gaan zoeken. Ingecheckte conventiebestanden (CLAUDE.md, AGENTS.md) en een Project Memory met de architectuurbeslissingen, de valkuilen uit het verleden en de reden waarom de dingen zijn zoals ze zijn. Eén keer geschreven, gelezen door elke agent op elke machine, voor altijd. Het is het schrijfwerk met de grootste hefboom dat een ontwikkelaar vandaag doet, en vrijwel niemand plant er tijd voor in.

Procedures, opgeslagen als procedures. De tiende keer dat je je releasechecklist uitlegt, ben je niet aan het briefen, je bent aan het overtypen. Een vaardighedenbibliotheek maakt van een terugkerende procedure iets dat een agent laadt zodra de taak past, en een promptbibliotheek doet hetzelfde voor de briefings zelf.

Tonen in plaats van beschrijven. Een alinea die een scheve knop beschrijft is minder waard dan een plaatje van die scheve knop. Stuur een stuk van je scherm rechtstreeks door, of teken erop om aan te wijzen wat je bedoelt. Bij een webpagina wint de live DOM aan de agent geven het altijd van hem beschrijven.

Praten in plaats van typen. Een gesproken briefing van drie zinnen draagt meer nuance dan de ene zin die je de moeite had genomen te typen. Spraakdictatie voor een snelle instructie, spraakmodus als je het heen en weer wilt zonder het toetsenbord aan te raken. Dit klinkt als een comfortfunctie. In de praktijk is het bandbreedte: mensen zeggen meer dan ze typen, en een agent wordt begrensd door wat je hem vertelt.

De eerste drie betaal je per taak. De vierde betaal je één keer en oogst je voor altijd.

Schakel 4: het werk aansturen, op de juiste machine

Eén agent is een gereedschap. Meerdere agents zijn een systeem, en een systeem heeft een operator nodig.

De praktische vragen zijn niet glamoureus, en ze zijn het vak. Wat kan er parallel draaien zonder dat twee agents dezelfde module bewerken? Welke taak verdient je aandacht terwijl ze loopt, en welke niet? Wat zou er moeten draaien terwijl jij slaapt?

Die laatste bepaalt waar het werk wordt uitgevoerd. Alles wat je onderweg misschien moet onderbreken, corrigeren of bijsturen hoort op de machine die voor je staat. Lang, goed afgebakend werk zonder grijze zones hoort ergens anders: een andere computer die van jou is of een server via SSH, zodat een klus van twee uur je laptop niet gijzelt. Terugkerend werk hoort in een planning. De vraag die de doorslag geeft is nooit ruwe rekenkracht, maar hoe waarschijnlijk het is dat je moet ingrijpen.

Heeft een klus fasen die echt van elkaar verschillen, dan is één agent er de verkeerde vorm voor. Iets bouwen dat daarna getest en vervolgens beoordeeld moet worden, zijn drie taken met drie verschillende vakgebieden, en met agentteams teken je die overdracht expliciet uit in plaats van bij elke stap de context opnieuw uit te leggen.

En omdat niets hiervan vereist dat je erbij zit, houdt het aansturen vanaf een telefoon op een curiositeit te zijn. De vraag van een agent lezen en er vanuit de trein in twintig seconden op antwoorden, is het verschil tussen een taak die klaar is en een taak die vier uur op je heeft gewacht.

Schakel 5: beoordelen, waar de verantwoordelijkheid woont

Dit is de schakel die je niet kunt delegeren, en de reden is niet technisch.

Agents hebben het meeste regel-voor-regel lezen al overgenomen. Wat ze niet kunnen overnemen is de handtekening. Verantwoordelijkheid gaat niet over op een model. Als een migratie een kolom in productie weggooit, is "de agent heeft het geschreven" geen zin die iemand accepteert, en dat hoort ook zo te zijn.

Wat verandert is de vorm van de beoordeling, niet het bestaan ervan. Elke regel lezen overleeft de aanraking met vijf parallel draaiende agents niet, en een mens die om zes uur 's avonds een diff van negenhonderd regels doorbladert levert een handtekening op zonder kennis op te leveren. Het beleid dat standhoudt is beoordelen naar rato van de blast radius: teksten en styling krijgen een blik, terwijl authenticatie, betalingen, rechten, persoonsgegevens en migraties regel voor regel gelezen worden, elke keer, door iemand die ze zelf had kunnen schrijven.

Twee dingen maken dat werkbaar. Een diff per agent zien in plaats van één samengevoegde berg vertelt je wie wat heeft veranderd toen er drie in dezelfde repo werkten. En het gesprek aan de commit hangen beantwoordt de vraag die zes maanden later echt tijd kost, en dat is nooit "wat is er veranderd" maar "waarom".

Voor alles met een gebruikersinterface stopt de controle niet bij de diff. Een agent die een echte browser bestuurt kan de flow doorlopen die hij net heeft gebouwd en terugkoppelen wat hij zag, en dat vangt de soort bug die in de broncode prima leest.

We hebben er een heel artikel aan gewijd waar je die aandacht aan besteedt: moet je de code van je AI-agent nog steeds beoordelen.

Schakel 6: opleveren, en de loop sluiten

Opleveren is de makkelijke helft van deze schakel. De helft die wordt overgeslagen is het laten weten aan degene die het vroeg.

Het is ook de helft die het meeste oplevert. Een gebruiker die iets meldt en later hoort dat het live staat, meldt het volgende ook. Een gebruiker die iets in de stilte meldt stopt met melden, en jij verliest de invoer die schakel één voedde. Wordt een ticket dat uit een publiek verzoek voortkwam gesloten, dan hoort degene die het indiende dat te horen zonder dat iemand eraan moet denken een mail te sturen.

Daarvoor is er meestal iemand die het moet zien werken en die jouw ontwikkelomgeving niet heeft: een klant, een ontwerper, een collega op een ander continent. Een publieke HTTPS-URL die naar je lokale machine wijst maakt daar een link van in plaats van een deployment, en de feedback die terugkomt gaat rechtstreeks schakel één in.

De keten sluit zich. Dat is wat er een vak van maakt in plaats van een wachtrij.

Wat er echt gekrompen is, en wat er echt gegroeid is

Lees die tabel eerlijk en de angst verandert van vorm. De delen die krompen zijn de delen waarvoor het het makkelijkst was om iemand aan te nemen. De delen die groeiden zijn de delen waarvoor je iemand nodig hebt die het systeem, de gebruikers en de gevolgen begrijpt. Dat is een moeilijker vak, geen kleiner vak, en het is een stuk minder eenzaam dan de versie waarin je de hele dag zat te typen.

Waar AgentsRoom hierin staat

Wij bouwen het gereedschap dat de hele keten vasthoudt, want het alternatief is zes tools die niets van elkaar weten.

Concreet: de verzoeken landen op een bord, sorteren zichzelf tot ideeën, worden gepromoveerd tot tickets, worden afgebakend tot iets dat een agent niet verkeerd kan lezen, worden uitgevoerd door één agent of een team ervan op je eigen machine of op een machine op afstand, worden per agent beoordeeld met het gesprek eraan vast, en worden gesloten terwijl degene die het vroeg bericht krijgt. Eén venster, één plek waar de stand van het werk klopt.

De losse onderdelen bestaan elders. De verbindingen ertussen zijn wat niemand opleverde, en in die verbindingen lekt het werk weg.

Vragen die mensen echt stellen

Gaat AI softwareontwikkelaars vervangen?

Het heeft het typen vervangen, niet het vak. Code schrijven is één schakel in een keten die ook bestaat uit horen wat gebruikers nodig hebben, beslissen wat de moeite waard is om te bouwen, het precies afbakenen, het werk aansturen, het controleren en het opleveren. Agents hebben de kosten van één schakel laten instorten, waardoor de andere vijf de bottleneck werden. Minder mensen worden betaald om regels te produceren. Meer mensen worden betaald om te beslissen welke regels zouden moeten bestaan, en om er verantwoording voor af te leggen zodra ze live staan.

Wat doet een ontwikkelaar eigenlijk als de agents de code schrijven?

Zes dingen, en maar één daarvan was vroeger zichtbaar op een scherm vol code. Je verzamelt wat mensen vragen, je beslist wat er gebouwd wordt en in welke volgorde, je brieft het werk precies genoeg dat een agent het niet verkeerd kan lezen, je laat meerdere klussen tegelijk lopen zonder het overzicht kwijt te raken, je beoordeelt naar rato van wat elke wijziging kan slopen, en je levert op en laat het weten aan degene die het vroeg. Het vakmanschap is verschoven van het produceren van de wijziging naar het afbakenen ervan en de verantwoordelijkheid ervoor.

Moet je nog steeds kunnen programmeren?

Ja, en meer dan vroeger als het om lezen gaat. Je hoeft de syntaxis van een taal die je twee keer per jaar aanraakt niet meer te onthouden, want de agent schrijft die. Je moet wel een diff kunnen openen en binnen een paar seconden weten of een migratie omkeerbaar is, of er een authenticatiecontrole is verplaatst, of een query het houdt bij tien keer zoveel verkeer. Wie geen code kan lezen, kan geen agent beoordelen, en wie geen agent kan beoordelen stuurt hem niet aan maar hoopt alleen maar.

Wat gaat er als eerste stuk als je het programmeren aan agents overdraagt?

De prioritering. Als bouwen een middag kost in plaats van twee weken, verdwijnen de kosten van het verkeerde bouwen uit het zicht, dus wordt het gebouwd. Teams eindigen met meer opgeleverde features en geen enkel opgelost probleem extra. Het tweede wat stukgaat is de feedbackloop: verzoeken van gebruikers komen sneller binnen dan iemand ze kan sorteren, dus stapelen ze zich op in chatgesprekken en gaan ze verloren, en hetzelfde verzoek wordt twee keer gebouwd omdat niemand doorhad dat het hetzelfde was.

Wat is de moeilijkste vaardigheid in deze nieuwe manier van werken?

Een briefing schrijven die een agent niet verkeerd kan lezen. Een agent duwt niet terug bij een dubbelzinnige instructie zoals een collega dat doet, dus vult hij de gaten met een plausibele gok en levert hij iets af dat samenhangend en verkeerd is. De mensen die goede resultaten krijgen zijn niet degenen met slimme prompts, het zijn degenen die herbruikbare context onderhouden: ingecheckte conventiebestanden, een opgeslagen procedure per terugkerende taak, een projectgeheugen dat de agents lezen voordat ze gaan zoeken, en screenshots of schetsen in plaats van alinea's die een scherm beschrijven.

Moeten codeeragents op je eigen machine draaien of op een machine op afstand?

Allebei, per taak gekozen. Alles wat je onderweg wilt bekijken, onderbreken of corrigeren hoort op de machine die voor je staat. Lang, goed afgebakend werk zonder grijze zones hoort op een andere machine die van jou is of op een server via SSH, zodat een klus van twee uur je laptop niet gijzelt. De vraag die de doorslag geeft is niet rekenkracht, maar hoe waarschijnlijk het is dat je moet ingrijpen.

De korte versie

Het vak is niet verdwenen. Het is uit de editor verhuisd, naar de keten eromheen.

Wil je deze maand één ding veranderen, kies dan schakel één. Alles wat stroomafwaarts ligt is verspilde moeite zodra het op het verkeerde probleem gericht staat, en het is de enige schakel waar een uur van jouw aandacht nog steeds wint van een uur agenttijd, met een factor die niemand kan meten.