El olfato que ningún modelo trae

Es la ronda once de review de una PR que en el ticket decía “cambio chico”.

Claude Code escribió el fix. Copilot lo revisó en GitHub y encontró un problema serio: una condición de carrera en una parte del código que nadie había pedido tocar. Claude lo corrigió. En la corrección apareció otro problema, más sutil, en un test que ahora pasaba por las razones equivocadas. Ronda doce. Ronda trece. En algún momento dejé de contar y empecé a leer el diff entero, línea por línea, como hacía antes.

Nada de esto es raro. Es lo que pasa ahora, casi todos los días.

Llevo más de veinte años haciendo software y hay algo que no me había pasado nunca: por momentos, siento que este trabajo está en peligro.

Una sensación nueva

No es la primera ola que veo. Pasaron la nube, el low-code que iba a reemplazar a los programadores, los frameworks que prometían que ya no hacía falta entender lo que había abajo. En todas hubo alguien anunciando el final del oficio, y en todas el oficio cambió de forma y siguió. Esta vez la sensación es distinta, y me cuesta explicar por qué.

Parte es la velocidad. El 22 de septiembre salieron dos modelos de frontera, de dos empresas distintas, con horas de diferencia. Los mejores agentes ya resuelven solos más de la mitad de un benchmark de tareas de terminal diseñado para ser difícil, tareas que hace un año parecían territorio de alguien con experiencia.

Parte es que no miro esto desde afuera. Trabajo con IA todos los días desde hace cuatro años. Buena parte del código que sale de mis manos ya no lo escriben mis manos.

Y sin embargo, cuando llego al final del día, la sensación se da vuelta.

Lo que el agente no ve

Hay un tipo de conocimiento que no aparece en el código. Es saber que esa cola va a explotar el día que el proveedor de pagos tarde tres segundos más en responder. Que ese cache está bien hasta que haya dos regiones. Que un cambio inocente en un esquema va a romper un consumidor que nadie recuerda que existe. No se lee en la documentación. Se aprende recibiendo el golpe, a las tres de la mañana, con producción caída y un rollback que no vuelve atrás lo que tenía que volver atrás.

A eso le digo olfato. Arquitectura, escalabilidad, sistemas distribuidos: todo eso se puede explicar en un libro, pero el olfato es la parte que el libro no alcanza. Es anticipar por dónde va a venir el problema antes de que haya evidencia de que existe.

Los agentes de hoy son muy buenos al nivel del código. Donde todavía los veo tropezar es en el nivel de arriba: el del contexto que no está escrito en ningún lado, el de las consecuencias de segundo orden, el de “esto funciona, pero no es lo que el sistema necesita”.

¿Es una limitación de hoy o algo más profundo, algo de su naturaleza? Tengo una intuición, y es que les va a costar mucho llegar ahí. Pero no lo sé. Y desconfío de cualquiera que diga saberlo con certeza, de un lado o del otro.

El retrabajo se mudó

Hace cinco años el delivery era más lento. Una feature pasaba por diseño, por discusión, por una PR que un compañero leía con calma. Encontrábamos los problemas temprano, muchas veces antes de escribir una línea, en una conversación. El retrabajo era poco.

Hoy el código aparece en minutos. Los problemas aparecen después, en loops de review que se retroalimentan: cada corrección trae algo nuevo, porque el agente arregla lo que le señalás con la misma confianza con la que escribió lo que estaba mal. Diez, quince rondas para dejar fina una PR que en el ticket parecía simple.

No digo que sea peor. Digo que es otra cosa. La IA no nos aceleró tanto como nos cambió el lugar donde encontramos los problemas. Pasamos de pensar antes a corregir después.

Hay un dato que me quedó dando vueltas. En 2025, METR midió a developers experimentados trabajando en sus propios repositorios, con y sin IA. Con IA tardaron un 19% más. Al terminar, estaban convencidos de haber ido un 20% más rápido. Un año después, cuando quisieron repetir el estudio, se encontraron con otro problema: muchos developers ya no querían participar si existía la posibilidad de tener que trabajar sin IA.

Me reconozco en las dos cosas. No sé si voy más rápido. Sé que no quiero volver.

También lo noto del otro lado, como usuario. El software que uso todos los días se rompe más que hace unos años: pantallas que no cargan, estados que no se actualizan, cosas que se rompen en una actualización y vuelven en la siguiente. No lo tengo medido y no puedo probar de dónde viene cada error. Pero muchos tienen una forma que conozco bien: código que pasó los tests y que nadie terminó de entender.

Las reglas cambian cada trimestre

Buena parte de mi trabajo hoy es ponerle guardrails a la IA. Instrucciones, contexto, lineamientos, reviewers automáticos. Todo lo necesario para que un agente cumpla un objetivo sin meter una regresión o un bug severo en el camino.

El problema es que eso que construís tiene fecha de vencimiento. Cada modelo nuevo razona distinto, obedece distinto, se equivoca distinto. Lo que funcionaba hace tres meses hoy a veces estorba. Es como aprender a manejar un auto que cada temporada cambia de lugar los pedales.

Los modelos se versionan. Cada tanto sale uno nuevo que reemplaza al anterior y, con él, parte de lo que sabías sobre cómo usarlo. El olfato no. El olfato se acumula.

Dejar de pensar

Lo que más me inquieta no está en el código.

