"Programmeren is opgelost"? De flikkerende bug zegt van niet

"Programmeren is opgelost"? De flikkerende bug zegt van niet

Dit is het ding dat niemand die de "programmeren is opgelost"-lijn pusht naast zijn slidedeck wil zetten: de meest besproken AI-codingtool ter wereld werd geleverd met een scherm-flikkerbug, en het kostte ruwweg een jaar aan patches, een rollback, en uiteindelijk een workaround-die-nog-steeds-achter-een-feature-flag-zit voordat iemand het afgehandeld kon noemen.

Geen hardwareprobleem. Geen infrastructuurprobleem. Geen of andere nare distributed-systems race condition die een onderzoeksteam nodig had. Een terminal-hertekeningbug. Het soort ding dat een competente engineer in een middag fixt — behalve dat deze twee modelgeneraties overleefde.

Ik wil even bij die kloof stilstaan, want het is het hele argument.

Het verhaal dat ik steeds hoor — op X, in podcasts, in die ademloze "het tijdperk van de software engineer eindigt"-threads — gaat zo: handmatig prompten is dood, programmeren is in feite een opgelost probleem, en de slimme zet nu is om te stoppen met code schrijven en te beginnen met het schrijven van loops die een AI door promptcycli jagen tot een of andere winstconditie bereikt wordt. Het moeilijke dat overblijft, zegt het verhaal, is infrastructuur, gebruikersfeedback en hardware. Programmeren? Dat is het makkelijke deel. Dat is klaar.

Ik gebruik elke dag AI-codingtools. Ik ben hier niet om je te vertellen dat ze niet werken — dat doen ze absoluut, en ik zal je precies laten zien waar. Maar "programmeren is opgelost" is het soort bewering dat slim klinkt in een keynote en uit elkaar valt zodra je naar de bonnetjes wijst. En het schoonste bonnetje dat ik heb is een bug die zo saai is dat hij het punt bijna vanzelf maakt.

Laten we erin duiken.

Wat "programmeren is opgelost" eigenlijk beweert (en wie het zegt)

Voordat ik een standpunt aanvecht, wil ik het zo sterk formuleren als de mensen die het aanhangen zouden doen. Eerst steelmanning. Het is de enige eerlijke manier om dit te doen.

