Home   2026-10-22 19:56:51

←

Claude Code krijgt ondersteuning voor instructiebestand Agents.md

Original article

Claude Code ondersteunt vanaf versie 2.1.277 Agents.md van OpenAI. Daarin staan instructies voor bijvoorbeeld verwacht gedrag en voorkeurstools. De ondersteuning voor Agents.md maakt het voor ontwikkelaars gemakkelijker om met AI-programmeeragents van verschillende platformen te werken.

"Als er geen Claude.md in een map staat, zoekt Claude naar Agents.md en gebruikt dat bestand", zegt Claude Code-engineer Thariq Shihipar op X. Gebruikers kunnen dit gedrag zelf aan- en uitzetten via /config.

AI-programmeertools als Claude Code lezen bij ieder verzoek dat ze krijgen een instructiebestand. Daarin kunnen ontwikkelaars instructies in Markdown zetten voor hun AI-agents. OpenAI maakte daarvoor enige tijd geleden al Agents.md. Vorig jaar werd het bestand ondergebracht bij de Agentic AI Foundation, die onder de Linux Foundation valt. Agents.md is niet gebonden aan één specifieke tool en veel andere platformen gebruiken dit ook.

Claude Code gebruikte tot nu toe alleen zijn eigen variant: Claude.md. Ontwikkelaars die werken met zowel Claude Code als een andere AI-agent, moesten dus twee instructiebestanden onderhouden. Claude.md is namelijk gebonden aan alleen Claude zelf.

Er bestonden wel workarounds om gemakkelijker om te gaan met beide Markdown-bestanden, zegt The Register. Denk aan symlinks maken om Claude.md en Agents.md te synchroniseren. Dergelijke oplossingen zijn nu dus niet meer nodig.

Claude Code
Claude Code

Door Eveline Meijer

Nieuwsredacteur

Feedback • 21-09-2026 13:30
87 • submitter: NdotGdot

21-09-2026 • 13:30

87

Submitter: NdotGdot

Reacties (87)

Ff context. De goeie manier was vroeger om de volgende inhoud te hebben in je CLAUDE.md bestand:
@AGENTS.md
En je AGENTS.md file bevatte dan de context van het project ( dit kon ook in je home directory zijn in de .claude map).

Zodoende ging CLAUDE je CLAUDE.md inlezen terwijl het in de achtergrond AGENTS.md laadt.

Dit is niet meer nodig, dus je kan gewoon CLAUDE.md wissen.
Dat is niet waterdicht, je gaat er vanuit dat de agent ook die link volgt. Een agent zal niet automatisch alle links volgens maar alleen als AI vindt dat dat nodig is.
Nouja er zit wel een verschil tussen alle links volgen in een file die van zichzelf al een hoop instructies bevat en een file die letterlijk alleen dat heeft. Ik heb eigenlijk nog nooit gezien dat een systeem het anders doet.

Sterker nog, ik werk met Codex Soul.md en zelfs die krijg ik eigenlijk bijna altijd door m'n strot geduwd door Claude terwijl dit eigenlijk juist weer niet de bedoeling is (want specifiek juist op Codex gericht).

maar de kanttekening is wel de moeite waard. Het is inderdaad niet waterdicht. Wat CLAUDE.md en AGENTS.md sws niet zijn.
Nee. Claude Code ondersteunt dit om automatisch in te lezen. Een soort van symlink.

Kun je gewoon controleren in de code op GitHub fyi.

[Reactie gewijzigd door NicoJuicy op 22 september 2026 15:04]

Toevallig afgelopen maand nog mee zitten klooien en was behoorlijk geïrriteerd over het feit dat dat nodig was.

Ik wil geen platform afhankelijke meuk in de root folder van mijn project.
EDIT: Sorry bij verkeerde persoon op reply geklikt

[Reactie gewijzigd door satoer op 21 september 2026 18:08]

Owke, ik vind dit heel interessant. Maar kan iemand voor mij een kleine use-case geven waarvoor dit nuttig is? Ik snap het niet helemaal.
Je kunt in je claude.md instructies geven die je anders bij elke prompt zou moeten doorgeven, zoals regels voor naamgeving, tests etc. Over het algemeen werken die instructies bij elke LLM (het is immers geschreven tekst), maar tot nu toe werkte alle andere llms met een bestand genaamd 'agents.md' terwijl claude naar 'claude.md' zocht.

