Karpathy: od vibe codingu k agentic engineeringu [Wiki]

Tato stránka je pouze pro čtení. Můžete si pouze prohlédnout zdrojový kód, ale ne ho měnit. Zeptejte se správce, pokud si myslíte, že něco není v pořádku.
====== Karpathy: od vibe codingu k agentic engineeringu ======

//Vytvořeno: **3.5.2026** | Aktualizováno: **~~LASTMOD~~**//

[[https://www.youtube.com/watch?v=96jN2OCOfLs|Andrej Karpathy: From Vibe Coding to Agentic Engineering]] je rozhovor o tom, jak se programování s AI posouvá od rychlého „vibe codingu“ k disciplinovanější práci s coding agenty. Hlavní přínos videa je praktický: agenti můžou výrazně zrychlit vývoj, ale jen pokud člověk pořád drží odpovědnost za architekturu, zadání, verifikaci a kvalitu výsledku.

{{youtube>96jN2OCOfLs?}}

===== Shrnutí =====

Karpathy popisuje LLM jako nový druh programovatelného počítače. V tomto pohledu není hlavní pákou jen ruční psaní kódu, ale práce s kontextem, zadáním a prostředím, ve kterém agent kód upravuje. „Vibe coding“ zvyšuje dostupnost tvorby softwaru, protože umožní rychle vytvořit funkční prototyp. „Agentic engineering“ je naopak snaha zachovat profesionální laťku: rychlejší vývoj bez rezignace na bezpečnost, udržovatelnost a kontrolu.

===== Software 3.0: prompt jako program =====

Karpathy rozlišuje tři vrstvy softwaru:

  * **Software 1.0** — explicitně napsaný kód.
  * **Software 2.0** — modely vzniklé trénováním na datech.
  * **Software 3.0** — LLM jako interpret, který zpracovává obsah kontextového okna.

Praktický důsledek: významná část práce se přesouvá od psaní syntaktických detailů k navrhování kontextu. Programátor musí vědět, co chce postavit, proč to dává smysl a podle čeho se pozná správný výsledek. Agent může doplnit detaily API, boilerplate nebo konkrétní implementaci, ale nemá automaticky dobrý úsudek o architektuře ani doménových pravidlech.

===== Vibe coding vs. agentic engineering =====

Karpathy popisuje rozdíl zhruba takto:

  * **Vibe coding** zvyšuje „podlahu“. Více lidí dokáže rychle vytvořit software, prototyp nebo osobní nástroj.
  * **Agentic engineering** má udržet „strop“. Cílem je používat agenty tak, aby rychlost neznamenala zranitelnosti, špatnou architekturu nebo technický dluh.

Agentic engineering je tedy inženýrská disciplína koordinace agentů. Nejde jen o to „nechat model něco napsat“, ale připravit mu práci, průběžně ji kontrolovat, dávat mu zpětnou vazbu a ověřovat výsledek stejně přísně jako u lidského vývojáře.

===== Proč je důležitá verifikovatelnost =====

Podle Karpathyho jsou dnešní modely nejsilnější tam, kde lze výstup snadno ověřit. Kód a matematika jsou typické příklady: existují testy, kompilace, typová kontrola, porovnání výstupů nebo jiné signály správnosti. Modely se navíc trénují v prostředích, kde lze za správný výsledek dát jasnou odměnu.

Z toho plyne praktické pravidlo: pokud má agent pracovat dobře, musí dostat smyčku zpětné vazby. Nestačí mu říct „implementuj funkci“. Lepší zadání obsahuje i způsob ověření:

  * jaké testy spustit,
  * jaký build musí projít,
  * jaké edge cases zkontrolovat,
  * jaké chování se nesmí změnit,
  * co má agent udělat, když test selže.

===== Zubatá inteligence modelů =====

Karpathy používá motiv „jagged intelligence“ — schopnosti modelů nejsou rovnoměrné. Model může zvládnout rozsáhlou refaktorizaci nebo hledání chyby v kódu, ale zároveň selhat v banální úvaze mimo dobře trénované a snadno ověřitelné domény.

Pro práci s coding agenty to znamená:

  * nenechávat agenta bez dozoru jen proto, že před chvílí zvládl těžký úkol,
  * rozlišovat mezi úkoly uvnitř „silné zóny“ modelu a úkoly, kde chybí jasná verifikace,
  * dávat agentovi testy, nástroje a konkrétní kritéria úspěchu,
  * počítat s tím, že některé chyby budou logické, ne syntaktické.

===== Workflow pro práci s AI coding agentem =====

Praktické workflow z videa se dá převést do tohoto postupu:

  - **Definovat záměr a hranice úkolu.** Nejdřív musí být jasné, co se má změnit, proč a co je mimo scope.
  - **Připravit kontext.** Agent potřebuje relevantní soubory, popis architektury, doménová pravidla a případné existující konvence projektu.
  - **Nechat agenta navrhnout plán.** Před implementací je vhodné chtít krátký plán změn, aby bylo možné zachytit špatný směr včas.
  - **Implementovat po menších krocích.** Menší změny se lépe kontrolují a lépe vrací zpět.
  - **Spustit ověření.** Agent má použít testy, build, lint, typovou kontrolu nebo jiný dostupný feedback loop.
  - **Udělat lidské review.** Člověk kontroluje architekturu, doménovou logiku, bezpečnost, datové vazby a udržovatelnost.
  - **Iterovat.** Zjištěné chyby se vrací agentovi jako konkrétní zpětná vazba, ne jako obecné „oprav to“.

===== Jak zadávat práci agentovi =====

Ve videu nezazněla sada hotových promptů k okopírování. Užitečné jsou hlavně zásady zadávání:

  * **Popiš cíl i důvod.** Agent má vědět, jaký problém řeší, ne jen jaký soubor má upravit.
  * **Vymez scope.** Explicitně napiš, co se měnit nemá.
  * **Přidej acceptance criteria.** Výstup musí splnit konkrétní podmínky.
  * **Přidej ověřovací příkazy.** Pokud existují testy nebo build, agent je má spustit a výsledek použít k opravám.
  * **Uveď doménová pravidla.** Typický příklad z videa je nutnost vázat externí služby přes unikátní user ID, ne přes e-mail, protože e-mail nemusí být bezpečný nebo stabilní identifikátor.
  * **Vyžaduj jednoduchost.** Modely mají tendenci generovat objemný kód, duplicity a křehké abstrakce. Jednoduchost musí být explicitní požadavek.

Příklad struktury zadání pro agenta:

<code>
Cíl: Uprav X tak, aby Y.
Kontext: Projekt používá A, B a C. Důležité soubory jsou ...
Omezení: Neměň veřejné API. Nepřidávej novou závislost bez důvodu.
Doménová pravidla: Pro párování účtů používej interní user_id, ne e-mail.
Ověření: Spusť testy ... a build ...
Výstup: Nejdřív napiš plán, potom proveď změnu a nakonec shrň, co bylo ověřeno.
</code>

===== Prostředí připravené pro agenty =====

Repozitář a infrastruktura by měly být „agent-friendly“. To znamená, že agent má mít čitelné instrukce, bezpečný prostor pro práci a nástroje, kterými může výsledek sám ověřovat.

Užitečné prvky:

  * **README a dokumentace pro agenta.** Dokumentace nemá být jen pro člověka v prohlížeči, ale má obsahovat části, které lze vložit do kontextu agenta.
  * **Testy a skripty.** Agent má vědět, jak spustit jednotkové testy, integrační testy, lint, typovou kontrolu a build.
  * **Jednoduché lokální spuštění.** Čím snadněji lze projekt spustit, tím snadněji agent opraví vlastní chyby.
  * **Verzování a malé diffy.** Git diff je základní kontrolní plocha pro review práce agenta.
  * **Sandbox.** Agent by měl pracovat v prostředí, kde může bezpečně spouštět příkazy a dostávat chybové hlášky, ale nemůže poškodit produkci.
  * **Automatizované API místo klikání v UI.** Pokud lze službu nastavit skriptem nebo API, agent s ní dokáže pracovat lépe než s ručním nastavováním v administraci.

===== Failure modes =====

Největší rizika nejsou jen syntaktické chyby. Často jde o chyby v úsudku nebo návrhu:

  * **Logická chyba v doméně.** Agent může použít zdánlivě rozumnou zkratku, která je v reálném systému špatně — například propojit účty přes e-mail místo stabilního ID.
  * **Kódový balast.** Modely často generují více kódu, než je potřeba, kopírují podobné části a vytvářejí zbytečné abstrakce.
  * **Křehká architektura.** Výsledek může fungovat na happy path, ale špatně se rozšiřuje nebo rozbije při změně vstupů.
  * **Falešný pocit jistoty.** Agent umí znít přesvědčivě i ve chvíli, kdy nemá dost kontextu.
  * **Překročení scope.** Agent může opravovat vedlejší věci, měnit formátování nebo přidávat závislosti bez jasného důvodu.

Člověk má proto zůstat odpovědný za vkus, úsudek, architekturu, bezpečnost a finální integraci.

===== Checklist pro zadání agentovi =====

  * Je jasně popsaný cíl změny?
  * Je popsané, proč se změna dělá?
  * Je omezený scope?
  * Jsou uvedené soubory, konvence nebo relevantní dokumentace?
  * Jsou napsaná doménová pravidla, která agent nesmí odhadovat?
  * Jsou definovaná acceptance criteria?
  * Ví agent, jaké testy nebo build má spustit?
  * Má nejdřív napsat plán před změnou?

===== Checklist pro review výstupu =====

  * Je diff malý a odpovídá zadání?
  * Nezměnil agent něco mimo scope?
  * Prošly testy, build, lint nebo typová kontrola?
  * Nejsou v kódu duplicity, zbytečné abstrakce nebo balast?
  * Jsou správně vyřešené identifikátory, oprávnění a hranice dat?
  * Funguje řešení i mimo happy path?
  * Je jasné, co agent ověřil a co neověřil?

===== Co vyzkoušet =====

  * Vzít menší reálný úkol v existujícím repozitáři a zadat ho agentovi se scope, plánem a ověřením.
  * Nechat agenta nejdřív jen přečíst projekt a navrhnout plán bez změn.
  * Přidat do projektu krátký dokument typu „jak má agent pracovat v tomto repozitáři“.
  * Porovnat výsledek dvou přístupů: volné zadání vs. zadání s acceptance criteria a testovacím příkazem.
  * Použít jiného agenta nebo model jako reviewer výstupu prvního agenta.

===== Zdroje =====

  * [[https://www.youtube.com/watch?v=96jN2OCOfLs|Andrej Karpathy: From Vibe Coding to Agentic Engineering]]