Na videu nebudou kocky v limuzine, ale napr. pismenka v terminalu, ktere davaji smysl a to se generuje fakt blbe.
Tak dej odkaz na YouTube na nějaké vygenerované AI video, kde se dělá něco složitého se software, borec je tam v terminálu, píše tam příkazy a dává to celé smysl jako by to bylo reálné.
A kdo a jak tohle bude pro boha kontrolovat? To jako budou vývojáři koukat denně na hodiny videí a snažit se odhalit, jestli v těch rozostřených pixelech náhodou je nebo není vidět validní kód? Nebo na AI videa pustíme pro kontrolu další AI? Koukat na video není práce a už vůbec to není užitečná práce, i když je tím mladá generace oblbovaná.
To už by dávalo větší smysl, aby se bugreporty posílaly poštou na papíře s rukou napsaným kódem a kontroloval to grafolog...
A kdo na ty videa bude cumet? Neznam horsi zpusob jak sdelit cokoli. Navod popsatelnej jednou vetou a je z toho 15 minut kecu ...
A k tomu nejaky attention whore (casto nespravne nazvany 'influencer') tam mava 5 minut rukami pred kamerou :D
To zahlcení ai slopem je občas vidět i tady na kresbičkách ke článkům. Je vidět, že je to automaticky generovaný random obrázek, nikdo si nedal práci s kontrolou a lepším promptem. Tahle "automatizace" jinak kvalitnímu obsahu vůbec nesedí.
12. 5. 2026, 07:19 editováno autorem komentáře
Pokud jde o obrázek k tomuto článku, tak přesně takhle to bylo záměrem, aby byl před článkem o AI slopu právě AI slop v podobě obrázku. Zkuste ale být prosím konkrétnější, který obrázek je podle vás problematický.
problematicky AI obrazek jsem nezaregistroval, vzdycky to nejak sedelo a tady to sedi taky
narazil jsem ale na podivne obrazky vybrane clovekem
1) kdyz p. Jezek pise o Vulkanu, tak obvykle se Spockem
2) ve starsich clancich o mold linkeru byl doprovodny obrazek plisen
souvislost chapu, ale oboje je/bylo tak desne vtipne, az to boli
Na toto téma tu byl článek před ani ne 14 dny: https://www.root.cz/clanky/o-chlapci-ktery-kricel-rce-a-budil-tim-slusne-unavene-lidi/
Každé jednoduché/rychlé řešení je zároveň nekvalitní a nedomyšlené řešení. Kvalita je vždycky vykoupena časem a náročnou kvalifikovanou prací a přípravou (což je zase čas). Ale to ve světě, kde se má časem mrhat na čumění na reklamu nebo zábavu, tak nějak nefunguje...
Taky pozorujeme obrovsky narust. U nas bych to rozdelil na:
1) skutecne problemy - tam o moc nalezu vice neni, nektere ale docela prekvapi. Je to treba kombinace drobne chyby a povolenych operaci, ktera vede k problemu.
2) hlaseni problemu ve historickych verzich, ktere jsou davno opravene - toho je opravdu hodne
3) hlaseni stejneho problemu treba 5 lidmi
4) nesmyslna hlaseni z nevydanych verzi (jen treba testovaci branche na githubu)
5) nesmysly, kde nesedi ani cisla verze sw s pouzitymi funkcemi apod.
Bodu 2-5 je ted asi 5x vice nez pred par mesici
Možno riešením by bolo, aby dotyčný ktorý nahlasuje chybu, by mal spraviť aj funkčný exploit, aby dokázal, že sa jedná o skutočnú chybu. Problémom však je to, že keď už niekto má funkčný exploit, tak sa môže zvysoka vykašľať na oficiálnu odmenu a môže to skúsiť strelit/predať na darkwebe.
Aj ja pri práci v programovaní používam AI, kde neustále promptujem to, aby som mal čo najefektívnejší kód - a celkom dobre to funguje - dá sa pritom veľa naučiť. Avšak, posielať priamo výstupy z AI a nahlasovať tie AI výstupy pre bezpečnostný tím je na hanbu na 100 rokov, pretože to iba ukazuje lenivosť a neschopnosť nahlasujúceho sa poriadne ponoriť do problematiky.
Aj, ja som nahlasoval chybu v jednej open source knižnici, kde som dva dni skúšal ručne nájsť príslučnú funkciu, ktorá v novej verzii nebola a áno skúšal som to aj s AI a aj ja sám. Nakoniec som chybu nahlásil. Ale v mojom prípade som sa s tým trápil dva celé dni, kým som to nahlásil.
Tohle neřeší vůbec nic. K halucinované chybě může přijít i halucinovaný exploit, stejně to musí někdo ověřit.
Suhlasim.
Funkcny, standarizovany exploit, ktory sa da automatizovane testovat v standarizovanom, idealne virtualizovanom prostredi. Padlo to? Vies spustit vlastny kod? Leakuju data ktore nemaju? True or false.
Nelze. Můžete mít exploit při konkrétní konfiguraci. Fajn, dovolíte v automatizovaném testovacím prostředí, aby exploit obsahoval config.
V tu chvíli se na Vás sesype hromada AI slopu na téma chybnej config (třeba pokud celý PAM nahradíte /bin/true ) vede k exploitu, a jsme tam, kde jsme byli.
Na druhej strane, ked najdes zranitelnost este sa na nu nemusi dat spravit funckny exploit... ale v kombinacii ineho prostredia, inej kniznice, pouzitia alebo v kombinacii s inou chybou moze byt aktivne zneuzivany.
Yep. To je další problém. Může si projekt dovolit ignorovat hlášení bez exploitu? IMHO ne, určitě ne ve chvíli kdy je hlášená zranitelnost potenciální arbitrary code execution a podobně.
I na zjevnou chybu v kódu je obtížné napsat 100% funkční syntetický test, který by demonstroval, že tam chyba je, a po opravě ukáže, že už není.
Crash se projeví jen u několika uživatelů z milionu za obskurních podmínek.
Nedokonalý fix obvykle způsobí, že se chyba projevuje s ještě menší pravděpodobností a zreprodukovat uměle už pak nejde vůbec.
Situace v této oblasti se mění velmi rychle. Daniel Stenberg ( curl) na svém blogu v příspěvku High-quality chaos z 22. dubna popisuje situaci trochu jinak než tento článek:
No more AI slop
…
Higher volume, higher quality
…
The quality is higher. The rate of confirmed vulnerabilities is back to and even surpassing the 2024 pre-AI level, meaning somewhere in the 15-16% range.
…
Everything is AI now
…
The difference now compared to before however, is that they are mostly very high quality.