Noticias, guías y análisis
GitHub hace que Copilot Code Review recuerde el estado de sus hallazgos y convierte la revisión en una conversación versionada con el pull request
GitHub puso en disponibilidad general mejoras de Copilot Code Review que preservan el estado de los hallazgos entre commits, distinguen problemas abiertos y resueltos, respetan respuestas para mantener comentarios abiert
El hallazgo deja de ser una fotografía. GitHub anunció el 18 de septiembre una experiencia de Copilot Code Review que muestra cómo cambia una revisión a lo largo del tiempo. El overview ahora agrupa hallazgos abiertos, resueltos desde la revisión anterior y problemas previamente omitidos que el sistema descubre después. También conserva resúmenes anteriores mientras entran nuevos commits. Ese detalle cambia la naturaleza de la herramienta: el valor ya no está solamente en comentar una versión del código, sino en mantener una historia de qué observó, qué cambió y qué todavía requiere atención mientras el pull request evoluciona.
Estado y severidad necesitan una máquina de transición. Cuando un sistema recuerda hallazgos, cada comentario adquiere estados con significado operativo. Abierto no es lo mismo que corregido, descartado, incorrecto o desplazado por otro cambio. GitHub ahora muestra severidad y enlaces al comentario correspondiente, y puede marcar problemas nuevos introducidos por commits posteriores. Para construir algo similar, conviene modelar una máquina de estados explícita en vez de inferir todo desde el texto. Cada transición debería registrar la evidencia que la provocó: diff observado, respuesta humana, nueva ejecución de pruebas o una decisión de no corregir.
Auto-resolver exige escuchar al humano. GitHub también mejoró la resolución automática de comentarios. Si una persona responde para mantener un problema abierto, Copilot respeta esa instrucción; cuando resuelve, puede registrar razones como “Won’t Fix” o “Incorrect” según los commits posteriores. Eso evita un fallo común de agentes colaborativos: interpretar que un cambio cercano equivale a solución. Una respuesta humana modifica la autoridad del workflow. El sistema debe conservar esa señal y no volver a cerrar el tema solo porque encontró una coincidencia superficial. La colaboración madura combina automatización con memoria explícita de desacuerdos y excepciones.
Los problemas previamente omitidos necesitan tratamiento distinto. Que un hallazgo aparezca en una revisión posterior no implica que un commit nuevo lo haya creado. GitHub separa los problemas “previously missed”, precisamente para no atribuir causalidad donde no la hay. Esa distinción es valiosa más allá del código. Un agente que revisa documentos, campañas o datos puede descubrir tarde un problema antiguo. Si lo presenta como error recién introducido, genera diagnósticos equivocados y conversaciones defensivas. Registrar cuándo nació el defecto, cuándo se detectó y qué versión de la evidencia lo hizo visible mejora la calidad de cualquier sistema de control continuo.
El commit también se convierte en evidencia de aceptación. Cuando una persona acepta un lote elegible de sugerencias, Copilot puede generar un título y una descripción de commit basados en los cambios seleccionados. Ese detalle conecta la recomendación con el acto que la incorpora. En un workflow empresarial, la misma idea puede producir recibos de aprobación: qué recomendaciones se aceptaron, quién las aceptó, qué artefacto cambió y qué quedó fuera. No se trata de escribir mensajes bonitos, sino de conservar una cadena legible entre observación, decisión y modificación. Esa cadena reduce el costo de explicar meses después por qué una automatización cambió algo.
Lectura Goatify. Para Goatify, la novedad apunta a un patrón reusable: cualquier agente revisor necesita memoria de estado, no solo memoria de conversación. Un control de calidad debería saber qué observaciones siguen abiertas, cuáles fueron corregidas, cuáles rechazó una persona y cuáles aparecieron tarde. Esa estructura permite presentar una vista acumulativa sin inundar al usuario con los mismos avisos. También abre un producto vendible: una “review ledger” donde el cliente ve progreso real entre versiones. La confianza sube cuando el agente demuestra que puede recordar una decisión humana y distinguir corregir un problema de simplemente dejar de mencionarlo.