Jak tři Java Champions využívají GitHub Copilot ke zvýšení produktivity

Nástroje pro programování s AI dokážou rychle generovat kód. Samotná rychlost ale neřeší nejtěžší problémy softwarového inženýrství. Vývojáři stále musí dodat kontext, ověřit výsledky, zajistit udržovatelnost a nést odpovědnost za to, co se dostane k uživatelům.

GitHub oslovil tři držitele ocenění Java Champion, z nichž každý má s Javou více než deset let zkušeností. Popsali konkrétní příklady využití GitHub Copilot v produkčních i open source projektech a postupy, díky nimž se z výstupů AI stává spolehlivý software.

Vlad Mihalcea: vlastní dovednosti a důraz na udržovatelnost

Profil na GitHubu: @vladmihalcea

S čím Vám GitHub Copilot v poslední době pomohl?

Používám ho k analýze, návrhu a implementaci různých funkcí v projektech Hypersistence Utils a Hypersistence Optimizer.

Už dlouho jsem například chtěl vytvořit webovou aplikaci s historií událostí z Optimizer, abychom viděli, jak se úsilí o optimalizaci promítá do výkonu aplikace. Před nástupem AI jsem tento úkol stále odkládal, protože by vývoj zabral týdny. Práce s Copilot je ale jako mít v týmu dalšího člověka. Použil jsem ho tedy k vytvoření aplikace, která bude součástí příští verze Hypersistence Optimizer. Místo týdnů mi implementace zabrala pouhé dva dny.

Jak GitHub Copilot obvykle používáte? Jako rozšíření v IDE, nebo v samostatné aplikaci GitHub Copilot?

Používám GitHub Copilot v IntelliJ IDEA, protože je pohodlné mít ho po ruce při kontrole zdrojového kódu nebo ladění.

Jako asistent při programování je velmi užitečný. Pomáhá mi urychlit jak analýzu problémů, tak tvorbu prototypů funkcí, které potřebuji ověřit.

Plány i kód vygenerovaný AI stále kontroluji. Jejím cílem je zvýšit mou produktivitu, ne mě úplně nahradit. V mnoha situacích sice poskytne správnou odpověď, ale někdy výsledek nestačí a musím zasáhnout.

Jaké tipy a osvědčené postupy byste doporučil? Jaké dovednosti například používáte?

Vytvořil jsem vlastní dovednosti (skills), aby texty, které Copilot generuje, působily, jako bych je napsal sám.

Jedna z nich zachycuje můj styl na základě 65 publikovaných článků. Návrh textu pak zní jako můj blog, nikoli jako výstup jazykového modelu. To je velmi užitečné při generování dokumentace k projektu: jazykový model může využít mých 12 let blogování a nabízet příklady, které dodržují stejné principy, například srozumitelnost záměru kódu, testovatelnost a jednoduchost.

Za svou kariéru softwarového inženýra jsem se naučil, že údržbou kódu trávíme mnohem více času než jeho vytvářením. Protože jsou pro existující produkty údržba a stabilita zásadní, připravil jsem dovednosti, které pomáhají AI dodržovat zavedené postupy v kódu v souladu s principem nejmenšího překvapení.

Jedním z tipů je měnit model podle typu úkolu. Pro důkladné promýšlení používám Opus s kontextovým oknem o velikosti 1 milionu tokenů a úrovní uvažování Extra High nebo Max. Pro jednodušší úkoly, jako je generování reportů, poznámek k vydání nebo kontrola dokumentace, používám lehčí modely, které spotřebují méně tokenů.

Pat Baumgartner: delegujte provedení, ne odpovědnost

Profil na GitHubu: @patbaumgartner

Ve své práci se věnujete koučování týmů. Jak k tomu přistupujete?

Velká část mé práce probíhá za běžného provozu firmy. Nemůžete všechno na půl roku zastavit kvůli „transformaci“. Obvykle začínáme společným řešením aktuálních problémů. Zjišťujeme, kde se tým právě nachází, určujeme, kam se chceme dostat a podle čeho poznáme zlepšení. Pak postupujeme krok za krokem.

