He estado ausente de este espacio. No por falta de ideas, sino porque cada minuto libre que tengo se lo ha estado llevando Aether, y el nuevo trabajo terminó de comerse lo que sobraba. Pero aquí estamos de vuelta, intentando ordenar algunas cosas que llevo semanas dando vueltas en la cabeza.

Voy a empezar por un experimento que hice hace unos días y que me dejó pensando más de la cuenta.

Aether lo he venido construyendo a mano, como siempre. Decisiones de arquitectura, modelo de datos, contratos, los pedazos críticos del backend. Eso lo escribí yo, línea por línea, con sus discusiones internas, sus rewrites y sus noches malas. No es un producto vibecoded ni quiero que lo sea.

Pero hace poco quise probar algo distinto. Tenía una feature acotada por agregar a Aether CLI, con sus boundaries bien definidos, y decidí delegarla por completo a un agente de IA. Le pasé el contexto, le di permisos para tocar el repo y me quedé viendo cómo trabajaba. Iba leyendo archivos, decidiendo dónde hacer los cambios, escribiendo el código, corriendo los tests. Todo en TypeScript, dentro de un proyecto que conozco línea por línea, sin que yo tocara el editor. Funcionó. Funcionó al primer intento.

Lo raro no fue que funcionara. Lo raro fue después, cuando intenté reconstruir mentalmente lo que acababa de pasar y me di cuenta de que no podía. No porque el código fuera complejo, sino porque yo no había estado presente mientras se escribía.

La fricción que se evaporó

Antes, cuando peleaba con un bug durante días, había una especie de catarsis al final. Una sensación de haber sufrido por algo y haberlo entendido. El código que escribías te cambiaba a ti tanto como tú cambiabas al código. Te ibas a dormir con una pregunta abierta y amanecías con una intuición nueva. Esa fricción era parte del oficio.

Ahora la fricción se evaporó. Y con ella, una parte importante de lo que significa construir software.

Lo curioso es que el resultado de ese experimento es objetivamente mejor que si lo hubiera hecho yo a mano un viernes en la noche. El código está más probado, mejor documentado, los commits más limpios. Pero esa parte específica del producto ya no me pertenece de la misma manera. Es como si me hubieran entregado una habitación amueblada dentro de una casa que sí construí. Vivo ahí, sí, pero no la conozco por dentro como conozco el resto.

Y creo que cualquier ingeniero que esté siendo honesto consigo mismo está sintiendo algo parecido cuando hace este tipo de pruebas, aunque no lo diga en voz alta.

La trampa de revisar lo que no escribiste

La parte que nadie quiere admitir es que ya no estamos revisando el código que el modelo genera. No de verdad.

El agente va a mil kilómetros por hora. Tú estás a treinta, tratando de leer línea por línea, intentando entender por qué eligió esa abstracción y no otra. Es imposible mantener el ritmo. Después de un par de días dejas de pelear y empiezas a aprobar pull requests basándote en si los tests pasan y si la feature hace lo que prometiste en el ticket. Es una forma nueva de confiar, más parecida a la selección natural que a la ingeniería. Si sobrevive a los tests, queda. Si no, se borra.

Eso funciona hasta que algo falla en producción a las tres de la mañana y nadie en el equipo, incluyéndome a mí, entiende realmente cómo está construida la parte que se rompió.

---

El cálculo que están haciendo las empresas

En Marzo de este año fui parte de una de esas decisiones en Oracle. Estaba en medio de una migración a microservicios, moviendo infraestructura a OKE, sin la menor señal de que algo estuviera pasando. Una invitación a una reunion en la bandeja de entrada y se acabó.

La prensa ya venía hablando del plan desde semanas antes. Que Oracle iba a recortar entre veinte y treinta mil personas para liberar varios miles de millones de dólares y meterlos en infraestructura de IA. Yo había leído las notas como cualquier otra persona, sin terminar de creer que algo así me fuera a tocar.

La empresa no estaba en pérdidas. No había falta de clientes. Era un movimiento de capital, desviar nómina hacia GPUs y centros de datos, y vendérselo al mercado como visión a largo plazo.

Desde entonces tengo una pregunta dando vueltas. Si la IA realmente nos hace más productivos, ¿por qué las empresas están despidiendo ingenieros en lugar de construir más cosas?

La respuesta no es técnica, es financiera.

Da igual que sean diez ingenieros o treinta mil, la aritmética es la misma. Despedir gente y ahorrar millones es un número que se puede llevar a la siguiente llamada con inversionistas. Es certeza. Aterriza limpio en el reporte trimestral. Construir más, en cambio, es una apuesta. Necesitas mercado, necesitas demanda, necesitas que la inversión se traduzca en ingreso, y nada de eso pasa en noventa días.

