↓Preskočiť na hlavný obsah
  1. Články/

PREPAIR Gate: Ako som si poskladal vlastný workflow pre vývoj s AI agentmi

·8 min
Chyba odhalená na papierovom pláne pred bránou vedúcou k hotovej stavbe
Obsah

Plánovací režim je dnes pri coding agentoch bežná vec. Agent nemusí po zadaní úlohy okamžite meniť súbory: môže najprv preskúmať projekt a navrhnúť postup. Pri práci s agentmi som si však postupne uvedomil, že samotný plán ešte nerieši jeden dôležitý problém.

Ten istý agent často preskúma projekt, vytvorí plán, implicitne posúdi jeho správnosť a po potvrdení ho aj implementuje. Medzi návrhom a zásahom do kódu síce vznikne prestávka, ale nie skutočne oddelená kontrola.

Začal som preto jednotlivé zodpovednosti oddeľovať. Najprv spresniť problém a pripraviť zadanie. Potom nechať coding agenta preskúmať reálny projekt a vytvoriť plán. Tento plán dať do samostatného AI kontextu, ktorého úlohou je hľadať chyby, nie návrh obhajovať. Pripomienky vrátiť autorovi plánu a až opravenú verziu ako človek schváliť na implementáciu.

Keď sa mi tento postup ustálil, dal som mu názov PREPAIR Gate.

Vlastný názov, nie nová univerzálna metodika #

PREPAIR Gate nie je etablovaný priemyselný štandard ani všeobecne uznávaná metodika. Je to môj pracovný názov pre konkrétne usporiadanie viacerých existujúcich princípov: plan-first development, prieskum codebase pred návrhom, critic agent, evaluator–optimizer, human-in-the-loop a approval gate.

Samotné stavebné prvky teda nie sú nové. Vlastné je ich spojenie do workflow, ktorý používam na oddelenie pochopenia problému, technického návrhu, kritiky návrhu a povolenia meniť kód.

Názov PREPAIR skladá jednotlivé fázy:

  • P — Problem refinement: spresnenie problému,
  • R — Requirements / Prompt: požiadavky a zadanie,
  • E — Exploration: prieskum projektu,
  • P — Plan: implementačný plán,
  • A — AI Review: nezávislá AI kontrola,
  • I — Iterate: zapracovanie pripomienok,
  • R — Ready: plán pripravený na implementáciu.

Za nimi nasleduje Gate: explicitné ľudské schválenie. Slovo Ready teda znamená ready for implementation, nie hotový release.

flowchart TD A["Spresnenie problému"] --> B["Požiadavky a prompt"] B --> C["Prieskum projektu"] C --> D["Implementačný plán"] D --> E["Nezávislý AI review"] E -->|"zásadné pripomienky"| F["Úprava plánu"] F --> E E -->|"bez zásadných problémov"| G["Ready for implementation"] G --> H{"Ľudský Gate"} H -->|"schválené"| I["Implementácia"] H -->|"vrátiť"| F I --> J["Testy, code review a release"]

Najprv problém, až potom prompt #

Prvá fáza ešte nepatrí do repository. Jej cieľom je zistiť, čo sa má v skutočnosti zmeniť.

Pri brainstormingu sa oddeľuje cieľ od prvého navrhovaného riešenia. Ujasňuje sa scope, správanie, ktoré musí zostať zachované, možné edge cases a otázky, pri ktorých musí rozhodnúť človek. Požiadavka „zablokovať pole vo formulári“ môže byť iba predčasným technickým opisom skutočného pravidla „po vystavení faktúry už nesmie byť možné zmeniť zákazníka“.

Z tohto spresnenia vznikne zadanie pre coding agenta. Kvalitný prompt vysvetlí cieľ, dôvod zmeny, obmedzenia a očakávaný výstup. Zároveň jasne povie, že agent zatiaľ nemá implementovať, ale preskúmať projekt a pripraviť plán.

Prompt by nemal bezdôvodne predpisovať konkrétne súbory či architektúru. To by bolo rozhodovanie podľa predstavy o projekte. Technický návrh má vzniknúť až po konfrontácii s jeho reálnym stavom.

Plán musí vychádzať z codebase #

Vo fáze Exploration coding agent hľadá, kde funkcionalita skutočne žije a ako zapadá do existujúceho systému. Sleduje použité patterns, podobné riešenia, modely, služby, controllery, komponenty, databázové väzby aj potenciálne vedľajšie účinky.

