Los agentes de código pueden leer su repositorio. Figma Specs busca darles las decisiones detrás del producto

Un agente de código toma un ticket: agregar un filtro a la página de pedidos. Lee el repositorio, encuentra la biblioteca de componentes, escribe código limpio y abre una pull request. El revisor lo rechaza en un minuto. El filtro debía estar oculto para un segmento de clientes, el estado vacío necesitaba el texto del equipo legal, y el equipo de diseño ya había decidido que los filtros van en un panel lateral, no en un menú desplegable. Nada de eso estaba en el repositorio. Estaba en una reunión, un archivo de diseño y un documento a tres enlaces de distancia.

Es una de las formas más comunes en que fallan los agentes de código. El código es plausible y el producto es incorrecto, porque el agente tuvo acceso a la implementación y no a la intención.

Qué lanzó Figma

El 15 de octubre, en Config India, Figma presentó Specs: un espacio de trabajo basado en Markdown que vive en el lienzo de Figma junto a diseños, diagramas de FigJam y capas de código. Una spec puede incrustar frames y cualquier nodo del lienzo junto al texto. Los archivos Markdown existentes se pueden arrastrar al lienzo para convertirse en specs. Conectores como GitHub y Hex pueden traer contexto externo, y el agente de Figma puede documentar el uso de componentes del sistema de diseño y responder a comentarios.

La parte que importa para la IA empresarial es la salida: las specs se conectan al servidor MCP de Figma, de modo que los agentes externos, como Codex, pueden leer una spec junto con sus frames vinculados, diagramas, capas de código y fragmentos de Code Connect. Las capas de código, que colocan prototipos interactivos respaldados por código en el lienzo, pasaron a beta abierta ese mismo día.

Specs se está desplegando en beta abierta para planes de pago, en web, escritorio y móvil.

El contexto es una cadena de suministro

La idea es correcta. Microsoft descubrió que los agentes de código siguen usando mal una API cuando su documentación es pobre; lo mismo ocurre con los productos. Un agente no puede respetar una decisión que nunca ve. Poner los requisitos en un formato legible por máquina, junto a los diseños que describen, y exponerlos a través de un protocolo estándar acorta la distancia entre lo que se decidió y lo que se construye.

Pero el contexto sobre el que actúan los agentes se comporta como cualquier otro insumo para producción: tiene una fuente, una versión y un responsable, o debería. El anuncio de Figma dice poco sobre el lado de la gobernanza:

• ¿Qué versión leyó el agente? Una spec se puede duplicar para que los compañeros de equipo trabajen en versiones separadas antes de alinearse. Dos versiones de un requisito, ambas legibles a través de MCP, es la receta para que un agente implemente la equivocada.
• ¿Quién lo aprobó? Los ingenieros pueden marcar frames como listos para desarrollo, pero el anuncio no describe la aprobación de una spec en sí. Un borrador y una decisión se ven igual para un agente.
• ¿Quién puede leerlo? El acceso del agente a través de MCP depende de los permisos. Las specs que incrustan investigación de clientes o planes no lanzados necesitan el mismo pensamiento de acceso que los documentos de los que provienen.

Haga que la spec sea parte del registro de cambios

Los equipos que adopten Specs, o cualquier enfoque similar, pueden cerrar la mayoría de esas brechas con proceso en lugar de características:

1. Marque qué specs son autoritativas, y mantenga los borradores fuera de las carpetas que leen los agentes.
2. Haga referencia a la spec y su versión en la pull request. Cuando un revisor rechaza el cambio de un agente, la primera pregunta debe ser si el agente leyó la decisión correcta.
3. Escriba criterios de aceptación que un agente pueda verificar, no solo prosa que pueda parafrasear. “Los filtros aparecen en el panel lateral” se puede probar; “hacer el filtrado intuitivo” no.
4. Asigne un responsable a los requisitos, tal como argumentamos que las definiciones de negocio necesitan dueños una vez que los agentes las leen.

Una spec legible no es una implementación verificada

El propio encuadre de Figma es cuidadoso, y los compradores deben mantener la distinción: una spec hace disponible la intención; no hace que un agente la siga. Los prototipos en capas de código tampoco son software de producción; los codebases complejos no están necesariamente soportados. La verificación sigue ocurriendo donde siempre, en la revisión y las pruebas.

Lo que cambia Specs es la calidad de la pregunta que un revisor puede hacer. En lugar de “¿por qué hizo esto el agente?”, se convierte en “¿hizo el agente lo que dice la spec?” Esa segunda pregunta tiene una respuesta, y mueve la conversación del gusto a la evidencia.