Specs y agentes: la especificación es donde se firma

El 3 de agosto, el desarrollador Niklas Gruhn le puso nombre a algo que cualquier equipo con agentes ya había visto: el meat proxy, la persona que reenvía lo que produce una IA sin leerlo, entenderlo ni validarlo. Su ejemplo más afilado no es un mensaje de Slack, es un pull request. Pegas el ticket en el agente, no miras lo que sale y dejas que los comentarios del revisor dirijan las iteraciones. El cambio acaba entrando, pero el trabajo lo han hecho los revisores con el agente, y tú has hecho de intermediario.

El 21 de septiembre, Shakers llevó el término al castellano con la pregunta correcta —quién firma lo que la IA escribe— y un ejemplo de daño que cualquier CTO reconoce: una especificación funcional que baja a desarrollo con un requisito inventado y que se construye entera antes de que nadie note que el negocio no lo pidió. Le pone además un coste, con el estudio de BetterUp Labs y el Stanford Social Media Lab de septiembre de 2025: el 40% de 1.150 trabajadores de oficina en Estados Unidos había recibido ese tipo de contenido en el último mes, cada caso costaba de media unas dos horas y el total salía a 186 dólares por empleado y mes. Es trabajo de oficina en general, no código, pero el mecanismo es el mismo.

Esta pieza se queda con el ejemplo de la especificación, porque señala algo que la conversación sobre el meat proxy todavía no ha dicho: en un ciclo de desarrollo con agentes, la respuesta no es revisar más el código, es firmar antes. Y la firma tiene un sitio concreto.

El meat proxy no es un problema de actitud

La lectura fácil es moral: hay gente que no se lee lo que manda. La útil es de diseño. Si en tu proceso el único punto donde una persona valida el trabajo es el pull request, quien abre ese pull request es un intermediario por construcción. No decidió el enfoque —lo eligió el agente—, no escribió las líneas y, si el cambio es grande, las está leyendo por primera vez con la misma atención que su revisor.

Lo contamos con datos en el review que sigue esperando a un autor: el code review descansa en que existe alguien a quien preguntarle por qué, y con código generado ese alguien a menudo no existe. Allí la conclusión era mover el porqué a un artefacto que se escribe antes de generar. Aquí toca la parte que quedó pendiente: quién responde de ese artefacto, y cómo se nota que alguien ha respondido.

Revisar más no arregla lo que se decidió antes

Vuelve al ejemplo de Shakers y sigue el requisito inventado por el proceso. El agente lo implementa bien, con tests que pasan. El revisor comprueba que el código es correcto, que no duplica nada y que los tests prueban algo. Todo está bien. Un review impecable confirma que el requisito inventado está bien construido.

El review compara el código con una intención. Si esa intención nunca se escribió y nadie la aprobó, se compara con lo que el revisor recuerda o supone del ticket. Ningún esfuerzo adicional sobre el diff lo arregla, porque el error no está en el diff: está en una decisión que nadie tomó explícitamente. Por eso un test escrito desde el código no lo prueba, lo describe, y por eso un review hecho sin un criterio escrito acaba siendo una opinión.

Dónde se firma en un ciclo de desarrollo con agentes

El flujo que comparten Spec Kit, Kiro y la mayoría de implementaciones de Spec-Driven Development es el mismo: especificación, plan, tareas, código. El Technology Radar de Thoughtworks lo resume así desde noviembre de 2025. Lo que ninguno de esos esquemas dice es en qué artefacto responde cada persona. Esta es nuestra propuesta:

Dos cosas de la tabla que conviene no leer deprisa. La primera: la firma cae donde hay una decisión humana que el agente no puede tomar, no en cada paso. Firmar tareas o firmar código generado es burocracia; firmar qué se construye y qué queda fuera es responsabilidad. La segunda: el código deja de ser el sitio donde se decide. Si en el review aparece una decisión nueva —una dependencia, un campo que nadie pidió, un comportamiento ante errores—, no se discute en el diff. Se devuelve a la spec, porque es ahí donde alguien tiene que responder de ella. Es el mismo criterio que aplicamos a la línea del pull request que nadie discute.

Las herramientas generan la spec; ninguna exige que alguien la firme

Aquí está la parte incómoda para quien ha comprado SDD como herramienta. Hemos leído la documentación de las dos más usadas buscando el punto donde una persona aprueba la especificación antes de seguir.

