How I built this blog with coding agents

I used to have a blog. Decent traffic, a clear topic, real personal experience: I wrote about frontend and the things I worked through myself. Then for not-particularly-important reasons I stopped maintaining it, and lost the domain along the way.

For a long time it felt like that story had simply ended. But today I felt like writing again — not about frontend as a profession, but about how I build real projects with coding agents. No abstractions about the future of development, just concrete processes, mistakes, and decisions.

That’s how techmeat.dev came to be.

Why I started this at all

The idea was spontaneous. I had unused tokens piling up, a few hypotheses I wanted to test, and I decided to put together a small but real project: a blog where the process of building it becomes the first piece of content.

My usual workflow with agents is much more elaborate: several stages of planning, review, and checkpoints. Here I deliberately simplified it. I wanted to see how far you can get if you quickly set the direction, prepare the context, and hand the agent most of the starter work.

This isn’t a reference process; it’s an experimental version. I’ll probably write about the stricter approach separately.

Preparation: skills, context, and project rules

First I installed the skills I needed. For a project like this it matters more than it seems: “build a blog” is too weak a problem statement. The agent needs clear rules: which technologies to use, where to keep the content, how to think about SEO, how to handle design, what not to do without reason. The starter set is captured in the working file INIT.md.

After that I initialized CLAUDE.md — the file with the project’s base context. The draft itself was in Russian, but I translated it into English right away for the working context, so it would be equally useful across every locale and tool.

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.

Then I copied CLAUDE.md into AGENTS.md. I don’t want to tie the project to one specific agent: if tomorrow I continue development in a different tool, the base rules stay next to the code.

First boot: foundation only

I didn’t ask the agent to start with pages or design. At the start I needed a correct technical foundation: an Astro project ready for Cloudflare Pages, with a clean structure and no extra initiative.

The prompt was deliberately narrow:

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.

The narrower the first request, the smaller the chance the agent starts “improving” the project where no decision has been made yet. That saves a lot of nerves: I needed a reliable starting point, not a pretty mockup.

Brainstorming instead of premature design

Next I turned on Superpowers and started brainstorming, deliberately asking it not to discuss design. At this stage I needed to decide what the blog consists of as a product, not what it looks like.

The prompt was:

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.

Brainstorming took about an hour. For a project this small that sounds like a lot, but the time paid off: without it I wouldn’t have ended up with a coherent plan and architecture spec. The agent helped me break the blog down into pages, shared blocks, the language model, and the content structure.

The result was two internal artifacts: the plan for the first version, and the architecture spec.

Autonomous development, review, and fixes

After brainstorming, all I had to do was agree with the direction and let the agent work. Most of the base structure appeared autonomously: routes, Markdown content, locales, components, RSS, tags, infrastructure for translations.

It didn’t go entirely without manual intervention. I added a few correcting prompts: clarified the set of languages, asked the agent to fix small bugs and tighten details it missed on the first pass.

Then I asked GPT-5.5 to review the resulting code and apply fixes immediately. I barely got involved: the agent found a few useful improvements, applied them, and ran the checks. Honestly, I pretty much vibe-coded this version, which is something I usually try to avoid. Here it was acceptable: the project is small, the cost of error is low, and the whole point was to test the boundaries of this approach.

This is where you can see clearly how I think about AI coding in general. The agent isn’t a magical “make me a product” button; it’s a very fast executor that needs frames, context, and periodic review. With good frames it offloads a large amount of grunt work. With vague ones it produces uncertainty just as fast.

Why I deferred design

I deliberately kept design out of the first phase. I have a separate process for the visual side, and I wanted to go through it on its own, without mixing architecture, content, and interface into a single task.

That’s why the first version of the blog looks like a technical skeleton: routes, localization, posts, tags, and the publishing infrastructure are already in place, the visual system isn’t, and that’s fine. Sometimes it’s more useful to get a working project first and then calmly think about how it looks and feels.

What I want to test with this blog

techmeat.dev is a working lab, not just a notes warehouse. I’m interested in how development changes when there’s a coding agent next to you all the time: where it speeds up the work, where it creates hidden risks, and where it helps you see a solution you would have reached much later on your own.

Three things in particular hold my attention.

Process. Not “the agent wrote the code” but what came before and after: which prompts worked, which constraints I had to set, which decisions are better left to a human.

Quality. AI-assisted development easily turns into a stream of patches if you don’t keep a plan and reviews. I want to show both the successful results and the places where the agent got it wrong, or where my problem statement wasn’t precise enough.

Repeatability. If you can’t repeat the approach on the next project, it isn’t a process — it’s a one-time trick. So I’ll capture not just the final code but the working schemes too: how the task was framed, which files appeared, which tools were involved, how decisions were made.

What’s next

The next stage is design. The continuation of this post will be exactly about that: how I did it, what decisions I made, what came out of it. Although what it will actually look like, I don’t know myself yet.

For now, for the record, let’s preserve how the blog looks today:

Design via Impeccable

If you watched the clip above — you’ve already seen what the blog looked like before, and what it ended up looking like after.

I deliberately kept design as a separate phase so I wouldn’t be mixing it with architecture and content in a single task. Colleagues recommended the Impeccable skill system — it helps the agent build a more thoughtful visual instead of the default AI aesthetic.

The result was simple and not-simple at the same time. Simple — because the whole thing fit into one prompt and a couple of question rounds with Claude Code. Not-simple — because the prompt had to be written carefully, and Claude Code’s questions were not exactly easy ones.

Initial prompt:

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 refreshed the design pretty fast. After a couple of clarifying prompts I was happy with the result.

Posters via Pencil

Next — posters, so links to the blog look good when shared on social. I plugged in Pencil (their MCP is excellent) and asked Claude Code to build a poster system and export it into the project. Some manual touch-ups were needed, but overall — fast and clean.

Prompt for this part:

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.

Comments, Lighthouse, and hosting

I didn’t wire up a comments system — I don’t see the need yet. If you’d like to discuss a post, there’s a PR link below it; you can leave comments right there.

At the very end I asked the agent to run Lighthouse on the site and tighten the numbers. They eventually landed at 100%.

For hosting I wanted the cheapest possible option in both money and time from the start — Cloudflare Pages. Zero dollars for everything plus built-in analytics. The domain, by the way, I also bought from Cloudflare — it turned out to be cheaper than the usual registrars.

What’s next

That wraps up the first cycle: the blog works, it’s translated, has a design, OG posters, and metrics I’m not embarrassed about. The next step is automating post writing. I have an idea for how to do this in a “modern” way — I’ll write about it in a separate post.