Construyendo Linkwise: del.icio.us en 2026

¿Os acordáis de del.icio.us? Para quienes trabajábamos con internet a mediados de los 2000, esa herramienta era un básico. Joshua Schachter creó algo que desde mi punto de vista fue brillante: un sistema de marcadores sociales basado en etiquetado libre que creaba lo que se llamó «folksonomía”, es decir, conocimiento organizado por la gente, no por taxonomías formales. Yahoo lo compró en 2005 y, como tantas otras adquisiciones, lo dejó morir lentamente. Imagino del.icio.us en 2026 y veo Linkwise.

Hace tiempo que sigo echando de menos la simplicidad de esa aplicación. No me interesa en absoluto un Notion con mil funcionalidades, no un sistema complejo de gestión de conocimiento. Sólo guardar un enlace, ponerle dos tags, encontrarlo después. Así que he decidido construir mi propio clon como side project para 2026.

Me he marcado como objetivo que este post documente el proceso: cómo he construido Linkwise usando Mocha (una herramienta de vibe coding de la que ya he hablado por ahí en alguna ocasión), los aprendizajes desde la perspectiva de UX, y las recomendaciones que haría a otros profesionales que estén explorando estas nuevas formas de crear productos digitales.

El contexto: vibe coding y límites claros

Antes de empezar quiero hacer, una vez más, una aclaración importante: esto es una prueba de concepto, no es una aplicación en producción. No hay un equipo de tecnología detrás, no hay QA, no hay infraestructura robusta. Esto es lo que una persona con un perfil no técnico puede construir en unas horas usando herramientas de IA generativa para codificar. Ni más ni menos. Y esto me parece importante aclararlo e insistir en ello, para que no haya dudas y para que las expectativas sean realistas y honestas.

Elegí Mocha porque permite iterar rápidamente mediante prompts en lenguaje natural. No es muy distinta a otras aplicaciones de este estilo, pero tengo que reconocer que para mí es la más simple y la que genera resultados, con menos fricción y menos complejidad posterior. El flujo es sencillo: describes lo que quieres, la herramienta genera el código, revisas el resultado, y ajustas el prompt si es necesario. Es vibe coding. Confías en que la IA entiende tu intención y traduce tu descripción a código funcional. Eso es mucho confiar, pero por eso las iteraciones tienen todo el sentido del mundo y marcan la diferencia.

Esto tiene ventajas bastante evidentes de velocidad, pero también limitaciones claras que iré mostrando. Parafraseando el estupendo libro de Enric Juliana Aquí hemos venido a aprender, eso no lo olvidéis nunca.

Timeline: de la idea al MVP funcional

Día 0: definición del concepto (21 enero)

Lo primero fue cristalizar la idea. No quería replicar del.icio.us exactamente (aunque la nostalgia tiraba hacia que lo hiciese, pude con ese impulso), sino capturar su espíritu pero con una ejecución más pulida Y un tanto actualizada. Mis referencias de diseño son claras y transparentes:

• Del.icio.us: densidad de información, etiquetado libre, funcionalidad sin florituras
• 37Signals/Basecamp: tipografía clara, espacios generosos, diseño honesto y directo

Decidí también el stack: auth con Google OAuth (por simplicidad), cumplimiento GDPR desde el principio (no en vano opero desde España), estética accesible AA. Y en inglés, porque así amplío el alcance potencial.

Primer aprendizaje UX: definir las referencias visuales concretas es fundamental cuando trabajas con IA. No basta con decir minimalista o limpio. Necesitas mucha más precisión para dar todo el contexto a la herramienta generativa: estilo 37Signals da contexto específico que la IA puede interpretar.

Día 1: prompt inicial y estructura base (21 enero)

Construí el primer prompt siguiendo una estructura que aprendí iterando:

1. Contexto del proyecto: qué quiero construir y por qué
2. Estética y principios de diseño: referencias concretas, paleta, tipografía
3. Features core: lista priorizada del MVP
4. Requisitos técnicos: auth, accesibilidad, GDPR
5. Exclusiones explícitas: qué NO incluir en el MVP

