De una idea difusa a un panel compartido: cómo construir con Codex una primera app de intercambio por torrents
1. El problema
La necesidad planteada combina tres acciones que suelen resolverse con herramientas separadas: escribir textos e ideas, compartir imágenes y mover archivos entre usuarios. El requisito diferencial es que todo ocurra en un panel interactivo, con elementos que puedan reorganizarse mediante drag and drop y con transferencia distribuida basada en torrents.
Convertir esa intención en producto exige reducir el alcance. Una primera versión no debería intentar ser una pizarra colaborativa completa ni un sistema universal de almacenamiento. El objetivo verificable puede ser más concreto: crear una sala privada, añadir tarjetas de texto e imágenes, reordenarlas visualmente y compartir un archivo mediante un torrent entre dos navegadores conectados.
2. Propuesta de producto
La aplicación sería un panel web de trabajo compartido organizado por salas. Una sala contiene tarjetas de tres tipos: texto, imagen y archivo. Las tarjetas se pueden mover en una cuadrícula, editar o eliminar. El archivo no se sube necesariamente a un servidor central: el sistema genera un identificador torrent y permite que otro participante lo descargue desde un par disponible.
El flujo principal sería:
- Crear una sala y obtener un enlace de invitación.
- Añadir una tarjeta de texto o soltar una imagen desde el sistema operativo.
- Arrastrar las tarjetas para organizar ideas y guardar su posición.
- Seleccionar un archivo, iniciar su distribución y mostrar el estado de seed o descarga.
- Abrir la sala desde otro navegador, recuperar el manifiesto y descargar el archivo mediante el torrent.
Los estados de interfaz deben ser explícitos: sala vacía, carga de datos, archivo preparando torrent, esperando pares, transfiriendo, completado y error. El alcance inicial puede excluir edición simultánea carácter a carácter, comentarios, cuentas complejas, carpetas y sincronización offline.
3. Arquitectura y plan de construcción con Codex
Codex debe actuar como agente de desarrollo: convertir requisitos en código, ejecutar pruebas, revisar errores y preparar una entrega reproducible. No forma parte de la aplicación final. Para evitar que el agente amplíe el producto sin control, el trabajo debe comenzar con un documento de alcance que defina entidades, estados y criterios de aceptación.
Una arquitectura razonable para el prototipo sería un frontend en React con Next.js. El backend puede exponer rutas REST para crear salas, listar tarjetas y guardar posiciones. Una base de datos relacional almacena salas, tarjetas, tipo de contenido, coordenadas, nombre de archivo y metadatos del torrent. El contenido binario no tiene que pasar por la base de datos.
El intercambio entre navegadores puede implementarse con una biblioteca WebTorrent y un tracker compatible con WebRTC. En el navegador, esto no equivale a disponer de un cliente BitTorrent tradicional: la comunicación entre pares se apoya en WebRTC y requiere señalización y conectividad compatibles. El backend conserva el manifiesto y los datos necesarios para volver a anunciar el torrent, pero la transferencia depende de que exista al menos un peer activo.
Una instrucción útil para Codex sería: “Construye solo la primera versión descrita en el alcance. Antes de modificar archivos, inspecciona el repositorio, enumera decisiones y riesgos. Implementa la sala, las tarjetas, drag and drop y la transferencia de un archivo con WebTorrent. Añade pruebas para la API, validación de tipos y un flujo de demostración reproducible. No añadas autenticación, comentarios ni colaboración en tiempo real sin autorización explícita.”
La implementación puede dividirse en fases: contrato de datos y API; panel local con tarjetas; persistencia y enlace de sala; integración de drag and drop; transferencia torrent; pruebas de extremo a extremo; revisión humana y entrega documentada. Codex debería ejecutar linting, pruebas unitarias y una comprobación de producción después de cada fase, no únicamente al final.
4. Qué papel tiene la IA
En este caso, la IA no necesita generar el contenido del panel ni decidir cómo se organizan las ideas. Su función es acelerar el desarrollo: interpretar requisitos, proponer una estructura inicial, escribir componentes, adaptar la integración con la biblioteca elegida, crear pruebas y diagnosticar fallos a partir de sus salidas.
La lógica convencional debe controlar la validación de extensiones y tamaños, los permisos de una sala, la persistencia de posiciones, los estados de transferencia y la navegación. La biblioteca torrent gestiona descubrimiento de pares, fragmentación y verificación de piezas. Codex puede sugerir código para esas partes, pero no debe considerarse una autoridad sobre seguridad, compatibilidad del navegador o licencias.
La revisión humana sigue siendo necesaria para confirmar que el flujo realmente funciona entre dos dispositivos, que los datos sensibles no se registran de forma accidental y que la experiencia explica cuándo el archivo está disponible solo mientras un peer permanece conectado.
5. Flujo de datos e interfaz
La entrada sigue esta secuencia: el usuario crea o abre una sala; el frontend valida el contenido; la API comprueba el identificador de sala y persiste la tarjeta; si se trata de un archivo, el cliente genera o carga el torrent y publica su manifiesto; otro cliente recupera ese manifiesto, contacta con el tracker y solicita las piezas; la interfaz actualiza el progreso mediante eventos del cliente torrent.
El panel debe incluir una zona de drop visible, controles para crear texto y un listado de tarjetas con nombre, tipo y estado. El movimiento no debería depender solo del ratón: teclado, foco visible y una alternativa para cambiar el orden son requisitos de accesibilidad. Las actualizaciones de posición pueden enviarse mediante REST al soltar la tarjeta; no hace falta introducir WebSockets hasta que la colaboración simultánea sea un requisito real.
6. Limitaciones, riesgos y demostración
El principal riesgo técnico es confundir “transferencia por torrents” con disponibilidad garantizada. Un navegador cerrado deja de compartir si no existe otro seed. NAT, políticas de red, bloqueadores y soporte desigual de WebRTC pueden impedir la conexión. Por eso la interfaz debe mostrar “sin pares disponibles” como un estado normal y no prometer almacenamiento permanente.
También hay riesgos de abuso: archivos maliciosos, contenido ilegal, enlaces de sala filtrados y consumo de recursos del dispositivo. La aplicación necesita límites configurables, validación de entradas, rate limiting, expiración de salas y una política clara de moderación. Para una primera demostración conviene utilizar archivos de prueba y una sala controlada, documentando qué ocurre cuando el peer emisor se desconecta.
Todo el MVP es viable con tecnologías actuales, aunque la compatibilidad concreta del cliente torrent y del tracker debe probarse en los navegadores objetivo. La entrega debería incluir repositorio, variables de entorno, instrucciones de arranque, casos de prueba y un vídeo o checklist de demostración: crear sala, soltar imagen, reorganizar tarjetas, transferir archivo, cerrar un peer y registrar el resultado.
7. Siguiente decisión
La primera versión demuestra una hipótesis pequeña sin ocultar sus dependencias. El siguiente paso no es añadir más funciones, sino decidir si la disponibilidad distribuida es suficiente o si el producto necesita un almacenamiento central de respaldo. ¿Debe el equipo mantener el modelo puro entre pares, o conviene introducir un servidor de recuperación para garantizar que un archivo siga disponible cuando ningún usuario esté conectado?
Dirección visual
Imagen editorial horizontal de un panel físico de trabajo con tarjetas de texto, fotografías impresas y una carpeta de archivos conectada visualmente entre dos estaciones de trabajo, mostrando el flujo de organización mediante piezas desplazables y la transferencia distribuida de un archivo entre dos dispositivos; incluir elementos que sugieran una sala compartida y estados de disponibilidad de los archivos, sin texto legible, logotipos ni iconografía genérica de inteligencia artificial.