Wanneer code bijna gratis is, verschuift de bottleneck naar behoeften, integratie, validatie en alignment

Wanneer codeproductie bijna gratis is, verschuift de bottleneck in softwarelevering van “code schrijven” naar andere punten: het juiste probleem definiëren, fragmenten samenvoegen tot een werkelijk werkend geheel, verifiëren dat het daadwerkelijk klopt, en de organisatie in lijn brengen. Dit is een herhaling van de Theory of Constraints in de softwareindustrie. De productiesector heeft dit 40 jaar geleden al doorgemaakt: zodra een processtap goedkoper wordt, verdwijnt de bottleneck niet — hij verplaatst zich naar de volgende, duurste stap. Als je dit begrijpt, kun je een algemene verwarring verklaren: AI-programmeertools zijn overal in het bedrijf ingezet, code schrijven is duidelijk sneller geworden, maar de leveringssnelheid is nauwelijks veranderd.

Een CIO van een productiegroep toonde me zijn gegevens van de afgelopen zes maanden. Het IT-team bestaat uit meer dan 80 mensen en heeft volledig AI-programmeertools geïmplementeerd. Op basis van code-uitvoer zijn de gemiddelde aantal commits en merge-snelheden met meer dan 30% gestegen. Maar de ervaring van de businesszijde is volledig anders: een slimme productieplanningfunctie duurt nog steeds minstens drie maanden van idee tot live. Hij verwachtte een verdubbeling van de snelheid, maar kocht alleen “snel coderen”. Zijn woorden waren direct: “Ik heb miljoenen uitgegeven aan licenties — en ik kreeg alleen ontwikkelaars die drukker zijn en businessdie sneller willen.”

Hij nam de verkeerde locatie van de bottleneck aan. De echte bottleneck was iets anders: elke nieuwe functie moest door MES, ERP, kwaliteitscontrolesystemen, productielocatie-terminals en een set regelgevende rapportagestandaarden, waarbij integratie en integratietests het grootste deel van de tijd opslorpten; terwijl AI-gegenereerde code geen enkele formele acceptatiecontrole heeft tussen zichzelf en de productieomgeving. Hoe snel je ook code schrijft, je staat gewoon in de rij achter de verkeerde bottleneck.

I. Manufacturing: 40 jaar geleden wist men al: bottlenecks bewegen

Om het huidige te begrijpen, gebruiken we eerst een bril die de productie-industrie al 40 jaar draagt. In 1984 schreef de Israëlische adviseur en fysicus Eliyahu Goldratt de roman “The Goal”, over een fabrieksleider op het punt van faillissement die zijn fabriek redt. De kern van het boek is één zin: De uitvoer van elk systeem wordt bepaald door zijn smalste onderdeel (de constraint, oftewel de bottleneck). Het verbreden van niet-bottlenecks heeft geen invloed op de totale uitvoer; alleen het verbreden van de bottleneck zelf maakt het geheel sneller. En zodra je de bottleneck verbreedt, verschuift die direct naar het volgende smalste punt. Dit is de Theory of Constraints (TOC).

Na de automatisering van de productie-industrie gedurende 40 jaar is de geschiedenis vrijwel een geschiedenis van “het verplaatsen van de bottleneck”. Toen CNC-machines het snijden goedkoper maakten, verplaatste de bottleneck zich naar het wisselen van malen en kwaliteitscontrole; toen flexibele productielijnen het wisselen van malen versnelden, verplaatste de bottleneck zich naar productieplanning en samenwerking in de supply chain; toen MES-systemen de productieplanning nauwkeuriger maakten, verplaatste de bottleneck zich naar vraagvoorspelling en cross-fabriek scheduling. Elke keer dat een segment geautomatiseerd werd, kwam het volgende naar boven. Automatisering elimineert nooit bottlenecks; het verplaatst ze alleen. Deze wetmatigheid is niet exclusief voor de productie-industrie. In juli 2026, in de a16z-podcast “Software in the Age of Agents”, kwam Steven Sinofsky, voormalig president van Windows bij Microsoft, met een voorbeeld uit zakelijke software onafhankelijk tot dezelfde conclusie. Zijn woorden waren:

“The long tail got no shorter. It just got longer in a different way.”

