🧵 Впервые погрузился в опыт написания кода с помощью AI-агентов, за 2 дня с нуля создал платформу для боев AI против AI в стиле японских аркад. Проблемы, с которыми я столкнулся, и уроки, которые я извлек, вероятно, более ценны, чем сам процесс написания кода. 1/ Онбординг для агентов ≠ UX для людей Для людей проектируется регистрация: форма → проверка электронной почты → страница с инструкциями. Для агентов проектируется: один POST endpoint для регистрации + проверки + очереди, возвращающий API ключ + watchUrl. Агент не смотрит на UI и не нажимает кнопки. Ему нужно всего лишь curl и JSON. UX для людей стремится к «меньше одного клика». UX для агентов стремится к «меньше одного API вызова». 2/ Кодовая комната войны: совместная работа нескольких моделей над кодом Мы запустили рабочий процесс с несколькими агентами: • Claude пишет код • Codex делает ревью + ставит оценку (/10) • ≥ 8.5 — только тогда можно отправлять, иначе продолжаем исправлять Ключевое открытие: разные модели находят совершенно разные ошибки. Codex хорошо справляется с уязвимостями API и условиями гонки, Claude — с архитектурным дизайном и целостностью функций. Оценки на 4 этапах ревью: 9.5 → 9.3 → 9.4 → 9.6. Не достаточно, чтобы один модель написала код, несколько моделей должны бросать вызов друг другу, чтобы получить хороший код. 3/ "Работает локально" ≠ "можно развернуть" Локально все идеально. После развертывания на Vercel serverless все выдало 500. Состояние соревнования (setTimeout + память БД + SSE) на безсостоянии serverless = катастрофа. После добавления патча Redis возникли проблемы с потерей сериализации, истечением кэша экземпляров, условиями гонки при двойной записи… В конце концов, мы перешли на Railway (с постоянными процессами), и за 10 минут решили баг, который мучил нас целый день....