Esta es la tercera y última de las tres entradas que configurarán Cuaderno de Bitácora, la primera serie que publico en este Blog. Es, quizás, la entrada más importante, pues en ella se contiene un gran hito personal en lo que al mundo de la programación se refiere, como fue el salto hacia la programación con Python. A diferencia del resto de entradas, con tal de categorizar y guiar mejor al lector, he subdividido el texto en varios subapartados.

1. Cambio de paradigma


Como señalábamos en el segundo capítulo de esta serie, tras nuestros primeros proyectos, nos encontrábamos limitados por el entorno de programación que nos ofrecía Visual Basic para Aplicaciones (VBA) dentro de Word Programador, pues si bien es un entorno idóneo para empezar a crear tus primeros formularios, si lo que quieres crear excede de lo que Microsoft previó originariamente para Word, tu código simplemente no tiene cabida.

Python, en cambio, se nos presentó como un lienzo en blanco. No es un complemento de otra aplicación, sino que es, en la práctica, tanto un lenguaje como su propio ecosistema.

Esta libertad absoluta tiene, por supuesto, sus pros y sus contras. En Python, si tú no programas específicamente que algo ocurra, simplemente no ocurre. Por ejemplo, si no escribes el código para que se abra una ventana, no se va a abrir por arte de magia, o si olvidas programar un botón para guardar los cambios, Python no te los va a guardar por defecto como haría Word. Todo ello requirió de un profundo proceso de aprendizaje.

2. El proceso de aprendizaje

Aprender Python fue como aprender gramática y ortografía de un idioma desconocido. Nos sumergimos en conceptos como tipos de datos, bucles, funciones... términos que para el lector ajeno a este mundo quizá no signifiquen nada, pero que en programación lo son absolutamente todo.

Extracto de mis apuntes sobre programación en Python

Al principio nos bastábamos con lo que íbamos aprendiendo leyendo libros y viendo tutoriales de YouTube, pero llegó un punto en el que la curiosidad y la necesidad desembocaron en una situación de entropía a la que  se tuvo que poner remedio. En mi caso ya no me bastaba con tratar de ser autodidacta: necesitaba estructura. Por ello, decidí formalizar ese caos y empecé a estudiar en la Escuela de Programación de la Universitat Oberta de Catalunya (UOC), además de realizar varios cursos online de otras universidades para asentar una base académica sólida.

En todo caso, este camino no lo recorrimos solos. Como no somos programadores expertos, gran parte de lo que aprendíamos era fruto de la interacción constante con inteligencias artificiales. Desde ChatGPT y Gemini hasta Claude, la IA se convirtió en nuestro mentor, explicándonos desde por qué un bucle no cerraba hasta cómo optimizar bloques enteros de lógica. 

3. División de poderes: Picasso y el del lienzo

Nuestra meta no era pequeña: seguíamos con el firme propósito de crear una herramienta que fuera capaz de consignar todos los escenarios posibles dentro de una conformidad penal. Queríamos codificar la infinita variedad de la realidad judicial, desde la gestión de múltiples acusados y delitos hasta extremos como suspensiones de condena, responsabilidad civil o decomisos.

Dada nuestra inexperiencia, Alberto y yo fuimos conscientes de que el proyecto nos desbordaría si no poníamos orden, así que decidimos distribuirnos el trabajo. Por mi parte, asumí la tarea de crear la interfaz y la entrada de datos, es decir, de diseñar el puente visual entre el usuario y la máquina. Por su parte, Alberto se hizo cargo de las entrañas del sistema: la gestión del almacenamiento y salida de datos.

Nuestra dinámica era curiosa y, en cierto modo, complementaria. Como ya se ha dicho en entradas anteriores, Alberto posee una brillantez técnica innata, aunque de motivación algo selectiva, mientras que yo, por el contrario, partía de un talento mucho menos excelso, pero trataba de compensarlo con una disciplina y dedicación férreas. Él solía decirme en tono jocoso que él era Picasso y yo el que le tensaba el lienzo, y que "no se podía presionar a Picasso", que cuando tuviera algo que pintar, lo pintaría. Y lo cierto es que el tiempo acabaría por darle la razón.

Dramatización (o no). Fuente: ChatGPT.

Esa mezcla de ingenio intermitente y perseverancia constante fue lo que nos permitió cruzar al otro lado del caudaloso río. No voy a negarlo: la travesía fue dura y hubo momentos de frustración profunda frente a la pantalla, pero esa combinación de fuerzas y de formas de trabajar logró que, finalmente, todo empezara a encajar. Con paciencia, el proyecto empezó a dar sus primeros pasos.

