El programador inmaculado

Hace unos días dejé un comentario en un hilo de Hacker News que preguntaba hacia dónde va la profesión de programar. Quien lo abrió acababa de cerrar una empresa pequeña y había visitado una más grande, y lo que encontró lo inquietó: el código ya no era la fuente de verdad, nadie lo revisaba línea por línea, y algunos desarrolladores corrían cinco sesiones de agentes a la vez sin leer realmente lo que producían. Mi respuesta fue el argumento que no dejo de repetir: que el rol se ha movido de programador a ingeniero que dirige agentes de programación, y que las fallas que vemos vienen de querer resolverlo todo con un prompt de cuatro líneas en lugar de mantener la ingeniería alrededor del código.

Llegó una respuesta que llevo dándole vueltas desde entonces. Señalaba los errores que un modelo había cometido —una clase Cookie lanzada sin un campo de nombre, una query que se rompía con dos filas de la base de datos que compartían un ID— y aterrizaba en una sola frase: “los mejores programadores humanos definitivamente no habrían cometido esos errores.”

Esa frase es el ensayo entero. Así que déjenme desarmarla con calma, porque creo que está haciendo algo que buena parte del hilo hace, y vale la pena verlo con claridad.

Primero, la parte que es cierta

No quiero descartar el hilo, porque la mayor parte de él no es miedo: es algo real, y yo también lo siento. Existe una verdadera deuda cognitiva que se acumula cuando el prompt se vuelve el artefacto que conservas y el código se vuelve un gas de escape que nunca lees; puedes perder el dominio de un sistema que nominalmente es tuyo. Existe el músculo que se atrofia cuando dejas que la herramienta lleve el volante durante meses y luego te sientas a hacerlo a la antigua y descubres que tus manos son más lentas que el recuerdo que tienes de ellas. Existe el agotamiento que varios describieron: la sensación de pelear contra tus herramientas, de entregar más mientras te sientes menos seguro de nada de ello, de que la responsabilidad se vuelve borrosa justo cuando sube el volumen.

Nada de eso es ludismo. Son personas describiendo un oficio que cambia bajo sus pies y nombrando lo que cuesta, que es exactamente la conversación que deberíamos estar teniendo. Quiero que quede asentado que lo tomo en serio antes de discrepar en nada, porque lo que sigue solo funciona si concedes que la preocupación de fondo es legítima.

El programador que nunca existió

Ahora la frase. Los mejores programadores humanos definitivamente no habrían cometido esos errores.

Observa lo que pasa alrededor de un error de la IA frente a uno humano. Cuando un modelo lanza una cookie sin campo de nombre, el error se captura, se cita y se hace circular como prueba de que la herramienta no sirve: un pulcro pequeño artefacto de incompetencia. Cuando una persona lanza el mismo bug, es un martes cualquiera. Se va a un ticket, lo atrapa el review o no, se lanza o no, y nadie concluye que no se puede confiar en los humanos para escribir software. El mismo defecto significa la máquina es incapaz en un caso y lo arreglamos en la siguiente pasada en el otro. Esa asimetría del escrutinio es todo el truco, y una vez que la ves ya no puedes dejar de verla.

Porque aquí está lo que todos sabemos y de algún modo refutamos cuando nos conviene: construimos una disciplina entera sobre la premisa de que los mejores programadores humanos cometen exactamente estos errores. El code review existe porque los cometen. Los linters, los type checkers, los tests, los gates de CI, los entornos de staging, los postmortems sin culpa de por medio: cada una de esas cosas es infraestructura que inventamos porque asumimos que gente competente y cuidadosa va a lanzar el off-by-one, va a pasar por alto el ID duplicado, va a olvidar el campo. El programador inmaculado que jamás lo haría: esa persona nunca ha estado en ningún equipo en el que yo haya estado, y apuesto a que tampoco en el tuyo. No nos protegemos contra ellos. Nos protegemos contra nosotros.

La comparación está amañada

Así que la comparación honesta nunca fue la IA sola contra un humano idealizado. Es un proceso gestionado con IA contra un proceso gestionado con humanos, y ambos atrapan errores río abajo, porque para eso existe el proceso.

Lo llamativo es que la respuesta me dio la razón sola. El contrapunto a mi argumento era que los buenos equipos no se pasan specs de mil líneas; trabajan de forma incremental, mediante conversaciones breves, verificando la alineación sobre la marcha. Sí: eso es precisamente. Eso es proceso y comunicación, la ingeniería envuelta alrededor del tecleo. Quítaselo a un humano y obtienes la misma clase de bug; mantenlo alrededor de un modelo y los bugs se atrapan igual que siempre. La discrepancia nunca fue realmente sobre capacidad bruta. Era sobre si conservas la ingeniería o no, o si esperas que el código se sostenga solo y luego te indignas cuando no puede, lo cual, que conste, no puede para nadie, ni de carbono ni de silicio.

El duelo no es un argumento de calidad

Creo que mucho de lo que hoy se lee como crítica técnica es algo más humano por debajo, y no lo digo para descalificarlo. Un hilo como ese es un terreno de catarsis para una profesión de luto. La gente construyó identidades sobre un oficio, se volvió buena en él a lo largo de años, y está viendo cómo se mueve el suelo. Por supuesto que eso sale de lado. Por supuesto que sale como la máquina es descuidada y yo no.

Pero hacer el duelo de un rol y evaluar una herramienta son actos distintos, y cuando dejamos que el primero se vista con el disfraz del segundo, el argumento se echa a perder de una forma específica: medimos a la máquina contra un humano que nunca existió, y a esa brecha la llamamos prueba. La señal está en hacia dónde apunta el rigor. Las críticas de verdad —deuda cognitiva, propiedad perdida, habilidad atrofiada— se enganchan con lo que de hecho está cambiando. La jugada del programador inmaculado no; defiende lo irremplazable del oficio inflando los errores de la máquina y retocando con aerógrafo, en silencio, los nuestros. Eso no es análisis. Es un sentimiento que aprendió a hablar como si lo fuera.

Dónde me paro

El punto nunca fue que el modelo sea impecable. No lo es, y me paso los días con sus fallas. El punto es que impecable tampoco fue nunca la vara para nosotros, y fingir que lo era es como se pierde el verdadero argumento. El trabajo del ingeniero —el trabajo que sobrevive a todo esto— es el proceso que vuelve sobrevivible cualquiera de los dos tipos de error: la dirección, la responsabilidad, el mapa dentro del cual puedes pararte y tomar una decisión. Ese es el trabajo. Siempre lo fue. El código solo fue, en todo momento, la parte que tarde o temprano podríamos delegar.

Prefiero construir ese proceso que defender una pureza que ninguno de nosotros tuvo jamás. No obtenemos software más honesto insistiendo en que éramos inmaculados. Lo obtenemos como siempre lo hicimos: asumiendo que el error viene, venga de quien venga que esté tecleando, e ingeniando para el día en que llegue.

(Este texto es un complemento de No quiero una IA que me necesite menos — donde defendí mantener al humano en el loop como el elemento que carga el peso, no como la ineficiencia que hay que eliminar.)