Operar la IA es fácil. Dirigirla es el oficio.

Le preguntas a un ingeniero por qué ha resuelto algo de una forma concreta y, cada vez más, la respuesta es "es lo que me sugirió la IA". Punto. Y se queda tranquilo ahí. Y no hablo tanto de perfiles junior...

Va una pregunta, y no es retórica: ¿cuándo fue la última vez que rechazaste una sugerencia de la IA no porque fallara los tests, sino porque no encajaba con tu sistema?

Yo tardé en saber responderla. Hace un par de años, cuando la herramienta era nueva, casi todo lo que generaba me parecía un regalito y lo aceptaba sin mirarlo mucho. Entonces aceptar a ciegas costaba poco, porque generaba poco: un par de funciones, un test. Ahora te genera un sistema entero en una tarde, y aceptar a ciegas cuesta otra cosa.

El problema no es la herramienta, es la posición que adoptas frente a ella

Esto no va de prompts. Hay guías muy buenas sobre cómo sacarle más a la herramienta, y esta no es una de ellas. La pregunta que me interesa es otra: qué se vuelve valioso cuando ya usas IA todos los días, que es algo que a estas alturas hace casi todo el mundo. El dominio de la herramienta dejó de ser un diferencial el día que se volvió mainstream.

Apoyo a siete equipos en Mercadona Tech, y las conversaciones que de verdad importan ya casi nunca son sobre cómo escribir algo. Son sobre si ese algo debía escribirse, sobre qué se rompe si falla, sobre quién lo sostiene cuando arde. Ninguna de esas la tiene la IA por ti.

Entre cómo usamos la IA hay un espectro, y ayuda mirar sus dos extremos. En uno está el operador: pide código, lo recibe, lo pega y lo masajea para que pase verde. Va rápido, pero su rastro de decisiones es opaco, para el equipo y, peor, para sí mismo. En el otro está el director: piensa antes, usa la IA para explorar y acelerar, pero mantiene la autoría de lo que sube a prod. Pero casi nadie vive en un extremo; nos movemos por el medio y, según el día y la prisa, derivamos hacia un lado o el otro. Lo que importa es hacia dónde derivas, porque cuando alguien te pregunta "¿por qué así?" tres semanas después, o tienes una respuesta o tienes un "es lo que me sugirió Claude".

El espectro: cómo usas la IA

Lo que un agente nunca firma por ti

Aquí está la clave, y es más estructural de lo que parece. La IA, sola o agéntica, es excelente generando opciones y ejecutándolas. Y es incapaz, no por inmadurez sino por construcción, de asumir la consecuencia de elegir mal en tu sistema.

Esa asunción es lo que avala un Product Engineer. Ningún agente da la cara por ti. Puedes tratar a la IA como una autoridad, y entonces lo que acumulas es deuda intelectual: código que funciona pero que no sabrías defender. O puedes tratarla como una herramienta que diriges, y entonces te multiplica. La diferencia no se ve a los seis minutos, cuando el PR pasa los tests y todo el mundo aplaude la velocidad. Se ve al cabo de un trimestre, cuando alguien abre esa zona y pregunta por qué está así.

Y la trampa llega disfrazada de productividad, que es lo que la hace peligrosa. Entregas más. Recibes elogios por lo rápido que vas. Tu calendario mete menos focus time porque, total, ya no hace falta pensar tanto. Y mientras tanto, sin que se note, cada PR que cierras contiene más decisiones que no son tuyas.

Cuando vuelves a un PR antiguo y te sientes ante código de otra persona, esa persona eres tú hace dos meses, el día que aceptaste sin mirar.

La práctica: la review mental antes de aceptar

Esto no se arregla con fuerza de voluntad ni con un propósito de año nuevo (sobre todo porque estamos en Junio 🙂). Se arregla con una práctica pequeña y repetida. El que más me ha servido es tratarme a mí mismo como reviewer del código que me da la IA, antes de aceptarlo. Tres preguntas, en orden:

1. ¿Lo aprobaría si me lo trajera un compañero a review? Si la respuesta es no, no lo aceptes. Es exactamente la misma vara de medir que usarías con cualquier humano. No tiene sentido bajarla porque el autor es una máquina.

2. ¿Podría explicárselo a otro ingeniero en menos de un minuto? Si no puedes, no lo entiendes lo suficiente como para responder por ello. Y avalar lo que no entiendes nunca fue el oficio, da igual quién escribiera el código.

3. ¿Sé qué se rompe si esto falla en producción? Si no lo sabes, no es código tuyo todavía. Es una sugerencia pendiente de adoptar.

