Antes de que el código generado por un agente se envíe a producción, deben cumplirse sin excepción las siguientes condiciones: la suite de pruebas pasa con éxito, los análisis de lint y tipos son correctos, el diff respeta el tamaño y alcance estipulados en el plan, el proyecto compila íntegramente, el escaneo de seguridad no detecta nuevas vulnerabilidades y un ingeniero humano ha revisado y aprobado el diff. Cada una de estas etapas es una puerta de verificación (verification gate): un control que debe superarse obligatoriamente antes de que el trabajo avance a la siguiente fase. Existe una puerta adicional que se ejecuta antes de escribir una sola línea de código: la aprobación humana del plan. Esta es la que más dinero ahorra, porque un plan rechazado a tiempo cuesta exactamente cero en ejecución. Este artículo define el concepto de puerta, detalla las que verdaderamente importan para el código de agentes y explica cómo las implementa Ivy Tendril.

Qué es una puerta de verificación

Una puerta es una condición estricta asociada a la transición entre dos fases. El trabajo en la fase N no puede acceder a la fase N+1 hasta que dicha condición se satisfaga plenamente. La condición debe evaluarse con idéntico rigor cada vez, y su resultado debe quedar registrado de forma auditable para revisiones posteriores.

Tres propiedades esenciales distinguen a una puerta de una simple sugerencia:

Es bloqueante. Una puerta que falla detiene inmediatamente la transición. Una comprobación cuyo resultado adverso solo actúa a modo de advertencia es un informe, no una puerta.
Es automática o explícita. Bien la evalúa de forma objetiva un programa (pruebas, linter, compilación), o bien una persona identificada toma una decisión registrada formalmente (revisión de código). «Alguien probablemente le echó un vistazo» no cumple ninguno de los dos casos.
Cuenta con una ruta de resolución de fallos definida. Cuando la puerta falla, el trabajo se redirige a un destino concreto: de vuelta al agente, de vuelta al plan o a un revisor humano. El código que suspende un control y queda flotando en tierra de nadie es la causa más frecuente de pérdida de trabajo en entornos de agentes.

El código redactado por humanos también atraviesa puertas: integración continua y revisión de pull requests. La diferencia radical con los agentes radica en el volumen. Cuando un solo desarrollador puede abrir veinte pull requests al día, la revisión humana se convierte en el cuello de botella más crítico. Por ello, las puertas previas a la revisión deben descartar tantos errores como sea posible antes de que un ingeniero lea el diff. En Patrones de orquestación de agentes se describe cómo se articula la verificación junto a las colas de trabajo, el aislamiento y los costes.

Las puertas críticas para el código generado por agentes

Puerta	Qué comprueba	Qué significa habitualmente un fallo
Aprobación del plan	Un humano ha leído el plan y validado el enfoque técnico y el alcance	La tarea estaba mal especificada o la estrategia técnica es errónea
Pruebas (Tests)	Las pruebas existentes pasan; el nuevo comportamiento está cubierto	El agente rompió funcionalidad previa o no añadió pruebas para sus cambios
Lint y verificación de tipos	El código respeta las normas del proyecto y compila sin errores	Violación de reglas, código muerto o errores de tipos introducidos al intentar pasar los tests
Tamaño y alcance del diff	Los archivos modificados coinciden con el plan; el diff es revisable	El agente alteró archivos ajenos al plan o refactorizó código no relacionado
Compilación (Build)	El proyecto completo compila desde la rama	Algo funciona de forma aislada pero falla al integrarse con el resto
Escaneo de seguridad	Sin nuevos secretos expuestos, dependencias vulnerables o patrones vetados	El agente introdujo credenciales, una dependencia insegura o una llamada no permitida
Aprobación del diff	Un humano ha revisado minuciosamente el diff y lo ha autorizado	Todo lo que las puertas automatizadas no pueden juzgar: intención, diseño, legibilidad

Las seis primeras se ejecutan antes de requerir la intervención humana: la puerta del plan opera antes de la ejecución y las restantes se evalúan de forma aislada en el worktree del agente tras concluir su labor. Dos de ellas merecen una mención especial.

Los riesgos inherentes al código generado por modelos de IA —manejo inseguro de salidas, dependencias peligrosas en la cadena de suministro, credenciales filtradas— están minuciosamente catalogados en el OWASP Top 10 for LLM Applications, constituyendo una lista de referencia idónea para lo que el escaneo de seguridad debe auditar.

El tamaño y alcance del diff es la puerta que los equipos omiten con mayor frecuencia, a pesar de ser mucho más crítica para agentes que para desarrolladores humanos. A un agente al que se le pide corregir una comprobación de nulos a menudo se le ocurre también reformatear el archivo entero, renombrar variables y modificar llamadas en tres lugares adyacentes. Juntas, estas alteraciones transforman una revisión ágil de 10 líneas en un diff inmanejable de 300 líneas. Una puerta de alcance compara los archivos y módulos tocados con lo pactado en el plan y reporta cualquier discrepancia.

El escaneo de seguridad intercepta secretos en texto claro, vulnerabilidades en librerías y patrones de código no autorizados. Dado que los agentes replican patrones del entorno circundante, un repositorio que contenga un patrón inseguro tenderá a propagarlo con rapidez.

Por qué el punto de control del plan evita ejecuciones inútiles

Todas las puertas posteriores a la ejecución comparten una desventaja económica: cuando fallan, los tokens y el dinero ya se han gastado. Las pruebas, el linter, la compilación y los escaneos te informan de que la ejecución ha ido mal. Solo la puerta del plan te lo advierte antes de incurrir en el gasto.

