In dit persoonlijke essay reflecteert de auteur op de verschuiving binnen de software-industrie van 'coders' naar 'engineers'. Waar de auteur zichzelf definieert als een low-level coder met een obsessie voor machine-optimalisatie, CPU-architectuur en fundamenteel begrip, ziet hij de industrie steeds meer verschuiven naar abstracties.
De kernpunten zijn:
- De passie voor het detail: De auteur beschrijft een intrinsieke behoefte om technologie vanaf de basis te begrijpen (bottom-up) in plaats van top-down.
- De impact van AI: De opkomst van LLM's wordt gezien als een katalysator die detailwerk en low-level optimalisaties automatiseert, waardoor de specifieke expertise van de 'coder' overbodig wordt.
- Existentiële crisis: De auteur ervaart een gevoel van verlies en professionele onzekerheid, omdat de vaardigheden die hem voldoening gaven en hem onderscheidden, nu door AI kunnen worden gereproduceerd.
- Vervreemding: Er is een groeiende kloof tussen de auteur en een industrie die efficiëntie via abstractie verkiest boven het ambachtelijke begrijpen van de machine.
Rouwen om het verlies van de details
De coder versus de engineer
Voordat de term "vibecoding" werd gemunt en de industrie verschoof naar het waarderen van programmeurs primair voor het ontwerpen van architectuur, noemde ik mezelf met trots een coder in plaats van een engineer. In mijn ogen benadrukte dit de manier waarop ik me richtte op de details, prestatie-optimalisatie, het kennen van de complexiteiten van de taal en het kunnen uitleggen hoe zaken precies werken, in tegenstelling tot het jongleren met Java-achtige abstracties.
Natuurlijk was dit gedeeltelijk een misvatting, maar ik kan niet anders dan opmerken dat de kansen om mijn sterkste kanten te benutten wegglippen, en dat de industrie overstapt op een model waar mijn geest niet mee kan werken.
Een obsessie met de machine
Ik maakte voor het eerst kennis met computing toen ik de geschiedenis-scène in Tron: Legacy zag. Mijn tienjarige zelf móést weten wat die regels betekenden, en zo begon ik aan de zware taak van het leren programmeren. Ik gaf niet om praktische toepassingen, het bouwen van nuttige programma's of het schrijven van code op zich: alles wat ik wilde was begrijpen hoe de machine werkt. Het kostte me enkele jaren leren en het intensief gebruiken van Linux voordat ik het doorhad, maar ik ben er gekomen.
Later probeerde ik me te specialiseren in verschillende gebieden, zoals netwerken, cryptografie of Rust, maar ik merkte dat ik altijd terugviel naar de machine zelf. Ik leerde het te waarderen en respect te hebben voor haar wensen. Ik vond vreugde in het schrijven van een toy OS, het tellen van cycli en het handmatig schrijven van machinecode. Ik was trots op het bedenken van slimme hacks. Net zoals een visser zich één kan voelen met zijn hengel, beschouw ik de machine als een verlengstuk van mezelf.
Ik doe dit nu acht jaar, en ik ben er volledig in opgegaan. Ik aarzel om van CPU te wisselen omdat ik ARM64 niet zo goed begrijp als x86, en dat geeft me oprecht ongemak. Ik maak me zorgen over allocaties in Python-code. Ik ben diep bezorgd over het feit dat ik niet weet hoe ik naar de JIT-disassemblage van Java-code op mijn pc moet kijken. Vandaag vond ik een geannoteerde versie van The Story of Mel en betrapte ik mezelf op de gedachte: wie heeft er in hemelsnaam uitleg nodig over "hexadecimaal"?
De behoefte aan detail en fundamenten
Ik zie mezelf niet als een programmeur die daarnaast expert is in een nichegebied; ik zie mezelf uitsluitend als een low-level coder, of zelfs gewoon als een detailgeoriënteerd persoon. Ik kan een website maken als dat moet, maar ik kan daar niet een maand lang aan werken zoals ik dat kan bij low-level software – al kan ik op precies dezelfde manier onderzoek doen naar natuurkunde.
Mijn focus op details stopt niet bij technologie. Ik kan onderwerpen niet top-down leren of omgaan met ontbrekende informatie. Wanneer iemand een concept aan me uitlegt, moet ik het zelf vanaf nul opnieuw uitvinden voordat ik het echt "snap". Op school besteedde ik uren aan het aanpassen van axioma's voor mijn intuïtie totdat ze pasten, om vervolgens theorems daarop te bouwen telkens wanneer ik ze nodig had, totdat ook zij intuïtief werden. (Sterker nog, de quality time met mijn vriendin bestaat vaak uit het bewijzen van theorems.) In de praktijk betekent dit dat ik niet kan experimenteren met koken zonder de onderliggende chemie te begrijpen. Over het algemeen kan ik niets gebruiken dat ik niet volledig begrijp – als het niet "klikt", kan ik er niet mee werken.
Dit is in het dagelijks leven oprecht belemmerend, maar voor een tijdje was de softwarewereld de enige ontsnapping die ik had uit deze worsteling.
De impact van LLM's
Zelfs zij die mij niet begrepen, hadden tenminste respect voor mijn werk aan low-level projecten. Er was een begrip dat kleine optimalisaties in compilers cumulatief werken, dat iemand assembly moet schrijven voor JSON-parsers om razendsnel te werken, en dat programma's niet zo slecht hoeven te zijn als de "Electron-prut" die we nu vaak zien. Misschien was het niet het centrale deel van softwareontwikkeling, maar het was belangrijk genoeg dat tijdsinvestering daarin als waardevol werd beschouwd. In andere gevallen bouwde ik reputatie op door dingen te weten, waardoor ik in één oogopslag naar de problemen van mensen kon kijken en wist wat er misging.
Dat duurde tot de komst van krachtige LLM's. De overweldigende consensus in de industrie is dat LLM's een zo uitputtend en vermoeiend proces als "zorgen maken over details" overbodig maken, waardoor ontwikkelaars zich kunnen concentreren op abstracties en grote projecten. Dat is geweldig voor hen, maar ik overdrijf niet als ik zeg dat ze alles van mij hebben afgepakt.
Als iedereen een LLM op trage code kan richten, waarna deze automatisch een hot loop vindt en een trucje van het internet gebruikt om deze te vectoriseren, is er weinig reden om iemand aan te nemen met een focus op dat vlak. Als een LLM de code kan analyseren, pointer provenance aan je kan uitleggen en je kan begeleiden totdat je het begrijpt, verdwijnt de waarde van expertise.
Ik kan LLM's niet op deze manier gebruiken. Ik word bijna fysiek ziek als ik werk aan een project met meer broncodebestanden of een algemene architectuur dan ik in mijn hoofd kan houden, dus ik haal niets uit een uitgebreid bereik.
Toen ik voor het laatst een LLM probeerde te gebruiken voor een hobbyproject, realiseerde ik me dat de LLM er meer over zou weten dan vrijwel elke persoon aan wie ik het zou kunnen laten zien. Ik kan tevreden zijn met het zijn van een onbegrepen genie, of wat dan ook – maar niet alleen als onwaardig voor menselijke interactie worden beschouwd, maar effectief de deur worden gewezen en worden doorverwezen naar een LLM, is meer dan beledigend. Sindsdien heb ik gezworen geen LLM's te gebruiken voor zaken waar ik om geef.
Een onzekere toekomst
In de loop van een jaar ging ik van een gepland toekomstperspectief naar zorgen over het aanvragen van een arbeidsongeschiktheidsuitkering. LLM-gestuurde ontwikkeling heeft elk onderdeel geoptimaliseerd dat programmeren voor mij draaglijk maakt, de arbeidsmarkt heeft besloten dat dit de toekomst is, en nu de enige optie in mijn leven die ik dacht dat constant was is verdwenen, blijkt dat er nooit een fatsoenlijk alternatief was.
Dat is waar ik nu sta. Opgezien van Big Tech, die LLM's met open armen ontvangt, hebben weinig bedrijven de middelen om te geven om het type werk dat ik doe. Linux had een kans om een uitzondering te zijn, maar ach. Hobby's bestaan nog steeds, maar die betalen de rekeningen niet, en in toenemende mate worden retrocomputing en prestatie-optimalisatie bevolkt door LLM-fans die erkenning zoeken in plaats van de ervaring, wat het plezier wegzuigt.
Gemaakt met mijn eigen blote handen (waarom ook niet).
Rouwen om het verlies van de details
De coder versus de engineer
Voordat de term "vibecoding" werd gemunt en de industrie verschoof naar het waarderen van programmeurs primair voor het ontwerpen van architectuur, noemde ik mezelf met trots een coder in plaats van een engineer. In mijn ogen benadrukte dit de manier waarop ik me richtte op de details, prestatie-optimalisatie, het kennen van de complexiteiten van de taal en het kunnen uitleggen hoe zaken precies werken, in tegenstelling tot het jongleren met Java-achtige abstracties.
Natuurlijk was dit gedeeltelijk een misvatting, maar ik kan niet anders dan opmerken dat de kansen om mijn sterkste kanten te benutten wegglippen, en dat de industrie overstapt op een model waar mijn geest niet mee kan werken.
Een obsessie met de machine
Ik maakte voor het eerst kennis met computing toen ik de geschiedenis-scène in Tron: Legacy zag. Mijn tienjarige zelf móést weten wat die regels betekenden, en zo begon ik aan de zware taak van het leren programmeren. Ik gaf niet om praktische toepassingen, het bouwen van nuttige programma's of het schrijven van code op zich: alles wat ik wilde was begrijpen hoe de machine werkt. Het kostte me enkele jaren leren en het intensief gebruiken van Linux voordat ik het doorhad, maar ik ben er gekomen.
Later probeerde ik me te specialiseren in verschillende gebieden, zoals netwerken, cryptografie of Rust, maar ik merkte dat ik altijd terugviel naar de machine zelf. Ik leerde het te waarderen en respect te hebben voor haar wensen. Ik vond vreugde in het schrijven van een toy OS, het tellen van cycli en het handmatig schrijven van machinecode. Ik was trots op het bedenken van slimme hacks. Net zoals een visser zich één kan voelen met zijn hengel, beschouw ik de machine als een verlengstuk van mezelf.
Ik doe dit nu acht jaar, en ik ben er volledig in opgegaan. Ik aarzel om van CPU te wisselen omdat ik ARM64 niet zo goed begrijp als x86, en dat geeft me oprecht ongemak. Ik maak me zorgen over allocaties in Python-code. Ik ben diep bezorgd over het feit dat ik niet weet hoe ik naar de JIT-disassemblage van Java-code op mijn pc moet kijken. Vandaag vond ik een geannoteerde versie van The Story of Mel en betrapte ik mezelf op de gedachte: wie heeft er in hemelsnaam uitleg nodig over "hexadecimaal"?
De behoefte aan detail en fundamenten
Ik zie mezelf niet als een programmeur die daarnaast expert is in een nichegebied; ik zie mezelf uitsluitend als een low-level coder, of zelfs gewoon als een detailgeoriënteerd persoon. Ik kan een website maken als dat moet, maar ik kan daar niet een maand lang aan werken zoals ik dat kan bij low-level software – al kan ik op precies dezelfde manier onderzoek doen naar natuurkunde.
Mijn focus op details stopt niet bij technologie. Ik kan onderwerpen niet top-down leren of omgaan met ontbrekende informatie. Wanneer iemand een concept aan me uitlegt, moet ik het zelf vanaf nul opnieuw uitvinden voordat ik het echt "snap". Op school besteedde ik uren aan het aanpassen van axioma's voor mijn intuïtie totdat ze pasten, om vervolgens theorems daarop te bouwen telkens wanneer ik ze nodig had, totdat ook zij intuïtief werden. (Sterker nog, de quality time met mijn vriendin bestaat vaak uit het bewijzen van theorems.) In de praktijk betekent dit dat ik niet kan experimenteren met koken zonder de onderliggende chemie te begrijpen. Over het algemeen kan ik niets gebruiken dat ik niet volledig begrijp – als het niet "klikt", kan ik er niet mee werken.
Dit is in het dagelijks leven oprecht belemmerend, maar voor een tijdje was de softwarewereld de enige ontsnapping die ik had uit deze worsteling.
De impact van LLM's
Zelfs zij die mij niet begrepen, hadden tenminste respect voor mijn werk aan low-level projecten. Er was een begrip dat kleine optimalisaties in compilers cumulatief werken, dat iemand assembly moet schrijven voor JSON-parsers om razendsnel te werken, en dat programma's niet zo slecht hoeven te zijn als de "Electron-prut" die we nu vaak zien. Misschien was het niet het centrale deel van softwareontwikkeling, maar het was belangrijk genoeg dat tijdsinvestering daarin als waardevol werd beschouwd. In andere gevallen bouwde ik reputatie op door dingen te weten, waardoor ik in één oogopslag naar de problemen van mensen kon kijken en wist wat er misging.
Dat duurde tot de komst van krachtige LLM's. De overweldigende consensus in de industrie is dat LLM's een zo uitputtend en vermoeiend proces als "zorgen maken over details" overbodig maken, waardoor ontwikkelaars zich kunnen concentreren op abstracties en grote projecten. Dat is geweldig voor hen, maar ik overdrijf niet als ik zeg dat ze alles van mij hebben afgepakt.
Als iedereen een LLM op trage code kan richten, waarna deze automatisch een hot loop vindt en een trucje van het internet gebruikt om deze te vectoriseren, is er weinig reden om iemand aan te nemen met een focus op dat vlak. Als een LLM de code kan analyseren, pointer provenance aan je kan uitleggen en je kan begeleiden totdat je het begrijpt, verdwijnt de waarde van expertise.
Ik kan LLM's niet op deze manier gebruiken. Ik word bijna fysiek ziek als ik werk aan een project met meer broncodebestanden of een algemene architectuur dan ik in mijn hoofd kan houden, dus ik haal niets uit een uitgebreid bereik.
Toen ik voor het laatst een LLM probeerde te gebruiken voor een hobbyproject, realiseerde ik me dat de LLM er meer over zou weten dan vrijwel elke persoon aan wie ik het zou kunnen laten zien. Ik kan tevreden zijn met het zijn van een onbegrepen genie, of wat dan ook – maar niet alleen als onwaardig voor menselijke interactie worden beschouwd, maar effectief de deur worden gewezen en worden doorverwezen naar een LLM, is meer dan beledigend. Sindsdien heb ik gezworen geen LLM's te gebruiken voor zaken waar ik om geef.
Een onzekere toekomst
In de loop van een jaar ging ik van een gepland toekomstperspectief naar zorgen over het aanvragen van een arbeidsongeschiktheidsuitkering. LLM-gestuurde ontwikkeling heeft elk onderdeel geoptimaliseerd dat programmeren voor mij draaglijk maakt, de arbeidsmarkt heeft besloten dat dit de toekomst is, en nu de enige optie in mijn leven die ik dacht dat constant was is verdwenen, blijkt dat er nooit een fatsoenlijk alternatief was.
Dat is waar ik nu sta. Opgezien van Big Tech, die LLM's met open armen ontvangt, hebben weinig bedrijven de middelen om te geven om het type werk dat ik doe. Linux had een kans om een uitzondering te zijn, maar ach. Hobby's bestaan nog steeds, maar die betalen de rekeningen niet, en in toenemende mate worden retrocomputing en prestatie-optimalisatie bevolkt door LLM-fans die erkenning zoeken in plaats van de ervaring, wat het plezier wegzuigt.
Gemaakt met mijn eigen blote handen (waarom ook niet).
Groetjes,