Cuesta entre treinta segundos y dos minutos por bloque aceptado. Y alguien dirá: "claro, eso me ralentiza, y el punto de la IA era ir rápido". Lo entiendo, pero creo que es mirar la película equivocada. Lo que te ralentiza de verdad es el bug oscuro de dentro de seis meses en una zona que nadie entiende, la review que tu compañero hace dos veces porque tu PR rompe la coherencia del módulo, la pregunta que no sabes responder en tu performance review. Esos dos minutos son un seguro tirado de precio.

Un caso de los que veo cada semana

Pides a la IA un retry para una llamada a un servicio externo que a veces falla. Te devuelve una clase RetryPolicy, una interfaz, un factory RetryPolicyFactory.forX(), configuración en YAML con maxAttempts, backoffMs, jitterFactor. Cuatro archivos, treinta líneas de plumbing, un test del factory. Primera lectura: maneja timeouts, distingue errores reintentables, hay cobertura. Verde. Si te quedas en ser un operador, lo aceptas aquí.

Segunda lectura, la de director: tu sistema hace un solo tipo de retry, en un sitio, con unos valores que llevan dos años sin tocarse. No tienes el problema genérico para el que la IA ha resuelto. Tienes uno concreto. La versión sostenible es una función de doce líneas en el archivo donde ya vive esa lógica, con los valores literales en el cuerpo. Si mañana aparece un segundo caso de retry, lo generalizas entonces, con dos ejemplos reales, no con uno imaginado.

La IA no se equivocó. Hizo lo que hace siempre: la solución estándar para el problema genérico, porque es lo que ha visto miles de veces. La que conoce tu contexto operativo eres tú. Y ahí está la división de trabajo que de verdad aprovecha lo mejor de cada uno: ella produce alternativas más rápido, tú eliges mejor.

Por eso, cuando enfrento una decisión no trivial, intento no pedirle la solución. Le pido las opciones. "Dame tres formas distintas de hacer esto, con los trade-offs reales de cada una en complejidad, mantenibilidad y rendimiento. Después te digo cuál encaja con nuestro contexto." Ese prompt hace dos cosas a la vez: produce material para pensar y me coloca a mí como decisor, no como ejecutor. El cuello de botella ya no es generar opciones, sino elegir bien entre ellas con un contexto que la herramienta no tiene y tú sí.

Lo que no tengo claro

No voy a fingir que esto sea un estado al que llegas y ya te quedas. La frontera entre operar y dirigir no es una línea, es un gradiente, y la herramienta empuja hacia el lado fácil todos los días, a todos. Dirigir no se gana una vez. Es una elección que repites cada vez que aceptas un bloque, y el día que dejas de hacerla conscientemente, vuelves a resbalar. Lo veo en gente con bastante más oficio que yo.

Lo que de verdad no sé es hasta dónde llega esto. Si los agentes mejoran lo suficiente, quizá parte de lo que hoy llamo "dirigir" también se automatice. A largo plazo, te digo la verdad, no lo sé.

Pero hay algo que sí tengo claro: la responsabilidad de elegir mal en un sistema que está en producción de verdad no la asume un modelo. La asume una persona con nombre. Y mientras eso siga siendo así, saber dirigir vale más que saber teclear.

Esto, por cierto, es solo una de las seis dimensiones del oficio en las que llevo tiempo pensando. La de colaborar con la IA sin disolverse en ella. Las otras cinco (decidir qué construir, leer el sistema antes de tocarlo, escribir lo que aguanta, sostener el outcome más allá del merge, y hacer visible el trabajo que no se ve en el repo) las he reunido todas, con prácticas para aplicar desde el lunes y cuatro imprimibles, en un documento que se llama Producto, no código. Si esta te ha resonado, ahí tienes el mapa completo.

El cierre

El código es un medio, no el fin. Esa frase es fácil de subrayar y difícil de practicar, porque la herramienta empuja todo el rato en la dirección contraria: producir más, aceptar más rápido, pensar menos. Dirigir es resistir esa corriente sin renunciar a la velocidad que te da.

Cuando esa frase deja de ser un eslogan y se convierte en cómo decides cada lunes (qué aceptas, qué rechazas, qué firmas con tu nombre), eres un ingeniero distinto del que ayer pegaba sugerencias hasta que el CI se ponía verde. La IA no te lleva ahí. Te lleva al otro lado, si la dejas.

Así que te la dejo, la pregunta del principio: ¿cuándo fue la última vez que dijiste "no" a la IA porque no encajaba con tu sistema, no porque fallara los tests? Si te cuesta recordarlo, no lo leas como un defecto tuyo. Es la corriente, y tira de todo el mundo. Saber que está ahí es ya la mitad de lo que hace falta para remar en contra.

Me interesa de verdad cómo lo estás viviendo tú. ¿Diriges o operas? ¿Y cómo lo notas?