Karpathy noemt het de verandering: niet sneller programmeren, maar meer programmeren

Jarenlang ging praten over code-assistenten vooral over autocompletitechnologie: kleine, nuttige suggesties, maar beperkt. De afgelopen weken is er echter een levendige discussie ontstaan rondom Andrej Karpathy (onderzoeker en spreker op het gebied van AI) en Boris Cherny (verantwoordelijk voor Claude Code bij Anthropic), die een idee definitief deed kristalliseren dat veel engineers stilletjes al aanvoelden: programmeren bevindt zich in een nieuwe fase.

Het gaat niet alleen om “hetzelfde doen, maar in minder tijd”. De echte sprong — die gewoonlijk de gewoonten verandert — is dat het werk schaalbaarder wordt. Waar vroeger een persoon zich beperkte tot “de taken die er toe doen”, openen zich nu projecten die vroeger simpelweg niet werden geprobeerd. Niet door gebrek aan visie, maar door tijdsgebrek, energie of kennis van perifere vakgebieden.

Van 20% naar 80%… in enkele weken

Karpathy beschrijft een overgang die misschien overdreven klinkt tot je het hebt meegemaakt: van een workflow gedomineerd door handmatig schrijven (met enige autocompletie) naar een situatie waarin agents het grootste deel van het werk doen, terwijl de mens fungeert als redacteur, supervisor en eindverantwoordelijke. Het voelt dubbel: enorme kracht… en een beetje een deuk in het ego. “Programmeren in het Engels” — instructies geven en succescriteria aangeven in plaats van elke regel te typen — voelt in het begin vreemd, maar wordt verslavend als het begint te werken.

Deze overgang rust bovendien niet op “toverkunst”. Het is gebaseerd op iets heel praktisch: grote operaties op een bestaande codebasis (volledige refactors, transversale wijzigingen, instrumentatie, tests) die vroeger een geconcentreerde inspanning en ijzeren geduld vereisten.

Snelheid versus expansie: de ultieme verklaring

Het meest interessante in het debat is niet of er tijd gewonnen wordt (dat gebeurt zeker), maar wat er met die tijd gebeurt. Karpathy vat het samen met een herkenbaar idee: het belangrijkste effect is niet dat je sneller werkt, maar dat je ‘de kaart uitbreidt’. Met assistenten die technische hiaten invullen, durven generalisten taken aan die meerdere disciplines combineren: videopipelines, automatisering via commandoregel, modelintegratie, deployment, documentatie, zelfs onderwijs of productbeheer.

Met andere woorden: de beperkende factor is niet meer altijd “kunnen schrijven”, maar wel wat je bouwt, hoe je het valideert en wat je niet toelaat.

Modellen blijven fouten maken, maar ‘beter’ (en dat is gevaarlijk)

Hier komt de kernwaarschuwing naar voren: degenen die juichen over het “geen IDE nodig” of de “zwermen van agents”, rushen mogelijk te snel. Karpathy benadrukt dat de modellen nog steeds fouten maken, maar dat de aard ervan is veranderd: het zijn niet meer duidelijke syntaxfouten, maar subtiele conceptuele misverstanden, vergelijkbaar met die van een junior ontwikkelaar in haast.

Er zijn herkenbare patronen:

  • Ze nemen aannames die niemand goedgekeurd heeft.
  • Ze verwerken verwarring slecht: vragen niet door, wijzen inconsistenties niet aan, maken geen afwegingen.
  • Ze worden vaak onnodig complex: meer abstracties, lagen en regels.
  • Ze laten ‘restanten’ achter: ongebruikte code, onnodige comments, onbedoelde wijzigingen.

De conclusie is niet “geen agents gebruiken”. Het is wel: inzetten met duidelijke regels: testen, reviews, scope-beperkingen en een mentaliteit van continue inspectie. Bij belangrijke software verdwijnt de menselijke rol niet, hij verandert alleen van functie.

“Ik moet mezelf eraan herinneren dat Claude het kan”

