AI Coding Discipline — proč jsou strukturované prompty a kontrakty důležité

Správné nastavení AI

Vývoj s pomocí AI s sebou nese reálné, často nezodpovězené otázky: jak nastavit AI a jednotlivé agenty tak, aby vše fungovalo správně a nerozbilo kód a logiku, které už v projektu existují? Refaktoring nikdy nesmí porušit strukturu, která je v kódové bázi už zavedená.

Co je pro AI nejdůležitější

  • Přesný a podrobný prompt — čím jasněji je požadavek popsán, tím lépe je splněn.
  • Rozdělení práce na menší, granulární kroky s ověřením po každém z nich přináší lepší výsledky než jeden velký prompt.
  • Omezení halucinací — AI má tendenci zvolit nejbližší zvučící možnost podle klíčových slov, i když neodpovídá skutečnému požadavku.
  • Vložení byznys logiky a explicitních omezení typu "co se nesmí rozbít" do promptu přináší lepší výsledky než prompt doplněný jen o unit testy.
  • Unit, integrační a end-to-end testy existují proto, aby potvrdily, že daná změna nerozbila funkčnost mimo rozsah zadaného tasku.

Co AITM přidává navíc oproti běžnému AI agentovi

  • Kontrakty, DOM prvky, behaviorální řetězce a popisy byznys logiky, ke kterým běžný AI agent přístup nemá.
  • Tasky vytvořené z Chatu nebo Brainstormu využívají kontrakty, dokumentaci a behaviorální byznys logiku k rychlému nalezení částí kódu, které se nesmí změnit, a relevantní byznys logiku vloží do promptu ještě dřív, než se AI čehokoliv dotkne — výsledkem je prompt přesně ušitý AI na míru, s minimem halucinací a nejlepší možnou implementací.
  • Prompty také dostávají skills a konkrétní kontrakty, díky čemuž lze task přesně navést na existující coding patterny a existující byznys logiku, což zlepšuje, jak dobře změna zapadne do stávajícího kódu.
  • Každý pipeline task je generován podle typu požadavku — Bug, Enhancement nebo Feature — a v pipeline je pro každý typ odlišně provedený a ověřený, což udržuje konzistentně vysokou kvalitu kódu.
  • Velké požadavky se rozdělují na menší, na sobě závislé tasky, které na sebe navazují; poslední task v řetězci ověří, že všechny byly vytvořeny správně a přesně.
  • Velké nebo nelogické změny zastaví task a vyžadují potvrzení člověkem (nebo silnějším modelem), že je změna skutečně správná, než může pokračovat.
  • Krok Architect zjistí, co a kde se změní, prohlédne metriky code-coverage a přesně zapíše, co se děje — nic víc, nic spekulativního.