Hijos de la línea magenta

9 min de lectura

Cuando el código parece correcto y aun así destruye la empresa y su empleo

De dónde salió la línea magenta

A mediados de los años noventa, Warren Vanderburgh, capitán instructor de American Airlines, grabó una charla interna que se volvió famosa: “Children of the Magenta Line”. Había visto crecer a una generación de pilotos con cabinas de cristal y computadoras de gestión de vuelo. El piloto automático dibujaba una línea magenta en la pantalla de navegación. Cada vez más, el trabajo de la tripulación consistía en mantener el avión sobre esa línea y confiar en lo que decía la caja.

Su advertencia era simple. La línea es una herramienta. El avión sigue siendo volado por humanos. Cuando la situación se vuelve rara, el movimiento correcto suele ser bajar un nivel de automatización, tomar control manual y volar. Los pilotos que ya no podían hacerlo, los que seguían preguntándole a la computadora por qué hacía lo que hacía mientras la pista se iba por el costado, eran los que estaban en problemas.

La charla no era anti-automatización. Era anti-pasividad. El punto de Vanderburgh era que la cabina había pasado, en silencio, de volar el avión a gestionar un sistema que vuela el avión, y que la formación, los hábitos y los instintos no habían alcanzado ese cambio.

Cambie “computadora de gestión de vuelo” por “asistente de programación con IA” y la charla se escribe sola.

La ladera colombiana

El caso más claro también es el más incómodo. El 20 de diciembre de 1995, el vuelo 965 de American Airlines llevó un Boeing 757 perfectamente funcional contra una montaña cerca de Cali, Colombia. El capitán tenía experiencia. El primer oficial era competente. El avión estaba sano. El tiempo en altura era bueno. Escribí sobre el lado humano de ese accidente en Siguiendo el plan hacia la montaña.

Lo que mató a esas 159 personas no fue una máquina rota. Fue una entrada de waypoint de una sola letra en la computadora de gestión de vuelo, aceptada sin verificación, que dobló la línea magenta alejándola del aeropuerto y llevándola hacia el terreno. La tripulación siguió razonando sobre el sistema en vez de razonar sobre hacia dónde iba realmente el avión. Cuando la alerta de proximidad al terreno gritó, la geometría ya era implacable.

Eso es confiar en la línea más allá del punto donde debe entrar el juicio. No es pereza. Es un reflejo entrenado de deferir ante la caja porque la caja suele tener razón.

Las herramientas de programación con IA suelen tener razón también. Ese es exactamente el problema.

El GPS-100 y el vuelo de examen

Un recuerdo personal pequeño. Hace años, cuando la navegación GPS civil era nueva, volé con una unidad instalada en panel que pertenecía básicamente a la generación del Garmin GPS-100. Pantalla diminuta. Base de datos limitada. Un milagro comparado con lo que había antes.

En un vuelo de examen, el examinador observó cómo configuraba la ruta. Antes de cada waypoint, comparé la latitud y la longitud que mostraba la unidad con las coordenadas publicadas en la carta. No porque esperara que el GPS mintiera. Porque el costo de una entrada incorrecta era un desvío real en un avión real, y el costo de verificar eran diez segundos.

Lo notó. Después me dijo que la mayoría de los candidatos ya tenía la costumbre de escribir el identificador y confiar en lo que apareciera. El juguete nuevo era tan bueno, tan rápido, tan seguro de sí mismo, que el paso de verificación se había evaporado en silencio.

Ese es el momento que hay que vigilar. No cuando la herramienta es mala. Cuando la herramienta es lo bastante buena como para que el humano deje de comprobar.

Programar no se ha resuelto

“Programar está resuelto” es una frase que solo sobrevive mientras mantenga pequeña la palabra “programar”. Si programar significa producir una función que compila y más o menos hace lo pedido, entonces sí: los modelos son muy buenos y mejoran. Han resuelto una porción del trabajo que antes podía tomarle una tarde a un desarrollador junior.

Si programar significa el acto completo de desarrollar software — nombrar el problema, modelar el dominio, diseñar los límites, decidir qué no construir, escribir tests que fijan comportamiento, integrar con sistemas que mienten sobre sus contratos, entregar con seguridad, observar qué pasa y cambiar el diseño cuando la realidad empuja de vuelta — entonces no se ha resuelto. Se ha vuelto más rápido en las partes que ya eran mecánicas y más peligroso en las partes que nunca fueron mecánicas.

La analogía de la línea magenta es exacta. El piloto automático no resolvió volar. Resolvió mantener rumbo y altitud con menos carga de trabajo, lo que liberó atención para cosas más difíciles: clima, tráfico, combustible, contingencias, decisiones. Las tripulaciones que prosperaron usaron esa atención para esas cosas difíciles. Las que se desviaron la usaron para desconectarse.

Un asistente de programación con IA no resuelve el desarrollo de software. Elimina una parte del trabajo clerical y le devuelve atención. Lo que haga con esa atención decide si su base de código termina mejor o empeora en silencio.

