Miért felejti el az AI kódoló ügynök a projektet? (És hogyan oldható meg)

Dolgoztál már AI-alapú kódszerkesztővel több napos projekten? Az első nap még remekül megy – felépíti az API-t, megírja a teszteket, dokumentál. Másnap viszont új beszélgetés indul, az ügynöknek fogalma sincs, hol tartottatok, és mindent újra el kell magyarázni. Néhány nap múlva már 70 ezer tokenes chat-történeteket böngészel, hogy előkerítsd a döntéseket.

A probléma nem csak a kontextusablak mérete. Hanem az, hogy rossz helyen tároljuk a projekt állapotát.

A chat-alapú emlékezet rejtett költségei

A chat kiváló eszköz az ember és az AI közötti együttműködésre. Projektadatbázisnak viszont gyenge.

Néhány gyakorlati probléma:

• A chat egyszer írható, sokszor olvasható. Ha egy döntés elsiklik, keresgélni kell.
• Nincs egységes igazságforrás. Az API specifikáció a harmadik vagy az ötödik beszélgetésben változott meg?
• Új ügynöknek nincs kontextusa. Minden beszélgetés kezdet nulláról indul.
• Az ellentmondások halmozódnak. Az egyik ügynök tesztstratégiát választ, a másik átírja az implementációt, a harmadik késznek jelöl valamit, ami még félkész.

A valódi szűk keresztmetszet nem az, hogy az ügynök tud-e kódot írni. Hanem az, hogy megérti-e, mit építünk és miért.

Az unalmas, de működő megoldás

Mi van, ha a projekt állapotát ugyanúgy kezeljük, mint a kódot? Vagyis verziókezelt fájlokban, a repóban tároljuk.

Nem wikit vagy külön projektmenedzsment eszközt használunk. Egyszerű, strukturált Markdown fájlokat készítünk, könnyű metaadat blokkokkal.

Példa:

# Architekturális döntés

Lifecycle: active
Role: spec
Project: payment-service
Updated: 2024-01-15

Related:
- implements: charter-payment-api
- pairs-with: implementation-log-payment-core

## Áttekintés

Stripe közvetlen API-ját használjuk wrapper library helyett, mert...

## Fontos döntések

- Idempotencia kulcsok minden művelethez
- Aszinkron webhook feldolgozás exponenciális visszahúzással
- PII sosem kerül helyi tárolóba

## Nyitott kérdések

- Gyorsítótárazzuk a rate limit állapotot?

Szándékosan egyszerű. Nincs speciális szintaxis, nincs adatbázis, nincs felesleges overhead. Csak:

• Cím
• Életciklus (aktív, kész, archivált)
• Szerepkör (specifikáció, napló, döntés, útmutató)
• Kapcsolatok más rekordokhoz
• Valódi tartalom

A varázslat nem a formátumban van, hanem abban, amit vele lehet csinálni. Egy CLI eszköz képes:

• Új rekordokat létrehozni egységes szerkezettel
• Kész elemeket archiválni törlés nélkül
• Rekordokat áthelyezni és automatikusan frissíteni a kapcsolataikat
• Szűrőkkel listázni a projekt összes elemét
• Ellenőrizni, hogy a kapcsolatok létező rekordokra mutatnak-e
• Automatikusan indexet generálni

Miért változtatja meg ez az AI munkafolyamatokat?

A lényeges változás az, hogy ahelyett, hogy egy friss ügynöknek azt mondanánk: „nézd át a chatet és értsd meg, hol tartunk”, egyszerűen egy CLI parancsot adunk neki.

docs list --project=payment-service --role=spec
docs list --lifecycle=active
docs check  # kapcsolatok ellenőrzése

Az ügynök így lekérdezheti a projekt állapotát ahelyett, hogy a beszélgetés történetéből ássa elő. Látja:

• Milyen döntések születtek
• Min dolgoznak éppen
• Mi blokkolt vagy várakozik
• Mely dokumentumok tekinthetők hitelesnek

Még fontosabb: az ügynök strukturált parancsokkal módosíthatja az állapotot, nem közvetlenül szerkeszti a fájlokat.

Ahelyett, hogy reménykednénk a helyes metaadat szerkesztésben, igéket adunk neki:

docs create --role=log "Rate limiting implementálva"
docs archive --record=spec-v2-deprecated
docs touch --record=spec-payment-api  # időbélyeg frissítése

Ezek a parancsok tartalmazzák a szabályokat. Az életciklus, a fájl helye, a kapcsolatok és az index egyszerre mozognak. Az ügynök nem tudja véletlenül elrontani a rendszert, mert az eszköz nem engedi.

A minta, ami kialakul: friss ügynök, ismert állapot

Ez hozza létre a „friss ügynök mintát”. Normál esetben új beszélgetés = kontextusvesztés. Strukturált állapot esetén:

1. Az ügynök új beszélgetéssel indul
2. Első lépés: docs list futtatása az aktív elemek megértéséhez
3. Látja a három kész mérföldkövet és az egy folyamatban lévőt
4. Elolvassa a tegnapi implementációs naplót
5. Ellenőrzi a specifikációt, hogy mit kell építenie

Nincs chat-ásás. Nincs döntések rekonstruálása. Csak: íme, mi történik, és mi a következő teendő.

A régi chat most már eldobható. Az állapot a repóban van, ahol lennie kell.

Hol számít ez igazán?

Érdemes megfontolni ezt a megközelítést, ha:

• AI páros programozási eszközökkel dolgozol többnapos projekteken
• AI ügynök munkafolyamatokat menedzselsz, amelyeknek folytatódniuk kell teljes kontextusátvitel nélkül
• CI/CD pipeline-okat futtatsz, amelyeknek ellenőrizniük kell a projekt koherenciáját
• Csapatban dolgozol, ahol közös megértésre van szükség a döntésekről és a nyitott kérdésekről
• Gyorsan iterálsz, és nehéz követni, hogy a jelenlegi specifikáció mit mond

Ez a minta nem helyettesíti a Git-et, a teszteket vagy a kód review-t. Inkább az a ragasztóréteg, ami koherenssé teszi az AI-támogatott fejlesztést az idő múlásával.

Az unalmas igazság

A megközelítés legjobb tulajdonsága, hogy mennyire unalmas. Nem új adatbázis-paradigmát találunk ki. Nem speciális IDE-t építünk. Egyszerűen a már ismert eszközöket (Markdown, Git, CLI) használjuk arra, amire valójában jók.

A szélsőséges esetek igazolják a koncepciót. Véletlenül elront egy kapcsolatot? A validáció elkapja. Lekési egy archivált rekordot? A list parancs megmutatja. Két munkamenet között elcsúszik az állapot? Az index a szerződés – vagy érvényes, vagy nem.

Ez az a fajta infrastruktúra, ami visszatekintve nyilvánvalónak tűnik. Mégis ez választja el azt, hogy „az ügynök valahogy működött” attól, hogy „az ügynök megértette a projektet és leszállította”.