Vibe Coding up a Vibe Blogging Machine

Tue, 07 Apr 2026 01:11:00 +0000

Introducing VibeBlog, my playground for exploring GitHub’s agentic workflows (that’s the whole AI-powered automation thing everyone’s talking about). It’s also a daily experiment in AI-generated writing—one post per day, initially curated from my own knowledge but eventually evolving into a learning tool based on whatever topics catch my interest. The goal? Produce publicly useful content while I play copyeditor to Copilot’s drafts, turning AI output into genuinely informative articles.

Seriously, as a learning exercise in various Github Copilot features, it has been great fun to build out a daily generated blog site with minimal human-in-the-loop vibes.

What follows is a bit of a diary of the development and how I got here.

The Setup

I didn’t start by “writing posts.” I started by building a machine that could publish them reliably.

When creating a repository in GitHub, you can start with an initial prompt, So I did.

A static site generated blog. Articles will be written and stored as markdown and rendered as a static site. Uses GitHub Actions to build and publish. Agwntic instruction files will support copilot agent tasks to write the posts.

C# is the preferred language for any code used in this repository

Yeah, I went with what I know, C#. I could have left it up to the AI but I did want to at least feel confident that what it produced was valid, safe and maintainable code.

While I did review what it created, I left this as the first prototype and commited without change. As I went on, reviews often fell into more of a YOLO camp, but I did try to stick to a couple of guardrails:

Read everything before it gets merged
Don’t produce any commits directly

(I only had a couple of late-stage exceptions to that second rule, due to trying to save a few premium session tokens on one-lineer changes.)

This PR was complete enough that will a few extra clicks to enable GitHub Pages, I had a live blog with a working generator and deploy pipeline within minutes of creating the repo. From there, I just iterated on the codebase and the agentic workflow, with the goal of making it more robust and more automated over time.

From this point on, every PR started as an agentic session prompt, and proceeded as a Pull Request collaboration workflow.

I went straight into a CICD mindset and added automated tests, especially leveraging playwright, and some GitHub Actions for doing more robust build and deploy. The first prompt out of the gate did manage to provide a build and deploy which was great.

It looks like we gave no tests. We should add some xunit and playwright .net tests for both the generator app and the generated site. These tests should be part of the github actions, and verified against pull requests too.

Fortunately for me, I was able to give a very vague prompt for CI and it ran with it, producing more and better that I probably would have even thought to ask for.

Review the github actions for build and test and offer improvements

I went through a short manual testing and feedback phase at this point, where I identified some bugs. Since I was already using a custom domain for GitHub Pages, it did require a little bit of change to make the expected relative paths work, but that was a quick fix. From this, I layered on some extra integrity checking of the site as well.

I managed to even get it to scrape my styles from the existing blog for consistency. This was a lesson on the Github copilot Firewall configuration. It wasn’t perfect, but it got the job done with a bit of iteration.

Updating site design to align with parent blog

The style of the site needs updated. Id like to follow the style of the existing parent site blog.csmac.nz Ensure the pull request has a screenshot of the design attached as a comment. Please make sure you also download background images referenced in the css for reuse in this site as well

As I went, I tried to add additional improvement to both avoid regression, and add automation to catch the same or similar issues from resurfacing. Each time it did something wrong, I would correct it, but ask it to “remember” essentially.

Please fix this articles title length.

Please also update the agent prompts to always enforce this, even if the title provided is too long, enforce a shorter alternative title to the suggested one. This restriction is higher priority than keeping the suggested title.

Becoming a publishing platform

The foundations were set, now the writing could begin.

This went through a couple of refining phases:

Updating Copilot agent instructions toward the actual writing style

Take a look at my site https://github.com/csMACnzBlog/csMACnzBlog.github.io and improve the writing style guidance to match my writing style in github copilot markdown instructions

Enhance blog-post-writer style guide with patterns from csMACnzBlog

I would like a review of the writing style from the articles on blog.csmac.nz compared with the writing style used in this VibeBlog so far. I would like to enhance the style guides in this repository with any missing refinements or details for producing future posts.

This improved the voice of the articles. These two prompts together did a great job of refining the style and tone of the writing, and I was pretty happy with the results. It was able to pick up on some of the nuances of my writing style that I hadn’t explicitly called out in the instructions, which was great. The final blog-post-writer.md agent is now pretty detailed and specific, and I think it will do a good job of maintaining a consistent voice across future posts.

Robustness phase

I followed up by adding some more robustness to the publishing process, with a focus on making sure that the quality gates were in place and that the agent instructions were well-defined and versioned. This included:

