Cómo construí este blog con agentes de programación

Hace tiempo tuve un blog. Tráfico decente, tema claro, experiencia personal de verdad: escribía sobre frontend y sobre las cosas que yo mismo iba resolviendo. Después, por razones no demasiado importantes, dejé de mantenerlo y, de paso, perdí el dominio.

Durante mucho tiempo me pareció que esa historia simplemente había terminado. Pero hoy volvió a apetecerme escribir, ya no sobre frontend como profesión, sino sobre cómo hago proyectos reales con agentes de programación. Sin abstracciones sobre el futuro del desarrollo: procesos concretos, errores y decisiones.

Así apareció techmeat.dev.

Por qué empecé esto

La idea fue espontánea. Tenía tokens sin usar acumulándose, varias hipótesis que quería comprobar, y decidí montar un proyecto pequeño pero real: un blog en el que el propio proceso de construirlo se convierte en el primer material.

Mi workflow habitual con agentes está mucho más elaborado: varias etapas de planificación, revisión y puntos de control. Aquí lo simplifiqué a propósito. Quería ver hasta dónde se puede llegar si fijas la dirección rápido, preparas el contexto y le das al agente la mayor parte del trabajo inicial.

No es un proceso de referencia, sino una versión experimental. Sobre el enfoque más estricto seguramente escribiré aparte.

Preparación: skills, contexto y reglas del proyecto

Lo primero fue instalar las skills necesarias. Para un proyecto así importa más de lo que parece: «hazme un blog» es un planteamiento demasiado débil. El agente necesita reglas claras: qué tecnologías usar, dónde guardar el contenido, cómo pensar el SEO, cómo abordar el diseño, qué no hacer sin necesidad. El conjunto inicial está fijado en el archivo de trabajo INIT.md.

Después inicialicé CLAUDE.md, el archivo con el contexto base del proyecto. El borrador estaba en ruso, pero para el contexto de trabajo lo traduje al inglés enseguida, para que sirviera por igual en todas las locales y en distintas herramientas.

This project is empty for now, but I am going to build my blog here. The project will be based on Astro, and posts will be stored as Markdown files. Each article will go through a multi-stage SEO and GEO preparation workflow using the skills available in the project and the geo-optimizer-skill CLI: https://github.com/Auriti-Labs/geo-optimizer-skill, which is already installed.

The blog will be about building projects with AI coding.

The domain has already been chosen and purchased: techmeat.dev.

The project will be hosted on Cloudflare Pages.

The primary language of the blog will be English, but there will also be translations into other languages, at least 10 popular ones. Translation pages must point to the English version of the same article with canonical links.

The project design must be created using the impeccable skill.

All project documentation must be written in English. Draft documentation may be an exception.

Luego copié CLAUDE.md en AGENTS.md. No quiero atar el proyecto a un agente concreto: si mañana sigo el desarrollo en otra herramienta, las reglas base se quedan al lado del código.

Primer arranque: solo cimientos

No le pedí al agente que empezara con páginas o diseño. Al inicio necesitaba unos cimientos técnicos correctos: un proyecto Astro listo para Cloudflare Pages, con una estructura limpia y sin iniciativa de más.

El prompt fue deliberadamente estrecho:

Let's start developing our blog project. First, use the Astro skills and set up the initial project, preparing it for hosting on Cloudflare Pages. There is no need to build pages or do any additional work right now. Only set up the project.

Cuanto más estrecha es la primera petición, menos opciones hay de que el agente empiece a «mejorar» el proyecto donde aún no se ha tomado ninguna decisión. Eso ahorra muchos nervios: necesitaba un punto de partida fiable, no una maqueta bonita.

Brainstorming en lugar de diseño prematuro

Después activé Superpowers y empecé un brainstorming, pidiéndole expresamente que no hablara de diseño. En esta fase había que decidir de qué se compone el blog como producto, no qué aspecto tiene.