Por motivos que algún día contaré, siempre me he guiado por un principio: es tan importante saber lo que uno quiere, como especialmente saber lo que no. Listar explícitamente lo que no quieres evita que la IA añada funcionalidades útiles que lo complican todo innecesariamente.

El resultado: en menos de 40 segundos tenía la estructura base de la aplicación con auth de Google, base de datos configurada, y la estructura HTML semántica. Una auténtica revolución para mi yo fronter de 2003.

Aprendizaje UX: en diseño de producto, sabemos que definir qué NO hacer es tan importante como definir qué hacer. Con IA, esto se vuelve literal: si no lo excluyes explícitamente, aparecerá. Y al principio, o en ocasiones puede parecer que mola, pero no.

Días 2-3: iteración sobre funcionalidad core (21-22 enero)

Aquí empezaron las iteraciones. El patrón se fue repitiendo:

1. Mocha genera código según mi prompt
2. Reviso en preview
3. Encuentro algo que no funciona como esperaba
4. Ajusto el prompt con instrucciones más específicas
5. Repito

Algunos ejemplos concretos:

Problema: el formulario de añadir bookmark mostraba debajo toda mi lista de enlaces existentes. Esto rompía el foco y abría la puerta a una sobrecarga potencial en el rendimiento cuando hubiese una lista larga de enlaces.

Solución prompt: “la página para añadir un enlace no debería cargar debajo el resto de enlaces que ya tengo. Crea una página separada /add solo para el formulario.»

Resultado: página dedicada, mucho más limpia.

Problema: los tags se mostraban como pills modernas con bordes redondeados y colores. Muy alejado del espíritu del.icio.us.

Solución prompt: “remove pill/badge styling completely. Display as plain text separated by spaces or commas. Clickable but look like text links.«

Resultado: tags como texto simple, mucho más del.icio.us.

Problema: el diseño inicial era demasiado corporativo moderno, con mucho padding y elementos flotantes.

