AI asistenti pro vývoj software: postupy vhodné pro programátory

Rozhraní na způsob ChatGPT

Většina lidí se nejspíše s „AI“ poprvé seznámí skrze rozhraní, se kterým jako první přišlo ChatGPT. Jedná se o webovou stránku s formulářem, na které si můžete s AI asistentem povídat. Použití pro programování je hned zřejmé: popíšeme, co chceme, a AI asistent napíše odpověď a vygeneruje kód. V případě, že požadujeme program používající nějaké knihovny, které nejsou úplně běžně známé, je vhodné jako přílohu nahrát jejich dokumentaci, příklady jejich použití, nebo u menších knihoven rovnou jejich zdrojový kód.

Též může být vhodné nahrát jako příklad nějaký podobný program/skript, kterým se má agent inspirovat, specifikovat požadovanou platformu (např. není nutné vytvářet složitější multiplatformní kód, pokud budeme chtít program používat jen na Linuxu) a požadovaný styl kódu (AI asistenti mají, alespoň z mé zkušenosti, extrémní snahu obalovat všechny funkce pomocí try-catch bloků, i tam, kde odchycení výjimky nedává smysl – takže jim můžete specifikovat, že toto nechcete).

Dříve bylo typické, že AI asistent kód pouze vypsal mezi své ostatní zprávy; nyní většina rozhraní podporuje tzv. artefakty (artifact), což je samostatné okénko s kódem, které si žije trochu nezávislé na chatu. Pokud je kód v JavaScriptu, může se uvnitř okénka dokonce rovnou spustit (ve vašem prohlížeči). Artefakty typicky lze sdílet pomocí odkazu, a někteří asistenti je umí editovat – pokud řeknete, že chcete něco jinak, negenerují se celé znovu (což je pomalé a náchylné na zanesení nových chyb), ale jen se upraví.

 Ukázka výroby artefaktu pomocí Claude AI. Přál jsem si vytvoření grafu z CSV souboru z laboratorního měření.

Tento přístup má podle mě jednu naprosto zásadní nevýhodu: artefakt není možné manuálně upravovat. Já totiž typicky pracuji takto:

• Popíši zadání a nechám si vygenerovat program (nebo nahraji existující program, který chci upravit).
• Výsledek si stáhnu a otevřu v lokálním textovém editoru, prohlédnu, zkontroluji, upravím si ho dle svých představ a opravím v něm chyby, které tam AI asistent udělal.
• Nyní bych se chtěl s AI asistentem bavit o této své upravené verzi, například si v ní vyžádat nějaké další úpravy. AI asistent ale samozřejmě nevidí změny v mém lokálním textovém editoru…
• …takže musím svůj změněný soubor nahrát do chatu, říct mu, že toto je moje upravená verze a teď se budeme bavit o ní, a že tam chci nějaké změny.
• Asistent udělá změny a vyprodukuje novou verzi.
• Já tuto verzi chci opět zkontrolovat, ale nevím, co přesně se tam změnilo. Nechci kontrolovat věci, které jsem už kontroloval a nezměnily se…
• …takže si soubor stáhnu a použiji lokální nástroj pro porovnání změn (diff – nejraději mám Meld) a změny schválím či odmítnu.
• No a takhle pořád dokola.

Tohle samozřejmě volá po tom, aby na to existoval automatizovaný nástroj, nebo byl tento proces integrován do vývojového prostředí. Nebojte se, samozřejmě takové možnosti existují a dostaneme se k nim v následujících kapitolách.

Povídal jsem si o tomto „přístupu à la ChatGPT“ s kamarády, které jsem viděl, že ho používají, ačkoli by mi integrace do nějakého IDE přišla výhodnější. Měli dobrý argument, proč může být vhodný: říkají, že do chatu vždy kopírují jen relevantní kontext, a nechávají si třeba poradit úpravu jedné funkce, a tím, že ji pak ručně adaptují do svého programu, dobře pochopí, jak funguje, a neztratí se v generovaném „cizím“ kódu.