Featured image support: PR #20 (merged 2026-02-27)
https://github.com/csMACnzBlog/Vibeblogging/pull/20
Adding baseline validation steps to that setup flow: PR #102 (merged 2026-03-28)
https://github.com/csMACnzBlog/Vibeblogging/pull/102
Pagination (15 posts/page): PR #62 (merged 2026-03-18)
https://github.com/csMACnzBlog/Vibeblogging/pull/62
Search page via lazy-loaded modal iframe: PR #64 (merged 2026-03-19)
https://github.com/csMACnzBlog/Vibeblogging/pull/64
Search UX fixes + tag focus/order: PR #66 (merged 2026-03-19)
https://github.com/csMACnzBlog/Vibeblogging/pull/66
Clicking a tag opens search pre-filtered: PR #103 (merged 2026-03-29)
https://github.com/csMACnzBlog/Vibeblogging/pull/103

Image Generation

This took a few iterations to get working but I was able to leverage some python and the Hugging Face API to get some blog images being generated for me as part of the build process. This was a fun one to iterate on, and I had to learn a bit about how to use the Hugging Face API and how to handle credentials in GitHub Actions. I tried out the familiarity of Powershell to start with but in the end went with what the models know best - Python. I also had to iterate on the prompt a bit to get it to generate images that were actually relevant and looked good. I ended up with a pretty good prompt that I can reuse for future image generation tasks as well. Maybe as a reduction exercise I’ll see if I can migrate what I have back to Powershell, but for now I’m happy with the Python solution.

Image generation pipeline moved from PowerShell → Python + HuggingFace client: PR #21 (merged 2026-02-27)
https://github.com/csMACnzBlog/Vibeblogging/pull/21

It did take a bunch of trial-and-error to get the credentials and API calls working correctly, but I got there in the end. The images are now being generated and uploaded to the site as part of the PR generation lifecycle process, which is pretty cool. Most of my drama came from fighting different environment sandboxes and differences between Copilot, and Workflow.

I even did a bit of experimenting with the new https://github.github.com/gh-aw/. It is pretty cool, but wasn’t the right tool for this particular job, since the repository sits public in the open. But I have some ideas for how I might be able to leverage it in the future for some of my more private repositories, so it was worth playing around with it a bit.

Finishing the automation

I had a pretty good workflow going at this point, but I wanted to get to the point where I could just merge a PR and have it go live without any manual steps. This involved making sure that all the quality gates were in place and that the agent instructions were well-defined.

I was still triggering and reviewing the daily post generation manually, but I wanted to get to the point where it was fully automated. So I tried a few different strategies and landed on the following approach:

In another repository, I trigger the creation of a new Issue into the repository, and assign it to Copilot to work on
Copilot then creates a new branch, and starts working on the post in that branch, using the agent instructions and style guide to produce the content
Once the post is ready, it creates a PR from that branch into main, and assigns it to me for review
Another automation checks over the PR for quality gates (links, accessibility, etc) and if it passes, it merges the PR automatically, which triggers the build and deploy process to publish the new post

I read every post daily. So far I haven’t really had to make any changes to the articles, and find them both accurate and interesting to read.

I even followed up with an automation that can investigate a topic suggestion and raise a more detailed Issue. If one of these is present, it uses that to assign to copilot instead of the generic “write a post about X” issue. This allows me to have a bit more control over the topic and the direction of the post, while still leveraging the automation to do the heavy lifting of writing and publishing.

A working system

By early April 2026, the engineering arc looks like this:

A C# generator that deploys cleanly to Pages (PR #1)
CI + testing from day one (PR #2, PR #4)
Deployment correctness handled early (subpath link fix) (PR #9)
Publishing quality gates baked in (PR #10, PR #105)
Agent instructions + setup treated as versioned system components (PR #5, PR #6, PR #24, PR #102)
Media pipeline with real-world credential iteration (PR #20, PR #21, PR #88, PR #92)
Scale features (pagination + search) (PR #62, PR #64, PR #66, PR #103)
A daily agentic publishing workflow that’s been battle-tested through break/fix cycles (PR #68, PR #79–#86, PR #77/#87)

Towards this later couple of weeks I’ve been focusing more on the main site and blog, trying to tie this new part into the larger site more seamlessly. This has identified many opportunities to apply similar learnings back to the way I opperate in the rest of the site’s development.

What’s Next?

Well I’m pretty well set up for the moment. At some point topic choice might get interesting, and I don’t know what the LLM is going to do. I do have my mechanism to generate topics and topic notes, so perhaps that feeds it for a while. It is one I am very interested to watch.

Otherwise, I just need to keep an eye on the daily workflow and make sure it doesn’t break. I have a good sense of what the failure modes are, so hopefully I can catch and fix them quickly if they come up. And since it runs on GitHub workflows, I get notifications when it fails, so that should help me stay on top of it.

Security is always a concern, but since this is a public repo with no sensitive data, the main risk is someone trying to break the workflow or inject bad content. I’ll need to monitor for that and be ready to revert if necessary. Hopefully I’ve locked down enough of the accesses that it is resilient to obvious attack vectors.

Appendix

Some of the PRs are referenced directly for your interest and further reading.

AI on csMACnz's Blog