Generated Code Verification
Generated Code Verification es la práctica de reunir e interpretar evidencia pertinente para establecer confianza justificada en que un cambio de software asistido por IA satisface los requisitos y restricciones de su tarea concreta. La unidad examinada es el cambio situado: una revisión determinada, bajo condiciones conocidas y frente a expectativas identificables. El origen automatizado del código no modifica esas obligaciones de ingeniería.
En el Atlas, el término no promete una demostración formal ni ausencia universal de defectos. Pregunta qué se puede sostener sobre este resultado y con qué límites. Que el agente diga “terminé”, complete un plan o produzca un diff no responde esa pregunta. La verificación puede concluir que una parte está respaldada y otra permanece incierta, sin convertir incertidumbre en éxito ni ocultarla como detalle operativo.
El cambio y las expectativas
Repository Exploration and Task Framing identifica intención, alcance y restricciones. Specification-Assisted Development puede conservar el contrato pertinente. La verificación conecta esas expectativas con el cambio real y sus efectos. Si el encargo solicita preservar compatibilidad, comprobar solo que la versión nueva compila deja una parte importante sin evidencia.
También importa identificar la revisión examinada. Una suite ejecutada antes de una modificación posterior no describe automáticamente el estado final. Una integración puede cambiar comportamientos aunque los incrementos separados hayan pasado sus checks. La evidencia necesita suficiente procedencia para saber qué código, datos y entorno representa. No exige registrar cada detalle del sistema si no afecta la interpretación.
Un requisito ambiguo no se resuelve observando qué resultado produce la implementación. El agente puede señalar alternativas y aportar evidencia, pero una decisión de negocio pendiente necesita la autoridad apropiada. Verificar fielmente un supuesto equivocado puede producir consistencia interna y un resultado inadecuado para el usuario. La confianza debe estar referida a expectativas explícitas, no a una intención imaginada por el modelo.
Task-Specific Evidence and Acceptance
La selección de evidencia depende del riesgo y de lo que cambia. Compilación y tipos pueden descartar ciertas incompatibilidades; tests unitarios pueden examinar reglas localizadas; integración y recorridos end-to-end pueden observar fronteras y comportamientos completos. Análisis estático, inspección manual y checks de seguridad o rendimiento aportan otras perspectivas cuando la tarea las necesita. No existe una checklist universal que deba ejecutarse íntegra para cualquier edición.
Una migración puede requerir comprobar conservación e interpretación de datos, además de construir el programa. Un cambio de permisos puede requerir casos permitidos y rechazados. Una corrección documental puede necesitar verificar afirmaciones y referencias, sin agregar tests de código irrelevantes. Testability explica por qué arquitectura, control y observación condicionan la calidad de esa evidencia.
La aceptación se relaciona con la intención y las condiciones acordadas. Un comando exitoso responde según el contrato de esa herramienta, no según todos los criterios del encargo. El build puede ser un gate necesario sin ser suficiente. A la inversa, un warning conocido puede ser compatible con los criterios del proyecto. El agente debe respetar esos acuerdos y explicar resultados sin redefinir el gate para conseguir una entrega verde.
La trazabilidad puede ser breve: expectativa, evidencia obtenida y límite relevante. No hace falta inventar una plataforma de métricas para una tarea pequeña. Sí conviene poder explicar qué afirmación respalda cada check y qué parte del resultado queda sin comprobar. La autoridad de aceptación pertenece al proceso vigente; esta práctica no impone aprobación humana adicional para toda acción ya autorizada.
Testing y generación de tests
Testing aporta evidencia mediante pruebas, con los límites de sus oráculos, escenarios y entornos. La verificación pregunta si el conjunto de evidencias justifica el resultado de la tarea. Una suite puede estar incompleta, contener expectativas incorrectas o ejercitar otro recorrido. “Todos los tests verdes” solo puede interpretarse conociendo cuáles fueron ejecutados y qué cubren respecto del cambio.
AI-Assisted Test Generation produce o adapta pruebas y fixtures. Generarlas no demuestra que se descubran, compilen o ejecuten. Para contribuir a la verificación necesitan ser pertinentes y tener expectativas justificadas. Si el agente escribe implementación y tests desde la misma regla equivocada, ambos pueden coincidir sin satisfacer la necesidad real.
También puede ser razonable no agregar tests nuevos cuando el riesgo es bajo y otra evidencia es más apropiada. La verificación no se mide por volumen de archivos ni por ejecutar repetidamente una suite sin relación con la incertidumbre. Una prueba pequeña que distingue el fallo relevante puede aportar más que muchas comprobaciones que reproducen la estructura interna del código.
Revisión como contribución
AI-Assisted Code Review inspecciona un cambio y puede encontrar defectos, incompatibilidades o vacíos de evidencia. Esa observación puede orientar una nueva comprobación o sostener una conclusión localizada. La revisión no constituye automáticamente evidencia suficiente de todo el comportamiento ni reemplaza las condiciones de aceptación de la tarea.
Una revisión que resume el diff sin contrastar requisitos aporta orientación, pero todavía no demuestra conformidad. Un comentario sin escenario concreto puede ser una pregunta válida y no un defecto confirmado. Al integrar sus resultados, interesa conservar esa diferencia. Convertir cada sugerencia del revisor en certeza puede introducir cambios innecesarios; ignorar un hallazgo sustentado porque los tests pasan también debilita la evaluación del resultado.
Self-Verification
Self-verification ocurre cuando el agente productor comprueba su propio trabajo. Puede detectar errores de sintaxis, contratos olvidados o modificaciones accidentales antes de la entrega. Permite ciclos rápidos de feedback y no debe descartarse como inútil. Su límite es que puede compartir las premisas y puntos ciegos que produjeron el cambio.
El agente puede ejecutar una herramienta independiente en ciertas dimensiones mientras conserva un oráculo compartido en otras. Un compilador no necesita aceptar el relato del modelo para detectar un tipo incompatible, pero no decide si el descuento aplicado corresponde a la política comercial. Por eso la independencia no es una propiedad absoluta de una sesión o una lista de herramientas; se analiza respecto del error que se quiere detectar.
Una autoevaluación responsable contrasta el resultado con el encargo y el diff real. No cambia silenciosamente expectativas para hacerlas coincidir con lo implementado ni presenta como ejecutado lo que solo estaba planificado. Si encuentra una discrepancia, puede corregir dentro del alcance autorizado o señalar la decisión que falta. Repetir “revisá cuidadosamente” no agrega evidencia por sí solo.
Independent Verification
La verificación independiente utiliza evidencia con dependencias de fallo significativamente diferentes de las que generaron el resultado. Puede provenir de una suite mantenida separadamente, análisis estático, una integración externa, revisión humana o un contexto de agente diferente. No requiere necesariamente otra persona, otro modelo o un proveedor distinto; tampoco esas diferencias garantizan independencia.
Lo importante es qué supuesto puede cuestionar la evidencia adicional. Dos modelos que reciben el mismo ejemplo erróneo pueden reproducir el mismo resultado. Una revisión humana que solo lee el resumen del autor también puede heredar esa premisa. En cambio, un contrato externo y una prueba que lo ejerce pueden detectar una incompatibilidad que el proceso generador no estaba considerando.
La independencia tiene un costo y debe ser proporcional al riesgo. No hace falta duplicar íntegramente toda tarea. Puede bastar una comprobación específica de la frontera que concentra la incertidumbre. El criterio es diversificar la evidencia relevante, sin presentar cantidad de revisores o marcas de herramientas como un indicador automático de corrección.
Ejemplo: una actualización parcial
Un agente modifica un endpoint para conservar campos omitidos de una solicitud. El build confirma que el programa se construye. Un test del mapper puede mostrar que omitir el teléfono preserva su valor. Todavía interesa saber si el contrato distingue ausencia de un campo de un valor explícitamente vacío y si la persistencia real mantiene esa diferencia.
Si el test deriva sus expectativas copiando el mapper nuevo, puede compartir su error. Una prueba de integración contra la semántica acordada aporta otra perspectiva. Si un cliente existente envía campos vacíos como reemplazo completo, hay además una restricción de compatibilidad que la comprobación local no cubre. El equipo puede resolver la transición o limitar el alcance, dejando claro qué comportamiento queda respaldado.
El ejemplo no prescribe una batería fija. Muestra cómo cada evidencia responde una pregunta diferente y por qué su combinación necesita interpretación. Un resultado satisfactorio de una herramienta no elimina las preguntas que nunca se le plantearon.
Evidence-Based Completion and Review
Una entrega basada en evidencia distingue qué cambió, qué se comprobó, qué pasó, qué falló, qué no se ejecutó y qué permanece incierto. Los Development Context and Execution Records conservan esa información con procedencia suficiente. No se necesita publicar razonamiento privado ni una transcripción interna del modelo para explicar decisiones y resultados observables.
Completion puede describir que el agente terminó su ejecución o produjo el artefacto solicitado. Evidence-based completion vincula la afirmación de cumplimiento con resultados pertinentes. Alcanzar un límite de tiempo, terminar un plan o cerrar comentarios no demuestra por sí mismo que el objetivo quedó satisfecho. Si hay trabajo parcial, informarlo con precisión permite decidir cómo continuar sin simular una aceptación completa.
La evidencia puede perder vigencia cuando cambia la revisión o el entorno. También puede ser contradictoria: una prueba pasa y una integración falla. El agente debe investigar o delimitar esa diferencia, en vez de seleccionar únicamente el resultado favorable. Coding-Agent Failure Modes and Recovery trata situaciones como ejecución incompleta, test gaming y false completion que pueden distorsionar esa entrega.
Frontera con Agent Evaluation
Agent Evaluation estudia cómo se comporta un sistema agente entre tareas y ejecuciones. Puede usar resultados de verificación como etiquetas para un conjunto de casos. La pregunta aquí es distinta: si este cambio satisface esta tarea. Un score agregado alto no verifica un patch particular, y un patch bien respaldado no demuestra fiabilidad general del agente.
La práctica termina con afirmaciones proporcionadas a la evidencia disponible y con límites visibles. Permite autonomía útil y revisión enfocada sin convertir código generado, tests verdes, una segunda opinión o un resumen convincente en garantías universales de corrección.