AI in het harnas

[tangentialdust]

Nu de nieuwste generaties modellen (GPT-6.1 en Claude 5.5) een tijdje beschikbaar zijn moet ik zeggen dat die (wmb) zeer sterk zijn, zeker qua programmeren. Hoewel ze nog steeds redelijk zwak zijn qua architectuur en ontwerp. Het loont dus om strategisch om te gaan met wat je aan een model vraagt en welke input je zelf geeft. Omdat een agent harnas een groot deel van die "upfront" context bepaalt lijken ze ook een belangrijker onderdeel van de programmeer stack te worden. Zie ook Terminal Bench die een model + het gebruikte harnas laat zien.

Ik ben zelf bijvoorbeeld al een tijd overgestapt op de pi agent omdat die model agnostisch is en de tools openbaar en inzichtelijk zijn. Sommige van mijn collega's zijn om die redenen ook overgestapt, terwijl anderen nog Copilot/Codex/Claude Code gebruiken. Ik zie nu ook dingen als ThinkRail ontstaan die het agent gebruik nog een stapje verder nemen.

Dus ik ben benieuwd wat de ervaringen van andere Tweakers zijn met agent harnassen en of jullie die keuze periodiek heroverwegen.

[dmantione]

Ik heb enige ervaring met Claude Code en vooral veel met Opencode en zet vooral in op Opencode: De Amerikanen willen je abonnementen aansmeren en zorgen dat je niet meer zonder denkt te kunnen. Ik zie Claude Code als het instrument daartoe.

Opencode is modelonafhankelijk, je wisselt van model met een druk op de knop en zo zie ik het graag. En Opencode werkt ook erg fijn.

Op zich moet ik mij ook in andere harnassen verdiepen, bijvoorbeeld het harnas van Deepseek is ook best interessant. Een programma goed leren vereist evenwel tijdinvestering en zó fanatiek gebruik ik KI nu ook weer niet.

[ZpAz]

Ik zie het als drie lagen die los van elkaar staan, maar wel samenwerken:

1. Het model. ChatGPT, Claude, DeepSeek enz., plus instellingen zoals het reasoning level.
2. De agent. Het systeem dat de loop draait, met of zonder UI: Codex, Claude Code, OpenCode, Pi, Omp, JetBrains Air (gebruik ik zelf nu). Ik wacht nog op Tern.
3. Je eigen harness. De skills, plugins, regels en tooling die je er zelf omheen bouwt.

Ik ben nog constant aan het wisselen en experimenteren op alle drie de lagen.

Mijn ervaring: met het standaardrecept (spec → uitvoeren → review → cleanup) krijg je op z'n best "redelijke slop". Features zijn vaak half af. En zodra je zegt dat iets niet werkt, gaat het model panic patchen: ergens een if erbij, test groen, klaar. Maar die test is vaak zelf niet correct. Groen zegt niet dat hij iets zinnigs test. Toch zitten die tests de code daarna wel lokaal vast, want een model past tests bijna nooit aan en verwijdert ze al helemaal niet, ook niet als dat nodig is (de AI complexity ratchet). Meer documentatie: ImpossibleBench meet hoe vaak modellen tests special-casen of aanpassen in plaats van het echte probleem op te lossen, en METR over reward hacking.

Daarom denk ik dat de guardrails echt in de codebase en de loop zelf moeten zitten, niet alleen in een AGENTS.md met "houd domain logic gescheiden van UI".

Statisch: afdwingen wat mag

• custom lint rules
• dependency-cruiser om af te dwingen wat waarvan mag afhangen
• Abide: decision models voor regels die eigenlijk over taste gaan:
  • geen comment die de regel eronder herhaalt
  • geen comment waar een rename volstaat
  • geen mixed concerns in één functie
• Knip tegen dode code, exports en dependencies die agents graag laten liggen
• etc

Runtime: zichtbaar maken wat er echt gebeurt

• interne state live exposen voor de agent: debug-endpoints, structured logs, traces (OpenTelemetry)
• tools die een agent direct in de draaiende app laten kijken, zoals Tidewave of Chrome DevTools MCP

Models have no taste.

Volgens mij is dít het nieuwe programmeren: continu een systeem bouwen en bijstellen, zodat de agent betere code schrijft. Een soort code factory. De tijd die je aan het product zelf besteedt, wordt steeds kleiner.

Op dit moment probeer ik een snel en redelijk slim model in de loop te hangen (DeepSeek v4.1 op LithosAI voor snelle inference). Dat moet panic patching herkennen en een frontier model bijvoorbeeld GPT of Claude dwingen een stap terug te doen naar het grotere plaatje, want daar zit meestal het echte probleem. Dan hoef ik zelf niet steeds bij te sturen. Want die grotere modellen vragen zichzelf nog steeds niet af tijdens het programmeren, moet ik een stap terug doen, ze gaan alleen maar full steam ahead tot alle vinkjes groen zijn.

Schema van wat ik nu probeer.

Dat proces is op zich al behoorlijk frustrerend. Zo'n loop slaat heel snel door naar één van twee kanten. Of hij gaat overcorrigeren: alles wordt constant opnieuw gecontroleerd en in twijfel getrokken, en er komt niks meer af. Of hij laat te veel door en je zit weer bij half werk. Het voelt als een potlood op z'n punt balanceren: een instabiel evenwicht dat je continu moet bijsturen.

Soms vraag ik me af of de meeste mensen en bedrijven (ook Anthropic e.d.) gewoon genoegen nemen met slop die net iets boven vibe coding uitkomt. Er lijkt in elk geval veel vaker code live te gaan met flink meer bugs dan vroeger (webman.tech). De data wijst dezelfde kant op:

