Vlákno názorů k článku Většinu aplikace už si zákazníci díky AI vytvoří sami. Zakázková tvorba softwaru přišla o obchodní model, říká česká firma od narg - Osobně si nemyslím že nastane doba kdy se...

Osobně si nemyslím že nastane doba kdy se bude všechno jen vibe-codovat bez hlubší znalosti kódu. Vyvíjet něco co se používá jako tool interně pomocí vibe-codingu je v pořádku a je to fajn. Ale vyvíjet něco co se připojí na internet, případně např. něco co pracuje s velkým objemem dat (ideálně ještě s daty které mají nějakou retenci) bez kontroly programátorem že to dělá správně mě přijde docela dobrý hazard.

Problém je, že bezpečnost kódu, jeho kvalita, udržitelnost... nikoho nezajímá dokud se nestane průšvih. Do prvního průšvihu všechny, až na naprosté vyjímky, zajímá jen cena na faktuře.

Předesílám, že píšu z úplně opačné pozice, než jsou weby, o kterých mluvíš. Mám vlastní PHP framework, dělám na něm 18 let a běží na desítkách webů, které sám spravuji. Takže já jsem ten nejlepší možný případ a ty opuštěné bastly ten nejhorší.

A právě v tom je podle mě háček. U těch desítek tisíc webů není nikdo, kdo by tu AI vůbec spustil. Není to o ceně nástroje, chybí tam člověk. Kdo dneska neplatí za upgrade z PHP 5, nezaplatí ani pár dolarů za AI, protože o tom, že mu web běží na prehistorickém PHP, většinou ani neví. A i kdyby to nechal přepsat, nemá nikoho, kdo by ten výsledek po AI zkontroloval, což je u přepisu kódu ta dražší část.

U sebe jsem upgrady až do PHP 8.1 dělal zdarma, čistě ve vlastním zájmu. Když všechny weby držím na posledním PHP, nemusím udržovat zpětnou kompatibilitu, jádro je malé, rychlé a míň kódu znamená i míň hypotetických děr. I u aktivních klientů, co za rok potřebují změnit nějakou blbost za hodinu práce, se to dlouhodobě vyplatí. A šlo to i bez AI. Většina změn byla popsaná v changelogu, takže jsem si na to napsal skript, který to opravil hromadně na všech webech a druhý, který pak všechny stránky proklikal a přečetl logy. Náročnost vyskočila teprve u type errorů. Tam už jsem u velkých projektů s desítkami MB kódu v modulech dal cenu za sníženou hodinovku, s tím že jestli budou někdy chtít jakoukoli změnu, zaplatí to tak jako tak, protože je na poslední verzi upgradovat budu muset, opravovat azbestovou střechu nebudu.

Bezpečnost jako argument pro upgrade moc neberu. I na 5.6 se dá provozovat bezpečný web, když programátor ošetří vstupy. To, jak jsem to řešil před dvaceti lety, používám dodnes a vylámal si na tom zuby i sám Fable. Nejdřív mi to označil za díru a až když jsem mu řekl, ať se podívá, jak ta třída reálně funguje, uznal, že je to nenapadnutelné. Názor si udělal podle toho, jak se funkce jmenuje a jak zdánlivě vypadá, dovnitř se nepodíval. U modelu, který se prezentuje jako dobrý na bezpečnost, mě to zaráží, protože vhodně pojmenovaná funkce mu takhle klidně proklouzne. A to je i můj problém s tím přepisem legacy kódu za pár dolarů.

Takže k té otázce, jestli je AI přepis lepší než nechat to zakonzervované. U jednoduchého pětistránkového webu asi ano, tam je to skoro jedno, ty weby jsou tak primitivní, že u sebe je přenáším kolikrát ctrl+c ctrl+v. U čehokoli složitějšího bych tomu zatím nevěřil, viz výše. To, co za upgrade chtějí některá studia, je pak ještě jiná story. Slyšel jsem i desítky tisíc za něco, kde rozdíl mezi verzemi PHP nebyl nijak zásadní, protože to studio muselo upgradovat samo od sebe, kolik práce to je nakopírovat stejný kód dalším? Pak se nedivím, že to klient odmítne.