Podle situace to mohou být postupy Software Craft, například TDD, refaktoring, průběžné dodávání softwaru a XP; architektura a modularizace se Spring Boot a Spring Modulith; Spring Security; optimalizace aplikací v Javě a Spring Boot pro kontejnery; nebo stále častěji vývoj s využitím agentů.

Důležité pro mě je, že pracuji s týmem. Rozhodujeme společně. Nechci, aby na mně tým začal být závislý. V ideálním případě mě po čase už nepotřebuje, snad jen jako partnera k diskusi.

Možná právě proto mě nová generace nástrojů AI tolik zajímá: rád pracuji s lidmi, učím se, experimentuji a řeším problémy. AI nám k tomu dává další velmi silný nástroj.

Můžete uvést konkrétní příklad, kdy Vám GitHub Copilot v poslední době pomohl?

Jsou to vlastně tři velmi odlišné příklady, které změnily můj pohled na práci s GitHub Copilot.

Migrace přibližně 900 výukových snímků

Začněme prvním příkladem.

Šlo o migraci přibližně 900 výukových snímků v 15 prezentacích z Reveal.js do Marp. Nebyly to jednoduché snímky. Mnohé obsahují kód, animace, a dokonce interaktivní příklady, ve kterých mohu během výuky měnit JavaScript. Především ale byly prezentace už prověřené výukou. Jejich návaznost fungovala. Ztráta jediné drobnosti mohla narušit výklad, který ve třídě používám.

Ručně by mi migrace pravděpodobně zabrala týden nebo déle. A upřímně, možná bych se do ní vůbec nepustil, protože šlo o tak úmornou práci.

S Copilot jsem na to šel jinak. Nejprve jsme analyzovali existující materiály, určili cílový stav, vytvořili plán migrace, stanovili omezení, doplnili příklady a vymezili, co musí zůstat zachováno. Pak jsme postupovali od velkých strukturálních změn k detailům.

Nejdůležitější bylo ověřování.

Vygenerovali jsme snímky obrazovky verzí v Reveal.js a Marp a porovnávali je vizuálně i algoritmicky. Vytvořili jsme malou aplikaci, ve které jsem mohl spustit obě prezentace vedle sebe a ručně ověřit animace. Porovnávali jsme dokonce i vygenerované soubory PDF.

Agent tedy jen neoznámil: „Migrace dokončena.“ Měli jsme důkazy.

Celá migrace mi zabrala přibližně osm až deset hodin. Za obsah, výukový záměr a každou významnou změnu jsem stále odpovídal já. Copilot mohl automaticky opravit překlep, ale změny obsahu, verzí, dat nebo významu jsme probírali.

Tato zkušenost mi potvrdila důležitý princip: delegujte provedení, ne odpovědnost. Za výsledek odpovídám já.

Oprava terminálové aplikace a úspornější zápis testů

Jaký byl druhý příklad?

Druhý příklad se týkal vývoje aplikace s terminálovým uživatelským rozhraním pomocí Tamboui. Zpočátku fungovala bezchybně v Linuxu pod WSL. Úplně jsem zapomněl, že ji někdo může spustit přímo v prostředí Windows CMD nebo PowerShell.

A pak to skutečný uživatel udělal.

Zjistil, že v některých formulářích aplikace jednoduše ignoruje klávesu Enter. To souvisí s dalším principem, kterému pevně věřím: vydávejte software brzy, protože se učíte z toho, jak ho lidé skutečně používají.

S Copilot jsme tuto zpětnou vazbu převedli na reprodukovatelné testy uživatelského rozhraní. V Linuxu Copilot ovládal aplikaci pomocí tmux. Při společné práci jsem se dozvěděl o psmux a mohl podobné scénáře spouštět i v PowerShellu. Problém jsme reprodukovali, vytvořili lokální opravu, dohledali skutečnou příčinu v Tamboui a já jsem odeslal opravu do původního projektu, kde byla přijata.

