AI agenti vývojářským týmům pomáhají, když přebírají úzce vymezené, opakující se úlohy, jako je první kolo revize kódu, kostry testů nebo rutina kolem vydání, s omezenými nástroji a s člověkem, který schvaluje každou změnu. Nechte je před akcí ukázat plán, logujte každé volání nástroje, přebírejte jejich práci jako diffy a před rozšířením jejich působnosti je otestujte na skutečných příkladech z vlastní historie.
Začněte úlohami, které se opakují, dají se ověřit a nesou malé riziko
Nejlepší první úlohy pro agenta jsou ty, které váš tým už každý týden dělá stejným způsobem a umí rychle ověřit. Pokud vývojář do minuty nepozná, zda je výstup správně, agent práci s kontrolou přidává, místo aby ji ušetřil.
Změny produkčních dat, změny infrastruktury a vše nevratné odložte, dokud se agent neosvědčí na bezpečnější práci.
- První kolo revize pull requestů: chybějící testy, rizikové vzory, nejasné názvy, problémy se stylem
- Generování testů pro existující funkce, hlavně testů hraničních případů a regresních testů pro opravené chyby
- Pull requesty s aktualizacemi závislostí a se shrnutím každého changelogu
- Poznámky k vydání sestavené ze sloučených pull requestů
- Třídění neúspěšných běhů CI: seskupení chyb a označení pravděpodobného commitu
Zvolte správnou vrstvu: API modelu, agentní framework, nebo nástroj pro workflow
Na jednu jasně vymezenou úlohu stačí přímá volání API OpenAI nebo Anthropic Claude s použitím nástrojů (tool use). LangChain přidává integrace a běžné stavební bloky a LangGraph modeluje agenta jako explicitní graf kroků se sdíleným stavem, takže se ve větvení, opakovaných pokusech a místech pro lidské schválení snáz vyznáte.
n8n se hodí na vše, co agenta obklopuje: spuštění webhookem z GitHubu nebo GitLabu, volání modelu, zveřejnění komentáře k revizi, upozornění do kanálu. Běžné rozdělení je orchestrace v n8n a rozhodovací krok v kódu, kde se dá verzovat a testovat jako zbytek vašeho softwaru.
V NorthStar Network naši inženýři vytvořili interní nástroje poháněné AI, které automatizovaly opakující se vývojářské úlohy pro tým nástrojů platformy.
Dejte agentovi jen ty nástroje, které nezbytně potřebuje
Agent může napáchat škodu jen prostřednictvím svých nástrojů, takže seznam nástrojů je vaše hlavní bezpečnostní pojistka. Každý nástroj definujte s úzkým účelem a validovanými vstupy, místo abyste agentovi dali obecný shell nebo API token s širokými právy.
Vše, co agent čte, včetně textu issues, komentářů v kódu a webových stránek, berte jako nedůvěryhodný vstup. Instrukce ukryté v souboru se mohou pokusit agenta odklonit (riziko známé jako prompt injection) a právě přísné hranice nástrojů brání tomu, aby takový pokus napáchal škodu.
- Ve výchozím stavu jen čtení: soubory, diffy a logy CI
- Zápis omezený na pracovní větev, nikdy do hlavní větve ani do produkce
- Samostatné, krátkodobé přístupové údaje pro každého agenta s minimálními oprávněními
- Žádné přímé nasazení: agent otevře pull request a po schválení nasazuje váš běžný pipeline
- Povolený seznam příkazů pro spouštění testů, prováděných v izolovaném kontejneru
Nejdřív plán, pak akce, a každé volání nástroje v logu
Požádejte agenta, aby před jakoukoli změnou připravil plán: které soubory bude číst, co chce změnit a jak výsledek ověří. Plány s nízkým rizikem mohou běžet automaticky. Vše, co se dotýká sdíleného kódu, čeká, až plán schválí člověk.
Logujte každé volání nástroje s jeho vstupy, výstupy, časovým razítkem a úlohou, ke které patří. Z tohoto logu dohledáte příčinu špatného výsledku, odpovíte na otázku auditu a všimnete si agenta, který vybočuje ze své úlohy. Chraňte ho stejně jako ostatní vývojářské logy, protože může obsahovat zdrojový kód.
Každý běh pevně omezte: maximálním počtem kroků, tokenů a minut a zastavením po opakovaných chybách, místo nekonečné smyčky opakovaných pokusů.
Každou změnu dodávejte jako diff, který zkontroluje člověk
Výstup agenta má přistát tam, kde vývojáři práci už revidují: v pull requestu, v komentáři k revizi, v konceptu poznámek k vydání. Diff ukazuje přesně, co se změnilo, CI nad ním proběhne a platí vaše běžná pravidla schvalování.
Diffy od agenta udržujte malé a s jediným účelem. Pull request, který přidává testy pro jeden modul, se reviduje snadno, kdežto takový, který kvůli obecnému vylepšení mění deset souborů, se schválí bez čtení, nebo zamítne. Změny od agenta označujte, aby revidující kontrolovali předpoklady, a ne jen syntaxi.
Vygenerované testy vyžadují zvláštní pozornost. Ověřte, že testují zamýšlené chování a selhaly by, kdyby byl kód špatně, a ne že jen zaznamenávají, co současný kód vrací.
Před rozšířením působnosti vyhodnoťte agenta na vlastní historii
Sestavte malou vyhodnocovací sadu z vlastních repozitářů: dřívější pull requesty se známými problémy, funkce se známými chybami, pády CI se známou příčinou. Spusťte na ní agenta pokaždé, když změníte prompt, model nebo nástroje, a výsledky porovnejte s předchozím během.
V každodenním provozu sledujte, jak často revidující přijímají návrhy agenta, kolik jeho pull requestů se sloučí bez úprav a jak často jsou plány zamítnuty. Novou úlohu nebo širší přístup mu dejte, až když jsou tyto signály stabilní.
Pravidla pro data sepište před prvním spuštěním
Rozhodněte, jaký kód a jaká data smějí jít ke kterému poskytovateli modelu a za jakých smluvních podmínek, a sepište to. U každého poskytovatele zkontrolujte nastavení uchovávání dat a trénování pro použití přes API a do promptů ani logů nedávejte tajné klíče, přístupové údaje a osobní údaje.
Pokud agent slouží více týmům nebo klientům, oddělte data, přístupové údaje a logy každého z nich. SDK Pilot, náš AI agent pro vývoj, nyní v bezplatném předběžném přístupu (early access), se těmito pravidly řídí: před provedením ukáže plán, loguje každé volání nástroje, vytváří diffy k revizi a izoluje data každé organizace.
Hlavní body
- Začněte s agenty na opakujících se úlohách, jejichž výstup vývojář ověří zhruba za minutu.
- Seznam nástrojů je hlavní bezpečnostní pojistka: nástroje držte úzké, ve výchozím stavu jen pro čtení a zápis omezte na větev.
- Před každou akcí vyžadujte plán a logujte každé volání nástroje s jeho vstupy a výstupy.
- Veškerou práci agentů přebírejte jako malé diffy přes váš běžný proces revize a CI.
- Než agentům rozšíříte působnost, vyhodnoťte je na skutečných příkladech z vlastní historie.
Časté dotazy
Může AI agent nahradit revizi kódu člověkem?
Ne. Agenti se hodí na první kolo, které zachytí chybějící testy, rizikové vzory a problémy se stylem, takže se lidé při revizi mohou soustředit na návrh a záměr. Každou změnu, která se slučuje, by měl dál schválit člověk.
Je bezpečné nechat AI agenta nasazovat do produkce?
Přímo ne. Nechte agenta otevřít pull request nebo žádost o změnu a nasazujte přes svůj stávající pipeline po schválení člověkem. Zůstane vám tak auditní stopa, testy i postup pro návrat zpět.
Mám na automatizaci vývoje použít LangGraph, nebo n8n?
Každý řeší jiný problém. LangGraph strukturuje uvažování agenta do explicitních kroků se stavem a místy pro schválení, kdežto n8n propojuje systémy pomocí spouštěčů a akcí. Mnoho týmů používá n8n ke spuštění a směrování práce a LangGraph nebo přímá volání API modelu pro samotného agenta.