De meest volledige versie van het argument komt van binnen Anthropic zelf. Boris Cherny — de maker van Claude Code — zei in interviews medio 2026 dat AI programmeren praktisch heeft opgelost, en dat hij al acht maanden geen enkele regel code met de hand had geschreven (Fortune, juni 2026). De framing die daaromheen groeide is nog scherper: stop met Claude één bericht tegelijk te prompten, luidt het argument — bouw loops. Construeer een harnas dat het model laat observeren, plannen, handelen en reflecteren over uren, soms dagen, iterend tegen tests en acceptatiemetrieken tot het convergeert naar een slagende staat (explainx.ai's uiteenzetting van de harnas-engineering-these).

In die wereldvisie verschuift de taak van de mens. Je schrijft geen functies. Je schrijft de scoringsfunctie — de winstconditie — en de loop slijpt ernaartoe. Een beter model kiezen is de verkeerde variabele optimaliseren; betere feedbackinfrastructuur bouwen is het echte spel. Ik heb zelf geschreven over de mechanica van deze aanpak in mijn eigen analyse van langlopende agent-harnassen, en ik zeg ronduit: als techniek is het echt en het is krachtig.

Dan is er het getal dat iedereen citeert. Anthropic rapporteerde dat regels code gemerged per actieve bijdrager ruwweg 8x de pre-2025 baseline bereikte tegen Q2 2026 — in sommige navertellingen geframed als "twee jaar codingoutput, elk kwartaal, per persoon" (OfficeChai). Tegen mei 2026 schreef Claude naar verluidt meer dan 80% van de gemerged productiecode intern (VentureBeat).

Dat is een werkelijk verbijsterende reeks beweringen. Als ik hier stopte, zou je de tab sluiten overtuigd dat programmeren klaar was.

Dus waarom ben ik niet overtuigd? Vanwege een detail verborgen in Anthropic's eigen aankondiging — en vanwege een bug. Laten we eerst het detail pakken.

De kanttekening die Anthropic in zijn eigen voetnoot plaatste

Hier is iets dat de hype-threads bijna nooit meenemen, en het is de eerlijkste zin in het hele gesprek.

Toen Anthropic het 8x-cijfer publiceerde, waarschuwde het eigen blogbericht van het bedrijf dat het getal "vrijwel zeker een overschatting" was, omdat het tellen van coderegels volume beloont, niet kwaliteit — en de per-PR regelaantallen moesten worden afgetopt op het 99e percentiel alleen al om uitbijters te filteren (zoals gerapporteerd in de productiviteitscoverage).

Lees dat nog eens. De organisatie die het sterkste "programmeren is opgelost"-argument maakt, hechtte een waarschuwingslabel aan haar eigen koptitelmetriek. Regels code is een berucht kapotte proxy — elke engineer die lang genoeg meedraait weet dat meer code vaak slechter is, niet beter. Een tool die je acht keer de diff laat genereren is niet vanzelfsprekend een tool die programmeren heeft opgelost. Het is misschien gewoon een tool die typen heeft opgelost.

En dat is de naad waar ik aan wil trekken. Want er is een verschil tussen drie beweringen die door elkaar lopen als mensen zeggen "programmeren is opgelost":

1. AI versnelt codeproductie. Waar. Overduidelijk, meetbaar waar.
2. AI verbetert codekwaliteit bij goed gebruik. Vaak waar, met echte kanttekeningen.
3. Programmeren, als moeilijk menselijk probleem, is klaar. Dit is de sprong. En hij overleeft het contact met het bewijs niet.

De eerste twee zijn echte vooruitgangen. Ik zou iedereen bestrijden die een junior dev vertelde deze tools te negeren. Maar de derde bewering — de klaar-bewering — is waar de marketing de machine voorbijrent. En het bewijs is niet een of ander filosofisch bezwaar over creativiteit of vakmanschap. Het is veel gênanter dan dat. Het is een flikker.

De flikkerbug die niemand stilletjes kon fixen

Als programmeren was opgelost — als je gewoon een loop op een probleem kon richten en het naar een winstconditie kon laten slijpen — dan zou het best uitgeruste AI-codingteam ter wereld, dat zijn eigen tool dogfoodt, 80% van zijn code schrijft met precies het model in kwestie, een terminal-renderingbug zonder hapering moeten kunnen verpletteren.

Dat is niet wat er gebeurde.

Claude Code is een terminal-app — agentische AI-coding die in je commandoregel leeft, uitgebracht in februari 2025. Vanaf het begin had het een berucht scherm-flikkerprobleem. De terminalinhoud scrollde snel, schudde en flitste tekst van eerder in de sessie — veroorzaakt doordat de renderer de hele terminalbuffer opnieuw tekende bij elke streaming-update in plaats van regelspecifieke, incrementele updates te doen. Je kunt het spoor zelf nalezen in een kerkhof van GitHub-issues: #769, en een lange staart van follow-ups zoals #16939, #18084, en #18827, verspreid over Windows Terminal, VS Code, Cursor, en de geïntegreerde terminals van Android Studio.

Let nu op de tijdlijn, want de tijdlijn is het argument:

• Begin 2025 en verder: Flikker herhaaldelijk gemeld. Bijzonder brutaal in xterm.js-gebaseerde terminals (VS Code, Cursor), waar het volledige-buffer hertekenen 2–3 keer per seconde het scherm deed stroboscoperen.
• Rond december 2025: Anthropic adresseert het publiekelijk, naar verluidt claimend een grote flikkerreductie met een herschreven differentiële renderer — ruwweg een derde van de sessies zag nog minstens één flikker, volgens gemeenschapsrapporten van de uitrol.
• Kort daarna: Instabiliteit. Een flikkervrije renderingwijziging werd uitgerold, en een regressie volgde — issue #41965 documenteert v2.1.89's "flikkervrije" alt-screen rendering die standaard terminal-scrollback vernietigde. De fix creëerde een nieuw probleem. Dingen werden teruggedraaid. Eind 2025: nog steeds niet schoon opgelost.
• Rond 1 april 2026: Een "no flicker mode" arriveert — CLAUDE_CODE_NO_FLICKER=1 — met een alternate-screen-buffer aanpak, dezelfde truc die Vim gebruikt wanneer het je terminal overneemt en hem onaangetast teruggeeft als je afsluit (piunikaweb). Het werkt. Maar het is een omzeiling, geen root-cause fix: het omzeilt het hertekeningsprobleem door ergens anders te renderen. En het werd geleverd als een research preview, achter een feature flag, met een begeleidende flag om muisregistratie uit te schakelen omdat dat zijn eigen wrijving introduceerde.
• Eind mei 2026: Een nieuwere terminalinterface toonde nog steeds niet-informatieve, "mysterieuze" foutmeldingen — de foutafhandeling zelf ongepolijst.

Eén onafhankelijke engineer noemde zijn uiteenzetting "De fix waar een jaar aan gewerkt is." Iemand anders bracht een patch van een derde partij uit genaamd Claude Chill alleen om met de flikker om te gaan, en het haalde de voorpagina van Hacker News. Wanneer gebruikers externe tools bouwen om je rendering te fixen, is de rendering niet opgelost.

Dit is waarom deze ene bug zoveel gewicht draagt: er is geen hardware-excuus. Geen infrastructuur-excuus. Geen "het echte moeilijke deel zit ergens anders"-ontsnappingsluik. Schermflikkering in een terminal is een puur, op zichzelf staand softwareprobleem — precies de categorie waarvan het "programmeren is opgelost"-verhaal zegt dat het het makkelijke deel is, het afgeronde deel. En het kostte een jaar, een rollback, en een flag-gated workaround bij het bedrijf dat het best gepositioneerd is op aarde om het te fixen.

Als programmeren was opgelost, was deze bug in een weekend gestorven. Dat gebeurde niet. Dat is geen gotcha. Dat is data.

"Schrijf gewoon loops" werkt — tot het de onglamoureuze bug ontmoet

Ik wil eerlijk zijn over de loop-these, want ik vind hem oprecht goed. Ik draai loop-gebaseerde automatisering in mijn eigen werk — ik heb geschreven over het plannen van Claude Code in cron loops en over de bredere verschuiving van een handmatige SDLC naar een agentische ontwikkelingslevenscyclus. Wanneer het probleem een heldere, machinaal controleerbare winstconditie heeft — tests slagen, types kloppen, de benchmark wordt groen — is een goed gebouwde loop een prachtig ding om naar te kijken. Het convergeert. Het is het dichtste bij "stel de scoringsfunctie in en loop weg" dat ik heb ervaren in vijftien jaar software schrijven.

Maar merk de vorm op van de problemen waar loops uitblinken: ze hebben allemaal een duidelijke winstconditie.

Een flikkerende terminal heeft dat niet. Wat is de test die groen wordt? "Het ziet er minder schokkerig uit voor een menselijk oog over veertig verschillende terminalemulators, elk met zijn eigen renderer, op drie besturingssystemen, bij variërende verversingssnelheden"? Daar is geen assertie voor. Geen expect(screen).not.toFlicker(). De winstconditie is vaag, omgevingsafhankelijk en deels subjectief — wat precies is waarom een jaar loops het er niet uit kon slijpen. De loop is slechts zo slim als de scoringsfunctie die je kunt schrijven, en sommige van de belangrijkste softwareproblemen zijn precies degene die je niet schoon kunt scoren.

Dat is het deel dat de "programmeren is opgelost"-framing overslaat. Het neemt stilzwijgend aan dat elk overgebleven probleem eruitziet als een unit test. De meeste moeilijke niet. Ze zien eruit als flikker. Ze zien eruit als "de foutmelding is technisch correct maar vertelt de gebruiker niets." Ze zien eruit als de project-load kwetsbaarheid die onderzoekers vonden in het bronlek, waar API-verzoeken afvuurden voordat de vertrouwensprompt verscheen — een ontwerpoverzicht dat geen test ving omdat niemand eraan dacht ervoor te scoren.

Als je liever hebt dat iemand deze agentische loops goed bouwt en onderhoudt — met de vangrails en de saaie-maar-kritieke foutafhandeling die de demo's overslaan — dat is een flink deel van wat ik op me neem. Je kunt zien wat ik heb geleverd op fiverr.com/s/EgxYmWD.

Dus de loop is niet fout. Hij is smal. Het is een fantastisch gereedschap voor het goed gespecificeerde midden van de probleemruimte en nutteloos aan de vage randen — en de vage randen zijn waar software daadwerkelijk breekt in productie. Dat "opgelost" noemen is het deel dat je kunt meten het hele werk noemen.

De menselijke kosten van doen alsof het moeilijke deel voorbij is

Nu wil ik praten over het deel dat me echt dwarszit, want de bug is slechts het bewijs — dit zijn de belangen.

Het "programmeren is opgelost, ship gewoon naar prod, schrijf de loop, haal de winstconditie"-verhaal landt niet in een vacuüm. Het landt op ontwikkelaars die, op dit moment, meer opgebrand en angstiger over hun baan zijn dan ik ze in lange tijd heb gezien. En de boodschap maakt beide erger.

Hier is het wrede mechanisme, en het is goed gedocumenteerd. Wanneer organisaties besluiten dat AI programmeren triviaal heeft gemaakt, sparen ze de bespaarde tijd niet op als slack — ze behandelen elke bespaarde minuut als een minuut die terugverschuldigd is als meer output. PR-volume springt 40–60% omhoog, en het knelpunt verschuift gewoon downstream naar review. Nu verdrinken dezelfde mensen in code die ze niet hebben geschreven, niet volledig kunnen vertrouwen, en onder druk staan om snel goed te keuren. Dat is niet minder burnout. Het is een nieuw, erger soort burnout, en het treft de mensen die AI het hardst omarmd hebben. Er is zelfs een heel genre van "AI zou developer-burnout fixen" post-mortems nu, wat je vertelt hoe het experiment verloopt.

Zet de twee helften bij elkaar en de oneerlijkheid wordt scherper. Management hoort "programmeren is opgelost" en stelt verwachtingen alsof het waar is. Ontwikkelaars leven in de kloof tussen die bewering en de flikkerende, foutmeldingen-spuwende, af en toe kapotte realiteit — en krijgen de schuld voor de kloof. Je krijgt te horen dat het moeilijke deel voorbij is terwijl je je dinsdag besteedt aan het debuggen waarom de loop met vertrouwen iets subtiel fouts heeft geleverd, met een foutmelding die niets uitlegde.

Er circuleert een botte metafoor voor dit soort berichtgeving — dat iemand iets met je been doet en volhoudt dat het het weer is. Ik houd het netjes, maar het sentiment klopt. Opgebrande engineers vertellen dat hun harde, echte, nog steeds noodzakelijke werk "het makkelijke deel" is — terwijl ze opruimen achter precies de tools die een oplossing worden genoemd — is geen optimisme. Het is gaslighting vermomd als een productiviteitsstatistiek.

En ik zeg dit als iemand die openlijk, bijna beschamend verslaafd is aan Claude Code. Ik ben niet de weerstand. Ik ben een zware gebruiker die je vertelt dat de marketing cheques uitschrijft die de tooling nog niet kan verzilveren.

Wat echt opgelost is, wat echt niet

Laat me specifiek zijn, want vage pessimisme is net zo nutteloos als vage hype. Hier is mijn eerlijke grootboek na dagelijks gebruik van deze tools door 2025 en in 2026.

Echt versneld door AI vandaag:

• Boilerplate, scaffolding, lijmcode, configuratie — bijna instant, bijna foutloos.
• Goed gespecificeerde refactors met sterke testdekking — loops vernietigen deze.
• Intentie vertalen naar een eerste versie — wat 45 minuten kostte duurt 6.
• Een onbekende codebase of API verkennen — sneller dan documentatie.

Echt verbeterd, met kanttekeningen:

• Codekwaliteit, wanneer je het harnas hebt gebouwd (tests, lint, types, acceptatiemetrieken) waar de loop tegen kan scoren. Geen harnas, geen kwaliteitswinst — alleen snellere rommel.

Echt NIET opgelost:

• Vage, niet-scorbare problemen — rendering over heterogene omgevingen, UX-polijsting, "dit is technisch correct maar voelt fout."
• Foutafhandeling en failure-mode ontwerp — de onglamoureuze 80% die demo's nooit laten zien, en waar Claude Code zelf nog struikelt.
• Weten wat je moet bouwen, en of het überhaupt zou moeten bestaan.
• Het oordeel om de loop te overrulen wanneer zijn winstconditie subtiel het verkeerde doel is.

Merk op dat de "niet opgelost"-kolom precies is waar de flikkerbug leeft. Dat is geen toeval. De bug is geen uitbijter — het is een representatief voorbeeld van het werk dat de hype klaar verklaarde.

Dus is programmeren opgelost? Nee — en het eerlijke antwoord is nuttiger dan de hype. Programmeren is versneld, soms dramatisch. De goed gespecificeerde delen zijn steeds meer automatiseerbaar door loops. Maar de harde, vage, oordeelszware kern — het deel dat software engineering een beroep maakt en geen typsnelheidswedstrijd — is precies zo onopgelost als het was, en de eigen bugtrackers van de tools bewijzen het.

Veelgestelde vragen

Is programmeren daadwerkelijk opgelost door AI in 2026?

Nee — programmeren is dramatisch versneld, niet opgelost. AI-tools blinken uit bij goed gespecificeerde, machinaal controleerbare taken (boilerplate, refactors, tests die slagen) maar worstelen nog steeds met vage, niet-scorbare problemen zoals cross-omgeving rendering, UX-polijsting en failure-mode ontwerp. Het bewijs is dat zelfs AI-codingtools geleverd worden met langlevende bugs die hun eigen loops niet kunnen fixen.

Wat betekent "schrijf gewoon loops" in AI-coding?

"Schrijf gewoon loops" verwijst naar harnas-engineering — in plaats van een AI één bericht tegelijk te prompten, bouw je een systeem dat het model door herhaalde observeer-plan-handel-reflecteer-cycli laat lopen tot het een gedefinieerde winstconditie bereikt zoals slagende tests. Het is een oprecht krachtige techniek, maar het werkt alleen waar je een duidelijke scoringsfunctie kunt schrijven, wat veel real-world problemen uitsluit.

Waarom is de Claude Code flikkerbug significant?

De flikkerbug is een puur softwareprobleem zonder hardware- of infrastructuurexcuus, maar het kostte ruwweg een jaar, een rollback, en een flag-gated workaround om aan te pakken — bij het bedrijf dat het best gepositioneerd is om het te fixen. Dat maakt het het schoonste tegenvoorbeeld van de bewering dat "programmeren het makkelijke deel is" van moderne software. Voor de volledige tijdlijn, zie het gedeelte hierboven.

Veroorzaakt AI-coding developer-burnout?

Rapporten en post-mortems door 2026 suggereren van wel — niet omdat AI minder werk doet, maar omdat organisaties bespaarde tijd omzetten in meer output, PR-volume met 40–60% opdrijven en de last verschuiven naar overweldigde code-review. Het "programmeren is opgelost"-verhaal verergert dit door verwachtingen te scheppen die niet overeenkomen met de rommeligre realiteit waar ontwikkelaars daadwerkelijk mee te maken hebben.

Het bonnetje waar ik steeds op terugkom

Ik opende met een flikkerende terminal, dus laat me daar afsluiten.

Wanneer iemand je vertelt dat programmeren is opgelost, stel ze dan één vraag: als dat waar is, waarom besteedden de mensen die het het hardst zeggen een jaar aan het fixen van een scherm dat niet wilde stoppen met schudden — en leverden ze de fix vervolgens achter een feature flag? Er is geen hardware om de schuld te geven. Geen infrastructuur om achter te schuilen. Gewoon een moeilijk, onglamoureus softwareprobleem dat doet wat moeilijke softwareproblemen altijd hebben gedaan: zich verzetten tegen de mensen die het onderschatten.

Gebruik de tools. Bouw de loops. Ship sneller — ik doe het, elke dag, en ik ben er beter van. Maar houd de lijn op de waarheid: programmeren is niet opgelost, het is versterkt. Het moeilijke deel is niet verdwenen. Het is verhuisd naar waar de loops niet kunnen reiken, en het is nog steeds van jou.

En eerlijk gezegd? Dat is goed nieuws. Want het betekent dat het oordeel dat je jarenlang hebt opgebouwd het deel is dat niet geautomatiseerd werd — het is het deel dat waardevoller werd. Laat een productiviteitsslide je niet van het tegendeel overtuigen.

Vanavond is dit het enige dat de moeite waard is: de volgende keer dat je een bug tegenkomt die je AI met vertrouwen niet kon fixen, voel je dan niet achter. Maak er een screenshot van. Die bug is het deel van het werk dat nog steeds van jou is — en het is het deel dat betaalt.

Laten we samenwerken

Wil je AI-systemen bouwen, workflows automatiseren of je technische infrastructuur opschalen? Ik help je graag.

• Fiverr (maatwerk builds & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise-oplossingen): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io