Rozdíl je totiž v tom, co se upgraduje. Svoje jádro znám a mám ho pod kontrolou. Upgradovat cizi práci, wordpress s nastahovanými děravými šablonami a moduly, je vždycky opruz. Ostatně stejně jako pro mě je opruz aktualizovat těch pár 3rd party knihoven, co v jádře mám. Ale to je daň za to, že je člověk nemusí psát sám a vymýšlet kolo, ale i to jde a i proto je nutné udržovat weby aktuální, protože často byla díra v těch 3RD věcech a přitom by ty opravené věci už nejeli na starším php, bez aktualizace nemůžeš zalepit cizí díru - nezodpovědné. I apple pokud vyjde díra pro nepodporovaný telefon vydá fixy... pokud je to vážné, tomu se říká zodpovědný přístup k dodané službě a práci. Tu ale většina patlalů, co dělala a dnes dělá weby s AI vůbec nemá.

Jo, po mě pokud chtěli překopat cokoliv jako je WP, Joomla, tak jsem to udělal jen tak, že to byla simple záležitost o pár stranách, kde nebylo moc modulů, jinak jsem je poslal někam pač by se to nevyplatilo a opravovat ten bordel ve WP nechtěl ale to proto, že WP neznám, nepoužívám na takové úrovni abych to dokázal levně debugovat. Dneska s Claude, to klidně překopu a je pro mě tedy furt méně práce to překlopit na svůj FW, proto, že ten WP podle mě je stejně otázka času, kde se tam ukáže něco jiného. Protože bez znalosti WP, Joomla na hloubkové úrovni podle mě člověk nemůže pořádně kontrolovat co mu claude vypotí a fakt často mi claude vypotí neskutečné prasácký kód, který si i schválí přes review... a to má celkem striktní zadání a předlohu jak to má vypadat. Neděje se to často, ale občas jo a bez kontroly by to tam bylo a kupilo se to.

Jj, názor ve stylu "paninko, máte to spravené a kdyby to začlo protékat, tak mi zavolejte. Ju?" Nevyvíjet v současnosti software s bezpečnostními prvky (secure by design), považuji za šlendrián.

Jinak přeji hodně zdaru s "levnými čínskými open modely". Určitě to pak dopadne fanfárově.

Jen částečně souhlasím, hodně chyb tam je a jsou známé, často se opravili až v 8 verzi... přesto si stojím za tím, že lze provozovat bezpečnou aplikaci.

Jako příklad uvedu jednoduché weby, kde není uživatelský vstup, protože většinu zranitelností jde reálně zneužít jen přes uživatelské vstupy a pracováním s nimi, to ostatně platí i pro novější verze, nevíme kolik tam je chyb a jsou stejně rizikové jen je zatím nikdo nenašel.

Celá bezpečnost je vždy založena na to, co do aplikace pustíme, pokud aplikace pouze zobrazuje, pak je prakticky vyloučeno aby se do ní někdo dostal. Další typ může být rozsáhlý systém ale za loginem, ano tam už bude možnost zneužití systému, protože může být kompromitovaný samotný autorizovaný uživatel ale to je za mě přijatelné riziko a padá na toho poučeného uživatele, samozřejmě pokud to jde, vždy doporučím modernizaci. Jen tvrdím, že nelze obecně tvrdit, že vše staré je automaticky špatné. Vždy je třeba vědět s jakými daty se pracuje a to včetně věcí na které se zapomíná, třeba data uložená v cookies nebo prohlížeči...

To je pravda. Ale otázkou je, jestli to vůbec souvisí s AI.

Kolik myslíte, že před cca 10+ lety bylo upatláno webů na PHP 5, které dodnes běží a tu prehistorickou verzi PHP pořád vyžadují? Řekl bych, že jich jen v ČR budou minimálně desítky tisíc. A ten model je pokaždé stejný - někdo si nechal udělat webové stránky a v tom lepším případě jim webové studio nabídlo po pár letech upgrade kódu na PHP 7, kterou zákazník kvůli ceně odmítl ... a v tom horším případě jim to ani nikdo nenabídl.

A pokud to vezmu hodně pragmaticky ... pokud tenhle legacy kód AI za pár dolarů přepíše do něčeho co běží na aktuální verzi, tak je to určitě lepší než když se to nechá zakonzervované tak jak je to teď.

GDPR, NIS2, CRA, však ono je to začne zajímat velmi brzy, pokud ještě nezačalo :).

Je to teď velké téma, pohybuji se v zakázkové výrobě SW a nevidím, že by nás AI nahradilo ani v budoucnu. SW stejně bude muset někdo rozumnět, někdo ho spravovat, udržovat, provozovat. Pokud tohle vše necháš na LLM, už dnes ty částky začínají být mnohem vyšší než fee, které běžně za aplikace bereme.

Bezpečnost kódu, jeho kvalita, udržitelnost moc lidí nezajímala ani předtím. Release first, fix later. Když nad tím bude člověk/firma, které zákazník může zadat, aby problém opravila, tak je jedno, že pod pokličkou, pod seniorem, nejsou junioři ale AI.

Po smrti je hromada SW, něco jde přepsat, něco nejde přepsat, něco nedává smysl přepsat, polemizovat můžeš jak chceš. Aby někdo zneužil díru ve starém PHP musí první zjistit, že tam to PHP běží, musí tam mít nějaké vhodné podmínky, musí mít zájem. Běželo nám na 5.6 na jednom legacy projektu do roku 2024, denně jsou to tisíce pokusů co končí v lozích a za ty roky vím jediné, 99.9% všech útoků je prakticky jak přes kopírák, cílí to na známá místa.

Takže ano, můžeš předpokládat, že tam chyba někde je a pravděpodobně je. Ale stejně tak můžeš předpokládat, že tě srazí zítra auto. Ta šance je dost možná pravděpodobnější u toho sražení autem, než, že se sejde tolik proměnných aby někdo na neznámém serveru, kde běží neznámý kód a neznámé verzi php bušil na správné místo, kde by se něco stalo...

Nemusíme fakt polemizovat o tom, že to bylo lepší překopat, bylo, jen na to nebyl prostor, protože to využívalo custom extensions pro php. Bezpečnost v IT není o tom, že se snažíš o 100% tomu normální člověk nevěří. 100% bezpečnost je vytažení kabelu ze serveru... Jde o míru rizika, za mě je ve spoustě situací zanedbatelná. Osobně vidím větší riziko provozovat aktuální WP na aktuálním PHP, než nějakou vykopávku na mrtvém php :)

Nezlehčuju to. Souhlasím, že 5.6 není bezpečné samo o sobě. Tvrdím, že riziko se dá řídit, když je na tom systém od začátku postavený.

Ptáš se, jak vůbec poznáme průlom. Přesně na to máme systém včasného varování: průběžná analýza access logů, každý request mimo existující index daného webu spustí výstrahu. Běží roky. Díky němu jsme dva roky před zákazem Joomla/WP/Drupal na serveru viděli tvrdá data: i aktualizovaný web vydržel průměrně půl roku, než se na disku objevil trojan nebo base64 nález v DB. I ty čtyři, co zůstaly v read-only režimu bez zápisu na disk, měly co chvíli plnou DB borelu, na posledním PHP, aktuální. Proto postupně odchází.

Klíč je pro mě attack surface. Když jediné vstupy na front části proženeš striktním regulárem, kterým projdou jen povolené hodnoty, nečteš nic z cookies ani z klienta a není tam upload, většina automatizovaných i adaptivních útoků nemá o co se opřít. Riziko roste s prvním formulářem a násobně s nahráváním souborů, přes obrázky šlo infikovat weby ještě na 8.2/8.3.

A čeho jsem se vždy bál nejvíc, není průnik zvenčí, ale ukradená session autorizovaného uživatele, za branami už nástroje zneužít jdou. Ten vektor je mimochodem stejně nebezpečný na 5.6 jako na 8.4.

