AI nástroje, které používám pro vývoj [Robert Haken, WUG Days Brno, 3.9.2026]

Jaké AI nástroje používám pro vývoj? Claude Code, GitHub Copilot, VS Code Agents, MCP servery a kolik to celé stojí.

Záznam přednášky z konference WUG Days Brno z 3. září 2026 – bez slidů, formou interaktivní diskuze nad reálným nastavením mého vývojářského prostředí.

  • Kahoot dotazník publika: jaké AI platformy, modely a nástroje používají čeští vývojáři a kolik za AI platí
  • Proč jsem po desítkách let opustil Visual Studio jako hlavní nástroj a k čemu ho používám dnes
  • VS Code Agents Window – paralelní sessions, Git worktrees a přepínání harnessů (Copilot, Claude, Codex)
  • Proč přechod GitHub Copilot na token-based billing změnil můj workflow a co vyšlo v simulaci nákladů
  • Claude Code s Claude Team Premium jako primární nástroj pro lokální vývoj – proč je subscription levnější než API tokeny
  • GitHub Copilot Business pro cloudové scénáře: automatizované code review, „assign to agent“ na GitHub Issues, sdílený pool AI kreditů
  • Volba modelů: Fable vs. Opus vs. Sonnet vs. GPT – kdy sáhnout po kterém a jak hlídat limity
  • MCP server v ASP.NET Core v pár řádcích kódu (ModelContextProtocol.AspNetCore) – dokumentace Havit.Blazor a firemní systém HAVIT Goran
  • Autentizace MCP serverů přes Entra ID / OAuth – registrace AI agentů jako klientů aplikace
  • Migrace z Azure DevOps na GitHub: repozitáře, pipelines, issues a druhá organizace pro interní projekty
  • Jak vypadá zadání pro AI agenta dnes – od podrobných instrukcí k triviálnímu popisu požadavku
  • Co AI dělá s profesí vývojáře: nárůst produktivity, „šlechtění“ AI ekosystému, změna role a únava z orchestrace agentů

HAVIT se stal OpenAI Select Partnerem

Společnost HAVIT, s.r.o., pražské digitální studio pro éru AI zaměřené na vývoj softwaru na míru, implementaci a adopci AI a Microsoft Azure, dnes oznámila, že byla jmenována OpenAI Select Partnerem v rámci OpenAI Partner Network.

OpenAI Partner Network je globální program pro partnery, kteří s OpenAI vytvářejí, prodávají a dodávají AI řešení. Sdružuje partnery s hlubokou oborovou expertízou, delivery kapacitami a vztahy se zákazníky a poskytuje jim zdroje, enablement a podporu, aby pomohli firmám nasadit frontier modely a produkty OpenAI a proměnit je v měřitelný přínos.

Jako OpenAI Select Partner bude HAVIT nadále spolupracovat s OpenAI a pomáhat organizacím zodpovědně a efektivně vytvářet, nasazovat a škálovat AI řešení. Díky tomu získají organizace více užitečné práce z každého tokenu a vyšší výkon za vynaložené prostředky s GPT‑6 Astra a s pomocí ChatGPT Work promění ambiciózní cíle v hotovou práci. HAVIT od roku 1997 dodal přes 200 projektů ve fintechu, automotive, zdravotnictví a dalších oborech a spojuje strategii, design, engineering a AI agenty pod jednou střechou.

„Jmenování OpenAI Select Partnerem potvrzuje směr, kterým jdeme už několik let — dostat AI z experimentů do produkčních systémů, na které se naši zákazníci denně spoléhají. S OpenAI chceme úzce spolupracovat na integraci frontier modelů do aplikací, které vyvíjíme a provozujeme, aby naši zákazníci získali měřitelné výsledky: rychlejší procesy, nižší provozní náklady a software, který svým uživatelům skutečně slouží,“ říká Robert Haken, zakladatel a Software & Cloud Architect společnosti HAVIT.

HAVIT podporuje organizace napříč obory implementací a adopcí AI (od dema k produkci), AI onboardingem vývojářských týmů, vývojem digitálních produktů kompletními produktovými týmy a expertízou v Microsoft Azure — od architektury po provoz v roli Microsoft Cloud Solution Providera. Mezi jeho práce patří AI agenti a AI funkce nasazené přímo do produkčních systémů zákazníků a mentoring vývojových týmů při přechodu na vývoj s AI.

