Ako pristupovať k vývoju s AI agentmi
Kontrola nad výstupom, človek ako architekt a tester, a skill, ktorý agenta donúti najprv vysvetliť návrh a až potom písať kód.
Myslím si, že panuje množstvo názorov na to, ako správne využívať agentov pri vývoji. V tomto článku sa s vami podelím o svoj prístup. Pravdepodobne sa bude od názorov ostatných líšiť, hlavné myšlienky však budú určite veľmi podobné.
1. Ako mať kontrolu nad tým, čo agent vytvorí
Myslím si, že základom správneho využitia agentov vo vývoji je kontrola nad výstupom. Nemusíme poznať každý riadok kódu. Mali by sme ale poznať každé architektonické rozhodnutie a rozumieť mu.
Je v tom podstatný rozdiel. Riadok kódu sa dá prepísať za minútu a väčšinou na ňom nezáleží. Architektonické rozhodnutie sa vám vráti o pol roka, keď už nikto nevie, prečo to tak je — a prepísať sa nedá za minútu, ale za týždne.
2. Akú rolu má človek vo vývoji s AI agentmi
Podľa môjho názoru musí byť človek vo vývoji s agentmi predovšetkým architekt, UX dizajnér a tester. Samozrejme aj v týchto rolách môže AI človeku pomáhať — ale človek tu musí vykonávať značnú časť úsilia pri kontrole.
To je tá časť, ktorá sa nedá delegovať. Agent vám napíše kód, ktorý funguje. Či je to ten správny kód na tom správnom mieste, a či to, čo ste zadali, bola vôbec dobrá vec — to zostáva na vás.
3. Ako napísať skill pre Claude Code, ktorý vynúti návrh
Z vlastnej skúsenosti odporúčam vytvoriť si skill, v ktorom agentovi oznámite, že pred akoukoľvek implementáciou vám musí najprv vysvetliť zvolené architektonické kroky — a to v podobe vopred definovanej štruktúry vnútri Markdown súboru.
Spomeňte agentovi, nech hojne využíva mermaid diagramy, príklady a grafy. Diagram odhalí nezmysel, ktorý sa v súvislom texte dobre schová: keď vám agent nakreslí tok dát a dva komponenty spolu hovoria obojsmerne, je to vidieť na prvý pohľad.
Tento skill môže vyzerať napríklad nasledovne:
.claude/skills/it-analysis/SKILL.md
---
name: it-analysis
description: Spracuj IT analýzu
---
# IT analytik
Si seniorný IT analytik. Špecializuješ sa na IT analýzy IT systémov + ich architektúru.
## Workflow
1. **Pochop čo máš riešiť** — Pochop zadanie a zamysli sa nad ním. Ako to riešiť? aké sú varianty riešenia? Edge cases?
2. **Spracuj analýzu podľa šablóny template.md**
3. **Ak sú odpovede na existujúce otázky** - Prepracuj analýzu na základe odpovedí na otvorené otázky. Otvorené otázky a odpovede nemaž, nechaj pôvodné. Môžeš doplniť ďalšie otázky. Na koniec analýzy daj prehľad zmien (changelog).
## Rules
- Výstup musí byť podľa šablóny `template.md`.claude/skills/it-analysis/template.md
# Šablóna pre tvorbu analýz
## Obsah
1. [Architektúra](#1-architektura)
2. [Databáza](#2-databaza)
3. [Backend](#3-backend)
4. [Frontend](#4-frontend)
5. [Riziká implementácie](#5-rizika-implementacie)
6. [Otvorené otázky na rozhodnutie](#6-otvorene-otazky-na-rozhodnutie)
## 1) Architektúra
V tejto časti bude rozobratá navrhnutá architektúra implementovanej funkcie. Súčasne bude rozobraté, akým spôsobom bude zmenená existujúca architektúra + napojenie na existujúcu architektúru. Žiaduce sú vhodné UML diagramy v mermaid.
## 2) Databáza
V tejto časti bude rozobratý navrhnutý databázový model cez ER diagram. Súčasne budú rozobraté zmeny existujúceho databázového modelu + napojenie na existujúci DB model. Žiaduce sú ER diagramy.
## 3) Backend
Tu budú v podobe bodového zoznamu rozobraté dopady na backend - teda čo sa bude musieť na backende pridať / zmazať / upraviť.
## 4) Frontend
Tu budú v podobe bodového zoznamu rozobraté dopady na frontend - teda čo sa bude musieť na frontende pridať / zmazať / upraviť.
## 6) Otvorené otázky na rozhodnutie
Očíslovaný zoznam s otázkami na rozhodnutie. Každý bod zoznamu bude vyzerať takto:
- **Deskriptívny názov otázky**: Detailný text otázky, z ktorého musím byť schopný pochopiť, na čo sa pýtaš.
`Odpoveď`: Text odpovede, prípadne `-` ak doposiaľ nie je žiadna odpoveď.4. Prečo nechať agenta najprv navrhnúť riešenie
Na základe tohto skillu si vždy najprv necháte navrhnúť riešenie, ktoré vždy najprv schválite. Samozrejme je nutné si výstup podľa tohto skillu poriadne skontrolovať, ale ten výstup určite stojí za to.
Navyše je podľa môjho názoru dôležité týmto zásadným otázkam rozumieť aj napriek tomu, že vlastný kód píše agent. Je to tá jediná časť, v ktorej sa rozhoduje o tom, či bude projekt o rok ešte na niečo.
Oddiel s otvorenými otázkami v šablóne je tam práve preto. Agent má sklon si nejednoznačnosti vyriešiť sám a mlčky — a vy sa o tom dozviete, až keď je kód hotový. Keď ho prinútite otázky vypísať, dostanete ich skôr, než na nich niečo stojí.
5. Ako s agentom prebrať návrh, ktorému nerozumiete
Ak si niektorými časťami dokumentu nie ste istí, nebojte sa ich iteratívne diskutovať s agentom. Vďaka komunikácii s ním lepšie pochopíte navrhnuté riešenie a pomôže vám to v dodávke kvalitného produktu.
Stojí za to si všimnúť, že táto diskusia má aj druhý efekt. Keď sa na niečo opýtate a odpoveď nedáva zmysel, väčšinou to nie je tým, že by ste to nepochopili — ale tým, že návrh je chybný. Vlastná neistota je slušný detektor problémov.
6. Prečo k AI agentovi pristupovať ako k juniorovi
Podľa môjho názoru by sme k AI agentovi mali vždy pristupovať ako k juniorovi na určitej pozícii — tej pozícii, ktorú ho práve necháme vykonávať.
Juniorovi zadáte prácu, necháte si vysvetliť, ako ju chce urobiť, a výsledok skontrolujete. Nedáte mu rozhodnutia, ktoré sa zle vracajú, a nenecháte ho pracovať týždeň bez obzretia. Zároveň mu ale nestojíte za chrbtom pri každom riadku, lebo potom by ste si to rovno urobili sami.
Presne tak sa mi osvedčilo pracovať aj s agentom.
7. Zhrnutie: tri pravidlá pre vývoj s agentmi
Tento spôsob sa mi osobne zatiaľ najviac osvedčil. Zhrnul by som ho do troch viet: poznajte každé architektonické rozhodnutie, nechajte si ho vysvetliť skôr, než vznikne kód, a pýtajte sa na všetko, čomu nerozumiete.
Máte na to iný názor? Napíšte na support@coden-app.com.