En Spec Kit, el kit de GitHub, la fase de especificación está bien planteada: pide definir qué y por qué antes de decidir cómo, y deja la tecnología para el plan. Pero su documentación no fija ninguna aprobación obligatoria entre fases. Recomienda revisar el resultado antes de continuar, y ahí se queda. En Kiro, de Amazon, el flujo completo guía por requisitos, diseño y tareas, y la documentación ofrece además un atajo explícito: para funcionalidades bien entendidas, Quick Spec genera los tres artefactos «sin puntos de aprobación». Claude Code tiene un modo plan que propone un plan y no toca ningún fichero hasta que lo apruebas, pero esa aprobación vive en la sesión de una persona, no en un artefacto versionado del repositorio.

No es una crítica a las herramientas: generar el artefacto es su trabajo, y decidir quién responde de él es trabajo de la organización. Pero conviene ver el riesgo que abre. Con un SDD mal implantado, el agente escribe la spec, el agente escribe el código y la persona reenvía las dos cosas. Es un meat proxy con más pasos y con apariencia de método. El Radar de Thoughtworks apunta en la misma dirección con otras palabras: algunas herramientas generan especificaciones largas y difíciles de revisar, y a veces no está claro a quién van dirigidas.

La objeción seria: nadie quiere leer especificaciones

Hay que contarla entera, porque es la mejor crítica publicada a SDD y la que más cuesta contestar. En octubre de 2025, Birgitta Böckeler, de Thoughtworks, probó Kiro, Spec Kit y Tessl sobre casos reales. Sus conclusiones: la salida de Spec Kit le resultó muy prolija y tediosa de revisar, hasta el punto de escribir que prefería revisar código antes que todos esos ficheros markdown. Kiro convirtió un bug pequeño en cuatro historias de usuario con dieciséis criterios de aceptación. Y el agente, con toda la especificación delante, no siguió todas las instrucciones: llegó a duplicar código al tomar la descripción de una clase existente por un requisito nuevo.

Las tres observaciones son ciertas, y ninguna tumba la tesis. La corrigen en tres puntos concretos:

• Una firma sobre doce páginas también es simbólica. Si nadie puede leer la spec entera, firmarla es el mismo gesto vacío que aprobar un pull request de cuatrocientas líneas. La spec que se firma tiene que caber en una página, y lo que no quepa es señal de que el cambio es demasiado grande. Hablamos de formato y de extensión en la tabla de decisión de los artefactos SDD.
• No todo necesita spec. Un bug de una línea no se especifica: se arregla con un test que falla y luego pasa. La firma se reserva para lo que cambia comportamiento de negocio o toca dinero, datos personales, permisos o migraciones.
• La spec no garantiza que el agente la cumpla. Por eso la tabla no termina en la especificación: el código se juzga contra ella y los casos de aceptación salen de ella. La firma no sustituye la verificación, le da un criterio. Es la misma lógica por la que el golden set es lo que sobrevive a los cambios de modelo.

Böckeler distingue además tres niveles: la spec que se escribe y se tira después de la tarea, la que se mantiene y acompaña a la funcionalidad, y la que sustituye al código como fuente que se edita. La firma sólo tiene sentido en los dos últimos. Si la especificación se tira al terminar la tarea, lo que queda firmado es un documento que ya no existe.

SDD, TDD y BDD con agentes: qué valida cada uno

La pregunta aparece en todas las formaciones, y con agentes la respuesta cambia de matiz. Las tres prácticas no compiten: cada una contesta una pregunta distinta, y las tres fallan del mismo modo cuando el artefacto de control lo genera el agente a partir de lo que ya ha hecho.

En la práctica, se encajan así: los escenarios de aceptación viven dentro de la spec —son lo que se firma junto al qué y al porqué—, y los tests se derivan de esos escenarios, no del código. BDD pone el formato, SDD pone la firma y TDD ejecuta la comprobación. El orden importa más que la etiqueta: primero lo firmado, luego lo generado.

La spec vive en tu repositorio, no en la herramienta

