The biggest challenge in running a tech blog is “how do I consistently write quality content?” Add multilingual support to the mix, and the workload doubles with translations.

/dev/write was born from these struggles. By combining Hugo static site generator with GitHub Copilot, I built an environment where you can focus solely on writing.

Why Another Blog System?

Honestly, existing blog platforms are great. Medium, Dev.to, Hashnode—all excellent choices. But there were a few pain points.

First, multilingual support. I wanted to publish posts in Korean, English, and Japanese, but most platforms required separate accounts or complex configurations.

Second, concerns about AI training data. Having my carefully written content used for AI model training without consent isn’t exactly pleasant.

Third, automated workflows. I wanted to automate the process of writing, reviewing, translating, and publishing as much as possible.

So I built a system based on Hugo + PaperMod theme that addresses all three.

Writing with GitHub Copilot

The most interesting part of /dev/write is using GitHub Copilot as a writing tool. In VS Code, you can invoke various prompts with the / command.

/create-draft Write about Docker container networking

You can just throw a topic like this, or provide a more detailed outline.

/create-draft
- Topic: Kubernetes Introduction
- Cover: Pod, Service, Deployment concepts
- Target: Developers familiar with Docker

If you have an existing README or documentation, you can ask it to create a tutorial based on that.

/create-draft Create a tutorial post based on this README
#file:README.md

AI Doesn’t Write Everything

Of course, leaving everything to AI from start to finish isn’t always the answer. In fact, writing the draft yourself first and having AI flesh it out often produces better results.

For example, if you want to migrate a post from your old blog and rewrite it in a tech blog style:

/complete-manual-post Rewrite this post in a tech blog style
#file:my-old-post.md

If you have a draft you wrote yourself, you can ask for code examples or more detailed explanations.

Based on this draft I wrote, make the content richer.
Add code examples and more detailed explanations.
#file:2025-12-05-my-draft.md

For posts where personal experience or opinions matter, or when you want to verify technical accuracy yourself, this approach is much more effective. AI is just a helper—the final judgment is yours.

Write One, Get Three

Another feature of /dev/write is automatic translation. Write in Korean, and English and Japanese versions are automatically generated.

Sure, machine translation has its limits. But it’s far better than writing in three languages from scratch. Just review the results and fix what needs fixing.

To maintain consistency during translation, there are a few rules:

  • Metadata like slug, translationKey, date stays identical across all languages
  • Title, tags, summary, and body content are translated
  • Code blocks are not translated (obviously!)

English uses American English, Japanese uses です/ます form. Technical terms are kept in the original language or shown in parentheses.

After translation, a validation script checks that all three language versions are properly aligned.

.\scripts\validate-translations.ps1

Verifying Technical Accuracy

The most important thing in a tech blog is accuracy. Especially when covering Microsoft technologies like Azure or .NET, checking against official documentation is essential.

/dev/write automates this through the MS Learn MCP Server. The MCP server is registered in the mcp.json file and configured for use.

The MCP server queries Microsoft’s official documentation to check if you’re using the latest API versions, if any features are deprecated, and if your content aligns with official recommendations. It helps prevent those “this method is no longer recommended” comments on your blog posts.

Why Scheduled Publishing Was Retired

The first implementation combined a future date value with a GitHub Actions cron schedule. In practice, GitHub Actions did not always start at the requested time. Runner queues and service conditions could delay publication.

The access model of a static site was another mismatch. Hugo can omit future posts from lists and build output, but a public Git repository does not provide server-side authentication or private content storage.

Scheduled publishing was therefore retired. A post now uses a current or past date, and publication happens when a commit changing all three translations to draft: false reaches main. A platform designed for timed release and pre-publication access control would be a better fit if those capabilities become necessary.

AI Crawler Policy

/dev/write allows major AI crawlers so that published content can be discovered and cited. The robots.txt file explicitly allows GPTBot, Google-Extended, CCBot, anthropic-ai, and other named crawlers.

The robots.txt file communicates a request to crawlers rather than enforcing access control. The CC BY-NC 4.0 license terms still apply independently of this crawler policy.

Local Preview

Want to see how your post looks before publishing? Just run the Hugo server locally.

hugo server -D

The -D flag shows posts with draft: true. Access http://localhost:1313 in your browser for a live preview. Files auto-refresh when you make changes, so it’s easy to check your work.

Wrapping Up

/dev/write isn’t perfect yet. But I think it’s achieved the goal of focusing on writing and automating the rest.

Multilingual support, AI-assisted editing, translation validation, and automated deployment now provide the core publishing flow. Features that do not fit the platform will continue to be removed based on operational evidence.

If you’re interested, check out the GitHub repository. Feedback is always welcome.