De dónde vengo
Diez años como desarrollador full stack, tech lead y diseñador, sobre un background artístico y amplio conocimiento del ámbito artístico, web3 y gestión cultural. Amplia experiencia laboral en la capa tecnológica de industrias como el IoT, la gestión de peajes, o la construcción.
Trabajando como desarrollador de software siempre fui del tipo al que le interesa más definir y diseñar la solución que implementarla. Decidir qué merecía la pena construir, y por qué, era lo que más me importaba. Es por ello por lo que normalmente trabajaba cerca de los product owners.
Ahora que los agentes se han hecho cargo de casi toda la implementación, y de casi todo el problem solving, pivotar hacia el diseño de producto es la progresión natural para mí.
juanmamoreno.com, definición del producto
El núcleo de la aplicación es un catálogo de obra artística. El catálogo consiste en un número de piezas, que son, al mismo tiempo, su propio certificado de autenticidad. La autenticidad de cada pieza se garantiza por el hecho de que todas ellas están minteadas en el blockchain Ethereum con un contrato del que solo el propio autor de las obras tiene la llave. La información del catálogo/certificados de autenticidad es pues inmutable e independiente al app
Por tanto, el catálogo es visible y navegable para cualquier usuario o agente, pero las herramientas relaccionadas con su gestión solo pueden ser usadas por el propio artista, que es, al mismo tiempo, el único usuario administrador del sitio.
El app permite al administrador gestionar el catálogo, (mintear nuevos certificados en el blockchain, marcar como vendido/disponible), automatiza posts en diferentes redes sociales en formato imagen y vídeo, y permite editar las fotografías de los certificados fácilmente sin depender de una herramienta externa. Por otra parte, hay una serie de tareas automatizadas, tales como la generación automática de textos descriptivos, la periódica búsqueda inversa de las imágenes en la red, así como la generación en pdf de documentos tales como dossieres, fichas técnicas, certificados de autenticidad...
El sitio está optimizado para ser descubierto por agentes de IA, e incluye un pequeño MCP para leer datos del catálogo, cuyo conector el autor usa en diversos flujos automatizos con Claude Cowork (como por ejemplo, buscar oportunidades que se ajusten al catálogo).
El sitio es estático en sentido estricto. Cada página, en los dos idiomas, se escribe en disco antes de publicarse y se sirve como archivo: no hay servidor que renderice nada, y por tanto no hay servidor que se caiga, que parchear ni que costear. Tod el sistema está pensado para que el coste sea mínimo, un par de euros al mes, aproximadamente.
La arquitectura de Cloud es, en esencia, un servicio que sirve una API, una serie de servicios Cloud de IA (para hacer búsquedas inversas de imágenes en Internet, para generar textos basados en imágenes y descripciones), una base de datos para la información del app y el cache de los certificados, un bucket para las imágenes en altas resolución y los vídeos
Fuera del scope del cloud y el app de frontend quedarían los datos on-chain (los certificados y el contrato) y el almacenamiento distribuído permanente de las imágenes en resolución web.
Descripción del producto
Tres cosas; certificados de autenticidad, catálogo, y toolbox para el artista.
Certificados de autenticidad
Cada obra física corresponde con N NFTs, escritos en un blockchan público (Ethereum). Cada NFT incluye los metadatos de la obra, así como una imagen en miniatura (2kb) en base64 y links a una imagen en resolución web en un storage distribuído y a una imagen en alta resolución almacenada en un bucket cloud. Los NFTs, en adelante, certificados de autenticidad, están minteados por un contrato propiedad del propio artista, que solo él puede firmar. Sin intermediarios ni dependencias, el artista-admin es propietario de toda la cadena. Esta infraestuctura está diseñada con el principal objetivo de ser independiente e inmutable y sobrevivir a este app e incluso al autor mismo.
El certificado de autenticidad de esa obra ↗ El catálogo
Sobre esta colección de certificados se han desarrollado una serie de features para que cualquier usuario pueda navegar el catálogo, buscar, filtrar, descargar certificados y fichas técnicas en pdf, hacer búsquedas inversas de las imágenes en la red, consultar su disponibilidad para la venta, contactar con el artista, pedir presupuesto,...
Aquí, el principal reto es la performance. Para ello, los datos onchain se cachean, y las imágenes se cargan en orden sucesivo de menos a más resoulución, de forma que la navegación es rápida pese a estar cargando en algunos casos imágenes de +10MB
El catálogo, con sus filtros ↗ Toolbox para el artista
El trabajo de cada semana, automatizado: editar la fotografía de un cuadro, recortarla al marco, eliminar brillos, ajustar los niveles, luego escribir y traducir un pequeño ensayo, añadir la obra al catálogo on-chain y publicar las imágenes y el vídeo que se generaron para ella en redes sociales. Todo está automatizado para que la intervención humana sea la mínima posible y el artista pueda centrarse en lo importante, que es la propia creación en el taller, y no la gestión.
La página desde la que se gestiona el catálogo, tras un inicio de sesión
Mantener el control
La solución delega la implementación de las soluciones, así como los pipelines de test y despliegues, en agentes de IA. El flujo está automatizado, de forma que el product owner introduce requisitos en el agente, y éste implementa, ejecuta tests unitarios, tests e2e, asegura que los requisitos preexistentes siguen funcionando, y sólo entonces despliega el frontend y los servicios y hace release de una nueva versión.
En mi opinión, mantener el control de los requisitos, de su permanencia y de cómo se han implementado es el principal riesgo que asumimos al delegar en agentes. Por ello se ha intentado encauzar este trabajo por las siguientes vías:
DOCUMENTO DE REQUISITOS: un documento de requisitos es una afirmación sobre el presente. La veracidad de esas afirmaciones se contrasta nombrando aquello que las demuestra. Un script lee el archivo antes de cada despliegue y rechaza la compilación si un número se usa dos veces, si una entrada no tiene test, si un test nombra un archivo borrado o si cita un test que se ha renombrado.
También es el documento de referencia de los requisitos del app cuya única prueba es el propio texto, ya que, dado que es un proyecto unipersonal, se ha prescindido por completo de cualquier herramienta Agile de gestión de tareas, en este caso se percibe como redundante.
AGENTS: un documento de guía para modelos de lenguaje que pone límites y expresa una preferencia sobre cómo trabajar. La idea es no delegar al 100% decisiones sensibles de arquitectura, diseño, prácticas de desarrollo o creación de tests.
Agentes y crawlers
Cada página se escribe en disco antes de publicarse, el texto está en el HTML y no hace falta ejecutar nada para leerlo; cada obra lleva sus datos estructurados; y el archivo que gobierna a los rastreadores nombra uno por uno a los de los modelos de lenguaje y los deja entrar.
El catálogo entero se publica además como un solo archivo json: título, año, técnica, medidas,... , el texto en los dos idiomas, la imagen, las dos direcciones de la página y el token del certificado. Lo escribe la compilación a partir de las propias páginas, así que no puede contradecirlas, y la compilación se niega a publicarse si el archivo deja de coincidir el build.
El servicio atiende el protocolo MCP en backend.juanmamoreno.com/mcp, para quien quiera ampliar el contexto de su agente con la información del catálogo. Siendo realistas, el único uso del MCP hasta la fecha es el de ampliar el contexto de mis propios agentes, con el fin de que los procesos que automatizo en mi día a día puedan tener un contexto más amplio y consumir menos tokens.
LINKS
El servicio que hay detrás del catálogo vive en un repositorio privado y, deliberadamente, ni se enlaza ni se describe aquí por seguridad.