AI coding agents voor softwareteams: waar menselijke controle nodig blijft

Waar agents echt goed in zijn

Zonder opsmuk zijn de huidige agents sterk in afgebakend, goed beschreven werk in een codebase die ze kunnen lezen: een beschreven defect reproduceren, een mechanische wijziging consistent over veel bestanden doorvoeren, de ontbrekende test schrijven, conventies volgen die in de repository zijn vastgelegd, en samenvatten wat ze hebben gedaan.

Ze zijn navenant zwak zodra er context nodig is die nergens staat. Bedrijfsregels die in iemands hoofd zitten, de reden waarom er een vreemde workaround staat, een klantrelatie die één aanpak politiek onmogelijk maakt. Ook daar produceert een agent een zelfverzekerd antwoord op, en precies dat is het risico.

Eén taak per agent werkt beter dan één agent die alles doet

Eén agent die de opdracht "los dit ticket op" krijgt, maakt zijn plan, zijn implementatie en zijn oordeel over het eigen werk in één doorlopende beweging. De beoordeling wordt dan gedaan door de partij met het grootste belang bij succes. Het werk opknippen in fasen met verschillende verantwoordelijkheden levert controlepunten op die een mens kan inzien.

De plannerfase verdient zichzelf sneller terug dan mensen verwachten. De meeste misgelopen runs leveren geen slechte code op, maar correcte code voor het verkeerde probleem, en een plan op het ticket vangt dat af voor de prijs van één goedkope modelaanroep. De planner van Suporta werkt precies zo, bewust alleen-lezen.

Waarom een agent niet op merge hoort te drukken

Dit is de ene grens waar het loont onbuigzaam te zijn, om praktische en niet om principiële redenen.

• Verantwoordelijkheid verhuist niet mee. In je contract staat dat jij aansprakelijk bent voor de opgeleverde code. "De agent keurde het goed" accepteert niemand, inclusief je verzekeraar.
• Groene tests zijn niet hetzelfde als correct. Een geslaagde suite bewijst dat wat je al bedacht had te controleren nog werkt. De dure defecten zitten in de ruimte waar niemand een test voor schreef.
• Zelf goedkeuren is geen review. Als hetgeen de wijziging schreef ook bepaalt dat hij goed is, zit er nergens in het proces een tweede mening.
• De schade is asymmetrisch. Een gemiste review kost een code review. Een ongereviewde merge naar de productieomgeving van een klant kost de relatie.

De kosten van een mens bij de merge houden zijn één code review per wijziging, en die deed je toch al. De kosten van hem weghalen zijn ongelimiteerd, en opeisbaar op het slechtst denkbare moment.

Wat de reviewagent je hoort te geven

Een goedkeuring zonder bewijs is een mening. Een bruikbare reviewer vertelt wat hij heeft gedaan, zodat een mens kan bepalen hoeveel van de wijziging nog echte aandacht nodig heeft.

Het telt ook dat de reviewer onder zijn eigen identiteit goedkeurt en niet als de auteur, zodat nergens in je historie een wijziging zichzelf goedkeurt. Een klein implementatiedetail met een groot gevolg voor de auditlijn.

De waarborgen die je vooraf instelt

Autonomie is alleen veilig in verhouding tot de controles eromheen. Elk punt hieronder hoort een instelling te zijn die jij beheert, geen belofte van een leverancier.

1. 1Een schakelaar per agent. Zet elke fase uit voor de hele organisatie, en laat die schakelaar gelden ongeacht wie of wat de run startte.
2. 2Een model per agent. Een sterk model voor planning, een goedkoop model voor documentatiecontrole. Kosten en kwaliteit zijn niet voor elke fase dezelfde knop.
3. 3Een maandbudget. Een plafond in je eigen valuta, met een waarschuwing ervoor en een harde stop erop. Zie AI-ontwikkelkosten per klant beheersen.
4. 4Expliciete rechten op commando's. Een agent draait de commando's die jij hebt goedgekeurd en verder niets.
5. 5Beperkte schrijfrechten. De hele codebase lezen is nuttig. Er overal in mogen schrijven is niet nodig.
6. 6Een wachtrij voor menselijke beslissingen. Alles wat dubbelzinnig is komt op één plek terecht in plaats van stil te vallen.

Waar je realistisch begint

De neiging is om agents op het lastigste ticket los te laten om te zien wat er gebeurt. Dat levert een mooi verhaal en een slecht besluit op. Begin waar het controleren van het resultaat goedkoop is.

• Goed beschreven defecten met reproductiestappen, in een codebase met tests. Het schoolvoorbeeld van controleerbaar werk.
• Mechanische wijzigingen over veel bestanden: een hernoemd veld, een verouderde aanroep, een versieverhoging met gevolgen.
• Testdekking voor bestaande code. Laag risico, zichtbaar resultaat.
• Achterstallige documentatie. Goedkoop, continu, en niemand doet het graag.

Houd alles wat met geld, authenticatie, rechten of datamigratie te maken heeft even buiten beeld tot je genoeg runs hebt gezien om de faalpatronen te kennen. Juist daar is een geloofwaardig ogend fout antwoord het duurst.

Wat er echt verandert voor het team

Niet de bezetting. Het werk verschuift in plaats van te verdwijnen: minder tijd met het uittypen van bekende wijzigingen, meer tijd met problemen scherp beschrijven en wijzigingen zorgvuldig beoordelen. Ticketkwaliteit wordt daarmee de bottleneck, en daarom telt de intakestap zo zwaar — zie van klantmail naar developer-ready ticket.

Twee gewoonten zijn het bewust beschermen waard. Junior developers moeten nog steeds code schrijven die een agent ook had kunnen schrijven, want zo bouw je oordeelsvermogen op. En reviews moeten echt blijven: een door een agent geschreven pull request die een stempel krijgt, is strikt slechter dan geen agent, omdat je de schijn van review hebt toegevoegd aan een ongecontroleerde wijziging.