Do budoucna plánuje HAVIT rozšiřovat nabídku služeb postavených na OpenAI, investovat do enablementu týmu a škálovat nasazení AI v zákaznických řešeních — a pomáhat tak zákazníkům proměnit AI ambice v byznysové výsledky.

Více o OpenAI Partner Network: https://openai.com/business/partners

Novinky v .NET 11 a C# 15 [Robert Haken, WUG Days Brno, 2.9.2026]

Co přinese .NET 11 a C# 15? Union types, closed hierarchies, async validace, LINQ Full Join a novinky v Blazoru v praxi.

Záznam přednášky z konference WUG Days Brno z 2. září 2026. Přehled novinek přicházejících v listopadu s .NET 11 a C# 15 – se zaměřením na to, co se hodí při každodenním psaní kódu.

Co se dozvíte

  • Release cycle .NET – konec podpory .NET 8 a 9, STS/LTS
  • Rekapitulace C# 14 – extension members, klíčové slovo field, null conditional assignment (?=)
  • C# 15 – union types a exhaustive pattern matching (výsledky API bez výjimek)
  • C# 15 – closed hierarchies (closed class) a výhled na closed enums
  • C# 15 – collection expressions s parametry konstruktoru (with), extension indexery, labely pro break/continue
  • Výhled na C# 16 – dictionary expressions, inline union types
  • Runtime – runtime-native async, JIT optimalizace, Blazor WebAssembly na CoreCLR místo Mono
  • BCL – Process.Run, StringStream, Rune API, Base64, LINQ Join bez result selectoru a nový FullJoin, EqualityComparer.Create
  • System.Text.Json – naming policy per property, podpora union types
  • Konfigurace – [ConfigurationIgnore], validace options přes službu z DI
  • Asynchronní validace – AsyncValidationAttribute, IAsyncValidatableObject (Minimal API i Blazor)
  • SDK – dotnet run -e pro environment variables, include souborů ve file-based apps
  • Blazor – DisplayName komponenta, TempData a Session v SSR, CacheView, vylepšený Virtualize

Slides

LLM Wiki II. – Zeptej se projektu [Daniel Hrubý, Vojtěch Lengál, Vzdělávací okénko, 20.8.2026]

Jak nasadit LLM Wiki na reálný projekt? Kotvy do kódu, self-healing wiki, ingest z pull requestů a wiki pro zákazníka.

Druhý díl o LLM Wiki (koncept dle Andreje Karpathyho) – tentokrát o tom, jak wiki žije na dvou reálných projektech v HAVITu, co se osvědčilo a kde jsou zatím díry.

  • Rekapitulace metodiky LLM Wiki: capture → ingest → lint → query
  • Typický týden projektu s wiki: transkripty z Teams meetingů, dotazy zákazníka, generování user stories do Confluence, kontext pro coding agenta
  • Migrace pětileté historie projektu z Confluence do wiki – a proč se dokumentace liší od toho, co dělá kód
  • Kotvy do kódu (code anchors) a koncept self-healing wiki: detekce a řešení rozporů mezi wiki a kódem
  • Skill user story crosscheck – kontrola zadání od zákazníka proti historii projektu a datovému modelu
  • Export LLM Wiki zákazníkovi + AGENTS.md, aby jeho AI psalo zadání v kontextu projektu
  • Popis pull requestu jako zdroj: GitHub Action po merge do masteru zařadí PR do fronty k ingestu
  • Zkušenosti z ročního projektu: 350 zdrojů, 130 wiki stránek, přes 3 000 odkazů
  • Kategorizace a immutabilita zdrojů, frontmatter s metadaty, redakce secrets, převod do Markdownu (markitdown)
  • Ingest jednou týdně v dávkách a přes pull request – proč ne paralelně a proč ne 150 zdrojů najednou
  • Lint: deterministický Python skript (dead links, duplicity) + LLM lint logických rozporů, výstup jako PR s komentáři
  • HAVIT Wiki plugin jako startovací čára pro nové projekty
  • Diskuze: MCP nad wiki, sdílení se zákazníkem, riziko nepřesností v bázi, verzování zdrojů