To je velmi dobrý argument, a vlastně je to podobné, jako když jsme před nástupem AI asistentů kopírovali ze StackOverflow – též bylo typicky nutné odpověď pochopit a upravit pro svůj program, a tím naše programátorské schopnosti rostly, ne se snižovaly. V tomto článku popisuji, jaké jsou možnosti; zamyšlení a diskuze nad rizikem „programátorského zakrnění“ a ztráty schopností je na konci.

Ještě se naskýtá otázka: jakým jazykem s AI asistentem mluvit? Já nějak automaticky používám při programování angličtinu (není nutné mít správnou gramatiku atd.), ale rozumí to samozřejmě i česky, a občas tam například vložím popis chyby v češtině (interní hlášení chyb pro náš firemní software si většinou píšeme česky) a normálně to funguje. Říká se, že při komunikaci v angličtině se asistenti chovají inteligentněji, ale nedělal jsem žádné objektivní porovnání a nemohu to potvrdit ani vyvrátit.

Napovídání kódu

Nejstarší a nejjednodušší způsob integrace do vývojového prostředí je chytré napovídání (code completion, suggestions atd.). Jednalo se vlastně o první verzi GitHub Copilot z roku 2021. Editor vám vymyslí a napoví, „co asi tak budete chtít psát dále“. Používá se typicky nějaký slabý, rychlý (a levný) model – lidé mívají tuto funkci nastavenou na stisk tabulátoru nebo dokonce automaticky během psaní a očekávají okamžité doplnění; jedná se o fragmenty kódu, které člověk napíše za pár sekund, takže pokud by se čekalo déle, již to nebude dávat smysl.

Lze to použít jen k jednoduchým úkolům, jako třeba vytvoření jednoduché funkce, pythoní doplňování seznamů a slovníků (list comprehension) atd. Kvalitě výsledku může pomoct napsat nejdřív komentář, co chceme provést, ale obecně pro takové použití už je lepší Inline chat, což popíšeme dále.

Chat uprostřed kódu (Inline chat)

Ukázky jsou z nástroje GitHub Copilot ve VS Code, ale samozřejmě existují rozšíření s obdobnou funkcionalitou do všech možných textových editorů a IDE.

Pro úkoly složitější než triviální napovídání se hodí funkce Inline chat. Typicky označíme nějaký kousek kódu nebo umístíme kurzor na místo, kde si přejeme vytvořit nový kód, klávesovou zkratkou vyvoláme malé okénko a do něj stručně napíšeme, co chceme udělat. Asistent pak může vybraný kód nahradit, rozšířit atd. Změnu zobrazí jako jednoduchý diff a můžete ji akceptovat.

Podívejme se pod pokličku, jak je funkce implementována. Ve VS Code jsem použil funkci Show Chat Debug View, alternativně by bylo možno odposlechnout síťovou komunikaci; zde uvedený záznam je zkrácen.

Jako první se Copilot zeptal slabého modelu (gpt-4o-mini), aby odhadl, co chceme s vybraným kouskem kódu udělat – ne vždy totiž požadujeme editaci, užitečné je třeba někdy něco označit a zeptat se, co daná funkce dělá.

A software developer is using an AI chatbot in a code editor in file /home/jenda/bin/ff.
Current active file contains following excerpt: [několik řádků okolo výběru]

The developer added the following request to the chat and your goal is to select a function to perform the request: „only use google search if url does not start with http and also does not start with ./“

Available functions:
Function Id: explain
Function Description: Explain how the code in your active editor works

Function Id: generate
Function Description: Generate new code

Function Id: edit
Function Description: Make changes to existing code

Function Id: doc
Function Description: Add documentation comment for this symbol

[…]

Slabý model usoudil, že chceme editovat. Následně Copilot zaslal na silný model (zde nastavený qwen-3-coder-480b) požadavek k editaci.

