We’ve all been there. You’re deep in a technical discussion with an AI assistant—analyzing code, exploring architecture, or debugging a complex issue. The conversation is rich with insights, and you think: “This would make a great blog post.”

But then reality hits: you need to switch to your blog repository, format the content, commit it, push it, and wait for the build. By the time you’re back, the original context is gone, and the momentum is lost.

What if you could publish directly from where you are?

Building on Existing Automation

In my previous post about automatically publishing a blog using GitHub Actions, I set up a workflow where pushing to the blog repository triggers an automatic build and deployment to GitHub Pages. This solved the build and deployment automation, but there was still one manual step remaining: creating the post file itself.

The workflow I described there handles:

1. Checking out the blog repository
2. Building the Hugo site with make
3. Deploying to jackysp.github.io

But you still needed to be in the blog repository to create the post. That’s where MCP changes everything.

Enter MCP: The Missing Link

The Model Context Protocol (MCP) is revolutionizing how AI agents interact with external systems. Instead of treating AI as a passive tool, MCP enables agents to act as autonomous agents with direct access to your tools and workflows.

In my setup, I’ve connected MCP-enabled agents (like Cursor) directly to my blog repository via GitHub MCP. This means:

• No context switching: Stay in your current working directory, whether it’s a random project folder or a deep codebase exploration
• Preserve conversation flow: The AI maintains the full context of your discussion
• Direct publishing: Create and publish posts without leaving your IDE

The Architecture: Seamless Integration

Here’s how the complete workflow operates:

┌─────────────────────────────────────────────────────────┐
│  AI Agent (Cursor/Claude) with MCP enabled              │
│  - Context: Any code repository or discussion            │
│  - Tool: GitHub MCP Server                               │
└──────────────────┬──────────────────────────────────────┘
                   │
                   │ Creates post via GitHub MCP
                   │
                   ▼
┌─────────────────────────────────────────────────────────┐
│  Blog Repository (jackysp/blog)                         │
│  - content/posts/[new-post].md                          │
│  - Commit: "Publish: [title]"                           │
└──────────────────┬──────────────────────────────────────┘
                   │
                   │ Push to master branch
                   │
                   ▼
┌─────────────────────────────────────────────────────────┐
│  GitHub Actions (from previous post)                     │
│  - Build: Hugo static site generation                   │
│  - Deploy: Push to jackysp.github.io                    │
└──────────────────┬──────────────────────────────────────┘
                   │
                   │ Published
                   │
                   ▼
┌─────────────────────────────────────────────────────────┐
│  Live Site (jackysp.github.io)                          │
│  - Post is live and accessible                           │
└─────────────────────────────────────────────────────────┘

The GitHub Actions part remains exactly as described in the previous post—no changes needed there. The MCP layer adds the ability to trigger it from anywhere.

The Workflow in Action

1. AI-Powered Content Creation

When you’re discussing a technical topic with an AI agent, you can simply ask:

“Turn this discussion into a blog post and publish it.”

The AI agent, with access to GitHub via MCP, can:

• Extract key insights from your conversation
• Format content according to Hugo front matter requirements
• Create properly structured markdown files
• Handle images and assets
• Commit and push to the repository

2. Automated Build & Deploy

The moment a post is pushed to the master branch, the same GitHub Actions workflow from the previous post kicks in:

on:
  push:
    branches: [ master ]

The workflow (as detailed in the previous post):

1. Checks out the blog repository with submodules
2. Builds the Hugo site using make
3. Deploys the built artifacts to jackysp.github.io

All without manual intervention.

3. Governance Through Contracts

To ensure quality and prevent accidents, I’ve implemented an AI Publishing Contract (PUBLISHING.md) that defines:

