Refiner, Implementer, Verifier: un flux de treball pràctic multiagent
A l'article anterior d'aquesta sèrie descrivia l'especificació com el contracte que hauria d'existir abans que un agent escrigui una sola línia de codi. El que no vaig explicar va ser com executar de debò els tres rols que fan servir aquest contracte — Refiner, Implementer, Verifier — com alguna cosa més que tres rols que heu d'adoptar simultàniament durant una sessió llarga.
Etiquetar seccions d'un mateix prompt no és el mateix que separar rols
Durant un temps, vaig executar els tres rols dins d'una única conversa: "converteix això en una especificació, implementa-ho i després verifica-ho". Mateix context, mateix fil continu, només tres encapçalaments en un prompt llarg.
No va funcionar com esperava. El pas de refinar anava amb presses — el model clarament volia arribar a la part d'escriure codi, així que tractava l'especificació com un tràmit en lloc de fer un raonament correcte sobre la petició. I el pas de verificació, executat just després que el mateix agent hagués acabat d'implementar, era sospitosament condescendent. Tenia, estructuralment, tots els incentius per concloure que la seva pròpia feina estava bé.
La solució no va ser redactar millor. Va ser donar a cada rol el seu propi context separat — una invocació de subagent nova, no un paràgraf més a la mateixa conversa. En el moment en què el Refiner no tenia ni idea de com acabaria sent la implementació, i el Verifier no tenia memòria de com de difícil havia estat implementar, tots dos es van tornar notablement més honestos.
Refiner Agent: només llegeix i escriu l'especificació
El Refiner rep la petició original i el context de projecte que necessita per entendre què s'està demanant — no com es construirà. La seva única sortida és l'especificació descrita a l'article anterior: objectiu, criteris d'acceptació, casos límit, dependències, restriccions, fora d'abast.
El que mai hauria de fer és proposar en silenci un enfocament d'implementació. "Faré servir un patró repository aquí" no és una decisió que li correspongui al Refiner. Si la petició és genuïnament ambigua — dues lectures vàlides, sense manera de saber quina és la bona —, la seva feina és dir-ho explícitament, no triar la més plausible i continuar endavant.
Per això el punt d'aprovació humana va just després d'aquest pas: detectar una ambigüitat aquí costa una frase. Detectar-la tres passos més tard costa una reescriptura.
Implementation Agent: llegeix l'especificació, mai la reescriu
Un cop aprovada l'especificació, l'Implementation Agent la rep juntament amb el harness — l'AGENTS.md, les skills rellevants, l'arquitectura i els permisos ja establerts. La seva feina és construir exactament el que s'ha especificat.
Si l'especificació sembla incorrecta o incompleta un cop comença la implementació — i passa —, el correcte no és reinterpretar-la en silenci i continuar endavant. És parar i senyalar-ho. Un Implementation Agent que amplia l'abast "ajudant" o omple un buit de l'especificació pel seu compte acaba de recrear exactament el problema que Spec-Driven Development existeix per evitar, un nivell més avall.
Verification Agent: mai es fia del que explica l'Implementation Agent
Aquest és el rol on més importa un context separat. El Verifier rep l'especificació i el diff real — no el resum de l'Implementation Agent sobre el que va fer, ni la seva explicació de per què una drecera estava bé.
Comprova el resultat contra cada criteri d'acceptació de manera individual, executa o proposa els tests que importen, i busca específicament riscos, deute tècnic i els casos límit que assenyalava l'especificació. No té memòria de com de difícil va ser la tasca, ni cap interès que la implementació sigui bona — que és exactament el que el fa útil. Un agent que recorda haver escrit el codi ja ha decidit, fins a cert punt, que el codi està bé.
Evitar que els rols es barregin entre si
Els tres patrons de fallada amb què més em trobo:
- El Refiner colant opinions d'implementació en lloc de quedar-se en el que s'està demanant.
- L'Implementation Agent "arreglant" o retallant en silenci la llista de casos límit de l'especificació en lloc de senyalar el desajust.
- El Verifier sent indulgent perquè té context de com de difícil va ser la feina — una cosa que no hauria de tenir d'entrada.
Cap d'aquests s'arregla demanant les coses més educadament. S'arreglen acotant el context de cada agent a només el que el seu rol necessita, i escrivint límits explícits — no només el que cada rol ha de fer, sinó el que no té permès decidir.
No necessiteu els tres sempre
Aquests rols són útils tot sols, no només com a etapes d'un pipeline.
De vegades executo només el Refiner — per convertir una idea a mig formar i desordenada en alguna cosa revisable abans de donar-la a ningú, humà o agent. De vegades executo només el Verifier — per auditar codi existent del qual ningú es fia del tot, sense tocar ni una línia. Cap dels dos necessita els altres dos per valer la pena.
Conclusió
Un harness defineix l'entorn. Un orquestrador defineix la seqüència. Aquesta és la part que realment fa la feina dins de cada etapa — i només es sosté si cada rol té el seu propi context, els seus propis límits, i cap accés a les dreceres que van prendre els altres.
Al pròxim article d'aquesta sèrie em centraré en la peça que lliga tot això: Human-in-the-Loop AI Development — quan deixar que el pipeline avanci sol, quan insistir a aturar-lo, i com notar la diferència abans que us costi alguna cosa.
Fins llavors, la pregunta que val la pena fer-se sobre la vostra pròpia configuració no és:
Tinc un Refiner, un Implementer i un Verifier?
És:
Algun d'ells encara sap coses que no hauria de saber?
Si esteu executant alguna cosa semblant a això, m'agradaria saber per on es filtren de debò els límits entre els vostres agents — no dubteu a escriure'm.