Hij noemde de Amazon-customer-service: ze schaften de telefoonlijn af en lieten de chatbot direct producten opnieuw verzenden. Op het eerste gezicht scheelde dat personeel, maar achter de schermen ontstond meteen een complexere vraag: “Hoe voorkomen we dat dit probleem zich opnieuw voordoet?” — een root-cause-analyse die veel ingewikkelder was dan telefoongesprekken beantwoorden. Hetzelfde geldt voor de reis- en onkostenvergoeding: nadat OCR automatisch boekingen maakt, gaat de financiële afdeling over naar reisprestatie-optimalisatie en dynamische prijsvergelijking. Het werk is niet verdwenen — het is verplaatst van “invoeren” naar “analyseren en beslissen”. Een veteran van Microsoft en partner bij a16z, zonder gebruik te maken van Goldratt’s theorieën, kwam tot dezelfde conclusie als de productie-industrie 40 jaar geleden. Eén afkomstig uit de fabriekshal, één uit zakelijke software — twee onafhankelijke paden die naar dezelfde wetmatigheid leiden.

Maar deze wetmatigheid moet worden beperkt, anders wordt hij verkeerd begrepen als absolute waarheid. Er zijn inderdaad banen die permanent verdwenen zijn: typistes, telefooncentrale operators, zetterijwerkers — deze beroepen zijn niet “verplaatst”, ze zijn werkelijk verdwenen. De vraag is of een taak verplaatst wordt of verdwijnt: dat hangt af van of de door automatisering vrijgemaakte capaciteit nieuwe vraag oproept (in de economie: het Jevons-paradox), of gewoon de bestaande vraag doet krimpen. De meeste werkzaamheden rond bedrijfscore-systemen vallen onder het eerste: hoe sneller je boekhoudt, hoe meer en gedetailleerdere analyses de baas wil zien. De conclusie is dus niet “automatisering verwijdert hoeveel werk”, maar “verplaats mensen en budgetten van de geautomatiseerde laag naar de nieuw ontstane laag”. (De long-tail-verplaatsing uit bedrijfssoftware-perspectief wordt volledig uitgewerkt in het bijbehorende artikel “Bedrijfssoftware Sticky”.)

Dit heeft meer te maken met software dan je denkt. In 2013 overnam Gene Kim het fabrieksgesprek van Goldratt bijna letterlijk en paste het toe op IT-operations, waarbij hij The Phoenix Project schreef: een verhaal over hoe een CIO met de Theory of Constraints een IT-afdeling redde die het hele bedrijf aan het verzwakken was. Dus “het bottleneckdenken uit de productie toepassen op software” is een reeds gevalideerde aanpak—niet slechts een tijdelijke metafoor.
制造业瓶颈转移：加宽一道，下一道就堵
第一阶段：切削是瓶颈
切削 / 下料
焊接
涂装
总装
检测
半成品堆积
整条线产出 = 切削这一站的产出（最窄环节）
引入数控机床，把切削加宽 ↓
第二阶段：瓶颈挪到了总装 / 检测
切削（已加速）
焊接
涂装
总装
检测
半成品堆积
约束理论（Goldratt, 1984）：产出由最窄环节决定；加宽它，瓶颈只搬家
软件业正在重演：写代码这道工序变便宜，瓶颈挪到需求 · 集成 · 验证 · 对齐
# 2. Terug naar software: code schrijven wordt de goedkoopste fase
Drie cijfers maken duidelijk dat de productiekosten van code naderen naar nul.

Copilot: GitHub’s eigen onderzoek toont aan dat in bestanden waar Copilot is ingeschakeld, ongeveer 46% van de code door Copilot is gegenereerd. Let op de meetmethode: dit is het aandeel binnen ingeschakelde bestanden, niet 46% van alle code op GitHub.
Stripe: Hun interne, zelfontwikkelde coding agent “Minions” levert en mergeert elke week meer dan 1.300 PR’s (vroeger 1.000, blijft stijgen). Een cruciaal detail: elke PR wordt manueel gereviewd voordat hij wordt gemerged. Stripe heeft het “schrijven” geautomatiseerd, maar het “goedkeuren” heeft hij bij de mens gelaten. Dit punt komt in sectie vier terug.
NVIDIA: Jensen Huang heeft openlijk verklaard dat 100% van de NVIDIA-engineers AI-programmeertools zoals Cursor gebruiken; “werken zonder AI” is bij NVIDIA niet langer acceptabel.