Během této práce samotné popisy testů narostly natolik, že se nevešly do dostupného kontextu. Požádal jsem proto Copilot, aby mi pomohl přepracovat jejich zápis. Místo rozvláčných tabulek s identifikátory, názvy a opakovanými popisy navrhl mnohem úspornější zápis pomocí šipek: krok → krok → vstup. Doplňující informace se uváděly jen tam, kde byly zásadní.

To mě překvapilo. AI jsme nepoužívali jen k vykonávání instrukcí. Společně jsme řešili, jak informace zapsat, aby podle nich bylo možné postupovat. Zápis nemusel být maximálně přívětivý pro člověka. Musel zachovat význam a zároveň být efektivní pro agenta.

Výuková aplikace pro matematiku

A třetí příklad?

Ten je zase úplně jiný.

Někdo z mých blízkých potřeboval procvičovat matematiku a napadlo mě: proč nevytvořit malou výukovou aplikaci?

Pokrývá sčítání, odčítání, násobení, dělení a dělení se zbytkem pro první až čtvrtou třídu. Nechtěl jsem ale vytvořit jen další jednoduchý kvíz. S Copilot jsem zkoumal vzdělávací přístupy, jako je opakování s časovými rozestupy, okamžitá zpětná vazba, přizpůsobování obtížnosti, motivace, kooperativní učení a gamifikace bez manipulativních prvků.

Zajímavé bylo, že Copilot během průzkumu zpochybnil jeden z mých původních předpokladů. Nejdříve jsem chtěl univerzální aplikaci pro děti z celého světa. Průzkum nás ale přivedl k tomu, abychom se podívali na konkrétní školní osnovy. Uvědomil jsem si, že pořadí probíraných témat, početní operace i číselné obory se liší natolik, že nemá smysl usilovat o univerzálnost hned od začátku.

Zaměřili jsme se tedy nejprve na Švýcarsko a podle toho nastavili postup výuky. Protože je Švýcarsko vícejazyčné, je aplikace dostupná v němčině, francouzštině, italštině a angličtině.

Má také kooperativní a soutěžní režim pro dva hráče. Když někdo odpoví špatně, vysvětlí jeden z možných postupů řešení a podobné otázky později znovu zařadí pomocí opakování s časovými rozestupy.

Záměrně jsem zvolil architekturu bez backendu. Nemám důvod shromažďovat osobní údaje dětí na serveru, takže data zůstávají v zařízení a aplikaci lze jednoduše hostovat na GitHub Pages.

Z malého experimentu se stalo něco, co přátelé používají a sdílejí mezi sebou. Tak trochu neplánovaně vznikl malý produkt.

Tato zkušenost mi ukázala další stránku Copilot: nepoužívejte ho jen k implementaci svého řešení. Využijte ho jako partnera k diskusi, který Vám pomůže rozšířit a prověřit možnosti řešení ještě před začátkem vývoje.

Od automatického doplňování k agentním postupům

Jak Copilot obvykle používáte?

Klasické automatické doplňování kódu v Copilot už vlastně nepoužívám.

Moje práce se téměř úplně přesunula k postupům s využitím agentů.

VS Code používám, když potřebuji rychlou vizuální zpětnou vazbu – když chci průběžně podrobně sledovat dokumenty, kód, prezentace nebo dílčí výsledky a podle nich upravovat postup.

U větších úkolů zaměřených na samotné provedení často pracuji s programovacím agentem z terminálu. V tomto prostředí mi více vyhovuje zadat určitou část práce, nechat ji provést a potom zkontrolovat celý výsledek. Rozhraní volím především podle toho, jakou průběžnou zpětnou vazbu potřebuji.

Zajímavou zkušenost jsem měl také s programovacím agentem přes GitHub během cesty na JavaLand. Začal jsem zkoumat nápad na plugin pro Maven, který optimalizuje výběr načítaných automatických konfigurací Spring Boot. Během přibližně čtyřhodinové cesty jsem agenta řídil z telefonu: zadal jsem úkol, zkontroloval výsledek, promyslel další krok a poslal další instrukci.

Než jsem dorazil, měl jsem funkční plugin pro Maven, CI pipeline, výkonnostní testy nad ukázkovou aplikací a reporty, které dokázaly doložit, zda optimalizace skutečně funguje.

