Leer Código Está Muriendo como Guardián

Un ensayo sobre lo que cambia cuando la IA escribe la mayor parte del código — y lo que no.

"Todo lo que hará falta para que un equipo de software cometa seppuku el próximo año es que una persona insista en que al menos un humano entienda cada PR..."

"Para ser un buen ingeniero de software el próximo año necesitas entender que leer código es un modo de fallo. Para verificar sistemas necesitas usar dinámicas, no estáticas."

— Greg Fodor (@gfodor), Diciembre 2024

Esta es una provocación que vale la pena tomar en serio, no una opinión caliente para descartar.

La revisión estática de código — un humano leyendo un diff línea por línea — no escala. Asume que el código es escrito por humanos, a ritmo humano, en patrones legibles por humanos. La IA destruye las tres suposiciones. Produce código más rápido de lo que podemos revisar, en volúmenes que hacen que "una persona inteligente lo miró" sea económicamente inviable.

Toleramos la revisión estática porque las alternativas eran peores. Ahora, la verificación dinámica ofrece un mejor camino: evidencia de comportamiento en lugar de inspección de estructura.

Testing basado en propiedades verifica invariantes a través de miles de entradas.
Fuzzing encuentra crashes lanzando datos aleatorios a las interfaces.
Observabilidad en tiempo de ejecución muestra lo que el sistema realmente hace, no lo que pensabas que haría.

La dirección de viaje es clara. La revisión estática como guardián principal está muriendo. Pero "dinámicas sobre estáticas" es un eslogan, no una estrategia. Y los eslóganes oscurecen las preguntas difíciles.

Donde el argumento falla

1. La Trampa de Verificación Circular

Si el sistema se prueba a sí mismo, ¿quién define "correcto"?

Los tests codifican suposiciones. Si la IA escribe tanto la implementación como los tests, emerge un bucle peligroso: la implementación satisface los tests, pero los tests afirman comportamiento incorrecto. Checkmarks verdes por todas partes; software funcionando en ninguna.

Leer no desaparece; se reubica. Si no estás leyendo la implementación, debes leer la especificación.

2. La Brecha de Herramientas

Fodor asume que puedes verificar puramente a través del comportamiento. Pero cuando el comportamiento es incorrecto de maneras que tus tests no anticiparon, tienes que depurar un sistema que nunca has leído.

La promesa es "comprensión justo a tiempo" — pregunta a la IA que te lo explique. Pero las herramientas actuales alucinan conexiones y simplifican en exceso la complejidad. Si dependes de la IA para explicar sistemas que la IA construyó, y la explicación es incorrecta, estás doblemente ciego.

3. Seguridad vs. Malicia

La verificación dinámica encuentra bugs (crashes, anomalías). Falla en encontrar malicia.

Las bombas lógicas y los backdoors están diseñados para pasar tests. Más inmediatamente, los modelos de IA frecuentemente alucinan nombres de paquetes. Los atacantes registran estos nombres para inyectar malware. Si ningún humano lee package.json, estás abierto a ataques a la cadena de suministro que la verificación dinámica nunca atrapará.

4. El Coste de la Verificación

El análisis estático es efectivamente gratis. La verificación dinámica es cara.

Los entornos efímeros, el fuzzing y los tests end-to-end consumen cómputo masivo. Los "equipos YOLO" podrían ganar simplemente porque su factura de infraestructura es menor. La estrategia ganadora no es "maximizar dinámicas"; es "gastar el presupuesto de verificación donde produce el mayor retorno."

Lo que realmente cambia

El rol humano no desaparece. Se desplaza de inspector a diseñador.

De revisor de diffs a revisor de tests. Si no estás leyendo el código, debes revisar rigurosamente los tests. ¿Codifican los requisitos reales?
De lector de código a lector de resultados. Estudias evidencia de comportamiento: trazas, métricas, informes de mutación.
De guardián a arquitecto. La atención se enfoca en la forma del sistema, los límites y los modos de fallo.

Un marco útil: los humanos diseñan experimentos; las máquinas exploran el espacio de estados.

El Suelo de Responsabilidad

Una cosa no puede delegarse: la responsabilidad.

Cuando el sistema cae a las 3 AM, "Lo hizo la IA" no es un post-mortem aceptable. La responsabilidad significativa requiere suficiente comprensión para aceptar el riesgo. Incluso si la IA nos supera en cada tarea técnica, la necesidad de que un humano diga "Confío en este fix lo suficiente para desplegarlo" permanece.

Sobre escribir esto con IA

Este ensayo fue escrito por IA (Claude, Gemini, GPT), guiado por Will.

Si la tesis es que deberíamos verificar comportamiento en lugar de inspeccionar estructura, entonces ocultar la procedencia es innecesario. El objetivo es calidad, no pureza humana. Rondas de revisión y juicio editorial producen esa calidad, independientemente de quién o qué escriba los caracteres.

Conclusión

Fodor tiene direccionalmente razón. Los equipos que insistan en "un humano entiende cada PR" serán lentos, y probablemente morirán.

Pero "dinámicas sobre estáticas" es incompleto. Alguien todavía tiene que definir la corrección, atrapar la malicia y asumir el riesgo. Los ingenieros que prosperen no serán los que leen todo, ni los que no leen nada. Serán los que saben dónde la atención humana proporciona la mayor palanca.

Para prácticas concretas sobre cómo trabajar de esta manera, consulta el artículo complementario: Desarrollo Asistido por IA: Una Guía Práctica.