Het artikel beschrijft een fundamentele verschuiving in softwareontwikkeling door de komst van 'agentisch coderen'. Waar coderen voorheen werd vergeleken met het houwen van steen — een traag en onvergefelijk proces — is code nu 'klei' geworden: kneedbaar, snel aanpasbaar en eenvoudig te herformuleren.
De auteur benadrukt dat, hoewel het maken van wijzigingen nu bijna gratis is, menselijk oordeel (smaak, architectuur en context) belangrijker is dan ooit om te voorkomen dat projecten vervallen in een vormloze brij. Er worden twee benaderingen onderscheiden:
- De weg van de vakman: Hierbij blijft de ontwikkelaar volledig in de loop, gebruikmakend van een razendsnelle feedbackcyclus voor exploratie en verfijning.
- De weg van de fabriek: Hierbij wordt een geautomatiseerde pijplijn gebouwd van specificaties en verificateurs, waarbij menselijke tussenkomst wordt geminimaliseerd en verplaatst naar de voorkant van het proces.
Beide methoden zijn complementair; de keuze tussen vakmanschap en industrialisatie hangt af van het specifieke probleem dat opgelost moet worden.
Code is nu klei
Agentisch coderen heeft dat veranderd: code is kneedbaar geworden. Hoewel het nog steeds is gemaakt van dezelfde onderliggende substantie als middeleeuwse code, zijn de kosten voor het maken van een wijziging ingestort. Dat zorgt ervoor dat het zich gedraagt als een geheel ander materiaal. Code is nu klei.
Werken met klei
Zodra code klei is, kun je het gaan modelleren. Smijt een paar grote klompen code-klei in de ruwe vorm die je wilt en kijk hoe het aanvoelt. Bevalt het niet? Het is eenvoudig om een deel opnieuw te vormen of zelfs alles plat te drukken en opnieuw te beginnen. Wanneer de algemene structuur goed voelt, verfijn je het zoals een beeldhouwer dat doet: van de algemene massa, naar de middelgrote kenmerken, naar de details.
Modelleren kan fractaal worden toegepast, op elke laag van wat je bouwt. Een solo-ontwikkelaar die een nieuw product verkent, zou de gehele kern in één dag kunnen schetsen om te zien wat werkt voordat hij in de details duikt, terwijl een team dat verantwoordelijk is voor een haperende productfunctie een paar dagen kan besteden aan het trekken van de functie in een volledig nieuwe richting om uit te zoeken of de pivot de moeite waard is. Geen enkele hoeveelheid planning of mockups verslaat het zien van het werkelijke product in actie.
Je product- en engineering-oordeel blijft echter van belang. Een wijziging aanbrengen is nu misschien bijna gratis, maar weten of het de juiste wijziging is, is dat niet. Als je dingen wilt bouwen die goed aanvoelen en solide in elkaar zitten, kun je niet simpelweg klompen klei blijven opstapelen. Je moet de delen verfijnen en nadenken over hoe ze passen, anders stort het geheel sneller in tot een vormloze brij dan dat je jezelf eruit kunt prompten. Smaak, context, vangrails, architectuur... dat zijn je armatuur en je oven.
Wanneer we dit oordeel moeten toepassen, en in welke mate, is iets wat we nog steeds aan het uitzoeken zijn. Er ontstaan verschillende workflows over een spectrum van menselijke betrokkenheid. Aan de extremen van dat spectrum liggen twee benaderingen die het waard zijn om te bekijken: de vakman en de fabriek.
De weg van de vakman
De vakman wil in de loop blijven. De snelle feedbackloop is het beste aan kneedbare code, en de reden waarom velen van ons er verslaafd aan zijn. In de tijd die nodig is om koffie te halen, kun je aan een functie denken, de aanpak met de agent op je telefoon plannen en het klaar hebben voor review zodra je terugkeert naar je bureau. Voeg enkele polijst-iteraties toe en je hebt een volledige product/engineering/QA-cyclus gecomprimeerd tot één persoon en dertig minuten.
Wanneer je je eigen gebruiker bent, wordt de loop absurd bevredigend. Zo werk ik aan een Markdown-editor die ik elke dag meer gebruik. Een paar dagen geleden keek ik naar een bestand met een lijst uitgaven en dacht ik: "Het zou cool zijn als ik ze allemaal automatisch kon optellen... wacht eens even, laat me er wat code tegenaan gooien!" Een halve frisdrank later had ik de eerste versie van calc blocks (een blok dat eenvoudige operaties evalueert en het resultaat in de marge toont) werkend in de app en al bruikbaar. Softwareontwikkeling in real-time.
Is dit niet gewoon vibe coding? Niet noodzakelijkerwijs. De weg van de vakman gaat over het in de loop blijven en het toepassen van je oordeel op elke iteratie. Wanneer je alleen het oppervlak dat voor de gebruiker zichtbaar is beoordeelt, is dat vibe coding. Wanneer je ook de code beoordeelt (op zijn minst de vorm, zo niet elke regel), is dat engineering. De loop is nu alleen sneller.
De weg van de fabriek
Aan het andere extreme wil je jezelf uit de loop verwijderen. Dat is de weg van de fabriek.
De fabriek draait volledig om het bouwen van systemen die code-klei vormen tot stenen die netjes in een grotere structuur passen. Denk aan een pijplijn bestaande uit specificaties, generatoren en verificateurs (tests, evaluaties, vangrails, review-agents) in loops die pas in laatste instantie escaleren naar een mens. Het werkt het beste in goed gestructureerde codebases met herhaalbare patronen die als mallen dienen, en duidelijke criteria waartegen het werk geverifieerd kan worden. De fabriek is geweldig voor zaken als het toevoegen van dat elfde CRUD-endpoint of het wegwerken van honderd kleine bugs.
Oordeel bestaat nog steeds in de fabriek; het is alleen stroomopwaarts verplaatst of ingebed in de pijplijn. Het is nog niet duidelijk hoeveel daarvan ingebed en geautomatiseerd kan worden, maar ik vermoed dat het opzetten van de fabriek zodat deze betrouwbare resultaten produceert, een groot deel is van wat engineering gaat worden.
Vakman of fabriek?
In beide gevallen stuurt het menselijk oordeel het werk. Het verschil ligt in wanneer het wordt toegepast. De vakman past het toe bij elke iteratie, wat geweldig is voor het verkennen van ideeën en het verfijnen van functies die goed moeten aanvoelen. De fabriek past het vooraf toe, bij het bouwen van de pijplijn, en zo min mogelijk tijdens de loop. Geen van beiden kan het zich veroorloven dit over te slaan.
Je zou denken dat fabrieken, gezien de industriële connotaties, alleen thuishoren in grote corporate codebases, terwijl vakmänner indie-hackers zijn die vanaf een strand in Thailand aan hun apps knutselen. Maar de twee kunnen complementair zijn, en veel praktijkworkflows zullen een mix van beide zijn. Grote, gevestigde producten hebben vakmanschap nodig om nieuwe problemen op te lossen of functies toe te voegen die goed moeten aanvoelen. En zelfs solo-ontwikkelaars zullen fabrieken willen runnen om zorg te dragen voor de saaie, herhaalbare delen, en om een schaal te bereiken die voorheen ondenkbaar was voor één persoon. Het punt is om de juiste aanpak te kiezen voor het probleem dat je probeert op te lossen. Wat, zoals blijkt, altijd de kern van software engineering is geweest.
Dus we hebben dit nieuwe materiaal in onze handen. Code is nu klei. Wat gaan we ermee bouwen?
Code is nu klei
Agentisch coderen heeft dat veranderd: code is kneedbaar geworden. Hoewel het nog steeds is gemaakt van dezelfde onderliggende substantie als middeleeuwse code, zijn de kosten voor het maken van een wijziging ingestort. Dat zorgt ervoor dat het zich gedraagt als een geheel ander materiaal. Code is nu klei.
Werken met klei
Zodra code klei is, kun je het gaan modelleren. Smijt een paar grote klompen code-klei in de ruwe vorm die je wilt en kijk hoe het aanvoelt. Bevalt het niet? Het is eenvoudig om een deel opnieuw te vormen of zelfs alles plat te drukken en opnieuw te beginnen. Wanneer de algemene structuur goed voelt, verfijn je het zoals een beeldhouwer dat doet: van de algemene massa, naar de middelgrote kenmerken, naar de details.
Modelleren kan fractaal worden toegepast, op elke laag van wat je bouwt. Een solo-ontwikkelaar die een nieuw product verkent, zou de gehele kern in één dag kunnen schetsen om te zien wat werkt voordat hij in de details duikt, terwijl een team dat verantwoordelijk is voor een haperende productfunctie een paar dagen kan besteden aan het trekken van de functie in een volledig nieuwe richting om uit te zoeken of de pivot de moeite waard is. Geen enkele hoeveelheid planning of mockups verslaat het zien van het werkelijke product in actie.
Je product- en engineering-oordeel blijft echter van belang. Een wijziging aanbrengen is nu misschien bijna gratis, maar weten of het de juiste wijziging is, is dat niet. Als je dingen wilt bouwen die goed aanvoelen en solide in elkaar zitten, kun je niet simpelweg klompen klei blijven opstapelen. Je moet de delen verfijnen en nadenken over hoe ze passen, anders stort het geheel sneller in tot een vormloze brij dan dat je jezelf eruit kunt prompten. Smaak, context, vangrails, architectuur... dat zijn je armatuur en je oven.
Wanneer we dit oordeel moeten toepassen, en in welke mate, is iets wat we nog steeds aan het uitzoeken zijn. Er ontstaan verschillende workflows over een spectrum van menselijke betrokkenheid. Aan de extremen van dat spectrum liggen twee benaderingen die het waard zijn om te bekijken: de vakman en de fabriek.
De weg van de vakman
De vakman wil in de loop blijven. De snelle feedbackloop is het beste aan kneedbare code, en de reden waarom velen van ons er verslaafd aan zijn. In de tijd die nodig is om koffie te halen, kun je aan een functie denken, de aanpak met de agent op je telefoon plannen en het klaar hebben voor review zodra je terugkeert naar je bureau. Voeg enkele polijst-iteraties toe en je hebt een volledige product/engineering/QA-cyclus gecomprimeerd tot één persoon en dertig minuten.
Wanneer je je eigen gebruiker bent, wordt de loop absurd bevredigend. Zo werk ik aan een Markdown-editor die ik elke dag meer gebruik. Een paar dagen geleden keek ik naar een bestand met een lijst uitgaven en dacht ik: "Het zou cool zijn als ik ze allemaal automatisch kon optellen... wacht eens even, laat me er wat code tegenaan gooien!" Een halve frisdrank later had ik de eerste versie van calc blocks (een blok dat eenvoudige operaties evalueert en het resultaat in de marge toont) werkend in de app en al bruikbaar. Softwareontwikkeling in real-time.
Is dit niet gewoon vibe coding? Niet noodzakelijkerwijs. De weg van de vakman gaat over het in de loop blijven en het toepassen van je oordeel op elke iteratie. Wanneer je alleen het oppervlak dat voor de gebruiker zichtbaar is beoordeelt, is dat vibe coding. Wanneer je ook de code beoordeelt (op zijn minst de vorm, zo niet elke regel), is dat engineering. De loop is nu alleen sneller.
De weg van de fabriek
Aan het andere extreme wil je jezelf uit de loop verwijderen. Dat is de weg van de fabriek.
De fabriek draait volledig om het bouwen van systemen die code-klei vormen tot stenen die netjes in een grotere structuur passen. Denk aan een pijplijn bestaande uit specificaties, generatoren en verificateurs (tests, evaluaties, vangrails, review-agents) in loops die pas in laatste instantie escaleren naar een mens. Het werkt het beste in goed gestructureerde codebases met herhaalbare patronen die als mallen dienen, en duidelijke criteria waartegen het werk geverifieerd kan worden. De fabriek is geweldig voor zaken als het toevoegen van dat elfde CRUD-endpoint of het wegwerken van honderd kleine bugs.
Oordeel bestaat nog steeds in de fabriek; het is alleen stroomopwaarts verplaatst of ingebed in de pijplijn. Het is nog niet duidelijk hoeveel daarvan ingebed en geautomatiseerd kan worden, maar ik vermoed dat het opzetten van de fabriek zodat deze betrouwbare resultaten produceert, een groot deel is van wat engineering gaat worden.
Vakman of fabriek?
In beide gevallen stuurt het menselijk oordeel het werk. Het verschil ligt in wanneer het wordt toegepast. De vakman past het toe bij elke iteratie, wat geweldig is voor het verkennen van ideeën en het verfijnen van functies die goed moeten aanvoelen. De fabriek past het vooraf toe, bij het bouwen van de pijplijn, en zo min mogelijk tijdens de loop. Geen van beiden kan het zich veroorloven dit over te slaan.
Je zou denken dat fabrieken, gezien de industriële connotaties, alleen thuishoren in grote corporate codebases, terwijl vakmänner indie-hackers zijn die vanaf een strand in Thailand aan hun apps knutselen. Maar de twee kunnen complementair zijn, en veel praktijkworkflows zullen een mix van beide zijn. Grote, gevestigde producten hebben vakmanschap nodig om nieuwe problemen op te lossen of functies toe te voegen die goed moeten aanvoelen. En zelfs solo-ontwikkelaars zullen fabrieken willen runnen om zorg te dragen voor de saaie, herhaalbare delen, en om een schaal te bereiken die voorheen ondenkbaar was voor één persoon. Het punt is om de juiste aanpak te kiezen voor het probleem dat je probeert op te lossen. Wat, zoals blijkt, altijd de kern van software engineering is geweest.
Dus we hebben dit nieuwe materiaal in onze handen. Code is nu klei. Wat gaan we ermee bouwen?
Groetjes,