Waarom AI-coding agents niet genoeg zijn voor productie-apps

Laten we beginnen door eerlijk te zijn tegenover de categorie. Moderne coding agents, Cursor, Claude Code, OpenAI Codex en hun gelijken, zijn oprecht sterke tools. Ze lezen grote codebases, plannen wijzigingen over meerdere bestanden, schrijven tests, repareren fouten en itereren tot alles slaagt. Engineeringteams die ze goed gebruiken, bewegen merkbaar sneller, en niets in dit artikel beweert het tegendeel. Het punt gaat over scope, niet over kwaliteit.

De output van een coding agent, hoe goed ook, is een wijziging aan code. Productiesoftware is een veel groter systeem van staande verplichtingen: bewijzen dat de wijziging werkt voor echte gebruikers, verifiëren dat ze geen kwetsbaarheid introduceerde, beslissen of ze überhaupt toegestaan was, haar veilig uitbrengen, merken wanneer ze zich misdraagt, en reconstrueren wat er gebeurde wanneer dat zo is. Elk van die verplichtingen bestaat, of er nu iemand aan toegewezen is of niet, en een coding agent, opererend in de codebewerkingsfase, ontslaat je van geen enkele. Hij verhoogt de druk op allemaal, want de fase die hij versnelt is degene die alle andere voedt.

De praktische vraag voor een team dat naar productie gaat is dus niet "is onze agent goed genoeg?" Het is "wie bezit alles stroomafwaarts van de diff, nu de diffs vijf keer sneller arriveren?" Teams met een sterke platformorganisatie kunnen antwoorden met infrastructuur die ze al draaien. Teams zonder moeten die loop bouwen of adopteren, en horen dat bewust te beslissen, niet het gat te ontdekken tijdens een incident.

Het helpt op te merken waarom het gat zo makkelijk te missen is. Agent-output is levendig, een werkende feature, een geslaagde testrun, een gesloten ticket, terwijl de ontbrekende loop onzichtbaar is tot hij onder druk staat: niemand ziet de browsertest die niet bestaat of de audit trail die nooit geschreven werd. Aankoopbeslissingen wegen het levendige van nature zwaarder dan het onzichtbare, en zo eindigen organisaties met uitstekende generatie en geïmproviseerde levering. De zes verplichtingen hieronder in de evaluatie opschrijven is de correctie; ze kosten een middag om eerlijk te beoordelen en ze voorspellen productiepijn veel beter dan welke generatiebenchmark ook.

Dit is het patroon dat engineering leiders blijven melden. Agents arriveren; het pull-request-volume springt binnen weken omhoog; en elke stroomafwaartse fase, review, QA, security, release, is plots de beperking. De organisatie glijdt dan in één van twee faalmodi. Óf de stroomafwaartse fasen houden de lijn en de backlog vormt zich opnieuw vóór hen, waardoor de productiviteitswinst verdampt in wachttijd; óf de fasen wijken, goedkeuringen worden lichter, testen wordt "voor deze ene keer" overgeslagen, en de organisatie levert feitelijk onbeoordeelde code op schaal uit zonder dat ooit te hebben besloten.

De tweede modus is de gevaarlijke, omdat hij op succes lijkt. De doorlooptijd daalt, dashboards glimmen, en het opgestapelde risico is onzichtbaar tot een specifieke dinsdag: een migratie geschreven door een agent, in negen seconden goedgekeurd door een reviewer met veertig open tabbladen, haalt de checkoutflow neer, en de postmortem ontdekt dat er geen browser-level test voor checkout bestaat, geen beleid dat schemawijzigingen markeert voor echte review, en geen schone manier om te weten welke van de tweehonderd merges van die week teruggedraaid moet worden.

Niets daarvan is de schuld van de agent. Elke ontbrekende waarborg ontbrak al voordat de agent arriveerde; er was simpelweg minder verkeer over de brug. De asymmetrie is het punt: tools die codeproductie vermenigvuldigen, vermenigvuldigen de consequenties van wat je delivery loop ontbeert.

