GitHub publicó el 12 de junio de 2026 una mejora que suena administrativa, pero pega directo en cómo se despliegan agentes en repos reales: Copilot code review ahora acepta controles más fuertes a nivel organización.

La noticia útil no es que Copilot revise PRs. Eso ya estaba en marcha. Lo nuevo es que GitHub está cerrando huecos operativos: configuración de runner desde la organización, soporte para exclusiones de contenido y eliminación del límite corto en instrucciones personalizadas. Leído como builder, esto no va de mejores frases en comentarios; va de qué contexto puede ver el agente, dónde corre y qué reglas debe obedecer.

Flujo editorial con una organización definiendo runners compartidos antes de enviar revisiones automáticas a pull requests

El cambio de runners sí importa

GitHub dice que Copilot code review usa GitHub Actions y que, por defecto, corre sobre runners hospedados por GitHub. Con la mejora nueva, los admins pueden definir el tipo de runner para toda la organización y bloquear esa configuración para que los repos no la cambien individualmente.

Eso resuelve una fricción real: si cada repo decide su runner, terminas con revisiones inconsistentes, costos difíciles de explicar y políticas de ejecución repartidas por todos lados.

Para equipos con compliance o repos sensibles, el valor es claro:

usar runners más grandes cuando la revisión necesita contexto pesado;
forzar runners aprobados por la organización;
evitar que un repo active un camino más débil por comodidad;
alinear Copilot code review y Copilot cloud agent cuando ambos están habilitados.

Content exclusions cambia el límite de confianza

La segunda mejora es todavía más importante: Copilot code review ahora respeta exclusiones de contenido a nivel repo, organización y enterprise.

Mapa editorial con carpetas excluidas, rutas permitidas y un agente de revisión operando solo dentro de límites aprobados

Eso no es un detalle menor. Muchos equipos tienen archivos que no quieren usar como contexto para un modelo: datos internos, fixtures con información sensible, carpetas generadas, snapshots enormes, documentación privada o módulos que no aportan a una revisión concreta.

Hasta ahora, activar agentes de revisión implicaba una pregunta incómoda: “¿qué tanto del repo está viendo realmente?”. Con exclusiones respetadas, la discusión puede volverse más parecida a una política de acceso:

qué carpetas nunca entran al contexto;
qué repos pueden usar review automática;
qué tipos de archivos se excluyen por defecto;
quién audita cambios en esas reglas.

Quitar el límite de instrucciones ayuda, pero también te puede ensuciar

GitHub también quitó el límite de 4000 caracteres para copilot-instructions.md y archivos *.instructions.md bajo .github.

Eso ayuda a equipos que ya tienen convenciones largas: arquitectura, testing, seguridad, estilo, migraciones, ownership, flags y rollback. Pero también abre una trampa: meter toda la wiki en instrucciones y esperar que el agente priorice bien.

Mi criterio sería separar:

reglas obligatorias y cortas;
referencias largas por área;
ejemplos concretos;
y tests o checks que validen lo que el comentario del agente sugiere.

Qué haría antes de activarlo en toda la empresa

Mi checklist sería:

define runner por organización y bloquea excepciones solo donde tengan dueño;
crea una lista mínima de rutas excluidas;
revisa si tus instrucciones tienen reglas repetidas o contradictorias;
prueba en repos con PRs medianos antes de activar revisión automática;
mide comentarios útiles, falsos positivos, costo y tiempo de runner.

Esta noticia conecta con el costo real de Copilot code review en Actions y AI credits. Aquella pieza explica la factura; esta explica la gobernanza. Si todavía estás armando las bases para agentes con permisos y revisión humana, empieza por el curso gratis.

La lectura corta: Copilot code review se está pareciendo menos a un bot de comentarios y más a una capacidad agentic que necesita políticas de plataforma.