Una consecuencia práctica de poner la firma en el artefacto y no en la herramienta: el método no te ata a ningún agente. Claude Code, Copilot, Cursor o Kiro leen ficheros del repositorio. Si la spec firmada es un fichero, cambiar de herramienta no cambia quién responde de qué. Si la firma vive en la sesión de un producto concreto, la pierdes al cambiar, y el mercado de herramientas cambia cada trimestre, como repasamos en Claude, Cursor y Copilot en la empresa.

El mecanismo ya lo tienes, y no es una herramienta nueva: una carpeta de especificaciones en el repositorio, un fichero CODEOWNERS que asigna esa carpeta a quien responde de ella y una regla de protección de rama que exija su aprobación antes de fusionar. Con eso, la firma queda registrada con nombre, fecha y versión exacta del texto. Una advertencia de la documentación de GitHub que casi nadie lee: con la revisión de propietarios activada, basta la aprobación de uno de ellos. Si queréis las dos firmas —producto y técnica—, hay que exigirlas aparte. La herramienta, sola, no distingue el rol.

Lo que se configura en el agente es lo contrario: que no empiece a generar sin una spec aprobada, y que lea la constitución y las skills del proyecto antes de proponer el plan. La responsabilidad está en el repositorio y el agente la lee. No al revés.

Una especificación firmable, entera

Para que la idea no se quede en abstracto, así es de corta una spec que se puede firmar en serio. El caso es inventado pero típico: exportar las facturas del mes para la gestoría.

specs/facturas-export-gestoria.md · v1.2

OBJETIVO
  El usuario de administración descarga en un fichero las facturas
  emitidas en un mes, con el formato que pide su gestoría.

POR QUÉ
  Hoy se copian a mano cada cierre de mes (unas 3 h). Petición de
  Finanzas en el ticket FIN-214.

FUERA DE ALCANCE
  - Facturas recibidas.
  - Envío automático a la gestoría.
  - Cualquier formato que no sea CSV.

CASOS DE ACEPTACIÓN
  1. Dado un mes con facturas emitidas, cuando exporto, obtengo un CSV
     con una fila por factura y las columnas del anexo A.
  2. Dado un mes sin facturas, cuando exporto, obtengo el CSV con
     cabecera y sin filas, y un aviso en pantalla.
  3. Dado un usuario sin rol de administración, no ve la opción.

DECISIONES ABIERTAS
  Ninguna.

FIRMAS
  Producto ........ [responsable de producto] · 2026-09-18 · PR #412
  Técnica ......... [tech lead]               · 2026-09-18 · PR #412

Tres líneas de ese ejemplo hacen casi todo el trabajo. «Fuera de alcance» es la que caza el requisito inventado: si el agente añade el envío automático porque le pareció útil, el review ya no es una opinión, es una comparación con una línea firmada. «Decisiones abiertas: ninguna» es la condición para firmar: mientras haya una, la spec no está lista y el agente no empieza. Y las firmas no son un adorno: si mañana alguien pregunta por qué la exportación no incluye las facturas recibidas, la respuesta tiene nombre, fecha y un pull request.

Firmar esa página cuesta minutos. Cuesta bastante menos que leer cuatrocientas líneas generadas buscando algo que nadie dijo que no había que hacer. Y cambia la pregunta del review de «¿está bien esto?» a «¿hace esto lo que firmamos, y qué hace además?», que es una pregunta que un revisor sí puede contestar, aunque no haya escrito ni una línea. Es también lo que separa un MVP de un quick ship.

Todo merge ya es una firma

Una última observación, para quien piense que esto añade un trámite. Vuestro equipo ya firma: cada aprobación de un pull request es una firma, con nombre y fecha, sobre un cambio que entra en producción. Lo único que cambia con agentes es sobre qué se firma. Si la única firma del proceso está en el código, se está firmando algo que ninguna persona ha escrito. Si está en la especificación, se firma lo único que una persona sí ha decidido.

El meat proxy no se corrige pidiendo a la gente que lea más. Se corrige moviendo la firma al sitio donde hay algo que decidir.

Preguntas frecuentes

¿Qué es un meat proxy y qué tiene que ver con el desarrollo de software?

Es la persona que reenvía lo que produce una IA sin leerlo, entenderlo ni validarlo. El término lo propuso el desarrollador Niklas Gruhn el 3 de agosto de 2026, y su ejemplo más claro es de código: pegar el ticket en el agente, no mirar lo que sale y dejar que los comentarios del revisor dirijan las iteraciones. En ese caso, dice Gruhn, el trabajo lo han hecho los revisores con el agente, y quien abrió el pull request sólo ha hecho de intermediario. En desarrollo el patrón es especialmente caro porque el reenvío acaba en producción.

