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. Cesta od nápadu do produkce se u těchto změn zkrátila z týdnů na dny.

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 běžně 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ž prošly čtyři jeho pull requesty.

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.

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

Cesta od nápadu do produkce se u jednodušších změn zkrátila z týdnů na dny. Před nasazením čekala malá úprava BETY2 na zadání, předání a volnou kapacitu vývoje — dohromady typicky několik týdnů. Čtyři změny, které product owner dodal s Claude Code, prošly od nápadu po nasazený produkční kód v řádu dnů: jediným zbývajícím předáním je samotné code review.

Čas vývojářů na jednoduchou změnu klesl z implementace na review. U těchto změn už vývojáři HAVITu netráví hodiny implementací podle psaného zadání — jejich prací je revize funkčního pull requestu. Implementační úsilí se přesunulo na product ownera a Claude Code.

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

  • 4 pull requesty od product ownera Broker Trustu zrevidovány a nasazeny do produkce
  • Čas od nápadu do produkce u těchto změn: dny místo týdnů
  • 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]

Zanechat odpověď

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]

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

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

Zanechat odpověď

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]

Zanechat odpověď

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]

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.