Hulp die zelfstandig werkt

Het andere deel van het vakgebied wacht niet op je.

Je geeft een hulpmiddel een doel, het werkt een tijdje zelfstandig en komt terug met iets dat af is. Dit deel heeft zich het snelst ontwikkeld en het is indrukwekkend.

Agenten

Een programmeeragent krijgt een doel en toestemming om eraan te werken. Die leest het project om uit te zoeken hoe alles is ingericht, maakt een plan, past bestanden aan, voert opdrachten en tests uit, leest wat er misging en probeert het opnieuw. Daarna krijg je een volledig wijzigingsvoorstel.

Ze komen in drie vormen voor. In je editor, waar je kunt meekijken en onderbreken. Op de opdrachtregel, gericht op een projectmap. En op afstand, waar je een taak beschrijft, iets anders gaat doen en terugkomt bij een wijzigingsvoorstel dat op beoordeling wacht.

Je draagt een stuk werk over zoals je dat zou doen aan een bekwame collega die je product niet kent. De twee belangrijke momenten zijn dus de overdracht en de terugkoppeling.

Reviewbots

Verwant, en steeds gebruikelijker: een AI die voorgestelde wijzigingen leest en erop reageert voordat een persoon dat doet.

Ze kunnen gemiste problemen aanwijzen: ontbrekende foutafhandeling, een benoemde waarde die nergens wordt gebruikt, een patroon dat niet bij de rest van het project past of een mogelijke beveiligingsfout. Ze kunnen ook echte problemen missen en problemen melden die er niet zijn. Een opmerking is een aanwijzing om te onderzoeken.

Ze zijn minder sterk in waar menselijke beoordeling eigenlijk voor dient: vragen of deze wijziging er moet komen en of die past bij de richting van het product.

Van prompt naar applicatie

Dan zijn er de hulpmiddelen waaraan je een applicatie beschrijft, waarna er een werkende verschijnt. Schermen, een database, inloggen, ergens online zodat je kunt klikken.

Om een idee aan mensen te laten zien, is dat bijzonder. Het heeft software bouwen bereikbaar gemaakt voor mensen die anders nooit voorbij de installatie-instructies waren gekomen. Veel van wat mensen met vibe coding bedoelen, gebeurt hier.

Wat je krijgt, is een echte applicatie. Bij echte applicaties horen vragen: waar worden de gegevens opgeslagen, wie kan erbij, wat gebeurt er als twee mensen de applicatie tegelijk gebruiken en wat kost het als duizend mensen dat doen? Worden er regelmatig back-ups van de gegevens gemaakt?

Verificatie is waarvoor je je oordeel nodig hebt

Dit is de verschuiving. Bij hulp die alleen voorstellen doet, kun je één voorgestelde wijziging tegelijk controleren. Van een agent kun je veel wijzigingen samen krijgen, en die beoordelen vraagt bewuste aandacht. Bij beide werkwijzen kan een fout onopgemerkt blijven.

Gegenereerde code verifiëren betekent drie afzonderlijke vragen stellen.

Was het verzoek juist? Zelfs een agent die je verzoek precies volgt, kan het verkeerde bouwen als een belangrijke regel ontbreekt. Die kan ook een goed verzoek verkeerd begrijpen. Controleer zowel wat je vroeg als wat er daadwerkelijk is gebouwd.

Doet het wat het beweert? De wijziging werkt en de tests slagen. Dekken de tests het gedrag dat voor jou telt, of alleen het gedrag dat de code toevallig heeft? Een agent die zijn eigen tests schrijft, kan een prachtig groen testresultaat rond een misverstand bouwen.

Hoort het in het product? Of het de juiste bestanden raakt, privégegevens privé houdt, met de omgeving samenwerkt en begrijpelijk is voor wie het later overneemt. Tests kunnen bewijs leveren voor sommige van die vragen, maar een geslaagde test stelt alleen het gedrag vast dat die daadwerkelijk heeft gecontroleerd.

Stel als concreet voorbeeld dat het verzoek luidt: “De bezorging is gratis bij een bestelling van 50 euro of meer.” Een gegenereerde rekenhulp geeft deze resultaten:

De eerste twee controles slagen. De derde onthult een fout op de grens: het precieze punt waar de regel verandert. De rekenhulp controleert mogelijk “meer dan 50” in plaats van “50 of meer”. Door de code te bekijken kun je de oorzaak vaststellen. Je hebt geen Python-syntaxis nodig om te zien waarom de eerste twee resultaten niet genoeg waren om het resultaat te accepteren.

Controleer na een correctie alle drie opnieuw. Als je alleen 50 controleert, kun je een nieuwe fout bij 40 of 75 missen. Deze voorbeelden bewijzen nog steeds niet dat elke bestelling werkt. Ze laten zien hoe een uitgesproken regel helpt om bruikbaar bewijs te kiezen.

Niets hiervan is een reden om agenten te vermijden. Het beschrijft waar je aandacht naartoe gaat zodra je er een gebruikt. Het is de reden dat je nog steeds software, programmeren, hardware, netwerken en de rest moet begrijpen.

Toegangsrechten zijn een echte beslissing

Een agent die bestanden kan aanpassen, opdrachten kan uitvoeren en het netwerk kan bereiken, is een programma met jouw toegang. Bij de meeste hulpmiddelen bepaal je zelf hoe ver die gaat: alleen lezen, aanpassen maar vragen voordat er iets wordt uitgevoerd, een sandbox gebruiken waar fouten begrensd blijven, of volledige vrijheid geven.

Stem dat af op waaraan de agent werkt. Een experimenteel project en het systeem met klantgegevens verdienen niet dezelfde speelruimte. “Het ging tot nu toe goed” is geen beveiligingsmodel. Taalmodellen maken fouten; dat heb ik zelf meegemaakt. Ze kunnen op onverwachte manieren gegevensverlies veroorzaken. Eén voorbeeld uit mijn eigen ervaring: een programmeeragent voerde tests uit op de productiedatabase in plaats van op de testgegevens en verwijderde zo al mijn productiegegevens. Ik ben oud en wijs genoeg om dagelijks back-ups te maken, dus ik verloor een dag werk. Dat doet nog steeds pijn. Les geleerd.

Hetzelfde hulpmiddel, twee heel verschillende uitkomsten

Een ervaren ontwikkelaar geeft een agent een duidelijk afgebakende taak, leest de wijziging, ziet dat er stilzwijgend een controle is verdwenen, vraagt om een oplossing en levert binnen een uur iets goeds op.

Iemand die die code niet kan lezen, krijgt dezelfde wijziging, ziet dat de app nog werkt en brengt die uit. De verdwenen controle duikt maanden later op als een fout waarvan niemand de oorzaak kan vinden.

Hetzelfde hulpmiddel. Dezelfde uitvoer. Het verschil zit volledig in wat de persoon kon zien.

Daarom staat dit hoofdstuk in een cursus over de vraag of je moet leren programmeren. Het is het eerlijke antwoord op de vraag of deze hulpmiddelen leren overbodig maken. Ze maken het juist meer waard. De laatste les brengt dat samen met de rest.