Takto jsem pracoval poprvé a překvapilo mě, že to opravdu fungovalo. Nesnažil jsem se psát Javu na telefonu. Kontroloval jsem, rozhodoval a určoval směr, zatímco agent prováděl práci.

Používám také MCP servery, pokud přinášejí užitečné možnosti nebo kontext. Využil jsem například Context7 pro dokumentaci, propojení se svou znalostní bází v Logseq a experimentoval jsem s MCP integrací pro Adobe Premiere Pro.

MCP ale nepoužívám jen proto, že je k dispozici. Pokud existuje dobré rozhraní příkazového řádku, často mu dávám přednost, protože mi připadá přímočařejší a rychlejší.

Agenta si také nepředstavuji jako „juniorního vývojáře“. Vnímám ho spíše jako partnera k diskusi. Stejně jako každý, kdo se připojí k projektu, se ale nejprve musí zorientovat.

Kontext je zásadní.

Čtyři principy spolehlivé práce s agenty

Jaké tipy a osvědčené postupy byste doporučil?

Moje hlavní doporučení zní: nesnažte se všechno vyřešit jediným promptem.

U každého složitějšího úkolu chci problému porozumět ještě před zahájením práce. Často agenta výslovně žádám, aby mi nejprve kladl otázky. Cílem je odhalit předpoklady a očekávání, které zatím nebyly vysloveny.

Dobrý agent dokáže neuvěřitelně rychle realizovat špatný nápad. Tím se ale náklady na chybnou cestu nesnižují.

Zažil jsem to při práci na optimalizátoru automatických konfigurací Spring Boot. Původně jsem chtěl podporovat Spring Boot 3.5 i 4.x. Kvůli rozdílům v architektuře jsme implementovali oba přístupy. Později jsem zjistil, že podporu 3.5 už nepotřebuji, a její odstranění bylo bolestivé.

Poučení bylo jednoduché: slepé uličky jsou drahé. Než zrychlíte, ujasněte si požadavky.

Jakmile je záměr jasný, chci plán. Při jeho kontrole mě zajímají zejména čtyři věci: jsou předpoklady výslovně uvedené, jsou stanovené kontrolní body, odpovídá postup architektuře a vyhýbá se zbytečné práci?

Druhým principem je stanovit kontrolní kritéria pro konkrétní úkol.

„Hotovo“ by nemělo znamenat, že model oznámil dokončení.

U refaktoringu může jít o úspěšné testy, doložení, že byly zpracovány všechny zamýšlené soubory, aktualizaci dokumentace a odstranění všech nedokončených položek TODO. U migrace prezentací mezi kritéria patřily snímky obrazovky, vizuální porovnání rozdílů, animace, výstup PDF a úplnost obsahu.

Kritéria se liší podle úkolu. Princip zůstává stejný: agent by měl být schopen doložit, že práce splňuje podmínky dokončení.

Nedávno jsem narazil na dovednost unlazy, která vychází z podobného přístupu: stanovit explicitní kontrolní kritéria, systematicky je projít a doložit jejich splnění místo hledání zkratek.

Třetím principem je převádět získané zkušenosti do opakovaně použitelných dovedností.

Začal jsem psát a udržovat vlastní Agent Skills. Když se během práce něco naučím – například agent nepochopil určitou konvenci, chyběla užitečná kontrola nebo jsem našel lepší postup – dovednost aktualizuji.

Při příštím provádění stejného úkolu už je tato zkušenost součástí zadání.

Příkladem je dovednost, kterou nazývám maintainer-audit. Inspirovala mě práce komunity kolem otevřených dovedností pro agenty. Používám ji napříč svými repozitáři. Kontroluje a tam, kde je to vhodné, také opravuje věci, které očekávám od udržovaného projektu: dokumentaci repozitáře, CI pipelines, konfiguraci Dependabot, CodeQL, jednotný úklid projektu a další standardy.

Cílem není vytvořit další auditní zprávu, kterou si budu muset přečíst. Dovednost automaticky přibližuje repozitář výchozímu standardu, který požaduji. Moje projekty jsou díky tomu jednotnější a snáze se udržují.