You are an AI programming assistant.
When asked for your name, you must respond with „GitHub Copilot“.
You are a world class expert in programming, and especially good at shellscript. [toto se mění podle typu otevřeného souboru :)]
Avoid content that violates copyrights.
If you are asked to generate content that is harmful, hateful, racist […] [všimněte si, že tyto požadavky to jen tak posílá po síti, takže by je bylo možné v případě potřeby upravit]

The user needs help to modify some code.
The user includes existing code and marks with $SELECTION_PLACEHOLDER$ [pozice kurzoru, resp. výběru] where the selected code should go.

[obsah souboru, s uvedeným $SELECTION_PLACEHOLDER$]
userPrompt: only use google search if url does not start with http and also does not start with ./

The modified $SELECTION_PLACEHOLDER$ code is: [tím, že tady toto napsali, asistent přímo odpoví kódem, bez obvyklých zdvořilostních frází – čili odpověď půjde přímo vložit jako kód]

Tento režim tedy podporuje lokální úpravy jednoho souboru (v rámci výběru či pozice kurzoru). Jeho výhodou je, že je rychlejší než plnohodnotný chat, který pracuje s celými soubory.

Plnohodnotný chat v rámci IDE

Pokud chceme udělat úpravu na více místech (nebo dokonce ani nevíme/nechce se nám specifikovat, na kterém místě, ať si tohle asistent vymyslí sám), nebo dokonce ve více souborech, potřebujeme pokročilejší nástroj.

Plnohodnotný chat (nazývaný někdy jen Chat, nebo též Edit mode) pošle asistentovi kompletní obsah souboru (souborů) a vyžaduje po něm, aby vytvořil patch, který se na tyto soubory aplikuje. K tomu si musíme zodpovědět několik otázek:

Jaké soubory asistent vidí? V například v Copilotovi se standardně posílá obsah aktuálně otevřeného souboru, ale je vhodné přidat všechny relevantní soubory – jak jsem výše psal: dokumentace a příklady použitých knihoven a API, hlavičkové soubory, logy, ukázková vstupní data, soubor README popisující obecný koncept projektu… Je tam na to tlačítko, přiložit všechny aktuálně otevřené soubory z IDE. Občas mám pocit, že trávím příliš mnoho času přípravou kontextu, pak to slavnostně odešlu a asistent úkol úspěšně splní – skoro by to chtělo automatickou správu kontextu (vyřešíme v příští kapitole).

Jak bude patch vypadat a jakým způsobem se aplikuje? Obecně není vhodné po asistentovi požadovat, aby upravený soubor (nebo dokonce několik souborů) celý vypsal – to je jednak výpočetně náročné (soubor může být velký a generování výstupu je u současných LLM mnohem dražší než čtení vstupu), jednak je riziko, že tam cestou něco nesouvisejícího pozmění (to mi přijde, vtipně řečeno, až pasivně agresivní – stává se, že vám asistent mimoděk refaktoruje kód, jako kdyby se mu zdál příliš hnusný a odmítal ho odrecitovat na výstup tak, jak jste ho odeslali). Používají se dva přístupy:

• Asistent vygeneruje patch v nějakém strojově zpracovatelném formátu. Buď jako unifikovaný diff (známý formát s plusy a mínusy na začátku řádku), nebo jako bloky „SEARCH [starý kód] REPLACE [nový kód]“. Tento patch se pak již automaticky strojově aplikuje. Zde je riziko, že asistent vygeneruje patch, který nepůjde hladce aplikovat – četl jsem, že typická úspěšnost bývá 90–95%. Když se to nepovede, předpokládám, že se asistentovi odešle další zpráva, a řekne se, ať to zkusí znovu.
• Asistent vygeneruje patch v nějakém mírně volnějším formátu (popíše změny částečně „slovy“). Tento patch se pak, spolu s originálním souborem, předloží nějakému slabšímu modelu, a řekne se mu, ať vypíše kompletní změněný soubor. Tento slabší model je jednak menší (takže to i pro větší soubory není výpočetně náročné), jednak hloupější, takže nemá silné názory na kvalitu kódu a nepustí se do samovolného refaktorování, a předpokládám, že je možná přímo dotrénován (fine-tuned) pro aplikaci změn. Koncept slabších modelů jsme již viděli výše, Copilot používá model s krkolomným jménem gpt-4o-instant-apply-full-ft-v66. Tento přístup také nefunguje vždy úplně dobře, já často zápasím s tím, že se mi posledních pár řádků souboru při tomto procesu z nějakého důvodu zduplikuje.

