“Sí, dejo que la IA escriba el código, pero después yo lo reviso, lo depuro y corrijo todo lo que hace falta.”

Cada vez que leo ese tipo de comentarios siento que estamos intentando demostrar algo, aunque no estoy seguro de qué. Pareciera que existe la necesidad de dejar claro que seguimos siendo nosotros los artifices del código y que la inteligencia artificial es solamente una mal ayudante. Como si revisar el código generado fuera la prueba definitiva de que el mérito continúa siendo humano.

Lo que me llevo a escribir este post (tweet) en X.

“Opinión impopular: optimizar el input suele ser mucho más rentable que depurar el output. Antes de escribir el primer prompt, asegúrense de comprender el problema, el contexto y el objetivo.”

Mientras más vueltas le daba, más claro tenía que ese tweet nunca había tratado de prompts. Tampoco de inteligencia artificial. En realidad, intentaba poner en palabras una incomodidad que llevaba tiempo sintiendo y que, hasta ese momento, no había logrado explicar.

Creo que la IA se está convirtiendo en el espejo más incómodo que hemos tenido los desarrolladores. No porque exponga nuestras limitaciones para escribir código, sino porque refleja, con una honestidad brutal, la calidad de nuestro razonamiento antes de comenzar a construir.

Y quizá esa sea la conversación que realmente deberíamos estar teniendo.

---

El reflejo del problema

Cuando un agente genera una implementación que no resuelve el problema, nuestra reacción suele ser inmediata. Culpamos al modelo. Decimos que razonó mal, que interpretó incorrectamente el contexto o que todavía está lejos de ser capaz de reemplazar a un desarrollador.

En muchos casos tendremos razón. Los modelos se equivocan. Hacen suposiciones incorrectas, utilizan APIs obsoletas, ignoran restricciones importantes o simplemente producen una solución mediocre. Eso seguirá ocurriendo durante algún tiempo.

Pero esa explicación también puede convertirse en un refugio demasiado cómodo.

Antes de preguntarnos qué hizo “mal” la IA quizá deberíamos hacernos una pregunta mucho más incómoda: ¿qué tan bien entendimos nosotros el problema que le pedimos resolver?

Después de todo, la IA no descubre objetivos ocultos. No interpreta necesidades que nunca fueron expresadas. No puede inferir restricciones que nosotros mismos no identificamos. Trabaja con el contexto que recibe y toma decisiones a partir de él.

Por eso empiezo a pensar que la calidad del código generado por una IA rara vez depende únicamente del modelo. Antes de que exista una implementación ya hubo una cadena de decisiones: alguien entendió un problema, definió un objetivo, identificó restricciones y decidió qué significaba realmente tener éxito.

Cuando esa parte del trabajo es sólida, la implementación suele serlo también. Cuando no lo es, la IA simplemente termina reflejando esa falta de claridad.

La IA no solo genera una implementación. También hace visible la calidad del trabajo intelectual que ocurrió antes de pedirle que comenzara a construir.

---

La implementación como consecuencia

Durante décadas identificamos el desarrollo de software con la capacidad de escribir código. Era una asociación natural. Hasta hace muy poco, implementar era la única manera de convertir una idea en un producto funcional.

Sin embargo, escribir código siempre fue la última etapa de un proceso mucho más complejo.

Antes hubo conversaciones con usuarios. Alguien tuvo que entender el negocio, descubrir restricciones, cuestionar supuestos, tomar decisiones difíciles, definir prioridades y establecer qué significaba realmente que una solución fuera correcta.

Ese trabajo rara vez producía una línea de código y, precisamente por eso, muchas veces pasaba desapercibido. Sin embargo, era el que terminaba determinando la calidad de todo lo que venía después.

Quizá por eso confundimos durante tantos años el medio con nuestro verdadero oficio. Pensamos que nuestro valor estaba en la implementación porque era la parte más visible del trabajo. La IA está rompiendo esa ilusión. Hoy puede escribir gran parte del código por nosotros, pero sigue siendo incapaz de hacer el trabajo intelectual que precede a toda implementación.

Programar siempre fue importante.

Comprender el problema que hay detrás de una implementación siempre fue más importante.

---

Delegar no significa dejar de pensar

Cuando hablamos de agentes de IA repetimos constantemente una palabra: delegar.

