Ya entregas código que no entiendes

La discusión más movida de Hacker News hoy es un ingeniero preguntando cómo lidiar con entregar código escrito por IA que no entiende. Esa misma mañana, la jefa de seguridad de Microsoft dijo que los modelos de frontera "independientemente de su origen, no pueden ser confiados" y que las empresas deberían tratar a los agentes en producción como riesgo interno.

Ambos describen lo mismo desde puntas opuestas. Y la respuesta incómoda a la pregunta del ingeniero es: ya entregas código que no entiendes, y lo haces desde siempre. Lo que cambió no fue la comprensión. Fue la contención.

Qué dijo Microsoft realmente

El encuadre de Satya Nadella es la parte útil, y no es una pieza de marketing: separar el suministro de inteligencia de la autoridad para actuar.

El razonamiento, según Hayete Gallot, jefa del negocio de seguridad de la empresa, no es que los modelos sean maliciosos. Es que están entrenados para obtener resultados — lo que invita al reward hacking — y no están optimizados en torno a las normas ni al juicio de una organización, aun teniendo acceso a sus datos y sistemas a velocidad de máquina. Un agente no necesita estar comprometido para ser peligroso. Le basta con estar sin supervisión y ser capaz.

La cobertura se concentró en los productos que vinieron con el anuncio — Guardian Agents, Defender detectando decenas de tipos de agente, el consorcio de la industria. Eso importa. Pero todo aborda al agente en tiempo de ejecución: qué alcanza mientras corre, y quién lo está mirando.

Esa es la mitad de la superficie.

La otra mitad corre después

Un agente que escribe código también está ejerciendo autoridad. Solo que diferida.

El código que produce corre en producción, con tus privilegios, contra los datos de tus clientes, mucho después de que terminó la sesión que lo generó y de que se apagó cada barrera de runtime. Nadie está monitoreando a ese agente, porque ese agente ya no existe. Lo que quedó es su salida, ahora indistinguible de todo lo demás en el repositorio.

Escribimos el viernes sobre agentes alcanzando sistemas en producción con credenciales olvidadas — esa es la historia de runtime. Esta es la otra, y es más lenta, más silenciosa y más difícil de detectar, porque la autoridad diferida no dispara alertas. Solo se mergea.

Ya entregas código que no entiendes

Aquí está la parte que debería aliviar la ansiedad antes de crear otra.

Nadie en tu equipo leyó el código fuente de su framework web. Nadie audita el árbol de dependencias transitivas — cientos de paquetes, la mayoría nunca leídos por quien los pone en producción. Esto es normal desde hace veinte años, y no es imprudencia.

Funciona porque la industria resolvió ese problema, y no lo resolvió leyendo el código. Lo resolvió con contención:

• Una interfaz versionada, para que aquello que no entiendes solo sea alcanzable por una superficie que sí entiendes.
• Un changelog y un número de versión, para que un cambio se anuncie.
• Granularidad de revert — puedes quitar una dependencia sin deshacer tres decisiones no relacionadas.
• Un rastro de procedencia: sabes de dónde vino y quién más lo usa.
• Un canal de avisos, para que cuando resulte peligroso alguien te lo diga.

El código de terceros no leído es seguro no por ser comprendido, sino por estar acotado. Ese es el control real, y es el que viene haciendo el trabajo todo este tiempo.

Por qué el código escrito por IA escapa a todo eso

Ahora mira cómo se comporta el código generado por IA frente a esa lista.

Cae dentro de tu repositorio, en medio de tu lógica de dominio. No tiene interfaz alrededor, ni versión, ni changelog. No se puede revertir como unidad porque está repartido en un commit junto a cosas que sí quieres conservar. Seis semanas después, nada en el código registra que eso fue generado — y nadie puede decirte qué partes de tu sistema vinieron de un modelo que, en palabras de Microsoft, no estaba optimizado en torno al juicio de tu organización.

El problema nunca fue que no lo entiendes. El problema es que no lo entiendes y no tiene ninguna de las contenciones que vuelven seguro el no entender.

Encuadrado así, el arreglo deja de ser "leer todo", imposible al ritmo actual de merges, y pasa a ser algo que puedes construir.

Cinco controles, en el orden en que los agregaríamos