4. La interfaz: de decorador a arquitecto

Aunque planeo dedicar una entrada exclusiva a explicar el funcionamiento interno de esta y otras herramientas, no puedo cerrar esta serie sin hablar de lo que fue mi parte: el diseño de la interfaz. 

Fue aquí donde la diferencia con Visual Basic se volvió casi dolorosa. Para quienes no estén familiarizados con el término, lo primero que necesitábamos era una librería de interfaz gráfica (GUI), o lo que es lo mismo, el conjunto de herramientas que permiten que un programa tenga ventanas, botones y menús, evitando que sea solo una pantalla negra con letras blancas.

Te animo a pensar en el último programa que hayas ejecutado, o en la última página web en la que has accedido. Todo lo que ves, y todo aquello con lo que interactúas, se denominan widgets u objetos: desde el sitio donde escribimos una contraseña, hasta el pequeño botón que seleccionamos para decidir si queremos que el sistema la recuerde o el botón de aceptar.

En VBA de Word, diseñar un formulario e insertar los objetos era un juego visual: tenías un cuadro de herramientas que arrastrabas con el ratón sobre una plantilla, ajustando su tamaño como si de una imagen en un archivo de Word se tratara. En Python, sin embargo, por una cuestión de licencias descarté opciones como PyQt5 (que permite ese dibujar visual) y me incliné por Tkinter, la librería que viene integrada por defecto con Python.


Creación de formulario con Word VBA


El problema es que en Tkinter los objetos no se dibujan como se ve en el GIF de arriba, sino que se crean desde el código. No había una plataforma base donde colocar objetos con el ratón como si estuviera jugando al Tetris, sino que tenía que declarar cada objeto mediante código y fijar su espacio exacto mediante coordenadas o ubicaciones relativas.


Creación de formulario con Tkinter (Python)

Aunque no lo parezca, tanto en el GIF anterior como en el código que ves en la última captura se está creando exactamente lo mismo, pero el planteamiento no tiene nada que ver, y creo que se alcanza a comprender que mi experiencia fue pasar de ser un decorador que mueve muebles en una habitación ya construida a ser un arquitecto que tiene que calcular dónde va cada ladrillo en el plano.

Hay que entender que cada  uno de estos objetos tiene su propia naturaleza y una lista interminable de atributos: algunos son compartidos por todos, pero otros son únicos y específicos de esa pieza.

Gestionando los tributos del objeto "cuadro de texto"

Tuve que aprender a configurar cada detalle, lo cual es un proceso de aprendizaje minucioso donde no basta con saber qué pieza quieres usar, sino que tienes que saber exactamente cómo se comporta y qué órdenes acepta para que no acabe flotando en un lugar donde no debería estar.

5. La usabilidad como bandera

Fue trasteando con estas funciones de arquitecto donde aprendí la necesidad crítica de crear una interfaz intuitiva, accesible y, sobre todo, ergonómica. En el día a día de un juzgado, donde el volumen de trabajo es asfixiante y donde el ritmo de la sala es incesante, cada clic cuenta. No basta con que el programa funcione, sino que tiene que ser un aliado que no agote al que lo usa.

Para lograrlo, me serví de un intercambio constante de pareceres con terceros, e incluso recurrí a mi padre, que por su absoluta ajenidad al mundo del derecho y de la programación, se convirtió en mi mejor baza para ejecutar lo que se suele denominar como "monkey testing": si él podía entender dónde clicar sin conocer el procedimiento, la interfaz funcionaba. 

También aprendí que, en ocasiones, lo estético bien merece lo ineficiente. Hay detalles visuales que, aunque impliquen críticas de nuestro Analista Líder de Bases, Eficiencia y Rendimiento Técnico Optimizado (A.L.B.E.R.T.O) por no ser los más optimizados técnicamente, son esenciales para que la herramienta sea humana y usable.

Así seguimos trabajando hasta que cada uno de nosotros había cumplido con su parte, hasta generar una suerte de versión alpha. Sin embargo, llegado a este punto la teoría de la división de funciones acabó por sucumbir a la práctica, pues ambos acabamos necesitando trastear, modificar y corregir el código del otro para que el proyecto no descarrilara. 

Fue en esas incursiones en el terreno del almacenamiento de datos donde aprendí a organizar la información a través de lo que se conoce como Programación Orientada a Objetos: clases, atributos y subclases, entidades elementales para organizar la información dentro del código.

6. Resultados

