Karpathy: od vibe codingu k agentic engineeringu

Vytvořeno: 3.5.2026 | Aktualizováno: 03.05.2026 14:04

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.

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.

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.

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.

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.

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

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

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:

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.

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.

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.

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?

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?

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.