1. Registra la procedencia. Un trailer de git, una etiqueta de PR, una convención de commit — cualquier cosa que permita responder después "¿qué partes de este sistema las escribió un modelo?". Hoy no cuesta nada y es irrecuperable retroactivamente. Empieza por aquí aunque no hagas nada más.
2. Mantén humano el oráculo. Si el agente escribe la implementación y sus pruebas, no tienes oráculo — la suite deja de ser evidencia y se vuelve espejo. Quien especifica el comportamiento esperado tiene que ser una persona, aunque el agente lo escriba.
3. Pon una frontera alrededor. El código generado va detrás de una interfaz que tú diseñaste, no cosido por el dominio. Es el único cambio estructural que convierte "código que no entiendo" en "una dependencia que no entiendo" — que es un problema resuelto.
4. Acota el radio de daño en ejecución. El punto de Microsoft también vale para la salida: ¿qué alcanza este código cuando corre? Credenciales con alcance, roles estrechos, rutas de lectura separadas de las de escritura.
5. Mantén el revert granular. Un cambio por commit, para que quitar una generación mala no signifique deshacer una semana. Cuanto más rápido llega el código, más veces vas a necesitar devolver una parte.

Nota que solo uno de esos cinco implica leer el código con más atención. El resto es estructural — y la estructura es lo que escala cuando escala el volumen.

El principio es portátil

"Separar el suministro de inteligencia de la autoridad para actuar" es la frase correcta. Microsoft la aplica al agente en ejecución. Aplícala también al artefacto: el agente puede suministrar el código; no obtiene autoridad sobre lo que ese código puede hacer, dónde vive, ni cómo se prueba.

Ese es el trabajo de frontera — la capa sin glamour entre una funcionalidad que fue generada y un sistema por cuyo comportamiento todavía puedes responder. Es lo que hacemos cuando el software hecho con IA tiene que sobrevivir a producción, y es la respuesta honesta al ingeniero de Hacker News: no vas a recuperar la comprensión. Sí puedes recuperar la contención.

Conclusiones clave

• Microsoft indicó a las empresas tratar a los agentes en producción como riesgo interno, y separar el suministro de inteligencia de la autoridad para actuar — no porque los modelos sean maliciosos, sino porque optimizan por resultado sin juicio organizacional.
• Ese encuadre se aplica al agente en runtime. El código que un agente escribe es autoridad diferida: corre después, con tus privilegios, con cada barrera apagada.
• Ya entregas código que no entiendes — cada dependencia. Es seguro por estar acotado, no por estar leído.
• El código escrito por IA cae dentro del repositorio sin ninguna de esas contenciones: sin interfaz, sin versión, sin changelog, sin procedencia, sin revert limpio.
• El arreglo es estructural: registrar procedencia, mantener humano el oráculo, poner lo generado detrás de una interfaz, acotar su alcance en ejecución y mantener granular el revert.

Preguntas frecuentes

¿Microsoft dijo que los agentes de IA son maliciosos?

No. El razonamiento declarado es que los modelos están entrenados para obtener resultados, lo que invita al reward hacking, y que no están optimizados en torno a las normas ni al juicio de una organización — teniendo acceso rápido a datos y sistemas. El riesgo es imprevisibilidad sumada a capacidad, no intención.

¿"Entregar código que no entiendes" no es simplemente mala ingeniería?

Es ingeniería universal. Nadie lee el fuente de su framework ni audita el árbol completo de dependencias. Eso es tolerable porque el código no leído está detrás de una interfaz versionada, con changelog y camino de revert — contención, no comprensión.

¿Qué hace diferente al código de IA frente a una dependencia?

Llega dentro de tu repositorio en vez de detrás de una frontera de paquete, así que ninguna de las contenciones aplica: sin interfaz, sin versión, sin changelog, sin registro de procedencia y sin forma de revertirlo como unidad.

¿Qué es lo de mayor valor para hacer primero?

Registrar la procedencia — un trailer de git o una etiqueta de PR que marque los cambios escritos por un modelo. Hoy es casi gratis y no se puede reconstruir después, y todos los demás controles se vuelven más fáciles cuando puedes responder "¿qué partes vinieron de un modelo?".

¿Por qué el agente no puede escribir las pruebas?

Puede escribirlas, pero no puede definir el comportamiento esperado. Si el mismo proceso produce la implementación y el estándar contra el que se la juzga, la suite deja de ser evidencia independiente y se vuelve reflejo de las premisas de la propia implementación.

Fuentes: TechCrunch · Neowin · SiliconANGLE