Lange tijd wist ik niet eens zeker of deze website überhaupt een blog nodig had.
Ik besteed het grootste deel van mijn werktijd al aan het oplossen van problemen. Sommige zijn gewone frontend- of backendtaken. Andere worden veel specifieker: image encoding, browsergedrag, SEO-experimenten, infrastructuurproblemen, AI-assisted development, mediaverwerking of een vreemd productieprobleem dat begint met een simpele vraag en uitgroeit tot meerdere dagen onderzoek.
Daarna nog een paar duizend woorden schrijven kan overbodig voelen.
Wie gaat dit lezen?
Wat levert het mij op?
Waarom niet gewoon het probleem oplossen en doorgaan?
Uiteindelijk vond ik een antwoord dat voor mij voldoende was: een deel van dit werk kost te veel om zomaar weg te gooien.
Een lastig probleem kan al een compleet artikel bevatten voordat ik het besef
Mijn artikelen beginnen meestal niet met de gedachte: “Deze week moet ik een blogpost schrijven.”
Ze beginnen met een probleem.
Soms komt het uit mijn werk, soms uit een eigen project. Soms raakt iets wat ik niet begrijp me gewoon genoeg om erin te blijven graven tot ik het veel beter begrijp.
Image processing heeft me vaak in zulke konijnenholen gebracht.
In het begin kan een taak bijna belachelijk eenvoudig klinken:
Neem deze afbeeldingen en maak ze kleiner.
Je kunt een AI-model om een script vragen en vrijwel meteen iets terugkrijgen.
Dat betekent nog niet dat je een goede image-processing pipeline hebt.
De eerste versie kan verschillen tussen JPEG, PNG, WebP en geanimeerde content negeren. Ze kan voor alles één qualitywaarde gebruiken, onnodig upscalen, transparantie slecht verwerken, metadata bewaren die je wilde verwijderen of metadata vernietigen die juist moest blijven. Ze kan alleen bestandsgrootte optimaliseren zonder visuele schade te meten. Op tien testbestanden kan alles perfect werken en op veel grotere schaal kan precies dezelfde aanpak een heel dure fout worden.
Een script dat succesvol draait, is niet hetzelfde als een systeem dat ik vertrouw.
Uit dat verschil komen veel van mijn artikelen voort.
Mijn AI-workflow is veel trager dan “vraag ChatGPT om het antwoord”
Bij dit soort problemen gebruik ik een betaald ChatGPT-account intensief.
Eén gesprek kan dagen of weken blijven doorlopen. Ik stel vragen, test voorstellen, stuur resultaten terug, betwijfel aannames, bekijk code, vind een volgende edge case, pas de implementatie aan, voer opnieuw uit, vergelijk het resultaat en herhaal.
Bij bijzonder diepgaande onderzoeken heb ik meer dan 100 uur werk rond hetzelfde brede probleem opgebouwd.
Dat betekent niet dat ik 100 uur wacht tot een AI-model het antwoord op magische wijze ontdekt.
Het proces is iteratief.
Een typische cyclus ziet er ongeveer zo uit:
- Ik beschrijf het probleem.
- Het model stelt een eerste oplossing voor.
- Ik voer die uit op echte data.
- Iets blijkt zwak, inefficiënt of gewoon fout.
- Ik breng het bewijs terug.
- We veranderen de aanpak.
- Ik test opnieuw.
- Er verschijnt een nieuwe edge case.
- Herhalen.
Die cyclus kan vaak terugkomen.
Het bruikbare resultaat is meestal niet het eerste script, maar de verzameling fouten, metingen, correcties en beslissingen die eromheen is ontstaan.
AI maakte een startpunt goedkoop. Verificatie niet
Dat is een van de redenen waarom ik de gebruikelijke discussie over door AI geschreven technische content te simplistisch vind.
Ja, een AI-model kan razendsnel een plausibele tutorial produceren.
Het kan ook code produceren die er volkomen redelijk uitziet en juist fout is in de situaties die ertoe doen.
Bij smalle technische problemen wil ik zelden het eerste plausibele antwoord. Ik wil weten wat er gebeurt als ik het echt uitvoer.
Als ik een image pipeline bouw, wil ik uitvoergroottes en visuele kwaliteit bekijken. Ik wil weten wat er met verschillende bronformaten gebeurt. Ik wil ongebruikelijke dimensies, alpha, animaties en corrupte input testen. Ik wil begrijpen welke aannames de implementatie maakt.
Als het script uiteindelijk een enorme collectie moet verwerken, wordt dit werk nog belangrijker.
Tien miljoen afbeeldingen is bewust een extreem voorbeeld, geen claim over de omvang van een specifieke dataset van mij. Het illustreert het probleem wel goed: een kleine systematische fout die tien miljoen keer wordt vermenigvuldigd, is niet langer klein.
De kosten van code genereren zijn ingestort.
De kosten om te bepalen of die code op schaal uitgevoerd zou moeten worden, niet.
De chat is onderzoeksmateriaal, niet het uiteindelijke artikel
Na zo'n lang onderzoek kan de chatgeschiedenis een absurde hoeveelheid informatie bevatten.
Daarin kunnen zitten:
- aanpakken die faalden;
- code die later werd vervangen;
- bruikbare benchmarkresultaten;
- logs;
- misverstanden;
- correcties;
- uitleg van onduidelijk gedrag;
- vergelijkingen tussen alternatieven;
- edge cases waar ik aanvankelijk niet aan had gedacht;
- en de uiteindelijke regels die ik ben gaan vertrouwen.
Dat allemaal in één privégesprek laten staan voelt als verspilling.
Daarom haal ik de nuttige delen eruit en maak ik er een artikel van.
Het artikel is geen transcript van het gesprek. Het grootste deel van het gesprek zou nooit artikel moeten worden.
Een nuttig technisch artikel heeft nog een bewerkingsronde nodig: doodlopende paden zonder les verwijderen, doodlopende paden die iets belangrijks uitleggen behouden, claims controleren, de chronologie reconstrueren, observatie en verklaring uit elkaar houden en het resultaat veranderen in iets waar een andere developer echt iets aan heeft.
Die redactionele stap is belangrijk.
AI kan eraan meewerken, maar het bewijs komt nog steeds uit het daadwerkelijke werk.
Image processing leerde me hoe diep een “simpel” probleem kan worden
Beeldoptimalisatie is waarschijnlijk het duidelijkste voorbeeld uit mijn eigen werk.
Ik heb er genoeg tijd aan besteed om iets dat eerst op een verzameling encoderinstellingen leek langzaam te zien veranderen in een veel groter systeemprobleem.
De vragen veranderen snel.
Met welk bronformaat werk ik?
Is het geanimeerd?
Moeten de afmetingen veranderen?
Hoe kies ik de kwaliteit?
Welke metric bepaalt of kwaliteitsverlies acceptabel is?
Werkt één quality threshold voor totaal verschillende afbeeldingen?
Hoe voorkom ik upscaling?
Welke metadata moet behouden blijven?
Wat gebeurt er met transparantie?
Hoe moet de uitvoer gevalideerd worden?
Rechtvaardigt een kleiner bestand de extra encodingkosten echt?
Wat gebeurt er als de inputpopulatie verandert?
Daarom ben ik sceptisch over scripts van vijf regels voor “ultieme image optimization”.
Ze kunnen absoluut een afbeelding verwerken.
Dat is iets anders dan een pipeline bouwen waarvan je de compromissen begrijpt.
Voor mijn huidige image-heavy workloads is AVIF meestal het formaat waar ik als eerste naar kijk. Dat is een regel die voortkomt uit het soort projecten waar ik aan werk, niet de claim dat elke website ter wereld morgen alle oudere formaten moet verwijderen. Compatibiliteitseisen, bronmateriaal, latency, encoderkosten en delivery architecture kunnen het antwoord veranderen.
Het interessante is niet om één formaat tot winnaar uit te roepen.
Het gaat erom de workload goed genoeg te begrijpen om de beslissing bewust te nemen.
Ik wil net zo diep in videoprocessing duiken. Zover ben ik nog niet. Dat is een deel van wat deze onderwerpen interessant maakt: telkens wanneer ik denk dat ik de bodem van een probleem heb bereikt, verschijnt er nog een laag.
Toen vond een Japanse site het blog
Ik verwachtte geen specifieke opbrengst van het publiceren van deze artikelen.
Dit blog levert mij geen betekenisvolle financiële opbrengst op. Ik doe het omdat ik het proces leuk vind en omdat ik nuttig werk liever bewaar dan het te laten verdwijnen in oude chats en terminalgeschiedenis.
Toen gebeurde er iets wat ik echt niet had verwacht.
Op 17 september 2026 publiceerde de Japanse site Levtech Freelance een overzicht met een titel die ongeveer neerkomt op “Aanbevolen blogs voor engineers die hun vaardigheden willen verbeteren”.
Het artikel van Levtech Freelance nam JSVar op naast verschillende andere engineeringblogs.
Levtech maakt deel uit van een groot Japans ecosysteem rond IT-carrières, en Levtech Freelance richt zich op ondersteuning en matching van freelance IT-engineers. Voor mij was niet alleen de backlink interessant. Interessanter was om te zien welke delen van mijn werk een externe redactie de moeite van het beschrijven waard vond.
In hun gedeelte over JSVar lichtten ze drie artikelen uit.
Eén ging over waarom Codex en TypeScript volgens mijn ervaring goed samenwerken in production development, vooral omdat TypeScript-types en compilerfeedback problemen in gegenereerde code vroeg zichtbaar kunnen maken.
Een ander ging over het vertalen van het blog naar 20 talen met ChatGPT en het zien van zoekbezoekers uit verschillende landen die direct op gelokaliseerde pagina's binnenkwamen.
Het derde was mijn experiment met het publiceren van 10.000 door AI gegenereerde SEO-pagina's, wat uiteindelijk eerder een verhaal over mislukking dan over eenvoudige groei werd.
Die selectie vond ik grappig, omdat het drie heel verschillende artikelen zijn die toch hetzelfde patroon delen.
Ze zijn gebaseerd op iets wat ik echt heb gedaan.
Ik weet niet precies hoe Levtech mij gevonden heeft
Hier ligt een verleidelijk verhaal voor de hand.
Ik spreek geen Japans.
Mijn site heeft een Japanse versie.
Een Japanse engineeringpublicatie vond de site.
Dus de Japanse vertaling van het blog zorgde ervoor dat Levtech het ontdekte.
Dat kan ik niet bewijzen.
Misschien hielpen de Japanse pagina's.
Misschien bracht search hen naar een Engelstalig artikel.
Misschien deelde iemand een link.
Misschien vonden ze de site via een totaal andere route.
Ik heb die attribution data niet, dus ik ga er geen nette SEO-case study van maken die de gegevens niet kunnen onderbouwen.
Wat ik wel kan bevestigen, is veel eenvoudiger: ik publiceerde het blog in meerdere talen en later vond een Japanse publicatie het interessant genoeg om in een redactionele selectie op te nemen.
Dat is op zichzelf al een goed resultaat.
Het is vooral bevredigend omdat localization ook een experiment was dat aanvankelijk veel werk leek voor een onzekere opbrengst.
De vermelding was belangrijk omdat ze onafhankelijke bevestiging gaf
Met “bevestiging” bedoel ik niet dat Levtech bewees dat alles wat ik schrijf correct is.
Ze hebben mijn codebase niet geaudit en mijn experimenten niet gereproduceerd.
Wat telde was bescheidener.
Iemand aan de andere kant van de wereld, schrijvend voor een publiek dat ik zelf niet in hun taal kan aanspreken, zag genoeg waarde in mijn werk om het voor hun lezers samen te vatten.
Ik had hen niet gepitcht.
Ik schreef de oorspronkelijke artikelen niet voor Levtech.
Ik verwachtte niet in een Japanse selectie terecht te komen.
Dat maakt het resultaat voor mij betekenisvol.
Het suggereert dat een zeer gespecialiseerd technisch artikel niet per se een enorm publiek nodig heeft om publicatie waard te zijn.
Het moet nuttig zijn voor de juiste lezer.
Moet een developer in 2026 een blog beginnen?
Voor mij: ja, met één belangrijke voorwaarde.
Je moet daadwerkelijk iets willen opschrijven.
Ik zou geen technisch blog beginnen alleen omdat iemand zegt dat elke developer een “personal brand” nodig heeft.
Ik zou het ook niet doen omdat ik passive income verwacht.
En ik zou het niet vullen met algemene uitleg van technologieën waarvoor al betere documentatie bestaat.
Maar als je werk telkens dingen oplevert waarvan je wilde dat je ze zelf had kunnen vinden toen je begon, dan is dat anders.
Schrijf ze op.
Schrijf over die vreemde production failure.
Schrijf over de optimalisatie die drie dagen langer duurde dan verwacht.
Schrijf over de benchmark die je aanname tegensprak.
Schrijf over de aanpak die elegant leek en faalde.
Schrijf over de uiteindelijke implementatie, maar leg ook uit waarom de voor de hand liggende implementatie niet genoeg was.
Dat zijn de delen die moeilijk uit algemene kennis te fabriceren zijn.
AI geeft me meer materiaal om over te schrijven, niet minder
AI heeft me niet doen denken dat technische blogs achterhaald zijn.
Voor mij is bijna het tegenovergestelde gebeurd.
Ik kan meer ideeën onderzoeken omdat een eerste implementatie of uitleg sneller beschikbaar is dan vroeger.
Snellere iteratie levert ook meer bewijs op: meer varianten, meer logs, meer benchmarks, meer mislukte pogingen en meer dingen die gecontroleerd moeten worden.
Dat ruwe materiaal krijgt pas waarde nadat iemand het werk doet om te bepalen wat waar is en wat ertoe doet.
Een AI-gesprek met 500 berichten is niet automatisch kennis.
Een script dat uiteindelijk echte tests doorstaat, samen met een uitleg van de 20 versies die dat niet deden, kan dat wel zijn.
Dat verschil wil ik in het blog vastleggen.
Publiceren voorkomt dat nuttig werk verdwijnt
Het meeste technische werk is verrassend tijdelijk.
Een moeilijke bug wordt opgelost.
De terminal gaat dicht.
De deployment slaagt.
Het gesprek zakt weg in de chatgeschiedenis.
Zes maanden later weet zelfs ik misschien niet meer waarom de uiteindelijke implementatie eruitziet zoals ze eruitziet.
Schrijven verandert dat.
Het dwingt me de redenering te reconstrueren zolang het bewijs nog bestaat.
Het maakt iets doorzoekbaars.
Het geeft me een referentie voor mijn eigen toekomstige werk.
En soms bereikt het blijkbaar iemand die ik nooit had verwacht — zelfs een engineeringpublicatie in een taal die ik niet spreek.
Ik heb nog altijd geen ingewikkelde reden om dit blog te onderhouden.
Ik leer graag.
Ik bouw graag dingen.
Ik ga graag veel te diep in problemen die aanvankelijk simpel leken.
En nadat ik tientallen, soms meer dan honderd uur heb besteed om tot een bruikbaar antwoord te komen, wil ik niet meer dat dat antwoord in een chatvenster sterft.
Voor mij is dat genoeg reden om het te publiceren.
Als jouw werk hetzelfde soort hard bevochten kennis oplevert, denk ik dat het voor jou misschien ook genoeg reden is.