Als je deze drie cijfers op elkaar legt, is de conclusie onweerlegbaar: de kosten per regel code naderen snel nul. De scherpe vraag die hieruit voortkomt: als coderen bijna gratis is, waarom zijn softwareproducten nog steeds zo duur, traag en moeilijk te leveren? Het antwoord komt uit de beperkingstheorie: je hebt de bottleneck van “code schrijven” verbreed, maar de bottleneck is alleen verplaatst. Waarheen?

Drie: De bottlenecks zijn naar vier plaatsen verhuisd

Deze keer zijn de bottlenecks geconcentreerd in vier stappen. Elke stap is iets wat AI op korte termijn niet kan aanpakken.

Eerste stap: Het definiëren van het juiste probleem.
AI kan binnen seconden schrijven: “de functie waar je over praat”, maar het kan niet schrijven: “de functie die je werkelijk nodig hebt”. De meeste softwareprojecten mislukken omdat het resultaat niemand gebruikt — omdat het probleem vanaf het begin niet goed is begrepen. Nu codeproductie goedkoper is geworden, is het vermogen om “een vaag bedrijfsprobleem te ontleden in een duidelijke, oplosbare en waardige specificatie” (problem formulation) de meest schaarse en duurste vaardigheid geworden. Materiaalproductie-terrein is hier vertrouwd mee: als de productielijn en de technische tekeningen fout zijn, produceer je met elke efficiënte machine alleen maar afval.

Tweede stap: Systeemintegratie.
AI is goed in het genereren van “een stuk code”, “een functie”, “een pagina”. Maar een systeem dat live kan gaan, is een integratie van honderden fragmenten — ze moeten gegevens uitwisselen, randgevallen verwerken, consistentie behouden en uitzonderingen weerstaan. Het genereren van fragmenten is goedkoop; het samenvoegen tot een betrouwbaar geheel is duur. Deze kosten zitten diep in organisatie- en architectuurafstemming — precies wat de wet van Conway en teamtopologieën bestuderen (zie de eerste twee delen van deze serie). Terug naar de CIO uit de inleiding: zijn tijd is niet verbruikt aan het schrijven van code, maar aan het afstemmen van de MES-, ERP-, kwaliteitscontrole- en rapportagesystemen.

Derde barrière: Validatie. De codebase explodeert, de betrouwbaarheid varieert. Wie beslist “het is correct”? Testen, code review, observabiliteit, canary releases — het gewicht van deze “validatie”-activiteiten neemt toe, niet af. Dit is de meest onderschatte barrière, en tegelijk de diepste spiegel van de productiemethode. Paragraaf vier gaat er specifiek op in.

Vierde barrière: Organisatie-afstemming. Als AI-agents deel uitmaken van het team: wie bepaalt wat er gedaan wordt, wie controleert, wie is verantwoordelijk voor het resultaat? Dit is een uitbreiding van de wet van Conway en teamtopologieën — organisatie-afstemming zelf wordt de barrière. Artikel 11 van deze serie gaat er specifiek op in: wanneer organisatieknopen niet langer alleen mensen zijn, wordt governance een kerncompetentie.

# 4. De diepste snede: Validatie — en wat Toyota werkelijk leert met “Jidoka”

Onder de vier barrières wordt validatie het meest verkeerd begrepen. Veel mensen denken: “Als AI snel code schrijft, dan testen we gewoon vaker.” Dat is slechts de helft waar. Om te begrijpen waarom validatie duurder wordt, moet je eerst het meest misbruikte en meest verkeerd geïnterpreteerde concept van Toyota correct uitleggen: Jidoka.

Eerst corrigeren we een wijdverspreide misvatting. Jidoka is niet “AI of machines gebruiken om mensen te vervangen”, noch “mensen tot machines maken die ononderbroken werken”. Beide richtingen zijn precies verkeerd.

Het woord “jidōka” bevat al het antwoord. In het Japans betekent “automatisering” gewone automatisering, maar Toyota gebruikte specifiek “自働化”, waarbij het karakter “働” de menselijke component (de menselijke radical) bevat. Het benadrukt “automatisering met een menselijke touch”. De precieze betekenis is: wanneer een machine of productielijn een afwijking detecteert, stopt deze automatisch en laat een mens ingrijpen om de oorzaak op te lossen, waarna de productie wordt hervat. Er werken twee mechanismen parallel: de machine heeft een afwijkingsdetectie ingebouwd en stopt zelf; iedereen op de productielijn die iets ongewoons opmerkt, trekt aan de andon-touw — en de hele lijn stopt onmiddellijk. Kwaliteit wordt niet aan het einde gecontroleerd, maar ingebouwd in elke werkvorm en ter plekke opgelost.