Tras meses de programación, llegó el momento de compartir la herramienta creada. ¿El resultado? Un éxito rotundo. Logramos crear un sistema integral capaz de generar, de forma automática y precisa, tanto la sentencia de conformidad como el requerimiento de ejecución. 

Ejemplo interfaz de nuestro programa

La reacción de los compañeros fue de absoluto asombro, pues ver cómo procesos que antes llevaban su tiempo de redacción manual y riesgo de error se resolvían ahora en unos pocos clics supuso un cambio radical en la dinámica del juzgado. 

Pero el reconocimiento no se quedó solo en los pasillos de nuestro juzgado. El proyecto fue galardonado con el Premio a la Calidad de la Justicia, en su modalidad de "Justicia más eficaz", XII edición, otorgada por el Consejo General del Poder Judicial (CGPJ). 

Galardón Premios Calidad de la Justicia

Sin embargo, como todo primer gran proyecto, el éxito funcional ocultaba una realidad técnica que solo nosotros conocíamos: el programa era eficaz, pero su arquitectura interna era un caos, fruto de la más absoluta inexperiencia que nos caracterizaba. Era un bloque monolítico, difícil de ampliar y con costuras que amenazaban con romperse si intentábamos añadir una sola función más.

Por ello, los meses siguientes al reconocimiento no los dediqué a crear nuevas herramientas, sino a la llamada refactorización: a abrir el motor de lo que ya funcionaba para reconstruirlo con mínimos estándares de limpieza. Aquello fue mi verdadero bautismo de fuego: entender que no basta con que el código funcione, sino que debe ser sostenible y escalable.

A día de hoy, sin embargo, el código sigue siendo más que mejorable y adolece de problemas estructurales innegables, pero a simples efectos prácticos, el programa cumple con su cometido.

7. Nuevos horizontes e Inteligencia Artificial

Una vez zanjada la fase de desarrollo de la herramienta de conformidad, el camino no se detuvo, simplemente cambió de escala. Decidí continuar en la creación de soluciones que abordaran otro de los grandes cuellos de botella de mi juzgado: la ejecución penal.

Así nació mi asistente de ejecución, un proyecto que supuso un salto cualitativo en el tratamiento de la información. El reto ya no era solo rellenar un formulario, sino lograr que la máquina fuera capaz de leer y entender la hoja de antecedentes penales. Para ello, desarrollé un sistema capaz de extraer datos automáticamente para analizar la cancelabilidad de cada asunto, aplicando una lógica técnica sobre una lectura automatizada. Lo que antes obligaba al usuario a dedicar horas de trabajo mecánico y tedioso, ahora se resuelve con una eficiencia que permite centrar el esfuerzo donde realmente importa: en la decisión jurídica.

Paralelamente, mientras lidiaba con el código tradicional, el mundo asistía a un fenómeno avasallador: la irrupción de la inteligencia artificial. No resultó difícil entender que la IA no era una moda, sino la cresta de una cuarta revolución industrial que iba a redefinir la forma en la que concebíamos nuestra relación con la tecnología.

Lógicamente, no quise quedarme como un mero espectador, así que empecé a trastear con prompts y en el desarrollo de herramientas que integraran esta tecnología en el flujo de trabajo judicial. Sin embargo, este aprendizaje no fue solo técnico: fue, ante todo, un ejercicio de responsabilidad. Me serví de diversas formaciones para entender que, en el ámbito jurídico, el uso de la IA debe estar blindado por una ética y una transparencia innegociables. No se trata de sustituir el criterio humano, sino de potenciarlo bajo un marco de seguridad absoluta.

En cualquier caso, tampoco pretendo profundizar en esta entrada sobre el mundo de la Inteligencia Artificial, pues tengo en mente dedicar varias publicaciones de este Blog a abordar este fenómeno desde múltiples perspectivas.

Por ello, y en conclusión, basta con decir que así ha sido, en esencia, mi recorrido por el mundo de la programación: un camino que empezó por necesidad, creció por curiosidad y se ha acabado convirtiendo en mi forma de combatir el desánimo frente a la precariedad de nuestro sistema judicial.

Con esta entrega cerramos la serie del Cuaderno de Bitácora. No es, ni mucho menos, un punto final, sino más bien el fin del prólogo. Hemos sobrevolado la narrativa y la experiencia humana que hay detrás de este proyecto, pero a partir de ahora, quiero bajar al detalle.

Queda mucho por analizar, muchas dudas por resolver y, sobre todo, mucho camino por recorrer juntos. Gracias por acompañarme en esta travesía de código y togas.