Ya no escribimos código, ¿ahora qué?

Cada vez que alguien anuncia el fin de la programación, revela cuánto creía que la programación consistía en teclear.

Escribir código siempre fue la parte chica. Si llevas la cuenta honesta de una semana normal —entender el problema, discutir con producto, leer código ajeno, diseñar, revisar PRs, perseguir un bug de datos, escribir la migración, mirar dashboards después del deploy— el rato con las manos en el teclado produciendo líneas nuevas es una fracción modesta. La automatizamos y quedó al descubierto todo lo demás, que nunca fue opcional.

El cuello de botella se movió, no desapareció

Antes: producir la implementación era caro, revisar era barato.

Ahora: producir es casi gratis, y revisar es el nuevo cuello de botella. Un agente te entrega 800 líneas en cuatro minutos y el equipo tarda tres días en confiar en ellas. La velocidad total del sistema no la fija quien escribe, la fija quien aprueba.

Esto tiene consecuencias prácticas incómodas: los PR gigantes ya no son un pecado de disciplina personal, son el modo por defecto de la herramienta. Si tu proceso dependía de que escribir fuera lento, tu proceso ya está roto y todavía no te enteras.

Las tres cosas que ahora concentran el valor

Especificar. Un requisito ambiguo antes producía dos semanas perdidas; ahora produce dos semanas perdidas en la mitad del tiempo. La gente que sabe convertir “queremos algo tipo Uber pero para reservas” en criterios de aceptación verificables vale más que nunca, porque ahora esos criterios son literalmente el input de la máquina.

Verificar. Tests, tipos, contratos, invariantes, entornos de staging que se parezcan a producción. Todo lo que convierte “parece correcto” en “es correcto sin que yo lo lea entero”. Los equipos con buena verificación aceleraron; los que revisaban a ojo se hundieron en revisión.

Decidir. Qué construir, qué no, qué borrar, qué deuda es aceptable, qué se acopla con qué. Ninguna de esas preguntas tiene una respuesta que se pueda generar sin conocer el negocio, la gente y los tres intentos anteriores que fracasaron.

Arquitectura vuelve a importar (irónicamente)

Cuando el código es barato, la estructura es lo caro. Un sistema con límites claros deja que un agente trabaje en un módulo sin romper otros cuatro; un monolito enredado convierte cada cambio en una ruleta.

Dicho de otra forma: la modularidad dejó de ser una preferencia estética y pasó a ser una condición de operación. El blast radius de un cambio automático es exactamente el tamaño de tu peor acoplamiento.

Lo que no cambió nada

Alguien sigue siendo responsable cuando el sistema se cae. Esa persona no puede decir “el modelo lo escribió” y quedarse tranquila. Delegar la escritura no delega la responsabilidad, igual que un arquitecto no le echa la culpa a la retroexcavadora.

Entonces, ¿qué hacemos ahora?

Lo mismo que siempre dijimos que hacíamos y rara vez teníamos tiempo de hacer bien: entender el problema, definir el contrato, diseñar la solución, verificarla y operarla.

La broma es que la industria pasó veinte años llamando “ingeniería de software” a escribir código, y justo cuando escribir código se automatizó, tuvimos que aprender ingeniería de software.