When the Blog Became an Editorial System

The first part was about how the blog's look and basic idea came together. That was the visible part: the dark editorial direction, the prompt-built intro animation, and the repeated steering away from anything too portal-like.

But when a project like this exists, a less comfortable question arrives: fine, we climbed the mountain, now are we actually going to use it?

I am oldschool about this. I want to make something. There is a mountain, I want to climb it. The goal is not necessarily to own a blog. The blog is more of a pretext. A bounded task through which I can test how far AI-assisted work can now carry something that would have taken me months of pixel pushing a few years ago.

But once it exists, the system has to survive the moment of creation. That was the real problem.

The problem: Codex must not bypass the system

With AI, it is very easy to be conveniently wrong. I could ask Codex to write articles directly into the database. Or generate Markdown files. Or paste HTML somewhere. For a single occasion, all of these could work.

But then there is no publishing workflow. There is only a codebase we sometimes bypass.

What I wanted instead was simple: if Codex edits, it should not do it behind the system. It should enter through the same door I would use. If I would publish through the admin as a human, Codex should publish through the admin too.

That is why the admin became a work boundary, not an extra.

The screenshot shows the point: slug, status, publish date, tags, featured image, Hungarian and English fields, article files, inline insertion. This is not a world-changing CMS. It is exactly enough admin for an article to be born properly.

Why I knew what kind of admin I needed

Because I have built enough of them. Take fotel.hu, for example, which I am especially proud of because it comes from before the GPT era. A fully custom site, no framework, with a serious editorial system, tagged search, videos and complex content management. I built that alone too.

This is not a CV detour. It is important context. I am not guessing what makes an admin usable. I know what happens when an HTML-based site comes together, works, and then threads, content, states and exceptions outgrow what you can comfortably keep in your head.

This is where many personal projects bend. Not because of the frontend. Not even because of the backend. They bend because there is no proper admin workflow. There is no single place where you can see the article state, attached assets, what is public, what is unfinished, and what is missing.

The decision: this is just a blog, let it stay one

The other side matters just as much: I did not want a big CMS. This is just a damn blog.

Each article needs to accept source materials. Images, Markdown snippets, downloadable files. Those should be easy to insert into the article body. The frontend CSS should decide what content looks like. Each article should not get its own little design universe. No formatting outside the site's scope.

In older systems I built by hand, I solved this more elegantly. At the moment of create, a temporary article state already existed. You could immediately upload images, files and resources to it. If the editor abandoned it, it was reset. If it became a real article, the temporary state became permanent.

Here I accepted that the article has to be saved once before assets can be attached to it. It is not perfect, but it is good enough. And that matters: in a personal AI-assisted tool, not every piece of old admin elegance needs to be rebuilt on day one. What matters is that the workflow does not lie.

Two languages: not a data model, but a chance

The reason for multilingual content was not architectural cleverness. The motivation was simpler: if a search engine accidentally finds the site, and the English version is also written properly, we have a better chance of helping a stranger somewhere in the world.

Because of AI, this is no longer as heavy as it used to be. But there is still risk in it. I still worry whether we will get to the point where you really understand and use my voice. I do not mean randomly sprinkling profanity. I mean keeping the rhythm, irony, professional confidence and self-criticism together.

That is why Hungarian and English cannot live two separate lives. There is one article with two language versions. Codex does not translate some file somewhere. It fills the other language in the same admin. If both languages are not complete, there is no publishing.

The reusable lesson is this: do not treat multilingual content only as translation. Treat it as a publishing rule. Do not trust memory to know whether the second language exists. Make the system require it.

AuthHandler: an old personal weapon in a new place

AuthHandler was not born for this blog. I wrote it back in the GPT-4.0 era, when I started fegyvermarket. I wanted an authenticator class that could independently handle provider auth and password auth, with the important surrounding flows: code or email-link confirmation, password reset, password change and provider connections.

This was still the era of copy-paste from the GPT web page into VS Code. And that was not the only reason it was harder. GPT-4.0 still bled from many wounds. A lot of manual coding was needed afterwards.

But AuthHandler worked. The goal was that for complex web services I would not have to suffer through auth handling again and again. One class instance should contain everything important about the user and login state, handled by a self-contained module from beginning to end.

For the blog, only the provider-only part was needed. Google and Facebook. No public password registration. No profile page. No social network. Here identification is really only needed for leaving likes and comments. Probably nobody will ever use it, but it works. I built it the way I imagined.

AuthHandler where it is actually needed

Login does not try to become the main event. It appears near the bottom of the article, where likes and comments actually need identity.

The user deletion flow was not philosophical either. Whatever the two big providers require, the system has to handle properly. If someone wants to delete their user, the system should delete or anonymize what needs to be deleted or anonymized. Not because that makes the blog exciting, but because it is the correct closure.

AuthHandler will deserve its own article, because it is a good example of how much AI-assisted coding has changed since GPT-4.0. Back then, a lot of things still had to be pulled into shape manually. With Codex today, connecting, adjusting and productizing a module like this happens at a very different pace.

