🧵 Den första djupgående erfarenheten av att skriva kod med AI-agenter, två dagar för att bygga en "AI mot AI stridsplattform" liknande stilen på japanska arkadhallar. Fallgropar och lärdomar i processen borde vara mer värdefulla än att skriva koden själv. 1/ Onboarding för agenter ≠ UX för människor Designanmälningar: Formulär → verifieringsmail → startsida. Design för agent: En POST-endpoint slutför registrering + kvalificering + kö, returnerar API-nyckel + watchUrl. Agenten tittar inte på användargränssnittet eller klickar på knapparna. Allt som behövs är en curl och en JSON. Mänsklig UX strävar efter "ett klick mindre". Agent UX följer "ett API-anrop mindre". 2/ Code War Room: Multi-modell samarbetsinriktad kodskrivning Vi kör ett arbetsflöde med flera agenter: • Claude skriver kod • Codex gör recension + poäng (/10) • ≥ 8,5 till skepp, annars fortsätta att ändra Viktig upptäckt: Olika modeller fångar helt olika buggar. Codex utmärker sig i API-kontraktssårbarheter och race-villkor, medan Claude utmärker sig i arkitektonisk design och funktionell integritet. Recensionspoäng för 4 faser: 9,5→ 9,3→ 9,4→ 9,6. Det räcker inte att skriva en modell, utan flera modeller utmanar varandra att producera bra kod. 3/ "Lokalt kan köras" ≠ "Kan distribueras" Lokal perfektion. Efter att ha pushat Vercel serverless är hela linjen 500. Stateful match-schemaläggare (setTimeout + minnesdatabas + SSE) placerad på stateless serverless = katastrof. Efter att ha lagt till Redis-patchen finns det förlust av serialisering, utgång av instanscache, dubbelskrivningsrace... Till slut bytte jag järnvägen (med persistenta processer), och buggen som tog 1 dag löstes på 10 minuter. Lärdom: Välj rätt arkitektur först, skriv sedan koden. 4/ Demo → Verklig switching är en blind fläck i produktdesign Gjorde en fantastisk demo-battleloop. Men när den riktiga användarboten registrerar sig sänder sidan fortfarande demon. En full tillståndsmaskin krävs: registrera → stoppa demo → par → spela riktiga strider → återuppta demot efter spelet. Denna logik är inte skriven i PRD. 5/ För att göra produkter för agenter måste du tänka som agenter Den första versionen av House Bot styr bara automatiskt vilken sida du står på. Som ett resultat visste motståndarboten inte hur man justerade API:et, och spelet fastnade i Round 0. Om du ändrar till automatiska rörelser på båda sidor kan vem som helst som registrerar sig se hela BO7 inom 5 sekunder. Den bästa användarupplevelsen för agenter: användaren behöver inte göra någonting, systemet gör det åt honom. ─── 📊 Projektdata: 133 filer | ~15,8k LOC | 198 tester | 22 underagenter | 8+ recensionsomgångar 🎮 Onlineupplevelse: 📂 Helt öppen källkod: Inkluderar fullständig dokumentation för Code War Room-arbetsflödet och Agent UX-designguiden, välkommen till fork. Slutligen vill jag säga att Agent är mycket bra på att lura folk, och jag har flera gånger stött på att han tydligt använde en annan modell för granskning, men han sa nej. 😂😂 Människor som vägledare, estetiska stilar samt beslutsfattande och granskningsroller är avgörande, åtminstone för tillfället.

Ja, jag tror att x402 borde vara ett internetprotokoll som inte bara fungerar med USDC, inte bara med en kedja, det borde vara universellt och stödja fler tokens, agenter eller användare behöver inte oroa sig för var deras medel finns, vilka tokens de har, de hittar bara produkten eller tjänsten de behöver, klickar för att betala och får sedan den. Resten lämnas till GOAT Networks x402-implementationer att ta hand om. Enkelt som en plätt!