En algún momento del 2024, la industria decidió que la productividad de los desarrolladores había dado un salto cuántico. Los dashboards de GitHub mostraban más commits. Los sprints se cerraban antes. Las demos llegaban puntuales. Los directores de producto pedían más. Los inversores aplaudían.
Y en cierto modo, era verdad. La IA había cambiado algo real en cómo se escribe código.
Pero hay algo que no cuadra cuando miras de cerca los sistemas que esos equipos están construyendo.
Velocidad no es lo mismo que avance
Un modelo de lenguaje puede generar en segundos una función que a un desarrollador le llevaría media hora. El código compila. Los tests pasan. La feature entra en el sprint. Todo cuadra en el standup del martes.
Lo que no aparece en el standup es quién entiende realmente ese código. Quién podría extenderlo el mes que viene sin reescribirlo entero. Quién sabe por qué se tomaron ciertas decisiones y no otras.
La IA escribe código sintácticamente correcto. Pero el contexto de negocio —el porqué detrás de cada decisión— no vive en el modelo. Vive en la cabeza del desarrollador que tiene el sistema en mente. Y cuando ese desarrollador acepta el output sin procesarlo del todo, ese contexto se pierde. No en el acto, sino despacio, commit a commit.
Hay una paradoja en todo esto que me parece importante: los desarrolladores que mejor usan IA no son los más rápidos. Son los más deliberados. Se detienen antes de ejecutar un prompt. Piensan qué están pidiendo exactamente y por qué. Evalúan el output con criterio propio antes de integrarlo. Son más lentos al principio, y mucho más sólidos al final.
Confundir velocidad de generación con velocidad de construcción es el primer error.
El segundo coste: arquitectura sin dueño
La escena es conocida. Un desarrollador necesita estructurar un módulo nuevo. Abre el IDE, describe el problema en el chat del asistente, evalúa la propuesta que suena más razonable, y empieza a construir sobre ella. La carpeta se crea, las interfaces se definen, el código empieza a fluir.
Lo que acaba de pasar no es una decisión de arquitectura. Es la ejecución de un patrón estadístico extraído de miles de proyectos que el modelo vio durante el entrenamiento —proyectos de otros negocios, con otros constraints, con otros equipos.
La arquitectura no es una estructura de carpetas ni un conjunto de interfaces bien nombradas. Es la acumulación de decisiones con memoria. Decisiones que saben que este negocio tiene este constraint específico, que este módulo va a crecer en esta dirección concreta, que las reglas de este dominio funcionan de esta manera y no de otra. La IA no tiene ese contexto. Tiene patrones.
Un modelo de lenguaje es un generador de patrones excepcional. Un arquitecto, no.
Cuando delegas las decisiones de estructura en una herramienta que no conoce tu negocio, el sistema que construyes técnicamente funciona. Pero nadie es su dueño real. Nadie puede explicarte con certeza por qué está hecho así y no de otra manera. Y eso, con el tiempo, es exactamente el tipo de deuda técnica que más duele: no la que ves, sino la que descubres cuando intentas cambiar algo.
Cómo uso IA en leo/
Uso modelos de lenguaje a diario. Son herramientas que forman parte de cómo trabajo, no un atajo para saltarme el trabajo.
Mi criterio es simple: la IA es una herramienta de exploración y ejecución, no de decisión. Le pido que genere opciones cuando no tengo claro un enfoque. Le pido que acelere la escritura de código que ya tengo claro en mi cabeza. Le pido que explore alternativas que yo no he contemplado. No le pido que decida qué arquitectura tiene sentido para un negocio que no conoce, ni que elija entre dos enfoques cuando la diferencia importa más allá del código.
La pregunta que me hago antes de delegar algo en un modelo es directa: ¿esta decisión necesita entender el contexto de este negocio? Si la respuesta es sí, no la delego.
No es una postura anti-IA. Es pro-criterio.
La diferencia entre ingeniería y ejecución automatizada
Lo que separa ingeniería real de ejecución automatizada no es qué herramientas usas. Es si quien las usa tiene un criterio claro sobre cuándo escucharlas y cuándo no.
La velocidad artificial es tentadora. Los números salen bien. Los sprints se cierran. Los stakeholders están contentos. Pero el sistema que queda detrás —sin dueño claro, con decisiones que nadie puede justificar— es un problema que se paga más tarde, con intereses.
Construir bien es más lento. Siempre lo ha sido.