Escribir código, eso ya lo hace la IA por ti. Pero revisarlo, eso aún recae sobre tus hombros.
Si un código está bien escrito o no, la IA no se hace responsable, al final tienes que revisarlo línea por línea tú mismo: este obstáculo ha atascado a mucha gente.
Recientemente, Anthropic también ha integrado la verificación por IA en el ciclo.
Han hecho que Claude, después de escribir el código, no lo entregue directamente, sino que continúe ejecutando cuatro comprobaciones:
/code-review para detectar bugs primero, /simplify para limpiar la implementación redundante, /verify para hacer una verificación de extremo a extremo, y si esta vez se modificó la interfaz, usar /design para verificar el aspecto visual contra DESIGN.md.
Después de pasar estas cuatro comprobaciones, se considera entregado.
El 22 de julio, el equipo de Claude Code hizo público este "ciclo de verificación" interno.
En otras palabras, después de que Claude escribe el código, primero busca errores por sí mismo, los corrige hasta que no haya problemas y luego vuelve a buscarte.
Esto significa que la IA ha comenzado a evolucionar desde "saber escribir código" hasta "saber verificar el código que escribe".
El ciclo de trabajo del agente inteligente, ahora incluye una verificación
Anthropic le ha dado un nombre a esto: ciclo de verificación (verification loop).
La definición oficial es simple: es un proceso iterativo en el que Claude verifica e intenta corregir su propio trabajo.
Lo que modifica es el ciclo de trabajo del agente inteligente.
Antes era "recopilar contexto → ejecutar acción → verificación manual", donde el último paso recaía en la persona: la IA entregaba el trabajo y tú tenías que revisarlo línea por línea.
Ahora esta línea se ha alargado a "recopilar contexto → ejecutar acción → verificación automática → corrección → nueva verificación". La verificación y la corrección se han reintegrado en el ciclo.
Diagrama del ciclo del agente inteligente oficial de Anthropic: después de recibir la instrucción, Claude recopila el contexto, ejecuta la acción, verifica el resultado; si la verificación falla, se devuelve para volver a ejecutar, y solo se devuelve si pasa.
Algunas comprobaciones Claude ya las hace. Señales deterministas en el repositorio de código, como el verificador de tipos, el linter, ejecutar pruebas, errores en tiempo de ejecución, puede leerlos y también corregirlos sobre la marcha.
Lo realmente problemático es otro tipo: si la interfaz se modificó correctamente, si el flujo del usuario es fluido, si este cambio ha dejado fallos ocultos...
Esto antes solo podía confiarse a la supervisión humana, realizando las mismas comprobaciones docenas o cientos de veces.
La solución de Anthropic es escribir una a una esas comprobaciones que siempre tienes que hacer manualmente, encapsularlas en Skills y dárselas a Claude para que las ejecute automáticamente en cada tarea.
En las últimas décadas, todos los procesos de ingeniería de software: escribir requisitos, planificar, revisiones por capas, interminables reuniones, en esencia se deben a que: escribir código es demasiado lento, el tiempo de los ingenieros es demasiado valioso.
Pero cuando la IA hace que escribir código sea más rápido y barato, esta premisa deja de existir.
El propio juicio del equipo de Claude Code es: el cuello de botella no ha desaparecido, solo se ha trasladado: de "escribir código" a la verificación, revisión de código, seguridad y otros aspectos.
El código se genera demasiado rápido, y el nuevo problema se convierte en si ese código es correcto, quién lo mantiene y si las personas pueden seguir el ritmo de revisar el código.
Ante este nuevo cuello de botella, el equipo de Claude Code primero experimentó consigo mismo.
Los 4 Skills de autoverificación que el equipo de Claude Code usa diariamente
Internamente, el equipo de Claude Code usa diariamente estos cuatro Skills de autoverificación.
/code-review, revisa específicamente los cambios en el código, detecta posibles bugs y, de paso, da una opinión de revisión.
Esto equivale a tener un revisor incansable a tu disposición.
/simplify, limpia el diff de esta modificación, elimina implementaciones complejas y enrevesadas, haciendo la estructura más simple.
No añade funciones, sino que elimina redundancias, simplifica la implementación, reduciendo los costes de mantenimiento futuros.
Esto es muy importante y demuestra gran habilidad. La mayoría de la gente escribe código acumulando, una herramienta que activamente hace reducción es especialmente valiosa.
/verify, realiza una verificación de extremo a extremo, la ejecuta de verdad, confirmando que la funcionalidad realmente se ha completado, y no solo "parece completada".
/design, solo entra en acción cuando se modifica la interfaz de usuario. Verifica punto por punto contra el DESIGN.md en el repositorio si tu implementación visual se ha desviado.
Estos 4 Skills no han surgido de la nada.
En su base, Claude Code ya ha establecido una capa de soporte de verificación lista para usar:
El /verify incorporado puede ejecutar la aplicación para observar cambios, tú escribes claramente los comandos de construcción y prueba en CLAUDE.md, y él los ejecuta; también hay Code Review específico para revisiones multiagente en PRs, y GitHub Actions que se disparan automáticamente en cada commit.
Los 4 Skills del equipo equivalen a añadir su propio proceso adicional sobre esta base genérica.
¿Cómo escribir tu propio Skill de verificación?
El método que da Anthropic también es simple:
Escribe con palabras sencillas ese paso que siempre tienes que hacer manualmente, como si le estuvieras explicando las precauciones a un nuevo compañero en su primer día.
Si te atas incluso al describir cómo debe ser esta comprobación, primero puedes pedirle a Claude que dé una versión de mejores prácticas genéricas y luego modificarla.
Es muy probable que tu versión difiera de la práctica genérica en algunos puntos, y esas diferencias son precisamente lo que más debe registrarse.
La verificación tampoco tiene que ser necesariamente un juicio vago como "sentir si está bien".
Por ejemplo: cualquier cambio que elimine un campo de la base de datos pero no tenga pasos de migración de datos asociados, será rechazado. Esta es una "regla local" que un linter genérico nunca captará, pero es exclusiva de tu proyecto.
Cualquier línea roja que solo hayas podido mantener mediante supervisión manual, merece la pena escribirla como un ciclo.
¿Y después de escribirla?
Dásela a skill-creator para que te haga algunas preguntas inversamente, o simplemente añade un archivo Markdown en .claude/skills/.
El Skill de verificación más simple son unas pocas líneas de explicación y un párrafo de texto. Luego llámalo en una nueva tarea, confirma que esta comprobación realmente se ejecuta, y si no, corrígelo.
Para esos Skills que no puedes modificar, como los incorporados o gestionados por plugins, también hay una solución: escribe un Skill envoltorio (wrapper) que llame primero al original y luego a tu verificación. Rodéalo, e igualmente integra la comprobación.
La verificación no es de talla única, tiene 4 niveles
Después de encapsular la comprobación en un Skill, la siguiente pregunta es: ¿cuándo se activa esto?
Anthropic da 4 niveles de automatización, de más flexible a más estricto.
Standalone: Tú mismo lo recuerdas y lo llamas manualmente.
Embedded: Integrado en el flujo de una tarea, se ejecuta junto con ella.
Chained: Varios Skills de verificación encadenados en una cadena, se ejecutan automáticamente uno tras otro.
On every PR: El nivel más duro, cada vez que se envía código pasa automáticamente por él.
La transición intermedia, oficialmente la llaman "del hábito al contrato".
Lo que antes era el hábito personal de "siempre recuerdo ejecutar /verify después de /simplify", después de encadenarlo, se convierte en el contrato fijo de "después de ejecutar /simplify, automáticamente se llama a /verify".
Toda la cadena recorre el ciclo de desarrollo por sí misma, y solo vuelve a buscarte cuando necesita tu aprobación.
Cuanto más larga es la cadena, mayor es la fiabilidad, pero oficialmente advierten específicamente: la verificación en cadena consume tokens de verdad.
Así que no establezcas desde el principio todas las comprobaciones como puerta de PR, que bloquee cada envío. La postura correcta es primero ver si es estable, y luego añadir gradualmente.
Detrás de los 4 Skills, la programación con IA está cambiando de carril
Detrás de los 4 Skills, la competencia en programación con IA está pasando de la generación a la verificación.
El padre de Claude Code también ha dado el mismo juicio.
El 9 de junio de este año, tuiteó: En la era en que los modelos potentes pueden ejecutarse de forma autónoma durante largos periodos, la autoverificación es clave para que el modelo se ejecute durante más tiempo y los resultados se acerquen más a tus expectativas: no tienes que estar frecuentemente supervisando a Claude, y puedes confiarle más trabajo.
En pocas palabras, cuanto más sólida sea la verificación, más libertad tendrá el agente para ejecutarse; cuanto más tiempo se ejecute, más tranquila estará la persona.
Antes confiábamos en las instrucciones (prompts), pero también tienen un límite: solo resuelven la tarea de esta vez, la próxima hay que empezar de nuevo.
Aquí primero corrijamos un malentendido común: un Skill no es un prompt en Markdown.
Es un módulo de capacidad, que contiene instrucciones, estructura de archivos, scripts, llamadas a herramientas, configuración y un conjunto completo de flujos de trabajo. Es la sedimentación de los pasos de verificación del equipo, normas de diseño, errores cometidos, en un paquete disponible a demanda, que Claude consulta por sí mismo cuando lo necesita.
Lo más crucial es que los Skills están pasando de ser una característica de Claude Code a un estándar abierto entre fabricantes.
Según el análisis de la industria, GitHub Copilot, Cursor, OpenAI Codex, Gemini CLI ya han adoptado el mismo formato.
Esto significa que los Skills que sedimentas para tu equipo no quedarán encerrados en una sola herramienta, sino que sedimentarán la experiencia, normas y procesos de verificación del equipo, convirtiéndose en una capacidad reutilizable.
Esto también lleva a una realidad punzante: el mismo Claude, utilizado por diferentes equipos, puede tener una eficiencia varias veces diferente. La causa de esta diferencia no está en el modelo, sino en el flujo de trabajo:
Si has escrito las comprobaciones como Skills, si has establecido ciclos de verificación, si has hecho que el agente inteligente cierre él mismo el ciclo de retroalimentación.
En definitiva, la capacidad del agente inteligente es una suma: modelo, más herramientas, más mecanismo de verificación, más flujo de trabajo.
El modelo, en este aspecto, cada vez es más similar entre todos. Lo que realmente marca la diferencia son los otros tres aspectos, y todos ellos están en manos del usuario.
Por supuesto, lo que muestra este blog es la optimización del flujo de desarrollo asistido por IA, no que "la IA ya pueda escribir software de forma independiente". Aún depende de los ingenieros y no puede hacer entregas a nivel de producción sin intervención humana.
Por lo tanto, no es que los agentes inteligentes vayan a quitar el trabajo a los ingenieros humanos, pero la dirección ya es clara.
Antes, siempre estábamos enseñando a la IA cómo escribir código, ahora hay que empezar a enseñarle a verificar si lo que escribe está bien.
Para alguien que usa la IA a diario para escribir código, el día en que finalmente pueda confiar con tranquilidad a la IA esa tarea de "tener que revisar manualmente antes de salir del trabajo", entonces realmente comenzará a hacer el trabajo por ti.
Referencias:
https://claude.com/blog/building-verification-loops-in-claude-code-with-skills
https://claude.com/blog/getting-started-with-loops?utm_source=chatgpt.com
Este artículo proviene del WeChat público "新智元" (Nueva Era de la Inteligencia), autor: ASI启示录
