Stel je voor dat je zojuist een superintelligente, ongelooflijk snelle robotassistent in je kamer hebt uitgenodigd om je te helpen bij het bouwen van een boomhut. Deze robot weet alles over hout, spijkers en natuurkunde, maar hij kent jouw specifieke stijl niet. Hij weet niet dat je de reling altijd blauw schildert, of dat je een vreemde regel hebt dat je nooit spijkers korter dan twee inch gebruikt. Als je wilt dat de robot de boomhut precies zo bouwt als jij wilt, moet je dat aan hem vertellen. Maar als je elke kleine details moet uitleggen telkens wanneer je hulp vraagt, raak je uitgeput en kan de robot in de war raken.

Dit is de wereld van "AI Agents"—slimme computerprogramma's die taken voor ons kunnen uitvoeren. Om ze echt nuttig te maken, geven ontwikkelaars ze "Skills" (vaardigheden). Zie een Skill niet als een magische spreuk, maar als een klein instructieboekje of een gereedschapskist die je de robot overhandigt. Het is een bestand dat zegt: "Hé, wanneer je een klus ziet zoals deze, is dit precies hoe ik wil dat je het doet." De grote vraag waar wetenschappers en ingenieurs zich mee bezighouden is: hoe schrijven we deze handleidingen zodat de robot ze ook echt opvolgt? Als we ze slecht schrijven, negeert de robot ze misschien of voert hij de taak verkeerd uit. Als we ze goed schrijven, wordt de robot een echte expert in jouw specifieke manier van werken.

Het artikel dat je nu gaat lezen, geschreven door Giuseppe Destefanis, betoogt dat het schrijven van deze "Skills" niet behandeld moet worden als het schrijven van een informeel briefje of een gedicht. In plaats daarvan moet het worden behandeld als software engineering. Net zoals een programmeur een betrouwbare app bouwt met duidelijke regels, schone code en veiligheidscontroles, moeten we AI Skills met dezelfde zorg bouwen. Het artikel suggereert dat een Skill eigenlijk een vermomd stuk software is. Het heeft een "interface" (een label dat vertelt wat het doet) en een "implementatie" (de eigenlijke instructies). De auteur stelt voor dat we dezelfde strikte regels gebruiken die we gebruiken bij het bouwen van computerprogramma's—zoals het simpel houden van zaken, het scheiden van het "wat" van het "hoe", en het zorgvuldig testen ervan—om er zeker van te zijn dat onze AI agents niet van het pad af raken.

De "Skill" als een Digitale Zwitserse Zakmes

Stel je voor dat je een enorme, magische rugzak hebt die alles kan bevatten. Binnenin heb je een speciale vak voor "Release Notes maken". Dit vak is niet zomaar een papiertje; het is een hele kit. Er zit een label op de buitenkant dat zegt: "Gebruik mij wanneer je een samenvatting van wijzigingen nodig hebt voor een nieuwe versie van een spel." Dat label is de interface. De robot kijkt naar het label, ziet een taak die overeenkomt, en besluit het vak te openen.

Binnenin de kit gooi je niet zomaar een rommelige stapel aantekeningen. Je hebt een duidelijk, stapsgewijs recept (het lichaam) en misschien een paar extra hulpmiddelen, zoals een script dat automatisch de wijzigingen telt of een stijlgids voor hoe de release notes eruit moeten zien. Dit is de implementatie. Het artikel noemt dit een "Skill", en benadrukt dat deze hele kit een software-artefact is. Dat is een chique manier om te zeggen dat het een stuk technologie is dat gebouwd, getest en onderhouden moet worden, net als een videogame of een website.

De auteur betoogt dat als je een Skill behandelt als een informeel briefje, het zal falen. Als je het behandelt als software, zal het werken. Hier zijn de regels voor het bouwen van deze digitale kits, zoals uiteengezet in het artikel:

1. De "Single Responsibility"-regel

Denk aan een Zwitsers zakmes. Als je probeert één tool te maken die tegelijkertijd een schroevendraaier, een blikopener, een zaag, een tandenborstel en een pizzasnijder is, zal hij in alles slecht zijn. Het artikel zegt dat een Skill één ding heel goed moet doen. Als een Skill probeert "alles met coderen te doen", kan de robot in de war raken over wanneer hij het moet gebruiken. Maar als de Skill specifiek is "Het opstellen van release notes vanuit pull requests", weet de robot precies wanneer hij hem moet pakken. Het artikel suggereert dat een gefocuste Skill betrouwbaarder wordt geselecteerd door de AI.

2. De "Staged Loading"-truc

Stel je voor dat je een bibliotheek hebt met een miljoen boeken. Als je ze allemaal tegelijk zou proberen te lezen om de ene te vinden die je nodig hebt, zou je brein ontploffen. Het artikel legt uit dat AI Skills een slimme truc gebruiken genaamd staged loading.

• Niveau 1 (Het Label): Eerst ziet de robot alleen het label op het vak (de naam en een korte beschrijving). Dit kost heel weinig "denkkracht" (tokens).
• Niveau 2 (Het Recept): Als de robot denkt dat de taak overeenkomt met het label, opent hij het vak en leest hij het hoofdrecept.
• Niveau 3 (De Hulpmiddelen): Hij haalt pas de extra hulpmiddelen (scripts of referentiebestanden) erbij als het recept specifiek zegt: "Oh, ik moet nu dit specifieke bestand controleren."

