Twee dagen het kantoor vol Newspark-collega’s en overal groepjes die aan hun eigen AI-opdracht werkten. Met tussendoor net zoveel kennisdeling als koffie, (alcoholvrije) biertjes, snoep en snacks. Ik ontdekte tussen twee testruns door dat Jelle, net als ik, recent in IJsland was geweest. Voor je het weet sta je vakantiekiekjes te vergelijken in plaats van code.
Samen met Bas en Hidde ging ik aan de slag met de opdracht 'een lokale code review bot inrichten met Ollama en een LLM'. We schoten al snel alle drie onze eigen kant op, niet in de laatste plaats omdat ons startniveau qua ervaring met AI nogal uiteenliep. Maar we kwamen steeds weer bij elkaar terug om te laten zien hoe we er mee bezig waren. Dat 'heen-en-weer' leverde meer op dan wanneer we allemaal hetzelfde pad hadden gevolgd. Het grappigste moment kwam al vroeg op dag één: nog geen vijf minuten nadat ik, direct na de installatie van Ollama en Qwen, mijn allereerste vliegtuigmodus-test had afgerond, viel het internet op kantoor daadwerkelijk uit.
Terwijl een deel van mijn collega’s stillag omdat ze afhankelijk waren van cloud-AI, kon ik gewoon lokaal doorwerken. Puur toeval. Maar wel een toeval dat precies liet zien waarom lokaal draaien meer is dan een leuk hackathon-experiment.
Drie testers, drie aanpakken, één opdracht
De opdracht klonk simpel: richt lokaal een LLM in dat code kan reviewen, zonder dat jouw code de deur uit hoeft voor een cloud-dienst. Het doel van de hackaton was vooral leren én plezier hebben: welke tools zijn er, hoe zet je zoiets op en welke coding guidelines wil je de AI eigenlijk laten toetsen.
Bas, Hidde en ik hadden alle drie een ander startpunt qua AI-ervaring, en dat was precies waarom we al snel uit elkaar dreven in onze aanpak. Ieder van ons verkende het onderwerp op zijn eigen manier en op zijn eigen tempo en juist door elkaar tussendoor te laten zien waar we tegenaan liepen, pikten we bij elkaar dingen op, die we zelf niet hadden gevonden. Dat is voor mij de kern van een hackathon: je wint er niks mee als je in je eentje het snelste resultaat neerzet, het draait juist om die omwegen van elkaar mogen zien.
Ollama en qwen2.5-coder: sneller opgezet dan ik het kon lezen
Ik startte met een vraag in de strekking van 'waar begin ik?' aan Claude. Als antwoord kwam 'Ollama downloaden en installeren en daarna een model kiezen'. Ik was van plan om eerst de officiële quickstart-documentatie door te lezen voordat ik zou beginnen, maar voordat ik daar goed en wel aan toe was, stond Ollama al geïnstalleerd. Dat zegt denk ik meer over de drempel van dit soort tools, dan ik van tevoren had verwacht. Die drempel is eigenlijk verrassend laag.
Van de voorgestelde modellen koos ik qwen2.5-coder, dat het meest geschikt leek voor codegerelateerde taken. Ik heb tijdens de hackathon bewust geen andere modellen uitgeprobeerd. Het doel was niet het perfecte model vinden, maar hands-on ervaren hoe je zoiets opzet en welke theorie en andere randzaken daarbij komen kijken.
Testdata, commits en een reviewer die meekijkt
Een AI die code reviewt, heb je pas echt getest als je hem tegen iets aan laat lopen. Daarvoor bouwde ik een klein testproject in git, met een reeks commits die ik bewust liet groeien. Elke commit gaf de reviewer nieuwe input in de vorm van een diff.
Wat ik uiteindelijk bouwde, groeide uit tot een kleine .NET-consoletool die:
- een git diff tussen twee commits ophaalt
- een markdown-bestand met team-conventies inleest
- diff en conventies naar Ollama stuurt
- de review teruggeeft via een paar losse review-agents: een Security Agent, een Code Style Agent en een Test Conventions Agent
Die drie agents draaien los van elkaar, met een taal als losse parameter, dus is de tool in theorie ook bruikbaar voor een andere stack dan C# (dit heb ik overigens nog niet getest, of dat ook daadwerkelijk zo werkt) en met een ander conventies-bestand. Deze opzet was overigens puur voor het leerproces: er bestaan inmiddels ook gewoon kant-en-klare plugins voor onder andere Visual Studio Code en andere IDE’s om vergelijkbare acties met Ollama uit te voeren.
