Portfolio UX con vibe coding usando OpenCode y Astro

diseña un portfolio ux con vibe coding

Este post te va a gustar porque me consta que las palabras vibe coding y portfolio UX son de tu interés. Las habíamos pasado por varias herramientas de generación de código y los resultados siempre quedaban a medias.

Esta vez lo hicimos con usando OpenCode con dos modelos distintos: Kimi K2.7 Code en la primera sesión y GLM 5.2 en la segunda.

El resultado fue una versión 1 funcional, responsive y con buena base SEO.

Te cuento cómo fue el proceso…

Por qué Astro para un portfolio UX

Astro es un framework pensado para sitios orientados a contenido. Páginas rápidas, estructura limpia y soporte nativo para archivos markdown.

Para un portfolio UX tiene mucho sentido: el diseñador puede editar su contenido, sus proyectos, sus textos legales, su página de Acerca de, todo desde archivos de texto… no necesita tocar código.

Además Astro no obliga a instalar demasiadas cosas. Un proyecto limpio, sin dependencias innecesarias, que cualquiera puede descargar, personalizar y publicar.

El prompt de partida para el vibe coding

Antes de lanzar nada a OpenCode, analicé el template con Claude Code (usando el modelo Opus). Le pedí que lo leyera de cabo a rabo y me devolviera un análisis detallado de la home y del detalle de proyecto.

Con ese análisis redacté el prompt inicial… un prompt largo, con todo lo que necesitaba:

  • Home y detalle de proyecto
  • Páginas de Acerca de, Servicios y notas legales editables con markdown
  • Proyectos organizados por categorías con proyectos relacionados al final de cada detalle
  • Dark mode por defecto con toggle para cambiar a light
  • Escala de color neutral de Tailwind, sin instalar Tailwind en el proyecto
  • Librería de iconos integrada
  • Contenido placeholder funcional para 7 proyectos en 3 categorías
  • Responsive en todos los breakpoints con un max-width de 1536 px

También le pedí que, si tenía sugerencias para mejorar lo que le pedía, las hiciera. Lo hizo, me ofreció 4 sugerencias razonables, las acepté todas.

Kimi K2.7 Code: primera sesión de vibe coding con OpenCode

El modelo trabajó durante unos minutos y dejó el proyecto en muy buen punto. Home, detalle de proyecto, navegación entre páginas, breadcrumb, scroll en tabs, dark y light mode. Todo funcionando.

Al pulsar «Cargar y reproducir vídeo», aceptas conectar con YouTube para mostrar este contenido. Recibirá tu IP y puede usar cookies y almacenamiento local según sus políticas. Más información. Puedes seguir leyendo sin cargarlo.

Ver en YouTube (se abre en otra pestaña)

No fue perfecto, había pequeñas cosas por ajustar. Pero la base era sólida, mucho mejor que lo que habíamos conseguido antes con otras herramientas de vibe coding.

GLM 5.2: segunda sesión, iteraciones y SEO

En la segunda sesión cambiamos de modelo. Antes de empezar le pedí a GLM que analizara el estado del proyecto y le volqué unas reglas de SEO para que las implementara, las reglas SEO las tenía redactadas para otro proyecto, si las quieres escríbeme y te las paso.

Al pulsar «Cargar y reproducir vídeo», aceptas conectar con YouTube para mostrar este contenido. Recibirá tu IP y puede usar cookies y almacenamiento local según sus políticas. Más información. Puedes seguir leyendo sin cargarlo.

Ver en YouTube (se abre en otra pestaña)

A partir de ahí fuimos resolviendo puntos concretos:

  • Aspect ratio 4/3 en las imágenes
  • Semántica HTML correcta en el Hero con una etiqueta
  • Reubicación del toggle de dark/light mode
  • Eliminación de un pretitle que el modelo anterior se había inventado
  • Sustitución de la librería de iconos por Phosphor Icons

También le pedimos que mantuviera una lista de tareas actualizada durante toda la sesión.

Funcionó bien.

Al terminar cada bloque de trabajo le pedíamos que marcara las tareas completadas y nos propusiera las siguientes.

Qué aprendimos en estas dos sesiones de vibe coding

El análisis previo importa…

Dedicar tiempo a analizar el diseño con Claude Code antes de lanzar el primer prompt a OpenCode marcó la diferencia. La IA tuvo contexto real desde el principio.

Los modelos hacen sugerencias útiles, si les das espacio para ello, te ahorran decisiones que de otro modo tendrías que tomar tú.

Cambiar de modelo entre sesiones tiene sentido. Kimi K2.7 Code fue muy eficiente para construir la base y GLM 5.2 fue preciso para iterar y ajustar detalles.

La lista de tareas como contexto persistente funciona, le da al modelo orientación entre prompts y ayuda a no perder el hilo en sesiones largas.

Lo que viene

El portfolio tiene cosas por iterar todavía, sobre todo en los componentes de navegación y en los estados de los botones. En los próximos vídeos del canal seguiremos trabajando en ello.

Si quieres ver las dos sesiones completas, las tienes aquí arriba.

Acerca de Juanpol

Product Designer en Magnific. Combino diseño, código e IA para crear mejores experiencias y agentes que transforman la forma en que diseñamos y construimos.

¿Te lo mando por correo?

Las siguientes notas de trabajo, en tu bandeja. Una o dos veces al mes.

Ver la newsletter