¿Qué significa «firmar» una especificación en la práctica?

Nada parecido a un PDF con rúbrica. Significa que la especificación es un fichero versionado en el repositorio y que entra en la rama principal mediante un pull request aprobado por personas con nombre, antes de que el agente genere el código. La firma es esa aprobación: queda registrado quién, cuándo y sobre qué versión exacta del texto. Desde ese momento, el código se juzga contra ese fichero, y cualquier cambio de alcance pasa por modificarlo y volver a aprobarlo.

¿Quién debe firmar la especificación?

Dos personas, porque firman cosas distintas. Quien responde del producto firma el qué y el porqué: que eso es lo que el negocio pidió, y que lo que queda fuera de alcance está bien fuera. Quien responde técnicamente firma que es construible y coherente con las reglas del proyecto. Lo que no funciona es que firme sólo quien la generó con el agente: es la misma persona revisando su propio reenvío. Ojo con las herramientas: con CODEOWNERS de GitHub basta la aprobación de uno de los propietarios, así que las dos firmas hay que exigirlas aparte.

¿Puede el agente escribir la especificación?

Como borrador, sí, y suele ahorrar tiempo. La condición es que quien la firma pueda defender cada línea sin volver a preguntarle al agente: es la prueba de Gruhn aplicada a la spec. Si una frase no sabría explicarla en una reunión, o no sabe de dónde sale un requisito, no puede firmarla. El ejemplo de daño que pone Shakers es exactamente ése: una especificación que baja a desarrollo con un requisito inventado y que se construye entera antes de que nadie note que el negocio no lo pidió.

¿En qué se diferencia SDD de TDD y BDD cuando trabajas con agentes?

Contestan preguntas distintas y se complementan. TDD comprueba que el código hace lo que dicen los tests. BDD comprueba que el comportamiento es el que se describió en escenarios de negocio. SDD fija qué se decidió construir, por qué, qué queda fuera y quién lo decidió. Con agentes, las tres fallan del mismo modo si el artefacto de control lo genera el agente a partir del código: tests que describen la implementación, escenarios que la parafrasean o una spec que nadie ha firmado. Lo práctico es que los escenarios de aceptación vivan dentro de la spec y que los tests se deriven de ellos, no del código.

¿Esto no es volver al waterfall?

No, si la spec es de una funcionalidad y cabe en una página. El waterfall firmaba un documento grande al principio del proyecto; aquí se firma un texto corto antes de cada cambio relevante, en minutos. La objeción tiene una parte de razón que conviene aceptar: Birgitta Böckeler vio cómo una herramienta convertía un bug pequeño en cuatro historias de usuario con dieciséis criterios de aceptación. Un bug de una línea no necesita spec. Una funcionalidad que toca dinero, datos o permisos, sí.

Fuentes citadas

• Gruhn, N. — Don't be a meat proxy (3 de agosto de 2026; origen del término y ejemplo del pull request)
• Willison, S. — Don't be a meat proxy (3 de agosto de 2026; la nota que difundió el término)
• Shakers — Meat proxy: quién firma lo que la IA escribe (21 de septiembre de 2026; el ejemplo de la especificación con un requisito inventado)
• BetterUp Labs y Stanford Social Media Lab — Workslop (septiembre de 2025; 1.150 trabajadores de oficina en EE. UU., 40% afectados en el último mes, unas 2 horas por caso, 186 $ por empleado y mes)
• Böckeler, B. — Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl (15 de octubre de 2025; los tres niveles de SDD y las críticas sobre revisión, tamaño y cumplimiento)
• Thoughtworks — Technology Radar: Spec-driven development (anillo Assess, noviembre de 2025)
• GitHub — Spec Kit (flujo constitución, especificación, plan, tareas e implementación)
• Kiro — Specs (documentación; Quick Spec sin puntos de aprobación)
• Anthropic — Claude Code: Common workflows (modo plan: propone y no edita hasta que se aprueba)
• GitHub — About code owners (revisión obligatoria de propietarios; basta la aprobación de uno)