<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="nl-BE">
  
  <title>Avonturen in AI-Land</title>
  <subtitle>Mijn blog over AI, (hoger) onderwijs en de combinatie daarvan.</subtitle>
  <link href="https://lars-derichter.github.io/feed.xml" rel="self" />
  <link href="https://lars-derichter.github.io/" />
  <updated>2026-09-04T00:00:00Z</updated>
  <id>https://lars-derichter.github.io/</id>
  <author>
    <name>Lars De Richter</name>
  </author>
  <entry>
    <title>De vraag die we niet durven stellen</title>
    <link href="https://lars-derichter.github.io/blog/de-vraag-die-we-niet-durven-stellen/" />
    <updated>2026-09-04T00:00:00Z</updated>
    <id>https://lars-derichter.github.io/blog/de-vraag-die-we-niet-durven-stellen/</id>
    <content type="html">&lt;p&gt;Het gesprek over AI in het hoger onderwijs zit vast op de verkeerde vraag.
“Mogen ze het gebruiken?” is een vraag over toelating, en die veronderstelt dat
we het antwoord kunnen afdwingen. Dat kunnen we niet, en iedereen die de
afgelopen twee jaar opdrachten verbeterd heeft, weet dat.&lt;/p&gt;
&lt;p&gt;De vraag die eronder ligt is ongemakkelijker: &lt;strong&gt;wat meet deze opdracht nog, nu
een taalmodel er in dertig seconden een aanvaardbare versie van maakt?&lt;/strong&gt;&lt;/p&gt;
&lt;h2 id=&quot;drie-soorten-opdrachten&quot; tabindex=&quot;-1&quot;&gt;&lt;a class=&quot;header-anchor&quot; href=&quot;https://lars-derichter.github.io/blog/de-vraag-die-we-niet-durven-stellen/#drie-soorten-opdrachten&quot;&gt;&lt;span&gt;Drie soorten opdrachten&lt;/span&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Als ik mijn eigen vakken erop nakijk, vallen mijn opdrachten uiteen in drie
groepen.&lt;/p&gt;
&lt;p&gt;De eerste groep is stukgegaan. Samenvattingen, definitieoefeningen, “leg in
eigen woorden uit”. Die maten of een student een tekst gelezen en verwerkt had.
Nu meten ze of een student een prompt kan typen. Daar is geen tussenweg en geen
slimme herformulering die dat repareert.&lt;/p&gt;
&lt;p&gt;De tweede groep is onaangeroerd. Alles wat gebeurt terwijl ik erbij ben:
mondelinge verdediging, een vraag tijdens het labo, een student die zijn eigen
code moet aanpassen op iets wat ik ter plaatse verzin. AI verandert daar niets
aan, want de tijd en de aanwezigheid zijn de meting.&lt;/p&gt;
&lt;p&gt;De derde groep is de interessante: opdrachten die beter worden als AI meespeelt,
op voorwaarde dat ik de opdracht herschrijf.&lt;/p&gt;
&lt;h2 id=&quot;wat-herschrijven-concreet-betekent&quot; tabindex=&quot;-1&quot;&gt;&lt;a class=&quot;header-anchor&quot; href=&quot;https://lars-derichter.github.io/blog/de-vraag-die-we-niet-durven-stellen/#wat-herschrijven-concreet-betekent&quot;&gt;&lt;span&gt;Wat “herschrijven” concreet betekent&lt;/span&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Een voorbeeld uit mijn eigen vak. De oude opdracht:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;Schrijf een functie die een lijst studenten sorteert op gemiddelde.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;Die is dood. De nieuwe:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;Laat een taalmodel deze functie schrijven. Lever in: de prompt die je
gebruikte, de code die je terugkreeg, minstens één fout of zwakte die je erin
vond, en je verbeterde versie met uitleg waarom.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;De tweede opdracht is moeilijker dan de eerste. Je kan ze niet maken zonder de
code te begrijpen, want je moet er iets aan mankeren zien. En de zwakke
inzendingen zijn meteen herkenbaar: wie niets vindt, heeft niet gekeken.&lt;/p&gt;
&lt;p&gt;Dit werkt niet overal. Het veronderstelt dat er iets te bekritiseren valt, en
bij een eenvoudige oefening is dat er niet. Maar het laat zien waar de meting
naartoe kan verschuiven: van het maken naar het beoordelen.&lt;/p&gt;
&lt;h2 id=&quot;wat-ik-nog-niet-weet&quot; tabindex=&quot;-1&quot;&gt;&lt;a class=&quot;header-anchor&quot; href=&quot;https://lars-derichter.github.io/blog/de-vraag-die-we-niet-durven-stellen/#wat-ik-nog-niet-weet&quot;&gt;&lt;span&gt;Wat ik nog niet weet&lt;/span&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Twee dingen houden me bezig en ik heb er geen antwoord op.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Bouwen studenten zo nog fundamenten op?&lt;/strong&gt; Kritiek geven op code
veronderstelt dat je ooit zelf code geschreven hebt. Als de eerste stap
wegvalt, waar komt die basis dan vandaan? Ik vermoed dat het antwoord
vakspecifiek is en dat we het per opleiding zullen moeten uitzoeken.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Wat doen we met wie geen toegang heeft?&lt;/strong&gt; De betere modellen kosten geld.
Een opdracht die AI veronderstelt, veronderstelt een abonnement. Dat is een
billijkheidsprobleem dat we tot nu toe grotendeels genegeerd hebben.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Ik heb geen sluitend kader. Wat ik wel heb, is een bruikbaardere vraag om mee
naar een opdracht te kijken dan of het mag.&lt;/p&gt;
</content>
  </entry>
  <entry>
    <title>Wat een deadline eigenlijk doet</title>
    <link href="https://lars-derichter.github.io/blog/wat-een-deadline-eigenlijk-doet/" />
    <updated>2026-08-28T00:00:00Z</updated>
    <id>https://lars-derichter.github.io/blog/wat-een-deadline-eigenlijk-doet/</id>
    <content type="html">&lt;p&gt;Elke lesgever kent het patroon. Je geeft een opdracht die vier weken loopt. Drie
