Amikor a blogból szerkesztőségi rendszer lett

Az első részben arról volt szó, hogyan állt össze a blog kinézete és alapgondolata. Ez volt a látványos rész: a sötét editorial irány, a promptból épülő nyitó animáció, a "ne legyen portál" típusú visszaterelések.

De amikor egy ilyen projekt elkészül, jön a kellemetlenebb kérdés: oké, ott a hegy, felmásztunk rá, most akkor használni is kellene?

Oldschool vagyok ebben. Meg akarok valamit csinálni. Ott a hegy, fel akarok rá mászni. Nem feltétlenül az a cél, hogy legyen egy blog oldalam. A blog inkább apropó. Egy jól körülhatárolható feladat, amin keresztül ki lehet próbálni, hogy AI-val hogyan lehet ma már végigvinni valamit, amit pár éve még hónapokig pixelbasztam volna.

Csakhogy ha már megvan, akkor a rendszernek túl kell élnie a megépítés pillanatát. Ez volt a valódi probléma.

A probléma: Codex ne kerülje meg a rendszert

Az AI-val nagyon könnyű rossz irányba kényelmesnek lenni. Mondhatnám azt, hogy Codex írja be a cikket közvetlenül az adatbázisba. Vagy generáljon Markdown-fájlt. Vagy másolja be valahova a HTML-t. Egy-egy alkalommal mind működne.

Csak akkor nincs publikációs folyamat. Akkor van egy kódbázis, amit időnként megkerülünk.

Nekem pedig pont az volt a célom, hogy ha Codex szerkeszt, akkor ne a rendszer mögött matatva tegye. Ugyanazon a kapun menjen be, amin én is bemennék. Ha emberként az adminon keresztül publikálnék, akkor Codex is az adminon keresztül publikáljon.

Ezért lett az admin nem extra, hanem munkahatár.

A screenshoton látszik a lényeg: slug, státusz, publish date, tagek, featured image, magyar és angol mezők, article files panel, inline beszúrás. Ez nem világmegváltó CMS. Ez pont annyi admin, amennyi ahhoz kell, hogy egy cikk rendesen megszülessen.

Miért tudtam, milyen admin kell?

Azért, mert csináltam már ilyet eleget. Ott van például a fotel.hu, amire azért is büszke vagyok, mert GPT előtti időkből jön. Teljesen egyedi site, no framework, komoly szerkesztőségi rendszerrel, tagelt keresővel, videókkal, komplex tartalomkezeléssel. Egyedül csináltam azt is.

Ez nem önéletrajzi kitérő, hanem fontos kontextus. Nem találgatom, mitől használható egy admin. Tudom, milyen az, amikor egy HTML-alapú site összeáll, működik, aztán a threadek, tartalmak, állapotok és kivételek túlnövik azt, amit fejben még kényelmesen lehet követni.

Ez az a pont, ahol sok saját projekt megrogyik. Nem a frontend miatt. Nem is a backend miatt. Hanem azért, mert nincs rendes adminfolyamat. Nincs egyetlen hely, ahol látszik, mi a cikk állapota, milyen asset tartozik hozzá, mi publikus, mi félkész, mi hiányzik.

A döntés: ez csak egy blog, maradjon is az

A másik oldal legalább ilyen fontos: nem akartam nagy CMS-t. Ez egy szaros blog.

Cikkenként kell tudjon fogadni forrásanyagokat. Képet, Markdown-részletet, letölthető fájlt. Ezeket lehessen könnyen beszúrni a cikktörzsbe. A frontend CSS döntse el, hogyan néz ki a tartalom. Ne legyen cikkenként saját kis designvilág. Ne legyen site scope-on kívüli formázgatás.

Régebben, amikor saját kézzel építettem ilyen rendszereket, ezt még elegánsabban oldottam meg. Create pillanatában már létrejött egy tmp cikkállapot. Azonnal lehetett rá képet, fájlt, resource-t feltölteni. Ha abandon lett a vége, ment a reset. Ha tényleges create lett, a tmp állapot rendes cikké vált.