Je to rozdiel medzi všeobecne rozumným návrhom a návrhom vhodným pre konkrétny projekt.

Príbuzný prístup Research–Plan–Implement kladie rovnaký dôraz na samostatný prieskum pred plánovaním. HumanLayer pri opise advanced context engineeringu pre coding agentov uvádza aj experiment, v ktorom plán vytvorený bez výsledkov prieskumu smeroval k odlišnému zásahu než plán založený na skutočnom fungovaní codebase. PREPAIR Gate tento princíp preberá, ale nekončí pri vytvorení plánu.

Výstupom exploration je konkrétny implementačný plán: čo sa zmení, kde, prečo je zvolený daný prístup, v akom poradí budú kroky nasledovať a čo treba overiť. Plán nie je iba checklist súborov. Má zachytiť technické rozhodnutia, riziká, zachovávané správanie a testovacie scenáre.

Autor plánu nemá byť jeho jediným kritikom #

Kľúčovým rozdielom oproti obyčajnému plan mode je AI Review. Hotový plán dostane druhá AI rola v samostatnom kontexte. Jej úlohou nie je plán zdvorilo potvrdiť, ale porovnať ho s pôvodným problémom a hľadať dôvody, prečo môže zlyhať.

Reviewer sa pýta napríklad:

  • Pochopil autor plánu požiadavku správne?
  • Nevynechal inú cestu, ktorou možno rovnaké dáta zmeniť?
  • Nezavádza nové pravidlo iba v UI namiesto business vrstvy?
  • Neexistuje v projekte jednoduchšie alebo už zaužívané riešenie?
  • Nerozširuje plán scope bez dôvodu?
  • Aké okrajové prípady a regresie chýbajú?

Nejde iba o self-review v tom istom slede úvah. Reviewer má inú rolu, samostatné zadanie a čistý kontext zameraný na kritiku. Nemusí to byť iný model ani iný dodávateľ. Takáto „nezávislosť“ nie je matematická: druhý model môže zopakovať rovnaký omyl. Je však užitočnejšia než situácia, v ktorej sa autor plánu bez prerušenia stane aj jeho schvaľovateľom.

Tento mechanizmus sa podobá workflowu evaluator–optimizer, ktorý Anthropic opisuje ako slučku, v ktorej jeden model vytvára výstup a ďalší ho hodnotí a vracia spätnú väzbu. Podstatný nie je počet agentov, ale rozdielna úloha a možnosť návrh na základe kritiky zmeniť.

Review vytvára ďalšiu verziu, nie rozsudok #

Pripomienky sa vrátia coding agentovi, ktorý pripraví ďalšiu verziu plánu. Ak review odhalil zásadné nepochopenie, môže byť potrebný nový prieskum alebo rozhodnutie človeka. Ak našiel iba chýbajúce testy či edge cases, plán sa doplní.

Slučka môže vyzerať jednoducho:

Plan v1 → Review → Plan v2 → Review → Ready

Počet iterácií nie je cieľ ani metrika kvality. Pri jasnom probléme môže stačiť jedno kolo. Pri komplikovanej zmene môžu byť potrebné dve alebo tri. Iterovanie sa končí vtedy, keď ďalší review už neprináša zásadnú hodnotu, nie vtedy, keď sa dosiahne vopred určené číslo.

Aj všeobecné odporúčania pre agentové systémy upozorňujú, že viac rolí a modelových volaní prináša vyššiu réžiu. Google Cloud pri výbere agentových návrhových vzorov odporúča zohľadniť latenciu, cenu aj potrebu ľudského rozhodovania. PREPAIR Gate preto nemá zmysel mechanicky aplikovať na každú drobnú úpravu.

Gate: posledné slovo zostáva človeku #

Keď review neodhaľuje zásadné problémy, plán je Ready. Implementácia sa však ešte nespustí automaticky.

Človek skontroluje, či plán rieši správny problém, rešpektuje scope a zodpovedá business rozhodnutiam. Môže ho schváliť, zamietnuť alebo vrátiť na úpravu. Až schválenie otvorí Gate a dovolí coding agentovi meniť projekt.

Je to konkrétna podoba human-in-the-loop princípu. Súčasné agentové nástroje poznajú podobné technické mechanizmy: napríklad OpenAI Agents SDK dokáže vykonávanie pred vybraným nástrojovým volaním pozastaviť a pokračovať až po ľudskom schválení alebo zamietnutí. V PREPAIR Gate však brána nechráni iba jeden citlivý tool call. Oddeľuje celú plánovaciu fázu od zásahu do codebase.

