Het artikel bespreekt de spanning tussen het gebruik van Large Language Models (LLM's) en het daadwerkelijk beheersen van het vak programmeren. De aanleiding is een brief van een lezer die met AI een complex systeem heeft gebouwd, maar merkt dat hij de controle verliest omdat het systeem zijn eigen begripsniveau te boven gaat.
De belangrijkste inzichten uit de tekst zijn:
- De AI-paradox: AI kan de drempel om iets te bouwen verlagen, maar creëert het risico dat men een 'schijnproduct' bouwt zonder de onderliggende logica echt te begrijpen.
- Waarde van fundamenten: Ondanks de opkomst van AI blijven basisprincipes zoals datastructuren, architectuur en netwerken essentieel om problemen zelfstandig op te lossen.
- Abstractie-regel: Een goede vuistregel voor ontwikkelaars is om de abstractielaag direct boven en direct onder de laag waarin men werkt volledig te begrijpen.
- Strategisch LLM-gebruik: De auteur adviseert om LLM's alleen in te zetten voor falsifieerbare vragen (vragen waarvan het antwoord direct verifieerbaar is door de code te draaien), en niet voor conceptuele of strategische leeradviezen.
Programmeren leren in het tijdperk van LLM's
Deze tekst bevat de openbare antwoorden op een brief van een lezer over het leren programmeren in het tijdperk van Large Language Models (LLM's). De auteur merkt op dat de situatie zo onzeker is dat zijn antwoorden niet als onveranderlijke waarheden moeten worden beschouwd, maar als zijn beste inschatting.
De paradox van AI-gestuurde ontwikkeling
Een lezer schreef over zijn ervaringen met AI-ondersteund programmeren:
"Ik probeer te begrijpen hoe mensen die software echt doorgronden, denken over leren en competentie in het tijdperk van AI. Ik ben ongeveer een jaar geleden gefascineerd geraakt door AI-assisted programming. Ondanks dat ik geen formele informatica-achtergrond heb, ben ik met LLM's erin geslaagd om een vrij groot TypeScript/JavaScript-systeem te bouwen, inclusief API's, PostgreSQL, LLM-pipelines, automatiseringsonderzoek en multi-model workflows. In het begin voelde het bijna magisch: AI leek de afstand tussen een idee hebben en het daadwerkelijk kunnen bouwen te overbruggen.
Maar nu ik probeer van dat systeem een echt productieproduct te maken, loop ik vast. Ik los één fout op met AI, waarna er een andere verschijnt, en vervolgens gedraagt een ander onderdeel zich op een manier die ik niet volledig begrijp. Na maanden van refactoring kwam ik tot een ongemakkelijke realisatie: ik heb mogelijk een systeem gebouwd dat boven mijn eigen niveau van begrip ligt. Wanneer alles werkt, is dat gat bijna onzichtbaar. Wanneer het niet werkt, wordt het zeer reëel.
Soms weet ik oprecht niet wat de volgende stap is zonder een ander model om hulp te vragen. Dat deed me afvragen of ik een jaar heb besteed aan het bouwen van een product, of aan het bouwen van de schijn van een product: iets dat geavanceerd genoeg is om te werken, maar dat ik niet diep genoeg begrijp om het echt 'te bezitten'. Ik ben absoluut niet tegen AI, maar ik ben onzeker over wat de juiste relatie ermee zou moeten zijn."
Een kritische blik op de technologische transitie
De auteur geeft aan dat hij zelf ook onzeker is, maar neigt naar een afkeer van AI, hoewel hij erkent dat het wellicht onstuitbaar is. Hij experimenteert ermee en is soms onder de indruk, maar juist dan voelt hij de meeste weerstand.
Vanuit zijn achtergrond als econoom maakt hij zich zorgen over de sociaal-economische impact. Hoewel vaak wordt aangevoerd dat technologie altijd nieuwe banen creëert, stelt hij dat dit niet altijd geldt voor de mensen die hun baan verliezen; kolenmijnwerkers werden niet zomaar programmeurs. Hij is sceptisch over het idee dat alles wel goed komt, zeker als we massale werkloosheid onder kenniswerkers zouden zien.
De waarde van fundamenten
De lezer vraagt zich af of het nog zinvol is om vandaag de dag fundamentele zaken te bestuderen, zoals talen, datastructuren, databases, netwerken, besturingssystemen, debugging en architectuur.
De visie van de auteur:
- Terugblikkend: Hij is zeer blij dat hij deze fundamenten heeft geleerd; deze vaardigheden hebben hem dertig jaar lang goed gediend.
- Huidige keuze: Als hij vandaag opnieuw zou beginnen, zou hij serieus overwegen om een ambacht te leren (zoals timmerwerk of metaalbewerking), omdat de vervanging van handmatige arbeid waarschijnlijk verder in de toekomst ligt dan die van cognitieve arbeid.
- Persoonlijke praktijk: Ondanks de AI volgt hij momenteel een universiteitsprogramma in datastructuren en taalsemantiek, primair uit nieuwsgierigheid.
Begrip en abstractielagen
Over de vraag of AI mensen in staat stelt om sneller te bouwen dan ze kunnen begrijpen, merkt de auteur op dat softwareontwikkelaars dit al decennia doen. Men werkt altijd op abstractielagen die men niet volledig begrijpt (bijv. een webdeveloper die geen compiler programmeert).
Een goede vuistregel is: begrijp de abstractielaag direct onder die waar je in werkt, en de laag direct erboven. Dit stelt je in staat om de meeste problemen zelfstandig op te lossen.
Systematisch leren versus "samenklunsen"
De auteur reflecteert op zijn eigen beginjaren. In 1999 schreef hij COM-componenten in C++ zonder precies te begrijpen wat hij deed, maar hij zorgde er wel voor dat het werkte. Hij was echter nooit tevreden met het simpelweg 'aan elkaar plakken' van onderdelen zonder begrip, waardoor hij later alsnog systematisch de fundamenten is gaan leren.
Hij twijfelt echter of deze aanpak vandaag de dag nog werkt. Het bereiken van een competentieniveau waarop je beseft dat je voorheen onwetend was (het overwinnen van de Dunning-Kruger-curve), kostte hem decennia. De vraag is of beginners vandaag de dag die tijd hebben. Hoewel LLM's kunnen helpen bij het stellen van gerichte vragen, blijft het menselijk brein de bottleneck in de snelheid van kennisabsorptie.
Methodiek van leren in het AI-tijdperk
Op de vraag hoe hij nu nieuwe technische zaken leert, antwoordt de auteur:
- Ervaring: Hij leert nu vaak door bestaande code te bestuderen en specifieke onduidelijkheden op te zoeken.
- Boeken: Hij heeft in het verleden sterk geleund op boeken, zeker voor talen als F# en Haskell.
- Gebruik van LLM's: Hij gebruikt LLM's nauwelijks voor het leerproces zelf, omdat hij wantrouwig is tegenover "bullshitting" (hallucinaties).
De strategie voor LLM-gebruik: De auteur stelt voor om LLM's uitsluitend te gebruiken voor falsifieerbare vragen.
- Goed voorbeeld: "Kan ik deze Haskell-expressie beknopter maken?" → Het antwoord is direct verifieerbaar: de code werkt wel of niet, en is korter of niet.
- Slecht voorbeeld: "Wat moet ik nu leren?" → Dit levert geen verifieerbaar antwoord op en is daarom ongeschikt voor een LLM.
Programmeren leren in het tijdperk van LLM's
Deze tekst bevat de openbare antwoorden op een brief van een lezer over het leren programmeren in het tijdperk van Large Language Models (LLM's). De auteur merkt op dat de situatie zo onzeker is dat zijn antwoorden niet als onveranderlijke waarheden moeten worden beschouwd, maar als zijn beste inschatting.
De paradox van AI-gestuurde ontwikkeling
Een lezer schreef over zijn ervaringen met AI-ondersteund programmeren:
"Ik probeer te begrijpen hoe mensen die software echt doorgronden, denken over leren en competentie in het tijdperk van AI. Ik ben ongeveer een jaar geleden gefascineerd geraakt door AI-assisted programming. Ondanks dat ik geen formele informatica-achtergrond heb, ben ik met LLM's erin geslaagd om een vrij groot TypeScript/JavaScript-systeem te bouwen, inclusief API's, PostgreSQL, LLM-pipelines, automatiseringsonderzoek en multi-model workflows. In het begin voelde het bijna magisch: AI leek de afstand tussen een idee hebben en het daadwerkelijk kunnen bouwen te overbruggen.
Maar nu ik probeer van dat systeem een echt productieproduct te maken, loop ik vast. Ik los één fout op met AI, waarna er een andere verschijnt, en vervolgens gedraagt een ander onderdeel zich op een manier die ik niet volledig begrijp. Na maanden van refactoring kwam ik tot een ongemakkelijke realisatie: ik heb mogelijk een systeem gebouwd dat boven mijn eigen niveau van begrip ligt. Wanneer alles werkt, is dat gat bijna onzichtbaar. Wanneer het niet werkt, wordt het zeer reëel.
Soms weet ik oprecht niet wat de volgende stap is zonder een ander model om hulp te vragen. Dat deed me afvragen of ik een jaar heb besteed aan het bouwen van een product, of aan het bouwen van de schijn van een product: iets dat geavanceerd genoeg is om te werken, maar dat ik niet diep genoeg begrijp om het echt 'te bezitten'. Ik ben absoluut niet tegen AI, maar ik ben onzeker over wat de juiste relatie ermee zou moeten zijn."
Een kritische blik op de technologische transitie
De auteur geeft aan dat hij zelf ook onzeker is, maar neigt naar een afkeer van AI, hoewel hij erkent dat het wellicht onstuitbaar is. Hij experimenteert ermee en is soms onder de indruk, maar juist dan voelt hij de meeste weerstand.
Vanuit zijn achtergrond als econoom maakt hij zich zorgen over de sociaal-economische impact. Hoewel vaak wordt aangevoerd dat technologie altijd nieuwe banen creëert, stelt hij dat dit niet altijd geldt voor de mensen die hun baan verliezen; kolenmijnwerkers werden niet zomaar programmeurs. Hij is sceptisch over het idee dat alles wel goed komt, zeker als we massale werkloosheid onder kenniswerkers zouden zien.
De waarde van fundamenten
De lezer vraagt zich af of het nog zinvol is om vandaag de dag fundamentele zaken te bestuderen, zoals talen, datastructuren, databases, netwerken, besturingssystemen, debugging en architectuur.
De visie van de auteur:
- Terugblikkend: Hij is zeer blij dat hij deze fundamenten heeft geleerd; deze vaardigheden hebben hem dertig jaar lang goed gediend.
- Huidige keuze: Als hij vandaag opnieuw zou beginnen, zou hij serieus overwegen om een ambacht te leren (zoals timmerwerk of metaalbewerking), omdat de vervanging van handmatige arbeid waarschijnlijk verder in de toekomst ligt dan die van cognitieve arbeid.
- Persoonlijke praktijk: Ondanks de AI volgt hij momenteel een universiteitsprogramma in datastructuren en taalsemantiek, primair uit nieuwsgierigheid.
Begrip en abstractielagen
Over de vraag of AI mensen in staat stelt om sneller te bouwen dan ze kunnen begrijpen, merkt de auteur op dat softwareontwikkelaars dit al decennia doen. Men werkt altijd op abstractielagen die men niet volledig begrijpt (bijv. een webdeveloper die geen compiler programmeert).
Een goede vuistregel is: begrijp de abstractielaag direct onder die waar je in werkt, en de laag direct erboven. Dit stelt je in staat om de meeste problemen zelfstandig op te lossen.
Systematisch leren versus "samenklunsen"
De auteur reflecteert op zijn eigen beginjaren. In 1999 schreef hij COM-componenten in C++ zonder precies te begrijpen wat hij deed, maar hij zorgde er wel voor dat het werkte. Hij was echter nooit tevreden met het simpelweg 'aan elkaar plakken' van onderdelen zonder begrip, waardoor hij later alsnog systematisch de fundamenten is gaan leren.
Hij twijfelt echter of deze aanpak vandaag de dag nog werkt. Het bereiken van een competentieniveau waarop je beseft dat je voorheen onwetend was (het overwinnen van de Dunning-Kruger-curve), kostte hem decennia. De vraag is of beginners vandaag de dag die tijd hebben. Hoewel LLM's kunnen helpen bij het stellen van gerichte vragen, blijft het menselijk brein de bottleneck in de snelheid van kennisabsorptie.
Methodiek van leren in het AI-tijdperk
Op de vraag hoe hij nu nieuwe technische zaken leert, antwoordt de auteur:
- Ervaring: Hij leert nu vaak door bestaande code te bestuderen en specifieke onduidelijkheden op te zoeken.
- Boeken: Hij heeft in het verleden sterk geleund op boeken, zeker voor talen als F# en Haskell.
- Gebruik van LLM's: Hij gebruikt LLM's nauwelijks voor het leerproces zelf, omdat hij wantrouwig is tegenover "bullshitting" (hallucinaties).
De strategie voor LLM-gebruik: De auteur stelt voor om LLM's uitsluitend te gebruiken voor falsifieerbare vragen.
- Goed voorbeeld: "Kan ik deze Haskell-expressie beknopter maken?" → Het antwoord is direct verifieerbaar: de code werkt wel of niet, en is korter of niet.
- Slecht voorbeeld: "Wat moet ik nu leren?" → Dit levert geen verifieerbaar antwoord op en is daarom ongeschikt voor een LLM.
Groetjes,