Especificación, trece tickets y un andamiaje verificado de extremo a extremo

El proyecto final de Trascendence de 42 Barcelona ya está en marcha: una plataforma de búsqueda de empleo asistida por IA, con un perfil profesional, búsquedas que se pueden deshacer, extracción de ofertas y un componente de reclutador. Este primer día del diario se centra en los cimientos.

Todo queda en su carpeta

La primera decisión de organización: cada funcionalidad vive en su propia carpeta, con sus rutas, servicios y plantillas. Así, las piezas relacionadas no se dispersan y añadir una nueva no termina dentro de los módulos de otra funcionalidad. Con el mismo enfoque preparé la especificación inicial y el mapa de decisiones, y publiqué trece tickets en GitHub Issues con sus dependencias nativas. La identidad corporativa también ha entrado en la planificación, aunque el logotipo y los colores aún están por decidir.

El andamiaje, probado contra una base de datos real

Antes de repartir los tickets hacía falta un andamiaje que no generara conflictos entre agentes. La clave ha sido descubrir por qué el esquema y las rutas se componen solos: cada funcionalidad declara sus tablas y su enrutador en su carpeta, y el servidor los recoge al arrancar. Añadir una funcionalidad no obliga a editar un registro central que todos tendrían que modificar. El andamiaje se ha verificado de extremo a extremo contra PostgreSQL real, con el registro de usuario, el inicio de sesión y el rol por defecto funcionando, y con la aplicación compilada y arrancada desde el resultado de la compilación.

La lucha con el límite de consumo

Quería repartir los trece tickets entre subagentes en paralelo, cada uno en su propio árbol de trabajo, pero el límite de consumo del modelo se cargó a los agentes a los pocos minutos, dejando trabajo sin terminar. El agente también falló por su parte: cambió el contrato de rutas mientras los agentes estaban en marcha. La lección quedó en dos partes: cuando el límite de consumo está agotado, lo fiable es implementar en serie desde la sesión principal, sin prometer un paralelismo que el entorno no aguanta; y fijar el contrato técnico antes de repartir el trabajo, no mientras corre. Parte de lo que quedó abandonado en los árboles de trabajo se recuperó a mano.

Trece tickets cerrados, y la revisión que destapó las carencias

Primero quedaron implementadas cinco funcionalidades, con pruebas y sin cabos sueltos: acceso a la cuenta, perfil profesional, búsquedas que se pueden deshacer, configuración y límites de servicios, y administración de usuarios y roles. La batería de pruebas sumaba 49 pruebas de API y 28 de web. Después se completaron los trece tickets. Pero la revisión en dos ejes, estándares y especificación, destapó lo que una revisión personal no veía: la aplicación devolvía texto inventado en lugar de llamar a un proveedor real, las credenciales propias y los límites no controlaban el uso, los avisos no tenían planificador ni correo, el reclutador no veía el perfil del candidato y varias pantallas no estaban montadas.

Las correcciones han cambiado más el fondo que la forma: ahora hay un cliente de IA real con una API compatible con OpenAI, la resolución de credenciales se realiza en cada petición y descuenta el límite del servicio, el aviso sale por SMTP al correo de cada persona con el planificador disparándolo, y el reclutador autorizado accede al perfil del candidato. La batería de pruebas cuenta ahora con 116 pruebas de API y 36 de web, y la compilación completa se realiza correctamente.

La lección del día

Las pruebas en verde no equivalen a un producto que funcione. Las carencias que solo se ven cuando te preguntas qué ocurrirá en producción marcan la diferencia entre una batería de pruebas que pasa y una aplicación que hace su trabajo.