Quién escribe los 571 criterios

Harvey puntúa a sus agentes de due diligence —la revisión documental previa a comprar una empresa— contra 571 criterios de sí o no por expediente. Preguntas del tipo: ¿cita la cláusula de cambio de control del contrato 14?

Publica el número. No dice quién los escribió.

Ramp hizo lo mismo para su agente de cierre contable y ahí sí lo dice: los redactaron “real-life accountants”, contables de verdad (Ramp Engineering).

Esa línea de diferencia decide si tu eval mide tu dominio o mide a tu propio equipo. Y pesa: con rúbricas así, siete modelos pasan del 23,3% de aciertos al 62,4% sobre 50 expedientes reservados, sin tocar el modelo. Lo que cambia es el código que los rodea: 39,1 puntos de media (Harvey y Baseten, septiembre de 2026).

Escribir esos criterios es trabajo humano, y lo hace alguien con un puesto, la agenda llena y un jefe que no le ha pedido esto. Conseguir sus horas y convertir lo que sabe en artefactos con test: ahí está el trabajo del Forward Deployed Engineer, el ingeniero desplegado en casa del cliente. Cinco casos publicados enseñan qué escribe.

La rúbrica la escribe el experto, y conviene decir su oficio

Los 3.469 criterios de Ramp cubren 237 tareas, y son solo los ocho escenarios que publican de un banco de pruebas mayor (lo desmonté aquí). Son empresas sintéticas, igual que el expediente de Harvey: Aravon Bridge Bank, 2.270 documentos y 31 millones de tokens. Lo sintético es el caso de prueba. El criterio con el que se juzga, no.

Harvey llama a la suya expert rubric y deja la autoría en blanco. Ese dato que no publica es el que permitiría saber si la rúbrica vale: una lista sin autor puede haberla escrito el propio equipo que construye el agente, y entonces mide lo que el agente ya hacía bien.

El cambio que introduce Ramp es de orden. En el reparto viejo el experto llega al final: ve una demo, dice “esto está mal” y su juicio muere en la reunión. Al llegar primero escribe preguntas de sí o no, y esa forma hace reutilizable su criterio: la misma lista mide al agente, compara implementaciones y sirve para ajustar el modelo premiando lo que acierta contra ella. Con eso —y aquí sí tocando el modelo— Harvey lleva a Qwen3.5 del 29,9% al 63,0%.

Conviene mirar quién hace qué ahí. Puntuar lo hace un modelo juez: otro modelo al que se le pasan la respuesta y la rúbrica, y devuelve acierto o fallo por criterio. Decidir qué cuenta como acierto lo firma una persona.

En la práctica: coge la lista de criterios de tu eval —la prueba con la que decides si el agente hizo bien el trabajo— y anota al lado de cada bloque quién lo firma, con nombre y puesto. Si la columna entera coincide con tu organigrama de ingeniería, lo que tienes es la lista de lo que tu agente ya hace bien.

El revisor deja de leer diffs y escribe la lista de lo que rompe

Duckbill son quince personas. Se encontraron con 60 PRs abiertos para un equipo de cinco y, en vez de contratar revisores, cambiaron la regla.

Desde ese cambio, la revisión humana es obligatoria en cinco sitios. La API pública. El servidor MCP —el Model Context Protocol, el estándar con el que un agente descubre y llama herramientas externas—. La autenticación, el sistema de diseño y los cambios no aditivos de esquema. También las skills de los agentes. Lo aplica un script que etiqueta el PR, con el suelo de cobertura de tests al 85%.

Pasaron de 353 a 684 PRs integrados, un 94% más. La mediana de integración cayó de 26 horas, cuando hay humano, a 1 hora cuando no lo hay (Gergely Orosz, septiembre de 2026).

Lo que cambió es dónde vive el criterio del revisor. Antes se juzgaba PR a PR, dentro de su cabeza, y no escalaba más allá de su jornada. Ahora se juzga una vez, como lista de rutas, y el humano queda para el radio de explosión alto: cuánto se rompe si el cambio sale mal.

El camino contrario también está documentado. Si metes un revisor automático sin esa lista, los ingenieros acaban revisando la revisión y no el código.

Escribe tu lista de radio de explosión con quien se ha comido las caídas, no con quien tiene el cargo, y que la aplique un script. Si aguanta dos semanas —mide la mediana de integración y los reverts por etiqueta—, el siguiente hueco de tu equipo ya no es para alguien que revise diffs.

El ingeniero de guardia deja su experiencia en el punto de decisión

En cuatro semanas, el agente de guardia de Ramp asistió 575 de los 1.220 PRs que arreglaron incidentes. Cada arreglo necesitó un 37% menos de ingenieros. Los respondedores lo marcan como útil el 90% de las veces (Ramp Engineering, septiembre de 2026).

