Teníamos menos de una semana, una idea concreta y ganas de probar algo. La Feria del Libro de Madrid arrancaba el 30 de mayo, y queríamos construir una herramienta que ayudara a la gente a saber a qué casetas ir para encontrarse con sus autores favoritos. Decidimos hacerlo usando Claude Code para la mayor parte del desarrollo. Lo que sigue es el relato de cómo fue, qué funcionó y qué nos sorprendió.
El punto de partida
La Feria del Libro de Madrid acoge a más de 4.200 autores firmando durante dos semanas (más de 7.000 sesiones de firma en total, y la cifra crece cada día). La web oficial ofrece la posibilidad de buscar por autor o fecha, pero para encontrar a todos nuestros autores favoritos necesitamos muchas búsquedas (una por autor) y bastante paciencia para no dejarnos ninguno. ¿Cómo podemos simplificar esta búsqueda?
El primer paso es, precisamente, identificar a nuestros autores favoritos. Lo más directo sería un buscador o un formulario donde introducir nombres o géneros, pero queríamos algo más inmediato, y se nos ocurrió hacerlo a partir de una foto de la estantería.
A partir de la foto, extraemos los autores y los cruzamos con el calendario de firmas, devolviendo una lista que nos ayudará a planificar la visita. Queríamos algo cómodo, inmediato, así que optamos por una aplicación de página única (SPA): abres la URL y ya está, no hay que instalar nada ni registrarse y lo puedes hacer desde el móvil.
El trabajo previo
Antes de ponerse a escribir el código había que salvar algunos escollos. El listado oficial de firmas de la Feria no se presenta en un formato cómodo: teníamos que descargarlo, procesarlo y montar un sistema para mantenerlo actualizado a medida que se añaden o cambian firmas (cosa que pasa todos los días, como hemos comprobado).
Mientras trabajábamos con esos datos surgió una segunda idea: si sabíamos qué autores tenía alguien en su estantería, podíamos deducir a grandes rasgos qué tipo de lector era. Y usando ese perfil, recomendarle otros autores que también firman en la Feria. No solo "estos son tus autores", sino ya que vas, "estos también te pueden interesar".
Para que eso funcionara necesitábamos clasificar a los autores por género literario. En vez de reinventar la rueda, hemos usado Thema, un estándar internacional de clasificación de libros por géneros y materias. Thema tiene varios niveles de categorización, pero para este experimento nos quedamos con las categorías de segundo nivel: las de primero son demasiado genéricas (Arte, Ficción, Historia,...) y a partir del tercero ya son demasiado específicas para este proyecto ( Medicina veterinaria preclínica, Figuras humanas representadas en las artes, Ficción de artes marciales, ...).
Después tocaba clasificar a los autores. Por cada uno de los más de 4.200 autores del catálogo, le preguntamos a un modelo de lenguaje (Claude Opus 4.7): dadas estas categorías literarias, ¿cuáles encajan mejor con la obra de este autor? Además, indicamos que si no "conocía" al autor con suficiente certeza, no devolviera nada, para evitar las invenciones en la medida de lo posible. Este proceso de "enriquecimiento" se ejecuta una vez al día, y los resultados se guardan como un fichero que el sistema consulta en tiempo real.
Como parte del mismo preproceso, el sistema genera también una frase de contexto para cada autor clasificado, para indicar por qué ese autor es relevante según nuestros gustos.
El flujo en tiempo real
Cuando el usuario sube su foto de la estantería, el sistema hace dos cosas en secuencia. Primero, un modelo de visión (Claude Opus 4.7) lee los lomos de los libros y extrae los títulos y autores. A continuación, otro modelo (Claude Sonnet 4.6) analiza la lista de autores y deduce el perfil lector, identificando los tres géneros literarios que predominan en su colección.
Con esa información, el sistema busca en el catálogo preprocesado y devuelve dos cosas: las firmas de los autores que se han identificado en la imagen, y recomendaciones de otros autores que también firman y encajan con el perfil literario identificado.
Cómo fue el proceso
El flujo de trabajo con Claude Code, en lo que respecta a la implementación, es simple. Le proporcionas contexto, describes lo que quieres, te ofrece alternativas, eliges una y lo implementa. Nosotros revisamos, indicamos si queremos cambiar algo y vuelta a empezar. No hemos escrito prácticamente nada de código a mano, ya sea Python para el backend o HTML, CSS y JavaScript para el frontend.
Donde el proceso se volvió más curioso fue en las conversaciones sobre diseño. La mayoría de las veces no eran instrucciones técnicas, sino conversaciones sobre criterio: "esto no tiene sentido visual", "la jerarquía aquí está al revés", "me gusta pero no conecta con el estilo que queremos". A veces, como apoyo a estas conversaciones, le hemos pasado un pantallazo o le hemos pedido al mismo Claude que lo obtenga directamente (usando un plugin como playwright).
Lo que fue bien y lo que no
El tiempo de desarrollo se redujo drásticamente. Este proyecto, sin ayuda, nos habría llevado entre 5 y 10 veces más tiempo. Y hay tareas que, con nuestro perfil (backend), directamente no habríamos abordado.
El código es más limpio de lo que cabría esperar. No solo el CSS: el HTML, el JavaScript y la integración con Astro (el framework que usamos para el site del Lab) quedaron bien estructurados y coherentes con el resto del proyecto. Claude Code leía los ficheros existentes antes de proponer cambios, lo que evitó gran parte de la deuda técnica habitual en procesos de iteración rápida.
Es maravilloso como interlocutor técnico cuando no eres experto en el tema. Cuando teníamos que tomar decisiones en áreas en las que controlamos menos (integración con AWS, configuración de CORS, configuración del pipeline de despliegue) podíamos plantear la situación y contrastar las opciones antes de solicitar algo al equipo de sistemas. No siempre tenía toda la información, pero ayudaba a formular mejor la pregunta y anticipar implicaciones. Es diferente a buscar en documentación: la conversación es bidireccional. Y si tienes interés, aprendes bastante por el camino.
El criterio estético no se puede delegar. Claude Code ejecuta bien, pero no detecta que algo no queda bien hasta que se lo indicas: un color que no encaja, un espaciado mal resuelto, textos a todo lo ancho o demasiado estrechos... Esos fallos los detectábamos nosotros, y tuvimos que iterar mucho en esta parte. Lo mismo ocurre con el copy: los mensajes de las pantallas, el texto de los botones, los subtítulos de cada sección (y el huevo de pascua) los decidimos nosotros. Claude Code proponía, pero la última palabra era nuestra.
Qué cambia en el rol del desarrollador
En el artículo anterior definimos un agente como un sistema que decide por sí mismo qué pasos dar y cuándo parar, y Claude Code encaja perfectamente en esa descripción. No solo completa código: lee los ficheros del proyecto, entiende el contexto, propone soluciones, las implementa y las revisa.
Lo que cambia radicalmente para el humano es el tipo de trabajo. Pasas menos tiempo (casi nada en este caso) escribiendo código y más tomando decisiones: ¿esto es lo que quería?, ¿tiene sentido estéticamente?, ¿el código que ha generado es coherente con el resto del proyecto?, ¿la solución que propone es la más adecuada o hay que empujarla en otra dirección?
Ese último punto es importante. El agente proporciona soluciones correctas pero conservadoras: tira de lo más seguro, de lo más probable. El criterio para salir de ese promedio lo seguimos poniendo nosotros, tanto en lo estético como en lo técnico. Y hay cosas que un modelo no puede saber: la voz del proyecto, qué encaja con nuestra identidad, qué palabras suenan bien en este contexto.
Lo que sí cambia de forma notable es la capacidad de abordar trabajo fuera de nuestra zona de confort. Siendo perfiles principalmente de backend, habríamos tenido que pedir ayuda para buena parte del frontend. Con Claude Code como interlocutor y ejecutor, hemos podido sacarlo adelante.
Siguiente iteración
Fírmame_ fue un experimento de una semana: un problema concreto, un equipo diminuto, un plazo corto.
La única forma de entender cómo cambia tu trabajo con estas herramientas es usarlas en algo real. Los artículos ayudan, pero no sustituyen a tener que decidir si el padding está bien o si el copy suena raro.
Este experimento fue nuestra forma de probarlo, y el resultado está disponible para que lo pruebes tú también.
Prueba Fírmame_ → (el servicio funcionará hasta el 14 de junio, última jornada de firmas de la Feria, o hasta que se nos acaben los créditos en Claude)