The code is also public on GitHub: sanch78/_AuthHandler. That makes AuthHandler not only an internal reference, but also a concrete starting point for seeing how a reusable auth module can be treated as its own tool.

Messages: mailto is lame

The problem with messages was simple: mailto is lame.

Sure, it works. But it breaks the experience. It throws the reader into a mail client, another app, another context. On a blog where the whole point is to stay inside the thought while reading, that feels unnecessarily clumsy.

So it became a modal. Name, email, message, save. Admin list. Not a CRM, not a ticket system, not a support portal. You can explain in half a sentence why it is nicer and how it works.

And of course there is the real business use case: if someone suddenly believes I am an absurdly competent expert and wants to pay one million dollars for my opinion, then me and Mini Me, meaning Codex, will handle it at speed.

When the message form finally brings a serious inquiry

The most optimistic business scenario for the contact form: a one million dollar inquiry, interesting status, Codex standing by.

Jokes aside, the message feature teaches the same lesson: a small feature can be proper without pretending to be more than it is. The reader can write. I receive it. Done.

Subscription: the usual small thing, we will see

There is no big philosophy behind subscription. The usual small thing: email field, validation, active status, admin list.

I would be surprised if even one person subscribed. If that ever happens, I will discover why other people have this feature.

That sounds cynical, but there is a practical decision in it. Do not build a newsletter platform before there is reader demand. No campaign machine, no tracking, no segmentation. For now, it is enough that if someone asks for updates, there is somewhere to store the email.

It is the same pattern again: do not build a large system for an assumed need. Build a small, clean receiving point, then expand if real life pushes traffic onto it.

The most important trick: turning a thread into documentation

There is one more thought that came together while writing this, and I think it matters more than any specific feature.

Often we start a thread casually. A quick question, a quick fix, and then suddenly it turns out this will be longer. At that point, the next good step is not asking for more code. It is turning the thread into transferable documentation.

My prompt for this looks roughly like this:

# Promptminta: amikor egy thread kinövi magát

Ezt akkor érdemes használni, amikor egy beszélgetés már nem csak gyors kérdés-válasz, hanem projektindító anyag lett.

```text
A thread alapján készíts el logikusan minden szükséges markup dokumentációt.

A cél az, hogy egy nulláról induló új thread teljesen képben legyen:
- mi a projekt célja;
- mi a jelenlegi állapot;
- milyen döntéseket hoztunk;
- mit tilos újra kitalálni;
- milyen fájlok, modulok, felületek és munkafolyamatok fontosak;
- milyen nyitott kérdések maradtak.

Ha bármi nem világos, előbb kérdezz.

Ne csak összefoglalj, hanem challenge-eld is a dokumentációt:
- hol hiányzik kontextus;
- hol túl homályos egy döntés;
- hol lehet félreérteni a következő threadben;
- hol kell konkrétabb szabály vagy példa.

Addig iterálj a dokumentációs javaslatokon, amíg nem látod hiányosnak őket.
```

## Miért működik?

Az AI-val végzett hosszabb munkáknál nem az a legnagyobb baj, hogy elfogy az ötlet. Hanem az, hogy a thread előbb-utóbb túl sok állapotot hordoz.

Ilyenkor nem újabb kód kell elsőre, hanem átadható kontextus.

---

# Prompt pattern: when a thread outgrows itself

Use this when a conversation is no longer just quick Q&A, but has become project-starting material.

```text
Based on this thread, create all necessary markup documentation in a logical structure.

The goal is that a brand new thread starting from zero has full context:
- what the project is for;
- what the current state is;
- which decisions have already been made;
- what must not be reinvented;
- which files, modules, interfaces and workflows matter;
- which open questions remain.

If anything is unclear, ask first.

Do not only summarize. Challenge the documentation too:
- where context is missing;
- where a decision is too vague;
- where the next thread could misunderstand something;
- where a more concrete rule or example is needed.

Iterate on the documentation suggestions until you no longer find them incomplete.
```

## Why it works

In longer AI-assisted work, the biggest problem is usually not lack of ideas. It is that the thread eventually carries too much state.

At that point, the next thing you need is not more code. It is transferable context.

This works because one of the main enemies of AI-assisted work is lost context. A long thread contains many decisions, half-sentences, reversals and "actually, not that way" moments. If that does not become documentation, the next round has to learn everything again.

But if the thread produces a README, goals, architecture, workflow and a list of things not to do, a new thread no longer starts in the dark. And Codex does not reinvent what we already decided.

What can someone copy from this?

If someone wants to build something similar, I do not think the first question should be which framework to use. The better questions are:

• Where is the single official gate for publishing?
• Does AI use the same gate as the human?
• What is the smallest admin that already prevents chaos?
• Which states must the system enforce?
• Which feature is a real need, and which one is just CMS nostalgia?
• When should a thread become documentation before more code is written?

This article is therefore not about "adding extras". It is about the blog becoming usable when the comfortable side doors were closed.

Codex should not edit files directly. It should not magic the database. It should not produce half-floating Markdown. It should use the admin. Fill both languages. Upload the asset. Insert the resource. Publish through the same system I would use.

From that point on, we were no longer only building a blog. An editorial workflow started to appear.