en een halve week gebeurt er niets. Dan volgen twee nachten waarin het meeste
werk gebeurt, en je krijgt iets binnen dat af is maar niet doordacht.&lt;/p&gt;
&lt;p&gt;De gemakkelijke conclusie is dat studenten uitstellen. Dat klopt, maar het
verklaart niets: iedereen stelt uit. De interessantere vraag is waarom onze
opdrachten dat gedrag belonen.&lt;/p&gt;
&lt;h2 id=&quot;een-deadline-is-een-signaal&quot; tabindex=&quot;-1&quot;&gt;&lt;a class=&quot;header-anchor&quot; href=&quot;https://lars-derichter.github.io/blog/wat-een-deadline-eigenlijk-doet/#een-deadline-is-een-signaal&quot;&gt;&lt;span&gt;Een deadline is een signaal&lt;/span&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Studenten lezen een deadline niet als een datum. Ze lezen ze als een uitspraak
over hoeveel het werk waard is en wanneer het echt moet beginnen. Eén deadline
op het einde zegt: dit is één blok werk, en het begint wanneer je het niet
langer kan uitstellen.&lt;/p&gt;
&lt;p&gt;Dat is een rationele gevolgtrekking. Als de enige meting op het einde staat, is
werken op dag drie een investering zonder feedback.&lt;/p&gt;
&lt;h2 id=&quot;drie-kleine-ingrepen&quot; tabindex=&quot;-1&quot;&gt;&lt;a class=&quot;header-anchor&quot; href=&quot;https://lars-derichter.github.io/blog/wat-een-deadline-eigenlijk-doet/#drie-kleine-ingrepen&quot;&gt;&lt;span&gt;Drie kleine ingrepen&lt;/span&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Wat bij mij werkt, in volgorde van hoeveel moeite het kost:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;&lt;strong&gt;Splits de deadline, niet de opdracht.&lt;/strong&gt; Zelfde eindproduct, maar op een
tussenmoment lever je in wat je hebt. Geen punten, wel gelezen.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Maak het tussenmoment goedkoop om te halen en duur om te missen.&lt;/strong&gt; Vijf
regels over je aanpak volstaat. Wie niets inlevert, krijgt geen feedback, en
dat merk je op het einde.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Toon het verschil.&lt;/strong&gt; Laat na afloop twee anonieme trajecten zien: één met
en één zonder tussenmoment. Dat overtuigt meer dan mijn waarschuwing.&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;De eerste ingreep kostte me een half uur per vak. Het effect was groter dan
alles wat ik daarvoor aan mijn opdrachtomschrijvingen had zitten sleutelen.&lt;/p&gt;
&lt;h2 id=&quot;de-valkuil&quot; tabindex=&quot;-1&quot;&gt;&lt;a class=&quot;header-anchor&quot; href=&quot;https://lars-derichter.github.io/blog/wat-een-deadline-eigenlijk-doet/#de-valkuil&quot;&gt;&lt;span&gt;De valkuil&lt;/span&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Meer tussenmomenten is niet beter. Ik ben ooit doorgeslagen naar wekelijkse
deelinleveringen, en toen verdween iets anders: studenten stopten met de
opdracht als geheel te zien. Ze leverden zeven keer een stukje in en hadden op
het einde geen idee wat ze gemaakt hadden.&lt;/p&gt;
&lt;p&gt;Eén goed geplaatst tussenmoment doet het werk. Twee is meestal het maximum. Wat
je zoekt is niet controle, maar een aanleiding om vroeg te beginnen.&lt;/p&gt;
</content>
  </entry>
  <entry>
    <title>De black box in je broekzak</title>
    <link href="https://lars-derichter.github.io/blog/de-black-box-in-je-broekzak/" />
    <updated>2026-08-19T00:00:00Z</updated>
    <id>https://lars-derichter.github.io/blog/de-black-box-in-je-broekzak/</id>
    <content type="html">&lt;p&gt;Vraag een taalmodel om iets uit te leggen en je krijgt een vloeiend, geduldig en