Hier is een contraintuïtieve conclusie die direct correspondeert met software: hoe dieper de automatisering, hoe meer kwaliteitscontroles en menselijke tussenkomst nodig zijn. Jidōka bevrijdt mensen van “herhaalde handelingen” en plaatst hen opnieuw in de rol van “afwijkingen detecteren, lijn stoppen, oorzaak oplossen”. Toyota gaf aanwerkers de macht om de hele productielijn te stoppen — precies omdat het begrijpt: hoe krachtig de automatisering ook is, er moet altijd iemand zijn die kan roepen: “Stop!” Dat is de ware betekenis van het slogan “wisdom given to robots”: de machine moet de capaciteit krijgen om te stoppen en de mens te roepen. De mens blijft aanwezig — verantwoordelijk voor het oplossen van de oorzaak.

Software is retracing this path—and doing so rapidly. GitClear’s research into AI-assisted code quality has observed signs of increasing duplicate code blocks and rising short-term churn: AI writes quickly, but also writes code that “looks right.” When vast amounts of code are never manually written line by line, the traditional trust mechanism of “developers just know” breaks down. What you need now is the software equivalent of an Andon cord and stop-the-line mechanism:

Testing (unit, integration, end-to-end) is upgraded from “try to do it” to a hard gate: no merge unless it passes.
Code review shifts focus from “checking style” to “checking intent and boundaries”: what is this code actually trying to solve, and are edge cases covered?
Observability (monitoring, logging, tracing) becomes standard, because runtime behavior speaks louder than code itself.
Gray releases / feature flags let AI-generated code be validated at small scale first, and only then rolled out broadly.

Looking back at Stripe’s 1,300 PRs in Section 2: the agent writes, but the merge gate is entirely reserved for human review. This is the living embodiment of jidoka in software: automate production, but keep approval in human hands—and empower humans with the authority to “stop it.” Production has become cheaper; quality control has become more expensive. This is a rule unchanged for 40 years.
自动化回路：丰田产线 ↔ 软件 CI/CD
丰田产线（自动化，带人字旁的自动化）
机器自动运转生产自动化
检测到异常机器自停 / 拉安灯
人介入，解根因不在末端检，就地解决
恢复生产人有权喊停
→
→
→
↓ 同一套逻辑，搬到软件
软件 CI/CD（AI 时代的质量门）
AI 生成代码写，自动化
测试 / Review 卡关不过不许合并
人查意图 + 修根因查边界、可解释
合并 / 灰度放量先小范围验
→
→
→
生产自动化，验收留给人的”停线权”，自动化越深质量门越要紧
Stripe Minions：每周 1,300+ PR 由 agent 写，全部人工 review 后才合并
自动化 ≠ 用 AI 替代人；自动化 ≠ 让人变成机器
= 异常停线 + 人介入解根因（automation with a human touch）

Vijf: De premie van “probleemdefinitie”: Een vaardigheid waardiger dan prompten

Als validatie een onderschatte bottleneck is, dan is “probleemdefinitie” een ernstig onderschatte vaardigheid. Prompt engineering was even populair, en veel mensen dachten dat “prompten kunnen schrijven” de kernvaardigheid was. Maar een prompt is slechts een techniek om een probleem te formuleren. Het echte schaarse vermogen ligt een stap verder: problem formulation — het opdelen van een vaag zakelijk probleem in een duidelijk, oplosbaar en waardig te oplossen probleem. Deze stap kan AI op korte termijn niet doen, omdat het eerst moet weten wat het probleem is.

Oude meesters uit de productie hebben het beste gevoel voor het belang van deze stap. Als een technische tekening of een productielijn verkeerd is gedefinieerd, dan produceer je, hoe efficiënt de volgende stappen ook zijn, gewoon een grote hoeveelheid fouten. Hetzelfde geldt voor software: als de vereisten verkeerd zijn gedefinieerd, dan bouwt AI tien keer sneller iets dat niemand wil.

Een eenvoudige test: Stop met concurreren over hoe snel je code schrijft; oefen in hoe duidelijk je problemen kunt opdelen. In organisaties betekent dit: maak “vereistedefinitie” en “validatie/acceptatie” officiële functies — laat ontwikkelaars dit niet meer als bijzaak doen. Nadat AI de implementatie goedkoper heeft gemaakt, stijgen de opbrengsten van deze twee functies het snelst.

