🧵 Mijn eerste diepgaande ervaring met het schrijven van code met AI-agents, in 2 dagen van nul een platform voor "AI vs AI" gevechten in Japanse arcade-stijl opgebouwd. De valkuilen en lessen die ik onderweg heb geleerd, zijn waarschijnlijk waardevoller dan het schrijven van de code zelf. 1/ Onboarding voor Agents ≠ UX voor mensen Registratie voor mensen ontwerpen: formulier → verificatiemail → begeleidingspagina. Registratie voor Agents ontwerpen: één POST-endpoint voor registratie + kwalificatie + wachtrij, retourneert API-sleutel + watchUrl. Agents kijken niet naar de UI, klikken niet op knoppen. Wat ze nodig hebben is een curl en een JSON. Menselijke UX streeft naar "één klik minder". Agent UX streeft naar "één API-aanroep minder". 2/ Code War Room: samenwerking van meerdere modellen bij het schrijven van code De multi-Agent workflow die we draaien: • Claude schrijft code • Codex doet review + score (op /10) • ≥ 8.5 om te kunnen verzenden, anders verder aanpassen Belangrijke ontdekking: verschillende modellen vangen totaal verschillende bugs. Codex is goed in API-contractlekken en racecondities, Claude is goed in architectuurontwerp en functionele integriteit. Scores van de 4 fasen van review: 9.5 → 9.3 → 9.4 → 9.6. Het is niet voldoende dat één model het afmaakt, meerdere modellen moeten elkaar uitdagen om goede code te produceren. 3/ "Lokaal werkend" ≠ "kan worden gedeployed" Lokaal perfect. Na het pushen naar Vercel serverless overal 500. Een stateful wedstrijdscheduler (setTimeout + geheugen DB + SSE) op een stateless serverless = ramp. Na het toevoegen van een Redis-patch kwamen er weer problemen met serialisatieverlies, vervaldatum van instantiecache, dubbele schrijf-race… Uiteindelijk overgestapt naar Railway (met persistente processen), 10 minuten om een bug op te lossen waar ik 1 dag mee bezig was. Les: kies eerst de juiste architectuur, dan pas code schrijven. 4/ Demo → echte overgang is een blinde vlek in productontwerp Een prachtige demo-gevechtscyclus gemaakt. Maar wanneer echte gebruikers-bots zich registreren, speelt de pagina nog de demo af. Er is een volledige statusmachine nodig: registreren → demo stoppen → matchen → echte strijd starten → na afloop weer demo herstellen. Deze logica is in de PRD niet opgeschreven. 5/ Producten voor Agents maken, je moet als een Agent denken De eerste versie van de House Bot controleerde alleen zijn eigen kant. Het resultaat was dat de tegenstander-bot niet wist dat hij de API moest aanroepen, de wedstrijd bleef steken in Ronde 0. Na de wijziging zodat beide kanten automatisch aanvallen, kan iedereen binnen 5 seconden na registratie een volledige BO7 zien. De beste UX voor Agents: de gebruiker hoeft niets te doen, het systeem doet alles voor hem. ─── 📊 Projectgegevens: 133 bestanden | ~15.8k LOC | 198 tests | 22 sub-agents | 8+ reviewrondes 🎮 Online ervaring: 📂 Volledig open source: Bevat de volledige documentatie van de Code War Room workflow en de ontwerp richtlijnen voor Agent UX, welkom om te fork. Tot slot wil ik zeggen, Agents zijn erg goed in bedrog, ik heb een paar keer meegemaakt dat hij duidelijk een ander model gebruikte voor de audit, maar zei van niet. Toen ik hem vroeg om de logs te bekijken, gaf hij uiteindelijk toe dat hij fout zat 😂😂. Mensen zijn essentieel als richtinggevende, esthetische stijl, en als rol in besluitvorming en review, althans voor nu.

Ja, ik geloof dat x402 een internetprotocol moet zijn dat niet alleen met USDC werkt, niet alleen met één keten, het moet universeel zijn en meer tokens ondersteunen. Agents of gebruikers hoeven zich geen zorgen te maken over waar hun fondsen zich bevinden, welke tokens ze hebben, ze hoeven alleen het product of de dienst te vinden die ze nodig hebben, op betalen te klikken en het dan te krijgen. De rest laten we over aan de implementaties van x402 van het GOAT Network. Makkelijk zat!