🧵 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.

49 x402-integrasjoner. 157 ERC-8004-agenter registrert. En hackathon. 🦞 Hos "OpenClaw on Bitcoin" i SF brukte et fullt hus av byggere GOAT Network til å gjøre noe vi ikke har sett i stor skala før: agenter som aktivt ansetter andre agenter, betaler hverandre autonomt og bygger omdømme på kjeden – alt på én dag. Slik ser den agentiske økonomien på Bitcoin ut – og den har så vidt begynt. Bygger du fortsatt? Vår virtuelle hackathon er fortsatt åpen: