Proč kód z AI potřebuje lidskou kontrolu (a proč to není problém)

Dneska se vývoj softwaru mění rychlostí světla. Nástroje jako Claude nebo ChatGPT dokážou z nápadu udělat funkční kód během dní, ne týdnů. Popíšete funkci, schválíte změny, doladíte a nasadíte. To zrůznorodňuje tempo práce.

Jenže je tu háček.

Nedávno jsem prohlížel kód takového rychle postaveného interního nástroje. Nic kritického, ale typické pro rok 2024. Žádné sci-fi katastrofy. Spíš obyčejné chyby: 28 problémů, většina bezpečnostních, z karet OWASP Top 10, co jsou známé od začátku tisíciletí.

Není to o tom, že AI je nebezpečné. Jde o to, jak rychlost předbíhá promyšlený design, který brání problémům.

Problém není v AI, ale v otázkách, co jste se nezeptali

Ten kód vypadal solidně. Architektura seděla, knihovny byly v pořádku, vše faktorovano. Kdybych to dělal sám o víkendu, nedalo by se odlišit na první pohled.

Rozdíl je v předchozím kroku. Než se napíše první řádek.

AI exceluje v tom, co mu řeknete. "Udělej systém pro správu uživatelů" – a máte ho. Ale neptejte se samo: Kdo k tomu má přístup? Jaké data jsou citlivá? Kde je autentizace? Co když někdo obchází frontend?

Dostanete funkci. Ne architekturu, která vás uklidní.

Příklad z praxe: Admin funkce bez ochrany

Představte si serverless funkci pro admina – vytváření uživatelů, reset hesel, mazání účtů. Klasika. Tým správně schoval klíče na serveru, ne v prohlížeči.

Funkce neměla žádnou autentizaci.

Ne slabou, ne špatnou. Žádnou. Stačilo otevřít DevTools, najít endpoint a poslat POST. A máte admin práva, resetujete hesla nebo mažete databázi.

Frontend skrýval tlačítko pro nepovolané – vypadalo to bezpečně. Ale bezpečnost v UI je iluze.

Tohle je klasický bypass autorizace z roku 2003. AI to nezmínilo, protože prompt zněl: "Funkce pro admina na vytváření uživatelů." Dělá to. A dovolí to i ostatním, protože jste to nezakázali.

Klíč: AI neví, co jste zapomněli říct.

Databáze bezpečná na papíře

Další typický případ. Databáze má row-level security (RLS) – omezuje přístup k řádkům podle uživatele. Skvělé, zvlášť když frontend posílá API klíč v JS.

Inženýr řekl AI: "Přidej podporu více uživatelů." AI napsalo migrace, nové tabulky s RLS. Super.

Ale pět starých tabulek s reálnými daty? Žádná změna. RLS možná bylo zapnuté, možná ne. Migrace to nekontrolovala.

Spusťte npm run db:push na čistém prostředí – nové tabulky zamčené, staré otevřené pro kohokoli s endpointem.

AI neudělalo chybu. Jen to řešilo úzký úkol, bez otázky: "Chcete vše zabezpečit?"

Co to znamená pro váš tým

Tohle neznamená, že AI odmítáme. Rychlost je zlatá. Ale potřebujete zkušené oči na architektuře, ne jen na syntaxi.

Co funguje:

Mějte bezpečnostní checklist před startem. Otázky jako: Kdo volá endpoint? Co když bez oprávnění? Jsou data veřejná? Potřebují všechny tabulky RLS? Zapište předpoklady.

Seniori dělají threat modeling, ne jen review řádků. Ty 28 chyb nebyly preklepy. Byly architektonické díry. AI píše kód, lidé myslí bezpečnost.

Buďte explicitní v promptech. Místo "endpoint pro uživatele" řekněte: "Endpoint pro admina s autentizací, popiš předpoklady." AI tak odhalí své myšlenky.

Testujte autorizaci zvlášť. Ověřte, že nepovolaní nemohou nic udělat, ne jen že povolaní mohou.

Hlavní lekce

AI negeneruje špatný kód. Je skvělé v tom, co řeknete, a špatné v tom, co zapomenete.

To je výhoda – nereaguje na vymyšlené požadavky. Ale zodpovědnost je na vás. AI nevymýšlí bezpečnost. Provádí vaši vizi rychle.

Ten kód opravili za minuty, jakmile někdo řekl: "Tady chybí autentizace." Starý problém narazil na nový workflow – a vyhrál, díky zkušenému oku.

Budoucnost: AI pro rychlost, lidé pro architekturu. Oba nutné.

Chcete se vyhnout těmto pastím? V NameOcean vidíme, jak rychle rostoucí startupy boří tech debt z uponáhľaných funkcí. Naše cloud hosting platforma má vestavěnou bezpečnost – rate limiting, management API klíčů, audit logy. Fungují automaticky, i když na ně zapomenete. Můžete se soustředit na rychlé nasazování.