Bijna elke AI-fout begint in het ticket

Bijna elke fout die AI maakte tijdens onze hackathon met het ontwikkelteam van One Go, zat in het ticket, in wat niemand had opgeschreven. Een klein deel zat in de code zelf. Wie sneller wil werken met AI, wint dus het meest bij betere specs, en dat vraagt iets van developers en product owners.

Te vaag of te opgeblazen

Een ticket kan op twee manieren tekortschieten. Het is te vaag, of het is met AI aangevuld en daardoor enorm opgeblazen. In beide gevallen weet degene die gaat bouwen niet precies wat er moet gebeuren. Bij One Go speelden allebei.

Daar ging de hackathon over: hoe kom je van een idee tot een plan dat je echt kunt uitvoeren? We probeerden het met spec driven development, losjes gebaseerd op een blogpost van Anthropic: eerst de intent, dan de spec, dan het plan. Drie gemengde hackathonteams van developers en non-developers werkten er een dag mee, op echte tickets van de backlog.

Wie niet bij het overleg was

Volgens een schatting van het ontwikkelteam van One Go is maar 1 à 2% van de fouten van AI echt verkeerd geschreven code. De rest begint in de spec. Waar die iets openlaat, vult de AI zelf een aanname in.

Een voorbeeld uit het project laat zien dat dit niet alleen voor AI geldt. Een versioning-API werd anders gebouwd dan hij was bedacht. De developer die hem bouwde, kwam pas later bij het team en was niet bij de eerdere gesprekken. De details stonden niet in het ticket, dus er was geen manier om ze te weten. Een AI-agent zit in precies die positie, alleen bij elk ticket.

Dat legt werk bij de product owner. Edge cases horen in het ticket voordat er een plan komt, ook bij een klein ticket. Wat je bij een bug of kleine toevoeging wel kunt overslaan, zijn de aparte stappen voor intent en plan. Daar kost het meer dan het oplevert. Bij een hele feature verdient het zich terug.

Wat in een hoofd zit, weet de AI niet

Een van de hackathonteams gaf dezelfde prompt op verschillende machines en kreeg verschillende resultaten. Het verschil zat in de regels die iedereen Claude in de loop van de tijd had gegeven. Dat is kennis van het team, maar het stond op één laptop.

Bij design gebeurde hetzelfde. Voor een kleine feature, zoals een instellingenpagina, is het design systeem genoeg, mits de AI expliciet de opdracht krijgt het te gebruiken. Geef je een Figma-ontwerp mee, dan volgt de AI dat heel letterlijk en gaat hij bestaande componenten restylen zodra die een klein beetje afwijken. Wanneer een ontwerp nodig is en wanneer het design systeem volstaat, is nu een afweging in iemands hoofd.

Beide horen op een plek waar het hele team ze kan vinden. Ook dat is spec: wat niet is opgeschreven, vult de AI zelf in.

Review bepaalt het tempo

Bij One Go is het grootste deel van de codebase met de hand geschreven. Nieuwe features laat het team grotendeels door AI schrijven, en die code wordt volledig gereviewd. Het lijkt meer op pair programming dan op een AI die zelfstandig zijn gang gaat. De regel is simpel: je bent verantwoordelijk voor de code in je pull request, hoe je daar ook komt.

Die volledige review is nodig omdat AI fouten maakt. En daar zit het knelpunt: AI levert veel meer tekst en code dan iemand kan reviewen. Op de hackathon liep elk hackathonteam daartegenaan. Agent Teams, een functie in Claude Code waarbij meerdere agents tegelijk aan één taak werken, elk met een eigen context, leverde goed werk. Omdat elke agent die context zelf opbouwt, ging er voor één ticket wel zoveel aan tokens doorheen dat het nog niet efficiënt is.

Claude reviewt eerst en vangt daarbij echte fouten af. Daarnaast komt hij met veel smaakkwesties, die het team vaak naast zich neerlegt. Wat developers daarna zelf nog vinden, gaat over domeinkennis en over fouten die voortkomen uit een onduidelijke of onvolledige spec. Wat in de review overblijft, begon dus meestal in het ticket.

Het team zou meer kunnen maken dan het nu doet, maar houdt bewust het tempo aan dat het kan reviewen. Het vakmanschap zit steeds meer in de spec en in het beoordelen van wat eruit komt.

De volgende keer draaien we het om

Op de volgende hackathon voegen we AI niet toe aan het proces dat er al is. We kijken welke processen anders moeten nu AI er is. Een belangrijk doel: de review zo inrichten dat het team die durft uit te besteden, bijvoorbeeld met geautomatiseerde UI-tests die de oude en de nieuwe situatie vergelijken.

Intent, spec en plan horen daarbij in het ticket. Daar zien mensen en de business wat er gebeurt, en daar vindt een agent, of een developer die later aansluit, wat er besproken is.

Verder vooruit verwachten we systemen die dag en nacht doorwerken, waarbij mensen 's ochtends via een dashboard de vragen beantwoorden die zijn blijven liggen. Ook dat zijn in de kern vragen over de spec.

Eerlijk is eerlijk: dit is bleeding edge, en de helft van wat we proberen levert misschien niets op. De backlog is met AI geslonken van zo'n drie jaar naar één jaar werk, maar One Go heeft ideeën voor jaren. Tijd om te experimenteren ontstaat dus niet vanzelf. Die moet je bewust vrijmaken, en daar is deze hackathon voor.

Wat dat in de praktijk betekent: edge cases staan in het ticket voordat er een plan is, teamregels en design-afwegingen staan op één plek die iedereen kan vinden, en in de review kijk je ook naar wat er in de spec ontbrak.

Over een jaar voeren we dit gesprek opnieuw, om te zien waar we dan staan.

Pak je volgende featureticket erbij en geef het aan iemand die niet bij het overleg was. Vraag wat die gaat bouwen. Elk verschil met wat jij bedoelde, is iets wat een agent zelf gaat invullen, en hoort dus nog in het ticket.