El test se ejecutó. Imprimió verde. Lo viste pasar. Luego integraste, cerraste la tarea y pasaste a la siguiente, y el verde se fue scroll arriba de la terminal y desapareció, como lo tira casi cualquier flujo. Tres semanas después algo se rompe cerca y no puedes responder una pregunta básica: ¿aquel test llegó a pasar de verdad, y contra qué versión del requisito? La prueba existió unos cuatro segundos y luego la tiraste.
El desarrollo basado en evidencia es la disciplina pequeña y aburrida de no tirarla. Cierra el trabajo con la prueba adjunta.
El estado no es evidencia
Empieza por una distinción que la mayoría de las herramientas difuminan a propósito. Una casilla completada, una pull request integrada, un badge verde, son estado. Te dicen que se declaró un estado. No llevan casi información sobre si la cosa subyacente es cierta, porque son trivialmente fáciles de poner sin que la cosa sea cierta. Una casilla es un clic. Un badge verde puede posarse sobre una suite que nunca se ejecutó.
La evidencia es distinta en su naturaleza. La evidencia es lo que pasó de verdad, registrado: el comando que se ejecutó, la salida que produjo, la versión del contrato contra la que corrió. Puedes inspeccionar la evidencia y reconstruir la verdad a partir de ella. De una casilla no puedes reconstruir nada salvo que alguien, o algo, la marcó. La misma distinción gobierna cómo deberían tomarse las decisiones de producto, no solo cómo se cierra el código.
El hueco importa más justo cuando menos te lo puedes permitir: cuando el autor fue un modelo y nadie miró cada línea. Un autor humano lleva el contexto en la cabeza y se le puede preguntar. Un modelo produjo un artefacto plausible y siguió adelante. El único relato duradero de si funciona es la evidencia que capturaste, porque no hay autor al que interrogar después. Es la misma razón por la que un éxito falso es tan peligroso. «Los tests pasan» como frase es estado. «Los tests pasan» como ejecución capturada contra un contrato nombrado es evidencia. Se leen igual y no son lo mismo.
estado
- casilla marcada
- PR integrada
- badge verde
evidencia
- el comando que corrió
- su salida real
- la versión del contrato
Qué capturar, y dónde vive
El desarrollo basado en evidencia es concreto, no una filosofía. Para una unidad de trabajo, captura:
- Qué se ejecutó. Los comandos e invocaciones reales, no un resumen de ellos.
- Qué produjo. La salida y los códigos de salida, tal como salieron, no comprimidos en «tiene buena pinta».
- Contra qué contrato. Los criterios de aceptación, en la revisión en la que estaban, para que un verde no pueda derivar en silencio a referirse a los requisitos de ayer.
Y luego la parte que todos se saltan: ponlo en algún sitio donde sobreviva. La evidencia que vive en un scrollback de terminal, un log de CI que caduca, o un chat al que nunca volverás a subir es evidencia que no tienes. Tiene que engancharse al cambio, viajar con él y ser encontrable por la siguiente persona y el siguiente agente sin arqueología. Una prueba que no puedes recuperar es indistinguible de una prueba que nunca tuviste.
Por eso una especificación es solo la mitad de lo que necesitas. Una especificación portable lleva la intención y el contrato; la evidencia es lo que prueba que el contrato se cumplió, y tiene que viajar en el mismo sobre o la spec es una promesa sin recibo.
La evidencia caduca, y eso es una virtud
Una objeción habitual: la evidencia se queda obsoleta. El test pasó contra la versión 3 del contrato, el contrato va ya por la versión 5, así que el verde capturado ya no prueba nada. Cierto. Y es justo por eso que la evidencia le gana a una casilla pelada en vez de compartir su debilidad.
Una casilla que se queda obsoleta sigue marcada. No lleva versión, así que nada en ella anuncia que ahora miente. Parece tan válida el día en que quedó obsoleta como el día en que se ganó, que es la peor propiedad que puede tener un estado. La evidencia que nombra la versión del contrato contra la que corrió se queda obsoleta de forma visible. Cuando el contrato pasa a la versión 5, una ejecución registrada contra la versión 3 queda en entredicho por sí sola, y el sistema puede marcarla: esta prueba se refiere a requisitos que desde entonces han cambiado, re-verifica antes de fiarte.
Eso no es la evidencia fallando. Es la evidencia haciendo lo único que el estado no puede, avisarte de cuándo ha dejado de ser cierta. Una obsolescencia que puedes detectar es un problema resuelto, re-ejecutas y vuelves a capturar. Una obsolescencia que no puedes detectar es como una base de código se llena de verdes que se refieren a un mundo que ya no existe. Capturar la versión del contrato junto a la ejecución es lo que convierte la primera situación en la segunda, y no cuesta más que la disciplina de registrar contra qué versión comprobaste. Es la misma razón por la que una especificación y su prueba tienen que viajar juntas: un contrato que se mueve mientras su evidencia se queda atrás es una promesa que nadie puede auditar.
La evidencia hace barata la confianza
Aquí está por qué esto se paga solo. Sin evidencia capturada, fiarte del estado del sistema significa reestablecerlo a mano cada vez que lo necesitas. ¿Esto sigue funcionando? Mejor lo re-ejecuto. ¿Aquello pasó alguna vez? Mejor lo compruebo. Cada pregunta sobre el pasado se vuelve una verificación fresca en el presente, y con agentes produciendo a volumen, las preguntas no paran.
Con la evidencia adjunta, el pasado responde a sus propias preguntas. Abres el registro en vez de reconstruirlo. Esa es la diferencia entre un sistema cuya fiabilidad tienes que re-ganar sin parar y uno cuya fiabilidad puedes consultar. Es la forma práctica de que el cuello de botella sea la confianza, no el output: la evidencia es lo que convierte la confianza de un coste recurrente en un activo guardado. También es lo que hace que la estación de aseguramiento pueda seguir el ritmo, porque asegurar un cambio que llega con su prueba es una lectura, no una re-ejecución.
La evidencia cierra el bucle que abre «hecho»
Esto conecta directo con lo que significa la compleción. Si hecho exige una demostración, la demostración es exactamente la evidencia, y el desarrollo basado en evidencia es solo la insistencia en que la demostración no se evapore en el momento en que la tarea cierra. La compleción produce la prueba; el desarrollo basado en evidencia la conserva. Uno sin el otro es medio bucle. Demostrar hecho y luego descartar la demostración te deja fiándote del recuerdo de un verde que ya no puedes ver.
El revisor también lo siente. Cuando el trabajo cierra con su evidencia adjunta, el último y más importante paso de la revisión, comprobar qué se ejecutó de verdad, es leer un registro en vez de reconstruirlo, que es buena parte de la salida de la fatiga de review.
Dónde encaja PaellaDoc
PaellaDoc captura la evidencia como subproducto del trabajo en vez de como una tarea aparte que nadie hace. Cuando una tarea cierra, qué se ejecutó, qué pasó y el contrato contra el que corrió quedan registrados junto al cambio, no abandonados a evaporarse en una terminal. El estado del sistema deja de ser algo de lo que te fías por fe o que re-verificas a mano, y pasa a ser algo que puedes abrir y leer.
Hay un cambio cultural enterrado en esto, y conviene decirlo claro. Adjuntar evidencia se siente como trabajo extra en el momento, y el momento siempre está ocupado, así que es lo primero que se abandona bajo presión. Ese instinto está del revés. La evidencia que hoy no capturas es la re-verificación manual a la que te apuntas la semana que viene, con intereses, en el peor momento posible, cuando algo ya se está rompiendo e intentas reconstruir si alguna vez funcionó. Capturar la prueba no es un sobrecoste encima del trabajo. Es el trabajo, aplazado o hecho, y aplazado siempre sale más caro.
Los modelos seguirán produciendo artefactos plausibles a un ritmo que ningún humano puede re-comprobar. Adjuntar la prueba, y conservarla, es cómo sigues pudiendo fiarte del sistema sin auditarlo desde cero cada vez que lo miras.
Preguntas frecuentes
¿Qué es el desarrollo basado en evidencia?
Es la disciplina de cerrar cada unidad de trabajo con su prueba adjunta: qué se ejecutó, qué produjo y contra qué versión del contrato, guardado donde la siguiente persona y el siguiente agente puedan encontrarlo. Existe porque la mayoría de los flujos se quedan el diff y tiran la prueba, el verde se va scroll arriba de la terminal y desaparece. Cuando el autor es a menudo un modelo que nadie miró línea a línea, la evidencia capturada es el único relato duradero de si el trabajo funciona.
¿Cuál es la diferencia entre estado y evidencia?
El estado es una casilla marcada, una pull request integrada, un badge verde. Te dice que se declaró un estado y no lleva casi información sobre si la cosa subyacente es cierta, porque es trivialmente fácil de poner sin que lo sea. La evidencia es lo que pasó de verdad, registrado: el comando que se ejecutó, su salida real, la versión del contrato. De la evidencia puedes reconstruir la verdad; de una casilla solo puedes reconstruir que alguien la marcó.
¿Qué debo capturar como evidencia de una tarea terminada?
Tres cosas, más un sitio donde guardarlas. Los comandos e invocaciones reales, no un resumen. La salida y los códigos de salida tal como salieron, no comprimidos en «tiene buena pinta». Y los criterios de aceptación en la revisión en la que estaban, para que un verde no derive en silencio a los requisitos de ayer. Luego engánchalo al cambio para que viaje con él. Una prueba que no puedes recuperar es indistinguible de una que nunca tuviste.
¿La evidencia capturada no se queda obsoleta y deja de servir?
Se queda obsoleta de forma visible, que es justo el punto. Una casilla que caduca sigue marcada y no anuncia nada. La evidencia que nombra la versión del contrato contra la que corrió queda en entredicho por sí sola en cuanto el contrato se mueve, así que el sistema puede marcarla: esta prueba se refiere a requisitos que han cambiado, re-verifica. Una obsolescencia que puedes detectar es un problema resuelto, re-ejecutas y vuelves a capturar. Una que no puedes detectar es como una base de código se llena de verdes que se refieren a un mundo que ya no existe.