zelfverzekerd antwoord. Vraag het naar iets wat niet bestaat en je krijgt
hetzelfde vloeiende, geduldige, zelfverzekerde antwoord. Het verschil zit niet
in de toon.&lt;/p&gt;
&lt;p&gt;Dat is geen randgeval of kinderziekte. Het is hoe het ding werkt.&lt;/p&gt;
&lt;h2 id=&quot;wat-er-onder-de-motorkap-gebeurt&quot; tabindex=&quot;-1&quot;&gt;&lt;a class=&quot;header-anchor&quot; href=&quot;https://lars-derichter.github.io/blog/de-black-box-in-je-broekzak/#wat-er-onder-de-motorkap-gebeurt&quot;&gt;&lt;span&gt;Wat er onder de motorkap gebeurt&lt;/span&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Een taalmodel schat, gegeven alles wat er tot nu toe staat, hoe waarschijnlijk
elk mogelijk volgend stukje tekst is. Daarna kiest het er een. En dan opnieuw.&lt;/p&gt;
&lt;pre class=&quot;language-python&quot;&gt;&lt;code class=&quot;language-python&quot;&gt;&lt;span class=&quot;token comment&quot;&gt;# Sterk vereenvoudigd, maar dit is de kern.&lt;/span&gt;
tokens &lt;span class=&quot;token operator&quot;&gt;=&lt;/span&gt; tokenize&lt;span class=&quot;token punctuation&quot;&gt;(&lt;/span&gt;&lt;span class=&quot;token string&quot;&gt;&quot;De hoofdstad van België is&quot;&lt;/span&gt;&lt;span class=&quot;token punctuation&quot;&gt;)&lt;/span&gt;
&lt;span class=&quot;token keyword&quot;&gt;while&lt;/span&gt; &lt;span class=&quot;token keyword&quot;&gt;not&lt;/span&gt; klaar&lt;span class=&quot;token punctuation&quot;&gt;(&lt;/span&gt;tokens&lt;span class=&quot;token punctuation&quot;&gt;)&lt;/span&gt;&lt;span class=&quot;token punctuation&quot;&gt;:&lt;/span&gt;
    kansen &lt;span class=&quot;token operator&quot;&gt;=&lt;/span&gt; model&lt;span class=&quot;token punctuation&quot;&gt;(&lt;/span&gt;tokens&lt;span class=&quot;token punctuation&quot;&gt;)&lt;/span&gt;          &lt;span class=&quot;token comment&quot;&gt;# kans per mogelijk vervolg&lt;/span&gt;
    volgende &lt;span class=&quot;token operator&quot;&gt;=&lt;/span&gt; kies&lt;span class=&quot;token punctuation&quot;&gt;(&lt;/span&gt;kansen&lt;span class=&quot;token punctuation&quot;&gt;,&lt;/span&gt; temp&lt;span class=&quot;token operator&quot;&gt;=&lt;/span&gt;&lt;span class=&quot;token number&quot;&gt;0.7&lt;/span&gt;&lt;span class=&quot;token punctuation&quot;&gt;)&lt;/span&gt;
    tokens&lt;span class=&quot;token punctuation&quot;&gt;.&lt;/span&gt;append&lt;span class=&quot;token punctuation&quot;&gt;(&lt;/span&gt;volgende&lt;span class=&quot;token punctuation&quot;&gt;)&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Nergens in die lus zit een stap waarin het model nagaat of wat het zegt klopt.