El prompt fue el siguiente:

Let's brainstorm in Russian about what my blog should consist of. Here's how I currently see it:

- All pages should share a unified design, but we are not discussing the design itself yet, only common blocks and similar structural elements. The header should include the techmeat.dev name and a language switcher. To clarify, the brainstorming result should describe what the blog should have, not how it should look.
- The home page should show previews of the 10 latest posts with links to the full posts. Maybe it should include something else too; suggest options.
- There should be an About page: something like a CV, but in a more blog-like form.
- There should be a Contacts page with links to my social profiles and GitHub.
- Maybe some other pages are needed; suggest options.
- This should be a very simple blog, mostly informational. I expect to publish materials often.

El brainstorming duró cerca de una hora. Para un proyecto tan pequeño suena a mucho, pero el tiempo se amortizó: sin él no habría salido un plan coherente ni una especificación de arquitectura. El agente ayudó a desglosar el blog en páginas, bloques comunes, modelo de idiomas y estructura de contenido.

Como resultado aparecieron dos artefactos internos: el plan de la primera versión y la especificación de arquitectura.

Desarrollo autónomo, revisión y arreglos

Tras el brainstorming, solo me quedaba aceptar la dirección y dejar trabajar al agente. La mayor parte de la estructura base apareció de forma autónoma: rutas, contenido en Markdown, locales, componentes, RSS, tags e infraestructura para traducciones.

No fue del todo sin intervención manual. Añadí algunos prompts correctores: precisé el conjunto de idiomas, le pedí que arreglara pequeños bugs y afinara detalles que el agente se saltó en la primera pasada.

Después le pedí a GPT-5.5 que hiciera revisión del código y aplicara los arreglos al momento. Apenas me metí en el proceso: el agente encontró varias mejoras útiles, las aplicó y pasó las verificaciones. Sinceramente, casi toda esta versión la vibe-codeé, algo que normalmente intento evitar. Aquí era admisible: el proyecto es pequeño, el coste del error es bajo, y la idea precisamente era probar los límites de este enfoque.

Aquí se ve bien cómo entiendo el AI coding en general. El agente no es un botón mágico de «hazme un producto», sino un ejecutor muy rápido que necesita marcos, contexto y revisión periódica. Con buenos marcos quita un volumen enorme de trabajo bruto. Con marcos difusos genera incertidumbre con la misma rapidez.

Por qué pospuse el diseño

A propósito dejé el diseño fuera de la primera fase. Para la parte visual tengo un proceso aparte y quería pasarlo por su cuenta, sin mezclar arquitectura, contenido e interfaz en una sola tarea.

Por eso la primera versión del blog parece un esqueleto técnico: rutas, localización, posts, tags e infraestructura de publicación ya están, y el sistema visual no, y eso está bien. A veces es más útil tener primero un proyecto que funciona y luego pensar con calma cómo se ve y se siente.

Qué quiero comprobar con este blog

techmeat.dev es un laboratorio de trabajo, no un simple almacén de notas. Me interesa cómo cambia el desarrollo cuando tienes al lado, todo el rato, un agente de programación: dónde acelera el trabajo, dónde crea riesgos ocultos y dónde te ayuda a ver una solución a la que solo habrías llegado mucho más tarde por tu cuenta.

Tres cosas en concreto me llaman la atención.

Proceso. No «el agente escribió el código», sino lo que hubo antes y después: qué prompts funcionaron, qué restricciones tuve que poner, qué decisiones es mejor dejarle al humano.

Calidad. El AI-assisted development se convierte fácilmente en un torrente de parches si no mantienes plan y revisión. Quiero mostrar tanto los resultados que salieron bien como los puntos en los que el agente se equivocó o donde mi planteamiento no fue lo bastante preciso.