Observemos lo que detectan las puertas posteriores: un fallo de tests porque el agente interpretó mal el requerimiento es, en el fondo, un fallo de plan. Un fallo de alcance porque el agente modificó módulos no solicitados es un fallo de plan. Un fallo de build porque el plan modificó un paquete sin prever el impacto en sus dependientes es un fallo de plan. En cualquiera de estos supuestos, un revisor leyendo un plan estructurado durante dos minutos lo habría detectado a tiempo, con un coste de ejecución exactamente igual a cero.

Por esta razón, el flujo de fábrica de software —la denominación de Ivy para la secuencia reproducible de planificar, ejecutar, verificar y revisar— incluye exactamente dos puntos de control humanos, colocando uno de ellos antes de que exista código alguno. En el punto de control del plan se deciden el alcance, la arquitectura y la secuencia de trabajo. En el punto de control del diff se convalida la exactitud del resultado. Todo lo que ocurre entre ambos pasos es enteramente automático.

Cómo gestiona Ivy Tendril las puertas de verificación

Ivy Tendril es una aplicación de escritorio local-first (macOS, Windows, Linux) que guía las tareas desde el plan conceptual hasta la pull request revisada. Los dos puntos de control humanos y las puertas automáticas intermedias están integrados orgánicamente en su ciclo de vida. Consulte la documentación de la aplicación Review para examinar la interfaz.

Puerta del plan. Un plan comienza en estado de borrador (Draft). El desarrollador lo examina y puede ampliarlo (Expand), dividirlo (Split), actualizarlo (Update) o añadir notas directamente en el texto para que el plan se reescriba. La ejecución nunca arranca sin la aprobación explícita del plan.
Ejecución aislada. Cada plan se ejecuta en su propio git worktree sobre una rama independiente, asegurando que la verificación se realice exclusivamente sobre los cambios de ese plan y nada más. En Git worktrees para agentes de IA paralelos se detalla por qué este aislamiento hace que las puertas sean fiables.
Pestañas de verificación. Al término de la ejecución, la aplicación Review presenta los tests, el lint y el diff en pestañas separadas, permitiendo al revisor evaluar las tres dimensiones antes de resolver.
Importación de CI en planes Pro. Los equipos que ejecutan sus puertas en entornos de CI —como GitHub Actions o herramientas análogas— pueden importar los resultados en la aplicación Review bajo el plan Pro, evitando saltar entre interfaces externas.
Ruta de resolución de fallos. Cuando falla una verificación, la tarea regresa de inmediato al agente acompañada del informe detallado del error. El agente recibe la salida real de los tests o del linter —no un resumen aproximado— y repite el proceso en el mismo worktree. La sección Jobs transmite en streaming la salida y las llamadas a herramientas del agente en tiempo real.
Puerta del diff. Solo cuando la verificación técnica concluye con éxito y un humano aprueba el diff, Tendril procede a abrir la pull request. Ninguna línea de código se publica sin contar con ambas autorizaciones.

El coste se monitoriza por plan y por cada job individual. De este modo, un plan que requirió tres intentos revela con exactitud el gasto de las reejecuciones, aportando los datos necesarios para juzgar si el plan debió ser más estricto desde el inicio.

Cómo empezar

Registre por escrito sus puertas actuales: la mayoría de los equipos constata que realiza pruebas y code review, y que el linter se ejecuta en algún lugar pero nadie tiene la certeza de si bloquea el avance.
Instale Tendril: curl -sSf https://cdn.ivy.app/install-tendril.sh | sh (macOS, Linux) o irm https://cdn.ivy.app/install-tendril.ps1 | iex (Windows). Instrucciones en instalación.
Ejecute un primer plan a través del ciclo completo y examine las pestañas de pruebas y linter antes de abrir el diff. Valore qué detalles se le habrían escapado de haber leído únicamente el diff.
Incorpore una comprobación de alcance a su revisión de planes: ¿concuerda la lista de archivos que el agente tiene permitido tocar con el contenido del plan?

Tendril es gratuito y con código disponible bajo la Functional Source License. La importación de verificaciones de CI, herramientas para equipos, despliegue local (on-premise) y SSO forman parte de los planes Pro y Enterprise.

Preguntas frecuentes

¿Deben las puertas de verificación bloquear automáticamente o solo informar al revisor?

Las pruebas, el linter, los análisis de tipos y la compilación deben bloquear de forma obligatoria; ningún revisor debería malgastar su tiempo en un diff que ni siquiera compila. Las alertas de alcance y seguridad deben presentarse al revisor con la potestad de aceptarlas, ya que en ambas pueden existir excepciones operativas legítimas.

¿Cuántos reintentos debe tener un agente cuando suspende la verificación?

Establezca un límite numérico estricto y regístrelo. Los fallos sistemáticos de verificación suelen ser un problema del plan, no de la ejecución; devolver el trabajo a la etapa de diseño de planes es preferible a pagar por un quinto intento fallido. El seguimiento de costes por tarea evidencia el gasto real de los reintentos.

¿Sigue siendo necesaria la revisión humana del diff si se superan todas las puertas automáticas?

Sí, rotundamente. Las puertas automatizadas verifican únicamente lo que puede formalizarse por adelantado. No evalúan si el cambio satisface la verdadera intención del ticket, si la arquitectura será sostenible en el tiempo ni si el plan original era adecuado. Por esa razón, el punto de control del diff constituye una de las dos puertas humanas irrenunciables.

Primeros pasos con Ivy Tendril

¿Listo para la orquestación paralela de agentes a nivel de desarrollador?

Explora el código: Conoce Ivy Tendril en GitHub (Código abierto).
Consulta la documentación: Encuentra guías de integración en tendril.ivy.app.
Agenda una sesión técnica: Contacta a renco@ivy.app para una consulta de arquitectura de 30 minutos.

Puertas de verificación: qué debe cumplirse antes de enviar código de agentes a producción