AI Project Memory pod kapotou: technická prípadová štúdia

Ako kontrolujem zdroje, kde zapájam model, čo som opravovala pri vysokej spotrebe tokenov a ktoré limity zostávajú otvorené.

Táto časť ide hlbšie do architektúry systému. Zachytáva konkrétne poradie kontrol, hranice medzi modelom a pevnými pravidlami aj veci, ktoré stále nepovažujem za uzavreté.

Základom je spoločný priečinok s textovými súbormi, ktorých zmeny sleduje Git. Git tu funguje ako história: ukáže, čo sa zmenilo, kedy a kým. Markdown je jednoduchý spôsob zápisu textu pomocou nadpisov, odrážok a tabuliek.

Čo v systéme robia jednotlivé nástroje

Dashboard ako downstream vrstva

Po pôvodnej implementácii pribudla nad PM systémom ešte jedna vrstva: lokálny read-only dashboard.

Dashboard nie je súčasťou ranného alebo večerného rozhodovacieho cyklu. Pracuje až s jeho výstupmi a s operatívnymi dátami z BEXPERA Google Sheetu.

ZDROJOVÉ PROJEKTY
        ↓
PM KONTROLY + AI INTERPRETÁCIA
        ↓
PROJECT / PORTFOLIO MEMORY
        ↓
        ├──────────────┐
        │              │
        │         GOOGLE SHEET
        │              │
        └───────┬──────┘
                ↓
       READ-ONLY DASHBOARD

Dashboard pri otvorení nevolá jazykový model. Z existujúcich zdrojov vytvorí snapshot, spojí súvisiace tasky, preverí kvalitu dát a vykreslí výsledok.

Tým zostáva oddelená vrstva, ktorá potrebuje AI interpretáciu, od vrstvy, ktorá už pracuje s existujúcim stavom.

Od zmeny v projekte k rannému prehľadu

Ranná a večerná kontrola má presné poradie.

1Kontrola najprv preverí zdroje

Skript prejde register projektov a pri každom vyhodnotí jeden z troch stavov:

• Updated – aktualizované,
• Confirmed no change – potvrdené bez zmeny,
• Needs confirmation – treba potvrdiť.

Táto kontrola nepoužíva jazykový model. Sleduje čas zmien, dostupnosť zdroja a konkrétne umiestnenie nových súborov. Nerozumie ich významu. Pomáha však potvrdiť, že žiadny registrovaný projekt nevypadol, a zúži množstvo podkladov, ktoré musí AI interpretovať.

2Model dostane presne vymedzený kontext

Ak je projekt potvrdený bez zmeny, AI ho znovu detailne nečíta. Pri stave Updated alebo Needs confirmation dostane konkrétne zmenené súbory a súvisiace aktívne úlohy.

Súčasná verzia systému vytvorí jeden presne vymedzený balík podkladov. Obsahuje register projektov, zoznam dôkazov, predchádzajúci súhrn, chránený obsah od iného nástroja, súvisiace úlohy a zmenené súbory.

Predtým sa tie isté podklady otvárali v niekoľkých kolách. Model opakovane čítal pokyny, celý register úloh a príliš širokú históriu. Výstup bol podobný, cesta k nemu bola drahšia a menej predvídateľná.

3Vznikne rozpracovaný kontrolný záznam

Po kontrole zdrojov sa vytvorí záznam so stavom Pending, teda rozpracované.

Zachytáva jeden ranný alebo večerný beh: kontrolované obdobie, spôsob spustenia, vykonávateľa a jeden riadok pre každý projekt. Vďaka tomu si viem overiť, že sa na nič nezabudlo.

Záznam má aj ochrannú funkciu. Ak ďalšia kontrola uvidí čerstvý rozpracovaný beh, skončí bez nového spustenia AI. Dve automatizácie tak nezačnú naraz vyrábať ten istý súhrn.

4Kontrola podľa pevných pravidiel overí dôkazy

Pred aktualizáciou spoločného prehľadu sa kontroluje napríklad:

• či kontrolný záznam existuje,
• či má všetky povinné údaje,
• či má každý projekt práve jeden riadok,
• či sú pomenované medzery v dôkazoch,
• či zostal zachovaný obsah patriaci inému nástroju.

Ak táto brána neprejde, aktuálny prehľad sa nezmení. Pre mňa je to dôležité. Nechcem otvoriť súhrn, ktorý pôsobí aktuálne, keď kontrola podkladov zlyhala.

5Model vytvorí rozhodovací pohľad

Až po úspešnej kontrole model interpretuje zmeny naprieč projektmi. Pripraví ranný alebo večerný pohľad a záverečná kontrola podľa pevných pravidiel preverí povinné časti, ich poradie a dokončenie procesu.

