Tu IA No Está Escribiendo Código Malo. Tú Estás Escribiendo una Especificación Mala.
La automatización llevaba 10 minutos ejecutándose cuando llegó la notificación. Un email enviado a un contacto que todo mi sistema había estado evitando discretamente durante 6 meses. Culpa mía. Demasiado tarde...
Releí la especificación. Decía: "hacer seguimiento con prospectos activos." Eso era todo. Sin lista de exclusiones, sin filtros de estado, sin restricciones sobre a quién no contactar. Claude ejecutó exactamente lo que escribí, sin dudarlo, sin omitir nada.
La especificación es el cuello de botella, no el modelo, no el prompt.
Omití Una Línea. Claude Hizo el Resto.
El agente tenía acceso a la lista completa de contactos. Todos: prospectos activos, leads inactivos, un distribuidor con el que habíamos dejado de trabajar discretamente 6 meses antes, y 2 o 3 personas de una alianza que había terminado de una manera que nadie quería revivir mediante email automatizado. La especificación no decía nada de eso. Decía "prospectos activos," que en mi cabeza tenía un significado construido a partir de meses de contexto, 12 decisiones informales, y al menos 1 conversación incómoda que había olvidado completamente documentar en algún lugar.
Claude no sabía nada de eso. Claude sabía lo que decía la especificación.
Así que hizo seguimiento. Con todos los que no estaban explícitamente excluidos. Profesionalmente, puntualmente, exactamente en el tono que había pedido. La lista de contactos no tenía una bandera de "no enviar email" porque nunca pensé en agregarla. La especificación no tenía reglas de exclusión porque asumí que eran obvias. El agente se ejecutó con lo que existía, no con lo que yo pretendía.
Esto es lo que cambia con la velocidad de ejecución de IA: un desarrollador humano con la misma especificación podría haber hecho una pregunta aclaratoria, o tomado una decisión de criterio, o al menos dudado en el caso límite. Un agente no duda. Entrega. (En C, esto se llama comportamiento indefinido. En agentes de IA, se llama "la especificación que escribí.")
Claude no cometió un error. Yo dejé una puerta abierta.
(Y sí, después de esto releí todas las demás especificaciones que había escrito para ese pipeline. Encontré 4 restricciones faltantes más en la primera pasada.)
GIGO Siempre Fue la Regla.
GIGO: Garbage In, Garbage Out (Basura Entra, Basura Sale). El principio data de 1957, acuñado en mainframes militares cuando los programadores descubrieron que alimentar una computadora con datos incorrectos producía salida incorrecta con perfecta consistencia. La máquina ejecutaba correctamente. El problema siempre estaba río arriba.
Estas no eran unidades con criterio. Eran IBM 709s leyendo tarjetas perforadas. La ambigüedad no era una opción. La entrada era binaria, la salida era binaria, y la brecha entre ambas siempre era el humano.
Durante 60 años, GIGO describió un problema de calidad de datos. Datos de entrenamiento malos entran, predicciones de modelo malas salen. Ese enfoque aún aplica. Lo que cambió es en qué capa entra la basura.
Con agentes de IA, la basura entra a nivel de especificación, no a nivel de datos. La entrada no es un archivo CSV corrupto. Es una especificación incompleta: una regla escrita demasiado suelta, un alcance definido demasiado amplio, una lista de exclusiones que vive solo en la cabeza de alguien. El agente no absorbe ambigüedad. Ejecuta a través de ella, a cualquier velocidad que le hayas dado, contra cualquier dato al que tenga acceso.
Noté esta semana que mi IDE guarda automáticamente cada 2 segundos. He tenido esta configuración activada y desactivada al menos 5 veces a lo largo de los años, y genuinamente no puedo recordar de qué manera realmente la quería. La configuración se siente lo suficientemente importante como para existir como configuración pero no lo suficientemente importante como para escribir la razón. En fin, el punto es que somos malos documentando las decisiones pequeñas.
Google Nombró el Nuevo Cuello de Botella el Mes Pasado
En mayo de 2026, un whitepaper de Google de Osmani, Saboo, y Kartakis llegó a Kaggle y pasó relativamente desapercibido durante unas semanas antes de que la comunidad de desarrolladores lo alcanzara. El argumento principal: el cambio que estamos viviendo no es un nuevo lenguaje o un nuevo framework. Es un movimiento de escribir código a expresar intención, y la mayoría de fallas que aparecen como "problemas de IA" son en realidad problemas de intención río arriba.
Según sus números, aproximadamente el 85% de los desarrolladores profesionales ahora usan agentes de codificación de IA regularmente, con alrededor del 41% de todo el código nuevo siendo generado por IA. A esa escala, una especificación vaga se ejecuta a velocidad de generador contra datos de clientes en vivo. La revisión de código no atrapa nada de eso. Y las matemáticas se componen rápido: si incluso una fracción de esas bases de código generadas se ejecutan en especificaciones incompletas, la superficie de área para incidentes como mi automatización de outreach deja de ser territorio de casos límite. Se convierte en el default.
El enfoque central del paper: "La mayoría de fallas de agentes, examinadas honestamente, son fallas de configuración." No brechas de capacidad en el modelo. Fallas de configuración en el arnés. Osmani escribió por separado en su blog después del whitepaper que cuando un agente hace algo inesperado, su primer movimiento es revisar el arnés, no cuestionar el modelo. Usualmente es una herramienta faltante, una regla que escribió demasiado suelta, o una barrera de protección que olvidó agregar. Eso coincide exactamente con lo que pasó a mi pipeline de outreach.
El artículo anterior de Bloomberg terminó diagnosticando la enfermedad equivocada: vieron los síntomas correctamente (pánico de productividad, salidas de IA con bugs, scope creep) y culparon a las herramientas. El whitepaper es más preciso. Las fallas de capacidad y las fallas de configuración son problemas diferentes que apuntan a soluciones diferentes. Una solución es un mejor modelo. La otra es escribir la especificación que deberías haber escrito antes de ejecutar cualquier cosa.
Tu Especificación de App de Tareas Se Rompe Aquí.
Prueba esto. Escribe una especificación para una app de tareas que cause un incidente real de producción. Agregar una tarea, completar una tarea, eliminar una tarea, listar tareas. No hay lugar para que la especificación salga mal de una manera que dañe algo real. El peor caso es un elemento marcado como completado cuando no debería estarlo.
Ahora escribe una especificación para una automatización de outreach que toque contactos de socios y cuentas activas. Quién es contactado, bajo qué condiciones, excluido cuándo, de qué lista, basado en qué campo de estado, con qué override para cuentas en pausa, y qué pasa con los 2 socios actualmente en una renegociación de contrato que has estado manejando personalmente durante 3 semanas? Cada 1 de esas restricciones faltantes es una puerta por la que el agente caminará.
Es básicamente la diferencia entre la zona tutorial y el primer dungeon real. Mismas mecánicas, conjunto de consecuencias completamente diferente. La mayoría de especificaciones vibe-coded están escritas para la zona tutorial y desplegadas en el dungeon.
La mayoría de builders aplican disciplina de especificación de app-de-tareas a herramientas de producción con efectos del mundo real. "Hacer seguimiento con prospectos activos" deja abierto qué significa "activo" exactamente, qué contactos están en pausa voluntaria, y cuáles están siendo manejados personalmente por alguien que no estará feliz de ver un email automatizado llegar. "Sincronizar el catálogo de productos con el feed del socio" no dice nada sobre referencias actualmente bajo revisión de contrato. "Procesar órdenes entrantes" no le da al agente cero orientación sobre qué hacer con una orden ya manejada por la ejecución anterior.
Cada restricción faltante es algo que el agente interpretará de cualquier manera que los datos hagan posible, a cualquier velocidad que le hayas dado. A escala de feed de socios, a escala de outreach, a cualquier escala donde la herramienta toque cuentas reales o dinero real, dejar brechas en la especificación no es un descuido que atraparás en QA. Es un incidente de producción esperando la combinación correcta de datos y timing.
El agente construye ambos con la misma confianza. La complejidad del dominio no se transfiere automáticamente a complejidad de especificación. Tienes que escribirla.
Lo Que Construí Para Atrapar las Brechas.
Después del incidente de outreach, puse una capa de refinamiento de especificación entre el builder y el agente en cualquier automatización nueva. Nada complicado: un diálogo guiado por Claude que se ejecuta antes de la primera línea de código. No escribe la especificación. Hace preguntas que tienes que responder.
Preguntas como: ¿quién o qué no debería tocar este agente, bajo ninguna condición? ¿Qué reglas de negocio implícitas gobiernan este dominio que nunca has escrito en ningún lugar? ¿Qué cuenta como "terminado," y qué cuenta como "nunca empezar"? ¿Qué pasa en los bordes: una cuenta expirada, un contacto en disputa, un producto marcado por legal, una orden ya procesada por la ejecución anterior?
La primera vez que lo usé en una nueva automatización de distribución, la entrada inicial fue "sincronizar el catálogo de productos con el feed del socio." Primera pregunta que la herramienta generó: "¿Hay categorías de productos que deberían ser excluidas de esta sincronización?" Me quedé ahí sentado por unos 5 segundos. Luego abrí un documento de hace 4 meses y encontré 12 referencias de productos marcadas como bajo revisión de contrato. Nunca había pensado ni una vez en ponerlas en la especificación.
Ese silencio después de la pregunta es su propio diagnóstico. Dudas de más de 2 segundos = restricción faltante. Mismo instinto que hacer "merge to main" cuando te has saltado la prueba. Tu instinto sabe antes que tu cerebro.
El valor no es el documento de salida. Son los 10 minutos de incomodidad antes de que el agente se ejecute. Creo que esto solo atrapa lo que ya estás medio consciente a algún nivel. Si una restricción nunca ha cruzado tu mente en absoluto, ninguna pregunta la sacará a la superficie. Ese es el techo honesto.
Especificar Es la Habilidad. Prompting Es un Subconjunto.
Prompt engineering es la habilidad de obtener mejor salida de un modelo en una conversación dada. Especificar es la habilidad de definir qué se le permite hacer al agente, a quién puede tocar, sobre qué datos puede actuar, y dónde se detiene. Estas son disciplinas diferentes operando en diferentes niveles del stack.
Un prompt limpio te da una mejor respuesta dentro de cualquier alcance que el agente ya tenga. Una especificación cuidadosa define cuál es el alcance. El builder que escribe prompts limpios contra una especificación suelta envía rápido y rompe cosas en producción. El builder que especifica cuidadosamente envía más lento al principio y se recupera de menos incidentes después. Con IA comprimiendo cronogramas de entrega de semanas a horas, "después" ahora significa la misma tarde.
Si quieres operar a nivel de proyecto y no solo a nivel de conversación, el framework completo de contratos de prompt cubre exactamente esto: qué puede generar el agente, qué puede modificar, qué requiere aprobación humana explícita. Es a lo que me moví después de suficientes incidentes como el del email.
El enfoque que expongo en Vibe Coding, For Real cubre la etapa anterior: antes de que cualquier generación de código comience, define las condiciones límite del dominio, no solo la lista de características. Lo que el sistema nunca debería hacer y qué reglas de negocio nunca han sido escritas porque todos asumieron que eran obvias.
Un agente no tiene intuición sobre lo que quisiste decir. Solo sobre lo que escribiste.
3 Preguntas Antes de Que Claude Obtenga Acceso.
El email del incidente no habría sido prevenido por un mejor modelo, o un mejor prompt. Habría sido prevenido por 10 minutos extra de trabajo de especificación antes de que el agente se ejecutara.
3 preguntas que ahora ejecuto antes de que cualquier agente obtenga acceso a datos en vivo:
¿Quién o qué no debería tocar este agente, bajo ninguna condición? No "quién está excluido de este lote" sino quién está permanentemente fuera de límites sin importar el estado, sin importar la membresía de lista, sin importar lo que muestren los datos. Estas exclusiones necesitan ser explícitas en la especificación, no implícitas por contexto.
¿Qué reglas de negocio implícitas nunca has escrito en ningún lugar? Piensa: la alianza que pausaste discretamente en noviembre, las referencias de productos sentadas en un documento de revisión legal que nadie abre, los 2 o 3 contactos a los que personalmente les dijiste "yo manejo este" y nunca marcaste en ningún lugar del sistema. Cada 1 de estas es una restricción que el agente no conoce a menos que la escribas.
¿Cuál es el nivel de riesgo real de este proyecto? No lo que esperas que sea el riesgo, sino qué pasa si el agente se ejecuta en todo a lo que tiene acceso. Una tarea mal categorizada en una app de tareas te cuesta 30 segundos. Un email al socio equivocado te cuesta una relación y una mañana. Una orden modificada en un feed de ecommerce en vivo te cuesta un incidente de facturación y posiblemente un cliente. El nivel de detalle en la especificación tiene que coincidir con el nivel de riesgo en el dominio, no solo el conteo de características.
El email del incidente me costó 1 mañana y 1 relación profesional que reparar. El agente se ejecutó exactamente como se especificó. Solo olvidé escribir la restricción.
Así es como funciona ahora. La IA ejecuta lo que escribes, no lo que piensas.
vamos a tener que aprender a ser explícitos ahora...
Fuentes
- Osmani, A., Saboo, S., Kartakis, S. (2026, May). The New SDLC With Vibe Coding. Google / Kaggle. https://www.kaggle.com/whitepaper-the-new-SDLC-with-vibe-coding
- Osmani, A. (2026, June). The New Software Lifecycle. https://addyosmani.com/blog/new-sdlc-vibe-coding/
- Eveilleau, P. (2026). Vibe Coding, For Real. Amazon Kindle. https://a.co/d/0d7xiVlX
Este post puede contener enlaces de afiliados. Si haces clic en ellos, podría ganar una pequeña comisión (no te cuesta nada, y me ayuda a seguir enviando artículos de calidad todos los días para tu placer de lectura).