Door Kwame Boateng

Coderen met AI-ondersteuning wordt vaak beschreven als een snellere versie van pair programming. Die vergelijking schiet inmiddels tekort. Wanneer een agent een repository kan inspecteren, meerdere bestanden kan wijzigen, tools kan uitvoeren, een preview kan genereren en een pull request kan openen, draait het centrale samenwerkingsprobleem niet langer simpelweg om de vraag: “Kan het code schrijven?” De vraag is: “Kunnen mensen zien, beoordelen, goedkeuren en later reconstrueren wat er is gebeurd?”

Daarom is de belangrijkste ontwerpverschuiving in softwareteams die met agents werken mogelijk de overgang van privéprompts naar zichtbare werkruimtes. Slack Code wordt bijvoorbeeld beschreven als een combinatie van projectkanalen met codeagents, auditing van codediffs, live HTML-previews, workflows voor feedback en goedkeuring, automatische archivering en auditlogs. De Copilot-app van GitHub heeft ook een deelvenster “Mijn werk” toegevoegd om issues en pull requests over projecten heen te organiseren. Deze functies wijzen op een praktisch principe: het werk van een agent moet minder lijken op een ondoorzichtig antwoord en meer op een changeset die een gecontroleerd productieproces doorloopt.

De chat is niet het werkverslag

Een gesprek met een agent kan nuttig zijn om een idee te verkennen, maar is een zwak systeem voor registratie. Belangrijke details kunnen begraven raken in een lange thread: welke bestanden zijn gewijzigd, welke opdrachten zijn uitgevoerd, welke aannames de agent heeft gemaakt, wat een reviewer heeft afgewezen en of het uiteindelijke resultaat afwijkt van het eerste voorstel.

Een duurzame werkruimte maakt die details controleerbaar. Die moet het verzoek koppelen aan een specifieke repository of een specifiek project, het plan van de agent bewaren, toolacties en bestandswijzigingen tonen, links naar tests en previews bevatten en vastleggen wie het resultaat heeft goedgekeurd. De precieze interface kan variëren—een issue tracker, pull request, samenwerkingskanaal of agentconsole—maar de informatie moet behouden blijven nadat de sessie is beëindigd.

Dit is van belang om alledaagse technische redenen, niet alleen vanwege compliance. Als er twee weken later een bug opduikt, heeft een team meer nodig dan alleen de uiteindelijke diff. Het kan nodig zijn om de oorspronkelijke vereiste, het gegenereerde plan, het testbewijs, de opmerkingen van de reviewer en de vraag of een mens expliciet een risicovolle afweging heeft geaccepteerd te kennen. Een duurzaam verslag verkort dat onderzoek.

Vijf lagen van zichtbaar werk

Teams die codeagents invoeren, kunnen elke wijziging behandelen als een klein, controleerbaar dossier. Vijf lagen zijn daarbij bijzonder nuttig:

  1. Intentie: de issue, acceptatiecriteria, beperkingen en gevraagde scope.
  2. Plan: de voorgestelde aanpak van de agent voordat die bestanden bewerkt. Bij een niet-triviale taak is dit een goedkeuringsmoment, geen versiering.
  3. Diff: de exacte toevoegingen, verwijderingen, afhankelijkheidswijzigingen, configuratiebewerkingen en gegenereerde assets.
  4. Bewijs: testresultaten, lintuitvoer, beveiligingscontroles, schermafbeeldingen en waar relevant een live of implementeerbare preview.
  5. Besluitverslag: opmerkingen van reviewers, gevraagde wijzigingen, goedkeuring, afwijzing, rollback of vervolgwerk.

Het doel is niet om elke wijziging door een zwaar comité te laten gaan. Een typefout en een wijziging in een betaalproces zouden niet aan identieke controles moeten worden onderworpen. Het gaat erom het niveau van toezicht evenredig te maken aan de mogelijke impact.

Goedkeuringen moeten aan acties worden gekoppeld

“De mens in de lus” is te vaag om een bruikbare controle te zijn. Iemand kan een plan goedkeuren zonder de resulterende diff te zien, of een codewijziging goedkeuren zonder te merken dat de agent ook een deploymentbestand heeft aangepast. Betere workflows maken duidelijk waartoe een goedkeuring toestemming geeft.

Een team kan bijvoorbeeld toestaan dat een agent automatisch een repository leest en lokale tests uitvoert, goedkeuring vereisen voordat er buiten een aangewezen branch wordt geschreven en een afzonderlijke goedkeuring vereisen voordat er wordt gemerged of gedeployed. Een agent kan een databasemigratie voorstellen, maar verboden worden die in productie uit te voeren. De voorgestelde aanpak van de VAE om te classificeren welke taken agents mogen voltooien en welke ze alleen mogen aanbevelen, weerspiegelt dit bredere patroon: autonomie moet per taak worden toegewezen en niet globaal worden verondersteld.

Goedkeuringen hebben ook een scope en een vervaldatum nodig. Goedkeuring voor “de tekst van de landingspagina bijwerken” zou niet stilzwijgend toestemming moeten geven voor een nieuw analysepakket. Een plan dat gisteren is goedgekeurd, zou vandaag niet automatisch een materieel gewijzigde diff moeten dekken. De interface moet die grenzen zichtbaar maken.

Previews maken van review inspectie

Code review is vaak eenvoudiger wanneer mensen het resultaat kunnen inspecteren in plaats van het uit bronbestanden te moeten afleiden. Een live HTML-preview kan gebroken uitlijning, ontbrekende toestanden, ontoegankelijke bedieningselementen of een onbedoelde wijziging in de navigatie aan het licht brengen die een reviewer in een tekstuele diff mogelijk over het hoofd ziet.