Navazuje na první díl LLM wiki (Karpathy).

Vzdělávací okénko prezentovali Daniel Hrubý a Vojtěch Lengál.

Když je zadáním pull request — jak v Broker Trustu vznikají změny aplikace s Claude Code

Broker Trust, a.s. nasadil s HAVITem Claude Team. Po cíleném školení tam vznikl nový způsob práce: product owner nepíše zadání a nečeká — jednodušší změnu si postaví sám v Claude Code a pošle ji jako pull request. Dřív srovnatelná změna trvala od nápadu do produkce typicky 3–4 týdny; nejrychlejší z těchto pull requestů byl v produkci 16 hodin po odeslání.

Výzva

BETY2 je CRM, se kterým pracuje síť finančních poradců Broker Trustu. Produktová strana přesně věděla, co v aplikaci zlepšit — ale každá změna, i drobná, šla stejnou cestou: napsat zadání, předat vývoji, čekat na kapacitu, vyjasňovat po schůzkách. A protože psané zadání je vždy jen přiblížením toho, co měl někdo v hlavě, vyjasňování patřilo ke každému požadavku. U jednoduché změny trvala cesta od nápadu do produkce typicky 3–4 týdny — a většinu z toho tvořilo čekání, ne práce.

Řešení

Broker Trust nasadil Claude Team napříč organizací — 42 licencí, z toho 10 Premium s Claude Code; licence i vlastní tenant si spravuje sám. Nasazení vyrostlo z 10 licencí na 42 během tří týdnů od spuštění.

Podstatnou změnou ale nebyl počet licencí, ale praktické školení lidí nejblíž produktu. HAVIT, který pro Broker Trust dlouhodobě vyvíjí jeho aplikace, odvedl onboarding a školení vybraných lidí — v červnu a červenci 2026 přednášky a workshopy zaměřené na jednu konkrétní schopnost: umět si s Claude Code z nápadu vyrobit funkční kód nad jejich vlastním kódem.

Školení prošli dva product owneři. První z nich už do kódu reálně přispívá: Martin Budín, product owner aplikace BETY2. Dnes pracuje jinak než dřív — místo psaní zadání a čekání na vývojáře popíše změnu Claude Code, iteruje ji nad skutečným kódem a výsledek pošle jako pull request. Vývojáři HAVITu ho zrevidují a mergují. Takhle už poslal čtyři pull requesty; tři z nich jsou zrevidované a nasazené v produkci.

Podstatné je, co to udělá s fází návrhu. Když si product owner změnu prozkoumá přímo v kódu, nepřichází k vývojovému týmu statický mockup ani odstavec textu, ale funkční implementace, kterou si lze proklikat a rozporovat. Nejasnosti, které se dřív ukázaly pozdě až při vývoji, jsou vidět hned na začátku.

Stejný posun se propsal i do designu. Produktový tým Broker Trustu si dnes návrhy úprav aplikace připravuje s Claude sám, místo aby je plánoval s designérem — krok návrhu tak nečeká na ničí kalendář.

Na kontrole kódu se přitom nic nezměnilo. Každá změna jde před produkcí pořád přes code review vývojářů HAVITu; product owner pull requesty otevírá, nemerguje je. Změnilo se jen to, kdo umí vyrobit důvěryhodný výchozí bod — a jak rychle.

Změřené výsledky

Nejrychlejší změna prošla z pull requestu do produkce za 16 hodin — proti typickým 3–4 týdnům před nasazením, tedy zkrácení cyklu o více než 95 %. Před nasazením čekala malá úprava BETY2 na zadání, předání a volnou kapacitu vývoje — dohromady typicky 3–4 týdny. Dnes product owner posílá rovnou funkční implementaci a jediným zbývajícím krokem je code review: nejrychlejší z jeho pull requestů byl zrevidovaný, mergnutý a nasazený v produkci do 16 hodin od odeslání.

Funkční implementace existuje první den, ne třetí týden. Product owner změnu postaví s Claude Code a tentýž den ji pošle jako funkční, proklikatelný pull request — dřív nic revidovatelného neexistovalo, dokud zadání nezvedl vývojář, typicky o týdny později. Tomu odpovídá i čas vývojářů na změnu: z hodin implementace podle psaného zadání na revizi funkčního pull requestu.

