Abrir un restaurante toma mucho más que imaginarse un menú. Primero se escriben las recetas, se prueban en una cocina de ensayo, se ajustan cantidades y tiempos, y solo cuando cada plato sale igual dos veces seguidas se prende el fogón para atender a cien comensales. Con Sherlock-docs, una herramienta que lee tutelas y hábeas corpus para sacar sus datos y avisar si un documento ya había llegado antes, seguí ese orden casi sin proponérmelo, y eso me permitió pasar de la idea a una primera versión en siete semanas.
El menú escrito
El problema era conocido. Pasar a mano los datos de una tutela a un registro (quién la presenta, contra quién, la fecha, de qué trata) se estimaba en 15 a 20 minutos en el cálculo inicial del proyecto, que además suponía unos cien documentos al día. Las dos cifras eran estimaciones y así quedaron anotadas. La meta que escribí fue bajar ese registro a 2 o 3 minutos, con una persona revisando cada dato antes de guardarlo.
El 23 de diciembre de 2025 hice el primer commit del repositorio (un cambio guardado con su nota en el historial), y lo que subí fue el resumen de una revisión de literatura, sin una sola línea de código. Ese mismo día cerré los dos primeros sprints (ciclos cortos de trabajo con un objetivo), uno de fundamentos y otro de decisiones. En el documento de decisiones dejé escrito, con la razón al lado, que el MVP (la versión mínima que sirve para probar la idea) no usaría un LLM (el tipo de modelo de lenguaje que hay detrás de los chats de IA), porque el modelo por sí solo pedía más de 8 GB de memoria y spaCy, una biblioteca de procesamiento de lenguaje mucho más liviana, alcanzaba para empezar. Tenerlo escrito me quitó de encima, desde el principio, la tentación de arrancar por lo más vistoso.
La cocina de ensayo
Hasta el 30 de enero casi todo lo que entró al repositorio fueron análisis y cuadernos de Jupyter, esos documentos donde el código se corre por pedazos y el resultado queda al lado, como la libreta del cocinero que anota cuánta sal le puso a cada intento. Ahí probé por separado el OCR (reconocer el texto de una página escaneada), la extracción de nombres, cédulas y fechas, y la detección de duplicados. Todavía no había carpeta de aplicación. Apareció el 31 de enero, y entre ese día y el siguiente le pasé el OCR y la extracción que ya funcionaban en los cuadernos.
Escribir tanto tenía una razón práctica. Buena parte del código lo trabajé con un asistente de IA, Claude Code, y cada sesión con un asistente empieza sin memoria de la anterior. El 3 de febrero lo dejé anotado en una guía de buenas prácticas del proyecto, donde la salida que propuse fue tratar la documentación como contexto persistente. Si una decisión no estaba escrita, el asistente la volvía a improvisar en la sesión siguiente, y a veces la improvisaba distinto. No estoy seguro de que hubiera escrito tanto trabajando solo. Las recetas me servían a mí, pero le servían todavía más a un ayudante de cocina que llega cada mañana sin acordarse de nada.
El primer servicio
El MVP quedó definido en el sprint 8, el 4 de febrero. El 13 de febrero, en el sprint 14, la primera versión ya estaba empaquetada con Docker (un formato que hace que la aplicación corra igual en cualquier equipo) y lista para instalarse, siete semanas después de aquel primer commit sin código.
Y pues, el primer servicio no salió perfecto. En febrero, con la herramienta ya funcionando, el plan del MVP anotaba que registrar un documento seguía tomando de 7 a 10 minutos, lejos de los 2 o 3 que había puesto en el papel, porque había que corregir a mano demasiados datos mal extraídos. Mi error fue tratar la precisión de la extracción como una mejora para después del MVP. Tuve que sacar una versión 2.0 del plan para meterla adentro, con una frase que todavía uso, la de que una funcionalidad que no cumple su propósito está incompleta. Esa corrección también pasó primero por el documento y después por el código.
Cuando miro esas siete semanas, las que más pesan son las cinco primeras, las de las recetas y la cocina de ensayo. Hoy hay herramientas que formalizan esta manera de trabajar, como Spec Kit de GitHub, que propone escribir la especificación antes de pedirle código a un asistente, y vale la pena echarle un vistazo aunque no la uses. Si tienes un proyecto propio en la cabeza, escribe la primera decisión que vas a tomar y por qué la tomas, en un archivo al lado del código, antes de prender el fogón. ¿Cuál sería la primera decisión que escribirías tú?
Serie Sherlock-docs · 1/6 · Todas las entregas · Próxima entrega el 15 de noviembre, sobre cómo leer una tutela escaneada y reconocer quién, qué y cuándo.
Escrito a título personal. Sherlock-docs es un proyecto personal ya terminado; no representa a la Rama Judicial.