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