Geen hype. Geen afwijzing. Alleen de vraag: wat kan het echt?
Ik gebruik AI-modellen sinds enige tijd in mijn dagelijkse werk. Niet omdat het modern is, maar omdat het gereedschappen zijn – en gereedschappen moet je toetsen. Wat helpt, blijft. Wat alleen maar extra werk oplevert, vliegt eruit. Dat geldt voor een soldeerbout net zo goed als voor een taalmodel.
Deze pagina is geen vergelijkingstest in tijdschriftstijl, geen toplijst en geen koopadvies. Het is een doorlopende, nuchtere inventaris van wat ik in de praktijk waarneem: waar AI-gereedschappen echt nut hebben, waar ze betrouwbaar falen, en wat je moet weten om je niet door het oppervlak te laten misleiden.
System Diagnostic
> AI_TOOLS EVALUATION FRAMEWORK
GETESTChatGPT · Gemini · Grok · ClaudeCONTEXTwebontwikkeling / HTML / teksten / onderzoek / code-reviewNIVEAUSvergelijking van gratis en betaalde toegangHOUDINGdenken in gereedschap / geen hype / eigen controleSTANDwordt voortdurend bijgewerkt – modellen veranderen, beoordelingen ook
Fouten worden zelfstandig herkend en gecorrigeerd. Het model schrijft, de mens beslist.
[mindset/approach]
Basishouding: gereedschap, geen autoriteit
Wie met oudere techniek heeft gewerkt, leert vroeg dat een systeem precies doet wat het doet – niet meer en niet minder. Het heeft bugs, grenzen, eigenschappen en foutpatronen. Die houding helpt ook bij AI-gereedschappen: het zijn systemen. Wie ze als autoriteit behandelt, maakt dezelfde fout als iemand die een plausibel klinkende output meer vertrouwt dan zijn eigen begrip.
Dat betekent concreet: elke uitvoer van een taalmodel is een voorstel, geen feit. Ook als de toon zeker klinkt. Juist als de toon zeker klinkt. Taalmodellen zijn niet daarom problematisch omdat ze soms ongelijk hebben. Problematisch zijn ze daar waar een fout dezelfde toon krijgt als een correcte uitspraak.
Daaruit volgt een eenvoudige werkregel: het model schrijft, ik beslis. Ik corrigeer fouten zelf. Ik controleer feiten die ertoe doen. Ik gebruik AI als versnelde eerste schets, niet als laatste woord. Dat is geen bijzondere voorzichtigheid, maar de enige verstandige manier om een gereedschap zonder eigen foutmelding te gebruiken.
[Basisregel] AI-gereedschappen in het dagelijks werk > uitvoer is altijd: voorstel, geen eindresultaat > zekere toon betekent niet: correcte informatie > controle blijft bij de gebruiker – niet bij het model > nuttig wanneer: het versnelt zonder te ontmachten
„Een gereedschap zonder foutmelding heeft een gebruiker nodig die fouten herkent.“
[technical/llm_basics]
Wat LLM's werkelijk doen – kort en zakelijk
Large Language Models – LLM's – zijn geen databanken, geen zoekmachines en geen denkende systemen. Het zijn modellen die op basis van zeer grote hoeveelheden tekst zijn getraind om het waarschijnlijkste volgende token voor een gegeven invoer te voorspellen. Dat is geen vereenvoudiging, maar de kern.
Wat daaruit ontstaat, is opmerkelijk: uit waarschijnlijkheidsverdelingen over tokens ontstaat tekst die samenhangend klinkt, argumenten opbouwt, code schrijft, verbanden legt en vragen beantwoordt. Dat werkt omdat taal zelf structuur heeft – en omdat een model dat die structuur goed heeft geleerd daaruit bruikbare uitvoer kan genereren.
Maar: het model heeft geen wereldkennis in de zin van een geverifieerde databank. Het heeft patronen – heel veel, heel goed gegeneraliseerde patronen. Wanneer het een jaartal noemt, haalt het geen veilig opgeslagen feit op, maar genereert het het token dat in deze context het waarschijnlijkst is. Dat verklaart waarom feiten soms kloppen en soms niet.
Wat LLM's goed kunnen
Samenhang in tekst opbouwen. Bekende structuren reproduceren. Parafraseren. Code in bekende patronen schrijven. Samenvatten. Vertalen. Stijl aanpassen.
Dat alles werkt goed daar waar geen externe verificatie aan de werkelijkheid nodig is.
Wat LLM's structureel niet kunnen
Zelf weten of een uitspraak waar is. Actuele gebeurtenissen zonder zoeken betrouwbaar kennen. Eigen onzekerheid consequent zichtbaar maken. Meerstapsberekeningen zonder hulpmiddelen veilig oplossen.
Dat zijn geen toevallige fouten, maar eigenschappen van de architectuur.
Een training-cutoff betekent: het model weet niets van gebeurtenissen na die datum, tenzij externe zoekfunctionaliteit is gekoppeld. Voor actuele onderwerpen is een taalmodel zonder zoektoegang daarom slechts beperkt bruikbaar.
[tools/overview]
De gereedschappen afzonderlijk
Ik heb alle vier hier genoemde gereedschappen gedurende langere periodes in echt gebruik getoetst – niet in een testlab, maar bij echt werk: HTML-pagina's schrijven en controleren, teksten formuleren, onderzoek doen, code nalezen, redactioneel gladstrijken. De inschattingen zijn subjectief en tijdgebonden. Modellen ontwikkelen zich, prijsmodellen veranderen en sterke en zwakke punten verschuiven.
ChatGPT
OpenAI · gratis en betaalde toegang
ChatGPT was voor mij een van de eerste gereedschappen van deze klasse die in het dagelijks werk echt bruikbaar werden. De kracht ligt in de veelzijdigheid: van eenvoudige tekstbewerking tot complexere structuur- en code-opgaven dekt het een breed spectrum af.
In HTML- en webwerk is ChatGPT degelijk, maar niet foutloos. Bekende patronen worden goed gereproduceerd. Bij zeer specifieke eisen – bijvoorbeeld ongebruikelijke CSS-constructies, A11y-details of lastige randgevallen – komen fouten voor die vaak met veel zelfvertrouwen worden gepresenteerd.
Praktisch nuttig is het vooral daar waar een eerste schets, een herformulering of een gestructureerde voorbewerking nodig is. Voor feiten, actuele onderwerpen of juridische uitspraken blijft gelden: controleren.
Algemene teksten: goedCode-basis: goedFeitelijke juistheid: controlerenActualiteit: alleen met zoeken
Gemini
Google · gratis en betaalde toegang
Gemini heeft een natuurlijk voordeel bij alles wat actuele informatie en Google-nabije contexten betreft. Dat maakt het voor onderzoeksopgaven interessanter dan puur offline modellen zonder webtoegang.
In tekstkwaliteit werkt Gemini op mij vaak gladder, deels ten koste van scherpte. Bij technische vragen levert het niet zelden algemenere antwoorden waar een concretere nuttiger zou zijn. Dat is een werkindruk, geen meetwaarde.
Nuttig was Gemini voor mij vooral daar waar actualiteit telt: nieuwere documentaties, huidige productstanden, zoekonderwerpen. Voor puur tekstwerk zonder onderzoeksdeel is het verschil kleiner.
Grok heeft een voor de hand liggend voordeel bij alles wat direct zichtbaar en relevant is in de X-omgeving. Voor die context kan dat nuttig zijn. Daarbuiten is het voordeel duidelijk kleiner.
In mijn gebruik lijkt Grok sterker geoptimaliseerd voor snelle, puntige antwoorden dan voor rustige, precieze technische arbeid. Voor HTML-review, nuchter tekstwerk en gestructureerd fijn werk was het in mijn praktijk minder betrouwbaar dan de andere hier genoemde gereedschappen.
Dat kan veranderen. Op het moment van deze inschatting is het voor mijn manier van werken het minst gebruikte gereedschap uit deze groep.
Claude is voor mij vooral nuttig bij langere, meer gestructureerde taken – vooral bij HTML-werk, redactionele tekstbewerking en grotere gesprekscontexten. Het praktische voordeel ligt minder in spectaculaire losse antwoorden dan in rustige consistentie over langere trajecten.
Voor HTML-pagina's en terugkerende patronen is Claude bruikbaar gebleken, niet omdat het geen fouten maakt, maar omdat de foutpatronen voor mij vaak voorspelbaarder zijn. Een gereedschap waarvan ik de fouten sneller herken, is in het dagelijks werk nuttiger dan een gereedschap dat onrustiger werkt.
Zwak blijft alles wat actuele feiten, lokale informatie of sterk tijdafhankelijke details vereist, voor zover geen zoekkoppeling beschikbaar is. Voor zulke taken is externe controle noodzakelijk.
Lange contexten: sterkHTML / structuurwerk: goedConsistentie: goedActualiteit: beperkt
[evaluation/strengths]
Waar AI echt helpt
Na langere praktijk heeft zich een duidelijk beeld gevormd van welke taken werkelijk profiteren van AI-gereedschappen en welke niet. Dat is geen theorie, maar het resultaat van wat in het dagelijks werk standhield en wat niet.
[+] Eerste schets versnellen
Het beginnen aan een tekst, een HTML-sectie of een codeblok kost vaak meer tijd dan het uitwerken. AI levert snel een eerste schets die daarna wordt bewerkt.
[+] Herformuleren en varianten
Een afgewerkte tekst anders formuleren, inkorten of in een andere toon schrijven – dat werkt goed en bespaart vooral wrijving bij de start.
[+] Boilerplate-code
Standaardstructuren die je kent, maar niet telkens opnieuw wilt typen: HTML-basisstructuren, CSS-blokken, JSON-LD-structuren, kleine hulpscripts.
[+] Uitleg geven en samenvatten
Complexe specificaties vereenvoudigen, lange teksten inkorten, technische zaken in begrijpelijker taal overzetten – hier zijn LLM's structureel sterk.
[+] Code reviewen
Bekende patronen in code herkennen, inconsistenties benoemen, duidelijke fouten aanwijzen. Geen vervanging voor testen, maar wel een bruikbare eerste controle.
[+] Vertalingen
Voor technische en zakelijke teksten zijn machinale vertalingen tegenwoordig bruikbaar. Voor sterk genuanceerde of stilistisch gevoelige teksten blijft controle verplicht.
Wat deze sterke punten verbindt: ze profiteren er allemaal van dat het model veel patronen kent en er snel toegang toe heeft – en ze vereisen allemaal geen zekere verificatie tegen de buitenwereld.
[evaluation/limits]
Systematische grenzen
Er zijn grenzen die geen bugs zijn en ook met een beter model niet zomaar verdwijnen. Ze volgen rechtstreeks uit de architectuur. Wie ze kent, werkt efficiënter, omdat hij niet probeert iets van een gereedschap te eisen wat het structureel niet kan leveren.
[-] Feitelijke juistheid
Taalmodellen hebben geen intern waarheidscriterium. Wat waarschijnlijk klinkt, wordt uitgegeven – ongeacht of het klopt.
Gevolg: elke feitelijke uitspraak die telt, wordt gecontroleerd.
[-] Actualiteit
Training-cutoff betekent: alles na een bepaald moment is zonder zoeken onbekend. Het model kan die grens zelf niet altijd netjes markeren.
Gevolg: voor actuele onderwerpen zoeken of een externe bron gebruiken.
Gevolg: zelf rekenen of geschikte tools gebruiken.
[-] Lokaal en specifiek
Wat zelden op het internet voorkomt, is vaak slecht in het model vertegenwoordigd. Lokale informatie, nichethema's en zelden gedocumenteerde details zijn bijzonder foutgevoelig.
Gevolg: hoe specifieker het onderwerp, hoe zorgvuldiger de controle.
[-] Consistentie over gesprekken heen
Zonder persistent geheugen vergeet het model eerdere gespreksonderdelen zodra de relevante context niet meer actief in het venster ligt.
Gevolg: belangrijke eisen bij lange gesprekken herhalen.
[-] Zelfkritiek
Als je een model vraagt of zijn eigen output correct is, neigt het tot bevestiging. Eigen fouten worden zonder concreet tegenwicht niet betrouwbaar herkend.
Gevolg: controle door de gebruiker, niet door het model zelf.
[problems/hallucination]
Hallucinaties – het centrale probleem
„Hallucinatie“ is de term voor het moment waarop een taalmodel dingen verzint en daarbij klinkt alsof het zeker is. Niet als een duidelijke crash, maar als een vloeiende, grammaticaal correcte, semantisch samenhangende uitspraak die gewoon fout is.
Het verraderlijke daaraan: hallucinaties zijn vaak zonder externe controle niet herkenbaar. Een verzonnen boektitel klinkt als een echte. Een verkeerde API-functie klinkt plausibel. Een fout jaartal klinkt niet anders dan een juist.
Typische patronen die ik heb waargenomen
Verzonnen bronnen: Wordt naar bewijzen gevraagd, dan produceert het model soms formeel plausibele literatuurverwijzingen of links die zo niet bestaan.
Onjuiste technische details: Registernamen, bitnummers, protocoleigenschappen of API-parameters worden plausibel samengesteld zonder werkelijk correct te zijn.
Geïnterpoleerde biografieën: Bij minder bekende personen of producten worden details toegevoegd die kloppend klinken, maar niet onderbouwd zijn.
Code die niet werkt: Syntactisch nette code kan semantisch fout zijn of gebaseerd zijn op functies die in de beweerde vorm niet bestaan.
[Hallucinatierisico] per type taak ; > LAAG: tekst herformuleren / vertalen / structureren > MIDDEL: code in bekende patronen / algemene feiten > HOOG: specifieke feiten / bronnen / zeldzame technische details > ZEER HOOG: lokale informatie / actuele gebeurtenissen / niches
Mijn praktische consequentie: bij taken met een hoog hallucinatierisico gebruik ik AI alleen voor schetsen die ik volledig controleer. Bij taken met een laag risico – tekst herformuleren, HTML structureren, bekende patronen – is de controle minder zwaar, maar nooit helemaal overbodig.
„Een model dat zeker klinkt, heeft niet gelijk. Het klinkt alleen zeker.“
[technical/context_window]
Contextvenster en geheugen
Het contextvenster is het gebied dat een taalmodel tijdens een gesprek kan „zien“. Alles wat daarin ligt – eerdere berichten, instructies, ingevoegde documenten – is voor het model toegankelijk. Wat daarbuiten valt, is weg.
Grote contextvensters klinken naar veel. In de praktijk blijft echter gelden: ook binnen dat venster krijgen nieuwere inhoud vaak meer gewicht dan oudere. Eisen uit het begin van een lang gesprek worden tegen het einde niet altijd even betrouwbaar gevolgd.
Geen persistent geheugen
Zonder expliciete geheugenfunctie begint elk nieuw gesprek bij nul. Het model weet niet automatisch wat in een ander gesprek is besproken, welke werkwijze je verkiest of welke regels je vorige week hebt vastgelegd.
Voor langere projecten betekent dat: belangrijke eisen, stijlregels en beperkingen moeten ofwel aan het begin opnieuw worden genoemd of expliciet worden meegegeven. Dat is geen zwakte van één specifiek model, maar een eigenschap van het systeem.
[Contextstrategie] voor terugkerende taken > eisen expliciet formuleren – niet veronderstellen > belangrijke regels aan het begin van het gesprek noemen > bij lange gesprekken: tussensamenvatting van wat geldt > model niet als archief gebruiken – dat is de taak van de gebruiker
[technique/prompting]
Hoe je vraagt maakt het verschil
„Prompt-engineering“ klinkt soms als duistere kunst. In werkelijkheid is het alleen de observatie dat formulering, context en beperkingen de kwaliteit van het antwoord merkbaar beïnvloeden.
Wat daadwerkelijk helpt
Context geven, niet veronderstellen: Een precieze inkadering leidt bijna altijd tot bruikbaardere antwoorden dan een korte wens zonder kader.
Negatieve eisen noemen: „Geen bulletpoints. Geen reclametoon. Niet inkorten.“ Zulke uitsluitingen zijn vaak belangrijker dan positieve wensen.
Stapsgewijs werken: Inhoud, toon, structuur en formaat niet onnodig in één enkel bevel persen.
Voorbeelden geven: Een concreet patroon is voor een taalmodel bijna altijd beter dan een abstracte stijlomschrijving.
Uitvoerformaat vastleggen: HTML, doorlopende tekst, precies één codeblok, geen koppen – als dat belangrijk is, moet het worden gezegd.
Fouten direct benoemen: Precieze correctie bespaart iteraties. Vage kritiek creëert nieuwe vaagheid.
Wat ik niet doe: urenlang prompts optimaliseren voor taken die ik in dezelfde tijd zelf zou kunnen afmaken. Een gereedschap bespaart alleen tijd als de bediening niet meer werk oplevert dan de taak zelf.
[economics/tiers]
Gratis versus betaald
Bijna al deze gereedschappen hebben gratis instappen en betaalde uitbreidingen. Of een abonnement zinvol is, hangt minder van de aanbieder af dan van de eigen werksituatie.
Gratis versies zijn vaak voldoende voor incidenteel gebruik: korte teksten, eenvoudige herformuleringen, eerste tests. Wie vaker werkt, langere contexten nodig heeft of uitgebreidere functies wil beoordelen, loopt daar snel tegen grenzen aan.
Een betaalde test is dan zinvol wanneer je een gereedschap echt wilt inschatten. De gratis versie laat vaak niet het volledige beeld zien: minder vermogen, lagere limieten, minder functies. Wie serieus wil beoordelen of een gereedschap in het dagelijks werk standhoudt, heeft een paar weken onder echte omstandigheden nodig.
In de praktijk is het verschil tussen gratis en betaald bij dezelfde aanbieder vaak groter dan het verschil tussen twee betaalde aanbiedingen van verschillende aanbieders.
[practical/webdevelopment]
AI in webontwikkeling: concreet
Wat ik daadwerkelijk inzet en wat niet – uit het dagelijkse werk met HTML, tekst en structuur.
Wat goed werkt
HTML-structuur genereren: Voor nieuwe subpagina's volgens een bekend patroon is een eerste schets vaak zinvol. Niet direct af, maar wel duidelijk sneller dan leeg beginnen.
Code-review: Inconsistenties, dubbele ID's, duidelijke fouten, ontbrekende kleinigheden – een eerste controle laat zich goed versnellen.
JSON-LD-structuur: Schema.org-markup is goed genoeg gedocumenteerd om snel bruikbare schetsen te laten genereren.
Teksten herformuleren: Een zakelijke beschrijving in begrijpelijkere taal brengen – of juist omzetten naar een nuchtere stijl – werkt betrouwbaar.
Reguliere expressies en kleine hulpscripts: Voor duidelijk afgebakende eenmalige taken bespaart dat tijd.
Wat ik niet blind inzet
Juridische of privacygerelateerde teksten zonder aansluitende eigen controle.
Toegankelijkheid zonder nacontrole. Voorstellen zijn nuttig, maar geen bewijs.
Prestatie-uitspraken zonder meting. Snel is alleen wat gemeten sneller is.
Veiligheidsrelevante configuraties zonder eigen begrip.
[Workflow] typische inzet bij een nieuwe subpagina > 1. Voorbeeldpagina als context geven + eisen formuleren > 2. Eerste schets laten genereren > 3. Inhoudelijk herwerken – feiten, toon, structuur > 4. Technisch controleren – HTML, ARIA, links, consistentie > 5. In de browser testen – geen vervanging voor eigen blik > AI is stap 2, niet stap 3–5
De fundamentele technische houding daarachter beschrijft ook philosophy.htm. Daar gaat het minder om afzonderlijke gereedschappen dan om de vraag waarom technische beslissingen überhaupt op die manier worden genomen.
[conclusion/summary]
Conclusie: wat overblijft
Na alles wat ik tot nu toe heb waargenomen, is mijn indruk noch enthousiasme noch afwijzing, maar vooral plaatsbepaling. AI-gereedschappen zijn bruikbaar. Ze versnellen bepaalde taken duidelijk. Ze hebben reële, systematische grenzen. Beide tegelijk zien is de enige zinvolle houding.
Wat mij in de publieke discussie stoort, is de neiging deze gereedschappen ofwel als revolutie te vieren ofwel ze pauschal af te wijzen. Geen van beide helpt verder. Een gereedschap is goed wanneer het in concrete situaties nuttig is – en het is alleen nuttig daar waar je het gecontroleerd inzet en de grenzen kent.
Het werkelijke probleem is niet dat fouten gebeuren. Het werkelijke probleem is dat fouten er vaak uitzien als successen. Daartegen helpt maar één ding: eigen vakkennis. Wie een gereedschap gebruikt dat hij niet kan controleren, geeft controle uit handen.
[Conclusie] AI-gereedschappen – stand van zaken > nuttig: versnelling van bekende taken > nuttig: eerste schets, herformulering, structurering > limiet: geen interne feitencontrole > limiet: geen vervanging voor domeinkennis > limiet: actualiteit alleen met zoeken > conclusie: bruikbare gereedschappen met bekende eigenschappen > houding: controle blijft altijd bij de gebruiker
Deze pagina wordt bijgewerkt wanneer er iets wezenlijks verandert. Modellen ontwikkelen zich snel, en wat vandaag geldt, geldt later misschien niet meer. Dat is geen reden om geen inschatting te formuleren – maar wel een reden om die open te houden.
„Een gereedschap dat ik niet kan controleren, is geen gereedschap – het is een risico.“
Juridische opmerkingen
Deze pagina is een onderdeel van de webpresentatie van het Hotel Goldener Ochsen in Göppingen-Hohenstaufen.
Verantwoordelijk voor de inhoud van dit domein is de exploitant van het hotel. Gedetailleerde informatie over de verantwoordelijke en over privacy vindt u op de officiële hoofdpagina's van het hotel.
Ook deze subpagina is opgezet als een puur informatieve, statische HTML-pagina. Er worden geen trackers, geen analysetools en geen toestemmingsplichtige cookies ingezet.
Statische pagina. Slanke structuur. Geen onnodige ballast.