Tyto dovednosti vnímám jako průběžně rozvíjené technické znalosti, nikoli jako statické prompty.

Čtvrtým principem je obklopit pravděpodobnostní model deterministickými nástroji softwarového inženýrství.

Mám vlastní sadu nástrojů pro kontrolu kvality, která zastřešuje například Checkstyle, PMD a kontroly architektury ve Spring Modulith. Vytváří souhrnný report, se kterým agent dokáže pracovat. Mohu ji spouštět pomocí hooků a nechat agenta opakovat cyklus:

změna → spuštění kontrol → přečtení nálezů → oprava → nové spuštění kontrol.

Cyklus pokračuje, dokud nezůstanou žádné nálezy.

To ale neznamená, že software přestanu sám kontrolovat. Stále aplikaci spouštím, používám ji a posuzuji, zda se chová a vypadá podle očekávání. Někdy záměrně implementuji jednu funkci po druhé, protože tak získávám mnohem rychlejší zpětnou vazbu.

Zjistil jsem, že chtít všechno najednou jen proto, že „AI to zvládne“, bývá špatný nápad. Rozsáhlé a obecné specifikace vedou k rozsáhlým a obecným implementacím. Jejich následné čištění může být náročnější než správně postupovat po menších částech.

Obecně si myslím, že bychom jako vývojáři měli mnohem více mluvit o tom, jak tyto nástroje používáme. Místo hledání jednoho univerzálního postupu vývoje s AI je důležité přizpůsobit způsob práce konkrétnímu kontextu.

I proto se mi líbí představa AI jako partnera k diskusi. Když chci v pátek večer něco vyzkoušet a nemám po ruce člověka pro párové programování, najednou mám někoho – nebo něco –, s kým mohu prověřit nápad, projít navržený postup nebo si problém ujasnit tím, že ho vysvětlím nahlas.

S těmito nápady se ale stále vracím ke skutečným lidem. Lidská zpětná vazba, porozumění produktu a kontext reálného světa zůstávají zásadní.

Jak podle Vás AI mění profesi vývojáře?

Nemyslím si, že by studenti softwarového inženýrství měli usilovat především o to stát se stroji na produkci kódu. Potřebují se naučit dobře řešit problémy. Musí rozumět uživatelům a zainteresovaným stranám, odhalovat skutečný problém za požadavkem, zpochybňovat předpoklady, rozumět produktům a trhům, vyvažovat architektonické kompromisy, kriticky myslet, pracovat systematicky a přenášet užitečná řešení z jednoho prostředí do jiného.

Model je mimořádně dobrý v navrhování možností a provádění úkolů. Jako člověk ale obvykle znám mnohem více skutečného kontextu – včetně věcí, které nikdo nikdy nezdokumentoval.

Chci tedy dál určovat podobu řešení a nechat agenta převzít větší část realizace.

V tomto smyslu podle mě AI vrací do softwarového inženýrství důraz na inženýrskou práci.

A to se mi líbí.

Frank Delporte: hledání nenápadné chyby v Pi4J

Profil na GitHubu: @FDelporte

GitHub Copilot je výborný pomocník při posuzování pull requestů a zkoumání hlášení chyb.

Jeden pozoruhodný příběh se týká knihovny Pi4J, která umožňuje vytvářet aplikace v Javě pro práci s elektronickými součástkami na Raspberry Pi. V únoru 2026 jsme vydali verzi V4 s novým pluginem využívajícím Foreign Function & Memory API. Před vydáním jsme ji důkladně otestovali. Přesto krátce poté někdo nahlásil, že použití pěti vstupních tlačítek nefunguje podle očekávání. Stisk kteréhokoli z prvních čtyř nakonfigurovaných tlačítek spustil kód správně, ale u pátého se nestalo nic.

Přesně takové hlášení nechcete dostat. Na první pohled nic neukazovalo na chybu. Žádná výjimka, žádné varování v logu, páté tlačítko prostě mlčelo. A aby toho nebylo málo: se starším pluginem gpiod fungoval stejný hardware i stejná aplikace bez problémů. Chyba tedy byla v našem novém FFM kódu, který využívá znakové zařízení GPIO linuxového jádra a komunikuje s ním prostřednictvím nativních volání. To není část kódu, ve které by člověk očekával rychlou odpověď.