Copilot pak ještě dělá jednu takovou blbůstku, výtah chatu (hlavičky funkcí a uživatelské zadání) pošle do slabého modelu ještě jednou, a tentokrát se zeptá, jak by šlo konverzaci shrnout několika málo slovy. To je pak to, co se zobrazuje jako titulek v historii. Vše uvedené si opět můžete zobrazit a detailně prozkoumat v již zmíněném Chat Debug View.

Po té, co tohle všechno proběhne, vám IDE typicky zobrazí seznam změn, co nastaly, a vy je můžete po jedné přijmout, odmítnout, nebo upravit.

Navzdory uvedeným optimalizacím je tento režim výrazně pomalejší než Inline chat. Abych uvedl konkrétní čísla, Inline chat může trvat 1–3 sekundy, plnohodnotný zásah klidně přes 10 sekund, což už svádí k tomu, přepnout do jiného okna a práci odprokrastinovat. Vídám uživatele používat „velký“ chat i na věci, které by se snadno a rychle vyřešily Inline chatem. Tak prosím vezměte na vědomí tyto rozdíly.

Agentické programování

Nejpokročilejší metodou je agentické programování. V předchozích případech jsme vždy napsali nějaký požadavek, odeslali ho asistentovi, a ten na něj odpověděl (typicky změnou kódu). Tomu se někdy říká single-turn komunikace nebo single-shot / one-shot. U agentického programování agentovi zadáme úkol a následně ho necháme komunikovat s počítačem (prostředí, se kterým agent komunikuje, se někdy říká harness) – multi-turn komunikace.

Toto běhové prostředí agentovi poskytuje nástroje – například si agent může říct, že chce přečíst nějaký soubor, vyhledat v souborech v aktuálním adresáři nějaké slovo, nebo že chce spustit nějaký příkaz. Běhové prostředí toto vykoná, a výsledek (obsah souboru, výstup příkazu) agentovi předá. V ideálním případě tedy agent dostane úkol, sám si najde potřebný kontext (ať už obyčejným grepem, nebo nějakým způsobem indexování kódu), provede změnu, změnu otestuje (upravený program spustí a vyzkouší / spustí testy), pokud to nefunguje, přidá si ladící hlášky nebo i spustí debugger, chyby opraví, výsledek ukáže uživateli, a provede commit do verzovacího systému.

Běhové prostředí typicky:

