La IA acelera la escritura de código, no su entrega
Generar código con IA ya no es el cuello de botella; entenderlo, revisarlo e integrarlo ahora consume el tiempo. La productividad percibida no se traduce en entrega más rápida.
Los asistentes de inteligencia artificial generan código a una velocidad que hace unos años habría parecido magia. Una tarea que llevaba una hora a un ingeniero, un agente la resuelve en minutos: escribe pruebas, refactoriza, documenta y hasta navega por repositorios completos. Pero esa rapidez choca con una realidad incómoda: generar código no es lo mismo que entregar software.
El problema no está en la escritura, sino en todo lo que la rodea. Revisar un diff de 2.000 líneas que tocó archivos que no debía, verificar si una lógica de reintentos es segura o identificar qué cambio aparentemente inofensivo rompió una regresión: eso sigue requiriendo la misma atención humana de siempre. Como dice un ingeniero senior en un análisis reciente, la IA ha abaratado la producción de código, pero no ha abaratado la ingeniería. El cuello de botella se ha desplazado de teclear a razonar.
Dónde está el verdadero cuello de botella
La suposición equivocada es que el tiempo en proyectos se iba en escribir sintaxis. Históricamente, las fases que más consumen son diseño, depuración, coordinación, pruebas y mantenimiento. Un cambio no vive aislado: interactúa con APIs, dependencias, pipelines de CI, herramientas de seguridad, procesos de release y consumidores aguas abajo. Cuando eliminas la fricción de escribir sin reforzar la capacidad de verificar, simplemente mueves el atasco más adelante.
Por eso métricas como líneas de código o PRs fusionadas suben, mientras la fiabilidad real se queda plana o empeora. La atención humana no escala: revisar colas interminables de código generado provoca cambios de contexto constantes y una carga mental que la IA no alivia.
Lecciones sobre el terreno
El umbral de esfuerzo de prompting existe. A veces pedir un arreglo rápido acaba en una respuesta enorme que refactoriza media carpeta y te obliga a corregir detalles. En ese punto, la opción más eficiente es recuperar el teclado y escribir tú. La IA debe ser un asistente, no un sustituto de tu criterio.
Otro problema es la pérdida de contexto. Un agente puede parecer que entiende el repositorio y, unas iteraciones después, ignorar decisiones que ya habíais tomado. Si no escribes esas restricciones en un sitio duradero (como un archivo AGENTS.md o .cursorrules), el modelo intenta reconstruirlas de la nada, y eso no sostiene una arquitectura.
Y un detalle práctico: en macOS, los agentes de IA generan comandos asumiendo un entorno que a veces no coincide. El sistema usa zsh por defecto, pero muchas automatizaciones esperan bash. Configurar un perfil de terminal específico para la IA (con bash instalado) evita fallos silenciosos en comandos complejos.
Lo que funciona
Los equipos que sacan partido a la IA no la dejan suelta. Establecen límites explícitos: reglas de repositorio, prohibición de accesos directos a bases de datos fuera de la capa de repositorio, timeouts obligatorios en llamadas HTTP, logging estructurado. Ese contexto mínimo evita que el modelo improvise según patrones genéricos de internet.
La conclusión práctica: la IA no ha hecho la ingeniería más barata, solo ha cambiado dónde se gasta el tiempo. Quien la use con reglas claras y revisión disciplinada ganará algo; quien la deje generar sin control acabará pagando más en revisiones y deuda técnica.
