When I built the slowloop blog, I made one decision.
No database.
At first it looked like a technical choice. Setting up a CMS felt tedious, running a database felt expensive, and markdown seemed like enough. But once I was actually using it, I realized this wasn’t just a tech decision. It was a decision about how I’d work with AI.
“I want to manage the blog without a separate DB — just using an LLM. Is this level of metadata and indexing enough to make it work?”
When I asked that, the answer was “yes.” And it turned out to be true.
Why Text Structure Works Well for AI Collaboration
With a database, AI can only access content through a structured API. It needs to write queries, understand the schema, and handle migrations every time something changes.
With plain text files, it’s different. AI just reads. Open a file, see the contents, edit, save. No extra layer.
export/slowloop/
├── content-drafts/ # posts in progress
│ ├── series-map.md # overall series status
│ └── *.md # draft files
├── blog/ # published KO
│ └── series-name/*.md
└── blog_en/ # published EN
└── series-name/*.mdAI doesn’t need an explanation to understand this structure. Open the files and everything is visible.
What This Makes Possible
Full Content Status at a Glance
A single series-map.md contains the entire series list, arc status, per-post state, and translation coverage.
When AI reads just this one file, it knows:
- How many posts exist so far
- Which series are active and how far each has come
- What needs to be written next
- What’s missing a translation
All of it. Even when a conversation is interrupted, reading this file brings the context back immediately.
Automatic KO/EN Translation
Write one post and both a KO version in blog/ and an EN version in blog_en/ get created together. AI does the translation. No outsourcing, no hiring a translator.
This is possible because of the text structure. With a database, you’d need to create separate translation records and manage their relationships. With files, you just copy and translate.
The primary audience is Korean-speaking, but the plan from the start was to also publish in English via AI translation. That’s only cost-free because of this structure.
Automatic Document Linking
Published posts are connected through the references: field. When AI drafts a new post, it can follow these links, read the related content, and incorporate it.
During the /blog-publish step, it scans the entire published corpus and automatically finds posts worth linking. I don’t have to manually say “connect this one to that one.”
The wiki is the source for the blog; the blog is the published form of the wiki. Because everything is text, AI can read both sides and connect them.
There Are Real Downsides
This structure has a lot going for it, but real-world use shows its limits too.
Consistency degrades. When AI manages multiple files, contradictions start to appear. The same fact written one way in file A and differently in file B. Without someone manually cross-checking, these are hard to catch. A database keeps everything in one place, so this problem doesn’t exist — but distributed files make it unavoidable. The experience of this becoming actual hallucination is covered in this post.
Fixing errors is harder than it looks. When AI-generated content contains a mistake, correcting it isn’t simple. You have to find the right text file, figure out which part is wrong, fix it, and possibly fix related files too. With a database, you update one record and you’re done. When the same content exists in both KO and EN versions, you have to fix both.
When AI loses context, it can edit things in unexpected ways. When a conversation starts fresh, AI has no memory of what was decided before. Reading the entry-point files (series-map.md, _index.md) gives a rough picture — but not the reasoning behind earlier decisions. The wiki sitting next to the blog, dedicated to capturing exactly that context, is what holds this together.
What This Structure Actually Enables
Running a blog on text files without a database means AI can treat the entire blog as a single filesystem.
Writing, translating, linking, tracking status, suggesting what to write next — AI does all of it. I set the direction, review the content, and decide what gets published.
This is the right way to run a blog as a solo developer.
The builder designs the tools, and AI operates them. The goal isn’t for things to run without me — it’s for me to only be present where I actually need to be.