Solución prompt: un prompt completo describiendo la estética del.icio.us + 37Signals, con ejemplos específicos: «Bookmark titles: 22px, bold, classic blue link color (#0000EE). Domain URLs: 14px, gray (#666). Reduce card padding significantly (12-16px). More information visible on screen.«

Aprendizaje UX: el feedback visual inmediato que da una herramienta como Mocha, o similares, acelera un montón las iteraciones de diseño. En proyectos tradicionales, cada cambio estético requiere coordinación con desarrollo. Aquí puedes iterar sobre detalles visuales en minutos.

Pero hay un trade-off: la rapidez puede llevarte a no pensar lo suficiente antes de ejecutar. Me pasó varias veces que pedí un cambio, vi el resultado, y me di cuenta de que no había considerado el caso edge o la implicación en vista móvil.

Día 4: añadiendo inteligencia artificial para la sugerencia de tags (22 enero)

Una de las features que más me interesaba era usar IA para sugerir tags automáticamente al añadir un enlace. El razonamiento era claro: mantener consistencia en el etiquetado es difícil. Si ya tengo 20 enlaces etiquetados con ux-research, que la IA sugiera ese mismo tag (no user-research) cuando añado contenido similar. O lo que es lo mismo, que la tecnología me facilite la consistencia. Esto se notará mucho al escalar.

El prompt para conseguir esta feature:

When a user adds a new bookmark by entering a URL, 
analyze the content and suggest 3-5 relevant tags 
automatically based on:
- Page title, meta description, main content
- User's existing tags (prioritize their vocabulary)
- Format: lowercase, hyphens for multi-word tags

Configuré la API de OpenAI, lancé… y para sorpresa de nadie no funcionó. Los logs mostraban que la clave API no se estaba cargando bien en el entorno de desarrollo.

Aquí descubrí una limitación importante: Mocha tiene dos entornos (desarrollo y producción), y los secrets configurados sólo aplican a producción. Para desarrollo, necesitas un archivo .dev.vars local. La documentación no era del todo clara en esto (yo tampoco soy un experto en esta movida), y pasé bastante tiempo debuggeando algo que era simplemente configuración. Pero bueno, aprendí un montón, y eso que me llevo.

Aprendizaje UX: las herramientas de IA para desarrollo todavía tienen rough edges en temas de configuración de entornos, manejo de secrets, y debugging. Si estás acostumbrado a las guardrails de un entorno de desarrollo tradicional, te vas a encontrar con sorpresas.

La expectativa de describe lo que quieres y mágicamente funciona es aspiracional, no realista. No nos vengamos arriba. Hay que estar preparado para debugging tradicional.

Día 5: refinamiento visual o el sidebar de tags (22 enero)

Otra cosa que quería hacer porque me parecía maravillosa del original es recuperar el layout clásico de del.icio.us: lista de bookmarks a la izquierda, nube de tags en sidebar derecho. Esto es un cambio de layout importante que en código tradicional requeriría repensar estructura, CSS grid, responsive behavior…

El prompt:

Desktop layout (>1024px): two-column layout.
Left column (65-70% width): search box and bookmark list
Right sidebar (30-35%): tag cloud with all tags, 
sorted alphabetically, clickable for filtering.
Mobile: single column, tag cloud above bookmarks.

Funcionó a la primera. Grid CSS generado correctamente, responsive breakpoints apropiados, sidebar con scroll independiente. Eso sí, en móvil el resultado no me convence cuando escala. Eso aún lo tengo que pulir.

Aprendizaje UX: para cambios estructurales de layout, estas herramientas son muy potentes. Lo que tradicionalmente podía requerir de horas de CSS y testing cross-browser, aquí sucede en segundos. Y me asombra y me sigue pareciendo magia.

Pero hay un matiz: no es facil ver el código intermedio y validar la implementación técnica. No nos queda más remedio que confiar en que la IA ha generado CSS mantenible y eficiente, y para una prueba de concepto está bien. Para producción, sería necesaria una auditoría técnica.

Día 6: paginación y detalles de UX (22 enero)

Estamos en un punto en el que con la funcionalidad básica ya funcionando, los detalles de UX se volvieron evidentes y más necesario. Y mi corazón de diseñador respiró tranquilo, porque me encontré en un territorio mucho más conocido:

1. Cargar todos los bookmarks de golpe no escala. Necesitaba paginación.
2. El bookmarklet (la feature estrella de del.icio.us) no funcionaba correctamente con React.

Para paginación, el prompt fue directo:

Display 10 bookmarks per page. Simple pagination 
controls at bottom: ← Previous [1 2 3] Next →
Maintain filters and search when paginating.
URL should reflect current page (?page=2).

El bookmarklet fue más tricky. React bloquea javascript: URLs por seguridad. La solución pasó por usar useEffect para establecer el atributo href directamente en el DOM, bypassing el filtro de React. Obviamente, todo esto lo aprendí por el camino, me supuso mucha fricción, pero aquí estoy contando lo orgulloso como si supiera de lo que estoy hablando.

Aprendizaje UX: los detalles de UX (paginación, estados de carga, manejo de errores) requieren prompts específicos. La IA no va a añadirlos de manera proactiva porque son best practices. Tienes que pedirlos explícitamente. Y para eso tienes que saber lo que quieres. Y lo que no.

Esto es importante: el juicio profesional no se puede delegar. La herramienta genera lo que describes, no lo que deberías haber descrito. La responsabilidad de pensar en edge cases, accesibilidad, performance… sigue siendo nuestra.

Día 7: GDPR y contenido legal (22 enero)

Para operar en Europa, GDPR no es opcional. Necesitaba:

• Privacy Policy completa (LOPDGDD española + GDPR)
• Terms of Service
• Funcionalidad de exportar datos (JSON download)
• Funcionalidad de borrar cuenta

Esto es contenido legal más features técnicas, así que mi prompt fue muy específico (o al menos eso intenté):

Create comprehensive Privacy Policy compliant 
with GDPR and Spanish LOPDGDD. Must include:
- Data controller information
- What data we collect and why
- User rights (access, rectification, erasure, 
  portability, complaint to AEPD)
- Data retention policies
- Cookie usage

Implement:
- Settings page with "Export all data" button 
  (downloads JSON)
- "Delete account" with confirmation flow

El resultado para mí fue bastante razonable: páginas legales bastante completas (aunque siempre recomendaría revisión por legal), y features de exportación/borrado funcionando.

Aprendizaje UX: Como pasa para otro tipo de contenidos, datos y procesos, para contenido legal o regulatorio, la IA es un buen punto de partida pero NO es sustituto de la revisión profesional. El texto generado cubre los puntos principales, pero en un proyecto real necesitaría validación legal.

Dicho esto, para una prueba de concepto, tener GDPR-awareness desde el principio es un ejercicio valioso. Te obliga a pensar en privacidad y derechos del usuario desde diseño, no como afterthought.

Día 8: pulido final, accesibilidad y metadatos (22 enero)

El último día ya fue para pulir detalles:

• Accesibilidad: ARIA labels, navegación por teclado, contraste AA, HTML semántico
• Metadatos: favicon, og:image para compartir en redes, apple-touch-icon
• Contenido: página About explicando el proyecto y enlazando a mi perfil profesional (pero básicamente porque esto es algo que he elegido)

Para asegurar el tema de los metadatos vinculado con unos escenarios concretos, pedí que generara las imágenes porque tampoco quería utilizar más tiempo en esto:

Generate favicon.png, og-image.png, and 
apple-touch-icon.png using:
- Grayscale design with classic blue accent
- Clean, minimal aesthetic
- "Linkwise" text or "L" monogram

Mocha generó las tres imágenes. No son diseño profesional, pero son apropiadas y funcionales. Para una prueba de concepto como esta son mucho más que razonables.

Aprendizaje UX: la capacidad de generar assets visuales básicos (iconos, imágenes sociales) dentro del mismo flujo de desarrollo acelera mucho el proceso. No son diseños award-winning ni de coña, pero cumplen su función.

Para producción, ninguna duda que haría falta el trabajo de diseño gráfico profesional. Pero para validar concepto rápidamente, ha sido suficiente para mi en este caso.

Aprendizajes consolidados para UX en un contexto de IA generativa

Después de esta experiencia, estos son los aprendizajes que me traigo aquí desde una perspectiva de experiencia de usuario:

1. El juicio profesional no se delega

La herramienta ejecuta lo que dices, pero no decide por ti qué construir o cómo debe comportarse. Ni lo contrario. Toda decisión de diseño, priorización de features, consideración de edge cases… sigue requiriendo criterio profesional.

Ejemplo concreto: la IA no me dijo oye, deberías añadir paginación porque si un usuario tiene 500 bookmarks va a ser inusable. Yo tuve que identificar ese problema y pedirle la solución.

2. La especificidad en prompts es equivalente a especificidad en wireframes

En diseño tradicional, un wireframe vago lleva a implementaciones que no son lo que esperabas. Con IA, un prompt vago lleva exactamente al mismo problema.

Los mejores resultados vinieron de prompts que especificaban:

• Medidas concretas (22px, padding de 12-16px)
• Referencias visuales precisas (estilo 37Signals, no decir sólo minimalista)
• Comportamientos exactos (click en tag = añadir a filtro activo)

3. El feedback rápido permite una iteración de diseño rápida

Lo que más me sorprendió fue poder iterar sobre estética visual en minutos. Ver un cambio, ajustar, ver otro cambio… El ciclo de feedback es tan rápido que puedes explorar opciones de diseño que en flujo tradicional no intentarías ni de coña porque no vale la pena el esfuerzo de desarrollo.

Esto es potente, pero también es peligroso ya que podemos caer en ese escenario (que tanto odio cuando lo hacen los demás y yo soy quien gestiona el proyecto o la iniciativa) de micro-optimización sin fin. Hay que mantener disciplina de esto es suficientemente bueno para el objetivo actual.

4. Los detalles de UX requieren cariño

Los estados de carga, los mensajes de error, la validación de formularios, el manejo de fallos de red… Nada de esto aparece automágicamente (nótese mi creatividad literaria a estas alturas del post). Hay que pedirlo de manera especifica.

Mi checklist mental pasó a ser:

• ¿Qué pasa si la URL no carga?
• ¿Qué ve el usuario mientras espera?
• ¿Cómo se comunica éxito/error?
• ¿Funciona en móvil?
• ¿Es navegable por teclado?

5. La accesibilidad no viene gratis (pero se puede integrar)

Aunque especifiqué WCAG AA compliant desde el principio, muchos detalles de accesibilidad requirieron prompts específicos o ajustes manuales. ARIA labels, contraste de colores, navegación por teclado… son elementos que hay que revisar.

Dicho esto, cuando le pides explícitamente accesibilidad, la IA genera código bastante decente con HTML semántico, labels apropiados, y atributos ARIA correctos.

6. El debugging sigue siendo debugging

Cuando algo no funciona, necesitas habilidades tradicionales de debugging: revisar logs, entender errores, identificar dónde está el problema. La IA puede ayudar a generar la solución, pero primero tienes que diagnosticar. También es verdad que las herramientas actuales ayudan bastante, con un poquito de motivación, a ponerse con ello, aunque no se tenga experiencia previa.

En mi caso, los problemas de configuración de API keys, el bookmarklet roto por restricciones de React, y varios edge cases requirieron debugging manual. Pero lo he dicho, la motivación de ir desbloqueando logros, siempre ha sido uno de los elementos que más me ha ayudado a aprender. En 2026, pero también en 2004.

Recomendaciones para profesionales UX usando IA generativa

Basándome en esta experiencia, estas son mis recomendaciones para colegas que estén explorando estas herramientas, una vez más:

Para Diseñadores UX

1. Trata los prompts como entregables de diseño

Un buen prompt es como un buen wireframe más una buena especificación. Estructura tu prompt con:

• Contexto y objetivos
• Referencias visuales específicas (no genéricas)
• Comportamientos esperados con ejemplos
• Casos edge y estados de error
• Lo que explícitamente NO quieres

2. Mantén un archivo de design tokens en tus prompts

Para consistencia visual, define desde el principio:

• Paleta de colores (con hex codes exactos)
• Escala tipográfica (tamaños, pesos, line-heights)
• Sistema de espaciado (8px, 16px, 24px…)
• Breakpoints responsive

Reutilizar este «design system prompt» en todas las features nuevas ayuda a mejorar la consistencia.

3. Valida accesibilidad manualmente

Aunque pidas WCAG AA compliance, revisa:

• Contraste real con herramientas como WebAIM
• Navegación por teclado (prueba sin mouse)
• Screen reader (al menos VoiceOver en Mac o NVDA en Windows)

No asumas que cumple AA sin verificar. Eso no sucedía antes de la IA y ahora tampoco.

4. Usa la velocidad de iteración de manera estratégica

Este es un temazo, porque buena parte de la vibra que nos devuelve el proceso de trabajar con este tipo de herramientas, se puede reconducir de una manera inteligente y muy productiva. El poder de iterar rápido puede llevarnos a perfectionism infinito. Ya os adelanto que eso es un error. Establecer criterios claros de good enough para cada etapa va a ser siempre la mejor estrategia. Os lo aseguro, después de haber gastado un buen puñado de tokens de manera inservible en el pasado (ojalá ese gasto sirva para que alguien aprenda lo que no hacer):

• Prototipo funcional: funciona, no importa si es feo
• MVP: funciona bien, estética básica correcta
• V1: pulido, accesible, profesional

No te quedes atascado puliendo detalles cuando aún no has validado el concepto. De verdad.

Para Product Managers y Product Designers

1. La velocidad no reemplaza el pensamiento estratégico

Poder construir algo en horas no significa que debamos hacerlo. Las preguntas fundamentales siguen siendo las mismas:

• ¿Resuelve un problema real?
• ¿Para quién?
• ¿Cuál es el valor diferencial?
• ¿Es sostenible mantenerlo?

La IA acelera la ejecución, pero en ningún caso no sustituye estrategia. Pensar que eso es así es un error.

2. Usa prototipos funcionales para validación temprana

Antes, un prototipo interactivo requería herramientas especializadas (Figma, Principle…) y tiempo, bastante tiempo. Ahora podemos tener un prototipo que funciona de una manera más que razonable (con base de datos, auth, etc.) en tiempo similar o menor.

Esto cambia la conversación con stakeholders y clientes: ya no es imagina que esto funciona así, es aquí está funcionando, pruébalo y me dices qué te parece. El cambio no es menor.

3. Documenta las limitaciones

Cuando presentes un prototipo construido con IA, sé explícito sobre:

• Qué ha sido generado vs. diseñado intencionalmente
• Qué funciona vs. qué parece que funciona
• Qué es code de producción vs. prueba de concepto
• Qué requeriría reescribirse para escalar

Evitar crear expectativas incorrectas es ya un indicador de liderazgo en diseño y de madurez.

4. Planifica para throw away code

Estos prototipos son excelentes para validar conceptos, pero el código generado probablemente no es lo que nadie medianamente profesional pondría en producción. Vamos a pensar en ellos como wireframes funcionales, no como base de código final. Si la prueba de concepto funciona, tiempo de hacer estimaciones para que un equipo de coders se ponga a ello.

Para equipos completos

1. Establece un proceso de revisión

Aunque una persona puede construir el prototipo (este que os cuento es uno de esos casos), sigue necesitando:

• Revisión de UX (¿cumple principios básicos?)
• Revisión de accesibilidad (¿es usable para todos?)
• Revisión de seguridad (¿hay vulnerabilidades obvias?)
• Revisión legal (¿cumple regulaciones?)

La velocidad de construcción no elimina la necesidad de checks and balances. Por favor, estop tenemos que grabarlo a fuego.

2. Crea una biblioteca de prompts reutilizables

Como equipo, construid una colección de prompts que funcionan bien para:

• Formularios accesibles
• Layouts responsive
• Patrones de navegación
• Manejo de errores
• Features comunes (búsqueda, filtros, paginación…)

Esto va a acelerar futuros prototipos y va a garantizar más consistencia. De todos modos la forma de organizar estas indicaciones va a tener un punto de personalización importante. Yo sólo propongo un marco general.

3. Diferencia «prototype thinking» de «product thinking«

Un prototipo hecho con herramientas IA generativa es perfecto para:

• Validar conceptos de manera rápida
• Explorar posibilidades de interacción
• Comunicar visiones
• Testear con usuarios reales para tomar decisiones de diseño mejor informadas

El rol del profesional evoluciona, no desaparece

Construir Linkwise me ha llevado aproximadamente entre 8 y 10 horas distribuidas en una semana. En un proceso tradicional, sólo las reuniones de kick-off, diseño, y setup inicial habrían consumido ese tiempo. Pero eso no significa que el trabajo profesional desaparezca. Significa que se transforma:

• De ejecutor a director: menos tiempo escribiendo código/píxels, más tiempo decidiendo QUÉ construir y CÓMO debe comportarse
• De especialista técnico a orquestador: la habilidad crítica pasa a ser comunicar la intención (una forma de outcome) de manera clara y validar los resultados
• De construcción a criterio: el valor no está en ensamblar componentes, sino en saber QUÉ ensamblar y POR QUÉ

Linkwise es una prueba de concepto. No tiene el pulido de un producto diseñado por un equipo profesional, ni de lejos. Tampoco tiene la robustez técnica de código revisado por ingenieros senior (lo he montado yo, que no tengo ese perfil). No tiene la profundidad de UX research que informaría decisiones en un proyecto real. De hecho no ha habido research.

Pero como herramienta para validar una idea, explorar posibilidades, y aprender sobre estas nuevas formas de trabajar… es exactamente lo que necesitaba.

Y eso, me parece, es el punto clave: estas herramientas no reemplazan el trabajo profesional, pero sí permiten que los profesionales exploremos más rápido, validemos más temprano, y enfoquemos nuestro expertise donde más valor aporta.

El futuro no es IA hace diseño UX. Ni de lejos, al menos hoy. El futuro es profesionales UX usan IA como herramienta para diseñar mejor, más rápido, y con más foco en lo que realmente importa: resolver problemas reales para personas reales.

Nota: Linkwise está disponible en linkwise.torresburriel.com como prueba de concepto abierta. Si quieres probar, guardar tus propios enlaces, o simplemente curiosear, eres bienvenido. Sólo recuerda: esto es un experimento, no un producto en producción.

Y si te interesa el tema, en Torresburriel Estudio estamos explorando cómo estas herramientas cambian nuestros procesos de diseño y consultoría UX. Siempre abierto a conversar sobre esto: linkwise@torresburriel.com