De eerste keer dat ik een gratis model vroeg om een functie te schrijven om een formulier te valideren, was het antwoord onberispelijk… totdat ik het uitvoerde met een leeg veld en het crashte. De code compileerde, had een nette structuur en de commentaren waren perfect. Maar het faalde in het meest voor de hand liggende geval. Die ervaring vat redelijk goed samen wat je kunt verwachten van gratis LLM’s voor programmeren: ze zijn een enorme hulp als je weet hoe je ze moet gebruiken, en een bron van frustratie als je delegeert zonder te controleren.
Deze gids is bedoeld voor wie begint. Ik ga niet de tien beste modellen in alfabetische volgorde opsommen en je ook niet beloven dat je zult programmeren zonder te weten hoe je moet programmeren. We bekijken welke gratis tools er bestaan, waar hun echte grenzen liggen en hoe je ze kunt benutten zonder absurde fouten te maken.
Wat je kunt verwachten van een gratis LLM (en wat niet)
Voordat je welke tool dan ook aanraakt, is het goed om het terrein helder te hebben. Een LLM is geen compiler en geen linter. Het is een tekstgenerator die miljoenen regels code heeft gezien en reeksen produceert die er statistisch gezien uitzien als correcte code. Dat betekent dat:
- Het wel goed werkt voor: het genereren van repetitieve sjablonen, het uitleggen van foutmeldingen, het vertalen van code tussen talen, het schrijven van basistests, het opstellen van documentatie of het voorstellen van structuuralternatieven.
- Het niet goed werkt voor: garanderen dat de code compileert, je privécodebase kennen (in gratis plannen is er bijna nooit volledige repository-context), prestatieproblemen in grote systemen oplossen of redeneren over exotische afhankelijkheden.
- Je nooit moet aannemen: dat de bibliotheken die het noemt bestaan, dat de versies actueel zijn of dat de API’s die het citeert niet zijn veranderd. Modellen hallucineren functienamen met een verontrustende zekerheid.
Volgens de officiële documentatie van verschillende aanbieders beperken gratis plannen meestal het aantal berichten per tijdvenster, de lengte van de context en, in sommige gevallen, de toegang tot recentere modellen. Dat maakt ze niet nutteloos; het betekent dat je goed moet kiezen waarvoor je ze gebruikt.
Gratis opties die het waard zijn om te proberen
Webchats met generalistische modellen
Bijna alle grote aanbieders bieden een gratis versie van hun chatbot met codeermogelijkheden. Het praktische verschil tussen hen zit in drie dingen: hoeveel berichten je kunt sturen voordat je wordt afgeremd, of ze het plakken van bestanden accepteren en hoe goed ze minder populaire talen aankunnen. Voor HTML, CSS, JavaScript en Python is elke optie geschikt. Als je met COBOL, Fortran of een interne DSL werkt, kelderen de kwaliteit bij allemaal.
Een truc die frustratie bespaart: open geen nieuwe chat voor elke vraag. Houd één gesprek per project aan en plak de relevante context aan het begin (bestandsstructuur, taalversie, framework). Gratis modellen verliezen gemakkelijk de draad wanneer je van onderwerp verandert, en slepen aannames mee uit het vorige bericht.
Automatische aanvulling in de editor
Hier zijn meer nuances dan het lijkt. Extensies voor automatische aanvulling met AI hebben gratis plannen, maar meestal met een maandelijks quotum aan suggesties. Voor een beginner die 30 regels per dag schrijft, is dat quotum ruim voldoende. Voor iemand die zes uur per dag programmeert, is het in één middag op.
Mijn praktische aanbeveling: installeer er één, gebruik het een week met de suggestieteller in het zicht en beslis daarna of het de moeite waard is. Veel mensen ontdekken dat automatische aanvulling hen meer afleidt dan helpt wanneer ze aan het leren zijn, omdat ze suggesties accepteren zonder ze te lezen.
Lokaal uitgevoerde modellen
Dit is de optie die het minst wordt genoemd en die je het meest kan interesseren als privacy prioriteit hebt of een onstabiele verbinding. Tools zoals Ollama of LM Studio maken het mogelijk om open modellen te downloaden en op je machine uit te voeren zonder kosten per gebruik. De keerzijde is duidelijk: je hebt hardware nodig. Een model met 7B parameters draait op een laptop met 16 GB RAM, maar de kwaliteit van de antwoorden in code ligt verschillende niveaus onder die van de grote modellen in de cloud.
Een concreet geval dat ik heb zien falen: een klein lokaal model vragen om een SQL-query te genereren met een JOIN van drie tabellen en een GROUP BY. Het resultaat had de juiste syntaxis en de verkeerde logica. Met grote modellen in de cloud slaagt dezelfde prompt meestal wel. Het is geen magie, het is omvang en trainingsdata.
Een workflow die verrassingen voorkomt
Wat iemand die gratis LLM’s benut scheidt van iemand die de hele dag rommel zit te debuggen, is het proces. Dit is degene die ik gebruik en die je kunt aanpassen:
- Beschrijf het probleem voordat je om code vraagt. In plaats van «schrijf me een functie die dit sorteert», leg uit welke data je hebt, welke beperkingen er zijn en wat je al hebt geprobeerd. De kwaliteit van het antwoord stijgt enorm.
- Vraag eerst om een uitleg, dan om de implementatie. Als het model je de aanpak uitlegt en jij het begrijpt, is de daaropvolgende code gemakkelijker te controleren. Als je de uitleg niet begrijpt, gebruik de code dan niet.
- Vraag de code in kleine stukjes. Een functie, een test, een configuratieblok. Grote blokken verbergen fouten die je pas ziet wanneer je uitvoert.
- Voer altijd lokaal uit. Geen uitzondering. Zelfs als de code triviaal lijkt, test hem met randgevallen: leeg, null, negatief getal, zeer lange string.
- Vraag naar de versies. «Bestaat deze API in versie 3.2 van deze bibliotheek?» is een vraag die je een half uur zoeken in de documentatie bespaart.
Een voorbeeld van een veelvoorkomende fout die je alleen met ervaring ziet
Wanneer je een LLM vraagt om code te genereren om een CSV-bestand te lezen, stelt het bijna altijd een oplossing voor die het hele bestand in het geheugen laadt. Voor een testbestand van 100 regels werkt dat perfect. Voor de CSV van 2 GB die je in productie hebt, raakt je machine zonder geheugen en sterft het proces. Het model waarschuwt je niet omdat in zijn training de meeste voorbeelden klein zijn. Als je expliciet vraagt naar streaming-lezen of naar de maximale bestandsgrootte, geeft het een betere oplossing. De les: vermeld de productiecontext in de prompt, niet alleen het abstracte probleem.
Waar de echte grenzen liggen
Er zijn taken waarbij een gratis LLM, hoe goed ook, je niet zal helpen. Ze herkennen bespaart je tijd:
- Code debuggen die je niet plakt. Als de fout afhangt van een interactie tussen drie bestanden en je laat er maar één zien, dan gokt het model.
- Een heel project refactoren. Gratis plannen hebben geen volledige repository-context. Ze geven je lokale patches die andere delen kunnen breken.
- Beveiliging. Een model kan code genereren met injectie-kwetsbaarheden zonder dat te melden. Als de code met gebruikersgegevens omgaat, controleer hem dan met specifieke tools of met iemand met ervaring.
- Talen met kleine ecosystemen. Hoe minder publieke code er van een taal bestaat, hoe slechter het antwoord. Dit omvat propriëtaire talen en interne bedrijfsframeworks.
Er is ook een praktische grens: gratis quota raken op. Als je midden in een probleem zit en de chat blokkeert je, heb je een alternatief nodig. Twee geconfigureerde tools hebben (een primaire en een reserve) voorkomt dat een gebruikslimiet je werk stillegt.
Hoe je kiest zonder de middag te verliezen
Er is geen enkele tool die voor iedereen het beste is. Het hangt af van je taal, je hardware en hoeveel code je per dag schrijft. Mijn suggestie is dat je drie verschillende profielen elk een week uitprobeert:
Een generalistische webchat voor conceptuele vragen en uitleg. Een extensie voor automatische aanvulling voor het dagelijkse werk. En een lokaal model als je apparatuur het toelaat, voor tests met gevoelige data. Met die combinatie dek je 90 % van de gevallen van een beginner af zonder iets te betalen.
En een laatste waarschuwing die meer waard is dan welke lijst van tools dan ook: gratis LLM’s zijn een versneller van het leren, geen vervanging. Als je de code die je terugkrijgt niet kunt lezen, kun je niet beoordelen of die correct is. De investering in het begrijpen van de fundamenten van de taal blijft op lange termijn de meest rendabele. Tools veranderen elke paar maanden; wat je leert, niet.