El Loop de ShadCN Es La Mejor Solución Para Tu UI Rota

El video introduce ShadCN como una de las bibliotecas de UI más utilizadas, pero señala problemas al usar agentes de IA para desarrollar con ella. Mientras que las páginas de aterrizaje simples funcionan bien, al construir aplicaciones complejas o implementar nuevas funciones, las cosas se rompen y afectan otras partes de la aplicación. Los agentes de IA intentan probar el código que escriben, pero se vuelven poco confiables con contextos grandes. Se necesita una forma de asegurar que los agentes completen el trabajo asignado, aquí es donde entran los bucles agénticos y específicamente el bucle Ralph de Anthropic.

Ralph es un nuevo plugin lanzado por Anthropic basado en una técnica de otra persona que ellos implementaron y liberaron como código abierto. Ralph es un bucle que usa los ganchos de detención de Claude Code que se ejecutan cuando Claude deja de generar una respuesta. Tan pronto como se detiene, el agente de IA recibe su archivo de prompt inicial nuevamente, permitiéndole mejorar su trabajo de manera iterativa. El bucle se detiene cuando Claude emite una 'promesa de finalización', que puede ser cualquier palabra configurada (en este caso 'complete'). Esto asegura que Claude no renuncie simplemente cuando quiera, sino que continúe trabajando hasta que realmente complete la tarea.

Después de instalar el plugin, se obtienen tres comandos: el comando de bucle Ralph, uno de cancelación y uno de ayuda. En el comando de bucle se proporciona el prompt que se alimenta al agente repetidamente. Es importante establecer un conteo máximo de iteraciones porque a veces Claude puede recibir una tarea imposible y quedarse atascado en un bucle infinito. El video menciona que el repositorio incluye buenas prácticas para los prompts que se pueden dar al bucle Ralph. El enfoque del video será discutir específicamente las mejores prácticas relacionadas con el flujo de trabajo de interfaz de usuario que se va a demostrar.

El video introduce dos funciones a implementar: una paleta de comandos para buscar y ejecutar comandos, y una vista de tablero similar a Notion. Para asegurar que estas funciones no rompan otras partes de la aplicación, se comienza con pruebas usando desarrollo guiado por pruebas (TDD). Claude Code puede configurar la estructura TDD automáticamente, creando carpetas de pruebas de extremo a extremo y capturas de pantalla para verificar problemas de UI. El TDD es un enfoque donde las pruebas se escriben antes de implementar el código, lo que significa que las pruebas iniciales siempre fallarán. Primero se escriben pruebas elaboradas, luego se escribe la cantidad mínima de código para pasarlas, y finalmente se refactoriza agregando más funcionalidad mientras se asegura que las pruebas sigan pasando.

Las pruebas son automatizadas y Playwright puede ser importado para verificación visual. A diferencia de usar el MCP de Playwright para verificar autónomamente a través del navegador, con TDD se toman capturas de pantalla para cada comportamiento funcional. Por ejemplo, si el comportamiento funcional es agregar una tarjeta, la captura de pantalla mostrará una tarjeta agregada al tablero. El agente de IA solo tiene que mirar esas capturas de pantalla y asegurarse de que no haya problemas en la implementación de los componentes de ShadCN. Estos archivos de prueba aseguran que cada vez que se agrega algo nuevo, todos los requisitos de comportamiento se cumplen, pero las capturas de pantalla se usan puramente para verificación de UI.

Aunque ya existe TDD, el bucle Ralph es necesario porque con tareas más grandes y ventanas de contexto casi llenas, los modelos abandonan abruptamente sus tareas y requieren entrada humana constante. Se pueden escribir pruebas de antemano para cualquier función, luego usar el bucle para instruir al agente sobre qué hacer y puede trabajar de forma autónoma. Se le indica qué flujo de trabajo seguir y la condición para emitir la promesa. Cuando completa la tarea y pasa todas las pruebas (en este caso 25 pruebas únicas), emite la promesa y sale del bucle, logrando autonomía completa en la implementación.