De meest aanjagende reactie komt uit Anthropic zelf. Boris Cherny, maker en verantwoordelijke voor Claude Code, vertelt dat hij die ervaring van ’weer hulp bij het herontdekken van modelvaardigheden’ bijna wekelijks heeft. Zijn voorbeeld is veelzeggend: bij een geheugenlek was zijn eerste reflex altijd hetzelfde (profiler, reproduceren, handmatig onderzoeken). Maar een collega vroeg aan de agent om een heap dump, die analyseerde hij en bracht meteen een pull request uit ‘de eerste keer’.

Cherny beschrijft zelfs een routine die voor traditioneel ontwikkelwerk sciencefiction lijkt: periodes waarin hij het IDE niet opent, en de snelheid van tientallen — en later honderden — pull requests in korte tijd, met de agent die code schrijft en de mens die stuurt. Hierachter schuilt een belangrijke boodschap: de mentale gewoonte weegt zwaar. Mensen zonder ‘model-historie’ (zoals nieuwe medewerkers of pas afgestudeerden) benutten de huidige capaciteiten soms beter omdat ze niet gebonden zijn door aangeleerde beperkingen.

De nieuwe competitieve voorsprong: goed kunnen redigeren, niet alleen goed kunnen schrijven

Als een LLM code schrijft, wat onderscheidt dan de besten? Het vermogen tot discriminatie. Kritisch lezen, verborgen aannames ontdekken, vereisten testen, vereenvoudigen. De vaardigheid verschuift van ‘genereren’ naar ‘beoordelen’. Karpathy wijst zelfs op een ongemakkelijk neveneffect: atrofie. Als je minder handmatig schrijft, wordt de spier om oplossingen te typen zwakker, zelfs als de vaardigheid om te reviewen verbetert of gelijk blijft.

Deze verschuiving doet een oude vraag heropleven, met een nieuw perspectief: wat gebeurt er met de ‘ingeniør 10x’? Als gereedschappen iedereen versterken, kan de kloof verkleinen… of juist groter worden, als de topengineers zich toeleggen op het aansturen van agents, het definiëren van criteria, het ontwerpen van architecturen en het afdwingen van netheid.

2026 en de “slopacolypse”: als het probleem niet meer produceren is, maar filteren

Karpathy voorspelt iets dat bijna onvermijdelijk lijkt: nu het genereren van code makkelijk wordt, zal het ook eenvoudig zijn om documentatie, artikelen, repositories, papers, video’s en inhoud ‘ranzig’ te maken. Een “slopacolypse” — een stortvloed van middelmatigheid — die GitHub, nieuwsbrieven, sociale netwerken en digitale platforms zal overspoelen.

Dit is geen louter culturele kwestie: het wordt een operationeel probleem. In een wereld overspoeld door inhoud wordt ‘curatie’, ‘verificatie’ en ‘het handhaven van standaarden’ cruciaal. In softwareteams vertaalt zich dat naar strengere processen: linters, testen, observability, security review, dependency management, merge policies en tracking van veranderingen.

De toekomst: minder tikken, meer sturen… en meer ambitie

De meest waardevolle interpretatie van de discussie is misschien niet nostalgie of euforie, maar de herdefinitie van ‘tekortkomingen’ als een routekaart: wat nu nog niet goed gaat — twijfels wegwerken, alternatieven bespreken, aannames afremmen, vereenvoudigen — is precies wat in de komende maanden beter wordt. En zodra dat gebeurt, zal de verandering niet alleen kwantitatief zijn, maar ook kwalitatief: grotere projecten, kleinere teams, kortere cycli.

Toch blijft één regel overeind: wanneer software cruciaal is, moet iemand de verantwoordelijkheid nemen. AI kan veel code genereren, maar verantwoordelijkheid, oordeel en strategische inzet blijven menselijk. Voorlopig vervangt de revolutie niet de ingenieur, maar drijft hem wel naar de rol van dirigent.

via: Karpathy geeft woorden aan de ‘faseverschuiving’ in codering met LLM’s

Scroll naar boven