Category Archives: AI

M365 Copilot a Goran MCP server [Igor Vít, Vzdělávací okénko, 4.9.2026]

Zanechat odpověď

Jak zpřístupnit Goran MCP server v Microsoft 365 Copilot? Copilot Studio, konektor, Entra ID auth a publikace agenta.

  • Srovnání práce s Goran MCP serverem v Claude vs. v M365 Copilot a Teams
  • Koncept agent → konektor → connection v M365 Copilot
  • Konfigurace MCP konektoru v Copilot Studio krok za krokem (Entra ID, client ID, secret, scope)
  • App registration a redirect URL – co je potřeba zařídit
  • Publikace agenta do kanálů Microsoft 365 a Microsoft Teams
  • Monitoring a logování MCP serveru v Copilot Studio
  • Jaké licence potřebujete (M365 Copilot, Copilot Studio)

Vzdělávací okénko prezentoval Igor Vít.

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

Zanechat odpověď

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

Zanechat odpověď

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

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

Zanechat odpověď

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

Zanechat odpověď

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.

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

1 Reply

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ý.

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

Zanechat odpověď

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

2026-06-15 – MS Build Redelivery – Novinky v GitHub CopilotDownload

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

HAVIT Agents – lightweight platforma pro běh AI agentů – představení PoC [Jakub Nábělek, 26.5.2026]

Zanechat odpověď

Vlastní lightweight platforma pro běh AI agentů. Cesta od Copilot Studia přes Cloud Console k vlastnímu řešení – HAVIT Agents PoC.

  • Proč Copilot Studio a Cloud Console nestačily na naše use casy
  • Architektura HAVIT Agents – projekty, agenti, billing a cost capy
  • Token-level pricing pro input / output / cache input / reasoning output
  • Model providers: AI Foundry, Anthropic, Azure OpenAI, lokální modely
  • Konektory (Azure DevOps, Atlassian) na třech úrovních – globální, projektové, agentní
  • Prompt Library jako sdílené centrální místo pro šablony promptů
  • Triggery agentů: manuál, file monitor (blob storage), schedule, webhook
  • File Monitor Providers – agent reaguje na soubory v blob storage
  • Memory Providers – persistentní paměť mezi běhy agenta
  • Notifikace přes e-mail a Microsoft Teams webhook
  • Artefakty: vstupní a výstupní soubory každého běhu agenta
  • Use cases: vyúčtování projektu, přepis Teams schůzky do Confluence, triage ticketů

Představil Jakub Nábělek.

🤖 Stavíme reálné AI systémy do produkce – agentní workflow, extrakce z dokumentů, RAG, evaluační rámce, které ustojíte před auditem: havit.cz/produkty/ai

AI v každodenní praxi vývoje software [Robert Haken, GitHub Copilot Dev Day Zlín, 26.5.2026]

Zanechat odpověď

Cesta od Visual Studia s Copilot autocomplete k agentnímu workflow – příběh, jak AI mění vývoj software v roce 2026.

  • Cesta od Visual Studia s Copilot autocomplete k plně agentnímu workflow
  • Always-on context: copilot-instructions.md, AGENTS.md a auto-generování přes „Adding Repository Custom Instructions“
  • Memory feature v GitHub Copilotu – kdy si nechat zapamatovávat a kam to uložit
  • Vlastní MCP server v C# (.NET) pro dokumentaci Havit Blazor stacku
  • Skills jako lazy-loadovaná část kontextu – Havit Blazor Stack skill napříč projekty
  • Vlastní marketplace s pluginy přes GitHub repozitář – sdílení skillů, MCP serverů a instrukcí v týmu
  • Visual Studio Code Insiders „Agents“ – víc coding agentů (Copilot + Claude Code) v jednom UI
  • Claude Code přes GitHub Copilot API („cloud necloud“ harness)
  • Migrace repozitářů z Azure DevOps na GitHub – oficiální doporučení Microsoftu, hybridní setup s ADO work-items a pipelines
  • AB# linkování mezi GitHub pull requesty a Azure Boards work-itemy
  • Cca 40 % triviální práce zadávané rovnou přes „Copilot“ tlačítko z work-itemu / PR
  • Reálný dopad: týmy z 5–10 lidí na 1–2 vývojáře + agenti, vibe-kódované pull requesty od produkťáků zákazníka

