Aprender lento vale

Empiezo con un momento concreto, que ya mencioné de pasada en otro post pero acá va completo. Estaba armando una animación en SVG, el formato de imagen que se dibuja con código y se puede mover con código. Quería un ícono que respirara, que se sintiera vivo sin parecer un GIF malo. Estaba en Cursor, un editor de código con IA integrada, y ya tenía escrito el prompt, el pedido en texto que se le manda a la IA. Pero me daba cuenta de que lo que estaba describiendo era muy vago, porque no tenía mucha experiencia animando SVGs.

Y paré en ese momento. No porque la IA no pudiera entenderme y hacerlo mejor que yo en cinco minutos; seguramente podía. Paré porque quería entender de qué va animar un SVG: por qué una curva, la forma en que un movimiento acelera y frena, se ve suave y otra no. Quería poder mirar el resultado después y decir “acá está mal” con argumentos, no con vibes.

Lo que perdés cuando no aprendés

Hay una diferencia grande entre usar algo y entenderlo. La IA te empeora esa diferencia porque cierra la brecha tan rápido que nunca la sentís.

Te pasó con una regex, seguro. Una regex es un patrón de texto para validar o buscar cosas, como un email. Pedís “dame una regex que valide emails” y te devuelve algo con lookaheads y grupos nombrados, los trucos avanzados del oficio. Funciona. Corrés los tests, pasan, shipeas. Pero si alguien te pregunta por qué ese (?= está ahí, mirás el techo.

Lo mismo con la animación. La IA te tira un SVG con transforms anidados (movimientos apilados uno adentro de otro), curvas de aceleración raras, trazos que se dibujan solos con stroke-dashoffset. Se ve bien en Chrome y medio raro en Safari. No sabés si es un error del navegador o de tu código, porque nunca construiste uno a mano.

El conocimiento superficial funciona hasta que deja de funcionar, y cuando falla no tenés con qué diagnosticar.

Dos cosas que ganás yendo lento

Cuando te bancás el aprendizaje lento, o hacés un curso tradicional (algo que hoy parece que se dejó de hacer, porque “la IA resuelve todo”), ganás dos cosas que la velocidad no te da.

La primera es criterio. Sabés qué pedirle a la IA porque sabés cómo se ve una buena solución en ese dominio. En vez de “haceme una animación linda” le decís “ease-out en el scale, mantené el transform-origin centrado, evitá animar el d del path si podés usar transform”. En palabras comunes: que el agrandado frene suave al final, que gire desde el centro, y que no redibuje la forma entera si alcanza con moverla. El prompt mejora porque vos mejoraste primero.

La segunda es diagnóstico. Podés mirar lo que devuelve la IA y detectar cuando algo no está bien, porque al aprender desarrollaste intuición en el dominio: la animación que funciona en Chrome pero se rompe en Safari, la regex que pasa los casos obvios pero explota con acentos o emojis (unicode), el CSS que se ve bien en la demo pero se traba en el celular. Sin entender el dominio, solo podés kickbackear lo obvio, o sea devolverle a la IA los errores que saltan a la vista. Con el dominio, ves el problema real.

Seguir aprendiendo de la manera tradicional, lento, sufriendo cuando las cosas no salen, no te hace peor prompt engineer (la persona que sabe pedirle cosas a la IA), sino el único tipo de prompt engineer que importa: el que puede auditar lo que sale y explicar lo que hace falta desde un lugar de autoridad.

No es todo o nada

No quiero decir con esto que haya que hacer todo a mano. Eso sería ridículo hoy, y no me refiero a eso.

El punto es otro: no dejar que la comodidad te convenza de que no hace falta saber del dominio sobre el que estás pidiendo. Hay cosas que se pueden vibecodear sin culpa, es decir pedirlas y aceptar el resultado sin mirar mucho el código: un script de una sola vez y bajo riesgo, un boilerplate (el código de relleno que sale igual siempre) que no vas a volver a tocar, o una conexión con el servicio de un tercero que solo necesitás que funcione hoy.

Pero hay cosas donde ir lento todavía tiene sentido: patrones nuevos que vas a usar seguido, técnicas que aparecen en todo tu laburo (CSS, SQL, animaciones, system design, o sea cómo se arma un sistema entero), y dominios donde la IA se equivoca seguido y vos tenés que ser el filtro.

La regla que conté en el otro post sigue siendo la misma: si algo me va a pedir criterio en seis meses, me banco aprenderlo ahora. Si es descartable, la IA.

¿Nosotros también?

La paradoja de arrancar con IA es que los que más la exprimieron al principio fueron los que más años llevaban aprendiendo sin ella. Toda esa lentitud previa fue la base. Sin ella, el prompting es adivinar. Con ella, es dirigir.

La IA va a seguir mejorando. Va a hacer animaciones SVG, regex, migraciones de base de datos (mover datos guardados de un formato a otro), todo, mejor que hoy. Eso no cambia la pregunta de fondo: ¿seguimos mejorando nosotros?

Yo intento parar la pelota de vez en cuando. Sigo invirtiendo tiempo en aprender dominios nuevos que podría haber resuelto con un prompt. Tiempo que podría haber usado para aprender la “última tool” de IA. Porque cada vez que aprendo algo a mano, la próxima vez que uso la IA salgo con algo mejor, no solo con algo más rápido.

Esa inversión es lenta, a veces fea y difícil de medir en un sprint de dos semanas, pero es la que separa a alguien que vibecodea de alguien que construye.