Sin embargo, sospecho que muchas veces la utilizamos como si significara desentendernos.

Delegar nunca ha significado eso.

Cuando un arquitecto explica una solución a su equipo, nadie espera que los desarrolladores descubran por intuición qué intenta resolver el negocio. Antes de comenzar a implementar existe una conversación donde se aclaran objetivos, restricciones, prioridades y criterios de éxito. La implementación empieza cuando el problema ya fue entendido.

Con la IA debería ocurrir exactamente igual.

Delegar la implementación no significa delegar el razonamiento.

Seguimos siendo nosotros quienes debemos responder las preguntas realmente importantes.

• ¿Qué problema estamos resolviendo?
• ¿Por qué es importante resolverlo?
• ¿Qué restricciones no pueden romperse?
• ¿Cómo sabremos que la solución es correcta?
• ¿Qué riesgos debemos evitar?

Solo cuando esas respuestas existen tiene sentido pedirle a alguien, humano o artificial, que comience a construir.

Porque ninguna implementación puede tener más claridad que la claridad con la que fue concebida.

---

El problema nunca fue la IA

Lo interesante es que esta situación no nació con los modelos generativos.

Durante años vimos proyectos fracasar porque el equipo construyó exactamente lo que creyó que debía construir, pero no lo que el negocio realmente necesitaba. Escuchamos una y otra vez frases como “el desarrollador entendió mal” o “eso no era lo que habíamos pedido”.

Con frecuencia responsabilizábamos a quien escribió el código.

Con mucha menos frecuencia nos preguntábamos si el problema había comenzado mucho antes, cuando nadie había logrado definir correctamente qué era lo que realmente necesitábamos construir.

La IA no inventó ese problema.

Lo único que hizo fue eliminar las capas intermedias que antes lo ocultaban.

Hoy el recorrido entre una idea y una implementación puede durar apenas unos minutos. Esa velocidad hace mucho más evidente que una comprensión deficiente del problema casi siempre termina produciendo una implementación deficiente.

No importa si quien implementa es un desarrollador junior, un arquitecto con veinte años de experiencia o un agente de IA.

La calidad de la implementación siempre será un reflejo de la calidad del razonamiento que ocurrió antes.

---

El verdadero espejo

Quizá ese sea el mayor cambio que está provocando la inteligencia artificial.

Durante años pensamos que estas herramientas pondrían a prueba nuestra capacidad para escribir código. Hoy empiezo a creer que están poniendo a prueba algo mucho más importante: nuestra capacidad para comprender un problema antes de intentar resolverlo.

Cada vez que un agente genera una solución muy distinta de la que esperábamos solemos pensar que estamos evaluando a la IA.

Tal vez ocurra exactamente lo contrario.

La IA nos está evaluando a nosotros.

Nos obliga a enfrentarnos con las decisiones que nunca terminamos de tomar, con las restricciones que olvidamos mencionar, con las ambigüedades que pasamos por alto y, sobre todo, con la calidad de nuestro propio razonamiento.

Quizá por eso sigo creyendo que optimizar el input suele ser mucho más rentable que depurar el output. No porque la IA nunca se equivoque, sino porque la mayor parte del valor del desarrollo de software siempre ocurrió antes de escribir una sola línea de código.

Quizá ese sea, al final, el verdadero aporte de la inteligencia artificial. No escribir código, ni siquiera escribirlo más rápido. Su mayor contribución puede ser otra mucho más incómoda: haber convertido en visible una habilidad que durante décadas pasó casi desapercibida.

Siempre pensamos que el desarrollo de software comenzaba cuando alguien abría un editor y escribía la primera línea. Hoy resulta cada vez más evidente que el verdadero trabajo ocurre mucho antes, cuando entendemos el problema, tomamos decisiones y construimos el contexto que hará posible una buena implementación.

Tal vez por eso el código que genera una IA rara vez habla únicamente de ella. En realidad, habla del desarrollador que decidió delegarle el problema. Habla de la claridad con la que comprendió el contexto, de las decisiones que tomó antes de implementar y, sobre todo, de la calidad de su razonamiento.

Quizá ese sea el espejo más incómodo que la IA nos ha puesto delante. No porque nos muestre qué tan bien programa una máquina, sino porque nos obliga a preguntarnos qué tan bien pensamos nosotros antes de empezar a construir.