Cómo construí mi portafolio con inteligencia artificial

Este portafolio nació de dos necesidades. La primera era migrar una landing construida en Angular hacia una arquitectura que permitiera publicar proyectos y artículos a partir de archivos Markdown. La segunda era poner en práctica las herramientas de inteligencia artificial que había explorado durante los últimos meses y entender cómo podían ayudarme dentro de un proceso real de desarrollo asistido por IA. Quería comprobar hasta qué punto podían aportar en el diseño, la implementación y la automatización de un producto completo.

Aunque no fue un proyecto para una empresa ni para un equipo en el que trabajara, sí fue un proyecto personal con un objetivo técnico real: diseñar, desarrollar y desplegar una nueva versión de jhonny.dev. También fue mi primer proyecto construido completamente con apoyo de IA, desde la exploración visual hasta la implementación y la automatización de su infraestructura.

El uso de estas herramientas me permitió completar la migración y la implementación en 15 días, con una dedicación de entre una y tres horas diarias. Más que reemplazar el trabajo de desarrollo, la IA redujo el tiempo invertido en explorar alternativas, traducir los diseños a componentes y resolver tareas repetitivas durante la construcción.

El reto no era pedirle a una IA que generara un sitio completo, sino crear el contexto y las restricciones necesarias para que distintas herramientas colaboraran sobre una misma visión sin perder consistencia.

De Angular a Astro

La versión anterior estaba construida como una landing en Angular. Esa base cumplía su propósito inicial, pero no facilitaba la creación de páginas dinámicas a partir de contenido escrito en Markdown.

Elegí Astro 6 para convertir el sitio en una plataforma de contenido. Con sus colecciones pude separar los datos editoriales de la interfaz y crear páginas para proyectos y artículos sin tener que modificar componentes cada vez que quisiera publicar algo nuevo.

Este cambio también simplificó la entrega del sitio como archivos estáticos, una característica que encajaba con el despliegue en Amazon S3 y su distribución mediante CloudFront.

Diseño de interfaces con Google Stitch

La etapa visual comenzó con la versión beta de Google Stitch, una herramienta de Google Labs para diseñar interfaces mediante lenguaje natural.

Partí de una paleta de colores definida y describí los módulos principales que necesitaba:

• La landing de presentación.
• El listado y detalle de proyectos.
• El listado y detalle de artículos.

Stitch generó propuestas para las versiones móvil y de escritorio. A partir de esas decisiones también obtuve un archivo DESIGN.md, que convirtió la dirección visual en documentación legible por otras herramientas de IA. El documento describía colores, tipografía, superficies, jerarquías y reglas para los componentes, por lo que el diseño dejó de depender únicamente de referencias visuales.

Los diseños se exportaron a Figma, donde fue posible revisar las pantallas y sus secciones de manera organizada. Figma se convirtió así en la referencia visual del proyecto y DESIGN.md en su referencia escrita.

Un contexto controlado para Codex

Utilicé Codex de OpenAI, con modelos GPT-5.4 y GPT-5.5, para acelerar la construcción del sitio. Sin embargo, antes de implementar componentes era necesario definir cómo debía trabajar la herramienta.

Con el comando /init generé la guía del repositorio en AGENTS.md y la adapté con las reglas del proyecto:

• Desarrollo mobile-first.
• Nomenclatura CSS basada en BEM.
• HTML semántico.
• Breakpoints con la sintaxis moderna @media (width >= 600px).
• Variables globales y tokens semánticos derivados de DESIGN.md.
• Convenciones para la estructura de Astro, nombres de archivos y validación de cambios.

Estas reglas transformaron decisiones que podían interpretarse de distintas maneras en instrucciones explícitas y reutilizables. Codex no recibía solamente una tarea aislada: también disponía del contexto técnico y visual necesario para resolverla dentro de los límites del proyecto.

Figma conectado al desarrollo mediante MCP

También conecté Codex al MCP de Figma. Esta integración permitió que la herramienta consultara directamente las pantallas diseñadas y utilizara esa información al construir componentes y páginas.

El flujo combinó tres fuentes de contexto:

AGENTS.md
  └─ Convenciones y metodología de desarrollo

DESIGN.md
  └─ Sistema de diseño y dirección visual

Figma MCP
  └─ Pantallas y composición de la interfaz

