Over the last period, I managed to build several things with Codex that I had wanted to build for a long time. They had not been waiting because they were impossible, or because I lacked the technical background. They were waiting because these are the kinds of projects that need a particular kind of momentum: not only starting, but actually carrying them through.

One of them was the commercial engine behind fegyvermarket.hu. It started from the idea of building a classified-ad system for specialized areas. Markets where a general marketplace is not necessarily the right place, or where it may not want to be present at all. The first covered area became legal firearms trading, but the engine itself grew from a more general idea.

Another one was cleaning up my home infrastructure: a robust multi-WAN firewall, multiple internet connections, failover, and fixed IPv4 hosting from home, even from behind a NATed WAN. It is the kind of task where every part makes sense on paper, yet it is easy to postpone for years because something else is always more urgent.

Then, suddenly, there were several working things. Things I was proud of. And that led to a simple thought: I should write them down somewhere. Not because this will become mass media, but because if even one person finds it interesting, useful, or encouraging, it is already worth it.

For that, I needed a place.

I was not looking for a blog engine. I had already had enough of those.

I have been a fullstack HTML5 developer for roughly thirty years. I have built enough content management systems, admin interfaces, and custom frameworks that the question "which CMS should I use?" did not really come up. I did not work with market frameworks; I was far enough ahead technically that people trusted me to solve things my way.

There was, for example, a banking project that a team could not deliver in a year. With my own admin framework at the time, called ADE, I delivered it from scratch in two weeks. I am not saying this to brag. It is important context: I was not starting from "I need a ready-made system because otherwise I cannot cope".

Quite the opposite. I know what a good admin feels like. I know where a CMS starts to bloat for no reason. I know when content management becomes a parody of itself.

So I wanted an oldschool blog. But without a blog-engine pose. It should be mine. It should be simple. It should be understandable. The frontend CSS should define what the content looks like, and the admin should do only as much as it has to.

The first prompt was still quite raw. Something like: I want to make a blog site, mostly about AI coding, plain text blog, sometimes videos, under sanch.hu, make a damn good visual concept, preferably not with an ancient HTML4 feeling.

That was a good start, because it had ambition in it. But it did not yet have the exact shape.

The first direction became a modern dev/AI vibe. A bit Vercel, a bit Linear, a bit hacker minimal. Dark mode, code, AI, grid, cards, AI tools, CTAs, all the things you usually get when you ask for something modern and techy.

It was not bad. It was just too much like a portal.

And that was the first important human decision: this should be more of a blog. Not a portal. Not a dashboard. Not a SaaS landing page. It should not try to look like a product. It should be readable.

What I did like was the idea of an intro animation. An empty page. Some kind of AI input container in the middle. A prompt types itself in. Thinking. Building page as requested. Then the sanch.hu blog assembles in front of your eyes.

Prompt example for the intro animation

A later, more concrete repair prompt that did not ask for vibes, but for verifiable behavior: real DOM elements, sequence, states, and replay support.

View intro-animation-prompt-example.md
Download

intro-animation-prompt-example.md

# Prompt példa: intro animáció javítása

Ez a részlet azt mutatja, hogyan lett a "legyen valami AI-os intro" ötletből konkrét, ellenőrizhető feladat Codex számára.

```text
Build a real animated homepage intro for the existing blog.

Read the current homepage, CSS and JavaScript first. Do not create a separate fake animation mockup.

Requirements:

1. On first load, start from a blank dark screen.
2. Show one centered AI prompt box.
3. Type this prompt character by character:
   "build a fully functional blog page. Techy but not high tech. Not fancy. Simple blog functionality."
4. After typing, show visible progress states:
   - thinking
   - reading constraints
   - assembling layout
   - done
5. Reveal the real page elements in sequence:
   - header
   - hero
   - post feed heading
   - post cards
   - sidebar
   - footer
6. The animation must reveal the actual DOM elements that remain usable after the intro.
7. Do not leave fallback text visible.
8. Do not introduce React or any frontend framework.
9. Keep the style calm, dark, editorial and readable.
10. Add a way to replay the intro with `?intro=1`.

After implementation, verify in the browser that the page is usable after the overlay disappears.
```