Previews zijn geen bewijs van correctheid. Ze moeten naast tests en broncode-review staan en die niet vervangen. Maar ze creëren een gemeenschappelijk object voor discussie: een reviewer kan verwijzen naar een specifiek scherm, een specifieke toestand of een specifieke interactie en feedback achterlaten die aan de voorgestelde wijziging is gekoppeld.

Dit is vooral waardevol wanneer niet-specialisten deel uitmaken van de review. Een productmanager kan misschien geen frameworkwijziging beoordelen, maar kan wel de juiste persoon zijn om te bevestigen dat de workflow overeenkomt met de vereiste. Een designer kan een visuele regressie valideren. Een beveiligingsspecialist kan zich richten op machtigingen en gegevensverwerking. De werkruimte voor agent-ondersteund werk kan elke vraag doorsturen naar de persoon die het best geplaatst is om die te beantwoorden.

Diffs hebben context nodig, niet alleen kleur

Een vertrouwde rood-groene diff blijft essentieel, maar door agents gegenereerde wijzigingen kunnen breed genoeg zijn om een reviewer te overweldigen. Teams zouden agents moeten vragen commits of wijzigingsgroepen beperkt te houden, uit te leggen waarom elk substantieel bestand is gewijzigd en gegenereerde of leveranciersbestanden afzonderlijk te identificeren.

Nuttige reviewvragen zijn onder meer:

  • Welk voor de gebruiker zichtbaar gedrag is veranderd?
  • Welke bestanden zijn uitsluitend gewijzigd ter ondersteuning van de implementatie?
  • Welke aannames deed de agent over bestaand gedrag?
  • Welke tests zijn toegevoegd, aangepast of niet uitgevoerd?
  • Kan deze wijziging gevolgen hebben voor machtigingen, het bewaren van gegevens, facturering of externe API's?

Deze vragen maken van review iets anders dan een vage vraag om “hier even naar te kijken”: ze maken er een herhaalbaar onderzoek van. Ze helpen ook een veelvoorkomende fout bloot te leggen: een aannemelijke functie die gepaard gaat met een onvolledige testaanpassing of een onbedoelde configuratiewijziging.

Archiveer de redenering die ertoe doet

Het is niet automatisch nuttig om elk token van elk modelgesprek te bewaren. Lange geschiedenissen kunnen duur zijn om op te slaan en moeilijk te doorzoeken, terwijl onderzoek naar contextcompressie waarschuwt dat samenvattingen belangrijke informatie kunnen verliezen. Een praktisch auditspoor moet daarom artefacten bewaren die relevant zijn voor beslissingen, in plaats van zonder onderscheid alles op te slaan.

Bewaar op zijn minst het verzoek, het goedgekeurde plan, de uiteindelijke diff, de resultaten van tools en tests, de verwijzing naar de preview of implementatie, beslissingen van reviewers en elke verleende uitzondering. Als een agent externe bronnen gebruikte of interne documenten ophaalde, leg dan de relevante bronverwijzingen vast en het punt waarop deze de wijziging hebben beïnvloed. Voor werk met een hoog risico kan het gerechtvaardigd zijn om de volledige interactie- en uitvoeringslog te bewaren.

Maak gegevens waar de belangen dat vereisen fraudebestendig en definieer bewaartermijnen voordat er een crisis ontstaat. Een auditspoor dat verdwijnt wanneer een kanaal wordt gearchiveerd — of dat geen onderscheid kan maken tussen een aangepast resultaat en het oorspronkelijke — zal geen serieus onderzoek ondersteunen.

Wat dit verandert voor carrières in de software

De opkomende vaardigheid is niet alleen betere prompts schrijven. Het gaat om het ontwerpen van werk dat iemand anders kan inspecteren en vertrouwen. Ontwikkelaars zullen zich comfortabel moeten voelen bij het specificeren van acceptatiecriteria, het opdelen van taken, het op grote schaal beoordelen van diffs, het bouwen van betekenisvolle tests en het bepalen waar een agent moet stoppen en vragen.

Professionals in product en design krijgen een grotere rol bij het beoordelen van previews en het verduidelijken van intentie. QA-engineers kunnen helpen bij het definiëren van goedkeuringspoorten en foutgevallen. Engineeringmanagers zullen throughput moeten meten zonder onzichtbaar risicogedrag te belonen. Technisch schrijvers en operationele specialisten kunnen bijdragen door beslissingen, uitzonderingen en runbooks duurzaam vast te leggen.

Een nuttige oefening is om een routinematige functie te nemen en de bewijsketen ervan in kaart te brengen: verzoek, plan, branch, diff, tests, preview, goedkeuring, release en rollback. Vraag vervolgens waar een toekomstig teamlid gedwongen zou zijn te gissen. Elke gok is een kandidaat voor een betere werkruimte, een duidelijkere machtiging of een duurzamer verslag.

Een eenvoudige operationele regel

Laat agents snel werken binnen een zichtbare, omkeerbare baan. Geef ze een afgebakende werkruimte, beperk gevoelige handelingen, vereist goedkeuring bij betekenisvolle grenzen, koppel bewijs aan de wijziging en bewaar de uiteindelijke beslissing. Het doel is niet om automatisering zo sterk af te remmen dat die op handmatig coderen gaat lijken. Het doel is snelheid verenigbaar te maken met verantwoordingsplicht.

Bij door agents ondersteunde ontwikkeling is de beste samenwerker niet het systeem dat op zichzelf de meeste code produceert. Het is het systeem waarvan het werk kan worden begrepen, ter discussie gesteld, goedgekeurd, ongedaan gemaakt en waarvan kan worden geleerd.