Receipt-Driven Development: la confianza no se recuerda, se re-deriva
Le puse nombre a algo que no existía: Receipt-Driven Development. Development.
Pero esta no es la historia de una feature. Es la historia de una decisión que me costó dias de inestabilidad, gente esperando, y varias noches de preguntarme si no me había equivocado. Y como toda buena aventura, arranca con una bifurcación en el camino.
Cuando llegó el momento de pensar la versión 2 de gentle-ai, tenía dos opciones. La primera era la segura: agarrar lo que ya funcionaba, pulirlo, sumar features que la gente pedía, y seguir creciendo tranquilo. Nadie me iba a reprochar nada. La segunda era la incómoda: mirar el mercado entero de AI code reviewers y aceptar una verdad que me venía molestando hace rato. Todos hacen lo mismo. Leen tu PR, dejan comentarios, y esos comentarios son opiniones. Opiniones que podés ignorar, que nadie verifica, y que dejan de valer cinco minutos después cuando alguien pushea un cambio más.
Elegí la segunda. Y acá viene la primera enseñanza de esta historia: evolucionar en público tiene un costo, y ese costo lo paga tu comunidad antes que vos. Durante bastante tiempo dejé a muchísima gente en una versión inestable. Cosas que se rompían, comportamientos que cambiaban entre releases, gente que confiaba en la herramienta para su laburo diario y se encontraba con sorpresas. Eso duele. Duele porque este proyecto existe para la comunidad, no al revés. Y sin embargo, si volviera atrás, tomaría la misma decisión. Porque quedarte en lo conocido por miedo a incomodar es la receta perfecta para construir algo mediocre que le sirve a todos un poquito y a nadie de verdad.
¿Y qué era esa idea por la que valía la pena romper todo? Una sola frase: la confianza no se recuerda, se re-deriva.
Pensalo un segundo. Cuando un reviewer aprueba tu PR, esa aprobación es un recuerdo. Un checkmark verde que dice "en algún momento alguien miró algo parecido a esto y le pareció bien". Pero el código sigue vivo. Alguien pushea un fix chiquito, un rebase, un "dale que es una línea". Y el checkmark sigue verde, mintiendo con total tranquilidad. La aprobación quedó atada a un momento del pasado, no al código que realmente vas a mergear.
Entonces la pregunta que me obsesionó fue: ¿y si la aprobación no fuera un recuerdo sino un recibo? Un recibo criptográfico atado a los bytes exactos que se revisaron. No a la branch, no al PR, a los bytes. Y en cada punto del ciclo de vida, antes de cada commit, cada push, cada PR, el sistema recalcula todo contra el estado real de git y lo compara con ese recibo. ¿Cambiaste un byte después del review? Cae el recibo y volvés a revisar. Sin excepciones.
A eso lo bauticé Receipt-Driven Development. Y el nombre no es capricho: se para sobre los hombros de TDD, que todos entendemos en un segundo. TDD te garantiza que el código hace lo que promete. RDD te garantiza que nadie lo tocó después de que fue verificado.
Ahora, entre la idea y la realidad hubo un desierto. Porque una cosa es decir "recibo criptográfico" en un tweet y otra muy distinta es hacer que funcione con el caos real de git: rebases, merges, archivos renombrados, estados intermedios. Cada pieza que construía revelaba tres problemas que no había visto. Segunda enseñanza: cuando construís algo que no existe, no tenés a quién copiarle. No hay Stack Overflow, no hay "cómo lo hizo tal empresa". Estás vos, el problema, y la disciplina de no mentirte sobre si tu solución realmente funciona.
Y para no mentirme, hice que el sistema fuera adversarial consigo mismo. En vez de un reviewer genérico que te felicita, cuatro lentes de IA revisan cada cambio en paralelo, cada uno obsesionado con algo distinto: seguridad, confiabilidad, resiliencia, legibilidad. No están para decirte que está lindo. Están para romperte el código, y cada finding tiene que venir con prueba concreta. Sumado a eso, una regla de justicia que me parecía innegociable: un finding solo puede bloquear tu cambio si TU cambio lo causó. La deuda técnica que ya estaba va a follow-ups. Se acabó el "te bloqueo el PR por algo que no tocaste".
¿Y funciona? Dejame contarte el momento donde el sistema se probó contra sí mismo, porque es mi parte favorita de toda esta aventura. Esta semana desarrollé una feature nueva: publicar por primera vez a un remote vacío. Esa feature pasó SIETE rondas de review adversarial. Siete. Cada ronda encontró un agujero real una capa más profundo que la anterior: primero paths, después blobs, después metadata de git. Y en el medio de todo eso, un secreto sobrescrito antes del primer push, exactamente el tipo de cosa que cualquier reviewer humano dejaría pasar porque "el archivo ya no está", quedó bloqueado con instrucciones exactas de remediación. Eso no lo encuentra un comentario en un PR. Lo encuentra un sistema que no confía ni en sí mismo.
Ahí entendí que los meses de inestabilidad habían valido la pena. Tercera enseñanza, y quizás la más importante: la estabilidad que tiene gentle-ai hoy no es la estabilidad de no haber roto nada. Es la estabilidad de haber roto todo lo que había que romper, temprano, cuando el costo de arreglarlo era mío y no de producción.
Si te quedaste con ganas del detalle técnico, cómo funciona el recibo por dentro, los gates, la admisión causal con evidencia, todo eso está explicado en el capítulo 21 del libro, que es gratis como siempre: https://the-amazing-gentleman-programming-book.vercel.app/es/book/Chapter21_Verifiable-Trust
TDD te dice que el código hace lo que promete.
RDD te dice que nadie lo tocó después de que alguien lo verificó.
Si cambia un byte, cae el recibo.
Nos vemos en la próxima, mis locuritas cósmicas.