Entonces, cuando las dos opciones aparecen sobre la mesa de un comité de dirección, ahorro seguro contra crecimiento incierto, ya sabes cuál gana. Siempre la misma. No porque sea la mejor decisión, sino porque es la decisión más fácil de defender.

Le pasa nombre a esto cuando se ve desde lejos: es falta de imaginación. Tienes en las manos una herramienta capaz de construir cosas que hace dos años eran imposibles, y lo primero que se te ocurre es reducir nómina.

Comerse las semillas

Lo que más me preocupa no es lo de hoy. Es lo de dentro de diez años.

Las empresas están dejando de contratar perfiles junior porque, en teoría, el modelo ya hace lo que ellos harían. Pero eso es exactamente como un agricultor que se come las semillas que necesita para plantar el año siguiente. Sobrevives el invierno, claro. Pero cuando llegue la primavera no vas a tener nada que sembrar.

En diez años, cuando los senior de hoy estemos cerca de retirarnos o ya cansados de pelear con sistemas legacy llenos de código que nadie entendió desde el día uno, ¿quién va a saber cómo funciona esto realmente? ¿De dónde van a salir los ingenieros capaces de leer un stack trace, abrir el debugger, y entender por qué un servicio se cae bajo carga si nunca tuvieron la oportunidad de equivocarse en pequeño antes de equivocarse en grande?

Aprender a programar no es solo aprender sintaxis. Es construirse un mapa mental de cómo se comportan los sistemas, y ese mapa solo se construye chocando contra las cosas. Si le quitas el choque a la siguiente generación, vas a terminar con gente capaz de hablarle a un agente, pero sin nadie capaz de explicarle al agente por qué está equivocado.

El cuento de los 10x

Hay un estudio reciente que mostró que los desarrolladores experimentados que usan IA son, en promedio, alrededor de un 19% más lentos que los que no la usan. Léelo otra vez. Más lentos, no más rápidos.

La narrativa oficial dice que la IA te hace diez veces más productivo. La realidad, al menos para perfiles senior trabajando en sistemas complejos, parece ser otra. Pasas tiempo revisando código que no escribiste, dándole contexto al modelo del que te tomaría resolverlo solo, y deshaciendo decisiones raras que el agente tomó porque no entendió la intención real del cambio.

La herramienta sirve, no estoy diciendo que no. Pero la productividad real es bastante más matizada que el demo bonito donde aparece código en pantalla en cuestión de segundos.

---

El nuevo filtro

Hay una idea que me parece interesante y que casi nadie está mencionando.

Durante décadas, el costo del software fue básicamente el costo de los ingenieros. Ese costo era un filtro natural. Solo los problemas que tenían suficiente valor económico justificaban contratar a alguien para resolverlos. Lo demás se quedaba sin hacer.

La IA, en el corto plazo, ha eliminado ese filtro. De golpe, problemas que antes no eran rentables ahora se pueden atacar porque cuesta casi nada generar código. Pero ¿qué pasa si los modelos buenos se vuelven caros? ¿Qué pasa cuando cada code review, cada test generado, cada sesión de debugging, cada refactor empieza a costar tokens medibles que aparecen en la factura?

Volvemos al mismo lugar, pero por otra puerta. El filtro no desaparece, cambia de forma. Antes era el salario del ingeniero. Mañana puede ser el costo de la inferencia. Y entonces vamos a volver a preguntarnos si vale la pena construir esto o aquello, igual que antes, solo que ya nadie va a tener las habilidades para hacerlo a mano si la cuenta no da.

Lo que me queda dando vueltas

No tengo una conclusión limpia para esto. La dejo abierta porque así es como lo estoy viviendo.

Lo cierto es que estoy enviando producto a producción a una velocidad que hace dos años habría parecido imposible. Cosas que habrían tomado meses, las tengo corriendo en días. Eso es real y no lo voy a negar.

Pero también hay algo que se está perdiendo y que todavía no encuentro cómo nombrar bien. Tiene que ver con el oficio, con la conexión entre lo que haces y quién eres después de haberlo hecho. Con esa idea, quizá pasada de moda, de que el código no es solo un medio sino también una forma de pensar.

No sé bien dónde aterriza esto. Igual ni romantizar el sufrimiento de antes ni rendirse al modelo sin condiciones son la salida. Igual lo único que cabe por ahora es mirar lo que está pasando con honestidad y aceptar que estamos en una etapa donde todavía no sabemos qué se queda y qué se va.

Por ahora me quedo con la duda. Que no es poco.