Programmeren voor journalisten in het vibecode-tijdperk

Hieronder een kleine gids voor journalisten die willen beginnen met programmeren en niet weten waar ze moeten beginnen. Aangepast voor het vibecode-tijdperk.

Photo by Scott Graham on Unsplash

Moeten we nog leren programmeren in een tijd waarin vibecoden dé manier is om snel iets te ontwikkelen, en een taalmodel sneller code schrijft dan een mens ooit zal kunnen? Ja, want:

• Er zijn grote ethische bezwaren bij het gebruik van AI. Dat gezegd hebbende, zijn er vaak zakelijke en persoonlijke belangen om het wel te gebruiken.
• Journalistiek is bij uitstek een vakgebied waarin transparantie en het kunnen uitleggen van je methodiek centraal staan.
• Vibecoden brengt je in de meeste gevallen alleen naar de eindstreep als je écht begrijpt wat je vraagt, en weet hoe het eindproduct in elkaar steekt.

Twee paden

Journalisten die willen leren programmeren zijn grofweg onder te verdelen in twee kampen: mensen die toffe visualisaties/interactieve verhalen willen maken en datajournalisten die iets meer de diepte in willen met hun onderzoek.

Het eerste kamp zal zich vooral gaan richten op wat er in programmeerjargon front end heet: het bouwen van websites met HTML, CSS en Javascript. Dit is een beetje een uitstervend ras in 2026, maar dat komt vooral door een verminderde vraag vanuit media zelf. Die lopen steeds meer tegen rigide IT-structuren aan die dit soort producties moeilijk maken, en besteden hun geld sowieso liever aan onderzoek. Maar het is naar mijn mening nog steeds legitiem om dit soort expertise in huis te hebben, juist nu de drempel voor toffe interactieve storytelling weer wat lager wordt door de opkomst van kunstmatige intelligentie.

Wie programmeren in wil zetten voor onderzoek, zal zich al snel storten op Python of R (voor de echte statistieknerds). Hier kun je ook nog wat basiskennis kunstmatige intelligentie in de mix gooien zodat je je eigen modellen kunt gaan trainen om groot data-onderzoek mogelijk te maken.

Voor beide types geldt: er is meer dan genoeg goed lesmateriaal online te vinden. Een klein lijstje:

• Lees documentatie, vooral als je met web-dingen bezig gaat. Die van Mozilla is de gouden standaard. Die van Python is taaier, maar wel goed.
• Codecademy heeft goede cursussen.
• The Net Ninja heeft goede cursussen voor wie liever video kijkt (en ze zijn gratis!).
• Udemy heeft goede cursussen. Die zijn wel betaald.
• Voor AI in de journalistiek is er geen betere cursus dan die van Laurens Vreekamp (schaamteloze zelfpromotie, ik werk hier zelf ook aan mee).

Dit is slechts een fractie van wat er online te vinden is. Vraag ook vooral aan de chatbots van deze wereld wat je qua kennis nodig hebt voor een bepaald project, en welke (gratis) cursussen je daar voor zou kunnen volgen.

Om niet vast te lopen in een taaie cursus kan het helpen om de standaardopdrachten links te laten liggen en meteen aan de slag te gaan met iets dat je echt kunt gebruiken. De ervaring leert dat een succesverhaal in je eigen vakgebied meer motivatie oplevert dan het bouwen van een willekeurige website. Bij vibecoding-tools laat dit je bovendien meteen zien of het ook werkt buiten de generieke voorbeelden: elke geautomatiseerde websitebouwer kan een kaarsenwinkel bouwen, niet alles kan een datajournalistiek project aanvliegen.

Hoogover denken

En nu het toch ter sprake is gekomen: moet je het leren programmeren zélf nog anders doen, nu code schrijven voor een groot deel is geautomatiseerd? Ik denk het wel. Het is vooral belangrijk om “hoogover” te kunnen denken: hoe werken datastructuren, hoe haken functies in elkaar, wat is het grotere idee achter de software?

Ook is het nog steeds belangrijk om de infrastructuur rondom code te begrijpen. Zo werken bijna alle programmeurs met git, een soort Google Drive voor code (deze gratis cursus is prima). Ook is het handig als je niet schrikt van een terminal. Voor wie met de browser aan de slag gaat, is het handig om wegwijs te worden in de browser console. Ook hiervoor zijn er genoeg cursussen te vinden.

Wat in het vibecoding-tijdperk belangrijker is dan ooit: veiligheid en privacy. Wanneer je werkt met taalmodellen, zorg dan dat je nooit gevoelige data uit laat lezen door deze modellen. Vervang deze door dummy data wanneer je gaat programmeren en hang de echte data er pas later in. Zorg dat je gevoelige data nooit commit in je repository (als je deze termen niet kent, doe dan vooral de hierboven genoemde snelcursus git).

Voorbij de marketing

Ik gebruik ook taalmodellen om te programmeren. Zelf blijf ik weg bij de echte editors die me alles uit handen nemen (Cursor, Devin). Ik zweer bij een combinatie van Neovim en Claude Code (maar doe dat alleen als je echt 100% comfortabel bent met de terminal). Welke tool je kiest maakt uiteindelijk weinig uit: aan de achterkant gebruiken ze allemaal dezelfde taalmodellen. Welk model je daar kiest, dat bepaalt de kwaliteit van je code.