Nasledujúci beh potom pokračuje od posledného potvrdeného kontrolného bodu.

Prvá verzia fungovala, ale spotrebovala priveľa tokenov

Toto bol jeden z momentov, pri ktorých mi došlo, že funkčný AI workflow ešte nemusí byť dobrý workflow.

Prvé verzie ranných a večerných kontrol vedeli vytvoriť použiteľný prehľad. Cesta k nemu však spotrebovala viac tokenov, než dávalo zmysel. Model opakovane čítal pracovné pokyny, celý register úloh, staré stavy a príliš širokú históriu zmien. Niekedy znovu otváral podklady, ktoré už raz dostal.

Ďalší problém bol v tom, čo systém považoval za zmenu. Kontrolný skript zachytával aj vlastné manažérske výstupy, pomocné súbory, zostavenia webu alebo výsledky testov v prehliadači. Projekt tak mohol vyzerať ako aktualizovaný len preto, že predchádzajúci beh vytvoril súhrn.

Pravidelné kontroly sa navyše mohli prekrývať so záložnou obnovou pomocou AI. Dva procesy potom čítali podobný kontext a pripravovali podobný výsledok.

Postupne som preto upravila niekoľko vecí:

• skript najprv preverí všetky projekty a model detailne číta iba Updated alebo Needs confirmation,
• povolené podklady sa spoja do jedného presne vymedzeného balíka,
• odvodené výstupy, buildy, knižnice a testovacie súbory sa z kontroly vylúčia,
• druhé kontroly zdrojov, široké opakované čítanie a slučky s ďalšími pokusmi sú zakázané,
• ranný a večerný cyklus používajú úspornejší model a nastavenie,
• opakovaná záložná obnova pomocou AI je pozastavená,
• zostala hodinová kontrola, ktorá vie rozhodnúť bez spustenia modelu.

Za mňa je najužitočnejšia tá posledná hranica. Najúspornejší beh AI je ten, ktorý sa nemusí spustiť.

Kontrola v počítači vie pred spustením modelu zistiť, že:

• dnešný kontrolný záznam je kompletný,
• plánovaný cyklus ešte beží,
• rozpracovaný záznam je mladší než 90 minút,
• systém je stále v ochrannom časovom okne,
• nie je dostupná sieť,
• rovnakú obnovu už vykonáva iný proces.

V týchto prípadoch sa model nespustí.

Je tu jedno dôležité upresnenie. Pravidelný cyklus o 08:00 alebo 18:00 už začína ako automatizácia s AI. Skript v ňom znižuje rozsah čítania, no neodstráni prvé spustenie modelu. Úplné vynechanie AI funguje iba tam, kde sa kontrola vykoná ešte pred jej spustením.

Presnú percentuálnu úsporu zatiaľ neuvádzam. Architektonická zmena je overená, finančný výsledok ešte meriam.

Od návrhu AI k hlavnej evidovanej úlohe

Druhá vetva systému rieši úlohy z Fireflies, priameho chatu, Codexu, Claude Code, kontroly alebo manuálneho vstupu.

Keď každý nástroj zapisuje priamo do hlavného zoznamu, ľahko vzniknú paralelné úlohy, kolízie identifikátorov a zmeny stavu bez jasného dôvodu. Preto má tento postup štyri kroky.

Príjem návrhu

Fireflies GPT zapisuje do vlastnej časti Fireflies Input. Návrhy z chatu smerujú po potvrdení do Intake & Review, teda na príjem a kontrolu.

Vstup obsahuje zdroj, navrhovanú zmenu, prípadný identifikátor úlohy, dôkaz, mieru istoty a stav kontroly. Hlavná úloha sa v tejto chvíli ešte nemení.

Kontrola rovnakých úloh

Systém porovná návrh s existujúcimi úlohami cez presný identifikátor, rovnaký názov v projekte, rovnaký zdroj a výsledok a napokon významovo rovnaký cieľ.

Model pomáha najmä pri poslednom bode: dokáže upozorniť na rovnakú úlohu napísanú inými slovami. Možnú duplicitu zapíše do Dedupe Review, teda na kontrolu duplicít. Počas hľadania nič nemaže ani nezlučuje.

Schválenie a zápis

Človek môže návrh zlúčiť s existujúcou úlohou, aktualizovať ju, ponechať obe s jasnejším rozsahom, označiť novší riadok ako duplicitu alebo si vyžiadať ďalšie potvrdenie.

Zodpovedná osoba, priorita, hlavný stav alebo termín sa nezmenia iba preto, že to navrhol model.