Er is geen aparte feitencontrole die het antwoord tegenhoudt. Vloeiendheid en
correctheid komen uit dezelfde beweging, dus ze voelen voor de lezer identiek
aan.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;Het model is niet aan het liegen. Liegen veronderstelt dat je de waarheid kent
en er van afwijkt.&lt;/p&gt;
&lt;p&gt;&lt;cite&gt;Iets wat ik te vaak moet herhalen&lt;/cite&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;h2 id=&quot;waarom-dat-lastiger-is-dan-het-klinkt&quot; tabindex=&quot;-1&quot;&gt;&lt;a class=&quot;header-anchor&quot; href=&quot;https://lars-derichter.github.io/blog/de-black-box-in-je-broekzak/#waarom-dat-lastiger-is-dan-het-klinkt&quot;&gt;&lt;span&gt;Waarom dat lastiger is dan het klinkt&lt;/span&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;We hebben geen gewoonte om zelfverzekerde, welgevormde taal te wantrouwen. Bij
een mens is vlot en gedetailleerd praten over een onderwerp een redelijk signaal
van kennis. Niet perfect, maar het correleert. Bij een taalmodel is die
correlatie doorgeknipt, en onze intuïtie is niet meegegaan.&lt;/p&gt;
&lt;p&gt;Concreet betekent dat drie dingen:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Het model weet niet wat het niet weet.&lt;/strong&gt; Er is geen interne meter die
uitslaat bij een gat in de kennis.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Zekerheid in de formulering zegt niets.&lt;/strong&gt; “Ongetwijfeld” en “mogelijk” zijn
stijlkeuzes, geen kansuitspraken.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Verifiëren kost meer moeite dan genereren.&lt;/strong&gt; Dat is de echte kost, en die
verschuift naar jou.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&quot;wat-ik-ermee-doe&quot; tabindex=&quot;-1&quot;&gt;&lt;a class=&quot;header-anchor&quot; href=&quot;https://lars-derichter.github.io/blog/de-black-box-in-je-broekzak/#wat-ik-ermee-doe&quot;&gt;&lt;span&gt;Wat ik ermee doe&lt;/span&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Ik gebruik taalmodellen elke dag. Voor dingen waar ik de uitkomst zelf kan
beoordelen: code die ik kan draaien, een tekst waarvan ik het onderwerp ken, een
structuur die ik kan omgooien. Daar zijn ze uitstekend.&lt;/p&gt;
&lt;p&gt;Voor dingen waar ik de uitkomst niet kan beoordelen, gebruik ik ze niet. Niet
omdat het verboden zou moeten zijn, maar omdat ik dan geen enkele manier heb om
te weten of ik iets goeds in handen heb.&lt;/p&gt;
&lt;p&gt;Dat onderscheid, tussen “ik kan dit nakijken” en “ik kan dit niet nakijken”, is
in mijn ervaring bruikbaarder dan elke lijst met regels.&lt;/p&gt;
</content>
  </entry>
</feed>