Esta combinación redujo la ambigüedad durante la implementación. Al tener reglas de ingeniería, tokens visuales y diseños de referencia, el modelo podía trabajar de forma más controlada, mantener patrones consistentes y evitar reprocesos que también habrían aumentado el consumo de tokens.

Una Skill para mensajes de commit

Como parte del experimento, creé una Skill para Codex CLI enfocada en una tarea concreta del flujo de Git.

La Skill lee únicamente los cambios que se encuentran en el área de stage y, a partir de ellos, genera un mensaje de commit semántico siguiendo Conventional Commits. Limitar su contexto a los archivos preparados para el commit evita que incluya cambios incompletos o información que no formará parte de esa versión.

Este ejercicio me permitió llevar la asistencia de IA más allá de la generación de código y convertir una convención repetitiva del equipo de desarrollo en un flujo reutilizable.

Despliegue continuo en AWS

El proyecto se publica mediante un workflow de GitHub Actions. Cada actualización de la rama principal instala las dependencias, genera la compilación de Astro y guarda el resultado como un artefacto antes de desplegarlo.

La versión compilada se almacena en Amazon S3 y se sirve desde un dominio propio administrado con Route 53 y CloudFront. El workflow aplica políticas de caché diferentes para HTML, archivos estáticos y recursos versionados de Astro; después crea una invalidación en CloudFront para hacer visible la nueva versión.

Cada despliegue también se conserva en un directorio versionado dentro de S3. Al finalizar, el pipeline genera un resumen con la versión, el commit, el autor y el tiempo de ejecución, y envía notificaciones detalladas mediante webhooks de Slack y Discord.

Push a main
  ↓
Build de Astro
  ↓
Versión almacenada en S3
  ↓
Publicación e invalidación de CloudFront
  ↓
Notificaciones en Slack y Discord

Rollback manual con versiones almacenadas

Además del despliegue automático, implementé un segundo workflow para ejecutar rollbacks manuales.

El flujo recibe el identificador de una versión, valida que exista en S3 y restaura sus archivos en producción. Después invalida nuevamente la caché de CloudFront y comunica el resultado en Slack y Discord.

Esta estrategia permite recuperar una versión funcional sin reconstruir el proyecto ni depender de que el último commit pueda desplegarse de nuevo. Las versiones guardadas en S3 funcionan como artefactos listos para restaurar.

Stack técnico

• Astro 6 y TypeScript.
• Markdown y colecciones de contenido de Astro.
• CSS, BEM, metodología mobile-first y tokens globales.
• Google Stitch y Figma.
• Codex y Figma MCP.
• GitHub Actions.
• Amazon S3, CloudFront y Route 53.
• Webhooks de Slack y Discord.

Resultado

El resultado fue una plataforma personal que permite publicar proyectos y artículos desde Markdown, mantiene un sistema de diseño documentado y cuenta con un proceso automatizado para desplegar o restaurar versiones en producción.

Más que una prueba de generación de código, el proyecto se convirtió en un ejercicio de orquestación de contexto. Cada herramienta tuvo una responsabilidad concreta: Stitch ayudó a explorar y documentar el diseño, Figma organizó la referencia visual, Codex apoyó la implementación y GitHub Actions automatizó la operación del sitio.

Qué aprendí

El principal aprendizaje fue que la calidad de un desarrollo asistido por IA depende en gran medida de la calidad de su contexto. Un archivo como AGENTS.md, un sistema de diseño documentado y una referencia visual accesible reducen las interpretaciones abiertas y producen resultados más consistentes.

También comprobé que la IA funciona mejor cuando el trabajo se divide en responsabilidades y restricciones verificables. Definir metodología, convenciones, breakpoints y tokens antes de construir hizo que las decisiones importantes no tuvieran que repetirse en cada solicitud.

La conexión con Figma me enseñó que los diseños no tienen que quedarse como una referencia separada del código. Al hacerlos accesibles mediante MCP, pude acercar diseño e implementación y disminuir la distancia entre lo planeado y lo construido.

Crear una Skill propia reforzó otra idea: las herramientas de IA pueden adaptarse a flujos pequeños y específicos, no solo a tareas grandes. Automatizar los mensajes de commit a partir del stage convirtió una práctica recurrente en un proceso más consistente y seguro.

Finalmente, la automatización del despliegue y el rollback confirmó que un proyecto no termina cuando la interfaz funciona. Versionar artefactos, controlar la caché, conservar una ruta de recuperación y comunicar cada cambio son partes necesarias de un producto que debe operar de forma confiable.