En el panorama actual de la ingeniería de software, la integración de modelos de lenguaje grandes (LLMs) plantea un desafío fundamental: la velocidad de generación versus la capacidad humana de comprensión. Facundo Olano, en su análisis, advierte que asumir que no necesitamos leer código generado por IA es irresponsable, ya que el programador sigue siendo el responsable final ante cualquier fallo. Sin embargo, si las organizaciones imponen mandatos para maximizar la productividad mediante estas herramientas, debemos adaptar nuestro enfoque de ingeniería.
La explicación central radica en que los LLMs producen código no determinista mucho más rápido que nosotros podemos leerlo. Esto implica que el código generado se convierte en una forma de "código máquina" de alto nivel, similar al ensamblador o bytecode. No podemos esperar revisar cada diferencia (diff) individualmente porque la velocidad de producción supera la capacidad cognitiva de lectura. Por lo tanto, la rigurosidad técnica debe migrar de la revisión de código a la especificación y a los tests.
En términos de aplicaciones, esto sirve para equipos que buscan escalar la velocidad de desarrollo sin sacrificar la calidad. Se requiere una reestructuración organizacional donde se elimine la burocracia y el control humano excesivo ("human-in-the-loop"). Los ingenieros actuarían como diseñadores de producto, con autonomía para tomar decisiones, mientras que las especificaciones en formato Markdown se convierten en la unidad de conocimiento del proyecto. Esto permite que los equipos funcionen con flujos de trabajo casi infinitos de requerimientos.
Las consideraciones finales son críticas. No es una decisión individual, sino organizacional, influenciada por la Ley de Amdahl. Si solo aceleramos la generación sin cambiar los procesos, no habrá ganancias tangibles. La alternativa no es dejar de ser rigurosos, sino cambiar dónde aplicamos esa rigurosidad: en las reglas de negocio definidas en especificaciones y en pruebas automatizadas que validen la conformidad del código. El código materializado es secundario; lo que importa es la especificación que lo guía. Además, se debe reducir la fricción y el gatekeeping para permitir que los agentes corran fuera de horario.