Renacer del fracaso: una retrospectiva real sobre cómo conseguir un agente de IA frontend Hoy, en FEDay, compartí un caso práctico sobre la implementación de un agente frontend. La narrativa principal no trataba sobre una victoria triunfal, sino sobre cómo un equipo pasó del éxito técnico al fracaso del producto, y cómo ese fracaso condujo a una mejora crucial en nuestro marco cognitivo. El valor de esta historia no reside en una metodología para el éxito, sino en los obstáculos que encontramos y en la evolución de nuestro pensamiento.
El año 2025 se considera el "Año del Agente". Con el lanzamiento de Deep Research, Manus y Claude Code, la comunidad tecnológica está entusiasmada. Muchos equipos se hacen la misma pregunta: "¿Deberíamos construir un Agente?"
Antes de profundizar en el tema, permítanme aclarar mi definición de agente de IA: > Agente de IA: un modelo de lenguaje grande (LLM) que recorre las llamadas de herramientas para lograr un objetivo específico. - Herramientas en un bucle: El modelo llama a la herramienta -> Obtiene el resultado -> Continúa el razonamiento. - Clear Endpoint: funciona para lograr un objetivo, no para repetirse infinitamente. - Fuente de objetivo flexible: El objetivo puede provenir de un usuario o de otro LLM. - Memoria básica: mantiene el contexto a través del historial de conversaciones.
El desafío: sistemas de diseño privados El equipo de un amigo se enfrentaba a un verdadero problema empresarial: la empresa contaba con un sistema de diseño interno completo y un framework frontend privado. Sin embargo, dado que este código era privado, los modelos de IA públicos nunca se habían entrenado con él. Los modelos de propósito general simplemente no podían generar código que se ajustara a sus especificaciones internas. El objetivo parecía claro: crear una herramienta similar a Lovable, pero con su propio sistema de diseño. Los usuarios subían un diseño de Figma o una captura de pantalla, y el agente generaba automáticamente código frontend conforme a los estándares internos. Suena perfecto, ¿verdad?
La verificación de la realidad Los desafíos fueron sustanciales: 1. Construir un sistema de agente completo es más difícil de lo que parece (interacción del usuario, ingeniería de contexto, etc.). 2. El modelo debe comprender y utilizar componentes privados que nunca ha visto. 3. Necesitábamos vistas previas del navegador en tiempo real del código generado. 4. Necesitábamos capacidades de reparación automática si el código fallaba.
El "éxito técnico": cómo lo construimos Como consultor técnico, mi primer consejo fue pragmático: "Ponlo en marcha antes de optimizar". Construir el agente no es lo más difícil; completar el ciclo de ejecución completo sí lo es.
1. La Fundación: Claude Agent SDK En lugar de reinventar la rueda, nos basamos en el SDK de Claude Agent. - Comprobado: Claude Code demostró que esta arquitectura funciona. - Listo para usar: las herramientas integradas cubren el 90% de los escenarios. - Extensible: admite herramientas personalizadas, MCP (Protocolo de contexto de modelo) y habilidades personalizadas. (Puedes encontrar parte del código prototipo en código abierto aquí: https://t.co/eon1eb3ECD)
2. La solución de vista previa: Sistema de archivos local Inicialmente, probamos Sandpack (un entorno de pruebas basado en navegador) para previsualizar código, pero falló con componentes privados complejos. El punto clave: Le dimos al agente un sistema de archivos local (una máquina virtual o directorio por sesión). Esto le permitió leer, escribir, modificar y compilar código libremente.
Proporcionarle al Agente un sistema de archivos local es la única forma de maximizar sus capacidades.
3. Solución del problema del "Componente desconocido" ¿Cómo enseñar a una IA a utilizar una biblioteca de componentes que nunca ha visto? Trátalo como si fuera un empleado nuevo. Convertimos las especificaciones del Sistema de Diseño, las listas de componentes y la documentación de la API a Markdown. No se necesita un RAG complejo: simplemente permitimos que el Agente realice la recuperación de archivos en la documentación local y el "código de referencia de alta calidad".
4. Garantía de calidad: el ciclo de verificación Para garantizar que el código realmente funcionara, construimos un bucle automatizado: Generación -> Verificación -> Reparación - Herramientas: Linting estático, comprobaciones de compilación y comparación visual (utilizando Chrome DevTool MCP). - Optimización: Colocamos herramientas de verificación en una habilidad o subagente para evitar contaminar la ventana de contexto del agente principal.
El "fracaso del producto": el silencio tras el lanzamiento El sistema funcionó. La demo fue impresionante. Lo lanzamos... y casi nadie lo usó. Tras la desaparición de la novedad inicial, las tasas de abandono se dispararon. Realizamos un exhaustivo análisis post mortem y entrevistas a usuarios, y nos dimos cuenta de que el problema no era la tecnología, sino una falta de adecuación entre la lógica del producto y los hábitos de los usuarios.
Por qué falló 1. Resistencia al hábito: Los diseñadores y gerentes de proyecto viven en Figma, no en ventanas de chat. Pasar de su zona de confort a una interfaz conversacional fue un gran punto de fricción. La mayoría ni siquiera sabía qué escribir. 2. El cuello de botella 80/20: El agente realizó el 80 % del trabajo a la perfección. Pero el 20 % restante requirió modificaciones manuales, lo cual requirió un esfuerzo enorme. A menudo, ese 20 % determinaba si el código era utilizable o no. 3. Fragmentación del flujo de trabajo: El entorno de generación estaba desconectado del entorno de desarrollo real. Los desarrolladores tenían que copiar y pegar el código manualmente, lo que hacía el proceso tedioso.
La actualización cognitiva: replanteando el problema Nos dimos cuenta de que nos habíamos equivocado al plantear la pregunta: "¿Cómo construimos un agente de IA para sistemas de diseño?". Esto convirtió al agente en el objetivo, en lugar del medio. La pregunta correcta fue: "¿Cuál es el propósito final de nuestro sistema de diseño?" 1. Especificaciones de diseño unificadas en toda la empresa. 2. Mayor eficiencia en el desarrollo.
Cambio 1: Diseño para IA, no para humanos Los flujos de trabajo actuales están centrados en el ser humano: comunicación manual, modificación iterativa, confirmación manual. Los flujos de trabajo futuros deben estar centrados en la IA: Entrada -> Agente de IA -> Salida. Nuevos principios de diseño: - Compatible con IA: elija conjuntos de tecnologías que los LLM comprendan fácilmente. Ligero: Conserva solo tokens de diseño. Amplía tu sistema con sistemas de código abierto compatibles con IA (como shadcn/ui) en lugar de mantener una enorme biblioteca privada.
Cambio 2: De "Agente" a "Habilidad" El pivote más crítico fue abandonar la "Plataforma de Agentes Independientes". Modelo antiguo (isla): un agente independiente, aislado del desarrollador, lo que genera fricción. Nuevo modelo (integración): convertir el sistema de diseño en una habilidad que pueda integrarse en entornos de desarrollo de IA existentes (como Cursor o Claude Code).
¿Qué es una habilidad? Es simplemente documentación Markdown (para que la IA la lea) + scripts de automatización (para inicializar proyectos e instalar el sistema). Ahora, un desarrollador trabaja en su entorno habitual. Cuando necesita el Sistema de Diseño, el Agente genérico lo llama "Habilidad" y el código generado se almacena directamente en el repositorio del proyecto. (Enfoque de referencia: antrópicos/habilidades/árbol/principal/habilidades/constructor de artefactos web)
Perspectivas profundas: 4 conclusiones clave 1. ¡Éxito técnico! = Éxito del producto Muchos ingenieros (incluido yo) caen en la trampa de pensar: «Si funciona, por lo tanto, es exitoso». A los usuarios no les importa tu conjunto de tecnologías; les importa si resuelve su problema sin interrumpir su flujo. 2. Diseñar flujos de trabajo centrados en la IA Hablamos de "Centrado en el usuario", pero debemos añadir una capa: "Centrado en la IA". No permita que la IA imite los flujos de trabajo humanos. Rediseñe el flujo de trabajo para que la IA pueda operar con la máxima eficiencia y luego permita que el ser humano disfrute del resultado. 3. Habilidad > Agente Las plataformas de agentes independientes enfrentan grandes barreras de adopción. Encapsular capacidades como una habilidad que se integre al ecosistema existente es un camino mucho más pragmático. 4. Acción Aunque el producto inicial fracasó, la mejora cognitiva fue invaluable. No se puede aprender a pasar del flujo de trabajo humano al flujo de trabajo de IA sin poner manos a la obra.
¡Simplemente construyelo! El fracaso es aceptable. Es infinitamente mejor que no hacer nada.