## Miért hasznos?

Az első változatoknál nem az volt a gond, hogy "nem volt elég szép". Az volt a gond, hogy az animáció nem a valódi oldalt építette fel, vagy statikus fallback állapot ragadt a felületen.

Ez a prompt már nem hangulatot kér, hanem működést:

- mit kell látni először;
- milyen állapotok kövessék egymást;
- melyik valós DOM-elemek jelenjenek meg;
- mit tilos behozni;
- hogyan kell ellenőrizni a végeredményt.

---

# Prompt example: fixing the intro animation

This excerpt shows how the vague "let's have an AI-style intro" idea became a concrete, testable Codex task.

```text
Build a real animated homepage intro for the existing blog.

Read the current homepage, CSS and JavaScript first. Do not create a separate fake animation mockup.

Requirements:

1. On first load, start from a blank dark screen.
2. Show one centered AI prompt box.
3. Type this prompt character by character:
   "build a fully functional blog page. Techy but not high tech. Not fancy. Simple blog functionality."
4. After typing, show visible progress states:
   - thinking
   - reading constraints
   - assembling layout
   - done
5. Reveal the real page elements in sequence:
   - header
   - hero
   - post feed heading
   - post cards
   - sidebar
   - footer
6. The animation must reveal the actual DOM elements that remain usable after the intro.
7. Do not leave fallback text visible.
8. Do not introduce React or any frontend framework.
9. Keep the style calm, dark, editorial and readable.
10. Add a way to replay the intro with `?intro=1`.

After implementation, verify in the browser that the page is usable after the overlay disappears.
```

## Why it helps

The early versions were not merely "not pretty enough". The problem was that the animation either did not build the real page, or a static fallback state remained visible.

This prompt asks for behavior, not vibes:

- what appears first;
- which states follow each other;
- which real DOM elements are revealed;
- what must not be introduced;
- how the result should be checked.

That was both a visual element and a very accurate metaphor. Because that is roughly how the whole project happened. Not by a finished system falling out of a single prompt, but by talking, giving direction, pushing back, criticizing, prompting again, letting Codex work, then fixing it again.

The final design direction took shape somewhere around this sentence: a simple dark editorial blog, with a few blue accents, plenty of whitespace, and proper typography. Not a portal, not a dashboard, not an AI SaaS landing page. More like a personal professional blog whose intro animation gives it character.

This is an important distinction. The blog is personal because I write about things I am proud of. Completed or ongoing projects I built together with AI. But that does not make it a diary. The goal is not to publish every daily mood swing, but to show through concrete work what can actually be built with AI today.

There may be diary-like reports later, especially for larger projects. But the base is not confession. It is more like a workshop journal, just in a slightly more organized form.

The development process was interesting too. The blog started in the browser-based ChatGPT. That is where the concept took shape, and where the first project descriptions, READMEs, goal documents, and architecture notes were written. Then I handed the process over to Codex, so we would not only talk about it, but actually build it.

Codex almost got it right on the first try. But "almost" is doing a lot of work here.

The browser-based ChatGPT became a kind of ruthless reviewer. It looked at the current state, criticized it, and wrote new prompts for Codex. Sometimes quite bluntly. In one round, the essential verdict on the homepage animation was that it was not a bad animation, but practically no animation at all. In another, fallback HTML was still visible. In another, the whole thing was too thin.

And it was right.

This part matters much more than the visual result itself. It shows how AI work actually functions. Not by typing one all-knowing prompt and receiving a finished product. It works by building a workflow.

A short project brief Codex can actually work from

Not full documentation, just the kind of frame that keeps AI from immediately building a system that is too large.

View codex-ready-projektbrief-reszlet.md
Download

codex-ready-projektbrief-reszlet.md

# Codex-ready projektbrief részlet

