AI Coding Agents in 2026: Wat er echt wordt opgeleverd vs. wat demo-ware is

Elke leveranciersdemo van dit jaar laat dezelfde truc zien: typ één zin, kijk hoe een agent een feature scaffold, lever het op, klaar. We hebben 2026 besteed aan het daadwerkelijk draaien van deze agents tegen echte klant-codebases — productie-monorepos met CI-gates, compliance-eisen en betalende klanten aan de andere kant. De kloof tussen de demo en de implementatie is echt, en het is de moeite waard om specifiek te zijn over waar die zit.

Wat er dit jaar echt is veranderd

Drie dingen zijn verschoven van "interessant" naar "essentieel" in ons eigen leveringsproces:

• Long-context repo awareness. Agents die de volledige structuur van een middelgrote monorepo in hun context kunnen houden (niet alleen het geopende bestand) vangen nu kruislingse pakketfouten op voordat de CI dat doet — een echte tijdbespaarder voor het soort pnpm/Next.js/NestJS monorepos dat wij bouwen.
• Tool-use loops, niet single-shot completion. De nuttige agents in 2026 draaien een plan → uitvoeren → verifiëren → herplannen-loop tegen daadwerkelijke testsuites en linters, niet alleen autocomplete. Die loop is wat "lijkt plausibel" verandert in "haalt de CI daadwerkelijk."
• MCP-stijl gestructureerde tool-toegang. Gestandaardiseerde manieren voor een agent om een database aan te roepen, een interne API te raadplegen of deployment-logs te lezen — in plaats van alles te scrapen uit screenshots of copy-pasten uit terminal-output — heeft veel van de onbetrouwbaarheid weggenomen die we zagen in agent-workflows uit het tijdperk van 2025.

Waar het nog steeds misgaat

• Ambigue productvereisten. Een agent zal met evenveel zelfvertrouwen het verkeerde ding bouwen als het juiste ding. De flessenhals was nooit de typsnelheid; het is de scoping, en dat is niet veranderd.
• Institutionele context die niet in de repo staat. Waarom de facturatie-logica van een klant een vreemde edge case heeft, of waarom een migratie op een specifieke manier is uitgevoerd voor een toezichthouder — die context leeft in Slack-threads en vergaderingen, niet in de code. Agents hebben dit niet, en het hallucineren van een plausibel klinkende reden is erger dan toegeven dat ze het niet weten.
• Beveiligingsgevoelige wijzigingen. We laten een agent niets mergen dat te maken heeft met auth, betalingen of PII-verwerking zonder een menselijke review. Niet omdat de code altijd fout is — soms is het prima — maar omdat de foutmodus (een subtiele auth-bypass, een stille PII-lek) asymmetrisch is: goedkoop om te introduceren, duur om te ontdekken.

Hoe we ze daadwerkelijk gebruiken, project voor project

Voor een typisch 2Run-project geldt nu: agents handelen de eerste versie van CRUD-scaffolding af, het schrijven van tests voor goed gespecificeerd gedrag, dependency upgrade PR's, en het vertalen van een geschreven spec naar een eerste versie van een component. Een mens is nog steeds verantwoordelijk voor architecturale beslissingen, alles wat met auth/billing/compliance te maken heeft, en de laatste review voor de merge. Die verdeling is sinds begin 2026 niet veel veranderd — wat veranderd is, is hoeveel we van de eerste categorie veilig kunnen uitbesteden, wat aanzienlijk meer is dan een jaar geleden.

De eerlijke kostenberekening

Agents zijn niet gratis, zelfs als de API-rekening laag is. Het beoordelen van agent-gegenereerde code die er goed uitziet maar subtiel fout is, kost meer dan het beoordelen van code die je zelf hebt geschreven, omdat je het mentale model vanaf nul moet opbouwen. De teams die in 2026 echte waarde halen, zijn degenen die hebben geïnvesteerd in strakke feedbackloops — snelle CI, strikte typering, goede testdekking — want dat is wat ervoor zorgt dat de fouten van een agent binnen seconden aan het licht komen in plaats van in productie. Als je testsuite mager is, zal een agent met evenveel snelheid bugs opleveren als features.

Waar we naar kijken voor 2027

Evaluatiekwaliteit, niet ruwe modelcapaciteit, zal het onderscheidende vermogen zijn. De modellen zijn al goed genoeg voor de meeste CRUD-achtige taken; het openstaande probleem is weten wanneer je de output moet vertrouwen zonder deze zelf opnieuw af te leiden. Degene die dat goedkoop oplost, wint de volgende ronde — niet degene met de grootste context window.