Cómo se ven los “hijos de la línea magenta” en una base de código

El modo de falla de la cabina tiene un equivalente para desarrolladores. Se detecta sin cronómetro.

• Pull requests donde el autor no puede explicar un bloque no trivial que aceptó.
• Tests que existen porque el asistente los sugirió, no porque fijan un comportamiento sobre el que alguien razonó.
• “Refactors” que mueven código sin cambiar lo que el sistema realmente hace o garantiza.
• Reportes de bugs parchados en tres lugares distintos porque nadie rastreó la causa, solo pidió un arreglo al modelo.
• Decisiones de arquitectura justificadas con “la IA lo recomendó” en vez de como un trade-off que eligió el equipo.
• Una incapacidad creciente de decir por qué una función tiene esa forma, solo que pasa.

Cada uno sigue el mismo patrón: la línea magenta está dibujada y se obedece. Nadie está volando.

Bajar un nivel

La receta de Vanderburgh no era prohibir el piloto automático. Era asegurar que los pilotos pudieran, en cualquier momento, bajar un nivel: de automatización completa a seleccionar modos a mano, a volar con datos crudos, a volar el avión por sensación. Cada nivel era una alternativa. La vigencia en los niveles inferiores hacía seguros los superiores.

La misma disciplina aplica al desarrollo asistido por IA. La cura no es rechazar las herramientas. Es mantenerse afilado en los niveles por debajo de ellas.

• Lea el diff que está a punto de hacer commit. Todo. En voz alta si hace falta.
• Escriba el test antes de la implementación con suficiente frecuencia como para no olvidar cómo se hace. Los tests son los datos crudos del desarrollador. Cubro la versión con agentes en Los tests vencen a las instrucciones para agentes de programación con IA.
• Mantenga pequeño un cambio pequeño. Si el asistente ofrece una reescritura enorme, rechácela y pida el paso más pequeño.
• Cuando algo se siente mal, suelte el asistente. Abra el archivo. Razone en su propia cabeza. Si no puede, esa es la señal de que perdió altitud sobre el problema, no de que el modelo necesita un prompt mejor.
• Interrogue el código a través de la herramienta con agente. Pregunte dónde vive una regla, qué archivos parsean precios, qué supuestos introdujo el cambio y si la misma decisión aparece en varios lugares.

Ese último movimiento importa. Un desarrollador experimentado puede leer la respuesta de un agente y oler el problema antes de que exista el incidente. “Estoy parseando precios aquí, aquí y aquí” no es un resumen inocente. Es una crisis futura presentándose con buenos modales. La respuesta correcta no es una reunión de comité. Es una instrucción precisa: mantenlo DRY, centraliza la regla de precios, añade el test que lo demuestra. El humano no compite con el agente. El humano interroga el sistema a través del agente antes de que la línea magenta doble en silencio.

Nada de esto frena a un desarrollador fuerte. Es lo que los desarrolladores fuertes ya hacían.

Qué debería preguntar liderazgo

Si usted es CEO, CTO o miembro del consejo y escucha a alguien explicar que programar ya es una mercancía, unas pocas preguntas no cuestan nada y ahorran mucho.

1. ¿Puede el equipo explicar, sin el asistente, el último cambio no trivial que entregó?

   Si la respuesta es un gesto vago hacia el historial de prompts, está mirando a hijos de la línea magenta.

2. ¿Qué pasa cuando el asistente se equivoca con confianza?

   Debe haber una respuesta real. Tests que fallan fuerte. Desarrolladores que cuestionan las respuestas del agente. Observabilidad que detecta deriva. Si la única red de seguridad es "el próximo prompt lo arreglará", el piso está más abajo de lo que sugiere la presentación.

3. ¿Dónde practica el equipo el nivel por debajo de la herramienta?

   Pairing, trabajo deliberado test-first, sesiones de lectura de código, pequeños refactors hechos a mano. En aviación eso se llama currency. Sin eso, las ganancias aparentes de productividad se toman prestadas contra un incidente futuro.

4. ¿Quién es dueño del diseño cuando el asistente no está de acuerdo?

   Si la respuesta es "usamos lo que produzca el modelo porque es más rápido", el diseño salió del edificio. La línea magenta ya se está dibujando sola.

El marco útil

Programar no se ha resuelto. Una parte se ha automatizado, y la parte que queda es la que siempre importó más: juicio, diseño, verificación y la disposición a contradecir a un sistema seguro de sí mismo cuando la geometría está mal.

Las tripulaciones que sobrevivieron la transición a la cabina de cristal no fueron las que menos usaron la automatización. Fueron las que se negaron a convertirse en pasajeras de su propio avión. Los desarrolladores y equipos que saldrán más fuertes de la transición a la IA son esa misma clase de personas.

La línea magenta es una herramienta. Alguien todavía tiene que volar.