Helemaal op het moment komen er zo'n beetje elke maand nieuwe modellen uit, waarvan de ene soms net even wat beter werkt dan de andere, dus het is niet ongebruikelijk om meerdere modellen door elkaar heen te gebruiken

[Reactie gewijzigd door blabla1234 op 21 september 2026 14:24]

Dus de enorme lastenverlichting voor ontwikkelaars/prompters is dus eigenlijk dat ze niet langer cp agents.md claude.md hoeven doen?
Dit is een voorbeeld van mijn AGENTS.md (https://github.com/DevSysEngineer/puppet-modules/blob/main/AGENTS.md). Dit bestand komt uit een open-sourceproject van mij, waarbij ik samen met AI-agents het project verder ontwikkel en verbeter.

In AGENTS.md staan afspraken en instructies waar de AI-agents zich aan moeten houden. Dat kunnen hele kleine en logisch lijkende dingen zijn, maar ook uitgebreidere afspraken over bijvoorbeeld code style, documentatie, security en de manier waarop wijzigingen binnen het project moeten worden uitgevoerd.

Het doel is vooral dat een AI-agent niet iedere keer zelf hoeft te bedenken hoe iets binnen het project hoort, maar vooraf duidelijke kaders en afspraken meekrijgt.
Ja dat begrijp ik, maar het enige wat deze Claude update nou doet is kijken naar een andere bestandsnaam.
Dat klopt, en dat is om de compatibiliteit te vergroten. Lijkt me dus iets positiefs, aangezien het een simpele quality-of-life feature is, waardoor het out of the box dus standaard werkt tussen de agent harnesses.
Ja maar dit wordt gepresenteerd als een absolute time-saver voor gebruikers terwijl het eigenlijk echt minimaal is. Copy, symlink, whatever voldeed al.
Nee, echt wel een tokensaver in claude. Met de @import werd het gehele bestand bij elke prompt meegestuurd.

Nu dus niet meer. Let wel op dat sub folders met agents.md niet correct werken in bijv. een monorepo (onafhankelijk van de instelling: claude_or_agents / claude_and_agents). De enige manier om dat werkend te krijgen is door in de agents.md in de root te verwijzen naar de subfolder agents.md met als opmerking ‘leed dit alleen als je in die map zit’.
Nope, met de @import werd het gehele bestand bij elke prompt meegestuurd.

Nu dus niet meer, nu leeft het wel in het geheugen maar buiten de context van elke prompt. Let wel op dat sub folders met agents.md niet correct werken in bijv. een monorepo (onafhankelijk van de instelling: claude_or_agents / claude_and_agents). De enige manier om dat werkend te krijgen is door in de agents.md in de root te verwijzen naar de subfolder agents.md met als opmerking ‘leed dit alleen als je in die map zit’.
Sorry maar dit is echt een heel slecht voorbeeld. Je AGENTS.md file is 10.000+ tokens en 582 regels! (bron). Dat wordt constant meegestuurd. En dat is nog exclusief de includes naar DOCUMENTATION_RULES.md (20.000+ tokens!) en OPERATIONAL_RULES.md (50.000+ tokens!).

Dus elke context is minimaal 10.000 tokens en maximaal 80.000 tokens. :'(

Ter info, Claude raad zelf aan onder kopje "Write effective instructions" dat de file niet langer dan 200 regels moet zijn:
Size: target under 200 lines per CLAUDE.md file. Longer files consume more context and reduce adherence
Nee, die 10000+ tokens gebruikt hij NU sinds de fix alleen als hij het nodig heeft. Met de @import werd het gehele bestand inderdaad bij elke prompt meegestuurd.

Nu dus niet meer. Let wel op dat sub folders met agents.md niet correct werken in bijv. een monorepo (onafhankelijk van de instelling: claude_or_agents / claude_and_agents). De enige manier om dat werkend te krijgen is door in de agents.md in de root te verwijzen naar de subfolder agents.md met als opmerking ‘lees dit alleen als je in die map zit’.
Dus mijn volledige statement klopt dan toch? Nogmaals, ik schreef:
Dus elke context is minimaal 10.000 tokens en maximaal 80.000 tokens
De AGENTS.md file is te groot. Zelfs zonder @import.
Wij werken in ons team met zowel Claude als Codex. Voorheen moesten we dus een Agents.md en Claude.md bestand hebben (waarbij wij dus maar in de een verwijzen naar de ander). Dit is nu dus niet meer nodig.
Ahhh. dit is het context bestand van Claude of ChatGPT? Als je deze dus beide bijhoud hebben beide dezelfde context?

Dat is handig want ik gebruik dus ook beide voor het coderen.

Zit ik dan op de goede gedachte?
In de agents.md zet je bijv. neer dat de agent niet zomaar mag pushen, alleen commiten en dat je geen oude frameworks wilt gebruiken in dit project etc. De werkafspraken zeg maar.
Je zet er alleen de absoluut noodzakelijke regels in. Hoe minder hoe beter.
Als je er geen hebt ben je 100% viber.
Agents.md is een instructiebriefje voor een AI assistent die aan een project werkt. Het is een gewoon tekstbestand in de projectmap, met afspraken over hoe de AI moet werken.

Vergelijk het met een overdrachtsbriefje voor een nieuwe collega: dit is ons project, zo werken we hier en hier moet je op letten.
is het niet handiger om een symlink te maken? Dan is het gewoon 1 bestand.
At-files worden, volgens Claude zelf, niet daadwerkelijk in-place expanded geladen. Het zijn geen 'compile time includes' - maar zijn context gebonden runtime pointers die geladen worden zodra ze tegengekomen worden. En als je Claude raadpleegt vanuit een context die geen disk access geeft, zoals inline prompts in VS 2026, dan kan deze de Agents.md link kennelijk niet volgen wanneer het file ingeladen wordt en vang je bot.

Werkt verder voor bijv. een Claude Code CLI sessie idd perfect.

[Reactie gewijzigd door R4gnax op 21 september 2026 19:17]

claude gebruiken vanuit een systeem wat geen disk access heeft zou verder ook helemaal niks moeten inladen. ook geen AGENTS.md. CLAUDE.md moet je met dergelijke systemen ook helemaal syncen en dat is echt irritant.
zoals inline prompts in VS 2026
Ik raad iedereen sterk af om dat te gebruiken. Mijn directe collega gebruikt het veel, maar als ik zie hoe ver je dan achterloopt op features van Claude Desktop en het gebruiken van andere zaken, voor mij echt totaal niet interessant.

/Workflows werkt niet, kun je dus helemaal niet zien of dat allemaal goed gaat. Komt nog eens bij dat VS code een soort single threaded processes afdwingt met de plugin. Dus waar ik heel wat sessies kan laten starten vanuit 1 sessie (dus afzonderlijk in de gaten te houden, maar wel georchestreerd) schijnt de VScode variant dat niet te kunnen. Voor alleen een simpele werkwijze prima, maar ik ga het daar niet mee redden.
Zou Claude dat (voorheen dus, toen dat nog nodig was) misschien "hard-coded" hebben dat hij direct agents.md inleest en gebruikt in de systeemprompt? (I.p.v. dat een LLM zelf moet bedenken dat hij bij het lezen van @agents.md dat bestand in moet lezen?)
Aparte bestanden of in de ene verwijzen naar de andere is in ieder geval expliciet en voor sommigen beter "zichtbaar" dan een symbolic link. Zeker op Windows zijn die niet persé gemeengoed
Ik begrijp wat je zegt, maar dat is voor mij hetzelfde als geen sneltoetsen te gebruiken omdat je ze niet kent.
Symlink werkt niet in een Intune V2 (EPM) omgeving. Wat veel corporates nu inregelen om NIS2 compliant te zijn.
De conclusie dat CLAUDE.md overbodig is door de native ondersteuning voor AGENTS.md klopt niet helemaal, omdat beide bestanden een ander doel dienen. AGENTS.md bevat de universele code- en procesregels voor alle AI-tools in het team, terwijl CLAUDE.md specifiek de terminalomgeving van de Claude CLI-tool aansturt. Zonder CLAUDE.md verlies je de directe integratie met je lokale ontwikkelaarsomgeving.

Het belangrijkste verschil zit in de praktische uitvoering van taken. In CLAUDE.md definieer je de exacte terminalcommando's voor het bouwen, linten en testen van de codebase. De open AGENTS.md-standaard ondersteunt deze toolspecifieke terminalacties niet. Daarnaast activeer en configureer je via CLAUDE.mdaangepaste slash-commands in de CLI. Ook gebruikt Claude dit bestand als landingsplaats voor het automatische geheugensysteem om projectspecifieke lessen op te slaan, zonder de universele opzet van AGENTS.md voor andere tools zoals Codex te verstoren.

Het loont om beide bestanden te behouden door de taken te scheiden. Alle inhoudelijke richtlijnen, security-baselines en mappenstructuren blijven in de grote AGENTS.md staan als centrale bron voor elke AI-agent. Daarnaast gebruik je een minimale CLAUDE.md die uitsluitend de lokale scripts aanroept en via een importregel naar AGENTS.md verwijst. Door de recente update indexeert Claude dat grote bestand efficiënt op de achtergrond, waardoor de tokens niet meer bij elke prompt worden meegestuurd.
Claude die elke keer dat hij een package wil installeren npm ipv pnpm gebruikt.
Een regel in de agend.md en dan gaat het goed.
Dat is juist iets wat je samen met andere regels inzake package management in een skill wilt zetten.
Als je het in claude.md of agents.md zet zal dat altijd in elke sessie context ingeladen worden, terwijl je het lang niet altijd nodig hebt.
Nou, je hebt allemaal 'wrappers' om LLMs heen op het internet. Bijvoorbeeld copilot of litellm. In een git repo wil je zo min mogelijk files en zo makkelijk mogelijk agents wisselen
CLAUDE.md is een instructiebestand dat Claude Code automatisch leest bij het starten in een project. Je zet er projectcontext in: build-commando's, codeconventies, architectuur, wat wel en niet mag. Zo hoef je dat niet elke sessie opnieuw uit te leggen.

AGENTS.md is het tool-onafhankelijke equivalent: een open standaard die door meerdere AI-codeertools (Codex, Cursor, Copilot, Kimi code en anderen) wordt gelezen. Zelfde doel, dezelfde soort inhoud, maar niet gebonden aan één leverancier.

Waar dit echt belangrijk gaat worden is als je met harnas engineering aan de gang gaat. De harnas beschrijvingen (wat wel en niet mag, hoe iets wel en niet mag en welke tools er beschikbaar zijn) zorgen ervoor dat iedere agent altijd start met een fatsoenlijke context die niet afhankelijk is van de gebruiker zelf. Het nadeel is alleen dat het suggesties blijven. Deze zaken worden nooit hard afgedwongen, maar zijn dus een instructie om een soort gedeelde basis mee te beginnen. Handig voor "gebruik geen any in TypeScript" of "run eerst de tests", maar het is geen afdwinging. De daadwerkelijke harde instructies (permissions, hooks, tools) staan daadwerkelijk een laag dieper in .claude/settings.json. Bij codex kun je zelfs nog een Soul.md gebruiken waar je dit echt in zet en dat wordt dan zwaarder meegenomen in de beslissingen. Zelfs operator override wordt dan veel vaker geweigerd.

Nog steeds is het niet per se deterministisch, maar je kunt er heel ver mee komen om meer zaken in code te beleggen die als tooling ter beschikking komen, waardoor het wel deterministisch is. Ik gebruik het onder andere voor cost en time rolups en comments plaatsen op tickets met een specifiek format.
Als je een project hebt waaraan verschillende ontwikkelaars werken met verschillende AI tools, hoef je niet voor elke AI-boer afzonderlijk een soort AI-readme in de hoofdmap van je project te zetten.

Je kunt gewoon één agents.md gebruiken met instructies voor alle AI tools van alle leveranciers.
Hehe, dat duurde even. Niet dat het heel lastig was om gewoon agents.md in je claude.md te refereren, maar fijn dat dat niet meer hoeft.
dat is ook precies wat ik doe! sneller dan dat Claude hem toevallig tegen moet komen bij een repo scan.
Het gebruik maken van een harness adapter files is makkelijker te verspreiden via source code etc.
Je ziet wel dat het biljoenen-bedrijven zijn, heh :+
Even een vraag, ik gebruik nu bij claud zelf skills, bijvoorbeeld /java-code, /java-review etc.. waarin een algemene beschrijving staat en referencies naar belangrijke reference files zoals java-code-conventions.md die dan door verschillende andere reference files of skills gebruikt worden.

Ik vindt dit persoonlijk handiger om meer controle te hebben over de initiele context bij een vraag.

Want niet alles in een /java-review hoeft terug te komen in /java-code en andersom.

Hoe doen andere dit?
Wij hebben in onze globale .claude folder een CLAUDE.md met daarin de basics over onze omgevingen (ik doe vooral cloudops, dus onze account mapping steekt er bv in). Die file houden we bewust relatief klein om de token overhead beperkt te houden.

Voor terraform, ansible, ... hebben we dan aparte skills. En nog wat aparte skills om bv `tofu apply` met Haiku te runnen ipv wat we dan net gebruiken van model.

Een CLAUDE.md file binnen een repo is vaak niet nodig bij ons, maar kan de voor dat project specifieke documentatie of gotcha's/regeltjes bevatten.

//edit: kort samengevat. Claude.md in een project folder is eigenlijk de readme.md die niemand ooit schreef.

[Reactie gewijzigd door Hardfreak op 21 september 2026 14:42]

Combinatie van skills en rules en inderdaad volgens hetzelfde stramien. Allemaal om zoveel mogelijk informatie uit de initiële context weg te houden en pas erbij te pakken wanneer het nodig wordt.
Volgens onderzoek is AGENTS.md blijkbaar toch niet echt nuttig: https://arxiv.org/pdf/2602.11988
Ik snap het echt niet. Je wilt toch juist duidelijke richtlijnen aan je project koppelen? Ik merk zelf dat zo'n agent veel sneller zijn weg vindt als ik er meteen een goede samenvatting van het project ingooi. Gewoon waar de bestanden staan, wat ze doen en ga zo maar door.

Maar minstens zo belangrijk is wat hij absoluut niet mag doen. Denk aan het vermijden van specifieke JavaScript code die niet compatibel is met iOS 12 of Safari 12 (als dat belangrijk is voor je project). Misschien ben je tegen problemen aangelopen met bepaalde timers en mag hij die simpelweg niet meer aanraken. Of je hebt al flink geoptimaliseerd en je wilt voorkomen dat hij dat allemaal weer om zeep helpt omdat hij voor de makkelijkste weg kiest. Bijvoorbeeld door domweg een hele lijst instellingen te refreshen in plaats van heel gericht alleen de aangepaste data bij te werken.

Het zijn zomaar wat voorbeelden waar ik zelf tegenaan ben gelopen en die de agent nu keurig links laat liggen, puur omdat het helder in de onboarding instructies staat.
Niet in mijn ervaring. Agents raken super in de war van mijn structuur met git submodules. Sinds ik dat uitleg in Agents.md zijn ze niet eerst minuten bezig om dat uit te zoeken.

Overigens is dat onderzoek inmiddels wat verouderd. Het gaat erg rap met nieuwe modellen dus resultaten van GPT 5.2 zijn waarschijnlijk niet echt meer relevant.

[Reactie gewijzigd door Wolfos op 21 september 2026 19:07]

Alleen de abstract gelezen, maar daar geven ze toch ook aan dat niet-standaard instructies wel nut kan hebben (vrij vertaald). Het meeste wat ik in een Claude.MD zet valt daar toch wel onder.
Maar je kon toch gewoon zeggen 'gebruik Agents.md'? ik heb mijn lokale 8b al lange tijd via md's werkend.
Ja, ik doe dat ook lokaal regelmatig. Of in plaats van "skills" gewoon zeggen "als je naar git pushed lees ff git.md"
Doe je alles in het Nederlands?

In het begin viel het altijd wat tegen als je geen Engels gebruikte (ivm minder trainingsmateriaal) en ik werk toch altijd in het Engels dus dat ben ik blijven doen. Maar ik had er niet aan gedacht dat het ook in het Nederlands kan nu. De modellen zijn zoveel beter dan in de begintijd.
Oh, nee, alles in het engels. Nederlands kan wel, maar van wat ik zo zag zijn models gewoon aantoonbaar slechter in het nederlands. Weet niet of dat nog zo is, maar lijkt me wel logisch, veel minder trainingsdata, tenzij ze misschien alles automatisch vertalen voor training ofzo, maar dat lijkt me niet.
Mijn ervaring is dat ze op de achtergrond vooral in het engels werken en denken, en dan hun uitvoer gewoon naar het nederlands 'vertalen'
Ik heb nu een project wat ik ooit in het nederlands begonnen ben als een simpel scriptje wat een beetje uit de hand gelopen is, het werkt eigenlijk prima in het nederlands. Wel soms wat opmerkelijke woorden die je letterlijk vertaald nooit tegenkomt, zoals 'werkboom', 'bouw' (in plaats van build).
En soms vallen namen van engelse concepten opeens op hun plaats doordat je ze in het nederlands leest en gaat nadenken 'wat bedoelt ie nou'. Denk bijvoorbeeld aan 'gate'.
Dat woord heb ik in development-context altijd gelezen met de betekenis zoals ik het in die context had geleerd, maar nu lees je 'poort' en valt de associatie op zijn plek... niet heel spannend, maar wel grappig.
Ah ja dat is precies wat ik dus in het begin ook had. Rare woorden bedenken en als hij echt moeilijke dingen ging doen dan ging hij vanzelf over op Engels.

Maar ik woon al jaren in diverse buitenlanden dus ik spreek sowieso weinig Nederlands meer. En het is een paar jaar geleden dat ik het geprobeerd heb.

[Reactie gewijzigd door Llopigat op 21 september 2026 15:23]

Ik werk al maanden compleet in het Nederlands met een complexe codebase. Is geen probleem.
Interessant, bedankt! Ik was er benieuwd naar.
Doe je alles in het Nederlands?
Ja, want ik merk met mijn Nederlandstalige projecten dat ie mogelijk dingen verkeert interpreteert doordat een stuk jargon mogelijk in het engels weer iets anders betekent. Ook meervoud van Nederlandstalige woorden in het engels wordt een puinhoop.

Als je een engels project hebt, dikke prima, maar als er ergens Nederlandstalige domeinkennis om de hoek komt kijken (wat bij overheid eigenlijk altijd is) dan ga je hel snel nat. Zeker met alle DLA's en VLA's die er voorbijkomen.
Officieel ondersteunt Claude(in tegenstelling tot andere LLM's) ook geen Nederlands. Maar als je hem testen laat genereren in een multilanguage project(waar dus ook invoer in Nederlands, Frans, Engels, Duits) getest moet worden, maakt ie gewoon wel testen aan met correcte vertalingen. En hij merkt ook spellings- & grammaticafouten op in bestaande code.

[Reactie gewijzigd door Stroper op 22 september 2026 11:30]

Je hebt maar 25kB aan memory index voor Claude Code en alles wat daar bovenuit komt, laat Claude Code stilzwijgend vallen. Dus alles via memories doen is de domst mogelijke manier om Claude op project-basis dingen te leren.

Gebruik bij voorkeur skills met een bondige trigger phrase en description om Claude te leren hoe iets te doen; en rules met de juiste glob file-context om Claude te leren wanneer iets te doen.

[Reactie gewijzigd door R4gnax op 21 september 2026 19:02]

Oh grappig, ik lees het nu net even. Ik gebruik claude (code) niet zelf, maar lokaal qwen met 200k context, en ik werkte eigenlijk al handmatig op een soortgelijke manier. Hij moet de readme.md van elke module up to date houden met wat we daar doen en waarom, dan heb ik een architecture.md met high level alle modules (zelfde idee), een vision.md met de project filosofie, en een todo.md voor design brainstorm. Als ik dan iets nieuws ontwerp leest hij eerst de relevante mds, hebben we een discussie, stel ik vragen, pas ik dingen aan (challenge over en weer) en als dat redelijk lijkt zeg ik eerst, vat deze discussie samen met de designs, acties, rationale en open punten en voeg die toe aan todo.md. Daarna mag hij implementeren, en ook als ik daar dingetjes tegenkom die niet lekker gingen zeg ik dat hij items aan ofwel todo.md voor desig of aan agents.md toe moet voegen. Agents.md heeft dingen als code standards, perfomance en test standards, checklists, het process boven uitgelegd, hoe hij subagents mag draaien, etc.

Een keer in de zoveel tijd vraag ik hem ook die files te inspecteren en op inconsistencies te scannen en eventueel wat te herschrijven.

Ik geloof dat ik nu zon 100 A4tjes mds heb, een geweldige project documentatie ook, tijdens het bouwen alle redenen en keuzes vastgelegd op hoger niveau dan de code zelf. En ik type geen regel zelf :+

[Reactie gewijzigd door Zoijar op 21 september 2026 20:27]

Mag ik vragen wat je op 8b draait? Ik heb zelf eens wat geprobeerd met de kleine modellen maar vond voor mijn usecase dat het eigenlijk gewoon niet goed genoeg was.
Niet degene die je het vraagt maar de laatste 8/9b modellen zijn behoorlijk capabel, zeker als je ze ook de tooling geeft om informatie op te zoeken via Web, RAG of MCP. Daarmee verplaats je de kennislast van het model naar de databronnen die hij gebruikt.

En dat is ook handiger, want op die manier heb je zowel een referentie die je kan checken, alsook up to date informatie wat je niet hebt als het in het model ingebakken zit. En met ingebakken kennis is het lastig na te gaan of hij niet aan het hallucineren is. Bovendien, in mijn geval gaat het vaak om dingen die persoonlijk zijn. En die gaan natuurlijk niet in de trainingset van een cloud model zitten. Dat is juist de kracht van een lokaal model, je kan er dingen in stoppen die je niet per se in de cloud zou willen. Een vraag begrijpen, zoeken naar antwoorden in bronmateriaal en het antwoord daaruit destilleren gaat een 8b model prima lukken. Vertalen en samenvatten ook. Dingetjes aanroepen om het huis te bedienen ook (dat kan zelfs met een 2b model). Je moet niet verwachten dat je een claude Opus equivalent hebt natuurlijk, maar eigenlijk is dat ook gewoon overkill voor de meeste dingen.

Alleen ingewikkelde taken als programmeren vallen tegen, maar qwen 27b schijnt daar ook best aardig in te zijn. Die heb ik nog niet draaiende, ik ben nog op zoek naar een goedkope 32GB kaart (een Instinct MI50 ofzo)

Wat ik nu doe is meerdere kaarten tegelijk draaien met verschillende modellen er op, die ik dan altijd in het VRAM laat zitten zodat ze supersnel opstarten.

[Reactie gewijzigd door Llopigat op 21 september 2026 15:21]

Zelf inderdaad ook "hopen" op meer vram.

Mag ik vragen welke modellen je ervaring mee hebt? Een van de nieuwere doe ik heb geprobeerd is ornith 1.5 9b en qwen (3.6 dacht ik)9b, maar had het idee dat ze constant over zichzelf vielen zeg maar. Eerlijk is eerlijk ik heb behalve wat hermes skills niet veel erom heen hangen, rag en mcp staan op de lijst, maar juist het feit dat de modellen zo tegenvallen met mijn setup in elk geval, zorgt ervoor dat ik daar nog geen energie ingestoken heb. Mocht je daar tips voor hebben, dan hoor ik dat ook graag.


Helaas heb ik maar een enkele 6950xt, de vorige kaart is niet de moeite van het starten waard voor ai taken, helaas.

[Reactie gewijzigd door Teun! op 21 september 2026 18:41]

Ja ik gebruik ook qwen 3.5 9b momenteel, ik ben er wel blij mee. En daarvoor llama 3.1 8b.

Maar wat bedoel je met over zichzelf heen vallen?

Ik heb hier twee kaarten in de server momenteel (een Nvidia en een AMD) maar er kan er nog eentje bij. Er kan er maar eentje op x16 maar dat is niet zo'n ramp want er gaat met LLM inferentie weinig over de PCI bus als je het binnen een enkele kaart houdt.
Misschien heb ik iets niet goed opgezet dat kan natuurlijk ook, maar ik heb regelmatig als ik een simpele taak wil laten doen met de terminal tool ofzo dat ie keer op keer verkeerde tools called of soms zelfs in een loop terecht komt.

Heb het daardoor ook nog niet echt voor nuttige taken in kunnen zetten, voor mij zit het nu op het niveau speelgoed (mijn implementatie dan, qua nuttigheid zeg maar).
Ohh ok daar gebruik ik het nooit voor. Ik vertrouw een LLM niet genoeg om het los te laten op mijn systeem. Ook die van claude enzo niet.

Maar voor IT dingen heb je inderdaad wat grotere modellen nodig. Qwen 27b en 35b (MoE) schijnen dat beter te kunnen. Maar op een 16gb kaart draaien die voor mijn zin niet goed genoeg.

Ik gebruik het meer voor research / web opzoeken, en als assistent om persoonlijke dingen aan te vragen. Zo kan het bijvoorbeeld WhatsApp groepen in de gaten houden waar ik zelf geen zin in heb om die bij te houden. Voor de recentste berichten heb ik dan MCP om het live op te vragen en de oude worden in markdown als knowledge gezet (RAG)

Ik laat wel claude scripts maken voor de lokale AI (zoals MCP tools en tools die data ophalen om in RAG te zetten). Dat maakt het ook deterministischer. En het privacy aspect speelt dan geen rol omdat hij alleen de tools maakt maar niet zelf met de data werkt.

Dan kan hij me waarschuwen van hee die en die heeft volgend weekend een verjaardag en dan kan ik followup vragen van is er een feest, wie komt er enz zonder dat ik de hele dag allerlei slap gelul bij moet houden 🤭

Dit soort dingen kan je ook met openclaud doen maar dat is veel minder deterministisch en efficiënt, die loopt continu rondjes te draaien.

[Reactie gewijzigd door Llopigat op 21 september 2026 20:53]

Gaan ze dan ook ~/.agents folder ondersteunen? Of is dat nog een stap te ver.
Hey Claude, add support for agents.md, same filecontent, different name.

There I fixed it :9
Pijnlijk (en dus opgelost) voor Windows-gebruikers. De rest van de wereld gebruikte gewoon een symbolic link.
Dat kan ook op Windows hoor.
Heeft het eigenlijk nog zin om te leren programmeren?
Zeker! Want want met AI programmeren zonder het zelf te kunnen is heel leuk voor hobby projecten. Maar als er geld in om gaat of als een project echt over een langere tijd onderhouden moet worden heb je echt nog wel menselijke sturing nodig. Anders eindig je met een project wat precies net niet doet wat het moet doen én wordt het vooral structureel een drama.
Dna ga ik komende vrijdag met de cursussen beginnen(stond overigens echt op de planning)
Mijn ervaring met door AI geprogrammeerde code is dat het al snel een onleesbare brei ellende wordt en als er problemen ontstaan het praktisch niet meer zelf op te lossen is (tenzij het echt iets heel basaals is) en je dan weer een AI tool in moet zetten om het te fixen.

Ik heb het idee dat er al veel mensen zijn die heel veel AI gebruiken om te programmeren en ik heb niet het idee dat het kwalitatief beter wordt. Het is wel sneller, dat wel.
Ja! Absoluut. Veel van deze modellen zijn nog met regelmaat te dom voor woorden en zal je moeten bijsturen. Daarnaast is de opgeleverde code controleren ook iets dat zeker nodig is.

En buiten dat alles: zelf dingen maken heeft nog steeds voldoening.
programmeurs zullen zeggen ja.

Ik als leek ben jaren aan kennis verwijderd van het resultaat wat een AI agent al voor je in elkaar kan toveren. in een middagje.

Kleine projecten: AI prima.


grote projecten: Experts/programmeurs nodig.
Dat je voor grote projecten experts/programmeurs nodig hebt is vooralsnog voornamelijk beperkt door tokens. Gooi er genoeg tokens tegenaan en de huidige frontier modellen kunnen enorm grote projecten opleveren. Je hebt nog wel iemand nodig die heel goed weet hoe hij de AI kan aan- en bijsturen maar code hoeft diegene niet meer te kloppen.
Dat heeft niet zo zeer met hoeveelheid tokens te maken als met context limiet.

[Reactie gewijzigd door R4gnax op 21 september 2026 19:25]

Je kunt ook gewoon slim gebruik maken van skills en agents.md. Ik laat mijn AI zoveel mogelijk ontwikkelzaken automatiseren om op termijn credits te besparen, geef de instructie om de Superpowers skills waar mogelijk in te zetten tenzij het echt niet nuttig is, laat basic taken automatisch consequent uitvoeren door het goedkoopste model, laat enkel een intensieve audit uitvoeren door het topmodel van de diff bij een nieuwe release en laat automatisch belangrijke dingen die later kunnen helpen documenteren in een Obsidian vault.
Leren programmeren is niet zozeer een bepaalde programmeertaal leren, het is ook een bepaalde logische denkwijze. En zeker dat laatste zal altijd nuttig zijn, al is het alleen al om je AI agent goed te kunnen instrueren.

Daarnaast denk ik ook dat het altijd wel nut heeft om 1 of 2 programmeertalen te kennen. Niet dat je ze perse compleet uit je hoofd moet kennen. Maar het is altijd handig om de output van AI te kunnen controleren, of zelf te debuggen, of zelf nog kleine wijzigingen te doen.
"En zeker dat laatste zal altijd nuttig zijn, al is het alleen al om je AI agent goed te kunnen instrueren."

Je kunt je afvragen of je dat uberhaupt leuk vind als werk natuurlijk. Wat je moet doen in een AI prompt gooien en gewoon files met door AI gegenereerde code lezen en kijken of het ongeveer klopt.

Beetje alsof je een schilder bent, door AI een schilderij laat maken en dan bekijken of je de kleuren en vormen wel goed vind.

Om te kunnen reageren moet je ingelogd zijn