Een developer in je team dient zes pull requests in voor de lunch. De review-wachtrij staat op 47 items. Niemand kijkt ernaar.
Dit is het nieuwe normaal.
Het jaar dat code goedkoop werd
Paul Dix, CTO van InfluxDB, noemde 2025 "het jaar dat code goedkoop werd en programmeren voorgoed veranderde." Hij heeft geen ongelijk. Met agentic tools zoals Claude Code, Codex CLI en Gemini CLI kan een enkele developer nu prototypes, migraties, refactors, bugfixes, tests en lijmcode produceren in een tempo dat twee jaar geleden absurd zou zijn geweest.
De sprong in mogelijkheden is echt. Ik heb het zelf gevoeld. Werk dat vroeger een middag kostte, is nu klaar in twintig minuten. Je beschrijft de vorm van wat je wilt, de agent vult de details in, en je gaat verder met het volgende.
Maar dit is wat niemand lijkt op te merken terwijl ze de snelheid vieren: gemergede PRs zijn geen geleverde waarde.
De bottleneck is verhuisd
Code schrijven was nooit de bottleneck in software engineering. Nooit. De trage onderdelen waren altijd dezelfde: requirements helder krijgen, wijzigingen reviewen, correctheid valideren, veilig naar productie brengen, en draaiend houden wat je hebt opgeleverd.
AI heeft het snelle deel sneller gemaakt. De trage delen zijn volledig onaangeraakt gebleven.
De data vertelt het verhaal. Teams met veel AI-adoptie mergeden 98% meer pull requests in 2026. Klinkt geweldig, tot je de keerzijde ziet: de reviewtijd van PRs steeg met 91%. Een CodeRabbit-studie toonde aan dat AI-geschreven code 1,7x meer problemen oplevert dan code van menselijke hand. En 43% van AI-gegenereerde wijzigingen moet worden gedebugd in productie.
Meer code. Meer problemen per PR. Langere reviewtijden. Trager naar productie.
De bottleneck is niet verdwenen. Die is stroomafwaarts verschoven, recht in de schoot van je meest ervaren engineers.
De review-wachtrij vreet je seniors op
Denk even na over wat een code review werkelijk vereist. Je moet de intentie achter een wijziging begrijpen, de effecten door het systeem heen traceren, en verifiëren dat er niets subtiels kapot is gegaan. Dat vraagt om een mentaal model van de codebase.
Bedenk nu dit: degene die de code schreef, heeft dat mentale model ook niet opgebouwd. De agent deed het denkwerk. De auteur klikte op "approve" bij een diff die ze vluchtig bekeken. En nu vragen ze jou om het te reviewen.
Dit is het cognitieve-belastingprobleem dat niemand meet. Elke AI-gegenereerde PR draagt minder context mee van de auteur. De patronen zijn onbekend, de naamgevingsconventies glijden weg, het "waarom" achter beslissingen ontbreekt. De reviewer moet dat allemaal vanaf nul reconstrueren.
Je meest senior mensen, degenen die wel de subtiele problemen kunnen spotten, zitten nu begraven onder een muur van contextloze diffs. Het 2026 State of Code-onderzoek toonde aan dat 96% van de developers AI-gegenereerde code niet volledig vertrouwt, maar slechts 48% het daadwerkelijk verifieert voor het mergen.
De helft van alle AI-gegenereerde code wordt geshipt zonder dat iemand het echt controleert. Dat is geen productiviteitswinst. Dat is een uitgesteld incident.
De tweedeling is er al
Paul Dix voorspelde een splitsing: organisaties die hun hele delivery chain aanpassen zullen hun voorsprong vergroten, terwijl de rest vastloopt in review, testen en releases.
Hij heeft gelijk, en je kunt het nu al zien gebeuren.
Kleine startups en verse YC-batches werken zonder zware procespoorten. Ze kunnen AI richten op elk onderdeel van de leveringsketen, niet alleen de code. Als ze goed zijn, krijg je strakkere feedbackloops, snellere experimenten en verrassend robuuste systemen voor de teamgrootte. Als ze slordig zijn, krijg je lavalagen die binnen weken verstenen.
Gevestigde teams hebben een ander probleem. Ze bouwden hun reviewprocessen, CI-pipelines en release gates voor een wereld waarin mensen code schreven op menselijke snelheid. Die processen waren al de bottleneck. Nu worden ze bestookt met een brandslang.
De kloof groeit exponentieel. Elke week die een team verdrinkt in zijn review-wachtrij, is een week die het niet shipt. Elke week die een slanker team wel shipt, is een week waarin het leert van productie.
Wat je er concreet aan doet
Het antwoord is niet nog een AI-codingtool. Daar heb je er genoeg van.
Het antwoord is investeren in de saaie delen van je pipeline:
- Geautomatiseerd testen dat echte problemen vangt: Geen coverage-theater. Tests die gedrag verifiëren, regressies vangen, en snel genoeg draaien dat developers ze niet overslaan. Als je CI 45 minuten duurt, helpt geen enkele hoeveelheid AI-gegenereerde code je sneller te shippen.
- Deployment-vangnetten: Canary releases, feature flags, geautomatiseerde rollbacks. De infrastructuur waarmee je met vertrouwen kunt shippen in plaats van met hoop. Als het deployen van een wijziging een vergadering vereist, heb je al verloren.
- Observability die je vertelt wanneer iets kapotgaat: Geen dashboards waar niemand naar kijkt. Alerts die afgaan wanneer gedrag verandert. Als je over productie-incidenten hoort via je klanten, is je monitoring decoratie.
- Reviewprocessen die schalen: Kleinere PRs, geautomatiseerde checks voor veelvoorkomende problemen, helder eigenaarschap. Het doel is niet om menselijke review te schrappen. Het doel is ervoor zorgen dat mensen de dingen reviewen die daadwerkelijk menselijk oordeelsvermogen vereisen.
Niets hiervan is glamoureus. Niets hiervan zal trenden op X. Maar het is het verschil tussen een team dat shipt en een team dat code genereert.
De echte vraag voor 2026
De industrie besteedde 2025 aan de vraag "hoe snel kun je code schrijven?" Het was toen al de verkeerde vraag en dat is het nog steeds.
De vraag voor 2026 is simpeler en moeilijker: hoe snel kun je code vertrouwen?
Want de developer die zes PRs indient voor de lunch is nergens 10x in als die PRs in een wachtrij liggen tot volgende donderdag. En het team dat duizend regels per dag genereert is niet productief als de helft daarvan gedebugd moet worden in productie.
Je pipeline is het plafond. De rest is gewoon sneller typen.