00:00:00Aunque Claude Code es una de las herramientas más potentes para el desarrollo de IA,
00:00:03¿por qué falla en ciertas tareas? Entre las funciones que Anthropic ha estado
00:00:08lanzando recientemente y los flujos de trabajo que hemos creado a su alrededor, la forma
00:00:12correcta de usarlo es hoy totalmente distinta a la de hace unas semanas. Nuestro equipo usa
00:00:16Claude Code a diario, y no solo para desarrollo, sino también para investigación, gestión de
00:00:21nuestro entorno de producción y automatización de tareas ajenas al código. Así que voy a mostrarles
00:00:26todo lo que hemos descubierto. Anthropic añadió hace poco el comando "insights" para Claude Code. Este analiza
00:00:31todas tus sesiones pasadas de Claude Code durante un periodo determinado y genera un informe. Dicho informe
00:00:36analiza tu estilo de trabajo, critica tus patrones habituales, resalta tus aciertos
00:00:40y errores, y te indica cómo mejorar. Lo que más nos interesaba era identificar
00:00:45dónde fallaban las cosas, porque ahí es donde podemos aprender y mejorar. El informe destacó
00:00:49las áreas con mayor fricción y sugirió funciones que podíamos añadir para optimizar
00:00:54el flujo de trabajo. Por ejemplo, recordamos una sesión en la que el agente principal consultó la lista
00:00:58de tareas repetidamente durante mucho tiempo al usar equipos de agentes. Esto hizo que la sesión se alargara demasiado
00:01:03y tuvimos que finalizarla nosotros mismos. Para evitar que esto ocurra en el futuro, podemos copiar este prompt
00:01:07en "claude.md" para que, cuando usemos Claude Code con multiagentes, Claude no consulte
00:01:12indefinidamente y actúe de inmediato. Podemos importar estos consejos a nuestros proyectos para futuros flujos, logrando que
00:01:17nuestra experiencia con Claude Code mejore con el tiempo. Nuestro equipo ha dedicado mucho tiempo a trabajar
00:01:22con Claude Code, y el paso más importante sigue siendo qué tan bien le proporcionas el contexto al agente.
00:01:26Esto puede incluir requisitos del proyecto desglosados en subpartes o documentación de los frameworks y
00:01:30librerías que estás utilizando; cuando le das el contexto adecuado, los errores prácticamente desaparecen
00:01:35porque sabe exactamente sobre qué actuar. Para la documentación del proyecto, preferimos que Claude la escriba
00:01:39en lugar de hacerlo nosotros mismos. Le dimos a Claude un prompt específico que contenía toda la información
00:01:44necesaria para desglosar la idea del proyecto en los documentos requeridos. Le pedimos que creara
00:01:48cuatro documentos, cada uno centrado en un aspecto específico de la aplicación. El más importante es el PRD,
00:01:53que contiene información sobre los requisitos y el alcance del proyecto. Luego está "architecture.md",
00:01:57que detalla el formato de datos, estructura de archivos, APIs y todos los detalles de arquitectura.
00:02:02Después, "decision.md", que incluye todas las decisiones que tomó Claude durante la creación del proyecto,
00:02:08sirviendo como referencia futura. Y el más crucial es "feature.json", que contiene
00:02:12todas las funcionalidades en un formato JSON específico. Incluye detalles de cada función de forma
00:02:17eficiente en términos de tokens, criterios de finalización y una clave de seguimiento para saber
00:02:22qué se ha implementado y qué no. Una vez que tu gran tarea está dividida en
00:02:27secciones más pequeñas, necesitamos proporcionar documentación sobre qué herramientas requiere para la implementación mediante
00:02:31el MCP de Context 7. Tiene documentación de todas las librerías y frameworks y se actualiza
00:02:36frecuentemente para que los agentes obtengan los documentos más recientes y cubran la brecha entre lo que el modelo sabe y
00:02:41lo que realmente dice la actualización actual. Configurar el MCP solo toma unos pasos. Una vez instalado,
00:02:46utilizó las herramientas de Context 7 y obtuvo la información de la librería directamente. Esto le permite usar
00:02:50la documentación más reciente, evitar errores de código por incompatibilidad de dependencias y lograr una
00:02:55implementación más precisa. Ahora bien, los "hooks" son otra función poco aprovechada. Los hooks en Claude Code
00:03:00son comandos de shell que se ejecutan en puntos específicos del ciclo de vida. Hay muchos tipos que se activan en
00:03:05momentos clave, como al iniciar la sesión, antes de usar una herramienta o después de usarla. Pero lo más importante
00:03:11es configurarlos con códigos de salida específicos. Estos códigos le dicen a Claude Code si debe proceder,
00:03:16bloquear o ignorar una acción. Un código 0 significa éxito. Un código 2 significa un error de bloqueo. Así,
00:03:22siempre que Claude intente hacer algo que no deba, se topará con el código 2, recibirá un mensaje de error
00:03:27y podrá corregirse. Cualquier otro código de salida no bloquea la ejecución, se muestra en modo detallado
00:03:32y el proceso continúa. Este código de salida 2 es fundamental porque permite controlar el
00:03:37comportamiento del agente. Si alguna vez has trabajado en desarrollo guiado por pruebas (TDD) con Claude Code,
00:03:41habrás notado que tiende a modificar las pruebas si no logra superarlas. Para evitar
00:03:46eso, configuramos un hook personalizado que se activa antes del uso de herramientas. El hook protege los scripts de prueba
00:03:50contra modificaciones. Si la ruta en la que intenta trabajar es un directorio de pruebas o contiene la palabra "test",
00:03:55muestra un mensaje de error indicando que no se permiten cambios en carpetas de prueba y devuelve el
00:04:00código de salida 2. Con este hook activo, cuando le pedimos a Claude que ejecutara las pruebas y estas
00:04:05fallaron, intentó modificar los archivos de prueba. Pero el script lo bloqueó y apareció un mensaje de
00:04:10protección contra modificaciones. Esto impidió que Claude editara archivos que no debía. Si has trabajado
00:04:15con MCPs, sabrás que saturan la ventana de contexto. Al trabajar en proyectos a gran escala,
00:04:19el número de MCPs conectados aumenta. Todas las herramientas MCP terminan ocupando espacio en la ventana de contexto
00:04:25y esta se satura. Para solucionar esto exactamente, Claude Code tiene un modo experimental de CLI para MCP.
00:04:31Activamos el indicador experimental de CLI para MCP. Una vez hecho, todos los MCP que aparecían
00:04:36en el contexto desaparecieron y las herramientas MCP dejaron de ocupar espacio. La pregunta era
00:04:41cómo acceder a las herramientas si ya no estaban en la memoria. En lugar de cargar todos los
00:04:45esquemas de herramientas de antemano, Claude Code usa información y llamadas de CLI para MCP y ejecuta todos
00:04:52los MCP conectados a través de estas herramientas mediante bash. Con el indicador activado, al darle un prompt,
00:04:56en lugar de llamar a la herramienta MCP directamente, las llamó vía CLI y las ejecutó como comandos bash en vez de
00:05:03herramientas MCP. Así, solo carga la herramienta necesaria bajo demanda, evitando la saturación del contexto. Además,
00:05:08si les gusta nuestro contenido, consideren pulsar el botón de "hype" porque nos ayuda a crear más
00:05:13vídeos como este y llegar a más gente. En vídeos anteriores, hemos insistido en usar
00:05:18git para que todo el trabajo de los agentes sea rastreado por control de versiones. Así puedes revertir cambios si los agentes
00:05:23no implementan algo correctamente. También publicamos un vídeo usando git para ejecutar un agente en tareas de largo
00:05:28alance que pueden ver en el canal. Usamos agentes paralelos para trabajar en diferentes árboles de trabajo
00:05:32para que pudieran crear todas las funciones del proyecto manteniéndose aislados entre sí.
00:05:37De esta forma, podíamos fusionar sus resultados más tarde sin interferencias, ya que agentes trabajando
00:05:41en los mismos archivos causan conflictos. No preferimos las ramas porque causan conflictos; los agentes tienen
00:05:46dificultades para cambiar de rama dado que comparten el mismo directorio de trabajo, pero los árboles de trabajo no.
00:05:50Así que le dimos un prompt con múltiples funciones a implementar y especificamos que cada agente
00:05:55debía trabajar en un árbol de trabajo separado. Utilizó un agente distinto para cada árbol e implementó
00:05:59las funciones de forma aislada, incluso cuando las descripciones de las tareas se solapaban en ciertos puntos.
00:06:03Después de que Claude implementara todo correctamente en ramas separadas, le pedimos fusionar el resultado
00:06:08para tener todas las funciones en un único directorio de trabajo. Ahora bien, el modo estricto es esencial para trasladar la carga
00:06:13de la verificación de errores al agente. Esto es algo que deberías configurar para cualquier lenguaje que uses,
00:06:18ya que detecta errores al compilar en lugar de cuando los usuarios los encuentran en tiempo de ejecución. Dado que
00:06:22nuestro lenguaje principal es TypeScript, siempre activamos el modo estricto en nuestros proyectos. Esto activa
00:06:26comprobaciones de valores nulos y tipos implícitos, obliga al tipado estricto y, en general, reduce los errores
00:06:31en ejecución. Esto importa para los agentes de IA porque no tienen una forma nativa de detectar fallos en tiempo de ejecución.
00:06:36El modo estricto minimiza los fallos y asegura que el compilador se encargue de estos problemas. Los agentes pueden
00:06:41basarse en los logs de error de la terminal para aplicar soluciones conocidas. En lugar de dejar que el proyecto sea
00:06:46probado solo por scripts, vale la pena añadir una capa adicional de pruebas. Se escriben historias de usuario
00:06:51que describen cómo interactúa el usuario con el sistema para guiar el proceso de prueba una vez
00:06:56construida la aplicación. De hecho, definimos las historias de usuario antes de la implementación porque esto
00:07:00establece un estándar que el desarrollo debe seguir. Usando un prompt, Claude escribió varias historias
00:07:05en una carpeta que contenía todas las formas posibles en que un usuario puede interactuar con el sistema.
00:07:10Cada historia detalla un aspecto de la aplicación, su prioridad y los criterios de aceptación para que el agente
00:07:15realice las pruebas. Las historias cubrieron todos los escenarios, incluyendo casos ideales y casos límite.
00:07:21Estas historias básicamente le dicen a los agentes cómo interactuar con el sistema que acabamos de construir.
00:07:26Con las instrucciones adecuadas, cualquier agente puede aplicar los mismos principios a la aplicación que está
00:07:31creando y satisfacer mejor las expectativas del usuario. Con las historias documentadas, le pedimos a
00:07:35Claude que las implementara una a una, indicándole que empezara por la ruta óptima de cada historia
00:07:40y asegurándose de cubrir todos los casos límite. Así, la implementación tuvo menos vacíos y una
00:07:45mayor satisfacción del usuario final. Todos los consejos que hemos comentado están disponibles en forma
00:07:50de plantillas listas para usar en AI Labs Pro. Para quienes no lo conozcan, es nuestra comunidad
00:07:55recién lanzada donde encontrarán plantillas, prompts, comandos y habilidades que pueden
00:08:00integrar directamente en sus proyectos. Si valoran lo que hacemos y quieren apoyar al canal,
00:08:05esta es la mejor manera. Tienen los enlaces en la descripción. Debemos aprovechar la
00:08:10paralelización al máximo, porque así es como el agente acelera su flujo de trabajo e implementa
00:08:14cosas que no dependen entre sí. Sabemos que Claude detecta automáticamente si una tarea puede ser
00:08:20paralela o secuencial y decide por su cuenta, pero no está de más crear los agentes nosotros mismos.
00:08:25También tratamos estas capacidades en nuestro vídeo anterior, donde hablamos de cómo usar agentes
00:08:29para agilizar el flujo de trabajo, aunque esta velocidad implica un mayor uso de tokens. Aun así,
00:08:34el esfuerzo de paralelización merece la pena. En un momento estábamos investigando el impacto de
00:08:39las mejoras de Opus 4.6 y el modelo seguía alucinando datos pese a tener las fuentes. Escribía
00:08:43información incorrecta y teníamos que corregirlo constantemente. La investigación parecía inútil
00:08:49porque terminábamos arreglándolo todo nosotros. Para evitar que esto se repitiera, usamos agentes paralelos.
00:08:54Configuramos una tarea de investigación para comparar las capacidades de enjambre de agentes de
00:08:58KimiK 2.5 y el enjambre de agentes de Claude. Usamos dos agentes: uno para investigar y otro para
00:09:03verificar los datos del primero. La idea clave era que ambos se comunicaran para asegurar la precisión de los
00:09:09hallazgos y no tener que hacerlo nosotros. En esta configuración, un agente realiza la tarea mientras el otro
00:09:14la analiza críticamente, estableciendo un método de trabajo adversarial. El agente investigador empezó
00:09:19primero y el verificador esperó hasta que hubo un primer borrador. Una vez listo el borrador,
00:09:24el verificador comenzó a revisarlo. Identificó de inmediato muchas inexactitudes en los datos listados
00:09:28por el investigador, eliminando la necesidad de detectarlas manualmente. Ambos agentes mantuvieron la
00:09:33comunicación, haciendo que el proceso de verificación fuera riguroso. Un agente se dedicaba exclusivamente
00:09:38a señalar la información errónea del otro. Hay muchas tareas que se pueden ejecutar con este enfoque
00:09:43adversarial, no solo investigación, sino también desarrollo: un agente implementa una función y
00:09:47otro revisa la implementación respecto al plan. Según el creador de Claude Code,
00:09:52el agente funciona mejor si tiene alguna forma de verificar su propio trabajo. La idea central es
00:09:57darle "ojos" al agente, es decir, la capacidad de comprobar si la función implementada es correcta y
00:10:02cumple las expectativas. Como estos agentes se basan en terminales, no pueden identificar problemas que
00:10:07ocurren en tiempo de ejecución, especialmente en el lado del cliente. Usamos varios métodos para verificar
00:10:12el trabajo del agente. El primero es la extensión de Claude para Chrome, que ofrece herramientas de navegador
00:10:17como captura de DOM, revisión de logs de consola y más. Otra herramienta es el MCP de Puppeteer.
00:10:21Este es útil porque se ejecuta en un navegador independiente que no contiene tus sesiones actuales,
00:10:26a diferencia de la extensión de Chrome. Está aislado y no interfiere con tus sesiones, aportando una
00:10:31capa extra de privacidad. Pero nuestra opción preferida es el navegador de agentes de Vercel. No es un MCP,
00:10:36sino una herramienta de CLI que dota a los agentes de capacidades de prueba de navegador. Incluye herramientas
00:10:41para navegación, capturas de pantalla y más. A diferencia de otras herramientas, no navega solo mediante
00:10:46capturas, sino que utiliza el árbol de accesibilidad donde cada elemento tiene una referencia única. Esto
00:10:51compacta el DOM completo de miles de tokens a unos 200 o 400, siendo mucho más eficiente. Ese era el
00:10:56problema principal de la extensión de Claude para Chrome que el navegador de agentes solucionó, ya que aquella
00:11:01carga todo el DOM en la ventana de contexto y la agota rápidamente. También añadimos instrucciones en
00:11:07Claude.md para que Claude priorice el navegador de agentes antes de recurrir a pruebas basadas en MCP.
00:11:12Así, Claude lo usa como método principal de verificación. Pero hay otro enfoque: probar es importante,
00:11:17pero existe una forma de reducir errores que no implica tests ni revisiones de código. Le pedimos a Claude que
00:11:23prediga sucesos que aún no han ocurrido. Le pedimos revisar la implementación e identificar áreas
00:11:28donde la aplicación podría fallar. Esto funciona porque le damos a Claude la oportunidad de predecir problemas
00:11:33comparando patrones de fallos que ya existieron en otras apps, aunque no los hayamos detectado
00:11:38nosotros mismos en las pruebas. Obliga a Claude a mirar el código desde un ángulo distinto.
00:11:43Al pedírselo, identificó brechas críticas que superaron nuestro proceso de pruebas de múltiples capas
00:11:47y halló 18 problemas que habrían sido dañinos en producción. Nuestras pruebas no los detectaron.
00:11:52Solo pudieron identificarse al empujar a Claude a analizar el proyecto desde otra perspectiva.
00:11:57Esto nos lleva al final de este vídeo. Si quieren apoyar al canal y ayudarnos a seguir creando
00:12:01vídeos como este, pueden hacerlo mediante el botón de "super thanks" de abajo. Como siempre,
00:12:06gracias por vernos y los espero en el próximo vídeo.
00:12:10channel and help us keep making videos like this you can do so by using the super thanks button
00:12:15below. As always thank you for watching and I'll see you in the next one.