De snelheid waarmee nieuwe taalmodellen en tools op de markt worden gebracht is ontzettend hoog. Ik schrijf dit in juli 2026, en een deel van de hier genoemde modellen en tools is waarschijnlijk al achterhaald. Daarom is het belangrijk dat je in de gaten blijft houden wat er uitkomt. Pas wel op voor marketingspeak van tech-bedrijven: als je ineens een enorme hausse aan Youtube-video’s voorbij ziet komen over een nieuw model dat “het beste ooit” is, dan zit daar waarschijnlijk ook gewoon een enorm marketingbudget achter.

Open source-modellen

Op het moment van schrijven (juli 2026) heb ik nog geen open source-taalmodel 
gevonden dat kan tippen aan betaalde diensten als Claude Code. Dat betekent
niet dat er niets is dat werkbaar is, maar voor echt productiewerk zet ik het
nog niet in.

Wil je er toch mee experimenteren? Dan kun je Ollama downloaden en dat koppelen
aan je editor/bestaande tools. Zo kun je werken met open source-modellen. 
Gratis, en met een bak minder zorgen over privacy en veiligheid (want er gaat
niets naar de cloud). 

Voor journalistieke taken als het labelen van data (vooral in het Engels) zijn
open source-modellen vaak wel geschikt. 

Probeer nieuwe tools eerst uit met voorbeelden uit jouw vakgebied voordat je een paar tientjes per maand betaalt. Als je sites als Wired en The Verge zijdelings in de gaten houdt, dan hoor je vanzelf wanneer iets echt belangrijk is. Besteed liever wat extra tijd aan het beter worden in programmeren en de tools die je al hebt dan aan het uitproberen van allerlei nieuwe tools.

Leesbare code

In mijn werk zie ik veel code die is gemaakt door taalmodellen. Die is vaak prima. Wat er wel misgaat, vooral bij beginnende programmeurs, is de leesbaarheid en de documentatie.

Taalmodellen houden ervan om enorm lange bestanden te maken, met honderden regels code. Die zijn slecht leesbaar: zie die ene regel waar het misgaat maar eens te vinden in zo’n kluwen van code. Ook hebben variabelen en functies vaak abstracte namen en wordt code vaak niet goed “opgeruimd” (het verwijderen van niet meer gebruikte regels etc.).

Juist voor beginnende programmeurs is het heel belangrijk dat code duidelijk en goed leesbaar is. Dé cursus die ik dan ook aan iedereen aanraad is deze: *Writing clean code van Academind. *Doe die wel nadat je minstens een programeertaal beheerst, welke maakt niet uit.

Nog een tip: als je werkt met een tool als Claude Code, dan kun je een instructiebestand gebruiken om het taalmodel te sturen richting het schrijven van leesbare, duidelijke code. Daarmee sta je al met 1–0 voor. Hieronder die van mij (voor de meeste projecten).

# Project Context

When working with this codebase, prioritize readability and clean code over cleverness. Ask clarifying questions before making architectural changes.

## About This Project

[LINE OR TWO ABOUT PROJECT]

## Key Directories

List in following format: 

- `app/models/` - database models
- `app/api/` - route handlers

## MCP servers

Always use Context7 MCP when I need library/API documentation, code generation, setup or configuration steps without me having to explicitly ask. 

## Standards

My coding standard is heavily focused on clean, modular code. Avoid long files and put explanations in READMEs rather then in the code itself. I prefer provider agnostic code, where functionality is implemented in a way that there is an abstraction layer on top which allows you to switch providers easily when it comes to things such as databases, deployment etc. 

### Naming variables and functions

- Use descriptive and meaningful names 
- For variables and properties: Nouns or short phrases with adjectives
- For functions and methods: verbs short phrases with adjectives
- For classes: nouns
- For booleans: yes/no questions (like isValid) 

### General clean code principles

- Limit the number of parameters in functions
- Functions should be small and do one thing. Avoid mixing levels of abstraction, but also avoid redundant splitting
- Use small classes with a single responsibility and with high cohesion
- Stay DRY: do not repeat yourself. Put functionality in different files and load them in different parts of the code if needed
- Avoid unexpected side effects
- Prefer positive checks
- Avoid deep nesting. Use the law of Demeter for "real objects" 
- Use the SOLID principles, especially SRP and OCP. 

### Folder and file structure

- When using python, place functions in a functions/ folder and if needed, subfolders for functions in a common category
- When using python, use a one function per file strategy (combined with the above), avoid functions starting with an underscore in favor of clearly named subfunctions (for small utilitarion functions, place them in a functions/utils/ folder if needed) 
- When using python, place common variables in a .env file (and always a .env.example equivalent) and use python-dotenv
- When using javascript, place functions in separate js files if it makes files less readable otherwise
- When using javascript frameworks, stick to component structures but avoid long functions in component files (put these in separate js files)

### Comments

- Avoid comments as much as possible, use clear variable naming and clean code instead
- If more elaborate explanation feels necessary, create a README file or add some explanation there
- Comments are acceptable for legal stuff, warnings, helpful explanations (i.e. with regex) or todo's

## Common Commands

Possible commands in this format: 

```bash
uvicorn app.main:app --reload  # dev server
pytest tests/ -v               # run tests

Notes

[EXTRA NOTES]

Leren programmeren heeft dus nog steeds zin voor journalisten in het tijdperk van kunstmatige intelligentie. En dat zal ook nog wel even zo blijven, zeker in de (moderne) journalistiek waarin methodiek en transparantie zo belangrijk zijn. Waar worstelen met de syntaxis van obscure programmeertalen grotendeels tot het verleden behoort, is het kunnen begrijpen van wat je aan het doen bent tijdloos.