Jak přistupovat k vývoji s AI agenty
Kontrola nad výstupem, člověk jako architekt a tester, a skill, který agenta donutí nejdřív vysvětlit návrh a teprve pak psát kód.
Myslím si, že panuje spousta názorů na to, jak správně využívat agenty při vývoji. V tomto článku se s vámi podělím o svůj přístup. Pravděpodobně se bude od názorů ostatních lišit, hlavní myšlenky ale budou jistě velice podobné.
1. Jak mít kontrolu nad tím, co agent vytvoří
Myslím si, že základem správného využití agentů ve vývoji je kontrola nad výstupem. Nemusíme znát každý řádek kódu. Měli bychom ale znát každé architektonické rozhodnutí a rozumět mu.
Je v tom podstatný rozdíl. Řádek kódu se dá přepsat za minutu a většinou na něm nezáleží. Architektonické rozhodnutí se vám vrátí za půl roku, kdy už nikdo neví, proč to tak je — a přepsat se nedá za minutu, ale za týdny.
2. Jakou roli má člověk ve vývoji s AI agenty
Dle mého názoru musí být člověk ve vývoji s agenty především architekt, UX designér a tester. Samozřejmě i v těchto rolích může AI člověku pomáhat — ale člověk zde musí vykonávat značnou část úsilí při kontrole.
To je ta část, která se nedá delegovat. Agent vám napíše kód, který funguje. Jestli je to ten správný kód na tom správném místě, a jestli to, co jste zadali, byla vůbec dobrá věc — to zůstává na vás.
3. Jak napsat skill pro Claude Code, který vynutí návrh
Z vlastní zkušenosti doporučuji vytvořit si skill, ve kterém agentovi sdělíte, že před jakoukoli implementací vám musí nejprve vysvětlit volené architektonické kroky — a to v podobě předem definované struktury uvnitř Markdown souboru.
Zmiňte agentovi, ať hojně využívá mermaid diagramy, příklady a grafy. Diagram odhalí nesmysl, který se v souvislém textu dobře schová: když vám agent nakreslí tok dat a dvě komponenty spolu mluví obousměrně, je to vidět na první pohled.
Tento skill může vypadat například následovně:
.claude/skills/it-analysis/SKILL.md
---
name: it-analysis
description: Zpracuj IT analýzu
---
# IT analytik
Jsi seniorní IT analytik. Specializuješ se na IT analýzy IT systémů + jejich architekturu.
## Workflow
1. **Pochop co máš řešit** — Pochop zadání a zamysli se nad ním. Jak to řešit? jaké jsou varianty řešení? Edge cases?
2. **Zpracuj analýzu dle šablony template.md**
3. **Pokud jsou odpovědi na existující otázky** - Přepracuj analýzu na základě odpovědí na otevřené otázky. Otevřené otázky a odpovědi nemaž, nech původní. Můžeš doplnit další otázky. Na konec analýzy dej přehled změn (changelog).
## Rules
- Výstup musí být dle šablony `template.md`.claude/skills/it-analysis/template.md
# Šablona pro tvorbu analýz
## Obsah
1. [Architektura](#1-architektura)
2. [Databáze](#2-databaze)
3. [Backend](#3-Backend)
4. [Frontend](#4-frontend)
5. [Rizika implementace](#6-rizika-implementace)
6. [Otevřené otázky k rozhodnutí](#6-otevřené-otázky-k-rozhodnutí)
## 1) Architektura
V této části bude rozebrána navržená architektura implementované funkce. Současně bude rozebráno, jakým způsobem bude změněna stávající architektura + napojení na stávající architekturu. Žádoucí jsou vhodné UML diagramy v marmaid.
## 2) Databáze
V této části bude rozebrán navržený databázový model skrze ER diagram. Současně budou rozebrány změny stávajícího databázového modelu + napojení na stávající DB model. Žádoucí jsou ER diagramy.
## 3) Backend
Zde budou v podobě bodového seznamu rozebrány dopady na backend - tedy co se bude muset na backendu přidat / smazat / upravit.
## 4) Frontend
Zde budou v podobě bodového seznamu rozebrány dopady na frontend - tedy co se bude muset na frontendu přidat / smazat / upravit.
## 6) Otevřené otázky k rozhodnutí
Očíslovaný seznam s otázkami k rozhodnutí. Každý bod seznamu bude vypadat takto:
- **Deskriptivní název otázky**: Detailní text otázky, ze kterého musím být shopný pochopit, na co se ptáš.
`Odpověd`: Text odpovědi, případně `-` pokud doposud není žádná odpověd.4. Proč nechat agenta nejdřív navrhnout řešení
Na základě tohoto skillu si vždy nejprve necháte navrhnout řešení, které vždy nejprve schválíte. Samozřejmě je nutno si výstup dle tohoto skillu pořádně zkontrolovat, ale ten výstup určitě stojí za to.
Navíc je dle mého názoru důležité těmto zásadním otázkám rozumět i přesto, že vlastní kód píše agent. Je to ta jediná část, ve které se rozhoduje o tom, jestli bude projekt za rok ještě k něčemu.
Oddíl s otevřenými otázkami v šabloně je tam právě proto. Agent má sklon si nejednoznačnosti vyřešit sám a mlčky — a vy se o tom dozvíte, až když je kód hotový. Když ho přinutíte otázky vypsat, dostanete je dřív, než na nich něco stojí.
5. Jak s agentem probrat návrh, kterému nerozumíte
Pokud si některými částmi dokumentu nejste jistí, nebojte se je iterativně diskutovat s agentem. Díky komunikaci s ním lépe pochopíte navržené řešení a pomůže vám to v dodávce kvalitního produktu.
Stojí za to si všimnout, že tahle diskuze má i druhý efekt. Když se na něco zeptáte a odpověď nedává smysl, většinou to není tím, že byste to nepochopili — ale tím, že návrh je vadný. Vlastní nejistota je slušný detektor problémů.
6. Proč k AI agentovi přistupovat jako k juniorovi
Dle mého názoru bychom k AI agentovi měli vždy přistupovat jako k juniorovi na určité pozici — té pozici, kterou ho zrovna necháváme vykonávat.
Juniorovi zadáte práci, necháte si vysvětlit, jak ji chce udělat, a výsledek zkontrolujete. Nedáte mu rozhodnutí, která se špatně vracejí, a nenecháte ho pracovat týden bez ohlédnutí. Zároveň mu ale nestojíte za zády u každého řádku, protože pak byste si to rovnou udělali sami.
Přesně tak se mi osvědčilo pracovat i s agentem.
7. Shrnutí: tři pravidla pro vývoj s agenty
Tento způsob se mi osobně zatím nejvíce osvědčil. Shrnul bych ho do tří vět: znejte každé architektonické rozhodnutí, nechte si ho vysvětlit dřív, než vznikne kód, a ptejte se na všechno, čemu nerozumíte.
Máte na to jiný názor? Napište na support@coden-app.com.