Takže ne „je to bezpečné, protože se nic nestalo". Spíš: víme, jak by se průlom projevil, aktivně to měříme a plocha útoku je minimální. A ne, není to návod pro ostatní, kdo nemá monitoring a minimální surface, ať to fakt nedělá. Ale pokud víš co děláš, co riskuješ, tak není problém porušit obecná pravidla.

Pravidla jsou primárně od toho aby pokrývali průměrný mainstream, nikdy nebudou zohledňovat situace, kdy to individuálně potřebuješ udělat jinak a nejde automaticky říkat, že aktualizace nás všechny spasí...

Zero day chyba se ti může objevit i v novém php a majorita serverů na to nijak nezareaguje :)

9. 8. 2026, 06:55 editováno autorem komentáře

to jsou záplaty, to není systémový problém, za chvilku se tam objeví nová zranitelnost nebo ta oprava nějakou udělala sama. Pokud mu o toho ještě nepromaže, data, je to super.

Pro zajímavost, zkušenost bráchy s AI (Claude) a WordPress (PHP). Web mu někdo napadl, klikání otevíralo občas reklamy. Claude mu odstranil závadné skripty z napadených kódů a popsal a následně zacelil díry ve starých pluginech, přes které se tam útočník dostal. Pro bráchu to bylo levnější a rychlejší, než řešit upgrade PHP, WordPressu a jeho pluginů na aktuální verzi (to jsme dříve zažili s jeho prvním blogem). Takto nikoho nepotřeboval. Mně, jako "jeho programátorovi" to řekl až zpětně.

3. 8. 2026, 22:33 editováno autorem komentáře

největší problém je, že dnes už v php 5.6 po smrti, nové chyby se v něm nezveřejňují a můžeš být v slepém pocitu bezpečí.

Jak už tu bylo řečeno, 99,9 % útoků je plošných. Když se někdo zaměří na tebe konkrétně, tak ti nepomůže aktuální záplatovaný systém. Když někdo moc chce, tak se třeba spojí s někým v tvé firmě. Zadní vrátka se dají i vyrobit (nebyl to myslím případ knihovny xz?).

Ne, na php 5.6 není nic bezpečného. I když samotná aplikace bude napsaná dobře, tak to PHP má hromadu zranitelností které nikdo nikdy neopraví. Provozovat cokoliv na PHP 5.6 je jízda na mrtvém koni.

Moderní programátor by měl AI používat asi jako bagr na stavbě .... na přesuny velkých hnot je to super nástroj, který vyřeší skoro vše .... levně, rychle a efektivně. Ale občas je potřeba z toho bagru vystoupit, vzít do ruky lopatu a kolem té chráničky s optikama to udělat opatrně a precizně.

5. 8. 2026, 14:51 editováno autorem komentáře

No hlavne AI act na ně a jejich zákazníky dopadne plnou silou koncem roku 2027 a to bude jejich konečná, tenhle naivní přístup může fungovat jenom teď.

Jaká konečná? AI Act reálné (mimo systémy do armády, zdravotnictví apod) jen říká, že máme uvést, že pro vývoj byla použitá umělá inteligence. Ale to se děje už dávno. Uvádíte to u hry na Steamu, u videa na YouTube, ... Moderní AI first firmy se tím dokonce chlubí. Naivní přístup je spíš outsourcing do Indie nebo nějakému juniorovi.

teď díky AI se začínají masivně šíři adaptivní útoky, kdy to není blbý brute force na stejnou zranitelnost přes miliony zařízení, ale prostě to kouká více na cíl.

Argument, roky to běželo a nic se nestalo je dost hloupý, nic neprokazuje, chtěl bych vidět jak dokážete vůbec zjistit, že k průlomu došlo a někde tam nesedí nějaký vyčkávací program.

Ani ten kabel už dneska není bezpečnost, protože se dá komunikovat spoustou dalších signálů, to bys musel vytáhnout napájecí kabel a nemít tam interně baterku, která drží nějakou management konzoli.

Chápu, prostě nebyly peníze a čas to napravit, ale prosím neobhajuj to, že to je vlastně bezpečné a nezlehčuj to pro ostatní, není to bezpečné, je to volovina to takhle dělat.