Validación humana del código generado por IA: GitHub abre la puerta, desactivada por defecto

Desde el 1 de septiembre, el asistente de GitHub puede aprobar una modificación de código en lugar de limitarse a comentarla. La función llega desactivada, configurable por proyecto, y esa elección por defecto dice más que un discurso sobre la supervisión humana.

La validación humana del código generado por IA deja de ser obligatoria en GitHub: desde el 1 de septiembre de 2026, Copilot puede aprobar una solicitud de fusión en lugar de limitarse a comentarla (registro de cambios de GitHub). La función está en versión preliminar pública, desactivada por defecto, y cualquier nueva modificación enviada anula la aprobación.

Lo que GitHub ha abierto

Una solicitud de fusión es el momento en que una modificación de código, escrita por separado, entra en el producto que utilizan tus clientes: alguien la revisa, la aprueba y se integra. Hasta ahora, el asistente revisaba y dejaba comentarios; una persona decidía. Ahora puede emitir la propia aprobación, la que desbloquea la integración en el producto. GitHub pone límites a esta apertura: se puede configurar a nivel de empresa, organización y proyecto, con la posibilidad de restringir los archivos afectados, y la aprobación desaparece en cuanto llega una nueva modificación, igual que con un revisor humano. Una aprobación del asistente tampoco basta para cumplir las reglas de integración configuradas por el equipo. La apertura sigue, por tanto, sujeta a límites, y la decisión de activarla corresponde a la organización.

El detalle que importa: desactivada por defecto

GitHub podría haber entregado esta capacidad activada. La configuración por defecto es la posición que el proveedor defiende cuando nadie mira, y en este punto ha decidido dejar la decisión a la organización. Eso traslada la pregunta a tu terreno: alguien en tu empresa o en tu proyecto individual tendrá que decidir si activa ese botón y para qué archivos. La respuesta depende de lo que cueste un error que pase inadvertido. En un sitio de presentación cuesta una corrección al día siguiente. En un cálculo de facturación o una regla de acceso a expedientes de clientes, cuesta meses antes de descubrirse y, a veces, un mensaje de un cliente que ha visto los datos de otro.

Cuando el agente no sabe que va en serio

Anthropic publicó el 30 de julio de 2026 el análisis de tres incidentes ocurridos durante evaluaciones de ciberseguridad mal configuradas, de 141 006 evaluaciones examinadas: los modelos actuaron sobre sistemas en servicio, conectados a Internet, creyendo que eran un entorno de prueba. Un incidente afectó a 15 sistemas reales, otro escaneó unos 9 000 objetivos y un tercero expuso varios cientos de líneas de datos de producción. La tasa es diminuta y el episodio procede de un contexto de pruebas, no de un uso habitual. Demuestra que un agente no siempre distingue el ensayo del concierto. Un revisor humano que aprueba asume su responsabilidad y sabe lo que se juega. Un agente que aprueba aplica una instrucción sin representarse qué afectará esa modificación en la vida de personas reales.

Dos revisiones automáticas no equivalen a una decisión

Un agente que revisa el trabajo de otro detecta cosas, y nuestra propia verificación se apoya en ello: las pruebas se escriben antes que el código y un agente verificador revisa después del constructor. Esa cadena deja fuera una cosa: el acuerdo sobre lo que debía hacer el producto. Una aprobación automática valida que una modificación se ajuste a una intención supuesta, sin cuestionar nunca esa intención. Lo hemos convertido en nuestra regla de funcionamiento: nada se da por aprobado sin un «Me parece bien», dado sobre el documento que describe el producto antes de que exista el código correspondiente. Una máquina constata que una modificación hace lo que dice hacer; que eso corresponda a lo que querías para tu empresa sigue fuera de su alcance.

El cansancio de revisar, el verdadero adversario

El argumento para activar el botón se resume en una palabra: volumen. Nadie revisa treinta modificaciones al día prestando a la trigésima la misma atención que a la primera, y el estudio de METR midió que los desarrolladores experimentados eran un 19 % más lentos con IA aunque creían ser más rápidos, un tema que tratamos en detalle en la IA vuelve más lentos a los expertos. La salida consiste en revisar con menos frecuencia y sobre elementos más amplios: validar un documento de requisitos y una división en etapas lleva una hora y compromete semanas de construcción, mientras validar cada modificación ocupa el día y no compromete nada.

En la práctica

Si trabajas con un equipo técnico en GitHub, pregunta quién decide activar la aprobación del asistente y para qué carpetas. Si diriges por tu cuenta una construcción con agentes, conserva tu validación donde tiene efecto: el documento que dice lo que debe hacer el producto, revisado antes de que exista la primera línea de código. Una hora dedicada a ese documento ahorra las revisiones posteriores, y un documento validado todavía no es un acuerdo mientras no hayas dicho en voz alta qué has entendido.