Vibe coding v Laravelu: AI agenti potřebují guardraily

Když se dnes řekne vibe coding, část lidí slyší budoucnost vývoje a část lidí slyší technický dluh. Obě reakce chápu. AI agenti mi reálně šetří čas, ale pouze tehdy, když pracují uvnitř jasných pravidel, automatizovaných kontrol a lidského review. Bez toho se rychlost snadno změní z výhody na past.

Tenhle článek je primárně o Laravelu, protože právě tam mám nejjasnější workflow s AI a nejsilnější guardraily. Princip ale není omezený na Laravel. Platí i pro jiné frameworky, menší Node.js nebo Python nástroje a někdy i pro malé aplikace bez frameworku. Stack mění podobu rizika. Neodstraňuje odpovědnost.

Vibe coding potřebuje odpovědnost, ne strach

Naivní verze vibe codingu stojí na tichém předpokladu: když výstup modelu vypadá přesvědčivě, bude nejspíš správný. Tady začíná rozdíl mezi hračkou a profesionálním vývojem. Kód není hotový ve chvíli, kdy se spustí. Je hotový až tehdy, když zapadá do architektury, řeší okrajové stavy, respektuje bezpečnostní hranice a dá se udržovat i za několik měsíců.

Proto produkční vibe coding nechápu jako „přijmi všechno“ a „pošli to ven“. Takový postup může působit rychle, ale náklady se jen přesunou do review, ladění a dlouhodobé údržby. Model nenese odpovědnost za rozbitý deploy, slabou autorizační kontrolu nebo migraci, která poškodí data. Tu odpovědnost nesu já.

Užitečná verze vibe codingu je pro mě blíž asistovanému inženýrství. Agent může zkoumat, navrhovat, vysvětlovat a připravit první verzi změny. Konečné rozhodnutí ale pořád patří vývojáři. Čím jasnější jsou kontroly, tím víc si mohu dovolit AI skutečně používat.

Laravel dává agentovi bezpečnější prostor

Laravel používám jako hlavní příklad, protože nabízí silný ekosystém: routing, validaci, Eloquent, queues, scheduler, autentizaci, testovací nástroje, Pint, Larastan, Pest, Rector a Laravel Boost. Tyto nástroje vytvářejí společný jazyk mezi projektem, vývojářem a agentem.

To je u vibe codingu důležité. Když agent generuje kód uvnitř frameworku, má větší šanci držet se známých hranic: route, controller, request, service, model, migration, test. Když ho nechám pracovat ve zcela volné struktuře, musím víc pravidel dodat sám. Framework z AI nedělá bezpečný nástroj. Jen mi dává víc míst, kde lze chyby zachytit.

Právě proto mi Laravel pro práci s AI vyhovuje. Framework už sám podporuje konvence a konvence jsou užitečné ve chvíli, kdy model potřebuje přemýšlet nad existujícím codebasem. Snižují počet náhodných rozhodnutí, která si agent může vymyslet.

Kdy používám menší stack bez frameworku

Vibe coding bez frameworku pro mě automaticky neznamená špatný nápad. U malých věcí může být naopak velmi efektivní. Občas použiji čistý Node.js, Python nebo téměř framework-free stack, když potřebuji malý nástroj s úzkým účelem.

Typicky jde například o:

• jednoduchý CLI skript nebo jednorázovou utilitu,

• malý interní nástroj pro zpracování dat,

• rychlý parser, import nebo export,

• proof of concept pro ověření nápadu,

• malou aplikaci bez rolí, plateb a složitých operací.

V takových situacích může být plnohodnotný framework zbytečná režie. Důležitý rozdíl je rozsah. Malý skript s omezeným vstupem, bez citlivých dat a bez ambice stát se dlouhodobým produktem má úplně jiný rizikový profil než produkční webová aplikace s uživateli, oprávněními, billingem, frontami a integracemi.

Čím méně struktury mi stack dává, tím explicitnější musím být já. Potřebuji README, jasné příkazy, základní testy, validaci vstupů a jednoduchý způsob, jak nástroj spustit i později. Malé neznamená nedbalé. Znamená to jen, že guardraily mohou být lehčí.

Jak vypadá reálná změna s AI agentem

Nejužitečnější AI workflow pro mě není zadání typu „přepiš celou feature“. Mnohem lépe funguje malá a dobře vymezená změna. Můžu agenta požádat, aby prošel existující Laravel feature, našel validaci, související testy a navrhl nejmenší potřebnou úpravu pro nové pravidlo.