Zes: Hoe zien de echte bottlenecks in vier sectoren eruit?

Als je het concept van “bottleneckverschuiving” toepast op vier sectoren, dan ligt de bottleneck in elk geval niet in het schrijven van code.

Manufacturing. De kern is de CIO uit de inleiding. Functies als intelligente productieplanning, kwaliteitstracering en energieverbruiksoptimalisatie zijn technisch niet moeilijk — veel modellen zijn al beschikbaar. De bottleneck ligt in de integratie en afstemming van MES/ERP/controle/rapportagesystemen, en in de praktijkvalidatie op het productievloerapparaat. De code voor dergelijke projecten wordt vaak snel geschreven, maar de integratie van MES/ERP-systemen neemt vele malen meer tijd in beslag dan het schrijven van de code zelf. Alleen als de acceptatiefase direct wordt geplaatst bij de productie-eindapparaten en de integratie, kunnen fouten ter plekke worden opgepakt — en niet pas bij productie-start worden ontdekt.

Telecom / Operators. Een enkel abonnementwijziging of het activeren van een zakelijke专线 (dedicated line) loopt door meerdere domeinen: kanalen, facturering, CRM, netwerkactivering en montagewerking. AI heeft de ontwikkeling in elk domein versneld, maar de end-to-end integratie en consistentievalidatie tussen domeinen vormen nog steeds het grootste tijdsblok. Een unieke bottleneck bij operators is compliance en reconciliatie. Een verschil van één cent in facturering is een incident — de validatie heeft hier een groter gewicht dan in welke sector ook. Bij het activeren van een zakelijke专线 bijvoorbeeld: hoewel AI de ontwikkeling in elk domein versnelt, blijft de end-to-end integratie plus facturatie-reconciliatie vaak meer dan de helft van de projecttijd in beslag nemen.

Financieel. Een aanpassing aan een kredietrisicobeheer- of anti-witwasregel reikt door over App, coresystemen, risicobeheerengine, data-platform en regelgevende rapportages. De validatie hier heeft een extreem hoog gewicht, want één fout kan leiden tot een compliance-incident. De bottleneck ligt in interpreteerbaarheid, auditabiliteit en traceerbaarheid: hoe nauwkeurig ook de regels die AI schrijft, als ze niet kunnen antwoorden op de vraag van de regelgever “Waarom is dit zo beslist?”, komen ze niet live. De iteratie van anti-witwasregels is een typisch voorbeeld: AI versnelt het schrijven van regels, maar het interpreteerbaarheidsreview en de afstemming met regelgevende rapportages nemen vaak de grootste helft van de hele cyclus in beslag.

E-commerce. Een promotie- of grote verkoopfunctie reikt door over producten, transacties, marketing, magazijnen en klantenservice. AI maakt het genereren van pagina’s en API’s razendsnel, maar de bottleneck verschuift naar loadtesten, voorraadconsistentie, risicobeheer tegen fraude en reconciliatie. Wat op de avond van een grote verkoop uitvalt, is nooit de code die te traag werd geschreven, maar de niet-gecontroleerde randgevallen. De voorbereiding op een grote verkoop is een microcosmos: de AI kan de promotiepagina snel genereren, maar end-to-end loadtesten en voorraadconsistentievalidatie nemen vaak de meeste werkuren in beslag.

De gemeenschappelijke kenmerken van deze vier sectoren zijn duidelijk: AI versnelt het “schrijven”, maar het “samenvoegen, verifiëren en afstemmen” zijn de knelpunten. De bespaarde ontwikkelcapaciteit investeren in deze drie dingen is echte efficiëntieverhoging. # 7. Wat als je het verkeerd beoordeelt: drie meest voorkomende misalignments

Eerste: “Snel code schrijven” gelijkstellen met “snellere levering”.
Dit is de meest voorkomende illusie. Code is slechts één stap in de leveringsketen; het verbreden van die stap maakt de hele keten niet sneller — het zorgt alleen voor meer halfafgewerkte producten achter de bottleneck. De theorie van beperkingen noemt dit voorraad; in software noemen we het niet-goedgekeurde PR’s en niet-geïntegreerde branches. Het resultaat: ontwikkelaars zijn drukker, de business is dringender, maar de output blijft hetzelfde — precies de situatie van de CIO uit de inleiding.