Příprava designu se zkrátila ze 4 týdnů na 1 týden. Návrhy úprav aplikace, které dřív produktový tým připravoval s designérem typicky 4 týdny, si dnes připraví sám s Claude za týden — a k vývoji přichází rovnou proklikatelný návrh.

V číslech, za první dva měsíce produkčního provozu:

  • 4 pull requesty od product ownera Broker Trustu; 3 zrevidované, mergnuté a nasazené v produkci
  • Nejrychlejší pull request od odeslání do produkce: 16 hodin — proti typickým 3–4 týdnům na změnu před nasazením
  • Příprava designu úprav: ze 4 týdnů s designérem na 1 týden vlastními silami produktového týmu
  • 2 product owneři vyškoleni v práci s Claude Code nad vlastní aplikací
  • Adopce Claude vyrostla 4× — z 10 na 42 licencí — během tří týdnů od spuštění

„Dřív jsme každou i drobnou úpravu museli popsat, předat a čekat, kdy se na ni najde kapacita. Dnes si ji náš product owner u jednodušších věcí postaví sám a pošle jako pull request k revizi. Hodně nám pomohlo, že se nebavíme nad textem zadání, ale nad hotovou věcí, kterou si můžeme proklikat.“

— Petr Musil, Technical architect, Broker Trust

Co dál

Zkušenost se přenáší dál. Broker Trust chystá vlastní agentní řešení nad Claude, které propojí jeho interní systémy — a staví je z velké části sám.

Azure Virtual Desktop [Jiří Gregor, Vzdělávací okénko, 23.7.2026]

Jak provozovat aplikace v Azure Virtual Desktop? Architektura, App Attach, FSLogix, škálování a náklady z reálné praxe.

  • Co je Azure Virtual Desktop a kdy ho zvolit místo Windows 365
  • Architektura: host pool, application group, workspace a session hosty
  • Zabezpečené připojení bez otevřených portů – RDP přes WebSocket a RDP Shortpath (UDP)
  • Identity přes Microsoft Entra ID a uživatelské profily s FSLogix
  • Pooled vs. personal desktopy, plný desktop vs. streamování aplikací (RemoteApp)
  • App Attach – distribuce aplikací a souběžné verze na jednom virtuálu
  • Škálování: scaling plan, výběr VM a burstable B-series
  • Náklady a licencování – per-user pricing, M365 licence a kde ušetřit
  • Monitoring přes AVD Insights a Log Analytics, správa session hostů přes Intune
  • Zkušenosti z reálného nasazení u zákazníků HAVIT

Vzdělávací okénko prezentoval Jiří Gregor.

LLM wiki (Karpathy) [Daniel Hrubý, Vzdělávací okénko, 9.7.2026]

Jak jsme LLM Wiki (dle Karpathyho) nasadili na reálný klientský projekt: ingest, lint a wiki query v praxi.

  • Praktická implementace Karpathyho konceptu LLM Wiki na reálném klientském projektu
  • Proč je wiki „kompilát“ zdrojů (nahrávky porad, e-maily, brainstorming s Claude), a ne RAG nad syrovými daty
  • Jak fungují skilly Wiki Ingest, Wiki Lint a Wiki Query a k čemu slouží canonical vs. draft stránky
  • Jak wiki detekuje konflikty mezi novým rozhodnutím a historií projektu
  • Zkušenost s lokálními modely (a proč zatím prohrávají na delším kontextu)
  • Jak wiki pomáhá generovat Confluence user story rovnou s aktuálním kontextem

Koncept vychází z Karpathyho gistu „llm-wiki“.

Vzdělávací okénko prezentoval Daniel Hrubý.

Azure Data Factory – merge dvou SQL databází [Ondřej Václavek, Vzdělávací okénko, 28.5.2026]

Jak sloučit dvě velké SQL databáze v Azure bez psaní SQL scriptů? Migrace přes Azure Data Factory krok za krokem.

  • Proč zvolit Azure Data Factory místo lokálních SQL scriptů nebo cross-database dotazů
  • Nastavení Managed Identity a oprávnění pro zdrojovou (db_datareader) a cílovou (db_owner) databázi
  • Připojení SQL serveru v privátní síti přes Private Endpoints
  • Parametrizace Linked Services a datasetů (database / schema / table jako parametry)
  • Trik s mapovací tabulkou místo ručního výčtu 120+ tabulek
  • Pipeline Lookup → ForEach → Copy activity
  • Vypnutí check constraints kvůli referenční integritě i výkonu
  • Paralelizace kopírování (15 workerů) a její úskalí
  • Pricing Azure Data Factory pro jednorázové vs. opakované migrace