Veo cada vez más decisiones importantes que se toman con lo que devuelve un chat. No hablo de pedir un borrador u ordenar ideas, que es un uso razonable. Hablo de estrategia: a qué mercado ir, qué producto frenar, dónde recortar. Gente con mucha responsabilidad que le pregunta a un modelo y decide en base a lo que el modelo le mastica. Una encuesta de Board a 300 ejecutivos de empresas estadounidenses encontró este año que el 61% cuenta a los LLMs entre las fuentes que más influyen en sus decisiones estratégicas. Entre los CFOs, casi la mitad dijo que sigue la recomendación de la IA incluso cuando contradice su propio criterio.

Pero creo que hay algo más profundo que preguntarle a un modelo qué hacer. Ya no le delegamos solo la respuesta. Le delegamos la pregunta: qué datos mirar. Y rara vez nos detenemos a preguntar si está mirando los correctos.

Pasa algo así. Un agente arma un dashboard y define las métricas: qué cuenta como usuario activo, qué es una conversión, desde cuándo se mide la retención. Deja todo documentado, prolijo y convincente. Semanas después, otro agente, en otra conversación, toma esa documentación para responder una pregunta distinta. Pero la documentación ya no coincide con lo que la métrica mide de verdad: un evento cambió de nombre, un filtro quedó a medias, una definición se reescribió en el camino. Nadie lo nota, porque nadie estaba mirando. El segundo agente razona impecable sobre una base torcida, y la conclusión sale plausible, bien escrita y sin olor. Y equivocada.

Sobre esa conclusión se decide.

En una empresa grande, una mala decisión se amortigua. En una startup no. Las startups pivotean todo el tiempo en base a datos como estos: cambian de cliente, de precio, de producto, porque una métrica dijo que algo no funcionaba. En una empresa que se hace a pulmón, con pocos meses de runway y un equipo chico que apostó todo, una decisión equivocada puede ser la última.

Nada de esto es culpa del modelo. Hizo lo que se le pidió. Lo que falta es alguien que se pregunte si estamos mirando lo que hay que mirar, y esa pregunta no aparece en ningún dashboard. El olor es justamente lo que importa. La sensibilidad al contexto, la incomodidad de que algo no cierra aunque todos los números cierren, la memoria de haber visto esto antes en otro lado y saber cómo terminó. Si eso se deja de ejercitar, no desaparece de golpe. Se atrofia de a poco, sin que nadie lo note, hasta el día en que hace falta.

Un estudio de Anthropic de este año va en esa dirección, a escala chica: developers que aprendían una librería nueva con IA terminaron entendiendo bastante menos que los que lo hacían a mano. La diferencia más grande estuvo en debugging, que es exactamente la habilidad de darte cuenta de que algo está mal.

La barrera que subió

Hay un relato que circula: cualquier junior con IA se convierte en senior. Mi experiencia es la contraria. Creo que la barrera de entrada a la ingeniería de software nunca estuvo tan alta.

Para trabajar bien con agentes hoy tenés que entender arquitectura, entender por qué algo escala o no, detectar cuándo un test prueba lo que dice probar, leer un diff de quinientas líneas y encontrar la que importa. Tenés que saber lo que sabe un senior y, además, darte cuenta de cuándo la herramienta se equivoca con total convicción. La IA no bajó la barrera. Automatizó los escalones de abajo.

Los números del mercado cuentan lo mismo desde el otro lado. Según el último informe de talento de SignalFire, la contratación de perfiles de entrada cayó cerca de un 65% en las grandes tecnológicas y un 76% en las startups en etapa temprana, comparado con 2019. Un estudio de Stanford encontró que el empleo de developers de entre 22 y 25 años bajó casi un 20% desde su pico de fines de 2022. Mientras tanto, las búsquedas se corren hacia arriba: cada vez más, lo que las empresas quieren son perfiles con años de experiencia.

Si un junior con IA fuera un senior, el mercado estaría contratando juniors. Está haciendo lo contrario.

Un estudio de la Universidad Nacional de Seúl entrevistó a developers senior y junior sobre esto. Uno de los seniors lo dijo mejor que yo:

“Te volvés senior porque la experiencia te enseña qué no hacer. Ahora los juniors ya no pueden aprender de los malos ejemplos.”

Cómo se resuelve eso es otro texto.

Supervisores

Creo que vamos hacia un lugar que, en parte, ya habitamos: el ingeniero como supervisor de agentes. Menos escribir, más definir, revisar, decidir.

Pero “supervisor” suena más cómodo de lo que es. El trabajo no es mirar cómo trabaja la IA y aprobar. El trabajo es asegurar resultados con IA y, muchas veces, a pesar de la IA. De sus sesgos, de su confianza, de su tendencia a resolver el problema que le describiste en lugar del que tenías. Y para eso, la única herramienta que no cambia con cada release es lo que trae cada uno: los golpes recibidos, los sistemas que viste caer, el olfato.

Entonces, ¿está en peligro el oficio? Vuelvo a la pregunta del principio y no tengo una respuesta limpia. Creo que el oficio de escribir código, tal como lo conocimos, está cambiando para siempre. Creo que el oficio de entender sistemas, anticipar problemas y decidir bien con información incompleta vale más que nunca. Y creo que la industria, en este momento, está confundiendo uno con el otro.

Tal vez el miedo sea infundado. Tal vez no.

Mientras tanto, abro la ronda catorce y leo el diff entero.