Mijn GitHub-contributiegrafiek van 2025 lijkt van twee verschillende developers te zijn. De eerste helft van het jaar is bijna leeg. In de tweede staan meer dan 4.000 commits.
Ik kreeg niet ineens meer vrije tijd. Ik combineerde nog steeds een fulltime baan met side projects. Wat veranderde was de hoeveelheid frictie tussen een idee en een werkende versie: ik ging AI-codingtools veel serieuzer gebruiken.
Die mooie grafiek verdient wel nuance. Het aantal commits is op zichzelf geen productiviteitsmaatstaf. Vierduizend commits bewijzen niet dat ik vierduizend nuttige verbeteringen maakte of dat de code goed was. Wat de grafiek wél laat zien, is een echte verandering in mijn werkritme: ik bouwde, iterereerde en shipte veel consistenter dan daarvoor.
De echte bottleneck was de energie om een experiment te starten
Bij side projects kwam ik steeds hetzelfde probleem tegen: de eerste bruikbare versie zit vaak achter veel routinewerk. Routing, validatie, scripts, tests, configuratie en cleanup kunnen momentum opslokken voordat ik weet of een idee het waard is.
Vroeger stelde ik experimenten uit wanneer de eerste werkende versie meerdere avonden setup leek te kosten. AI-codingtools verwijderden dat werk niet, maar verlaagden de kosten van de first pass en brachten me sneller bij een testbare versie.
De grootste winst was dus niet sneller typen. Het was lagere activation energy: meer ideeën bereikten daadwerkelijk het punt waarop ik echte feedback kon verzamelen.
Hoe mijn Node.js-workflow veranderde
Ik verving mijn developmentproces niet door een chatvenster. In Node.js-side projects gebruikte ik DeepSeek als een tweede paar handen voor duidelijk afgebakende taken: een eerste implementatie opzetten, onbekende code lezen, tests voorstellen, een stack trace analyseren, een grote refactor opdelen en deployment-aannames controleren.
- Scaffolding: de saaie eerste versie van handlers, validatie, scripts of tests.
- Code reading: een request of waarde volgen voordat ik iets wijzig.
- Refactoring: mechanische veranderingen opdelen in kleine reviewbare diffs.
- Debugging: meerdere hypotheses uit logs halen.
- Verification: edge cases en regressies zoeken nadat de happy path werkt.
Hoe duidelijker inputs, outputs, constraints en bestaande conventies waren, hoe makkelijker het resultaat te verifiëren was. Vage taken leverden vaker een plausibele maar verkeerde abstractie op.
Daarom behandelde ik AI-output als een candidate patch, niet als eindantwoord. Type checking, tests, build en de echte flow waren bewijs; een zelfverzekerde uitleg niet.
Waar DeepSeek het meest hielp — en waar niet
DeepSeek was voor mij vooral nuttig omdat ik het herhaaldelijk kon inzetten voor concrete programmeertaken. Ik kon een first pass vragen, een deel afwijzen, de echte fout teruggeven, de scope verkleinen en snel itereren.
Ik noem dit geen benchmark. Ik heb geen gecontroleerde studie tegen ieder concurrerend model gedaan en modelreeksen veranderen snel. De verdedigbare claim is kleiner: DeepSeek paste goed genoeg in mijn workflow dat ik AI-assistentie veel vaker ging gebruiken.
Het werkte het beste als feedback goedkoop was: een functie, tests en een echte fout. Het was zwakker bij impliciete productcontext of subtiele architectuurkeuzes. Dan kon een vloeiend antwoord een verkeerde aanname gevaarlijk af laten voelen.
AI veranderde de kosten van experimenteren
De grootste verbetering was niet “AI schrijft code, dus development is automatisch”. Veel kleine onderdelen werden simpelweg goedkoop genoeg om te proberen. Een side-projectfeature die vroeger als te veel setup voelde, kon nu een prototype worden terwijl ik nog enthousiast was over het idee.
Dat onderscheid is belangrijk. AI verlaagde de kosten om tot een testbare versie te komen. Architectuur, productkeuzes, deployment en correctheid verdwenen niet. Een gegenereerde implementatie kan fout zijn; een succesvolle build kan tijdens runtime stuklopen; een gedeployd prototype kan nog steeds een slecht product zijn.
Voor mij was het praktische voordeel momentum. Zodra ik het hele systeem eenmaal zag werken, was ik veel eerder bereid om het verder te verfijnen.
Wat een sterkere benchmark nodig zou hebben
Voor een reproduceerbare benchmark zou ik exacte modelversies, vaste programmeertaken, repository-snapshots, prompts, ruwe outputs, verstreken tijd, geaccepteerde en afgewezen patches, reviewtijd, testresultaten en rework vastleggen.
Ik zou ook meer meten dan commits: tijd van idee tot geverifieerde versie, defects, rollbacks en herschreven werk. Zonder die context zijn 4.000 commits bewijs van activiteit en veranderd gedrag, niet van softwarekwaliteit.
Wat er voor mij veranderde
2025 was het jaar waarin ik stopte elk side project te zien als een berg setup die ik handmatig moest beklimmen. AI maakte de eerste werkende versie goedkoop genoeg om vaker het punt te bereiken waar de echte productbeslissingen belangrijk werden.
Daarom ziet de tweede helft van mijn GitHub-grafiek er zo anders uit. Niet omdat AI mij meer uren per dag gaf en niet omdat elke gegenereerde regel goed was. Het verminderde de frictie die eerdere ideeën had gedood voordat ze echt werden.
In 2026 ligt mijn focus op de minder spectaculaire helft van de vergelijking: de workflow verfijnen, kwaliteit serieuzer meten en zorgen dat sneller ontwikkelen betere software oplevert in plaats van alleen meer commits.