Algo se invirtió en silencio en la ingeniería de software en los dos últimos años. Durante casi toda la historia del sector, el código era el artefacto y la especificación era el andamio desechable a su alrededor - un documento escrito una vez, ojeado dos y abandonado al tercer sprint. Ahora los agentes de IA escriben una porción creciente del código y la economía se ha dado la vuelta. El código se volvió barato de producir y barato de regenerar. Lo escaso es un enunciado preciso de lo que el código debe hacer. La especificación ya no es andamio. Es el artefacto de ingeniería.
Los equipos que la tratan así obtienen un apalancamiento creciente de los agentes: entregan trabajo bien definido, verifican el resultado de forma mecánica y fusionan con confianza. Los que no, obtienen una nueva clase de deuda técnica - código de aspecto plausible que nadie pidió, generado más rápido de lo que nadie puede revisarlo. La diferencia entre unos y otros no está en el modelo ni en las herramientas. Está en si la especificación es un contrato.
Un prompt no es una especificación
El fallo más común es tratar la ventana de chat como si fuera la especificación. Un prompt es el inicio de una conversación: describe la intención en prosa, deja los casos límite a la buena voluntad de quien lee y desaparece en el historial en cuanto se envía. Nadie puede revisarlo, comparar sus versiones ni señalarlo tres semanas después, cuando se discute el comportamiento. Un agente al que se le da un prompt hace lo que hace un contratista al que se le da una conversación de pasillo: rellena cada hueco con sus propias suposiciones, y con aplomo.
Una especificación es otro objeto. Vive en el repositorio, junto al código que gobierna. Está versionada, así que se puede ver qué se acordó y cuándo cambió. Es revisable, así que un colega puede objetar al requisito en lugar de a la implementación. Y es comprobable - la propiedad crucial -, lo que significa que para cualquier trabajo entregado hay una forma mecánica de preguntar: ¿esto satisface la especificación, sí o no? En el momento en que esa pregunta exige un juicio subjetivo, lo que tiene es prosa, no un contrato.
Qué convierte una especificación en contrato
Cuatro ingredientes separan un contrato de un deseo. Los criterios de aceptaciónvan primero: enunciados observables y binarios sobre el comportamiento. «Rápido» es un deseo; «p95 por debajo de 200 ms con 50 peticiones por segundo» es un criterio. «Gestiona entradas incorrectas» es un deseo; «rechaza cargas malformadas con un 422 y un código de error legible por máquina» es un criterio. Si no puede decidir «pasa» o «no pasa» desde fuera de la implementación, reescríbalo hasta que pueda.
Los ejemplos resueltos van segundos, y trabajan más que cualquier otra sección. Pares concretos de entrada y salida - incluidos los feos: la lista vacía, el envío duplicado, el caso límite de zona horaria, el usuario que pega un emoji en el campo del importe. Los ejemplos son donde afloran las suposiciones ocultas. Y son también, no por casualidad, casos de prueba esperando a que alguien los transcriba.
Los invariantes van terceros: propiedades que deben cumplirse tome el camino que tome la implementación. Los saldos nunca se vuelven negativos. Toda transición de estado queda registrada. Los borrados son lógicos. Ninguna llamada al proveedor de pagos sin una clave de idempotencia. Los invariantes son las barreras que sobreviven a la refactorización - lo que importa doblemente cuando quien refactoriza es un agente que no estuvo en la reunión donde se explicó la regla.
Los no objetivosvan últimos y son los más desatendidos. El modo de fallo de un agente rara vez es hacer de menos; es hacer de más - inventarse opciones de configuración, añadir una caché que nadie pidió, «mejorar» el código de al lado. Una lista corta de lo que este cambio no debe tocar y de los problemas que no debe resolver es el control de alcance más barato que escribirá jamás.
Un agente rellena cada hueco de la especificación con sus propias suposiciones - y con aplomo. El contrato existe para que no queden huecos que merezca la pena rellenar.
Los contratos hay que hacerlos cumplir
Un contrato que nadie hace cumplir es decoración. La capa de cumplimiento es lo que convierte el desarrollo guiado por especificación en una disciplina de ingeniería y no en una costumbre documental, y tiene tres partes. Primero, las pruebas como forma ejecutable del contrato. Los criterios de aceptación y los ejemplos resueltos se transcriben a un conjunto de pruebas antes de que el agente escriba código de implementación. El conjunto es la especificación compilada en algo que una máquina puede comprobar; el trabajo del agente es hacer que pase sin debilitarla. Proteja las propias pruebas en la revisión - un agente que edita una aserción para que pase ha renegociado el contrato de forma unilateral.
Segundo, las fronteras tipadas. Los esquemas, los tipos y los contratos de API fijan cada interfaz que toca el código del agente. Un esquema estricto en la frontera convierte toda una clase de salidas plausibles pero incorrectas en errores de compilación y fallos de validación - retroalimentación que el agente recibe en segundos, dentro del ciclo, en lugar de retroalimentación que un revisor entrega días después. Cuanto más estricta sea la frontera, menos margen queda para que se cuele basura con aplomo.
Tercero, puertas de revisión que comparan el diff con el contrato. La revisión humana no desaparece; cambia de objetivo. Revisar la salida de un agente línea a línea, a velocidad de agente, es una partida perdida - sencillamente hay más código que atención. Revisar el diff contra el contrato sí es abordable: ¿satisface el cambio cada criterio de aceptación, respeta cada invariante, se mantiene dentro de los no objetivos? Todo lo que haya en el diff que el contrato no explique es la primera pregunta de la revisión, no un extra.
Las tres formas en que sale mal
Especificación vaga, basura con aplomo.El equipo escribe tres viñetas, el agente produce ochocientas líneas y la distancia entre la intención y el comportamiento se descubre en producción. La señal son las conversaciones de revisión que empiezan con «no es eso lo que quería decir» - una frase que acusa a la especificación, no al agente. La solución es aburrida: más ejemplos, criterios más afilados, escritos antes de generar y no después.
Sobreespecificación, cero apalancamiento. La cuneta contraria. Si la especificación dicta la implementación - fichero a fichero, función a función -, ha escrito el código dos veces, una en prosa y otra en el lenguaje en que se ejecuta, y el agente queda reducido a un mecanógrafo. Especifique el comportamiento en la frontera y los invariantes dentro de ella; deje la implementación a quien la escribe. Si especificar una tarea lleva más tiempo que hacerla, esa tarea no necesitaba un agente.
Deriva de la especificación. El fallo más silencioso. El contrato decía una cosa, la producción evolucionó hacia otra y, tras tres meses de pequeñas renegociaciones de pasillo, la especificación describe un sistema que ya no existe. La deriva es inevitable; la deriva no registrada es una elección. La regla que lo evita cuesta una frase: los cambios de comportamiento aterrizan primero como cambios de especificación, en el mismo pull request, o no aterrizan.
El flujo, de principio a fin
En la práctica esto es un ciclo corto. Escriba el contrato - criterios, ejemplos, invariantes, no objetivos - y hágalo revisar por quienes van a convivir con el comportamiento; aquí es donde discrepar sale barato. Transcriba las partes comprobables a pruebas que fallen. Entregue el contrato al agente y déjele redactar contra el conjunto de pruebas en rojo, iterando hasta que las comprobaciones mecánicas - pruebas, tipos, esquemas, linters - pasen sin editar las propias comprobaciones. Después revise el diff contra el contrato, no contra su paciencia: criterios cumplidos, invariantes respetados, nada fuera de los no objetivos. La fusión deja registrados el contrato y su cumplimiento en una sola unidad atómica, y la siguiente tarea arranca desde una línea base honesta.
El ciclo tiene un beneficio de segundo orden que sorprende a los equipos: los contratos hacen paralelizable el trabajo de los agentes. Dos agentes sobre un encargo vago chocan; cinco agentes sobre cinco contratos con fronteras tipadas entre ellos fusionan sin conflicto, porque cada contrato enuncia qué debe hacer su pieza y dónde termina. La misma propiedad que hace comprobable una especificación la hace componible - que es como un equipo senior pequeño supervisa una cantidad de implementación simultánea que hace cinco años habría requerido un departamento entero.
Una regla mecánica más mantiene honesto el ciclo: las comprobaciones se ejecutan en integración continua, no bajo palabra del agente. Un agente que informa de que «todas las pruebas pasan» está haciendo una afirmación; una canalización en verde sobre un conjunto de pruebas sin modificar es un hecho. El contrato, sus pruebas y la canalización forman juntos un árbitro neutral al que le da igual si el código lo escribió una persona en un mal día o un modelo en uno confiado - y esa indiferencia es exactamente lo que hace fiable el resultado.
Los equipos que adoptan esto descubren que el cuello de botella se ha movido. La habilidad escasa ya no es producir código - es decidir con precisión qué debe hacer el código y expresarlo de forma comprobable. Esa fue siempre la parte difícil del software; los agentes no crearon el problema, solo eliminaron el sitio donde se escondía.
Cuándo compensa - y cuándo es sobrecarga
El desarrollo guiado por especificación no es gratis, y fingir lo contrario mata su adopción. El contrato se paga solo cuando el trabajo tiene consecuencias y el coste de equivocarse es real: sistemas que mueven dinero, que tocan datos de clientes, que se apoyan en las fronteras entre equipos o que van a ser mantenidos por personas - y agentes - que no estaban presentes cuando se tomaron las decisiones. Compensa más rápido justo donde la salida del agente es más difícil de revisar a ojo.
Es sobrecarga para pruebas de concepto, prototipos y scripts de un solo uso - código cuyo único propósito es tirarse una vez ha respondido a una pregunta. Escriba una frase de intención, deje correr al agente, quédese con el aprendizaje y borre el código. La disciplina consiste en saber en qué modo está, y en ser honesto en el momento en que un prototipo empieza a convertirse en silencio en un sistema. Ese momento - y no la reescritura seis meses después - es cuando se escribe el contrato.
El sector pasó dos décadas aprendiendo que las pruebas no son burocracia, sino aquello que permite ir rápido sin romper lo que importa. Las especificaciones están haciendo ahora el mismo viaje, por la misma razón. Cuando el coste marginal de escribir código se acerca a cero, el valor se concentra en el enunciado de lo que el código debe hacer - y los equipos que escriben ese enunciado como un contrato son aquellos para los que los agentes de verdad acumulan valor.