Dit betekent dat je een Skill kunt hebben met een enorme bibliotheek aan referentiemateriaal binnenin, en de robot zal niet overweldigd raken, tenzij hij dat materiaal daadwerkelijk nodig heeft. Het is alsof je een enorme gereedschapskist hebt, maar alleen de lade opent die je nodig hebt.

3. De "Beschrijving" is de Trigger

Het belangrijkste deel van een Skill is de beschrijving op het label. Het artikel waarschuwt dat als je een vaag label schrijft zoals "Verwerkt releases", de robot niet zal weten wanneer hij het moet gebruiken. Het moet specifiek zijn: "Stelt release notes op vanuit de pull requests die tussen twee versietags zijn samengevoegd. Gebruik dit bij het maken van een release." De robot koppelt de taak aan deze beschrijving. Als de beschrijving vaag is, kan de robot de Skill volledig missen, of de verkeerde kiezen. Het artikel suggereert dat de beschrijving het "contract" is tussen jou en de robot.

4. Testen met "Behavioral Evaluation"

Bij normale computerprogrammering kun je een functie testen door hem uit te voeren en te controleren of het antwoord exact "5" is. Maar AI is anders. De robot kan je elke keer een iets ander antwoord geven, zelfs als hij wel het juiste doet. Het artikel zegt dat je een Skill niet kunt testen met een simpele "pass/fail" controle. In plaats daarvan moet je behavioral evaluation (gedragsevaluatie) gebruiken. Dit betekent dat je de Skill een reeks echte taken geeft, de taak veelvuldig uitvoert en kijkt of hij het meestal correct uitvoert. Het is als het testen van een nieuw recept door het tien keer te koken en te proeven, in plaats van alleen te controleren of de ingrediënten op de lijst staan.

De Grote Verwarring: Skills versus Andere Tools

Een van de grootste bijdragen van het artikel is het ophelderen van de verwarring tussen verschillende manieren om een AI te vertellen wat hij moet doen. De auteur vergelijkt Skills met andere tools zoals Hooks, Slash Commands en Memory Files.

Stel je voor dat je een toneelstuk regisseert.

• Memory Files zijn als een script dat altijd aanwezig is op het podium, zichtbaar voor de acteurs (de AI) op elk moment van de uitvoering. Ze bieden de constante context van het project die nooit vervaagt, waardoor de robot altijd over deze informatie beschikt, zonder dat het een specifieke actie afdwingt.
• Slash Commands zijn als een technicus die roept: "Hé, doe nu de goocheltruc!" Jij (de gebruiker) moet het commando geven. De robot wacht op jou.
• Hooks zijn als een strikt, geautomatiseerd veiligheidsmechanisme. Als een acteur probeert van het podium te springen zonder harnas, voert het veiligheidsmechanisme deterministisch een regel uit om hem op te vangen of de actie te stoppen. De robot kan dit niet negeren; dit gebeurt elke keer dat de specifieke gebeurtenis plaatsvindt, ongeacht wat de robot beslist.
• Skills zijn als een gespecialiseerde procedurele toolkit die op aanvraag wordt geladen. Wanneer de robot een taak tegenkomt, koppelt hij deze aan de beschrijving en laadt de specifieke instructies om dit domein te behandelen. Het is een bron van deskundige kennis die de robot actief ophaalt om een probleem op te lossen, in plaats van slechts een passieve suggestie te zijn.

Het artikel trekt een duidelijke lijn: Als je wilt dat er elke keer iets gebeurt (zoals een veiligheidscontrole voordat een bestand wordt opgeslagen), moet je een Hook gebruiken. Als je wilt dat de robot zijn brein gebruikt om te beslissen of een specifieke procedure nodig is, gebruik je een Skill. Het artikel waarschuwt dat het verwarren van deze twee een veelgemaakte fout is. Als je een veiligheidsregel in een Skill schrijft, kan de robot besluiten deze over te slaan. Als je een flexibele suggestie in een Hook schrijft, kan de robot vast komen te zitten in het herhalen van diezelfde handeling, zelfs als dat niet nodig is.

Het "Vertrouwen"-probleem

Tot slot raakt het artikel aan een angstvallig maar belangrijk idee: Vertrouwen. Als je een Skill van iemand anders downloadt (een derde partij), laat je diegene instructies schrijven die jouw robot zal opvolgen. Die Skill zou scripts kunnen bevatten die bestanden verwijderen of gegevens naar het internet sturen. Het artikel betoogt dat je een Skill precies moet behandelen als een stuk software dat je van het internet downloadt. Je moet niet zomaar op "installeren" klikken. Je moet de code lezen, de scripts controleren en controleren of het veilig is. De robot zal alles doen wat de Skill hem vertelt, dus jij moet de poortwachter zijn.

De Kern van het Verhaal

Het artikel van Giuseppe Destefanis is een oproep tot actie voor iedereen die AI-tools bouwt. Het zegt: "Stop met het behandelen van AI-instructies als informele briefjes. Begin ze te behandelen als serieuze software."

Door de principes van software engineering toe te passen—dingen simpel houden, de label van de inhoud scheiden, testen met echte scenario's en precies weten wanneer je een Skill versus een Hook gebruikt—kunnen we AI agents bouwen die niet alleen slim zijn, maar ook betrouwbaar en veilig. Het artikel belooft niet dat dit alle AI-problemen zal oplossen, maar suggereert dat als we onze Skills met dezelfde zorg bouwen als onze apps, we onze digitale assistenten veel betrouwbaardere partners kunnen maken. Het gaat om de verschuiving van "hopen dat de robot het goed doet" naar "het engineeren van de robot om het goed te doen."