Antes de eso hacía lo siguiente. Miraba los logs, veía que el error más antiguo era de hace veinte minutos y concluía que el incidente había empezado entonces. Con total seguridad. Las ventanas de consulta suelen mirar una hora hacia atrás por defecto, así que cogía el dato más viejo que le cabía dentro y montaba encima la teoría del despliegue de hace veinte minutos.

Cualquiera que haya estado de guardia lo pilla al vuelo. Esa persona sabe la trampa, y lo que hizo Ramp fue sacársela de la cabeza y ponerla donde el agente se equivoca.

Lo hicieron en dos sitios. Primero escribieron la pregunta en el prompt: “Before acting on a query result, ask: ‘Could my query be silently excluding the data I’m looking for?’”. Pero en una sesión larga esa línea se diluye, así que añadieron un hook. Un interceptor que corta al agente antes de publicar en Slack y le suelta ahí mismo la orden de cargar la lista de trampas y repasarla. Ramp lo llama instrucciones just-in-time: en vez de cargarlas todas al principio, se entregan cuando el agente va a actuar.

El fallo que corrigen es el de un novato: parar en la primera explicación plausible. Y el artefacto que lo corrige es la experiencia de un veterano, ejecutándose en el instante exacto del error.

En tu próximo post-mortem, añade la línea “qué comprobó el humano que el agente no habría comprobado” y fíchala a nombre de quien lo comprobó. Cuando el mismo nombre salga tres veces, esa persona ha dejado de ser un recurso de guardia: es el autor de tu siguiente artefacto.

Del cliente quieres dos personas, no un documento de requisitos

Las dos personas que necesitas de un cliente no son quien firma el contrato. Son quien da acceso a la fuente real y quien es dueño del fichero que la empresa manda a sus clientes.

Se ve en cómo OpenAI moldeó su producto para servicios financieros, con Morgan Stanley y Evercore como design partners: clientes que co-diseñan antes del lanzamiento (OpenAI, septiembre de 2026). De ahí salieron dos decisiones ajenas al modelo. Indexar y hospedar los datos de Daloopa, PitchBook, LSEG y Crunchbase en su propia infraestructura, porque los conectores MCP de los proveedores les resultaban poco fiables. Y dejar que un administrador publique las plantillas de Excel, Word y PowerPoint de la firma, con barreras de información entre equipos que no pueden compartir datos.

Un documento de requisitos describe el trabajo. Una plantilla es el trabajo. Por eso la plantilla se versiona como código y el documento envejece en una carpeta.

El precio también es de personas: los datos pasan por la infraestructura de quien te vende el producto, y alguien de tu lado tiene que poder decir que no (Maya Zehavi).

Pide esos dos nombres antes del arranque y mete sus artefactos en el repo. Si a las dos semanas solo tienes un documento de requisitos, el problema está en con quién has hablado.

El FDE negocia horas de experto, no listas de requisitos

Los 3.469 criterios de Ramp y los 571 de un expediente de Harvey son horas que alguien le quitó a su trabajo de verdad. Conseguir esas horas es lo que hace el FDE, el ingeniero desplegado en casa del cliente, y esa restricción no aparece en ningún diagrama de arquitectura.

Su entregable es la conversión: entran horas de experto, salen artefactos con test que sobreviven al cambio de modelo. Y la moneda de esa negociación es concreta: el experto suelta horas cuando a cambio recibe menos del trabajo que ya odia. Con eso se le pide el tiempo, no con “necesitamos validar unos casos de uso”.

Conviene saber qué desmontaría el argumento. Si tu dominio cambia de reglas cada trimestre, la rúbrica se deprecia antes de amortizarse. Y en la propia medición de Harvey, repartir el trabajo entre subagentes sube el coste por expediente en seis de los siete modelos (Harvey y Baseten): esto no sale gratis. Lo que no cambia es quién sabe qué significa “bien hecho”.

Métele el tiempo del experto al plan como una línea con unidad y fecha —“seis horas del contable senior en dos sesiones, 80 criterios escritos”—, en vez de como “disponibilidad para dudas”. Y mide criterios por semana: es la única métrica de este trabajo que no depende del modelo.

Cuatro artefactos, cuatro dueños: la rúbrica del contable, la lista de rutas del que se come las caídas, las trampas del veterano de guardia, la plantilla del dueño del fichero. Ninguno lo escribe el modelo, y los cuatro sobreviven a cambiarlo. ¿Quién es esa persona en tu empresa, la que sabe qué significa “bien hecho” en tu dominio, y cuántas horas suyas tienes reservadas por escrito y con fecha?