Drie werkende apps, allemaal op localhost
Codeeragents kunnen de software schrijven. Het draaiend krijgen op een plek waar anderen erbij kunnen is nog steeds mensenwerk, en dat is het deel dat nu geautomatiseerd moet worden.
Er is een soort bericht dat je tegenwoordig wekelijks voorbij ziet komen. Iemand die nooit een regel code heeft geschreven meldt dat hij in een half uur drie werkende webapplicaties heeft gebouwd, en zet de links erbij.
Alle drie de links wijzen naar localhost.
Dat is geen goedkope steek onder water. Die applicaties werken waarschijnlijk echt. Diegene heeft ze vrijwel zeker zelf gebouwd, en dat half uur zal kloppen. Wat het bericht zonder het te bedoelen laat zien, is precies waar de huidige generatie gereedschap ophoudt: de code bestaat, hij draait op de machine waar hij geschreven is, en daar blijft hij.
Het deel dat niet makkelijker werd
Software schrijven was vroeger de dure stap. Dat is het niet meer, of in elk geval niet op dezelfde manier. Geef een agent een beschrijving en er komt iets uit dat draait, sneller dan jij het fatsoenlijk kunt opschrijven.
Alles daarna is precies zo moeilijk gebleven als het was.
Om een applicatie ergens neer te zetten waar anderen erbij kunnen, heb je een plek nodig om hem te draaien, een manier om hem daar te krijgen, een domein, een certificaat, ergens om geheimen te bewaren, een database die een herstart overleeft, back-ups, en enige manier om te weten of het ding nog overeind staat. Niets daarvan is interessant. Alles is verplicht. En het is het deel dat geen enkele agent voor je kan doen, omdat het niet in de repository staat.
Het werk valt daarmee uiteen in een helft die is teruggebracht tot minuten, en een helft die een ervaren engineer nog steeds een dag kost — of een beginner een weekend en drie afgebroken pogingen.
Waarom agents stoppen bij de rand van de repo
Een agent is goed in alles wat hij kan zien en aanpassen: bestanden, tests, een build. Zijn wereld houdt op bij het bestandssysteem.
Uitrollen is geen bestand. Het is een reeks handelingen met verhoogde rechten, tegen systemen die niet in de repository staan, en elke stap kan mislukken op een manier die van binnenuit de code onzichtbaar is. De registry weigert de push. Het certificaat komt niet rond. De container start en stopt weer, en de reden staat in een log op een machine waar de agent nog nooit van gehoord heeft.
Je kunt een agent een shell geven en het hem laten uitzoeken. Dat gebeurt ook. Maar dan heb je een proces dat je niet volledig kunt voorspellen de sleutels van je infrastructuur gegeven, en is de schade van één misverstand je productieomgeving. Op een laptop is dat een prima ruil. Daarbuiten niet.
Het alternatief is om uitrollen klein genoeg te maken om door een smalle opening te passen. Niet de agent meer macht geven, maar datgene wat hij moet doen zo eenvoudig maken dat het in één instructie past.
De vergelijking met een Google Doc
Ik kom steeds terug bij hoe een gedeeld document zich gedraagt, omdat dat het dichtst in de buurt komt van hoe uitrollen zou moeten voelen.
Je opent het. Je verandert iets. Er is een nieuwe revisie, automatisch, en je ziet wat er veranderd is en kunt terug. Je deelt een link en de ander heeft het. Niemand denkt na over waar het bestand staat, waar het op draait, of het opslaan gelukt is.
Dat komt niet doordat documenten eenvoudig zijn. Sommige zijn enorm, met honderden bijdragers en jaren geschiedenis. Het gedrag verandert niet met de omvang. De complexiteit is echt, hij is alleen niet van jou.
Uitrollen zou zo kunnen werken, en doet dat meestal niet.
Wat dit betekent voor bedrijfsprocessen
Er is een tweede reden waarom dit ertoe doet, en die is minder voor de hand liggend dan de eerste.
Als uitrollen moeilijk is, dan duwt het automatiseren van een bedrijfsproces je richting gereedschap dat speciaal gemaakt is om dat probleem te vermijden. Workflowplatformen als n8n en Zapier zijn niet voor niets populair: ze halen het uitrolprobleem volledig van tafel. Je tekent het proces in een ontwerpscherm en het draait. Geen servers, geen pipeline, niets om te beheren.
De rekening komt later. Een proces dat je tekent is lastig fatsoenlijk te testen, omdat er geen natuurlijke plek is om vast te leggen wat er zou moeten gebeuren voordat het echt gebeurt. Het is lastig te beoordelen, want het verschil tussen twee versies van een tekening is niet iets wat je kunt lezen. En elk bedrijf blijkt een proces te hebben met een vorm die net niet past op de beschikbare blokken, dus eindig je met een node die iets doet waar hij niet voor bedoeld is en een opmerking erbij die uitlegt waarom.
Als uitrollen echt eenvoudig was, hoefde je die afweging niet te maken. Dan schrijf je het proces als code, en krijg je er tests bij die draaien voordat het live gaat, een geschiedenis die leesbaar is, en een beoordeling die laat zien wat er veranderde. Daarna rol je het uit zoals je alles uitrolt.
Dat mensen de beperkingen van een ontwerpscherm accepteren komt vrijwel nooit doordat ze liever tekenen dan schrijven. Het komt doordat het alternatief een pipeline is.
Klein hoeft niet klein te blijven
De voor de hand liggende tegenwerping is dat dit alleen opgaat voor onbeduidende dingen, en dat alles wat serieus is toch het volledige apparaat nodig heeft.
Dat volgt niet. Een proces dat begint als één dienst die één taak doet kan uitgroeien tot iets substantieels zonder dat de manier van beheren ooit verandert, net zoals een document kan groeien van een aantekening tot een specificatie zonder een ander soort ding te worden. Wat constant moet blijven is de bediening: beschrijf wat er moet draaien, en het draait.
Het apparaat hoort iets te zijn waar je in groeit als je het nodig hebt, niet het entreegeld.
Waar ik aan werk
Ik ben hiermee bezig, en dat is de reden dat ik er zoveel over heb nagedacht. Stackyl brengt de uitrolpipeline terug tot één MCP-server, zodat een agent kan uitrollen wat hij net geschreven heeft zonder dat je hem de sleutels van iets geeft. Je beschrijft wat er moet draaien. Het draait, in de EU, met een revisiegeschiedenis.
Of die specifieke poging slaagt is een andere vraag, en het is te vroeg om te beweren van wel. Maar het gat waar het op mikt is echt, en het is zichtbaar in elk van die berichten. Drie werkende applicaties in een half uur, en alle drie op localhost.
Het bouwen ging hard. Het uitleveren niet.
Hexxore bouwt software, koppelt systemen en beheert de infrastructuur eronder. Werk je aan iets waar deze vraag speelt? Vertel ons erover.