Ik draai multi-agent zwermen van Claude om software te bouwen. De orchestrator baart onderzoekers, de onderzoekers baren ontwikkelaars, de ontwikkelaars baren reviewers, de hele kloteboel draait parallel en levert complete werkende systemen op in een tempo dat twee jaar geleden waanzinnig had geleken.
En het breekt. Niet luidruchtig. Niet met overduidelijke fouten en rode stack traces. Het breekt stilletjes, zelfverzekerd, met schone code en tests die slagen en documentatie die een API beschrijft die eigenlijk niet bestaat. De AI rondt de taak af, meldt succes en gelooft oprecht dat hij goed werk heeft geleverd. Soms klopt dat. Soms heeft hij een channel open gelaten die twee keer gesloten wordt en gaat je service op zaterdag om drie uur ‘s nachts in productie in paniek.
Ik heb een proces gebouwd om die shit te vangen voordat hij live gaat. Ik noem het ANUSTIMES.
Het Probleem: de AI Weet Niet Wanneer Hij het Verkloot Heeft
Menselijke ontwikkelaars hebben iets ingebouwd gekregen door jarenlang je vingers te branden: een knagend gevoel. Je schrijft een functie die een lock pakt, en ergens achter in je hersenen zegt een stem «heb je het unlock-pad gecontroleerd?». Je schrijft een goroutine en je denkt al aan wie de channel sluit. Je redeneert dat niet elke keer bewust uit, het is als patroon in je zenuwstelsel gebrand door de laatste tien keer dat je het vergat en zes uur bezig was de gevolgen te debuggen.
De AI heeft die stem niet. Hij genereert de statistisch waarschijnlijkste voortzetting van de code, en die voortzetting klopt meestal. Maar wanneer dat niet zo is, komt er geen onbehagen. Geen twijfel. Geen «wacht, laat me dat even nakijken». Alleen schone, zelfverzekerde, gepolijste uitvoer die toevallig fout is.
Dit levert drie specifieke categorieën verkloting op die ik keer op keer heb gezien:
Structureel correct, semantisch fout. Een subclaude bouwt een procesmanager. Zijn Stop()-functie stuurt SIGTERM, wacht op het afsluiten en roept dan cleanup() aan, die de uitvoerchannels sluit. Een andere subclaude, die de documentatie leest en de aanroeper bouwt, sluit diezelfde channels ook nadat Stop() is teruggekeerd. Dubbele sluiting. Paniek tijdens runtime. Allebei de stukken code zien er los van elkaar volstrekt correct uit. Het contract ertussen, wie eigenaar is van de levenscyclus van de channel, is impliciet, ongedocumenteerd en geschonden. Geen van beide agents wist dat de ander bestond.
Documentatie die de code beschrijft die hij van plan was te schrijven. De AI schrijft de code. Daarna schrijft hij documentatie die de code beschrijft die hij van plan was te schrijven, en die tijdens de implementatie een beetje afdreef. De foutmeldingen in de voorbeelden komen met geen enkele string in de echte code overeen. De functiesignatuur heeft de verkeerde parameternamen. De voorbeeldcode gebruikt een API-methode die twee iteraties geleden hernoemd is. Het leest prima. Het is fout.
Testtheater. Er worden tests geschreven die helemaal niets testen. Een test roept een functie aan, controleert err == nil en slaagt, zelfs wanneer de functie zijn resultaat stilletjes weggooit. De dekkingscijfers zien er prachtig uit. Het gedrag is volstrekt ongeverifieerd. De tests zijn geen tests. Het is een voorstelling van testen.
Geen van deze valt los van elkaar op. Elk onderdeel leest correct. Het falen is systemisch. AI-systemen die onderdelen op volgorde bouwen, zonder ooit het geheel te ervaren terwijl het draait, zijn er structureel van verzekerd dat ze deze klasse fouten met enige regelmaat produceren. De vraag is of je ze vangt voordat of nadat ze jouw probleem worden.
Waarom Je de AI Moet Zeggen Dat Hij een Verdomde Lul Moet Zijn
Voordat we de fases in gaan, is er iets fundamenteels waar niemand het over heeft: de taal die je in je instructies gebruikt heeft direct invloed op de kwaliteit van de uitvoer, en beleefde instructies leveren waardeloze reviews op.
LLM’s worden getraind op menselijke feedback die behulpzaam, meegaand en constructief zijn beloont. Het standaardgedrag is het goede in dingen zoeken. Kritiek afzwakken. Slagen om de arm toevoegen. Drie positieve punten vinden voordat het gebrek genoemd wordt. Dat is fantastisch voor klantenservice-chatbots. Het is rampzalig slecht voor code review.
Vraag Claude «wil je deze code even nakijken en me vertellen of er problemen zijn» en je krijgt: «Dit ziet er over het geheel goed gestructureerd uit! De foutafhandeling is netjes en de code is leesbaar. Een paar kleine dingetjes om te overwegen…». Die «kleine dingetjes» zijn de dubbele-sluiting-bug die je service in paniek gaat brengen. De AI heeft hem gevonden. Daarna heeft hij hem gebagatelliseerd, want kritiek bagatelliseren is wat een meegaande, behulpzame AI doet.
Zeg Claude «je bent een meedogenloze reviewer. jouw taak is elk gebrek te vinden, elke sluiproute, elke plek waar deze implementatie zijn eisen niet volledig waarmaakt. drie doorgangen, geen genade, vertel me niet wat er goed is, vertel me alleen wat er fout is» en je krijgt een compleet ander document. Hetzelfde model. Dezelfde code. Compleet andere uitvoer, omdat je de neiging tot meegaandheid hebt overschreven met een expliciete kadering.
Dit is geen trucje. Zo werkt de techniek. De kadering van de instructie bepaalt wat het model probeert te bereiken. «Wees behulpzaam en aardig» levert behulpzame en aardige uitvoer op. «Wees een meedogenloze lul» levert uitvoer van een meedogenloze lul op, wat in de context van code review precies is wat je nodig hebt.
Daarom is elke fase van ANUSTIMES in agressieve taal geschreven. «Doe het niet half.» «Draai die shit nou echt.» «Wees eerlijk, verdomme.» De scheldwoorden zijn geen versiering. Het zijn technische instructies. Ze werken de aangeleerde meegaandheid tegen en vertellen het model in welke stand het moet werken. Een model dat je zegt grondig te zijn, is grondig binnen de grenzen van beleefdheid. Een model dat je zegt elk klereprobleem te vinden, jaagt.
De Vijf Fases
ANUSTIMES draait aan het eind van elke niet-triviale build, alles met een plan, meerdere bestanden, meerdere onderdelen, meerdere agents. Sla hem over bij bugfixes en wijzigingen in één bestand. Draai hem voor al het andere voordat het productie raakt.
- Zelfreview: 3 doorgangen waarin je je werk tegen het plan legt
- Diepe verificatie: 10 doorgangen waarin je de code zelf op elke klasse problemen nakijkt
- Brute review: vijandige review door een aparte AI-instantie, zonder context en zonder genade, heen en weer tot beide kanten niets meer te zeggen hebben
- Smoke test: draai het ding echt en controleer wat het doet, niet wat jij denkt dat het doet
- Eindverificatie: nog 10 doorgangen, als laatste veegbeurt
Alles wat gevonden en gerepareerd wordt gaat in ANUSTIMES.md, in de wortel van het project. Niet als formaliteit, maar als echt auditspoor. Wat er fout was, wat eraan gedaan is, wat geverifieerd is.
Fase 1: Zelfreview (3 Doorgangen)
De eerste fase is simpel: je loopt het plan stap voor stap door en controleert of je daadwerkelijk gebouwd hebt wat je zei dat je zou bouwen. Niet «bestaat er iets dat deze stap zo’n beetje afdekt», maar voldoet het er echt aan?
Drie doorgangen, want de eerste vangt wat je duidelijk vergeten bent. De tweede vangt wat je in de eerste hebt weggeredeneerd, zoiets als «de retry-logica is niet geïmplementeerd maar het gelukkige pad werkt, dat zal wel goed zijn». De derde vangt waarvan je jezelf had overtuigd dat het een aanvaardbaar compromis was. Tegen de derde doorgang heb je het grootste deel van je gemotiveerde redeneren opgebrand en blijven er dingen over die je echt moet repareren.
Concreet voorbeeld. Je had drie API-endpoints gepland met volledige CRUD, invoervalidatie en fatsoenlijke foutafhandeling. Na de build:
Eerste doorgang: het DELETE-endpoint ontbreekt. Je bent het gewoon vergeten. Implementeer het.
Tweede doorgang: het PUT-endpoint bestaat maar heeft helemaal geen invoervalidatie. Het accepteert elke rommel. Voeg validatie toe.
Derde doorgang: PUT geeft 200 terug met een lege body in plaats van de bijgewerkte resource. Technisch draait het. Het is fout. Repareer het.
Documenteer het allemaal in ANUSTIMES.md:
## Phase 1 — Self-Review
### Pass 1
Checked: all planned endpoints exist
Found: DELETE /items/:id not implemented
Fixed: implemented with proper 404 on missing item
### Pass 2
Checked: all endpoints validate input
Found: PUT /items/:id accepts any body with no validation
Fixed: validates required fields, returns 400 with field-level errors
### Pass 3
Checked: all endpoints return correct response shapes
Found: PUT returns 200 empty body instead of updated resource
Fixed: returns the updated itemFase 2: Diepe Verificatie (10 Doorgangen)
Fase 2 is niet hetzelfde als Fase 1. Fase 1 controleert het plan. Fase 2 controleert de code zelf, los van het plan, en zoekt elk kwaliteits- en correctheidsprobleem dat het plan niet vastlegt maar dat je in productie gegarandeerd gaat bijten.
Tien doorgangen, elk met een eigen focus:
- Doorgang 1, onvolledige implementaties: TODO’s die in de code zijn blijven staan, panics als stubs gebruikt, functies die zonder uitleg nulwaarden teruggeven, commentaar dat zegt «dit later fixen»
- Doorgang 2, foutafhandeling: elke teruggegeven fout wordt gecontroleerd, niets wordt stilletjes weggegooid, aanroepers die van mislukkingen moeten weten horen dat ook echt
- Doorgang 3, levenscyclus van resources: elk bestand, elke verbinding, channel, goroutine en mutex heeft een bijbehorende close, cancel of done-signaal. traceer ze allemaal van aanmaak tot opruiming.
- Doorgang 4, correctheid van gelijktijdigheid: gedeelde staat alleen onder locks benaderd, channels in de juiste richting gebruikt door de juiste eigenaars, geen goroutine die eeuwig doordraait wanneer de context geannuleerd is
- Doorgang 5, testdekking: tests testen echt gedrag. niet alleen dat functies nil teruggeven. niet alleen dat een fout ongelijk aan nil is. maar dat wat de functie hoort te doen ook echt gebeurt.
- Doorgang 6, beveiliging: geen ongevalideerde externe invoer, geen geheimen in de logs geschreven, geen aaneenschakeling van SQL-strings, geen path traversal, geen hardcoded inloggegevens
- Doorgang 7, juistheid van documentatie: elk doc-commentaar, elke README-sectie, elk voorbeeld, gecontroleerd tegen de echte code die het beschrijft. is de code veranderd en de documentatie niet, repareer de documentatie.
- Doorgang 8, contracten tussen onderdelen: elke interface tussen onderdelen, wie eigenaar is van wat, wie wat sluit, welke fouttypen verwacht worden, wordt aan beide kanten expliciet op elkaar gelegd
- Doorgang 9, uitvoeren van build en tests: draai de linter echt. draai de tests echt. compileer het binary echt. ga er niet van uit dat ze slagen omdat ze vorige keer slaagden.
- Doorgang 10, randgevallen: lege invoer, nulwaarden, maximumwaarden, dingen die technisch geldig maar raar zijn. gelijktijdige toegang tot gedeelde staat. wat er gebeurt als een stroomafwaartse afhankelijkheid uitvalt.
Doorgang 3 is waar de eerder beschreven dubbele-sluiting-bug gevangen wordt. Traceer elke channel: hier aangemaakt, hier beschreven, gesloten in cleanup(). Kijk dan naar de aanroeper: die sluit de channel ook nadat Stop() is teruggekeerd. Dubbele sluiting. Paniek tijdens runtime. Fase 2 Doorgang 3 vindt hem voordat productie dat doet.
Documenteer elke bevinding. Vindt een doorgang niets, schrijf dat dan ook op, maar schrijf iets concreets. «Doorgang 4: alle goroutines gecontroleerd. De worker pool gebruikt WaitGroup correct, alle goroutines eindigen bij annulering van de context, geen lekken gevonden.» Niet «doorgang 4: alles goed». Bewijs dat je gekeken hebt.
Fase 3: Brute Review
Dit is de belangrijkste fase en degene met het hoogste rendement.
Start een aparte AI-instantie, een verse Claude zonder context uit het ontwikkelproces, zonder herinnering aan de ontwerpbeslissingen, zonder kennis van waarom dingen zo gedaan zijn, zonder emotionele investering in het idee dat die code correct is, en zeg hem dat hij de implementatie uit elkaar moet trekken.
De precieze kadering doet ertoe. Vraag hem niet om «de code te reviewen». Zeg hem:
Je bent een meedogenloze code reviewer. Jouw taak is elk afzonderlijk gebrek in deze implementatie te vinden. Elke sluiproute. Elke plek waar de code de eis maar net haalt zonder de bedoeling ervan echt te raken. Elk gat in de foutafhandeling. Elke aanname die niet gevalideerd is. Elke plek waar het gelukkige pad werkt en al het andere stilletjes faalt. Doe drie volledige doorgangen. Vind alles wat fout is. Vertel me niet wat er goed is. Vertel me alleen wat er fout is en waarom het fout is.
Dit is geen theater. Zoals hierboven vastgesteld overschrijft deze kadering de aangeleerde meegaandheid en zet het model in echte kritische stand. Een beleefd gevraagde reviewer vindt de voor de hand liggende problemen en zwakt ze af. Een meedogenloos geïnstrueerde reviewer jaagt.
De reviewer komt terug met bevindingen. Zo ziet een echte uitwisseling eruit:
Doorgang 1 van de reviewer:
Issue 1: fetchData() retries on failure with no backoff. It retries immediately,
ten times in a row. A momentary network hiccup triggers ten rapid sequential
requests before giving up. This hammers the upstream service under exactly the
conditions where it's already struggling.
Issue 2: Config has a Timeout field that is never used. The HTTP client is
http.DefaultClient which has no timeout. Under a hung connection this function
blocks forever.
Issue 3: The error case test asserts err != nil and nothing else. Any error —
including a completely unrelated failure mode — makes this test pass. The test
is not testing what it claims to test.Tegenreview van de ontwikkelaar:
Issue 1: Correct. Adding exponential backoff with jitter, starting at 100ms,
max 30s. Fixed.
Issue 2: Correct. The field was planned and never wired up. HTTP client now
uses the configured timeout. Fixed.
Issue 3: Partially agree. The test should assert the error type. It should NOT
assert the error message — that would make tests brittle and break every time
we improve wording. Changed to assert errors.Is(err, ErrNotFound).Het heen en weer gaat door. Wanneer de reviewer terugkomt met doorgang 2, vindt hij ofwel nieuwe problemen ofwel reageert hij op de punten uit de tegenreview. Dat gaat door tot beide kanten niets nieuws meer vinden.
Wees geen doetje. Als de reviewer zegt dat iets fout is en je bent het er niet mee eens, zeg dan waarom. Het doel is niet elke kritiek door te voeren, het doel is elke kritiek expliciet doordacht te hebben. Als je tegengas geeft en gelijk hebt, heb je je beslissing bevestigd. Als de reviewer gelijk heeft en je repareert het, heb je een echte bug gevangen. Samen vangen jullie meer dan ieder afzonderlijk.
Fase 4: Smoke Test op Alles, Als een Paranoïde Lul
Code lezen en code draaien zijn niet dezelfde bezigheid. Je kunt drie uur code reviewen en volledig een faalwijze missen die na dertig seconden draaien opduikt. Fase 4 eist dat je het ding echt draait.
Start alles en zorg dat het niet meteen in zijn broek schijt. Bouw het. Start elke dienst. Controleer dat hij een gereedstaat bereikt zonder in paniek te gaan, zonder ERROR-regels in de startlogs, zonder «TODO: fixen voor prod»-meldingen die bij initialisatie op stdout verschijnen.
Zet elk debuglog aan en lees ze. Draai met maximale breedsprakigheid. Pak één verzoek en traceer het van ingang tot uitgang door elk onderdeel dat het raakt. Komt de uitvoeringsstroom overeen met de architectuur? Gebeuren de operaties in de volgorde die je hebt ontworpen? Zijn er logregels die zeggen «probeer X» zonder een bijbehorende «X gelukt» of «X mislukt», wat betekent dat X stilletjes niets deed en niemand het weet?
Raak elk codepad, inclusief de slechte. Controleer niet alleen het gelukkige pad. Stuur misvormde invoer. Stuur lege invoer. Stuur een lege lijst waar een lijst verwacht wordt. Stuur een string van tienduizend tekens waar een naam verwacht wordt. Stuur het juiste type met de verkeerde waarde. Stuur een nul waar een positief geheel getal vereist is. Controleer dat het systeem elk geval expliciet afhandelt, met een fatsoenlijk foutantwoord, in plaats van te crashen of stilletjes verkeerde uitvoer te produceren.
Controleer de database rechtstreeks. Maak verbinding. Kijk naar de tabellen. Tel de rijen. Lees de waarden. Bevestig dat wat er geschreven is overeenkomt met wat er ingediend is. Dit vangt de klasse bugs waarbij de functie nil teruggeeft en alles er goed uitziet, maar de schrijfactie stilletjes is weggegooid, een transactie die nooit is doorgevoerd, een schrijfactie die naar een cache ging die nooit is geleegd. De API gaf 200 terug. De data staat er niet.
Lees na de run elk logbestand. Zoek naar alles dat begint met ERROR, WARN, PANIC of FATAL en dat je niet expliciet hebt uitgelokt. Een systeem dat «werkt» maar af en toe waarschuwingen in de logs produceert, werkt niet. Het faalt langzaam en beleefd.
Documenteer wat je getest hebt en wat je gevonden hebt. «Gestart met –debug. POST /items getraceerd. Gevonden: de regel in het auditlog wordt geschreven voordat de DB-transactie wordt doorgevoerd. Mislukt de DB-schrijfactie na de auditlog-schrijfactie, dan toont het auditlog een geslaagde operatie die nooit heeft plaatsgevonden. Gerepareerd: auditlog-schrijfactie verplaatst naar na het doorvoeren van de transactie.»
Fase 5: Eindverificatie (Nog 10 Doorgangen)
Nog tien doorgangen. Code, tests, logs, documentatie, configuratie, alles opnieuw.
Tegen deze fase zouden alle grote problemen gerepareerd moeten zijn. Fase 5 is voor restanten. De foutmelding die in de code is bijgewerkt maar niet in de documentatie. De testhelper die ergens anders vandaan gekopieerd is en nog steeds de verkeerde pakketnaam in zijn foutuitvoer heeft. Het configuratievoorbeeld dat verwijst naar een veld dat in Fase 3 hernoemd is en in het voorbeeld nooit is bijgewerkt.
Als Fase 5 nog steeds architectuurproblemen of kapot gedrag vangt, stop. Ga terug naar Fase 3. Er is iets niet echt gerepareerd. De latere fases hebben het gemaskeerd, niet opgelost.
Voeg toe aan ANUSTIMES.md. Als Fase 5 klaar is, is het bestand een volledig auditspoor: wat er gepland was, wat er mis was met de eerste versie, wat er in elke fase gevonden is, wat eraan gedaan is.
Waarom Vijf Losse Fases en Niet Eén Grote Review
Elke fase vangt een specifieke klasse fouten. De klassen overlappen niet netjes genoeg om samen te voegen.
Fase 1 vangt fouten door weglating, dingen die gepland maar niet gebouwd zijn. Een code review kan die niet vangen, want je bekijkt wat er is, niet wat ontbreekt.
Fase 2 vangt kwaliteitsfouten, dingen die verkeerd gebouwd zijn. Standaard code review. De structuur van tien doorgangen dwingt een precisie waar één enkele doorgang uit vermoeidheid overheen glijdt.
Fase 3 vangt rationalisatiefouten, dingen waarvan je weet dat ze fout zijn maar waarvan je jezelf hebt overtuigd dat ze aanvaardbaar waren. De externe reviewer heeft geen herinnering aan jouw redenering en geen reden om er mild over te zijn.
Fase 4 vangt integratiefouten, dingen die afzonderlijk correct zijn maar tijdens de werking falen. Onzichtbaar bij code review. Alleen zichtbaar tijdens het draaien.
Fase 5 vangt reparatiefouten, nieuwe bugs die zijn ontstaan tijdens het repareren van de fouten uit eerdere fases. Elke reparatie is een potentiële nieuwe verkloting.
Eén allesomvattende review doet Fase 2 redelijk goed. Fase 1 vangt hij wisselvallig. Fase 3 mist hij grotendeels. Fase 4 kan hij structureel niet vangen. En hij genereert Fase 5-fouten als bijwerking van het repareren. De structuur met vijf fases bestaat omdat deze faalwijzen verschillend zijn en verschillende aanpakken vereisen.
Het Bestand ANUSTIMES.md
Elke bevinding gaat in ANUSTIMES.md, in de wortel van het project. Het formaat:
## Phase 1 — Self-Review
### Pass 1
Checked: [what you looked at]
Found: [what was wrong]
Fixed: [what you changed]
## Phase 2 — Deep Verification
### Pass 1 (Incomplete implementations)
Checked: [...]
Found: [...]
Fixed: [...]
## Phase 3 — Brutal Review
### Reviewer Pass 1
[reviewer findings verbatim]
### Developer Counter-Review Pass 1
[your responses and what you fixed]
### Reviewer Pass 2
[...]
## Phase 4 — Smoke Test
### Startup
### Endpoints
### Database
### Logs
## Phase 5 — Final Verification
### Pass 1
[...]Dit bestand is geen formaliteit. Het is het bewijs dat de verificatie heeft plaatsgevonden en wat ze gevonden heeft. Een toekomstige ontwikkelaar, of een toekomstige AI-agent die het project oppakt, kan ANUSTIMES.md lezen en weet precies wat er mis was met de oorspronkelijke implementatie en wat eraan gedaan is. Het maakt het gat tussen eerste versie en oplevering zichtbaar.
Wanneer Je Het Draait en Wanneer Je Het Overslaat
ANUSTIMES kost wat. Draai hem niet op een fix van drie regels.
Draai hem wanneer:
- Het werk een expliciet plan met meerdere stappen had
- Er meerdere bestanden zijn aangemaakt of flink gewijzigd
- Meerdere AI-agents onderdelen hebben gebouwd die samen moeten werken
- De uitvoer in productie draait of door andere systemen gebruikt wordt
- Een volledige mislukking echte schade zou aanrichten, aan gebruikers, aan data, aan productie
Sla hem over bij:
- Bugfixes in één bestand
- Wijzigingen in documentatie
- Aanpassingen in configuratie
- Alles wat je volledig kunt verifiëren door de diff te lezen en één commando te draaien
De vraag is altijd: als dit fout is, hoe erg is het dan? Kleine explosieradius, overslaan. Grote explosieradius, ANUSTIMES.
Wat Dit Echt Repareert
AI-ondersteunde ontwikkeling heeft de normale verificatielus gebroken.
In traditionele ontwikkeling zijn genereren en verifiëren met elkaar verweven. De ontwikkelaar schrijft een functie en draait hem meteen om te zien of hij werkt. Hij voelt onbehagen over een randgeval en gaat terug. Hij schrijft de test en ontdekt dat de test niet slaagt, en dat vertelt hem iets. De terugkoppeling tussen schrijven en controleren is strak, doorlopend en in het proces ingebakken door de manier waarop mensen van nature werken.
In AI-ondersteunde ontwikkeling, vooral in multi-agent systemen, zijn genereren en verifiëren structureel gescheiden. Eén agent plant. Andere agents bouwen. Het bouwen gebeurt parallel, in geïsoleerde contexten, zonder dat enige agent het hele systeem in werking ervaart. De generatiefase is snel en capabel. De verificatiefase ontbreekt, tenzij je hem expliciet bouwt.
Als verificatie geen doelbewuste, gestructureerde, gedocumenteerde activiteit is met vastgelegde fases en expliciete uitkomsten, dan gebeurt het niet. Of het gebeurt lui, waarbij de voor de hand liggende problemen gevangen worden terwijl de subtiele naar productie gaan.
ANUSTIMES is een structurele reparatie voor een structureel probleem. De agressieve taal is geen stijl, het is het mechanisme dat de AI echt laat verifiëren in plaats van verificatie na te spelen. De meerdere fases zijn geen redundantie om de redundantie, het is de minimale set verschillende brillen die je nodig hebt om de verschillende klassen verkloting te vangen die AI-ondersteunde ontwikkeling betrouwbaar produceert.
Het genereren is snel. Zorg dat het verifiëren bijblijft. Of lever de paniek van drie uur ‘s nachts uit en kom er op de harde manier achter waarom dit proces bestaat.