Ik had een werkende AI-skill voor engineeringtaken.
In het begin zag die eruit als een gewone instructie: rol, taak, antwoordformaat en een paar beperkingen. Dat was voldoende zolang de scenario’s kort waren: een stukje code bekijken, een plan voorstellen, een duidelijke fout analyseren.
Daarna kreeg de skill complexere taken.
Bijvoorbeeld: “bekijk deze PR vóór de merge.”
In zo’n korte zin zit veel verborgen werk. Je moet begrijpen wat er verandert, welke beperkingen er zijn, waar risico kan zitten, waarop de conclusie gebaseerd is, welke opmerkingen de wijziging echt blokkeren en welke opmerkingen alleen suggesties zijn.
Elke nieuwe fout voegde weer een regel toe aan de instructie.
De AI stelde te snel een wijziging voor — dus kwam er een eis bij om eerst de grens van de taak te bepalen.
De AI mengde belangrijke opmerkingen met smaakvoorkeuren — dus kwam er een regel bij om blockers, vragen en suggesties te scheiden.
De AI schreef zelfverzekerde conclusies zonder controle — dus kwam er een blok over evidence.
Het antwoord werd technisch correct, maar zwaar om te lezen — dus kwam er een redactionele regel bij.
Zo verandert een gewone prompt geleidelijk in een werkprotocol.
Op een bepaald moment zit het probleem niet meer alleen in de inhoud. Het probleem zit in de vorm zelf: één tekst probeert tegelijk het werk vast te houden van een inputanalist, ontwikkelaar, architect, risicocontroleur, QA-specialist en eindredacteur.
Voor mezelf noem ik deze structuur een skill-consilium: één AI-skill voor de gebruiker, maar daarbinnen meerdere duidelijk gescheiden verantwoordelijkheidsgebieden.
Wat ik bedoel met een AI-skill
Met AI-skill bedoel ik een stabiele instructie voor een terugkerend werkscenario.
Dat kan een skill voor Codex zijn, een aparte assistant, een system prompt, een set regels in een repository of een vergelijkbaar mechanisme. De naam van het instrument is secundair. De werkbetekenis is belangrijker: de gebruiker brengt steeds een taak van hetzelfde type, en de AI voert die uit volgens een verwacht patroon.
Voorbeelden van zulke scenario’s:
- een pull request reviewen;
- een bug analyseren;
- een veilig wijzigingsplan voorbereiden;
- een releasecheck uitvoeren;
- een handoff maken na een lange taak — dus de taakstatus overdragen aan een volgende persoon of een volgende AI-sessie;
- conceptdocumentatie omzetten naar een bruikbare versie.
Zolang het scenario eenvoudig is, werkt een korte instructie prima.
Maar een terugkerende engineeringtaak krijgt snel extra lagen. Je moet de input begrijpen, beperkingen vasthouden, risico’s zien, het resultaat controleren en een antwoord geven waarmee een mens echt verder kan.
Een skill-consilium ontstaat op het moment dat het nuttig wordt om binnen één skill verschillende soorten controle expliciet te benoemen.
Waarom een grote prompt begint te hinderen
Een grote prompt groeit vaak uit terechte reacties op fouten.
Het model haast zich om code te wijzigen — dus voegen we een regel toe: eerst de taak begrijpen.
Het model mist risico — dus voegen we een apart blok toe over data, toegangsrechten en compatibiliteit.
Het model schrijft een te algemene conclusie — dus voegen we de eis toe om aan te geven waarop die conclusie gebaseerd is.
Het model verliest de juiste toon — dus voegen we redactionele eisen toe.
Al deze regels zijn op zichzelf nuttig. De complexiteit begint wanneer ze allemaal in één algemene stroom liggen.
Het model moet tegelijk input lezen, actie plannen, architecturale gevolgen controleren, risico zoeken, nadenken over tests en het uiteindelijke antwoord schrijven.
Voor een kleine taak is dat acceptabel.
Voor een taak met meerdere lagen kan het antwoord netjes lijken, terwijl het controleproces verborgen blijft.
De gebruiker ziet alleen de eindtekst. Die moet zelf reconstrueren:
- welke feiten de AI betrouwbaar vond;
- waar de AI risico zag;
- waarom een opmerking blokkerend werd;
- waarop de conclusie gebaseerd is;
- wat een aanname bleef;
- of de wijziging geaccepteerd kan worden.
Zo’n antwoord kan prettig leesbaar zijn en toch zwak als engineeringinstrument.
Hoe het skill-consilium is opgebouwd
Van buiten blijft alles vertrouwd: de gebruiker spreekt met één AI-skill en krijgt één eindantwoord.
Van binnen gaat de taak door meerdere rollen.
| Rol binnen de skill | Waarvoor die verantwoordelijk is | Wanneer die het werk moet stoppen |
|---|---|---|
| Inputspecialist | Begrijpt wat is aangeleverd: diff, taakbeschrijving, logs, beperkingen, ontbrekende gegevens | Wanneer er te weinig context is voor een betrouwbare conclusie |
| Domeinspecialist | Kijkt naar de betekenis van de taak binnen het specifieke domein | Wanneer de oplossing wegdrijft van het oorspronkelijke probleem |
| Actiearchitect | Kiest de werkvolgorde en de kleinste veilige wijziging | Wanneer het plan een onduidelijk gebied raakt |
| Risicocontroleur | Zoekt naar data, toegangsrechten, compatibiliteit, onomkeerbare acties en onverwachte gevolgen | Wanneer er een risico is dat niet met tekst alleen gesloten kan worden |
| Kwaliteitscontroleur | Kijkt naar tests, reproductie, acceptatiecriteria en bewijs | Wanneer de conclusie niet verifieerbaar is |
| Eindredacteur | Bouwt het antwoord zo op dat een mens snel de beslissing en volgende stap begrijpt | Wanneer een technisch correct antwoord moeilijk toepasbaar is |
De namen kunnen per taaktype veranderen.
Bij code review liggen de accenten anders dan bij een bugfix. Bij documentatie weer anders.
Het belangrijkste is dat elke rol apart werk doet: een eigen type probleem vindt, een eigen beslissing neemt of een eigen controle toevoegt.
Voor de gebruiker heeft de interne structuur alleen zin wanneer die het resultaat beter maakt. Een skill-consilium behoudt één handig eindantwoord, maar voegt discipline toe: de input is geanalyseerd, het risico is benoemd, de controle is zichtbaar en het resultaat is bruikbaar.
Voorbeeld: pull request review
Neem een korte vraag: “bekijk deze PR.”
In een zwakke variant geeft AI een lijst opmerkingen terug:
- De naam van de variabele kan beter.
- Misschien is een test nodig.
- Controleer de afhandeling van toegangsrechten.
- De code kan leesbaarder.Formeel is er een review.
Praktisch worden cosmetiek, een mogelijke test, een risico rond toegangsrechten en een algemene opmerking over leesbaarheid door elkaar gegooid.
De auteur van de PR moet nog steeds zelf begrijpen wat de merge blokkeert, welke vraag verduidelijking vraagt en welke punten kunnen wachten.
In een skill-consilium loopt dezelfde vraag anders.
De inputspecialist controleert of er een taakbeschrijving, diff, tests en belangrijke beperkingen zijn.
De domeinspecialist kijkt of de wijziging het opgegeven probleem oplost.
De actiearchitect beoordeelt de schaal: is dit een lokale wijziging of een contractwijziging?
De risicocontroleur zoekt plekken waar een kleine wijziging invloed kan hebben op gebruikers, data, toegangsrechten of backwards compatibility.
De kwaliteitscontroleur kijkt waarop de conclusie steunt: een test, reproductie, handmatige controle of alleen redenering.
De redacteur zet het antwoord in een werkbaar formaat:
Blockers:
- Na een autorisatiefout geeft de code gecachte data terug. Daardoor kan de gebruiker een verouderde status zien of data waarvoor hij geen toegang meer heeft.
Vragen:
- Is er een test voor het scenario waarin autorisatie faalt?
Suggesties:
- Scheid fallbackgedrag voor technische fouten van fallbackgedrag bij geweigerde toegang.
Conclusie:
- De PR is nog niet klaar voor merge. Eerst moet geweigerde toegang expliciet worden afgehandeld en met een test worden bevestigd.De waarde zit in prioritering.
Een serieuze bevinding krijgt het juiste gewicht. Onzekerheid wordt expliciet benoemd. De mens begrijpt sneller wat de volgende stap is.
Voorbeeld: bugfix
Een andere veelvoorkomende vraag is: “hier is de fout, los hem op.”
Zo’n vraag duwt AI gemakkelijk richting direct zoeken naar een bestand en meteen een patch voorstellen.
Soms werkt dat.
In echte ontwikkeling begint een bugfix meestal eerder: je moet het symptoom begrijpen, de reproductie, de omgeving, de grenzen van de wijziging en de manier van controleren.
In de rolstructuur scheidt de inputspecialist feiten van aannames:
- wat er precies is gebeurd;
- waar de log staat;
- welke stappen het probleem reproduceren;
- welke versie van de omgeving gebruikt wordt;
- wat al gecontroleerd is.
De domeinspecialist zoekt het waarschijnlijke gebied van de oorzaak.
De actiearchitect stelt het kleinste pad voor: waar kijken, wat wijzigen en welke opties buiten deze wijziging blijven.
De risicocontroleur stelt de vervelende vragen:
- Raakt de wijziging data?
- Zijn er migraties nodig?
- Worden toegangsrechten geraakt?
- Verandert een publieke API?
- Raakt dit background jobs?
- Kan dit productierisico opleveren?
De kwaliteitscontroleur eist een controlescenario: een test, een commando, reproductie vóór en na, handmatige controle of een eerlijke notitie dat de controle nog beperkt is.
Het eindantwoord moet kort zijn, maar inhoudelijk:
- wat de oorzaak was;
- wat is gewijzigd;
- hoe het is gecontroleerd;
- welk risico overblijft.
Hier is vooral belangrijk dat de stappen behouden blijven die een ervaren ontwikkelaar meestal in zijn hoofd vasthoudt.
Wat er in de praktijk verandert
De eerste verandering: minder blinde vlekken
Een algemene assistant optimaliseert vaak voor het dichtstbijzijnde zichtbare doel.
Vraag om een review — en hij schrijft opmerkingen.
Vraag om een bugfix — en hij stelt een patch voor.
Vraag om een plan — en hij maakt een stappenlijst.
Een rolstructuur voegt vóór de actie een paar verplichte vragen toe:
- Wat is bekend?
- Wat is onduidelijk?
- Waar zit risico?
- Waarmee kan het resultaat worden gecontroleerd?
De tweede verandering: makkelijker verbeteren
Wanneer alles in één prompt staat, is het lastig te begrijpen wat precies kapotging.
Zijn de antwoorden te droog geworden?
Zijn controles verdwenen?
Zijn risico’s te zacht geformuleerd?
Is het model zelfverzekerd gaan handelen bij ontbrekende data?
Elke nieuwe wijziging in de algemene prompt kan onbedoeld aangrenzend gedrag raken.
Wanneer verantwoordelijkheidsgebieden gescheiden zijn, is de plaats van de fout sneller zichtbaar.
Als de skill onbevestigde feiten toevoegt, versterken we de inputanalyse en het werken met bronnen.
Als de skill risico mist, scherpen we de rol voor risicocontrole aan.
Als conclusies moeilijk toepasbaar zijn, passen we de opbouw van het eindantwoord aan.
Als een review verandert in een lange lijst van alles en nog wat, wijzigen we de prioritering van opmerkingen.
De derde verandering: geleidelijke groei
In het begin kan hij alleen een uitvoerder en een eenvoudig antwoordformaat bevatten.
Daarna verschijnt inputcontrole.
Daarna een aparte risicocontrole.
Daarna kwaliteit en bewijs.
Daarna een eindredacteur.
Nieuwe rollen verschijnen precies daar waar een terugkerende taak al een aparte verantwoordelijkheid vraagt.
Zo’n groei is begrijpelijker dan meteen proberen de perfecte prompt voor alle gevallen te schrijven.
Wanneer dit de moeite waard is
Deze aanpak loont waar een taak meerdere verantwoordelijkheidslagen heeft.
Goede kandidaten
- een beslissing vóór merge;
- een bug met een onduidelijke oorzaak;
- een wijziging in een publieke API;
- een releasecheck;
- een taak met gebruikersdata;
- een handoff na lang werk;
- review van materiaal dat extern gepubliceerd wordt.
Voor kleine taken is een rolstructuur overbodige ballast.
Een Git-commando herinneren, een compilerfout uitleggen, één zin aanpassen of een kort codevoorbeeld maken gaat meestal sneller met een gewone vraag.
Nog een risico: rollen om de rollen
Als elke “specialist” hetzelfde zegt, krijgt de gebruiker ruis.
Als het eindantwoord verandert in een lange bespreking, zit de skill in de weg.
Elke rol moet óf een apart type probleem vinden, óf een aparte werkbeslissing nemen.
Hoe je dit kunt proberen zonder apart instrument
Het eenvoudigste experiment kan direct in een chat.
Als je werkprompt al is veranderd in een muur van regels, probeer dan eerst één rol los te maken: inputcontrole of risicocontrole.
Neem een terugkerend scenario, bijvoorbeeld PR-review of buganalyse, en vraag AI om de taak per rol te doorlopen:
Analyseer de taak als een skill-consilium binnen één AI-skill:
1. Input: wat is bekend en wat ontbreekt.
2. Gedrag: wat verandert er voor het systeem of de gebruiker.
3. Risico’s: wat kan breken of voorzichtigheid vereisen.
4. Controle: waarmee kan de conclusie worden bevestigd.
5. Resultaat: blockers, vragen, suggesties, conclusie.Na een paar runs wordt zichtbaar waar AI het vaakst faalt.
Als het ontbrekende feiten verzint, is strengere inputanalyse nodig.
Als het een gladde conclusie schrijft zonder controle, is een kwaliteitsrol nodig.
Als het blokkerende bevindingen en nice-to-have suggesties mengt, is aparte prioritering nodig.
Als het antwoord moeilijk te lezen is, is een eindredacteur nodig.
Wanneer het scenario regelmatig terugkomt, kan deze structuur worden vastgelegd als een stabiele AI-skill.
Wat ik uit deze ervaring heb meegenomen
Het skill-consilium hielp mij stoppen met het eindeloos verzwaren van één prompt.
In plaats van steeds meer regels aan één algemene tekst toe te voegen, begon ik verantwoordelijkheid te scheiden:
- wie begrijpt de input;
- wie kijkt naar het domein;
- wie kiest de volgorde van handelen;
- wie zoekt risico;
- wie controleert kwaliteit;
- wie bouwt het antwoord op.
AI maakt nog steeds fouten.
De verantwoordelijkheid blijft bij de mens.
Maar de skill begint rustiger en begrijpelijker te werken: achter de zelfverzekerde tekst verschijnen zichtbare werkcontroles.
In softwareontwikkeling is dat extra belangrijk.
Een goed resultaat bestaat hier zelden uit één correct antwoord. De weg ernaartoe telt: wat als feit werd beschouwd, waar het risico zat, waarmee de conclusie werd bevestigd en welke beslissing de mens moet nemen.
Nuttige AI-skills voor engineeringwerk zullen zich volgens mij precies in deze richting ontwikkelen: weg van de hoop op één perfecte prompt, naar een duidelijke verdeling van verantwoordelijkheid binnen het instrument.
Ik ben benieuwd hoe jullie een vergelijkbaar probleem in jullie werk oplossen.