Až vykonávací krok zmení hlavnú evidovanú úlohu. Pri zapísaní schválenej zmeny sa uloží pôvodná aj nová hodnota, zdroj a schválenie. Tým sa zachová správnosť a konzistentnosť záznamov aj história rozhodnutí.

V jednom reálnom prípade som našla viac významov pod identifikátorom T-038 a duplicitný riadok pre rovnakú webovú prácu. Schválené zlúčenie zachovalo starší identifikátor. Historický riadok sa nevymazal a nesúvisiaca úloha s kolíziou dostala nový identifikátor.

Výsledkom bolo menej nejasností bez straty histórie.

Kde používam model a kde pevné pravidlá

Pomáha mi jednoduchá otázka: potrebuje tento krok porozumieť významu, alebo iba overiť jasne určené pravidlo?

Jazykový model používam na interpretáciu rôznych dôkazov, rozlíšenie výsledku a prekážky, prípravu súhrnu, významové porovnávanie úloh a návrh priorít.

Pevné pravidlá používam na kontrolu pokrytia všetkých projektov, povinných údajov, počtu a poradia sekcií, stabilných identifikátorov a histórie zmien.

Model dostane význam a priestor na úsudok. Kód drží hranice a konzistentnosť. Človek zostáva pri rozhodnutiach, ktoré menia platný stav.

Kde vzniká praktická hodnota

Keď sa na jednotlivé časti pozerám samostatne, každá môže pôsobiť ako malá administratívna vrstva. Ich hodnota sa ukáže až pri spojení viacerých projektov a nástrojov.

Systém mi pomáha:

• obmedziť opakované čítanie projektov, v ktorých sa nič nezmenilo,
• znížiť riziko, že si rovnakú úlohu zapíšem viackrát,
• oddeliť potvrdenú zmenu od nového návrhu,
• zachytiť projekt, pri ktorom chýba dôkaz alebo rozhodnutie,
• zachovať výstupy viacerých AI nástrojov bez tichého prepísania,
• pokračovať od posledného potvrdeného kontrolného bodu,
• spätne pochopiť, prečo sa stav alebo úloha zmenili.

Najviac to dáva zmysel vtedy, keď človek alebo tím drží viac paralelných projektov, používa viac AI nástrojov a potrebuje sa vracať k úlohám, ktoré trvajú dlhšie než jeden chat.

Pri jednom krátkom projekte by bol celý setup príliš ťažký. Tam by som zostala pri jednom hlavnom zozname úloh, jednoduchom pracovnom zázname a jasnom pravidle, kto môže meniť stav.

Čo systém stále nevyriešil

AI Project Memory používam pri pravidelných PM cykloch, stále však má limity.

Kontrolný záznam potvrdí zahrnutie projektov a správny formát. Nezaručí, že model každý dôkaz pochopil správne. Ľudské schválenie chráni citlivé zmeny, zároveň pridáva čakanie.

Porovnávanie významovo podobných úloh zostáva úsudkovou prácou. Potrebujem merať prípady, keď AI spojí dve odlišné úlohy, prehliadne skutočnú duplicitu alebo človek zmení jej odporúčanie.

Ochrana hlavných záznamov je dnes z veľkej časti procesná. Produkčná verzia by mala mať oddelené účty a technické oprávnenia pre navrhovanie, schvaľovanie a zapisovanie zmien.

Otvorená zostáva aj presná úspora nákladov a plne automatická obnova so spoľahlivým vzdialeným ukladaním histórie.

Tieto limity mi pomáhajú odlíšiť fungujúci osobný pracovný systém od predstavy úplne autonómneho riadenia projektov.

Čo som upravila po prvých behoch

Prvé použiteľné prehľady ešte neznamenali, že mám hotový systém. Pri opakovaných PM cykloch sa ukázali tri konkrétne problémy: model čítal aj projekty bez relevantnej zmeny, výstupy predchádzajúcej kontroly sa mohli znovu dostať do vstupu a pri návrhoch bolo potrebné jasnejšie odlíšiť nový návrh od potvrdeného stavu.

Preto dnes pevné kontroly najprv určia, ktoré projekty sa zmenili a či pri niektorom nechýba zdroj. Model interpretuje iba relevantné podklady. Zápis priority, ownera, termínu alebo hlavného stavu čaká na ľudské potvrdenie.

Tento setup obmedzuje zbytočné čítanie a nedovolí návrhu automaticky zmeniť platný stav. Neviem ešte tvrdiť, koľko systém šetrí nákladov ani aká je jeho chybovosť. Tieto metriky zatiaľ nemám zmerané.