~/blog/tag/craft
Vakmanschap
Over codekwaliteit, bewust bouwen en het vak van softwareontwikkeling.
Waar ik over schrijf
Vakmanschap is wat je niet kunt uitbesteden. De meeste stukken onder deze tag gaan daarover, geschreven in de tijd waarin de verleiding om uit te besteden groter is dan ooit.
Dit is de ruil die ik teams steeds zie maken. Ze grijpen naar een agent omdat het sneller features oplevert. De features komen. De bugs komen mee.
De code-review wordt dunner omdat de diff er aannemelijk uitziet. Zes maanden later kan niemand in het team meer uitleggen waarom de auth-flow doet wat hij doet, en de laatste die het wel kon is allang weg.
Het vak dat ik hier verdedig, is het deel dat niet in commit-snelheid zichtbaar is. Het is smaak, en het gevoel dat er iets niet klopt voordat je kunt benoemen waarom. Het is de bereidheid om code zorgvuldig te lezen, ook code die je niet zelf hebt geschreven. En het is de discipline om een fix die je niet begrijpt te weigeren.
Daar wordt niks van makkelijker als er een agent bij betrokken is. Eerder belangrijker. De pull request die je op instinct had gevangen omdat hij raar voelde, is precies wat een agent in zelfverzekerde toon zal produceren. De lezer moet meer werk doen, niet minder.
Dat is de rode draad van deze stukken. Het model is een gereedschap. Het oordeel is van jou, en dat mag je niet neerleggen.
Het volledige argument, met alle stukken in samenhang, vind je in de gids Vakmanschap in het AI-tijdperk.
beste startpunten
- De prompt is geen spec
Het kaderstellende stuk. Een prompt draagt intentie, een spec draagt constraints. De meeste vakfouten zijn varianten op die verwarring.
- Beter code leren lezen: een oefenroutine
Het vak als spier. Een oefenroutine voor code lezen, want iedereen stelt de diagnose en niemand traint de oplossing.
- Je vindt de bug niet als je de code niet schreef
Het argument in zijn scherpste vorm. Je vangt alleen de bugs in code die je begrijpt. Het vak zit in het lezen, niet in het schrijven.
Lege catch-blokken in AI-code: het commentaar dat je linter het zwijgen oplegt
AI-code slikt fouten in met catch-blokken waar alleen een commentaar in staat, en de aanbevolen ESLint-config laat ze juist dankzij dat commentaar door. Wat ik in mijn eigen repositories vond, waarom een model ze schrijft, en de regel die wel door het commentaar heen kijkt.
lees →Wie schreef deze commit? Git-attributie als een agent meewerkt
Ik ging op zoek naar de coding agent in 1.644 commits uit tien van mijn publieke repositories. Hij liet geen enkel spoor na. Wat de auteursgegevens wél herschreef, was de merge-knop.
Slopsquatting: bestaat het package? Verkeerde vraag
Het standaardadvies tegen verzonnen packages luidt: controleer eerst of het package bestaat. Ik heb vier namen uit het nieuwste onderzoek opgezocht op PyPI. Ze bestaan alle vier. De registry beantwoordt de verkeerde vraag, en dat gaat in beide richtingen mis.
Software inschatten met AI: het typen was nooit waar de tijd in zat
Software inschatten met AI zit er steeds naast. Eén enquête van METR vroeg 349 mensen in technische beroepen hoeveel sneller ze waren geworden en hoeveel meer waarde ze opleveren, en kreeg 3x en 1,4 tot 2x terug. Het gat tussen die twee antwoorden is de schatting die je eigenlijk maakt.
Kwaliteitsdrempels voor AI-code: baselines die alleen strenger worden
Met een lint-baseline dwing je een standaard af die je codebase vandaag nog niet haalt. Bestaande overtredingen krijgen vrijstelling, nieuwe breken de build, en het bestand mag alleen krimpen. Hoe PHPStan, ESLint, detekt en Sonar dit doen, en de vier manieren waarop zo'n drempel stilletjes stopt met werken.
Oncall voor AI-code: wat je regelt voordat de pager afgaat
Het bekendste geval van AI-code die productie platlegde wordt door het bedrijf zelf ontkend. Niemand van buiten kan uitmaken wie gelijk heeft, want de gegevens waarmee dat zou kunnen, zijn nooit vastgelegd. Oncall voor code die een model schreef is een administratieprobleem.
Observability opzetten voor AI-code: wat je review niet ziet
94% van de technisch leidinggevenden schat AI-code bij de review hoger in dan mensenwerk. 82% hield er binnen een halfjaar een productiestoring aan over. Twee meetinstrumenten, dezelfde code, tegengestelde uitkomsten.
Werd je code slechter na een modelwissel? AI-modellen vergelijken zonder benchmark
Je wisselt van model, er zit iets niet lekker, en je hebt niets om naar te wijzen. Waarom de prompt opnieuw draaien en een model als jury inzetten allebei niet werken, en de kleine, saaie meetopstelling die de vraag wel beantwoordt.
Junior developers aannemen in 2026: de instroom stopte, en dat was een keuze
Bedrijven namen geen junior developers meer aan, en het cijfer dat iedereen erbij haalt staat niet in het onderzoek waaraan het wordt toegeschreven. Wat er wel in staat, maakt van die ingestorte instroom een keuze. En één groot bedrijf doet nu precies het omgekeerde.
De bottleneck zit in je code review: iedereen citeert het verkeerde getal
De mediane reviewtijd van een pull request steeg met 441%. Dat cijfer wordt ten onrechte aan DORA toegeschreven, en het is het minst bruikbare van de drie getallen uit het rapport waar het wél vandaan komt.