Vzdělávací okénko prezentoval Ondřej Václavek.

Potřebujete pomoct s Azure? Podívejte se na naše služby: Microsoft Azure.

Jak jsme začali používat Copilot v dotnet/runtime [Jiří Činčura, Vzdělávací okénko, 16.6.2026]

Jak tým .NET začal používat GitHub Copilot v dotnet/runtime? Praktické zkušenosti, workflow i limity AI agentů.

  • Co je dotnet/runtime a proč je nasazení AI v repu se 14 miliony řádků kódu výzva
  • Proč se AI agent chová jako junior bez paměti – každý úkol řeší od nuly
  • Jak si zdokumentovat testovací workflow (inner/outer loop) a kdy psát asserty
  • Generování testů podle RFC/specifikace místo podle existující implementace
  • Refactoring a psaní testů jako ideální use case pro coding agenta
  • Když agent tvrdí „mám hotovo“ a nemá – magická klauzule „nepřestávej, dokud nemáš hotovo“ a problémy s velkým context window
  • Reálné pull requesty (např. optimalizace filtru v Directory.GetFiles na Windows)
  • Reprodukce bug reportů – agent vyrobí čistý copy-paste repro
  • Různá workflow: web na GitHubu, Copilot coding agent, Copilot CLI, VS Code – najít to svoje
  • Plně automatizované úlohy: generování dokumentace, hledání duplicitních issue, kontrola testů v PR

Vzdělávací okénko prezentoval Jiří Činčura.

Novinky GitHub Copilot [Robert Haken, Microsoft Build Redelivery Praha 2026]

Novinky GitHub Copilot z Microsoft Build 2026: nová GitHub Copilot App, agentic workflows, přepojení Visual Studia na CLI SDK a migrace z Azure DevOps na GitHub.

🚀 Onboardujeme vývojářské týmy na AI – Copilot, agenti, MCP servery a disciplína, díky níž je vývoj s AI skutečně rychlejší: havit.cz/sluzby/ai-developer-onboarding

  • Cesta od „kodéra“ k AI operátorovi – proč Robert přestal používat Visual Studio
  • Šlechtění AI ekosystému: copilot-instructions.md / AGENTS.md, skilly a vlastní MCP servery
  • Paralelní práce na více sessionech přes Git worktrees
  • Visual Studio se přepojuje na GitHub Copilot CLI SDK – konec funkčního dluhu
  • GitHub Copilot CLI jako SDK: terminál je jen jeden z mnoha klientů
  • Visual Studio Code „Agents“ (Ctrl+Shift+A) pro paralelní agentní sessiony
  • Nová aplikace GitHub Copilot App: end-to-end workflow, agent merge, code review agent, cloud agenti i remote sessions (QR / mobil / web)
  • Migrace z Azure DevOps / Azure Repos na GitHub (oficiální doporučení Microsoftu) + zadávání práce z Azure Boards a code review agent nad Azure Repos (preview)
  • Code review agent na podvozku GitHub Actions – plnohodnotný agent s MCP a tooly
  • Agentic workflows: automatizace na GitHub Actions, security-first (sandbox, safe outputs, AI credit limity); příklady – auto-update dependencies, detekce DRY duplicit, triáž issues
  • Rubber duck agent s křížením modelů (Opus × GPT-5)
  • Chronicle: historie konverzací, podklady pro standup a tipy na efektivitu
  • Lokální sandbox, Security Review a firewall – security na prvním místě
  • Triky: fork session, „by the way“ dotaz a sdílení session přes Gist

Slides

Přednášku na Microsoft Build Redelivery Praha 2026 prezentoval Robert Haken.

🛠️ Migrace z Azure DevOps na GitHub – přestěhujeme vám repozitáře, aby vaši vývojáři neztráceli kontakt s AI (jako jsme to udělali sami): havit.cz/products/github-migration