El porqué del código, guardado junto al código
Todo código tiene una segunda mitad que vive en la cabeza de la gente: por qué estos reintentos, por qué este fallback, por qué se descartó lo obvio. Y se va cuando se van ellos.
Veinte lenguajes, indexados como código
Los símbolos y las llamadas entre ellos entran en el mismo grafo que tus notas, no en un buscador aparte. Una nota de decisión y la función que salió de ella acaban siendo vecinas, porque es lo que son.
El historial de git, indexado junto a las notas
Qué cambió, cuándo, y qué se escribió sobre ello en su momento, todo alcanzable en una sola pregunta. El commit te dice qué pasó; la nota te dice por qué; por separado ninguno sirve de mucho.
El radio de impacto, antes de tocar nada
Pregunta qué depende de un símbolo y la respuesta sale del grafo, no de una búsqueda de texto que encuentra todos los comentarios donde aparece el nombre. Sirve justo cuando el código no te suena, que es cuando hace falta.
Heredas un servicio y te encuentras un número mágico
Siete reintentos. Ningún comentario. El blame apunta a un commit que dice «fix flakiness».
Preguntas por qué los reintentos son siete. La respuesta cita una nota de decisión de hace dieciocho meses —el timeout del propio almacén se midió en seis segundos bajo carga, siete reintentos cubrían con margen el peor caso observado, y bajar a tres devolvía el fallo— y, al lado, la función que lo implementa y el test que lo fija.
Ahora sabes si puedes cambiarlo. La alternativa era cambiarlo, publicarlo y enterarte después.
¿Puedo usar esto con mis datos?
La recuperación es local. La generación va adonde tú la apuntes.
Encontrar los pasajes correctos ocurre en tu máquina, siempre. Lo que pase después lo eliges tú: conecta un modelo en la nube y los pasajes recuperados viajan a ese proveedor, exactamente igual que si los pegaras tú; apúntalo a un modelo que se ejecute en local y no sale nada de la máquina. Esa segunda opción existe hoy, y es la que convierte «¿dónde se tratan nuestros datos?» en «en tu dispositivo».