Aktualizovaná verze přednášky pro GitHub Copilot Dev Day Zlín 26.5.2026. Prezentoval Robert Haken.

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

🛠️ 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

Pomalé buildy v Claude Code na MacOS

Zanechat odpověď

Pokud na macOS pracuješ s Claude Code a ještě nemáš zapnutý sandbox, zapni si ho. Je to jediná smysluplná obrana, jak izolovat agenta od zbytku stroje — filesystem, síť, syscally — a riziko vážného průšvihu klesne řádově. Praktický návod, jak to nakonfigurovat, je třeba v článku Sandboxing Claude Code on macOS. Tenhle text předpokládá, že už ten krok máš za sebou — a popisuje jeden konkrétní side-effect, na který jsem narazil.

Symptom

Začalo to nenápadně — všiml jsem si, že Claude Code mi začal nezvykle dlouho trvat i jednoduché úkoly. Drobné refaktory, na které byl dřív zvyklý odpovědět během chvíle, najednou zabraly desítky minut. Když jsem se podíval pořádně, co se uvnitř session vlastně děje, ukázalo se, že agent opakovaně spouští dotnet build a každý jednotlivý běh mu trvá pět minut. Lokálně, ve vedlejším terminálu, ten samý build doběhne za sekundu.

Výstup z těch dlouhých běhů vypadal pokaždé identicky:

  Determining projects to restore...

Build FAILED.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:05:00.81

Pět minut, FAILED, a přitom nula chyb a nula varování. Build failed s 0 errors? Co to vůbec je? Buď build selhal a má nám sdělit proč, nebo neselhal — ale tyhle dvě věci dohromady jsou nesmysl.

Diagnostika

Nechal jsem to vyřešit samotného agenta — zajímalo mě, jakou cestou se k příčině dostane on. Co následuje, je jeho úvaha nahlas.

První rozumný tip byl NuGet restore — síť uvnitř sandboxu je omezená a v logu svítilo „Determining projects to restore“. Zkusil tedy --no-restore. Stejný výsledek. Tak možná zápisová práva do ~/.dotnet nebo ~/.nuget cache? Ne. Přidal --no-dependencies -v:m, nic. Pro jistotu pak pustil ještě jeden běh úplně mimo sandbox přes dangerouslyDisableSandbox: true — a build doběhl za 1,02 sekundy. Tím bylo jasné, že problém je 100 % sandbox.

Když běžná podezření zradila, sáhl po -v:diag — to MSBuild zaplaví výstup úplně vším, co se uvnitř děje. Hned na prvních pár desítkách řádků se objevilo:

(eval):1: nice(5) failed: operation not permitted

Příčina

Claude Code na macOS pouští každý Bash tool call přes Apple Seatbelt sandbox, který blokuje syscall setpriority() (běžně volaný přes nice). MSBuild defaultně forkuje worker nody (-maxcpucount), každý worker si při startu chce snížit svou prioritu přes nice(), sandbox volání odmítne — a worker se zacyklí v silent retry/respawn smyčce. Žádná chyba na stdout, žádný non-zero exit, žádné varování. Jen čekání, až dotnet sám zabije proces vlastním 5-minutovým watchdogem.

Klíčové na tomhle failure mode: MSBuild považuje nice failure za non-fatal, a worker fork stack se snaží vzpamatovat. Sandbox tedy nezablokuje build — jen mu odebere mechanismus terminace.

Řešení

Sandbox nenabízí granular syscall allow (Seatbelt na macOS to neumí filtrovat per syscall pro běžné uživatelské profily). Co Claude Code umí, je vyloučit konkrétní commands ze sandboxování:

{
  "sandbox": {
    "excludedCommands": ["dotnet *"]
  }
}

V ~/.claude/settings.json. Pozor na syntax — excludedCommands používá Claude Code permission-rule syntax, tedy prefix s wildcardem. Plain ["dotnet"] se s ničím nematchne a problém přetrvá. Po změně settings je potřeba session restart.

Výsledek: dotnet build v sandboxu 0,62 s, žádný nice retry-loop.