Tweede: Versnellen van productie terwijl kwaliteitscontroles worden verwijderd.
Dit is een typische schending van jidoka. Sommigen denken: “AI schrijft snel en goed, dus code review kan worden vereenvoudigd en tests kunnen worden weggesneden.” Juist het omgekeerde is waar: hoe sneller de productie, hoe belangrijker de anzen-snoer. Weghalen van acceptatiecontroles is gelijk aan een productielijn volledig laten draaien zonder iemand erbij — defecten stromen sneller naar productie.

Derde: Geld uitgeven op niet-bottlenecks.
Integratie is de bottleneck, maar je koopt meer AI-programmeringslicenties; validatie is de bottleneck, maar je werven meer ontwikkelaars. De theorie van beperkingen is duidelijk: investeren in niet-bottlenecks levert geen extra output op — het maakt de boekhouding alleen slechter. De juiste volgorde: eerst de bottleneck identificeren, dan alle middelen daarop richten.

VIII. Implicaties voor beslissers

Inzicht 1: Teken eerst een bottleneckkaart voordat je tools koopt.
Breek de laatste drie keer dat je vastliep op: waar is de tijd echt heen gegaan? Was het moeilijk om code te schrijven, of om onderdelen samen te voegen, of ontbrak er validatie, of was de requirement onduidelijk? Als je het niet kunt markeren, gok je op technische laag. Een bottleneckkaart is waardevoller dan elke tool-aankooplijst: ze voorkomt minstens de helft van de onnodige IT-investeringen in grote bedrijven.

Inzicht 2: Investeer de vrijgemaakte capaciteit in requirements en validatie.
AI maakt ontwikkeling sneller — dat betekent dat je mensen vrijmaakt. Zet die mensen formeel aan in de rollen “requirements definiëren” en “validatie & acceptatie”, en laat ze niet verder code blijven schrijven. De return op deze twee rollen stijgt het snelst in het AI-tijdperk.

Inzicht 3: Geef je software een Andon-touw.
De meest directe toepassing van zelfstandigheid is het instellen van harde grenzen in je CI/CD: geen merge als tests falen, review moet intentie en grenzen controleren, gray release eerst op kleine schaal, observabiliteit wordt standaard. Hoe meer je productie automatisert, hoe sterker je deze poort moet maken. Zo voorkom je dat “gratis code” uitmondt in “gratis incidenten”.

Inzicht 4: Herpositioneer mensen, verwijder ze niet.
Zelfstandigheid leidt tot één conclusie: hoe dieper de automatisering, hoe belangrijker de menselijke rol in “oordelen, accepteren, root cause analyseren”. Bevrijd mensen van herhaalde handelingen en herschik ze naar validatie en alignment — dit is het kernprincipe van organisatieontwerp in het AI-tijdperk, en het onderwerp van de komende artikelen in deze serie.

IX. Je zou je misschien afvragen

“We only pilot AI in a small area—why map the entire company’s bottleneck?”
Even a pilot must start with clarity: Is the环节 you’re piloting AI on actually the bottleneck? If the real constraint lies in integration or validation, then piloting AI on “writing code” is throwing money at the wrong spot—exactly the third mismatch described in Section 7. Do a small-scale bottleneck diagnosis first; only then will your tool investment be worthwhile.

“Won’t the validation gate slow down delivery?”
Short-term friction, long-term acceleration. The “speed” without a validation gate is just speed pushing defects into production—rework costs start at tenfold. From automation experience: fixing a defect on the spot costs a fraction of fixing it downstream.

“How does this relate to our AI transformation?”
Directly. The most common pitfall in AI transformation is assuming the bottleneck is in “coding / capacity,” then buying tools to widen that single link. First diagnose the bottleneck—then decide where to spend. That’s why I placed “capability assessment” and “value scenario identification” early in the AI Transformation 7-Step Coaching Framework: identify the bottleneck before talking about tools.

Omgekeerde zelfcontrole (antwoord zonder versiering): Waar heb je onlangs het meeste tijd doorgebracht bij een vastgelopen levering: bij het schrijven van code, of bij het samenvoegen, controleren en afstemmen? Hoeveel van de code die je AI-hulpmiddelen produceren, komt stabiel live en wordt daadwerkelijk gebruikt door gebruikers? Heeft je CI/CD-pijplijn een harde gate waarbij “geen merge toegestaan als tests falen”? Als je bij één van deze drie vragen ongemakkelijk voelt, stop dan eerst met het kopen van meer AI-hulpmiddelen en zoek eerst je bottleneck.

