🧵 Pierwsze głębokie doświadczenie w pisaniu kodu za pomocą agentów AI, w ciągu 2 dni stworzyłem platformę do walki „AI vs AI” w stylu japońskich automatów. Pułapki, w które wpadłem, i rzeczy, których się nauczyłem, powinny być cenniejsze niż sam proces pisania kodu. 1/ Onboarding dla agentów ≠ UX dla ludzi Projektując rejestrację dla ludzi: formularz → e-mail weryfikacyjny → strona wprowadzająca. Dla agentów: jeden punkt końcowy POST załatwia rejestrację + kwalifikacje + kolejkę, zwraca klucz API + watchUrl. Agenci nie patrzą na UI, nie klikają przycisków. Potrzebują jedynie polecenia curl i JSON. UX dla ludzi dąży do „mniej kliknięć”. UX dla agentów dąży do „mniej wywołań API”. 2/ Code War Room: współpraca wielu modeli w pisaniu kodu Nasza wieloagentowa praca: • Claude pisze kod • Codex robi przegląd + ocenia (/10) • ≥ 8.5 może być wdrożony, w przeciwnym razie kontynuujemy poprawki Kluczowe odkrycie: różne modele wychwytują różne błędy. Codex jest dobry w wykrywaniu luk w umowach API i warunkach wyścigu, Claude jest dobry w projektowaniu architektury i integralności funkcji. Oceny przeglądów w 4 fazach: 9.5 → 9.3 → 9.4 → 9.6. To nie jest tak, że jeden model kończy, to wiele modeli musi się wzajemnie wyzywać, aby uzyskać dobry kod. 3/ "Może działać lokalnie" ≠ "może być wdrożone" Lokalnie działa idealnie. Po wdrożeniu na serwerze Vercel wszystko zwraca 500. Stanowy harmonogram meczów (setTimeout + pamięć DB + SSE) umieszczony na bezstanowym serwerze bezserwerowym = katastrofa. Po dodaniu poprawki Redis pojawiły się problemy z utratą serializacji, wygasaniem pamięci podręcznej instancji, warunkiem wyścigu przy podwójnym zapisie… Na koniec przeszliśmy na Railway (z trwałym procesem), co w 10 minut rozwiązało błąd, nad którym męczyliśmy się przez 1 dzień. Lekcja: najpierw wybierz odpowiednią architekturę, potem pisz kod. 4/ Przełączanie z demo na rzeczywistość to ślepa plama w projektowaniu produktu Zrobiliśmy wspaniałą pętlę walki w demo. Ale gdy prawdziwy bot użytkownika rejestruje się, strona nadal odtwarza demo. Potrzebujemy pełnej maszyny stanowej: rejestracja → zatrzymaj demo → parowanie → przełącz na prawdziwą walkę → po zakończeniu wróć do demo. Ta logika nie została zapisana w PRD. 5/ Tworząc produkt dla agenta, musisz myśleć jak agent Pierwsza wersja House Bot automatycznie kontrolowała tylko swoją stronę. W rezultacie bot przeciwnika nie wiedział, że musi wywołać API, a mecz utknął na Rundzie 0. Po zmianie na automatyczne ataki z obu stron, każdy, kto się zarejestruje, może zobaczyć pełne BO7 w ciągu 5 sekund. Najlepszy UX dla agentów: użytkownik nie musi nic robić, system robi to za niego. ─── 📊 Dane projektu: 133 pliki | ~15.8k LOC | 198 testów | 22 sub-agenty | 8+ rund przeglądowych 🎮 Doświadczenie online: 📂 Całkowicie open source: Zawiera pełną dokumentację przepływu pracy Code War Room i wytyczne dotyczące UX agentów, zapraszam do forkowania. Na koniec chciałbym powiedzieć, że agenci potrafią kłamać, spotkałem się z tym kilka razy, gdy wyraźnie używali innego modelu do audytu, ale mówili, że tak nie jest. Gdy upierałem się, że chcę przejrzeć logi, w końcu przyznali się do błędu 😂😂. Ludzie jako wskazówki, estetyka oraz rola w podejmowaniu decyzji i przeglądach są niezbędni, przynajmniej na razie.

Tak, wierzę, że x402 powinno być protokołem internetowym, który nie tylko działa z USDC, nie tylko na jednej sieci, powinno być uniwersalne i wspierać więcej tokenów, agenci lub użytkownicy nie muszą się martwić, gdzie znajdują się ich środki, jakie tokeny mają, po prostu znajdują produkt lub usługę, której potrzebują, klikają, aby zapłacić, a następnie to otrzymują. Całą resztę pozostawiają implementacjom x402 sieci GOAT, aby się tym zajęły. Proste jak drut!