Vlákno názorů k článku AI mění svět open source: zahlcení, inflace projektů a klesající motivace od a6b - s lidskym kodem a vibecodem mi to pripada...
-
s lidskym kodem a vibecodem mi to pripada jako s drevostavbou a kamennou stavbou.
kdysi mel drevenou chysi kazdy nuzak a kdo mel dum z kamene cihel byl nekdo. dnes ma cihlovou ci betonovou stavbu kazdy a drevenku maji jen ti bohatsi.
vibecode byl nedavno jeste neco extra, ale uz se z toho stava odpad a lidsky kod zacina byt luxusem. -
třeba nekvalitní AI kód nás povede k tomu, že vybudujeme lepší nástroje pro kontrolu kvality kódu a to pomůže i AI.
Sice je super říct, že AI produkuje odpad, ale mě fascinuje jiná věc, i u repositářů, kde jsem si myslel, že automatické code kontroly jsou na velmi dobré úrovni mi AI ukázala jak strašné mezery tam máme. Bohužel AI místo dodržení pravidel se snažila mít "zelený stav" a tak pravidla bylo jednodušší obejít.
Skvělá na AI je, že toho produkuje tolik, ukáže velmi rychle, kde jsou další slabá místa při vývoji aplikací a že vlastně to není ten vývojářů, ale všechny procesy okolo.
-
> třeba nekvalitní AI kód nás povede k tomu, že vybudujeme lepší nástroje pro kontrolu kvality kódu a to pomůže i AI.
To je dost těžký problém a jeho části možná ani nebudou výpočetně řešitelné. Kvalitní kód je pro mě
- stručný
- robustní - rozšířitelný, opravovatelný
- rychlý
- vrstvený, dělený do komponent s jasně definovanou hranicí odpovědnosti
a určitě ještě pár dalších vlastností, které nemůžu než shrnout pod výraz elegantní.
Když vidím, jak ukecaný, z jedné strany protkaný zbytečnými kontrolami, zbytečně plevelený komentáři a extrahováním jednou použitých jedno- a dvouřádkových funkcí; z druhé strany pasivní kód který spoléhá na volajícího spíš než aby dodal defenzivní kontroly, používající nehezká jména pro proměnné i funkce... S takovou bych kvalitu kódu nerad svěřoval jazykovým modelům.
-
Zajimave, ze u definice kvalitniho kodu nemas "splnuje funkcni ocekavani", nebo-li dela co ma :)
Hodne silnej argument je prave ta rychlost, jak rychle dorucim feature/produkt. Pro "pure engineering" to neni hezke, ale z hlediska sales/pm/useru je to asi to nejdulezitejsi. A ti sedi na penezich.
A prave tady ma teoreticky AI hroznou silu a zaroven to trochu umlci ostatni argumenty - dela to to, co ma? Pak treba nevadi horsi citelnost nebo robustnost (x vrstev, osklivej kod. apod.), protoze stejne postves agenta na fix. A rychlost nebo efektivita kodu taky nemusi byt tak dulezita, podivejme na VSCode/Spotify/Slack/Teams(?) a dalsi, co zijou z neefektivniho Electronu, ale stejne je vsichni pouzivaji...
Tim nechci rict, at se otevrou stavidla vsemu (koneckoncu spousta toho, co zminujes jde hodne ovlivnit skillama/guidance pro agenta v repu), ale vyvolava to hodne az "filozofickych" otazek, co je vlastne dulezite a jak moc. Nebavim se (zatim? :)) o nejakem super kritickem kodu, ale o "beznem" SW. Nevim, jestli je to dobre nebo ne, co pisu za kod ja urcite by taky slo napsat efektivneji v assembleru, ale to by trvalo vecnost napsat... Ted se ta abstrakce posouva no :)
-
Funkční kód beru jako nižší laťku než kód kvalitní :)
> A prave tady ma teoreticky AI hroznou silu a zaroven to trochu umlci ostatni argumenty - dela to to, co ma? Pak treba nevadi horsi citelnost nebo robustnost (...), protoze stejne postves agenta na fix
Ta rychlost, s jakou LLM vytvoří kód je dobrá, když se bavíme o novém kódu. U jakýchkoliv úprav už pak nastupuje architektura, úspornost a všechno možné, co pomáhá snižovat nároky na kontext. Moje zkušenosti ukazují, že čím míň toho po LLM chceš, tím je užitečnější. (Do extrému dohnáno to pochopitelně znamená, že LLM jsou nejužitečnější, když po nich nic nechci.)
Nehlídaný agent začne prasit, nároky na kontext se začnou zvětšovat, peníze za tokeny polezou nahoru, užitečnost modelů spadne dolů a skončíme s nerozmotatelným klubkem špaget, na které se všichni budou bát sáhnout. Jedinou jakž-takž záchranou pro programátory budou testy - pokud teda bude kód pokrytý a agent nezařídí jejich přiohnutí.
> A rychlost nebo efektivita kodu taky nemusi byt tak dulezita, podivejme na VSCode/Spotify/Slack/Teams(?) a dalsi, co zijou z neefektivniho Electronu, ale stejne je vsichni pouzivaji...
Jasně, něco prostě trvá a u úlohy, která běží na pozadí pětkrát za den je buřt, jestli trvá pět vteřin nebo deset. Ale když u toho sedí člověk a kouká na to, jak se ten excel startuje těch samých deset vteřin jako roku 2006...
Zrovna ty teamsy budou zadarmo drahý, protože tu někomu nefunguje mikrofon, tam zas má někdo problémy s přihlášením, upozornění chodí jenom za úplňku a v úterý (ale zase ne všem), a zbytek týmu sedí na schůzi a čeká a čeká. Jasně, MS ten čas nepálí, protože ten čas propálí někdo jiný. Pokud možno aspoň v pěti, aby se to trochu škálovalo. Nehledě na peníze, nehledě na zákazníky, nehledě na šéfy - nechtěl bych mít tuhle katastrofu pod svým jménem.
> ale vyvolava to hodne az "filozofickych" otazek, co je vlastne dulezite a jak moc.
Důležité je, co za člověka u toho agentu nakonec sedí. Jestli je to někdo, kdo umí rozpoznat problémy dřív, než nastanou. Jestli se dokáže učit. Jestli dokáže poměřit přínos a náklady. Takový inženýr bude na svojí práci po právu pyšný a bude se o kvalitu zajímat. Anebo tam bude sedět biologický automat, který bude brát výstupy LLM a pouštět je na vstup gitu nebo čehokoliv jiného.
Já vím, kterého z těch dvou bych za klávesnicí viděl radši.
-
Já myslím, že ona kontextová náročnost je metrika docela dobrá metrika kvality kódu a dřív nebo později na ni selže člověk i AI. AI zatím dřív.
Zkoušel jsem takhle vibecoding pár projektů, AI vždycky přidává nové funkce cestou nejmenšího úsilí a refactoring sem nepatří. To znamená, že funkce obsahují kód, který je třeba a nejsou úplně obecné a neprůstřelné, dělají to co stačí. Jenže při jisté velikosti kódu se AI začne dívat jen na hlavičky a ne implementace, omezení dokumentovaná nejsou, funkce neobsahují asserty a AI prostě předpokládá, co funkce dělá na základě hlavičky, kde nejsou žádná omezení zmíněná v komentáři. A v tuhle chvíli každá změna kód buď okamžitě nebo skrytě rozbije. AI to možná pak i opraví, ale lokální malou změnou, ne refaktoringem a zvýšením odolnosti kódu. Zároveň v tuhle chvíli začne duplikovat kód a celý projekt se začne hroutit.
Člověk co má trochu zkušeností se nějak snaží kód postupně vylepšovat a lépe strukturovat, ale AI s tím má problém, stejný výsledek, víc práce s nejasně definovanou metrikou co je lepší kód, protože na tom se neshodnou ani lidé.
-
"argument je prave ta rychlost"
Vzhledem k tomu co mam moznost videt, je tohle argumet vylozene proti pouziti AI. Protoze vysledek je mnohem horsi nez toho nejhosiho patlala, a "fuguje" to sotva na ten prvni pohled. Ve skutenych aplikacich se ocekava, ze resi typicky stovky, ale klidne i radove vic ruznych okrajovych a obcas nastavajicich situaci, pricemz spoustu z nich vyresi i ten nejhorsi patlal, ale nikoli ai.
A opravovat/dodelavat to do kodu po ai = je o rady rychlejsi to prepsat cely znova. Kazdopadne to pak nasobne dyl trva.
-
L.Stříbrný podporovatel
> Ve skutenych aplikacich se ocekava, ze resi typicky stovky, ale klidne i radove vic ruznych okrajovych a obcas nastavajicich situaci, pricemz spoustu z nich vyresi i ten nejhorsi patlal, ale nikoli ai.
To není pravda. Patlal stěží zvládne happy day, AI mě naopak občas překvapí, co zachytí. Zvlášť ta co dělá review je dobrá, dost často chytí věci "Tady jsi něco změnil, ale na tomhle úplně jiném místě se dělá něco podobného taky a tam jsi na to zapomněl, je to OK?"
-
Pri tomto ma napadá historka, snáď pravdivá, o rozdieli v prístupe k výrobe za 2. svetovej vojny.
Nemci mali viečka nádrže na tankoch uchytené na peknej retiazke, krásna jemná práca, keby bol pozlátená, s radosťou by sa to dalo nosiť na krku. Briti tam dávali retiazku nejakú nahrubo opracovanú, mierne skorodovanú. Sovieti tam priviazali kus špagátu. Koľko nadbytočnej práce bolo v ktorom z riešení?
Ono aj záleží na účele - pre lety do vesmíru už asi takýto prístup nemohli použiť.
-
"Pri tomto ma napadá historka"
Jenze pro ucely valceni nepotrebujes nejlepsi techniku na svete, potrebujes vyhovujici techniku ... kterou zvladnes ve velkym a levne vyrabet. Jednoduse proto, ze ten nejlepsi tank na svete ti stejne jako ten nejhorsi znici jeden bigos s trubkou pres rameno. Jenze z toho levnyho tanku pak vyklepes zbytky osadky, navaris zaplatu a muze jezdit dal, zatimco ten neljepsi nemas cim nahradit, protoze ti cinani zadny cipy zrovna nedodaj.
Zatimco u SW se tak nejak ocekava, ze se bude pouzivat dlouhodobe, v nekterych pripadech klidne i desitky let. A za tu dobu se do nej bude velice pravdepodobne chcit prubezne zasahovat a menit ho ... i kdyby to bylo treba jen kvuli vnejsim vlivum - treba zmeny legislativy.
Coz je ostatne taky jedna z tech legraci ... zrovna dneska sem mel tu pochybnou "cest" ... ze prej dneska uz erpcko neporebujes, protoze AIcko si to vyresi samo ... bych chtel videt, jak se AIcko dohaduje s financakem na tema vyklad legislativy a co jak ma nebo nema byt zaucrovano ... lol. A chtel bych videt firmu, ktera by do toho sla.
BTW: Jen behem dneska prislo 7 "AIckovych" firem (MS, guugl, tesla ...) o $800G v cene akcii ... jo je videt ze to vydelava. A guugl je dokonce poprvy v historii za posledni ctvrtleti v minusu.
-
Jenomze sem se hodne presouva role developera - ten, co kontroluje integrace a pozadavky a ruci za funkcnost, vice architekt a QA zaroven :) Psat kod neni uz skill, skill je ,ze to dokazu "orchestrovat", aby to delalo, co ma. Dam priklad. Pridavam vetsi ficuru do projektu:
- agent udela plan, ja delam review, ze dava smysl
- soucasti planu je rozdeleni na tasky, verifikace apod.
- ja osobne pak necham agenta udelat jeden task, udelam mu hned review, iteruju nad tim, kdyz jsem spokojen, udelam commit
- pokracuju dalsim taskem atd.
- udelam verifikaci celku, testu, final review apod.To neni o tom, ze reknu "chci hodinky z vodotryskem" a prijdu k hotovym hodinkam, ja jsem s nim a prubezne ho vedu/opravuju (a opravama treba zlepsim nasi guidance v projektu). A takto muzu delat paralelne vice veci na jednou (ja teda nezvladam vic jak 2-3 najednou ,ale to je mozna moje omezeni ;)
ČLÁNKY DO MAILU