A vos que programás seguro te pasó: le pedís a Claude Code que te resuelva una función, la pegás en el proyecto, corre en local sin errores y pensás que ya está. Pero después aparece un bug rarísimo en producción, algo que ni vos ni la IA vieron venir, y ahí perdés horas tratando de entender qué pasó con un código que técnicamente "no escribiste vos" pero ahora tenés que arreglar igual.
El problema de fondo no es que las herramientas de IA para programar sean malas. Es que la mayoría de los devs las usa sin ningún proceso de control. Se le pide algo a Claude, sale una respuesta que compila, y listo, se hace merge. Pero que algo compile no es lo mismo que esté bien hecho, y ahí es exactamente donde entran los loops de verificación que Anthropic explicó hace poco.
El problema de aceptar código de la IA sin revisarlo
En equipos chicos, típicos de muchas empresas de software en Argentina, no siempre hay un QA dedicado ni tiempo para hacer code review línea por línea de todo lo que genera una IA. Y ahí es donde se filtran errores que después cuestan caro, sobre todo cuando el proyecto crece y nadie recuerda bien qué parte escribió una persona y qué parte escribió la IA.
Los problemas más comunes no son errores de sintaxis, esos los agarra el compilador. Son fallas más sutiles, que pasan los tests superficiales pero rompen en casos reales de uso.
- Código que compila pero rompe con un caso borde que nadie probó, como un array vacío o un usuario sin permisos
- Funciones que dependen de una librería o versión que no existe en el proyecto real
- Tests que la IA "dice" haber corrido, pero que en realidad no ejecutó
- Código que funciona pero no respeta la arquitectura o las convenciones del resto del proyecto
- Commits gigantes, difíciles de revisar a mano, que mezclan varias cosas a la vez
Qué son los loops de verificación en Claude Code
El 22 de julio, Anthropic publicó en su blog cómo armar loops de verificación en Claude Code usando Skills. La idea central es simple de entender: en vez de pedirle a Claude que escriba código y confiar a ciegas, se lo configura para que revise y verifique su propio trabajo contra criterios definidos antes de darlo por terminado.
En la práctica, esto cambia el orden de las cosas. Claude ya no entrega una respuesta y espera que vos la chequees entera. Primero corre su propia verificación, y solo te avisa cuando el trabajo cumple con lo que se definió como "terminado". Esto no elimina la necesidad de que un humano revise, pero reduce muchísimo la cantidad de idas y vueltas.
- Definir criterios de aceptación claros antes de empezar: que compile, que pasen los tests existentes, que respete el estilo del proyecto
- Armar una Skill que le indique a Claude exactamente cómo verificar esos criterios, paso por paso
- Pedirle que corra esa verificación antes de marcar cualquier tarea como terminada
- Si algo falla, que itere y corrija solo, en vez de simplemente avisarte que algo no anduvo
Cómo empezar a aplicar esto en tu día a día
No hace falta armar un sistema perfecto desde el primer día. Podés arrancar con una sola Skill de verificación para el tipo de tarea que más se repite en tu trabajo, por ejemplo, revisar que cualquier endpoint nuevo tenga manejo de errores y un test asociado. Con eso ya vas a notar menos revisiones manuales innecesarias.
Si trabajás como freelancer o en un equipo chico, esto es particularmente útil porque hace de "segundo par de ojos" cuando no hay presupuesto para un QA de tiempo completo. Y si mantenés código legado, ayuda a que la IA no rompa cosas que ya funcionaban, porque el criterio de verificación puede incluir explícitamente no tocar ciertas partes sensibles del sistema.
Otra ventaja poco obvia es que documentar los criterios de verificación te obliga, a vos como programador, a ser más explícito sobre qué significa "terminado" en tu propio proyecto. Muchas veces esa definición vive solo en tu cabeza o se discute de palabra en una reunión y se olvida. Convertirla en algo que la IA puede chequear automáticamente termina ordenando también el trabajo humano del equipo, no solo el de la máquina.
Día 29 del curso de ArtiLearn: Claude Code paso a paso
En el curso de 30 días de ArtiLearn, el día 29 está dedicado justamente a Claude Code, con apenas 15 minutos de práctica guiada. Ahí se ve paso a paso cómo configurar este tipo de flujos de trabajo, incluyendo cómo armar tus primeras Skills de verificación, sin necesidad de ser un experto en IA para arrancar.
Los loops de verificación no son un lujo técnico, son una forma concreta de que la IA deje de ser una fuente de sorpresas en tu código. Cuanto antes empieces a definir esos criterios, menos tiempo vas a perder revisando a mano lo que la máquina ya podría haber chequeado por vos.