La trampa de las especificaciones: por qué los agentes de IA para programar exigen requisitos impecables

El problema de las especificaciones no es nuevo: la IA solo lo hizo evidente

En el desarrollo de software con agentes IA, hay una verdad incómoda que siempre estuvo ahí: el verdadero cuello de botella no es escribir código. Es decidir qué código escribir.

Fred Brooks lo dejó claro en 1986 con su ensayo No Silver Bullet. Explicó que los grandes avances en programación —como la programación orientada a objetos o el time-sharing— solo resolvían la complejidad accidental (el lío de implementar). La complejidad esencial (el desafío de conceptualizar) siempre ha sido el obstáculo mayor: alinear expectativas, negociar prioridades y definir requisitos para algo que aún no existe.

Hoy, con la IA generando código a toda velocidad, muchos creen que este problema se evaporará. Craso error. No ha desaparecido.

Especificaciones detalladas no son lo mismo que especificaciones en lenguaje natural

Aquí viene el lío. Herramientas modernas, desde generadores de PRD con IA hasta validadores automáticos, parten de una idea falsa: si la IA hace las preguntas correctas, las lagunas en la spec se cierran solas.

Pero el lenguaje natural es ambiguo por diseño. Por eso nacieron las notaciones formales. Puedes armar un spec que suene perfecto —narrativo, convincente, todos asienten— y aun así falte la precisión que un agente IA necesita para código sólido. Dices "el dashboard debe cargar rápido" y la IA lo interpreta como quiera. Pero "P95 de latencia <2000ms, con tope en percentil 99 de 5000ms" es una spec real.

Al meterle una spec vaga a un agente, pasa una de dos:

1. La ambigüedad genera código raro. Funciona, pero la arquitectura es un desastre. Terminas refactorizando por meses.

2. El agente asume por su cuenta. Usa patrones de su entrenamiento —miles de proyectos parecidos— y entrega algo que no pediste, con total confianza.

Ninguna es victoria.

Dónde brilla el desarrollo con agentes IA (y dónde falla)

Para ser justos: los agentes IA arrasan en tareas simples. Páginas de aterrizaje, apps CRUD, integraciones básicas, flujos de e-commerce estándar. Son problemas con soluciones probadas, miles de ejemplos en los datos de entrenamiento. El agente solo hace matching de patrones.

Eso acelera mucho. Un fundador solo multiplica su ritmo por 10. Un equipo pequeño arma herramientas admin en horas, no semanas. Productividad pura.

El truco: esto funciona por la claridad implícita de la spec, no a pesar de ella. El dominio es tan conocido que no hace falta explicarlo todo.

Para lo demás —lógica de negocio única, integraciones nuevas, decisiones arquitectónicas para escalar— sigues necesitando pensamiento humano. La IA acelera la escritura. No el razonamiento. No te dirá "esto es mala idea, hagamos X primero". Solo ejecuta lo que le ordenas.

Como dijo un dev: "La IA escribe código, pero no se niega a escribirlo sin que le expliques por qué X sería mejor." Eso es pensamiento de producto puro. Irremplazable.

El cuello de botella real: la fricción en la comunicación humana

Si la spec es lo duro y la IA no la resuelve, ¿qué sí funciona?

Simple: bajar la fricción entre personas.

Cuando un PM pasa un brief a un ingeniero y este pierde una semana en reuniones aclaratorias, hay un problema de spec. Si los mockups del diseñador chocan con límites del backend no mencionados, mismo rollo. Si el agente IA genera código con suposiciones locas, igual.

No hace falta un agente más listo ni frameworks mágicos. Hay que inyectar precisión en las charlas humanas antes de que la IA entre en juego.

Eso implica:

• Specs como artefacto central. No un doc opcional, sino el contrato base para generar código.
• Documentar tradeoffs explícitamente. ¿Por qué eventual consistency y no strong? ¿Este modelo de datos o el otro? Todo por escrito.
• Notación formal en lo crítico. Esquemas SQL, contratos API, budgets de performance. Herramientas que no admitan vaguedades.
• Bucles de feedback tempranos con IA. Genera un pedazo de código con tu spec, ve qué ambigüedades salen y afina.

Qué cambia en tu flujo de trabajo

Si usas IA para sistemas en producción, no tires los agentes a la basura. Invierte más en specs, no menos.

Suena raro en tiempos de "moverse rápido". Pero rápido con spec mala es fallar más deprisa. Los equipos que ganan con IA no le piden al agente que invente el qué. Piensan duro primero y usan IA para ejecutar a lo bestia.

Para startups y equipos chicos: tu ventaja no está en generar código. Está en specs cristalinas. Si logras describir tu lógica de negocio tan preciso que la IA lo clava, ya ganaste. El código es lo fácil ahora.

La conclusión

Brooks tenía razón en 1986 y la mantiene en 2025. La complejidad esencial del software está en concebirlo, no en armarlo. La IA no alteró eso: solo hizo obvio el abismo entre ideas vagas y código preciso.

La próxima revolución en productividad no vendrá de agentes más potentes. Vendrá de equipos que pulan sus specs sin piedad, eleven la ingeniería de requisitos a disciplina top y usen IA para amplificar claridad, no para tapar huecos.

Esa es la jugada maestra en IA y desarrollo. Requiere lo que ningún agente hace: pensar hondo sobre qué demonios estás construyendo.