Itt elnéztem azt, hogy előbb menteni kell a cikket, és csak utána lehet rá referenciákat akasztani. Nem tökéletes, de elég jó. És ez fontos mondat: egy AI-val közösen épített saját eszköznél nem minden régi adminfilozófiai eleganciát kell elsőre visszaépíteni. Az számít, hogy a munkafolyamat ne hazudjon.

Két nyelv: nem adatmodell, hanem esély

A többnyelvűség mögött nem valami nagy architekturális okoskodás volt. Egyszerűbb a motiváció: ha véletlenül megtalálja a keresőmotor a site-ot, és angolul is értelmesen van megírva, nagyobb eséllyel adunk segítséget egy idegennek valahol a világban.

Az AI miatt ez már nem olyan teher, mint régen. De ettől még van benne kockázat. Fontos, hogy a magyar és az angol ne két külön életet éljen. Egy cikk van, két nyelvi változattal. Codexnek nem egy fájlt kell még valahova lefordítania, hanem ugyanabban az adminban kell kitöltenie a másik nyelvet is. Ha nincs meg mindkettő, nincs publikálás.

Ebből az olvasó azt tudja elvinni, hogy a többnyelvűséget nem fordítási feladatként érdemes kezelni, hanem publikációs szabályként. Ne az emlékezetedre bízd, hogy megvan-e a másik nyelv. A rendszer kérje számon.

AuthHandler: régi saját fegyver új helyen

Az AuthHandler nem ehhez a bloghoz született. Még a GPT-4.0 időkben írtam, amikor a fegyvermarketet kezdtem. Akkor akartam egy olyan autentikátor osztályt, amely önállóan képes provider auth-ot és jelszavas auth-ot kezelni, minden fontos körítéssel együtt: kódos vagy email linkes visszaigazolás, jelszó reset, jelszócsere, provider kapcsolat.

Ez még az a korszak volt, amikor a GPT weboldalról ment a copy-paste a VS Code-ba. És nem csak ezért volt nehezebb. A 4.0 több sebből vérzett. Kurvasokat kellett kézzel utána kódolni.

Viszont az AuthHandler bevált. Az volt vele a cél, hogy komplex webes szolgáltatásoknál ne kelljen újra és újra auth kezeléssel szopni. Egy osztálypéldányban legyen ott minden, amit a userről és a belépésről tudni kell, és ezt egy önálló modul kezelje elejétől a végéig.

A blogban ebből csak a provider-only rész kellett. Google és Facebook. Nem kell jelszavas publikus regisztráció. Nem kell profiloldal. Nem kell social network. Itt tényleg csak like és comment otthagyásához kell azonosítás. Kutya sem fogja használni soha, de működik. Megcsináltam, ahogy elképzeltem.

AuthHandler ott, ahol tényleg szükség van rá

A belépés nem külön felületként akar főszereplő lenni. A cikk alján jelenik meg, ahol a kedveléshez vagy hozzászóláshoz már tényleg kell azonosítás.

A user delete flow sem filozófiai kérdés volt. Amit a két nagy provider előír, azt végig kell vinni. Ha valaki törölni akarja magát, akkor a rendszer törölje vagy anonimizálja, amit kell. Nem azért, mert ettől lesz izgalmas a blog, hanem mert így korrekt.

Az AuthHandler önmagában is megér majd egy külön cikket, mert jó példa arra, mennyit változott az AI-val kódolás a 4.0 óta. Akkor még nagyon sok mindent kézzel kellett utánahúzni. Ma Codexszel már egészen más tempóban lehet egy ilyen modult bekötni, igazítani és termékbe rakni.

A kód közben kint van GitHubon is: sanch78/_AuthHandler. Így az AuthHandler nem csak belső hivatkozás, hanem megnézhető kiindulópont is ahhoz, hogyan érdemes egy saját auth modult külön kezelhető eszközként felépíteni.

Üzenetküldő: a mailto béna

Az üzenetküldőnél a probléma egyszerű volt: a mailto béna.

Persze működik. Csak megtöri az élményt. Kidob a levelezőbe, másik appba, másik kontextusba. Egy blognál, ahol az egésznek az a célja, hogy olvasás közben maradj a gondolatban, ez feleslegesen sutának érződik.