Reproducibilidad. Si el enfoque no se puede repetir en el siguiente proyecto, no es un proceso, es un truco puntual. Por eso voy a registrar no solo el código final, sino también los esquemas de trabajo: cómo se planteó la tarea, qué archivos aparecieron, qué herramientas participaron, cómo se tomaron las decisiones.

Qué sigue

La siguiente etapa es el diseño. La continuación de este post irá precisamente sobre eso: cómo lo hice, qué decisiones tomé, qué salió al final. Aunque cómo va a quedar exactamente, yo todavía no lo sé.

Mientras tanto, para la historia, dejemos guardado cómo se ve el blog hoy:

Diseño con Impeccable

Si viste el clip de arriba, ya viste cómo se veía el blog antes y cómo terminó viéndose después.

Decidí dejar el diseño en una fase aparte de forma deliberada: no quería mezclarlo con la arquitectura y el contenido en una sola tarea. Compañeros me recomendaron el sistema de skills Impeccable — ayuda al agente a construir un visual más cuidado, en lugar de la estética por defecto de la IA.

Salió simple y a la vez no tan simple. Simple — porque todo cupo en un prompt y un par de rondas de preguntas de Claude Code. No tan simple — porque el prompt había que escribirlo con cuidado, y las preguntas de Claude Code no eran precisamente fáciles.

Prompt inicial:

The blog is already running on the base setup with starter content, but it was deliberately built without design — I wanted to handle that as a separate phase.

You have the impeccable skill, but I'm not great at using it yet. Let's learn it together from the docs at https://impeccable.style/docs/impeccable.

What I want for the blog: a simple, elegant design with minimal decorative imagery (ideally none at all). Content first, but the site should feel pleasant — design must not get in the way of consuming content. At the same time the visual character should reflect my own attitude toward design.

I have no references; let's build it from scratch.
The blog already has a light/dark theme toggle — we can keep it or drop it.
We have many locales, including Asian scripts and Arabic, so RTL matters.
Mobile-first is also important.
You'll find more details in /docs.
You can ask me questions, but don't drown me in them — only the essentials.

Claude Code refrescó el diseño bastante rápido. Tras un par de prompts de ajuste el resultado me convenció.

Pósters con Pencil

Siguiente — pósters, para que los enlaces al blog se vean bien al compartirlos en redes sociales. Conecté Pencil (su MCP es excelente) y le pedí a Claude Code construir un sistema de pósters y exportarlo al proyecto. No fue sin pequeños retoques manuales, pero en conjunto — rápido y limpio.

Prompt para esta parte:

I'm adding a `design/` folder to the project for design artifacts. Let's start with post posters.

Posters will live in Pencil — you have the MCP for that.

Build a poster system for every page of the blog; the layouts should be templated. Post posters should be kept separate so adding a new poster per post is easy.

Posters need two sizes — landscape and portrait — to cover both social-network variants.

Make a poster for the first post, fully on-spec and at the correct dimensions. The first poster will become the template, with small per-post variations.

Export every poster, place them correctly inside the project, and wire each one up to the matching page.

The home-page poster should also serve as the default poster for any page that doesn't have its own yet.

Comentarios, Lighthouse y hosting

No conecté un sistema de comentarios — por ahora no veo la necesidad. Si quieres comentar un post, hay un enlace al PR debajo; puedes dejar comentarios ahí mismo.

Al final le pedí al agente que pasara Lighthouse al sitio y ajustara las métricas. Las cifras terminaron en 100%.

Para el hosting quise desde el principio la opción más barata en dinero y tiempo — Cloudflare Pages. Cero dólares por todo, más analítica integrada. El dominio, por cierto, también lo compré en Cloudflare — resultó más barato que en los registradores habituales.

Qué viene después

Aquí cierra el primer ciclo: el blog funciona, está traducido, tiene diseño, pósters OG y métricas que no dan vergüenza. El siguiente paso es automatizar la escritura de posts. Tengo una idea de cómo hacerlo a la manera “moderna” — escribiré sobre ello en un post aparte.