Wil je vroege waarschuwing in plaats van een postmortem, volg dan vier getallen terwijl de agent-adoptie groeit: mediane reviewtijd per gemergde wijziging (richting nul zakken is een symptoom, geen overwinning), testdekking van de flows die omzet dragen, gemiddelde tijd om een productieprobleem te herleiden tot de wijziging die het veroorzaakte, en het aandeel deploys met een getest rollback-pad. Beweegt één ervan de verkeerde kant op terwijl het mergevolume klimt, dan arriveert de asymmetrie op schema, en alle vier zijn goedkoper te repareren in maand twee dan in maand twaalf.

Pad één: stel de loop zelf samen. CI met echte gates, browsertest-infrastructuur, securityscanning gekoppeld aan iets dat bevindingen verifieert, reviewbeleid dat je team daadwerkelijk handhaaft, deploymentautomatisering met rollback, observability, en de lijm om agent-gegenereerde wijzigingen door dit alles te laten stromen. Dit is een legitiem pad, het is wat sterke platformteams doen, en de kostprijs is dat het een staande engineeringinvestering is, geen aankoop. Heb je de platformorganisatie om het te bouwen en te onderhouden, dan zijn coding agents binnen die loop een uitstekende combinatie.

Pad twee: adopteer een platform waar de loop het product is, en de generatie erbinnen gebeurt. Dit is de ruil die de meeste teams zonder platformorganisatie eerlijk moeten evalueren: minder maatwerkcontrole dan zelf bouwen, in ruil voor testen, governance, security, deployment en monitoring die op dag één bestaan en per ontwerp meeschalen met het wijzigingsvolume. De twee paden zijn ook geen vijanden. Genoeg organisaties draaien engineers met coding agents op hun kernsystemen en een beheerd platform voor de lange staart van businessapplicaties die anders nooit aandacht van het platformteam zouden krijgen.

Een eerlijke vuistregel voor de keuze tussen de paden: tel je platformengineers en je applicaties. Een sterk platformteam dat een handvol kernsystemen ondersteunt, kan de loop absoluut bouwen, en zou dat waarschijnlijk moeten doen. Datzelfde team, gevraagd die loop uit te strekken over tientallen afdelingsapps, door bureaus gebouwde portalen en overname-erfenissen, zal verdrinken. Die lange staart is waar de koopbeslissing zich meestal terugverdient. En de paden componeren: niets aan een platform adopteren voor het portfolio vereist het opgeven van de pipeline die je kernproduct al vertrouwt.

Ciao is pad twee, bewust gebouwd. Elke workspace krijgt een AI-software-organisatie, CTO, Doctor, QA-analist, Security-engineer, Coder en SysOps-operator, zodat de rollen die de loop bezitten er vanaf de eerste prompt zijn. QA draait deterministische browserreplays, self-healing tests, smoke gates vóór publicatie en productiechecks na publicatie. Security draait statische scanning, dependency-checks en toegangscontrole-probes, en bevestigt kwetsbaarheden tegen de live app voordat ze gemarkeerd worden. Guardrails past plain-English-beleid toe, legt menselijke review vast en laat een audit trail achter elke merge. Doctor, een read-only AI-SRE, onderzoekt de live app, DNS en CDN, diagnosticeert de hoofdoorzaak en concipieert de fix, en Conductor geeft één scherm over de hele vloot.

En omdat de codebewerkingsfase geen ommuurde tuin hoort te zijn: applicaties zijn echte React, TypeScript en Supabase met 100% eigendom, op elk moment exporteerbaar naar je eigen repo, en custom sandbox images verpakken dezelfde lifecycle rond Rails, Java, Go, Python, Node en multi-process backends. Deploy naar Ciao cloud, je eigen AWS-, Azure- of GCP-account, private VPC, of on-prem onder aparte voorwaarden. Serieuze ontwikkelprogramma's beginnen bij USD 10.000 per jaar, en de nuttigste demo, als dit artikel resoneerde, is kijken hoe één wijziging de hele loop aflegt van prompt tot gemonitorde productie.