• CodeRabbit: AI-PR's bevatten gemiddeld ~1,7× zoveel issues, met ~75% meer logic- en correctness-fouten.
• GitClear: refactoring daalde van ~24% naar ~10% van de wijzigingen, en er wordt nu meer code gedupliceerd dan verplaatst.
• DORA 2024: meer AI-adoptie hangt samen met lagere delivery stability.
• METR: ervaren devs waren met AI 19% trager, terwijl ze dachten dat ze sneller waren.

---

MAAR

Ik weet niet of ik het allemaal gewoon 'los moet laten'. Want iets maken wat redelijk 'alleen' goede code produceerd, zo frustrerend. Ik weet niet of ik programmeren nog leuk vind eigenlijk. Voorheen was het altijd dat het compleet deterministisch was. Hier zit er een dobbelsteen bij met random rewards en straffen voor mijn gevoel wat het een bordspel van geluk meer maakt dan van skill.

Ik voel me de rat in deze studie. Ik blijf de AI knop maar drukken omdat er soms heel snel iets goeds uitkomt. Maar heel vaak is het ook enkel frustratie. Vaak voelt het wel alsof er meer frustratie is dan iets goed.

---

<sub>Momenteel ook aan het solliciteren, en naast dat het super frustrerend is en je echt het hele team moet zijn blijkbaar (full stack + security + devops is niet meer genoeg) met 8 rondes. Waar ze trots zeggen AI first te zijn, maar je wel met het handje moet programmeren tijdens de interviews. En ook al was ik daar altijd erg goed in. Als je een jaar ofzo al full agentic probeert te gaan, dan vervalt dat toch wel zeer snel!

tldr: Ik wil houtbewerking doen ofzo.</sub>

---

Is dit niet iets meer voor de devschuur trouwens?

[ Voor 16% gewijzigd door ZpAz op 30-10-2026 10:40 ]

[tangentialdust]

1. Het model. ChatGPT, Claude, DeepSeek enz., plus instellingen zoals het reasoning level.
2. De agent. Het systeem dat de loop draait, met of zonder UI: Codex, Claude Code, OpenCode, Pi, Omp, JetBrains Air (gebruik ik zelf nu). Ik wacht nog op Tern.
3. Je eigen harness. De skills, plugins, regels en tooling die je er zelf omheen bouwt.

Ik zie de verdeling iets anders, het harnas is de combinatie van het programma plus de skills, plugins, etc. Een agent is 1 instantie van een model in je harnas die een gevraagde taak uitvoert.

Daarom denk ik dat de guardrails echt in de codebase en de loop zelf moeten zitten, niet alleen in een AGENTS.md

Dit sowieso, die AGENTS.md komt alleen aan het begin van de context binnen, als het model een tijdje draait is de recollection echt niet top meer.

Dat van de immer groeiende codebase herken ik ook. Oneindige review rounds die steeds weer een klein probleem vinden om dan vervolgens 20 minuten bijna je hele feature herschrijven. De statische tools zien er ook erg interessant uit, ga ik zeker wat mee spelen. Sowieso benieuwd naar de decision models.

Hou je statistieken bij van waar agents uitkomen in je schema? Ik heb een vrij minimale implement + review loop die na x review rounds of een design keuze direct stopt en de user om input vraag. Daar merkte ik wel dat de hoeveelheid review rounds bijvoorbeeld wat minder werden toen ik van modellen switchte. Ik zat op Opus 5.5 en Sonnet 5.5 voor implementatie met een simpele router ertussen. Nu aangepast naar Sol-6.1 high en medium als routes.

Soms vraag ik me af of de meeste mensen en bedrijven (ook Anthropic e.d.) gewoon genoegen nemen met slop die net iets boven vibe coding uitkomt.

Dat durf ik wel te wedden. Hier op werk is onze designer bijvoorbeeld volledig van Figma afgestapt en maakt direct prototypes met Claude Code. Opzich werkt het en het is handig om iets te hebben dat interactief is. Maar als je wat dieper gaat kijken is het veel plakband en prayers.

Is dit niet iets meer voor de devschuur trouwens?

Wellicht, ik poste hier omdat de model discussies ook hier waren. Maar verplaats het vooral als dit daar beter past.

[ZpAz]

tangentialdust schreef op vrijdag 30 oktober 2026 @ 14:48:
[...]

Ik zie de verdeling iets anders, het harnas is de combinatie van het programma plus de skills, plugins, etc. Een agent is 1 instantie van een model in je harnas die een gevraagde taak uitvoert.

Ah ja, ik denk dat het geheel inderdaad een agent is. Waar ik vanwege de titel eigenlijk meer op doelde, is dat het systeem vooral beter wordt door twee dingen: de modellen zelf en de specifieke structuur die je eromheen bouwt.

Het maakt volgens mij minder uit of je dat in OpenCode, Pi of een andere basisloop hangt. De tools, skills en kaders die je zelf instelt, voegen denk ik veel meer waarde toe.

Benchmarks zoals Terminal-Bench zijn zeker interessant, maar die testen vooral of veel kleine problemen opgelost kunnen worden. Ze kijken minder naar codekwaliteit en onderhoudbaarheid op de lange termijn (al is dat natuurlijk ook lastig te benchmarken).

Hou je statistieken bij van waar agents uitkomen in je schema?

Nee, ik ben voornamelijk nog aan het kijken of dit uberhaubt werkt. Vooralsnog is het ittereren, maar ik ben gefrustreerd haha.