Dobrý agent tady umí ušetřit čas. Zmapuje request flow, najde Form Request, upozorní na relevantní policy, navrhne feature test a připraví první implementaci. Tím ale práce nekončí. Tím začíná review.

Reálný příklad: agent přidá nové pole do Filament formuláře a upraví model. Na první pohled kód vypadá v pořádku. Larastan ale upozorní na nullable relaci, se kterou generovaný kód zachází jako s vždy dostupnou. Pest test zachytí, že uživatel bez oprávnění se pořád dostane na jednu cestu. Pint odstraní stylový šum, aby byl diff čitelnější. Rector může zjednodušit mechanickou část změny. Teprve potom čtu skutečné chování a rozhoduji, jestli změna do projektu patří.

To je rozdíl mezi používáním AI jako zkratky a používáním AI jako partnera pro návrh. Agent posune práci dopředu, ale kontroly rozhodují, zda je výsledek důvěryhodný.

Moje guardraily v Laravelu

V Laravel projektech jsou moje guardraily poměrně jasné. Laravel Pint drží konzistentní styl. Larastan a PHPStan zachytávají typové problémy, chybějící návratové hodnoty a předpoklady, které by se jinak schovaly až do runtime chování. Pest mi dává feature testy, unit testy, architektonické testy a type coverage. Rector pomáhá s mechanickým refactoringem a modernizací.

Workflow rád rozděluji do dvou vrstev. První vrstva opravuje kód tam, kde je to bezpečné. Druhá vrstva ověřuje, že změna může projít před mergem nebo nasazením. V praxi to znamená příkazy jako:

• composer refactor pro Rector a Pint opravy,

• composer test:refactor pro Rector dry run,

• composer test:lint pro kontrolu formátování,

• composer test:types pro statickou analýzu,

• composer test:type-coverage pro type coverage,

• composer test:arch pro architektonická pravidla,

• composer test:unit pro feature a unit testy,

• composer test pro celý ověřovací pipeline.

Právě tenhle pipeline je jádro celého workflow. Umožňuje agentovi pracovat rychleji, aniž bych mu musel slepě věřit. Pokud změna neprojde formátováním, statickou analýzou, type coverage, architektonickými kontrolami a testy, není připravená.

Laravel Boost zlepšuje kontext, ne odpovědnost

Laravel Boost si zaslouží samostatnou zmínku, protože kontext je jeden z největších problémů AI asistovaného programování. Obecný model může hádat, jak Laravel funguje, ale hádání je křehké. Ještě slabší je ve chvíli, kdy záleží na verzích balíčků, struktuře projektu nebo konkrétních frameworkových konvencích.

Boost pomáhá tím, že zpřístupňuje Laravel pravidla, dokumentaci odpovídající nainstalovaným verzím balíčků a informace o aplikaci. Agent tak dostává lepší výchozí bod. Může vycházet z konkrétnější znalosti místo toho, aby produkoval kód, který jen vypadá jako Laravel.

Neberu Boost jako magickou vrstvu, která z modelu udělá seniorního vývojáře. Beru ho jako způsob, jak snížit počet zbytečných chyb. Odpovědnost pořád zůstává na mně: přečíst diff, spustit kontroly, pochopit změnu a rozhodnout, jestli má jít ven.

Nejde o framework, ale o odpovědnost

Kritici vibe codingu mají často pravdu, když kritizují slepé používání AI. Kopírovat generovaný kód do produkce bez review není engineering. Je to hazard s lepším autocomplete. Úplně odmítnout AI ale zase ignoruje praktickou hodnotu, kterou už dnes má, pokud je zapojená do disciplinovaného workflow.

Kdybych měl svůj pohled shrnout jednou větou, řekl bych: AI mi šetří čas, ale nebere mi odpovědnost. Laravel je hlavní příklad proto, že mi dává silné guardraily, ale stejný princip platí i jinde. V malém Python nebo Node.js skriptu mohou být guardraily jednodušší. V produkční aplikaci musí být silnější.

Budoucnost, která mě zajímá, není slepý vibe coding. Je to spíš agentic engineering: jasný záměr, dobrý kontext, malé kroky, automatizované kontroly a člověk, který čte diff a rozhoduje. Framework pomáhá, ale skutečnou hranicí je pořád odpovědnost.