Los agentes de IA y el futuro del desarrollo de software

Qué cambió, en concreto

Hace un año, añadir un cuarto idioma a este sitio significaba una tarde larga de ediciones mecánicas. Hace poco fue una sola instrucción y una pasada de revisión. Eso es un cambio real en lo que puede producir una jornada de trabajo, y ocurrió sin ningún cambio en lo bien que entiendo el sistema.

Las partes que se abarataron son las que nunca me gustaron: renombrar un concepto en todas partes, conectar un campo nuevo a través de cinco capas, escribir la misma prueba con otra forma. Las partes que siguen siendo caras son las que deciden si el software es bueno o no.

El cuello de botella se movió a la especificación y la verificación

Cuando el código abunda, lo escaso es saber exactamente qué construir y poder demostrar que existe.

Ahora paso más tiempo escribiendo un enunciado preciso del problema que escribiendo código, y más tiempo comprobando el comportamiento desplegado que revisando un diff. Dos veces el mes pasado un cambio compiló, pasó sus comprobaciones de tipos y no hizo nada, porque un serializador descartó un campo y porque un archivo generado se produjo antes de que existieran los datos que necesitaba.

Un agente habría cerrado los dos tickets como terminados. Ninguno lo estaba.

Qué hago de otra forma

Cambios más pequeños. Un diff que puedo leer de una sentada, verificado en producción antes de que empiece el siguiente. Una vuelta atrás que he probado de verdad. Pruebas que afirman el comportamiento que un cliente notaría en lugar de detalles de implementación que halagan una cifra de cobertura.

Y una regla clara sobre los hechos: no dejo que la prosa generada afirme nada que no pueda señalar. Los casos de estudio de este sitio se montan con datos que ya existían, no salen de la imaginación, porque un párrafo seguro sobre un cliente que no existe es peor que una sección vacía.

Lo que los agentes todavía no pueden hacer

No pueden decidir qué debería ser el producto. No pueden decirte que la funcionalidad que pediste va a confundir al usuario, ni que la regla de negocio está mal. No pueden saber que el número del párrafo es falso a menos que algo en el repositorio diga lo contrario.

Tampoco son fiables con el fallo. Un modelo informará de éxito porque las operaciones que puede ver salieron bien, mientras que el resultado real se perdió tres capas más abajo.

La predicción que estoy dispuesto a hacer

Espero que los equipos de software se dividan por disciplina y no por número de personas. Los equipos que ya tenían pruebas, revisión y una forma de volver atrás irán más rápido que nunca. Los equipos que publicaban por intuición publicarán más código que no entienden, y los fallos serán más silenciosos y más caros.

La tecnología no cambia qué es la buena ingeniería. Cambia la rapidez con la que llegan las consecuencias.

Qué le diría ahora a un ingeniero junior

Aprende el sistema que hay debajo de la herramienta. Entiende la petición, la cola, el límite de la transacción, el despliegue. El modelo escribirá el código más rápido que tú; la persona que sabe decir por qué está mal seguirá siendo la que importa.