🧵 Den første dyptgående erfaringen med å skrive kode med AI-agenter, 2 dager for å bygge en "AI mot AI kampplattform" lik stilen til japanske arkader. Fallgruvene og læringene i prosessen bør være mer verdifulle enn å skrive selve koden. 1/ Onboarding for agenter ≠ UX for mennesker Designpåmeldinger: Skjema → verifiserings-e-post → oppstartsside. Design for agent: Et POST-endepunkt fullfører registrering + kvalifisering + kø, returnerer API-nøkkel + watchUrl. Agenten ser ikke på brukergrensesnittet eller klikker på knappene. Alt den trenger er en curl og en JSON. Menneskelig UX jakter på «ett klikk mindre». Agent UX følger "ett API-kall mindre". 2/ Code War Room: Multi-modell samarbeidende kodeskriving Vi kjører en arbeidsflyt med flere agenter: • Claude skriver kode • Codex gjør anmeldelse + poengsum (/10) • ≥ 8,5 til skip, ellers fortsette å endre Viktig funn: Ulike modeller fanger helt forskjellige feil. Codex utmerker seg i API-kontraktssårbarheter og kappløpsbetingelser, mens Claude utmerker seg i arkitektonisk design og funksjonell integritet. Gjennomgangsresultater for 4 faser: 9,5→ 9,3→ 9,4→ 9,6. Det er ikke nok å skrive én modell, men flere modeller utfordrer hverandre til å produsere god kode. 3/ "Lokal kan kjøre" ≠ "Kan deployere" Lokal perfeksjon. Etter å ha pushet Vercel serverløs, er hele linjen 500. Stateful match-planlegger (setTimeout + minnedatabase + SSE) plassert på stateless serverless = katastrofe. Etter å ha lagt til Redis-patchen, er det tap av serialisering, utløp av instanscache, dobbelskriving... Til slutt byttet jeg jernbanen (med vedvarende prosesser), og feilen som tok én dag ble løst på 10 minutter. Leksjon: Velg riktig arkitektur først, og skriv deretter koden. 4/ Demo → Ekte switching er en blind flekk i produktdesign Gjorde en nydelig demo-battle-loop. Men når den ekte brukerboten registrerer seg, sender siden fortsatt demoen. En full tilstandsmaskin kreves: registrer deg → stopp demoen → par → spille ekte kamper → gjenoppta demoen etter spilling. Denne logikken er ikke skrevet i PRD-en. 5/ For å lage produkter for agenter må du tenke som agenter Den første versjonen av House Bot styrer automatisk hvilken side du er på. Som et resultat visste ikke motstanderboten hvordan den skulle justere API-en, og spillet satt fast i runde 0. Hvis du endrer det til automatiske bevegelser på begge sider, kan hvem som helst som registrerer seg se hele BO7 innen 5 sekunder. Den beste brukeropplevelsen for agenter: brukeren trenger ikke gjøre noe, systemet gjør det for ham. ─── 📊 Prosjektdata: 133 filer | ~15,8k LOC | 198 tester | 22 under-agenter | 8+ gjennomgangsrunder 🎮 Nettopplevelse: 📂 Fullstendig åpen kildekode: Inkluderer full Code War Room-flytdokumentasjon og Agent UX-designguide, velkommen til fork. Til slutt vil jeg si at Agent er veldig flink til å lure folk, og jeg har opplevd flere ganger at han tydeligvis brukte en annen modell for auditing, men han sa nei. 😂😂 Mennesker som retningsrettede veiledere, estetiske stiler og beslutnings- og vurderingsroller er essensielle, i hvert fall foreløpig.

Ja, jeg mener x402 bør være en internettprotokoll som ikke bare fungerer med USDC, ikke bare med én kjede, det bør være universelt og støtte flere tokens, agenter eller brukere trenger ikke bekymre seg for hvor midlene deres befinner seg, hvilke tokens de har, de finner bare produktet eller tjenesten de trenger, klikker for å betale og får det deretter. Alt annet overlates til GOAT Networks x402-implementasjoner å ta seg av. Enkelt som bare det!