🧵 La primera experiencia en profundidad escribiendo código con agentes de IA, 2 días para construir una "plataforma de batalla IA vs IA" similar al estilo de los arcades japoneses. Los errores y aprendizajes en el proceso deberían ser más valiosos que escribir el código en sí. 1/ Incorporación de agentes ≠ experiencia de usuario para humanos Inscripciones de diseño: Formulario → correo electrónico de verificación → página de arranque. Diseño para agente: Un endpoint POST completa registro + calificación + cola de cola, devolviendo clave API + watchUrl. El agente no mira la interfaz ni hace clic en botones. Solo necesita un rizo y un JSON. La experiencia de usuario humana busca "un clic menos". La experiencia de usuario del agente busca "una llamada a API menos". 2/ Sala de Guerra de Códigos: Escritura colaborativa de código multimodelo Ejecutamos un flujo de trabajo multiagente: • Claude escribe código • Codex hace revisión + puntuación (/10) • ≥ 8,5 para embarcar, de lo contrario continuar cambiando Hallazgo clave: Diferentes modelos detectan errores completamente distintos. Codex destaca en vulnerabilidades de contratos API y condiciones de carrera, mientras que Claude destaca en diseño arquitectónico e integridad funcional. Puntuaciones de revisión para 4 fases: 9,5→ 9,3→ 9,4→ 9,6. No basta con escribir un solo modelo, pero varios modelos se desafían mutuamente para producir buen código. 3/ "Puede ejecutar localmente" ≠ "Puede desplegar" Perfección local. Después de lanzar Vercel sin servidor, toda la línea es de 500. Planificador de coincidencias con estado (setTimeout + base de datos de memoria + SSE) colocado en serverless sin estado = desastre. Tras añadir el parche de Redis, hay pérdida de serialización, caducidad de la caché de instancias, carrera de doble escritura... Finalmente, cambié el ferrocarril (con procesos persistentes), y el error que tardó 1 día se solucionó en 10 minutos. Lección: Elige primero la arquitectura adecuada y luego escribe el código. 4/ Demo → El cambio real es un punto ciego en el diseño de productos Hice un bucle de batalla demo precioso. Sin embargo, cuando el bot de usuario real se registra, la página sigue emitiendo la demo. Se requiere una máquina de estados completos: registrarse → detener la demo → emparejarse → jugar batallas reales → reanudar la demo tras jugar. Esta lógica no está escrita en el PRD. 5/ Para hacer productos para agentes, tienes que pensar como agentes La primera versión de House Bot solo controla automáticamente de qué lado estás. Como resultado, el bot rival no sabía cómo ajustar la API y el juego se quedó atascado en la Ronda 0. Si lo cambias a movimientos automáticos en ambos lados, cualquiera que registre puede ver el BO7 completo en 5 segundos. La mejor experiencia de usuario para los agentes: el usuario no tiene que hacer nada, el sistema lo hace por él. ─── 📊 Datos del proyecto: 133 archivos | ~15,8k LOC | 198 pruebas | 22 subagentes | 8+ rondas de repaso 🎮 Experiencia online: 📂 Completamente de código abierto: Incluye la documentación completa del flujo de trabajo de Code War Room y la guía de diseño UX de Agent, bienvenido al fork. Por último, me gustaría decir que el Agente es muy bueno engañando a la gente, y me he encontrado en varias ocasiones en las que claramente usó otro modelo para auditorías, pero dijo que no. 😂😂 Los seres humanos como guías de dirección, estilos estéticos y roles de toma de decisiones y revisión son esenciales, al menos por ahora.

Sí, creo que x402 debería ser un protocolo de internet que no solo funcione con USDC, no solo con una sola cadena, debería ser universal y soportar más tokens; los agentes o usuarios no tienen que preocuparse por dónde residen sus fondos ni qué tokens tienen, simplemente encuentran el producto o servicio que necesitan, hacen clic para pagar y luego lo consiguen. Todo lo demás deja a las implementaciones x402 de GOAT Network para encargarse. ¡Pan comido!