Ezt a rövid mintát akkor érdemes használni, amikor nem egyetlen nagy "csináld meg" promptot akarsz adni, hanem munkára fogható keretet.

```text
Cél:
Egy saját, egyszerű publikációs felületet szeretnék AI-val közösen építeni.

Első verzió:
- olvasható kezdőoldal;
- cikkoldal;
- címkék;
- keresés;
- minimális admin;
- képek és letölthető fájlok csatolása.

Tilos most:
- nagy CMS-t építeni;
- dashboardot csinálni;
- marketinges landing page irányba vinni;
- felesleges frameworköt behozni;
- olyan funkciót hozzáadni, ami nem segíti az írást, olvasást vagy publikálást.

Design:
Sötét, nyugodt, editorial blog. Kevés kék akcentus. Sok whitespace. Nem portál.

Munkamód:
Először olvasd el a célokat, aztán javasolj szerkezetet. Kódot csak akkor írj, ha a scope már tiszta.
```

---

# Codex-ready project brief excerpt

Use this short pattern when you do not want to send one giant "build it all" prompt, but want to give the model a useful working frame.

```text
Goal:
I want to build a simple personal publishing surface together with AI.

First version:
- readable homepage;
- article page;
- tags;
- search;
- minimal admin;
- attached images and downloadable files.

Not now:
- do not build a large CMS;
- do not make it a dashboard;
- do not turn it into a marketing landing page;
- do not introduce unnecessary frameworks;
- do not add features that do not help writing, reading, or publishing.

Design:
Dark, calm, editorial blog. A few blue accents. Plenty of whitespace. Not a portal.

Working mode:
Read the goals first, then propose structure. Write code only when the scope is clear.
```

For me, two AI roles separated naturally. The browser-based ChatGPT became the conversation partner, critic, and prompt writer. Codex became the implementer working directly on the codebase. I sat between them with professional taste, decisions, impatience, occasional swearing, and that very old developer feeling: "this is not it yet".

The homepage intro animation needed roughly ten rounds before it became acceptable. And that perfectly shows why the myth of the one-prompt product is wrong.

An amateur often looks for the prompt that will finish an app, a web service, or an entire product. A professional sees immediately where the first generated version bleeds in a thousand places. The structure is wrong. The rhythm is off. There is too much decoration. There is too little content. It does not work on mobile. It animates the wrong thing. It builds a mockup instead of revealing the real DOM elements. The backend is not right yet. The admin wants to do too much. The content editor would produce messy HTML.

In the past, these were the points where many personal projects went sideways or stayed unfinished. Fixing, polishing, stripping back, and rebuilding is more boring than the first idea.

AI changed that.

Not because AI knows what is good instead of me. But because now there is someone to throw the details back to. Someone writes the next version. Someone rearranges the structure. Someone writes a prompt for the other model. Someone summarizes why the current state is bad. And someone does not get offended when I say: this is crap, let's start again.

That is what made the blog itself interesting. It is not only that it was built with AI. It is that the goal, the look, the engine, the admin, the editorial workflow, and now even the articles about it all come from the same method.

This blog writes itself. But not by removing me from it.

Quite the opposite.

It turns my experiences into articles. It starts from my projects. It has to work according to my taste. It has to survive my impatience. My professional history decides when an admin is good, when a feature is unnecessary, when a blog starts becoming a portal, and when we need to step back to a simpler solution.

AI is not the author instead of me in the sense that it invents who I am. It is more like an editorial partner. It asks, organizes, phrases, translates, criticizes, rewrites. It helps turn what I already know in my head into something publishable, something I probably would never write down this consistently on my own.

That is why this became the first article. Before I write about fegyvermarket.hu, the home infrastructure, or any other project I built with AI, it is worth explaining how the place where those articles will appear came into being.

The next part will be less about appearance. It will be about introducing the AuthHandler class and making the blog multilingual. Because after a while, the questions were no longer about whether the page looked good, but whether it behaved like a real product.