El futuro de los desarrolladores: menos código, más arquitectura

La economía cambió de lado

Durante cincuenta años, escribir código fue la parte cara del software. Todo en la profesión se organizó alrededor de eso: lenguajes para escribir menos, frameworks para no repetirse, bibliotecas para no reescribir, estimaciones medidas en cuánto código faltaba.

Esa premisa cayó. Producir código correcto e idiomático se volvió barato y rápido. Y cuando el costo de una etapa se desploma, el cuello de botella se muda a la siguiente.

La siguiente es decidir si ese código debería existir y si está bien.

Lo que se encarece cuando escribir se abarata

Verificar. Leer mil líneas con atención cuesta lo de siempre. Los equipos que aceleraron la producción sin acelerar la revisión están acumulando deuda invisible — código que pasó porque parecía correcto.

Integrar. Un sistema que funciona solo y un sistema que convive con otros siete son cosas distintas. Contratos entre servicios, versionado, compatibilidad hacia atrás, qué hacer cuando el otro lado se cae: nada de eso lo decide la IA por ti, porque depende de acuerdos entre equipos.

Operar. Costo de infraestructura, latencia, observabilidad, plan de vuelta atrás. El código generado en masa suele ser técnicamente correcto y operativamente ingenuo — funciona, pero nadie pensó cuánto cuesta ejecutarlo mil veces por minuto.

Elegir qué no hacer. La restricción siempre fue la capacidad de entrega. Con esa restricción aflojada, lo que queda es la disciplina de decir que no — y es escasa.

La arquitectura no es un diagrama

Cuando digo que el trabajo migra hacia la arquitectura, no hablo de dibujar cajitas ni de un cargo con la palabra "arquitecto". Hablo de cuatro actividades concretas:

Definir fronteras. Qué es un módulo, qué expone, qué esconde, quién puede llamar a quién. En un mundo de código generado, una buena frontera es lo que impide que el desorden se propague — y lo que le da al agente un pedazo lo bastante pequeño para trabajar con seguridad.

Elegir restricción en vez de posibilidad. Tipado fuerte, esquemas validados, migraciones versionadas, tests de contrato. Cada restricción que impones es una clase entera de error que el código generado no puede cometer. Eso pasó de "buena práctica" a "infraestructura de seguridad".

Diseñar para la verificación. Si la salida de un componente solo puede juzgarla un humano leyéndola, no escala. Si puede comprobarse con un test, un tipo, una invariante o un monitor, escala. Diseñar sistemas verificables se volvió la habilidad central.

Decidir el costo. Dónde vale la pena gastar, dónde vale simplificar, qué aguanta hacerse mal a propósito. Criterio económico aplicado al software.

El desarrollador sénior de 2030 va a leer mucho más de lo que escribe, y lo que escriba será sobre todo restricción: contratos, tests, tipos, políticas.

Cómo queda el día a día

Ya se ve la forma en los equipos que adoptaron la IA en serio:

• Menos tiempo en el editor, más tiempo en revisión. La proporción se invierte, y revisar deja de ser la tarea del final del día para ser la actividad principal.
• Pull requests más pequeños. Porque el cuello de botella es la lectura, no la escritura. Quien manda un cambio gigante generado por IA está transfiriendo su propio costo al revisor.
• Tests y tipos como especificación. Tú describes la restricción; la implementación se genera y se verifica contra ella.
• Más registros de decisión. Por qué lo hicimos así, qué consideramos, qué descartamos. Es el contexto que ni el modelo ni el colega nuevo tienen de otra forma.

Qué estudiar ahora

Si la apuesta es correcta, el mayor retorno está en estos cinco:

1. Modelado de dominio. Traducir el negocio a estructura. La habilidad más duradera de la lista.
2. Sistemas distribuidos. Fallo parcial, idempotencia, consistencia, colas. Los agentes trajeron esos problemas de vuelta a las aplicaciones comunes.
3. Pruebas y verificación. Tests basados en propiedades, tests de contrato, tipos expresivos. Todo lo que convierte "parece correcto" en "está probado".
4. Operación. Observabilidad, costo, rendimiento. La parte que la IA cubre menos y que más duele.
5. Escritura. Registros de decisión y especificaciones. Tu interfaz con humanos y con máquinas es ahora la misma.

Fíjate en lo que quedó fuera: ningún framework, ningún lenguaje específico. No porque no importen, sino porque esos cinco siguen valiendo cuando el framework de moda se jubile — y el framework de moda siempre se jubila.