La IA nos hizo rápidos. ¿Pero nos hizo mejores?

Empiezo con una confesión: me encantan las herramientas de IA para código. Uso Cursor, Claude, flujos agénticos, todo el stack. He deployado cosas en horas que me hubieran llevado días. He armado prototipos un fin de semana que antes hubieran sido proyectos de “el trimestre que viene”. Se siente como un cheat code.

Y justo por eso me preocupa.

La trampa de la productividad

Hay algo de lo que nadie habla en las conferencias de IA para dev tools: si un agente escribe 10x más código que vos, hay 10x más posibilidades de que meta un bug. No es una opinión polémica, es matemática. Pero de alguna forma desarrollamos un sesgo colectivo donde asumimos que el output de la IA probablemente está bien.

¿Por qué? Porque una o dos veces, clavó el problema perfecto. Refactorizó esa función desordenada. Escribió esa regex que venías evitando. Armó un componente entero con un prompt de una línea. Y a partir de ese momento, bajamos la guardia. Dejamos de leer cada línea. Empezamos a vibecodear.

Lo entiendo. Leer código generado por IA es aburrido. Es como corregir un ensayo de otro. Sabés que la forma general está bien, así que tus ojos se deslizan sobre los detalles. Pero los detalles es donde viven los bugs. Los detalles es donde pasan las decisiones arquitecturales sutiles que vas a tener que bancar los próximos dos años.

El punto medio que no existe

Vengo pensando mucho en esto, y llegué a una conclusión incómoda: no hay un buen punto medio entre “yo controlo el código” y “dejo que los agentes hagan todo y ni miro.”

Pensalo. El momento en que delegás todo a agentes que pueden producir 100x más código que vos, no hay forma de mantener el ritmo como reviewer humano. Tendrías que delegar también la revisión de código. Y después el testing. Y después las decisiones de arquitectura. Es delegar infinitamente.

Históricamente, los equipos de ingeniería construyeron guardrails justamente porque no confiábamos en que una sola persona lo hiciera bien: checklists, aprobaciones múltiples, aprobaciones del director de ingeniería. Esos procesos existían para imponer la lentitud como valor. Para asegurarse de que nadie pusiera algo dudoso solo porque tenía apuro.

Esos procesos no desaparecieron, pero el espíritu detrás recibió un golpe. La vibra pasó de “seamos cuidadosos” a “seamos rápidos.” Y la velocidad es genial, hasta que no lo es.

El arma secreta del developer experimentado

Acá hay algo que creo que se pierde en el hype de la IA: la habilidad más importante de un developer senior nunca fue la velocidad de tipeo. Es el criterio. Saber cuándo decir que no. Cuándo decir “no, no deberíamos construir eso.” Cuando un requisito de producto suena razonable pero va a crear una pesadilla de mantenimiento.

Los agentes de IA están felices de construir lo que les tires. Esa es toda su onda. Les decís “construílo”, lo construyen. No te dicen que no. No te dicen que la feature no vale la complejidad. No tienen opiniones sobre si esta migración es la decisión correcta, o si estás complicando de más una solución para un problema que todavía no existe.

Ese criterio viene de años de cometer errores, mantener malas decisiones, y desarrollar lentamente una intuición de cómo se ve el buen software. Lo que me lleva a la parte de la que realmente quiero hablar.

Aprender lento es un superpoder

El otro día me encontré a punto de pedirle a Claude que me genere una animación SVG. Y frené. No porque la IA no pudiera hacerlo. Absolutamente podía, probablemente mejor que yo en un primer intento. Sino porque quería entender cómo funciona.

Esta es la paradoja del trabajo asistido por IA: la razón por la que fuimos tan productivos cuando aparecieron las herramientas de IA es que habíamos pasado años aprendiendo las cosas de la forma difícil. Toda esa lentitud, ese dolor, seguir tutoriales, leer Stack Overflow, esa frustración de “¿por qué no funciona?” Esa es la base que nos hizo buenos al prompting. Sabíamos qué pedir porque sabíamos cómo se veía la respuesta.

Si dejamos de invertir en ese aprendizaje lento, estamos matando a la gallina de los huevos de oro. Vamos a ser más rápidos en el corto plazo y más tontos en el largo plazo. Vamos a convertirnos en prompt jockeys que no pueden debuggear el output cuando el modelo se equivoca. Y se va a equivocar.

Así que vengo haciendo un esfuerzo consciente por seguir aprendiendo cosas manualmente. No todo, obvio. No estoy escribiendo migraciones SQL a mano por diversión. Pero cuando me encuentro con algo que no entiendo, una técnica de CSS, una librería de animaciones, un patrón de system design, trato de bancármela. Construirlo a mano. Cometer errores. Ir lento.

Resulta que aprender lento también te hace un mejor prompt engineer. Cuando entendés un dominio profundamente, podés detectar cuando la IA está segura pero equivocada. Podés escribir prompts que guían al modelo hacia soluciones realmente buenas en vez de solo soluciones que parecen buenas. Podés revisar el output con expertise real en vez de vibes.

¿Entonces qué hacemos?

No tengo una respuesta clara. No te voy a decir que dejes de usar herramientas de IA. Yo seguro que no. Pero creo que necesitamos ser honestos sobre los trade-offs.

Velocidad no es calidad. Output no es valor. Y el developer que puede hacer la cosa sin la IA siempre va a ser mejor haciéndola con la IA.

Seguí aprendiendo lento. Seguí construyendo cosas de la forma difícil a veces. Mantené ese músculo vivo.

Porque los agentes van a seguir acelerándose. La pregunta es si nosotros vamos a seguir mejorando.