Přiřadil jsem tedy problém agentovi Copilot coding agent a jako výchozí bod mu dal cesty ke dvěma souborům: třídě poskytovatele a FFMDigitalInput. Přibližně za půl hodiny byl připravený pull request s vysvětlením, které jsem opravdu nečekal.

Každý vstup spouští sledování událostí, které čeká v blokujícím nativním volání poll(), dokud jádro neohlásí změnu na příslušné GPIO lince. Tato sledování běžela ve virtuálních vláknech. Virtuální vlákno, které se zablokuje uvnitř nativního volání, se ale nemůže odpojit od svého nosného vlákna. Zůstává k němu připoutané po celou dobu volání. Raspberry Pi 4 má čtyři jádra, takže plánovač virtuálních vláken má čtyři nosná vlákna. Po registraci čtyř vstupů zůstanou všechna čtyři nosná vlákna trvale čekat v poll(). Páté sledování se sice vytvoří, ale nikdy se nedostane ke spuštění. To přesně odpovídalo nahlášené chybě. Ne „události občas selhávají“, ale „pátý vstup nedělá nic“.

Nejvíce mě nezaujala samotná změna kódu, ale následná diskuse při kontrole. Do komentáře jsem napsal dotaz, aby Copilot problém vysvětlil podrobněji:

„Myslel jsem, že smyslem virtuálních vláken je právě zbavit se omezení počtem platformových vláken. Vysvětlete prosím, proč tedy vadí, že čtyři virtuální vlákna zablokují čtyři vlákna na čtyřjádrovém procesoru, jako má Raspberry Pi?“

Celá diskuse je dostupná v pull requestu. Copilot dokázal spojit skutečnost, že Raspberry Pi má čtyři procesorová jádra, s nahlášeným problémem. Navrhl jednoduchou opravu a také několik dalších vylepšení, na která při analýze narazil.

Doporučení pro práci s programovacím agentem

• Řekněte mu, kde hledat: U problému Pi4J #622 jsem doplnil cesty ke dvěma souborům. Je to malá námaha, která ušetří spoustu hledání v rozsáhlém projektu. I když netušíte, co chybu způsobuje, obvykle alespoň odhadujete, v jaké části kódu hledat. Předejte tuto informaci nástroji, aby nemusel procházet celý projekt.
• Požadujte důkazy a testy: „Přidejte jednotkový test, který ověří změnu“ je požadavek, který zadávám často. Vlastně jsem zadával – nyní už je pravidlem v mém souboru s instrukcemi. Pomáhá odhalit i chybnou diagnózu: pokud nový test na původním kódu neselže, navržené vysvětlení nemusí být správné.
• Ptejte se proč: Pokud opravě nerozumíte, řekněte to a požádejte o vysvětlení. I vysvětlení je součástí výsledku a mělo by se dostat do dokumentace projektu, záznamu úkolu nebo pull requestu. Pomůže každému, kdo si informace přečte později. V týmu Pi4J například tato oprava vyvolala další otázky kolem připoutání virtuálních vláken při nativních voláních.
• Zachovejte si kontrolu: Všechny tyto pull requesty v Pi4J před začleněním zkontrolovali a schválili správci projektu. Právě tento model zde funguje nejlépe: agent provádí analýzu, ale za vydaný software odpovídají lidé. Kód vygenerovaný nástrojem kontroluji i ve svých ostatních projektech. Vždy chci zachovat čitelnost a udržovatelnost. Nástroj příliš často vytváří duplicitní metody nebo znovu implementuje něco, co už existuje jinde a mělo by se sjednotit. To je Vaše odpovědnost. S AI lze dnes programovat velmi rychle – a stejně rychle lze v kódu vytvořit nepořádek. Udržujte ho proto přehledný a zvládnutelný. Ocení to Vaši kolegové i Vy sami, až budete později hledat chyby nebo přidávat vylepšení.