• Určuje, které operace jsou bezpečné (výpis adresáře, přečtení souboru z projektu), a které jsou nebezpečné a potenciálně destruktivní, běh přeruší a vyžaduje potvrzení od uživatele.
• Proaktivně agentovi poskytuje kontext, například vyhledá relevantní soubory (indexování kódu), hlavičky funkcí, o kterých se hovoří, a nabídne je agentovi.
• U složitějších úkolů nechá agenta nejdříve vytvořit seznam úkolů (TODO list, Focus Chain), jak zadaný úkol rozložit na několik menších úkolů, a při běhu agenta mu tento seznam připomíná a nechává ho splněné úkoly odškrtávat.
• U úkolů vyžadujících refactoring velké části kódu se nejdříve na začátku použije plánování (plan mode, architect), kdy má agent získat informace a vytvořit plán, jak bude úkol řešit. Tento plán se nechá schválit uživatelem, a teprve potom se přejde do fáze, kdy se opravdu vykonává (act mode). Někdy se pro plánování používá jiný AI model, který je více orientován na kvalitní přemýšlení (varianta modelu někdy označovaná jako thinking), a pro vykonávání akcí se pak používají modely, které přemýšlejí minimálně (označované instruct). Případně lze u některých modelů úroveň přemýšlení (reasoning effort, thinking budget) nastavit za běhu.
• Nějakým více či méně spolehlivým způsobem kontroluje, jestli agent postupuje a někde se nezasekl, a když se tak stane, může obnovit nějaký starší bod obnovy (checkpoint) a zkusit to znovu – nebo přivolat uživatele a nechat ho situaci nějak vyřešit.
• V případě webových či grafických aplikací poskytuje agentovi přímo vzdáleně ovládaný prohlížeč, ve kterém aplikace běží, a agent může simulovat klikání („klikni na souřadnici X, Y“) a psaní na klávesnici a sledovat výsledky (požádat o screenshot). Obecně poskytuje MCP server. Takto lze například automatizovaně vyvíjet webové stránky nebo dokonce kreslit v CADu (to je hodně v začátcích a moc to nefunguje).
• U déle běžících úkolů uklízí kontextové okno agenta – identifikuje již nerelevantní obsah a odstraňuje ho. To se může udělat tak, že se spustí další asistent („sub-agent“) a zadá se mu, aby dosavadní obsah konverzace shrnul na desetinu velikosti, nebo v jednodušším případě pomocí předprogramovaných heuristik. Výsledkem tedy je „na tomto úkolu pracujeme, tohle jsme již vyzkoušeli, toto ještě musíme udělat“ – ale jsou odstraněny detailní výpisy ladících nástrojů, rozpracované staré verze souborů atd.
• Obecně může spouštět na jednotlivé podúlohy sub-agenty, čímž se šetří kontext (hlavní agent pak nemá v kontextu snahu o vyhledání nějaké informace, ale jen výsledek), a těchto sub-agentů může běžet více paralelně, čímž se program zrychluje.

Osobně mám z agentického programování rozporuplné pocity. Na většinu práce, kterou dělám já, se podle mě nehodí (vy to samozřejmě můžete mít jinak). Přijde mi, že trávím příliš času navigováním agenta a opravováním chyb, které dělá; to už je jednodušší si to udělat sám, protože když opravuji chybu po agentovi, tak to je „cizi program“, který musím pochopit. Ale řešil jsem už i úlohy, kdy bylo úplně dokonalé napsat „tady ti říkám, jaké informace obsahuje API a potřebujeme je stáhnout, tady je knihovna pro práci s API, a prostě to nějak zařiď“, a on potom upravoval program a spouštěl ho, přidával si tam ladící výpisy když mu něco nefungovalo, a nakonec to skončilo úspěšně.

Opravdu důležité tedy je dát mu možnost, jak svoji práci otestuje – ale nemusí to být jen skutečné programové testy. Díky tomu, že je to jazykový model, to může být i slovní popis, jak by zhruba měl výsledek vypadat. Zájemce o podrobnější ukázku agentického programování bych odkázal na kurz od autorů Claude Code a blog autorů Cline (Claude Code a Cline jsou příklady programů, které implementují popsanou funkcionalitu pro spouštění agenta). Též je zajímavé přečíst si prompty s instrukcemi pro jednotlivé nástroje (úprava souboru, spuštění příkazu…), které agent může používat.

Je nutno upozornit, že agent efektivně může spouštět libovolný kód na systému, na kterém běží. Nebezpečné příkazy se sice musí schvalovat, ale byly na to triviální útoky, kdy to například příkaz schovalo někam do zdrojového kódu, a úpravy souborů se zdrojovým kódem projektu se typicky dějí bez schválení. Takže by se měl ideálně spouštět v sandboxu, což bohužel tvůrci agentů málokdy přímo podporují.

Příště si ukážeme konkrétní programy

V dnešním článku jsme si představili přístupy k využívání AI asistentů pro programování. V příštím díle se podíváme na konkrétní programy, které uvedené pracovní postupy implementují a integrují do různých textových editorů a vývojových prostředí.

(Autorem obrázků je Jan Hrach.)