Ezért lett modal. Név, email, üzenet, mentés. Adminban lista. Nem CRM, nem ticket rendszer, nem support portal. Egy félmondatban el lehet mondani, hogyan szép és hogyan működik.

És persze ott a valódi üzleti use case is: ha valaki elhiszi, hogy kibaszott profi vagyok, és egymillió dollárt akar fizetni azért, hogy szakértsem meg, akkor én és Mini Me, vagyis Codex, megbatikoljuk mint a szél.

Amikor az üzenetküldő végre komoly megkeresést hoz

A contact form legoptimistább üzleti forgatókönyve: egymillió dolláros megkeresés, érdekes státusz, Codex készenlétben.

A viccet félretéve: az üzenetküldő tanulsága az, hogy egy kis funkció is lehet rendes, ha nem akar többnek látszani. Az olvasó írni tud. Én megkapom. Kész.

Subscription: szokásos kis izé, majd kiderül

A feliratkozásnál nincs nagy filozófia. Szokásos szar: email mező, validálás, aktív státusz, adminlista.

Meglepne, ha egy ember is feliratkozna. Ha majd lesz ilyen, rájövök, másnak miért van.

Ez így cinikusan hangzik, de van benne egy gyakorlati döntés. Nem kell hírlevél-platformot építeni, amíg nincs olvasói igény. Nem kell kampánygép, tracking, szegmentálás. Egyelőre elég annyi, hogy ha valaki mégis kéri, legyen hova eltárolni.

Ez megint ugyanaz a minta: ne építs nagy rendszert feltételezett igényre. Építs kicsi, tiszta fogadópontot, aztán ha az élet rátolja a forgalmat, bővíted.

A legfontosabb trükk: amikor a threadből dokumentáció lesz

Van még egy gondolat, ami írás közben állt össze, és szerintem fontosabb, mint bármelyik konkrét funkció.

Sokszor egy threadet csak úgy elkezdünk. Gyors kérdés, gyors megoldás, aztán egyszer csak kiderül, hogy ez hosszabb lesz. Ilyenkor nem az a jó következő lépés, hogy még több kódot kérünk. Hanem az, hogy a threadből átadható dokumentációt csináltatunk.

Az én promptom erre nagyjából így néz ki:

# 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.

Ez a módszer azért működik, mert az AI-val végzett munka egyik fő ellensége az elvesző kontextus. Egy hosszú threadben rengeteg döntés, félmondat, visszavonás és "ja, mégse úgy" él. Ha ebből nem lesz dokumentáció, a következő körben újra kell tanítani mindent.

Ha viszont a thread alapján készül README, célleírás, architektúra, workflow és tiltólista, akkor egy új thread már nem a sötétből indul. És Codex sem találja ki újra azt, amit egyszer már eldöntöttünk.

Mit lehet ebből lemásolni?

Ha valaki hasonlót akar csinálni, szerintem nem azzal kell kezdenie, hogy milyen frameworköt válasszon. Hanem ezekkel a kérdésekkel:

• Hol van a publikáció egyetlen hivatalos kapuja?
• Az AI ugyanazt a kaput használja, mint az ember?
• Mi az a minimális admin, ami már megakadályozza a szétesést?
• Milyen állapotokat kell a rendszernek számon kérnie?
• Melyik funkció valódi igény, és melyik csak CMS-nosztalgia?
• Mikor kell egy threadből dokumentációt csinálni, mielőtt tovább kódolunk?

Ez a cikk ezért nem arról szól, hogy "lettek extrák". Hanem arról, hogy a blog akkor kezdett használhatóvá válni, amikor a kényelmes kerülőutakat lezártuk.

Codex ne közvetlenül fájlokat piszkáljon. Ne adatbázist varázsoljon. Ne féloldalas Markdownokat gyártson. Használja az admint. Töltse ki a két nyelvet. Töltse fel az assetet. Illessze be a resource-ot. Publikáljon ugyanazon a rendszeren keresztül, amin én is publikálnék.

Onnantól nem csak blogot építettünk. Elkezdett kialakulni egy szerkesztőség.