AbroMelón

Cómo está construido

Una revisión técnica de las decisiones, arquitectura y compromisos del proyecto.

AbroMelón empezó con esta pregunta: ¿podemos recoger muchas opiniones, entender cuáles dicen esencialmente lo mismo y devolver una visión útil de lo que piensa un grupo?

El primer prototipo salió en producción en dos días de desarrollo. Desde el principio decidimos construirlo como un producto real más allá de la demo de laboratorio.

La arquitectura es bastante convencional: Next.js para la aplicación, PostgreSQL como fuente de verdad, Drizzle para el acceso y las migraciones de datos y Better Auth para autenticación. La interfaz utiliza Tailwind y componentes pequeños, intentando mantener el número de abstracciones bajo. La parte de IA está aislada detrás de servicios propios para no acoplar el dominio a un proveedor concreto. La dificultad técnica interesante está en el modelo.

Una persona crea un “melón”, otras personas aportan proposiciones y el sistema intenta detectar cuándo una nueva aportación ya está representada por una posición existente. No basta con comparar texto: dos personas pueden defender exactamente la misma idea usando palabras, idiomas o niveles de detalle distintos. Para trabajar esto construímos varios pequeños datasets sintéticos con casos positivos y negativos y empezamos a probar la consolidación semántica como un problema de producto. La aplicación puede detectar aportaciones similares, proponer una reformulación común y mantener la relación entre el texto original y la posición consolidada. Después esas posiciones pueden agruparse, votarse y formar parte del informe final.

Pronto apareció otro problema: ver las opiniones de los demás condiciona lo que escribimos. De ahí salió una fase ciega opcional. Durante un periodo inicial los participantes aportan sin ver las posiciones existentes. Cuando termina, el melón pasa a una fase abierta donde empieza la consolidación y la interacción con las ideas del grupo. Alrededor de ese núcleo han aparecido decisiones menos visibles pero igual de importantes: distintos estados del melón, permisos del propietario, discusiones públicas y privadas, usuarios anónimos o autenticados, límites de participación, generación de informes sin destruir el estado de la discusión, QR para compartir una sesión y una interfaz que pueda funcionar tanto con seis personas en una reunión como con cientos de participantes. La mayor parte del trabajo no ha consistido en llamar a un LLM. Ha consistido en decidir qué debe hacer el modelo de dominio antes y después de esa llamada, qué información debe conservarse, qué acciones son reversibles y qué comportamiento queremos cuando la IA se equivoca.

En pocos días el proyecto pasó de una prueba sobre similitud semántica a una aplicación desplegada en producción, con autenticación, persistencia, participación, votación, fase ciega, consolidación, informes y una base preparada para internacionalización.

Es también la forma en la que nos gusta construir productos con IA: una tecnología concreta resolviendo una parte concreta del sistema, rodeada de software bastante normal y de decisiones de producto explícitas.