• Allowed paths: Only content/** and static/** can be modified
• Post format: Required front matter fields (title, date, tags, slug, summary)
• Image handling: Standardized location and reference format
• Commit conventions: Single commit per post with descriptive messages

This contract ensures that AI agents can publish content while respecting the repository structure and quality standards.

Why This Matters: The Developer Experience Revolution

Zero Context Switching

Traditional workflow:

1. Copy conversation → Switch to blog repo → Format → Commit → Push → Wait
2. Context lost, momentum broken

New workflow:

1. Ask AI to publish → Done
2. Context preserved, workflow continuous

Capturing Technical Insights

The best technical insights often emerge during active problem-solving. With this workflow, you can:

• Document discoveries in real-time
• Turn debugging sessions into tutorials
• Transform architecture discussions into deep-dives
• Share codebase explorations as learning resources

Scaling Knowledge Sharing

Previously, the friction of publishing meant many valuable insights were never written down. Now, the barrier to publishing is minimal, making it easier to:

• Share learnings with your team
• Build a personal knowledge base
• Contribute to the developer community
• Document your problem-solving journey

Technical Implementation Details

MCP Server Configuration

The GitHub MCP server provides the AI agent with:

• Repository read/write access
• File creation and modification
• Commit and push capabilities
• Branch management

GitHub Actions Workflow

The CI/CD pipeline (as described in the previous post) handles:

• Go environment setup (for Hugo builds)
• Repository checkout with submodules
• Site generation via make
• Deployment to GitHub Pages repository

No changes needed to the existing workflow—it just gets triggered from a new entry point.

Hugo Site Configuration

Posts follow Hugo’s standard structure:

• Location: content/posts/
• Format: YAML front matter + Markdown content
• Images: Stored in content/posts/images/
• Draft control: draft: true/false for preview/publish

The Future: AI-Augmented Documentation

This workflow represents a shift toward AI-augmented documentation. Instead of treating AI as a writing assistant, we’re treating it as a publishing agent that can:

• Understand context from code discussions
• Extract technical insights automatically
• Format and structure content appropriately
• Publish without breaking workflow

As MCP and similar protocols mature, we’ll see more sophisticated capabilities:

• Automatic code analysis and explanation
• Multi-post series generation from extended discussions
• Cross-referencing with existing content
• SEO and metadata optimization

Getting Started

If you want to set up a similar workflow:

1. Set up automated publishing (see my previous post)
2. Enable MCP in your AI agent (Cursor, Claude Desktop, etc.)
3. Configure GitHub MCP server with repository access
4. Define publishing contracts for governance
5. Start publishing from your conversations

The technical details are straightforward, but the impact on productivity and knowledge capture is profound.

Conclusion

The intersection of AI agents, MCP protocols, and automated CI/CD creates a new paradigm for technical publishing. By building on the existing GitHub Actions automation and adding MCP as the entry point, we eliminate context switching and reduce friction.

This isn’t just about automating blog posts—it’s about preserving the flow state of technical discovery and making knowledge sharing as natural as having a conversation.

The future of technical documentation is here, and it’s conversational.

This post was created and published using the exact workflow described above—from a discussion about workflow automation to a live blog post, all without leaving the conversation context.

As a long-time podcaster, I’ve always enjoyed sharing my thoughts and ideas through audio. While the world of video content—and the role of a YouTuber—has its allure, the complexities of video editing have kept me anchored in the realm of podcasting. My journey has involved leveraging platforms like Spotify Creator (formerly Anchor) for hosting and distributing my recordings. This platform offers a wide array of features for free, including audio recording, editing capabilities, and automatic promotion to Spotify.

However, I sought a more comprehensive solution, one that would allow me to listen to my own podcast while driving, using the Podcast app on my CarPlay device. To achieve this, I ventured into publishing on Apple Podcasts (podcastsconnect.apple.com), which also offers free hosting. With a self-designed cover and episodes uploaded, I was set—or so I thought.

The Challenges of Traditional Podcasting

Despite having the technical setup, I faced significant challenges:

• Consistency: Maintaining a regular publishing schedule proved difficult.
• Voice Quality: My voice quality was inconsistent, affecting listener engagement.
• Content Preparation: Crafting well-structured episodes without improvisation was challenging.
• Enhancements: Incorporating background music and other audio elements to enrich the listening experience required additional effort.

These hurdles led to my podcast being suspended for approximately two years. I found myself in need of a solution that could simplify the process and revitalize my passion for podcasting.

Discovering NotebookLM: An AI-Powered Podcasting Tool

Recently, I stumbled upon NotebookLM (notebooklm.google.com), an innovative application developed by Google. NotebookLM harnesses the power of artificial intelligence to generate podcast content. Users can provide a topic and related documents, and the AI takes over, creating engaging podcast episodes.

My Experience with NotebookLM

Intrigued, I decided to give NotebookLM a try. The results were nothing short of astounding:

• Effortless Production: The AI effortlessly generated a half-hour episode featuring two speakers discussing the topics in English.
• Enhanced Content: It went beyond the provided information, utilizing search engines to gather additional relevant data from the internet.
• Quality Output: The quality of the generated content was exceptionally high, surpassing what I could produce on my own.
• Incorporated Music: Appropriate background music was added, enhancing the overall listening experience.
• Cost-Free: All these features were available entirely for free.

A Case Study: Deep Dive into TiDB

To put NotebookLM to the test, I created an episode about TiDB, a product developed by my current employer. The process was seamless, and the final product was impressive. You can listen to the episode here: Deep Dive into TiDB.

Conclusion

The integration of AI into podcast creation through tools like NotebookLM has the potential to revolutionize the way we produce content. It removes many of the barriers that podcasters face, such as time constraints, technical challenges, and the need for consistent quality.

For anyone looking to start or rejuvenate their podcast without the traditional hassles, I highly recommend giving NotebookLM a try. It’s remarkable to see how AI can not only match but enhance human capabilities in creative endeavors.

I hope this helps! Let me know if there’s anything you’d like to add or modify in your blog post.

Table of Contents

• Introduction to Ollama
  • A Popular Choice
  • Ease of Use
  • Built with Golang
• My Practices with Ollama
  • Preferred Models
    • Llama 3.1
    • Mistral
    • Phi-3
    • Qwen-2
  • Hardware Constraints
• Exploring UIs for Ollama
  • OpenWebUI
  • Page Assist
  • Enchanted
  • AnythingLLM
  • Dify
• Diving into llamaindex
• Experimenting with Candle
• Conclusion

Introduction to Ollama

A Popular Choice

Ollama has rapidly become a favorite among developers interested in local LLMs. Within a year, it has garnered significant attention on GitHub, reflecting its growing user base and community support.

Ease of Use

One of Ollama’s standout features is its simplicity. It’s as easy to use as Docker, making it accessible even to those who may not be deeply familiar with machine learning frameworks. The straightforward command-line interface allows users to download and run models with minimal setup.

Built with Golang

Ollama is written in Golang, ensuring performance and efficiency. Golang’s concurrency features contribute to Ollama’s ability to handle tasks effectively, which is crucial when working with resource-intensive LLMs.

My Practices with Ollama

Preferred Models

Llama 3.1

I’ve found that Llama 3.1 works exceptionally well with Ollama. It’s my go-to choice due to its performance and compatibility.

Mistral

While Mistral also performs well, it hasn’t gained as much popularity as Llama. Nevertheless, it’s a solid option worth exploring.

Phi-3

Developed by Microsoft, Phi-3 is both fast and efficient. The 2B parameter model strikes a balance between size and performance, making it one of the best small-sized LLMs available.

Qwen-2

Despite its impressive benchmarks, Qwen-2 didn’t meet my expectations in practice. It might work well in certain contexts, but it didn’t suit my specific needs.

Hardware Constraints

Running large models on hardware with limited resources can be challenging. On my 16GB MacBook, models around 7B to 8B parameters are the upper limit. Attempting to run larger models results in performance issues.

Exploring UIs for Ollama

Enhancing the user experience with UIs can make interacting with local LLMs more intuitive. Here’s a look at some UIs I’ve tried:

OpenWebUI

OpenWebUI offers a smooth and user-friendly interface similar to Ollama’s default UI. It requires Docker to run efficiently, which might be a barrier for some users.

• Features:
  • Basic Retrieval-Augmented Generation (RAG) capabilities.
  • Connection to OpenAI APIs.

Page Assist

Page Assist is a Chrome extension that I’ve chosen for its simplicity and convenience.

• Advantages:
  • No requirement for Docker.
  • Accesses the current browser page as input, enabling context-aware interactions.

Enchanted

Enchanted is unique as it provides an iOS UI for local LLMs with support for Ollama.

• Usage:
  • By using Tailscale, I can connect it to Ollama running on my MacBook.
  • Serves as an alternative to Apple’s native intelligence features.

AnythingLLM

AnythingLLM offers enhanced RAG capabilities. However, in my experience, it hasn’t performed consistently well enough for regular use.

Dify

Dify is a powerful and feature-rich option.

• Pros:
  • Easy to set up with an extensive feature set.
• Cons:
  • Resource-intensive, requiring Docker and running multiple containers like Redis and PostgreSQL.

Diving into llamaindex

llamaindex is geared towards developers who are comfortable writing code. While it offers robust functionalities, it does have a learning curve.

• Observations:
  • Documentation is somewhat limited, often necessitating diving into the source code.
  • The llamaindex-cli tool aims to simplify getting started but isn’t entirely stable.
    • Works seamlessly with OpenAI.
    • Requires code modifications to function with Ollama.

Experimenting with Candle

Candle is an intriguing project written in Rust.

• Features:

  • Uses Hugging Face to download models.
  • Simple to run but exhibits slower performance compared to Ollama.

• Additional Tools:

  • Cake: A distributed solution based on Candle, Cake opens up possibilities for scaling and extending use cases.

Conclusion

Exploring local LLMs has been an exciting journey filled with learning and experimentation. Tools like Ollama, llamaindex, and Candle offer various pathways to harnessing the power of LLMs on personal hardware. While there are challenges, especially with hardware limitations and setup complexities, the control and privacy afforded by local models make the effort worthwhile.

Feel free to share your experiences or ask questions in the comments below!