Volgende stap

Dit is het derde deel van de 15-delige serie “Software Engineering Transformations in the AI Era”. We gingen van Conway (organisatie bepaalt architectuur) en Team Topologies (hoe je organisaties ontwerpt) naar bottleneckverschuiving (wanneer code bijna gratis is, waar is de bottleneck dan heen?). De volgende aflevering (deel 4) wisselt naar een praktischer perspectief: hoe kies je de meest gebruikte AI-programmeertools. Maar de conclusie kan tegenintuïtief zijn: keuze van tools is uiteindelijk een organisatiebeslissing — kies op basis van je volwassenheid en governance, niet op basis van “wie de meest imponerende code schrijft”.

Serietoelichting: Deze serie volgt de nieuwste ontwikkelingen in AI-programmeertools, organisatiestructuren en software engineering paradigma’s, zoals de evolutie van Conway’s wet in de tijd van AI-agents in 2026, of de volwassenheid van de nieuwste tooling-ecosystemen. Volg deze serie voor continue inzichten.

Over deze serie

De serie “De transformatie van software engineering in het AI-tijdperk” is een diepgangsonderzoek bestemd voor CIO’s, CDO’s en CTO’s en digitale verantwoordelijken uit de telecom-, financiële, productie- en e-commerce-sector, en bestaat uit 15 artikelen. Gebaseerd op 200+ wetenschappelijke artikelen en industrierapporten, biedt het beslissingsondersteuning met expliciete bewijsniveaus.
Ik ben een voormalige IBM-engineer en ICF-gecertificeerde coach die AI- en digitale projecten heeft uitgevoerd bij telecombedrijven en grote ondernemingen. Alles wat hier staat, is het praktische oordeel van iemand die bedrijven heeft begeleid door hun fouten heen.

Referenties (allemaal gecontroleerd)

a16z (2026). Software in the Age of Agents. The a16z Podcast. (Steven Sinofsky, voormalig president van Microsoft Windows: „The long tail got no shorter, it just got longer in a different way“ — een onafhankelijke bevestiging van de wet van de verplaatste TOC-bottleneck uit het oogpunt van bedrijfssoftware; primaire bron — originele podcast-opname. Standpunt: a16z-partner / voormalig Microsoft-executief, VC-standpunt. Gasten gecontroleerd: a16z Enterprise-team partner Seema Amble, voormalig Microsoft Windows-president Steven Sinofsky (board partner), a16z-auteur Elena Burger; uitgezonden juli 2026.)
Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement. (Oorspronkelijke bron van de Theory of Constraints (TOC); primaire bron; roman met als setting een productiefabriek.)
Kim, G., Behr, K. & Spafford, G. (2013). The Phoenix Project. IT Revolution Press. (Overneemt Goldratts TOC letterlijk naar IT-operations; de brug van productie naar software; primaire bron.)
Toyota. Toyota Production System — Jidoka (自働化). toyota-global.com (Jidoka = automatisering met het teken voor „mens“; stilstand bij afwijking + menselijke interventie om de oorzaak op te lossen; Andon-systeem; primaire bron.)
GitHub (2022/2024). The Economic Impact of the AI-Powered Developer Lifecycle. (Copilot activeert ongeveer 46% van de code-invoer binnen het bestand; meting op basis van „enabled file-level“; primaire bron.)
Stripe (2025/2026). Minions: Stripe’s one-shot, end-to-end coding agents. stripe.dev/blog; InfoQ rapporteert >1.300 PR’s per week, volledig menselijk review (primaire + secundaire bron.)
NVIDIA / Jensen Huang. Openbare verklaring dat 100% van de ingenieurs AI-programmeertools zoals Cursor gebruiken (rechtstreekse uitspraak.)
GitClear (2025). AI-Assisted Code Quality Research. (Waargenomen toename van herhaalde code / kortetermijn churn onder AI-ondersteuning — ondersteunt de stelling dat „validatie duurder wordt“; secundaire bron.)
Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate. IT Revolution Press. (Leveringsprestaties worden bepaald door cultuur, stroomsnelheid en feedback — niet door individuele coderingssnelheid; primaire bron.)