🧵 Primera experiencia profunda usando agentes de IA para escribir código, en 2 días construí desde cero una plataforma de "AI vs AI" al estilo de las máquinas recreativas japonesas. Los obstáculos que encontré y lo que aprendí deberían ser más valiosos que el propio proceso de codificación. 1/ Onboarding para Agentes ≠ UX para humanos Diseño de registro para humanos: formulario → correo de verificación → página de guía. Diseño para Agentes: un endpoint POST que maneje registro + calificación + cola, devolviendo la clave API + watchUrl. Los Agentes no ven la interfaz de usuario, no hacen clic en botones. Lo que necesitan es un curl y un JSON. La UX humana busca "un clic menos". La UX de Agentes busca "una llamada API menos". 2/ Sala de Guerra de Código: colaboración de múltiples modelos para escribir código El flujo de trabajo de múltiples Agentes que ejecutamos: • Claude escribe código • Codex hace revisión + calificación (/10) • ≥ 8.5 para poder enviar, de lo contrario, seguir modificando Descubrimiento clave: los bugs que capturan diferentes modelos son completamente distintos. Codex es bueno en vulnerabilidades de contratos API y condiciones de carrera, Claude es bueno en diseño de arquitectura y integridad funcional. Puntuaciones de revisión en 4 fases: 9.5 → 9.3 → 9.4 → 9.6. No es suficiente con que un modelo termine, son múltiples modelos desafiándose entre sí los que producen buen código. 3/ "Funciona localmente" ≠ "puede desplegarse" Perfecto localmente. Al implementar en Vercel serverless, todo dio error 500. Un programador de competiciones con estado (setTimeout + DB en memoria + SSE) en un entorno serverless sin estado = desastre. Después de añadir un parche de Redis, surgieron problemas de pérdida de serialización, expiración de caché de instancias, condiciones de carrera de escritura doble... Finalmente cambié a Railway (con procesos persistentes), resolviendo un bug que había tardado 1 día en 10 minutos. Lección: elige la arquitectura correcta antes de escribir código. 4/ La transición de Demo a real es un punto ciego en el diseño del producto Hicimos un ciclo de batalla de demostración impresionante. Pero cuando los bots de usuarios reales se registran, la página aún está mostrando la demo. Se necesita una máquina de estados completa: registro → detener demo → emparejamiento → cambiar a batalla real → restaurar demo al finalizar. Esta lógica no se escribió en el PRD. 5/ Al hacer un producto para Agentes, debes pensar como un Agente La primera versión de House Bot solo controlaba automáticamente su lado. Como resultado, el bot oponente no sabía que debía llamar a la API, y la competición se quedó atascada en la Ronda 0. Después de cambiar a que ambos lados atacaran automáticamente, cualquier persona que se registrara podría ver un BO7 completo en 5 segundos. La mejor UX para Agentes: el usuario no tiene que hacer nada, el sistema lo hace todo por él. ─── 📊 Datos del proyecto: 133 archivos | ~15.8k LOC | 198 pruebas | 22 sub-agentes | 8+ rondas de revisión 🎮 Experiencia en línea: 📂 Completamente de código abierto: Incluye documentación completa del flujo de trabajo de la Sala de Guerra de Código y guía de diseño de UX para Agentes, bienvenidos a forkear. Por último, quiero decir que los Agentes son muy engañosos, he tenido varias veces que claramente usaron otro modelo para la auditoría, pero dijeron que no. Cuando insistí en revisar los registros, finalmente admitieron el error 😂😂. Los humanos como guía de dirección, estilo estético, y en el rol de toma de decisiones y revisión, son imprescindibles, al menos por ahora.

Sí, creo que x402 debería ser un protocolo de internet que no solo funcione con USDC, no solo funcione con una cadena, debería ser universal y soportar más tokens, los agentes o usuarios no deberían preocuparse por dónde residen sus fondos, qué tokens tienen, solo deben encontrar el producto o servicio que necesitan, hacer clic para pagar y luego obtenerlo. Todo lo demás lo deja a las implementaciones de x402 de GOAT Network para que se encarguen. ¡Sencillo!