In ons vorige artikel schreven we over de hype rondom Claude Code. Ergens rond de kerstvakantie leek er een soort magische grens verbroken te zijn, waarbij deze modellen, in combinatie met een CLI (Command Line Interface), opeens bijzonder effectief werden. Mijn dagelijkse programmeerwerk is al voor zo'n 90% verschoven naar deze tools. Situaties waar ik zelf nog regels code schrijf, in plaats van ze te reviewen, komen al bijna niet meer voor.
Maar ondersteuning bieden bij het programmeren is niet het enige wat Claude Code kan. Hij is namelijk ook erg behulpzaam gebleken bij het configureren van mijn computer.
Let wel op: hierbij heb ik het over mijn Linux-workstation. Waar Claude Code bij zowel Linux als macOS behoorlijk compatibel is, lijkt dit bij onze Windows-computers toch wat minder soepel te verlopen. Zo kreeg mijn collega Henk het bijvoorbeeld niet eens voor elkaar om Claude Code geïnstalleerd te krijgen op zijn laptop. Arme Henk... maar goed, daar gaat dit artikel niet over, dus terug naar Linux-land.
Linux configureren
Wat bedoel ik met het configureren van mijn computer, en op welke manier helpt Claude daarbij? In tegenstelling tot Windows, waar applicaties vaak (en regelmatig exclusief) grafische user-interfaces zijn, zijn Linux en Linux-applicaties vaak van nature meer 'command line native', met soms een optionele grafische wrapper / grafische frontend beschikbaar.
Computerbesturing via CLI (toetsenbord-dominant) tegenover een GUI (muis-dominant)
Voorbeeld: Ik wil kunnen kopiëren, knippen en plakken vanuit de command-line. In Linux-land kan dat niet zomaar - je moet hier eerst de juiste software voor installeren (en er zijn meerdere opties). In mijn geval kies ik de software 'xclip'. Als ik deze wil installeren, open ik de terminal en typ ik het volgende:
sudo apt-get install xclip
Er volgt vervolgens een lading met systeemtekst, en enige tijd later kan ik via de CLI kopiëren, knippen en plakken! De meeste andere software kun je op precies dezelfde manier installeren.
Dit laat direct zien waarom Linux zo automatiseerbaar is. Want je kunt dit soort installatieregels allemaal bij elkaar in een script verzamelen. En de volgende keer dat je een computer gaat installeren, voer je gewoon dat script uit.
Dit was ook de manier waarop ik, jaren geleden, rond de tijd van Ubuntu 18, mijn installatiescripts opbouwde. Met als doel dat het optuigen van een volgende computer vrijwel automatisch kon gaan. Toch ben ik in de loop der jaren hierin gaan verzaken. Dat kwam eigenlijk door een combinatie van drie redenen.
Drie redenen voor verzuim
1. Verouderende scripts
Een belangrijke les waar bijna iedere ervaren developer wel bekend mee is: iedere regel code die je schrijft, is een regel code die je moet onderhouden. Dit soort scripts veroudert. Opeens is er iets veranderd, en vereist de installatie van je software een andere aanpak. Afhankelijkheden kunnen veranderen of er komt een nieuwe versie beschikbaar, en je script blijkt opeens hopeloos verouderd.
PS: Als jullie dit nog wel doen, neem dan snel contact met ons op.
2. Veranderende hardware
Iedere developer die met Linux werkt heeft weer zijn eigen 'horrorverhalen'. De stand-by-modus die niet meer wil activeren (of deactiveren), de instelling voor schermhelderheid die niet reageert en altijd maximaal staat (waardoor je laptop in een zonnebank verandert) of überhaupt je videokaart werkend zien te krijgen met de beschikbare drivers.
Bij iedere wisseling van de hardware krijg je dus weer te maken met een nieuw probleem, uniek gekoppeld aan dat stukje hardware. Ik heb daadwerkelijk nog nooit een systeem meegemaakt waarbij ik niet iets 'vreemds' moest doen om het goed werkend te krijgen. Hierdoor moet je vaak alsnog handmatig je installatiescript gaan doorlopen, in plaats van het automatisch uit te laten voeren. Iedere installatie is dus weer spannend.
3. Lui 🦥
Bovenstaande punten zijn natuurlijk valide. Het maken en onderhouden van dit soort scripts is een tijdrovende taak, vanwege deze verouderende script en veranderende hardware. Maar, de hoofdreden is voornamelijk: het is een hoop werk en ik ben erg lui.
Dus het fanatiek onderhouden van een volledig geautomatiseerd installatiescript riep ik al snel een halt toe. Ondanks dat, bleef ik nog wel trouw en gedisciplineerd installatienotities bijhouden van al mijn systemen. Want niks is vervelender om, na een herinstallatie, weer een halve dag te moeten gaan googelen, omdat je bent vergeten dat je een bepaalde bluetooth-driver moet uitschakelen om je bluetooth-dongle werkend te krijgen.
De taken waar AI geschikt voor is
Het is dus vooral veel werk om zo'n installatiescript te maken en te onderhouden. Het is niet complex - je weet hoe het moet, maar er moeten wel veel kleine details worden opgezocht en uitgewerkt. Eigenlijk lijkt dat best veel op de use-case die wij hebben voor programmeerwerk.
Bijvoorbeeld: het doen van een simpele refactor, of het toevoegen van een aantal simpele unit-tests. Taken waarvan je weet hoe het moet, maar het kost even tijd. En het kan niet 'even snel', want je moet net iets teveel met de details bezig zijn. Dus vaak doe je die dingen maar niet. De code werkt nu immers, de refactor is niet kritiek, en we willen verder. Maar het stoort en knaagt natuurlijk wel een beetje, iedere keer als je ermee werkt.
Dit is het type werk waarvoor AI momenteel uitzonderlijk goed geschikt is. Het voldoet namelijk aan twee criteria.
1. Een taak waarvan je al precies weet hoe het moet
Het is werk waarvan je al precies weet hoe het moet, maar wat een stuk sneller gaat als je het door de AI laat uitvoeren, en je het achteraf controleert. Dit laatste is wel belangrijk, want soms gebeuren er nog gekke dingen. Zorg voor controle, of in ieder geval voor een goed 'harness'.
Want vergeet niet dat je nog steeds met een non-deterministische entiteit te maken hebt, die soms ongelooflijk knappe resultaten weet op te leveren, maar even later ook weer heel eigenaardige fouten kan maken. Zo had ik binnen korte tijd Claude Opus 4.6 'betrapt' op vier verschillende fouten:
- Ik vroeg om een filter mee te geven van 1 januari 2023. Claude Code voerde daar vrolijk 2025 in.
- Ik gaf Claude een lijstje van drie wijzigingen. Toen ik een controle uitvoerde, was de derde wijziging nergens te bekennen.
- Ik geef vaak instructies om documentatie bij te werken, samen met een taak, maar de documentatie blijkt achteraf vaak onaangetast te zijn. Wat dat betreft, is het net een developer. Die zijn ook moeilijk aan te sporen tot het schrijven van documentatie.
- Ik vroeg Claude om een overzicht van wijzigingen bij te houden, terwijl we ze uitvoerden. Net als met documentatie deed Claude alsof ik deze vraag nooit had gesteld.
2. Een taak die uitgevoerd wordt binnen een goede bestaande structuur
Het is werk wat goed past binnen een bestaande structuur. Een codebase kan bijvoorbeeld al veel bestaande unittests bevatten. Dat geeft de LLM veel informatie en context - en een LLM is erg goed om dit soort 'patronen' te herkennen en daarbinnen te blijven. Je krijgt daardoor ook veel minder snel problemen dat een AI bijvoorbeeld met andere versie van je library probeert te werken.
Bij 'greenfield'-projecten is dit bijvoorbeeld heel anders. Ik zou vooralsnog niet aanraden om hier veel (met name ongecontroleerde) AI op los te laten. Het opzetten van een goed uitgedachte en duidelijke structuur is erg belangrijk (en vereist ook ervaring van een senior developer). Het liefst dan ook een structuur waar de AI goed tot zijn recht komt. Hier schreef ik in een eerder artikel al over: dit is vaak een iets plattere structuur, met iets minder diepe abstractielagen.
Terug naar knippen en plakken
Eerder in dit artikel liet ik zien hoe we xclip kunnen installeren. Normaal gesproken zou ik dit hebben uitgevoerd, twee aliases ervoor hebben toegevoegd in mijn .bashrc (alias copy en alias paste), en hiervan een aantekening hebben gemaakt in mijn installatiedocumentatie.
Maar, met behulp van Claude Code, heb ik in dezelfde tijd het volgende gedaan:
- Het installatiescript uitgebreid de noodzakelijke regels om deze tool te installeren.
- Het installatiescript uitgebreid met de twee aliases, zodat ze vanzelf worden toegevoegd, en ik dat bij mijn volgende systeem niet handmatig hoef te doen.
- En als we toch bezig zijn: het installatiescript uitgebreid met Wayland-detectie. Als de displaymanager werkt op basis van Wayland, installeer dan een andere clipboard-tool, die beter werkt in die situatie.
- Configureer in die situatie de aliases zodanig dat ze die andere tool gebruiken. Deze heeft natuurlijk weer een heel andere syntax.
Natuurlijk instrueer ik Claude om iedere 'complexe' installatie in een eigen file onder te brengen, aangeroepen vanuit het 'main' setupscript. Ik dwing de LLM dus om te werken in een vaste structuur, die ik vooraf heb uitgedacht. Zodra er in de toekomst dus onderhoud nodig is voor dit specifieke onderdeel, hoeft dit maar te gebeuren in één bestand.
Vele hainden maken licht werk
Voor mij is het gebruiken van Linux in de afgelopen maanden merkbaar leuker geworden. Een veelvoorkomend gezegde was vroeger dat Linux gratis is, als je tijd geen waarde heeft. Men zei dit omdat je vaak veel tijd kon kwijtraken aan het überhaupt werkend maken van je computer, terwijl een besturingssysteem zoals Windows (in theorie) out-of-the-box goed werkte en bleef werken.
Tegenwoordig ligt de stabiliteit van Linux-desktopsystemen veel hoger dan in de tijd waaruit deze uitspraak stamt. Toch zit er nog steeds een kern van waarheid in deze oude uitspraak. Maar dankzij Claude Code gaat dit opeens een stuk soepeler. Een groot deel van het debuggen van Linux is het opzoeken en uitproberen van zoveel mogelijk verschillende oplossingen, tot je op de juiste stuit. In deel 2 van deze blogserie ga ik hier een voorbeeld van geven.
Tegelijkertijd geldt nog wel bij deze huidige generaties van LLM's dat je nog steeds zelf moet denken, en deze tools het beste vooral kunt gebruiken om je eigen acties mee uit te voeren - alleen dan sneller dan wanneer je het zelf zou doen. Het is nog heel belangrijk om kennis en ervaring te hebben, en die toe te passen. Misschien momenteel zelfs nog wel belangrijker dan voorheen! In deel 3 van deze blogserie ga ik hier een voorbeeld van geven.
