Así que te estás preparando para no volver a escribir nunca más una línea de código mientras asciendes al paraíso del vibe coding. Voy a intentar convencerte de que el hecho de que la programación asistida por IA permita a los desarrolladores concentrarse en tareas de mayor nivel y más impacto, en lugar de perder tiempo escribiendo código, tiene algunos inconvenientes. Voy a intentar hacerlo sin que pienses “skill issue” y sin que creas que soy algún tipo de ludita.

Hoy en día, las empresas tecnológicas y los desarrolladores en general están intentando agregar restricciones a la programación asistida por IA para hacerla más predecible, requerir menos iteraciones y producir código más seguro y mantenible. ¡Esto está muy bien! Esa parte tiene todo el sentido. Si vas a depender de estas herramientas, necesitás estructura.

En algunos equipos esto aparece como flujos de trabajo spec-first: describís el comportamiento, los casos borde y las restricciones junto con el agente, y luego le pedís a un agente que implemente en base a esa descripción.

En muchos de estos flujos, el rol del desarrollador se aleja casi por completo de la implementación. Te asegurás de que la documentación que describe la funcionalidad sea correcta, y luego revisás el código que el agente generó a partir de esa documentación. Incluso podrías delegar la revisión —o al menos complementarla— con otro agente que compare la documentación con los cambios reales. El código llega ya terminado.

Desde el punto de vista de la productividad esto es innegablemente efectivo, pero también cambia la forma en que te relacionás con el sistema.

El punto principal en el que creo y que quiero transmitir es que las personas mejoran su pensamiento de sistemas mediante su implementación. No por tipear por tipear, sino por verse obligadas a tomar decisiones: dónde van los límites, cómo fluye el control, qué significan los nombres, qué invariantes se cumplen de verdad. Mucha comprensión solo aparece cuando te comprometés con una estructura y tenés que convivir con ella.

Ese tipo de entendimiento es difícil de recrear solo haciendo review código generado. Escribir y hacer reviews no son la misma actividad. Reviewing verifica corrección y consistencia; escribir te obliga a pensar.

Hay un contraargumento muy razonable a todo esto. Para devs con experiencia, gran parte del trabajo real sucede antes de que se escriba una sola línea de código. El valor está en el juicio: entender los trade-offs, secuenciar cambios, anticipar modos de falla y gestionar el riesgo. Desde esa perspectiva, escribir código es mayormente ejecución, y delegarlo a un agente es una ganancia evidente.

Entiendo ese punto de vista, e incluso estoy de acuerdo con partes de él. Mejores herramientas nos permiten empujar más pensamiento hacia etapas previas, y eso es una mejora real.

Donde no estoy tan convencido es en tratar la programación práctica como algo opcional. Algunos insights solo aparecen durante la implementación. Algunos diseños solo revelan sus problemas cuando intentás expresarlos con precisión. Y cierta intuición solo se mantiene afilada si se ejercita.

Nada de esto es un argumento en contra de usar agentes. Las partes aburridas de la programación —boilerplate, refactors mecánicos, código de pegamento— son candidatas perfectas para delegar.

Lo que me preocupa es qué tan rápido estamos normalizando la idea de que toda la programación debería delegarse. Que los ingenieros solo piensen en términos de resultados y traten al código como un detalle de implementación que es mejor dejar en manos de otra cosa.

La cuestión es esta: a mí me gusta programar. Agregar una funcionalidad, arreglar un bug sutil, o darse cuenta a mitad de camino de que un diseño puede ser más simple de lo que pensabas sigue siendo trabajo valioso. No solo porque se siente bien, sino porque construye entendimiento.

Probablemente haya un punto medio acá. Dejar que los agentes aceleren el trabajo. Que se encarguen de lo aburrido y mecánico. Pero seguir eligiendo, de manera deliberada, escribir código real en los lugares que importan, incluso si eso nos hace un poco más lentos.

Sí, hay algo de nostalgia en eso. Está bien. Somos humanos, no optimizadores de throughput. El disfrute, la intuición y la agudeza a largo plazo también cuentan.