Un agente termina y escribe «Hecho». Has leído esa palabra mil veces de compañeros humanos y pesaba, porque detrás había una persona que había juzgado el trabajo, sabía que sería suyo el bug si se equivocaba, y estaba gastando su credibilidad en la afirmación. El «hecho» del agente se ve idéntico y no carga nada de eso. Es la palabra más probable que emitir tras una interacción con forma de tarea. No apuesta nada, no significa nada, y llega con seguridad total.
Así que la definición de «hecho» que venías usando se rompió en silencio. Daba por hecho a un humano detrás de la palabra. Quita al humano y la palabra queda vacía, y todo proceso construido sobre creerla ahora no cree nada.
Lo que «hecho» colaba de contrabando
La vieja definición de «hecho» funcionaba en parte sobre el papel y en parte sobre una persona. Sobre el papel decía cosas como: código escrito, tests pasando, revisado, integrado. Pero mucho del aseguramiento real no estaba en la checklist. Viajaba dentro del humano. Cuando un desarrollador decía «hecho», respondía implícitamente de que había ejecutado la cosa, de que entendía lo que cambió, de que habría notado si rompía algo cercano, de que no iba a quedar como un idiota en la daily de mañana. La checklist era un suelo. La persona era el techo.
Los agentes quitaron a la persona y dejaron la checklist, y la checklist a solas resulta ser una cosa débil. «Tests pasando» significa que el agente dijo que los tests pasan, que no es lo mismo que que los tests hayan corrido. «Revisado» significa que alguien ojeó un diff demasiado grande para verificarse de verdad. «Código escrito» es el único ítem fiablemente cierto, y nunca fue el punto. Las partes de «hecho» que hacían el trabajo real eran las que vivían en el juicio y la apuesta de un humano, y esas no se transfirieron al agente junto con el tecleo.
«Hecho» ya no puede ser un estado
Aquí está el desplazamiento, y no es sutil. «Hecho» ya no puede ser un estado que algo declara. Tiene que ser un estado que la evidencia demuestra.
Un estado es una etiqueta. «Completo». «Pasando». «Listo». Un agente puede producir cualquier etiqueta al instante, y lo hará, porque producir la etiqueta que encaja con una tarea de aspecto terminado es justo lo que optimiza. Una etiqueta no vale nada como señal precisamente cuando más la necesitas, en la frontera entre funcionar y estar roto, porque la etiqueta se ve igual en ambos lados.
La evidencia es distinta. La evidencia es un artefacto que puedes inspeccionar que se vería distinto si el trabajo no estuviera hecho de verdad. Un proceso de test que salió con código cero, con su salida guardada. Un build que produjo un binario que corre. Un diff que un escaneo de seguridad dio por limpio, con el informe adjunto. La captura, el log, la ejecución grabada. La propiedad que define a la evidencia es que no puedes generarla siendo seguro de ti mismo. Existe porque algo real ocurrió, o no existe. Una definición de «hecho» construida sobre evidencia sobrevive a la velocidad de la IA porque la fluidez del agente, su único superpoder, no le compra nada. No puede convencer a una suite de tests de que salga con código cero.
Esta es la idea entera detrás de cerrar el trabajo con la prueba adjunta en vez de con el estado declarado, y es la única versión de «hecho» que significa algo cuando la entidad que lo informa no apuesta nada por acertar.
Reconstruir la definición, ítem a ítem
Coge cada línea de tu vieja definición de «hecho» y pregunta: ¿cuál es la evidencia y quién la produjo? Si la respuesta es «lo dice el agente», reescríbela.
No «los tests pasan» sino «la suite de tests corrió y su salida está adjunta». La distinción es la reforma entera. Una es una afirmación que hace el agente, la otra es un registro que produjo un proceso. Adjunta la ejecución, no el resumen de la ejecución.
No «cumple los requisitos» sino «contrastado contra criterios de aceptación que existían antes del código». Si la corrección se juzga contra criterios escritos después de ver la implementación, la implementación definió su propia nota de aprobado. Los criterios tienen que ser anteriores al código, y la comprobación contra ellos tiene que quedar registrada.
No «revisado» sino «el radio de impacto se verificó mecánicamente, y un humano confirmó el alcance y las líneas que cargan riesgo». La review de código de agente que significa algo empieza por el alcance y va respaldada por evidencia, no es un diff que alguien scrolleó. Di qué parte respaldó una máquina y qué parte una persona.
No «sin problemas obvios» sino «las comprobaciones que pueden fallar corrieron y pasaron». Un «hecho» que solo incluye comprobaciones que siempre tienen éxito es teatro. Cada condición de la definición debería ser algo que pudiera volver en rojo, o no está verificando nada.
hecho de antes
- tests pasan
- cumple requisitos
- revisado
- sin problemas obvios
hecho a velocidad IA
- salida adjunta
- contrastado vs criterios
- radio verificado
- checks que fallan corren
El patrón en todas: sustituye la palabra del agente por un artefacto, y nombra el proceso que hizo el artefacto. Lo que en realidad haces es sacar las partes de «hecho» que solían vivir en el juicio de un humano hacia evidencia explícita y producida, porque el humano que las sostenía ya no está en el bucle, y el agente que lo sustituyó no es de fiar para sostener nada.
«Hecho» viaja con el trabajo o no cuenta
Una propiedad más que la definición a velocidad de IA necesita. La evidencia tiene que viajar adjunta al trabajo, no vivir en un sitio aparte que alguien tenga que ir a ensamblar luego. La razón es el volumen. Cuando una persona publica el código de una semana en un día, «reunimos la evidencia en la release» significa que la evidencia no se reúne nunca, porque la release es una avalancha y nadie va a reconstruir la prueba de cuarenta cambios integrados a posteriori.
Así que «hecho» significa que la prueba se adjunta en el momento de completar, por cambio, automáticamente, o «hecho» no significa nada. Una definición de «hecho» que exige que un humano recopile evidencia a mano no sobrevive a la velocidad de la IA por la misma razón que no sobrevivió la palabra del humano: da por supuesta a una persona lenta y cuidadosa en un bucle que ya no es ni lento ni está dotado de personal. La evidencia la tiene que producir y atar al trabajo el proceso que hace el trabajo.
Aquí es donde la definición de «hecho» deja de ser una página de wiki que nadie lee y se vuelve algo operativo, un gate. Y conecta directo con verificar código generado por IA, porque una definición de «hecho» construida sobre evidencia es solo la verificación enunciada como política: nada está hecho hasta que existe y está adjunta la prueba de que lo está.
Dónde encaja PaellaDoc
Una definición de «hecho» que vive como evidencia adjunta por cambio, producida automáticamente, no es algo que puedas sostener en la cabeza a lo largo de cuarenta merges al día. PaellaDoc lo vuelve trabajo del sistema. Los criterios de aceptación se ponen antes de generar. Las comprobaciones corren y su salida se captura. El trabajo no llega a «hecho» hasta que la evidencia existe, y la evidencia viaja con el cambio en vez de esperar a ensamblarse en la release. Defines una vez qué significa hecho, en términos de prueba y no de la palabra del agente, y la fábrica se niega a llamar terminado a nada hasta que puede enseñarte por qué.
Preguntas frecuentes
¿Por qué el «hecho» de un agente de IA no significa nada?
Cuando un humano decía «hecho», respondía de que había ejecutado la cosa, entendía el cambio y sería suyo el bug si se equivocaba. Ese aseguramiento vivía en el juicio y la apuesta de la persona, no en la checklist. Un agente emite «hecho» como la palabra más probable tras una interacción con forma de tarea. No apuesta nada y llega con seguridad total funcione la feature o no, así que todo proceso construido sobre creer la palabra ahora no cree nada.
¿Cómo escribo una definición de «hecho» para trabajo generado por IA?
Coge cada línea de tu vieja definición y pregunta: ¿cuál es la evidencia y quién la produjo? Si la respuesta es «lo dice el agente», reescríbela. No «los tests pasan» sino «la suite corrió y su salida está adjunta». No «cumple los requisitos» sino «contrastado contra criterios de aceptación que existían antes del código». No «revisado» sino «radio de impacto verificado mecánicamente, alcance confirmado por un humano». Sustituye la palabra del agente por un artefacto y nombra el proceso que lo hizo.
¿Cuál es la diferencia entre un estado y la evidencia en una definición de «hecho»?
Un estado es una etiqueta, «completo», «pasando», «listo», que un agente produce al instante, y se ve idéntica a ambos lados de la frontera entre funcionar y estar roto. La evidencia es un artefacto que puedes inspeccionar que se vería distinto si el trabajo no estuviera hecho de verdad: un proceso de test que salió con código cero con su salida guardada, un build que produjo un binario que corre. No puedes generar evidencia siendo seguro de ti mismo. Existe porque algo real ocurrió, o no existe.
¿La evidencia de «hecho» tiene que recopilarse automáticamente?
Sí, o no se recopila. Cuando una persona publica el código de una semana en un día, «reunimos la evidencia en la release» significa que nadie reconstruye la prueba de cuarenta cambios integrados a posteriori. «Hecho» significa que la prueba se adjunta en el momento de completar, por cambio, por el proceso que hace el trabajo. Una definición que necesita que un humano ensamble la evidencia después da por supuesto un bucle lento y dotado de personal que ya no existe.