Blog + IA: El cóctel perfecto
Tengo un blog estático hecho con Hugo, desplegado en Cloudflare Pages, y cada post lo genero con IA. Pero no es un copy-paste — es un flujo de trabajo donde la IA me ahorra empezar desde una página en blanco, pero yo decido qué, cuándo y cómo se publica.
Este post explica cómo funciona todo el pipeline. Desde que le pido a un LLM que escriba un borrador hasta que la página aparece en aletz.net.
El flujo en un vistazo
IA (borrador) → Revisión humana → Draft en Hugo → Git push → CI/CD → Cloudflare → LIVE
Cinco pasos. Dos automatizados, tres manuales. Así me gusta.
1. El borrador con IA
Le digo a Claude Code, a Haiku o a qwen3.6 local:
“Genera un post de blog sobre X, con este tono, estas secciones, estilo similar a mis posts anteriores”
El modelo escribe un markdown con front matter YAML y lo guardo en ai-posts/. Este directorio es solo un almacén temporal — Hugo no lo procesa, así que nada se publica accidentalmente.
aletz.net/
├── ai-posts/ ← borradores IA (hugo no los toca)
│ ├── alert-fatigue.md
│ ├── finops-para-sres.md
│ └── ...
└── website/ ← el sitio real (lo que se publica)
├── content/posts/2026/
└── ...
La clave: los borradores nunca se publican solos. Hay un paso humano entre la IA y la publicación.
2. Revisión y ajuste
Aquí es donde el humano toma las riendas. Leo el borrador, lo corregido, añado mi experiencia, cambio secciones, ajusto el tono. Este proceso es iterativo: la IA genera, yo reviso, pido ajustes, repito 3-5 veces hasta que el post me convence.
Esto no es “la IA escribe y publiqué”. Es “la IA me da una base sólida, y yo la pulo hasta que está bien.”
3. Convertir a draft público
Cuando el post está listo, lo muevo a website/content/posts/2026/ y ajusto el front matter:
---
title: "Mi post sobre X"
date: 2026-06-29
draft: false # ← este es mi interruptor de publicación
tags: ["ai", "hugo", "cloudflare"]
---
draft: true = Hugo no lo incluye en la build. draft: false = sí. Es mi interruptor manual de “publicar o no”. La fecha también la pongo yo, no la IA.
4. Preview local
Antes de subir nada, compilo el sitio localmente:
make server
# → localhost:1313 con auto-reload
Abro el navegador y reviso que todo se vea bien. Hugo reload automáticamente cuando toco un fichero, así que puedo ajustar en caliente sin reiniciar nada.
Si algo va mal, lo corrijo. Si está bien, commit y push.
5. CI/CD: push → build → deploy
Ahora empieza la parte automática. Hago un git push y Gitea detecta el cambio, dispara el workflow y…
git push
→ Gitea Actions (ubuntu runner)
→ clona el repo
→ construye con Hugo (en imagen Docker custom)
→ deploy con wrangler a Cloudflare Pages
→ https://aletz.net/ (CDN global, HTTPS automático)
Un workflow en unos 2-3 minutos: clonar, construir con Hugo, deploy con wrangler pages deploy a Cloudflare. Sin servidores propios, sin nginx, sin gestionar SSL. Cloudflare hace todo: CDN, HTTPS, DNS, deploy.
El workflow usa una imagen Docker custom que tengo en registry privado con Hugo extended empaquetado. No depende de que el runner tenga nada instalado — lo trae todo la imagen. Los secretos se inyectan como variables de entorno.
¿Por qué este flujo?
Porque me gusta el control. La IA genera el borrador, pero yo decido qué se publica, cuándo, y cómo. El pipeline automatiza lo mecánico (build, deploy, CDN) pero no toca lo creativo (contenido, tono, decisiones).
El stack es limpio:
- Hugo → markdown → HTML estático. Sin Node, sin JS build, sin dependencias runtime.
- Cloudflare Pages → CDN global, HTTPS automático, deploy desde Git.
- Gitea Actions → CI/CD self-hosted con imagen Docker custom, control total.
- Tema nostyleplease → minimalista, sin JavaScript, solo texto.
Markdown → HTML → CDN. Simple.
Conclusión
IA para generar borradores, Hugo para construir, Cloudflare para servir, y yo en medio decidiendo qué merece la pena publicar. El pipeline automatiza lo mecánico — el contenido es mío. No es perfecto, pero es mío y funciona.