Príklad: zákazník na vyfakturovanej objednávke #

Predstavme si požiadavku:

Po vystavení faktúry už používateľ nesmie na objednávke zmeniť zákazníka.

Coding agent môže pri povrchnom pohľade nájsť editovací formulár, zablokovať pole a doplniť validáciu controllera. Plán vyzerá rozumne, kým testovanie neodhalí, že zákazníka možno zmeniť aj cez API, import alebo inú administračnú obrazovku.

Exploration môže ukázať, že všetky vstupné cesty nakoniec používajú spoločnú business službu. Správny plán potom presunie pravidlo do jedného centrálneho miesta a jednotlivé UI upraví iba tak, aby používateľ dostal zrozumiteľnú spätnú väzbu.

Review AI môže navyše nájsť otázku, ktorú autor plánu nevyriešil: čo sa má stať po stornovaní faktúry alebo pri dobropise? To už nie je technický detail, ale business rozhodnutie pre človeka.

Na tomto príklade je vidieť rozdelenie rolí:

  • exploration našiel správne miesto zásahu,
  • review našiel chýbajúci prípad,
  • človek rozhodol o pravidle,
  • coding agent až potom dostal stabilný plán na implementáciu.

Chybu je lacnejšie opraviť v pláne #

Ak sa nesprávny predpoklad odhalí v pláne, často stačí prepísať niekoľko bodov, doplniť podmienku alebo zvoliť inú vrstvu systému. Diff stále neexistuje.

Po implementácii sa ten istý omyl môže rozšíriť do databázy, backendu, API, frontendu, testov, migrácií a dokumentácie. Oprava už neznamená zmenu jednej myšlienky, ale koordinovaný rework viacerých hotových častí. Navyše môže byť ťažšie priznať si, že zvolený smer je chybný, keď už doň bolo investované veľa práce.

PREPAIR Gate preto vedome platí malú cenu vopred: viac premýšľania, viac interakcií s AI a určitú latenciu. Ekonomický zmysel má tam, kde je táto réžia nižšia než pravdepodobná cena nesprávnej implementácie.

Kedy workflow použiť — a kedy nie #

Pri preklepe, izolovanej úprave textu alebo triviálnom bugfixe by celý proces mohol stáť viac než samotná oprava. V takom prípade stačí bežný plánovací režim, rýchla kontrola alebo priama implementácia s testom.

PREPAIR Gate má najväčší význam pri zmenách, ktoré:

  • zasahujú viac súborov alebo vrstiev,
  • menia business logiku,
  • majú viac vstupných ciest a edge cases,
  • ovplyvňujú architektúru alebo verejné API,
  • vznikajú v staršom či komplikovanom projekte,
  • môžu pri nesprávnom návrhu spôsobiť drahý rework.

Ani pri vhodnej úlohe nie je AI review zárukou správnosti. Modely môžu zdieľať rovnaké slepé miesta, reviewer môže pracovať s neúplným kontextom a človek môže schváliť chybný plán. Workflow znižuje určité riziká; neruší potrebu overovania.

Gate nie je release gate #

PREPAIR Gate rieši iba časť životného cyklu pred implementáciou. Po otvorení brány coding agent upraví kód, ale tým práca nekončí. Nasledovať môžu automatické testy, manuálne overenie, code review, ďalšia AI kontrola implementácie, opravy, refactoring, pull request, deployment a napokon release.

Správna skratka procesu preto nie je:

plán → schválenie → hotovo

ale:

plán → schválenie → implementácia → validácia → release

Oddeliť roly je dôležitejšie než pridať viac AI #

PREPAIR Gate som si neposkladal preto, aby som do vývoja pridal čo najviac agentov alebo krokov. Vznikol z potreby rozdeliť právomoci, ktoré sa v jednom agentickom procese ľahko zlejú: pochopiť problém, navrhnúť riešenie, posúdiť vlastný návrh a vykonať ho.

Názov je nový, väčšina princípov pod ním nie. Podstatné je ich poradie a oddelené role. Coding agent pozná codebase a pripraví technický plán. Review AI sa ho pokúsi spochybniť. Človek drží cieľ, scope a posledné rozhodnutie.

Výsledkom nemá byť dokonalý plán ani bezchybná implementácia. Cieľ je skromnejší a praktickejší: presunúť čo najviac chýb do fázy, v ktorej ešte existujú iba ako ľahko opraviteľné vety.

Zdroje a ďalšie čítanie #