Usando el comando de Ralph, se proporcionó un prompt para construir iterativamente la función de paleta de comandos. El prompt incluía requisitos básicos (aunque estos también estaban en las pruebas) y delineaba todo el flujo de trabajo. El flujo de trabajo consistía en: ejecutar las pruebas (que fallarían inicialmente), implementar los componentes para hacerlas pasar, revisar capturas de pantalla de la interfaz de usuario para asegurar implementación correcta de ShadCN, y ejecutar las pruebas nuevamente para confirmar que aún pasaban después de los cambios de UI. Como esta era una tarea más pequeña, Claude pudo implementar todo de una vez, escribir todos los componentes y hacer que todas las pruebas pasaran. Después de revisar las capturas de pantalla y confirmar que todo funcionaba, emitió la promesa de finalización y el bucle se detuvo.

No hubo problemas con la paleta de comandos porque había pocas posibilidades de errores de UI, pero al implementar la vista de tablero se descubrió un error enorme en el sistema. Usando el mismo prompt con requisitos diferentes pero flujo de trabajo similar, Claude completó todos los requisitos de una vez y aseguró que las pruebas pasaran. Sin embargo, había casos donde el número de pruebas exitosas disminuía porque al cambiar algo se rompía algo más, demostrando la importancia del TDD. El problema principal fue que después de verificar que estaba terminado, al revisar la UI había errores que Claude había perdido completamente. Los errores eran visibles en las capturas de pantalla, pero Claude los había ignorado y emitió la promesa prematuramente sin verificar realmente si la UI estaba arreglada.

El análisis reveló que el problema fue una falla del proceso, específicamente en términos de arreglar la interfaz de usuario. Claude sí pasó todas las pruebas porque se suponía que debía ejecutar los archivos de prueba repetidamente, pero no había una prueba específica para la UI aparte de las capturas de pantalla. Claude echó un vistazo a algunas capturas de pantalla e ignoró errores de UI que había visto, y algunos archivos fueron completamente ignorados. El problema principal fue que emitió su declaración de promesa prematuramente sin verificar si la UI estaba realmente arreglada. Se realizó una sesión de lluvia de ideas usando las mejores prácticas del repositorio para llegar a reglas específicas y un cambio en el proceso que aseguraría que la UI siempre fuera correcta.

Se cambiaron varias cosas en el prompt principal. La primera fue el protocolo de verificación de capturas de pantalla: se agregó un prefijo simple a cada imagen indicando a Claude si había leído la captura de pantalla o no. En la primera implementación, Claude todavía no leía todas las imágenes, solo algunas, escribía 'verified' encima y renunciaba temprano. Para resolver esto se le alentó a pensar diferente: después de renombrar todas las capturas de pantalla, no debería emitir la promesa todavía, lo que significa que no debería considerar la tarea completada. La siguiente iteración confirmaría la finalización, garantizando que al menos dos bucles se ejecuten. Las pruebas se cambiaron para separar la verificación de imágenes de las pruebas funcionales.

La siguiente iteración se asegura de que todas las imágenes tengan el prefijo 'verified' y si Claude pierde alguna, las mira de nuevo y corrige la salida. Con este cambio, los pequeños errores de interfaz de usuario finalmente se corrigieron y pudo implementar todas las funciones correctamente. En el siguiente bucle, Claude ejecutó las pruebas de nuevo, encontró algunos errores y los corrigió. Debido a que todos los archivos tenían la palabra 'verified', ejecutó una prueba final. Esta vez completó su tarea en dos bucles y pudo corregir todos los errores importantes de interfaz de usuario en la aplicación, demostrando la efectividad del proceso mejorado.

El video concluye con una promoción de Automata, el servicio del creador que ayuda a dar vida a ideas mediante aplicaciones o sitios web. Después de enseñar a millones de personas cómo construir con IA, implementan estos flujos de trabajo ellos mismos y descubrieron que pueden construir mejores productos más rápido que nunca. Se posicionan como copiloto técnico para quienes tienen ideas pero no tienen equipo técnico, aplicando los mismos flujos de trabajo enseñados en sus videos para convertir conceptos en soluciones reales sin los dolores de cabeza de contratar o gestionar un equipo de desarrollo. Invita a contactarlos en hello@automata.dev y agradece el apoyo mediante el botón de Super Thanks.