Vlákno názorů k článku
Gentoo zakazuje přispívání kódem generovaným umělou inteligencí
od Youda - No to je magorina.
Dneska bez AI nekoduje nikdo...
-
Já nevím, jestli se má jednat o vtip.
Se syntaxí poradí každý IDE za posledních 30 let (víc si nepamatuju ;-)). S parametry funkcí také - i free doplňky do vimu to uměly už před 15 lety. StackOverflow je dobrý možná tak na prozkoumání dalších / jiných možností jak něco udělat, ale rozhodně to není návod na použití čehokoliv a už vůbec ne na copy paste.
Jestli je tento komentář myšlen vážně, tak to říká jediné - děláte to blbě.
-
To není tak jednoduché - malinký přínos a žádné ztráty. Abyste ten jeden blok za měsíc mohl potvrdit, budete muset trávit čas tím, že budete pročítat a zavrhovat různé navržené bloky kódu, které z nějakého důvodu nevyhovují.
Tohle je dost zásadní problém. Klasické intellisense a podobné nástroje když neví, tak mlčí. LLMka velice rády halucinují kraviny, se kterýma pak musíme my lidi ztrácet čas. Jestli to stojí za to je hodně proměnlivé. -
Asi záleží na použití. Pokud je ten blok něco triviálního, kde se jen v konkrétním jazyce interpretuje existující a známý algoritmus, tak to asi není moc potřeba.
Asi nečekám, že mi Github Copilot napíše celou aplikaci nebo něco složitého. Ale možná bude efektivnější jednodušší kusy kódu nechat napsat AI než juniorního programátora. Tak jako tak tam pak někdo musí udělat revizi kódu, ale ten junior za $9.9/měsíc rozhodně pracovat nebude.
Ale určitě je důležité zmínit, že neni programování jako programování. AI určitě hodně pomůže například s webovými aplikacemi, kde ta repetetivnost kódu je hodně vysoká. Dobře to funguje například při psaní automatizací. Dovedu si představit, že to bude generovat větší část unit testů.
Ohrazuji se pouze vůči tomu, když někdo řekne že se mu to nevyplatí. Ta cena je tak směšně malá, že i člověku co se věnuje programování jeden den v měsíci a ušetří mu to napsání opravdu malé části kódu by to mělo být přínosem.
-
> Ta cena je tak směšně malá
Vždyť jsem to napsal přímo. Nejdůležitější část ceny za použití AI není těch směšných 10$ ale moje člověkohodiny co padnou na codereview toho generovaného kódu.
Aby bylo AI přínos, musí být použitelná dostatečná část generovaného kódu. Aby čas ušetřený psaním toho kódu převážil čas strávený čtením toho generovaného kódu.
'
Tool co ušetří napsání opravdu malé části kódu je i zadarmo drahý, pokud nefunguje naprosto spolehlivě a bezobslužně. -
Mluvíš o programátorech, kteří jsou tak hloupí, že si neumí spočítat náklady. Ale existují i programátoři, kteří do dovedou.
Po čase jsem se naučil odhadnout, že na některé problémy není ekonomické se ho ptát. Také jsem se naučil co to znamená, když začne dávat zmatené odpovědi. Stejně tak, jako normálnímu programátoru běží v hlavě na pozadí proces, který zhodnocuje, jestli použití té či oné knihovny, algoritmu, řešení se vyplatí, a zda se na to nemá vykašlat, tak LLM je prostě jen další řešení do řady.
-
Ale ono nejde o to, že bych potřeboval poradit nějaké jednotlivosti ohledně parametrů nebo tak něco. Byl jsem třeba v situaci, že jsem chtěl napsat úplně nový program, využívat API, které jsem několik let nepotřeboval, takže jsem si ani nepamatoval názvy funkcí apod. Nebo jsem potřeboval vyřešit problém v jazyce ve kterém běžně nedělám a nevěděl jsem jaké na to jsou vhodné knihovny. Tak jsem prostě napsal co to má dělat a ono to vysype během pár sekund několik set řádků funkčního kódu, který bych ručně dával dohromady třeba hodinu a prolejzal tuny dokumentace a SO. Je to prostě řádově rychlejší než do dávat dohromady ručně. Navíc je ten kód idiomatický, což se hodí v případě, kdy ten jazyk nemám ještě zažitý.
-
S tou funkčností je to právě přijde mi dost často trochu problematické. Jako jo, pro některé případy užití je to fajn, s tím naprosto souhlasím, ale jindy jsem dostával kód, který sice vypadal funkčně ale reálně obsahoval spoustu problémů logikou plynoucí právě z toho, že jde o LLM a nikoliv něco, co by skutečně danou věc reálně chápalo.
-
Syntax napovidaly editory uz zacatkem 90'
A patlalove, kteri nic neumi, to samozrejme jinak nez lepenim ciziho kodu nezvladaji. Tenkrat se k tomu cizimu kodu nemeli jak dostat, tak jich bylo minimum. Vysledky tomu odpovidaji ... ono to neco dela, ale nikdo nevi co vlastne.
Zrovna takovou patlaninu v C# resim ... na jednech widlich to bezi ... ale neseje, a na druhych ... to z nejakyho duvodu i seje. Logy zadny, konfigurace, kterou to minimalne z casti ignoruje(nastaveni casovace na 15 minut == deje se to kazdych 5 minut), je prosychr v 5 ruznych souborech ruznych formatu ...
-
Zrovna experimentuju s copilotem a jsem z toho tak nějak rozpačitý. Člověk ho musí hlídat jak ostříž. Je to jako mít k ruce nepoučitelného lempla. To, co se nedá podělat, obvykle zvládne,
Ale důsledně si halucinuje i věci, které třeba Intellisense ví (třeba doplňování includů)
A jak má možnost nakráčet do nějaké neinuitivní pasti, tak to spolehlivě udělá. -
Heh, komici.
Priklad, ktery jsem psal prave ted.Potrebuju zaokrouhlovat cisla counteru do prezentace na WEB GUI
Dotaz do AI:
"Please write javascript function that have number parameter "value" and return human readable string with SI suffic like 123.45M or 123.45k."
Odpoved
function formatNumber(value) {
const absValue = Math.abs(value);
const SI_SYMBOLS = ["", "k", "M", "G", "T", "P", "E"];
const tier = Math.log10(absValue) / 3 | 0;if (tier === 0) return value.toString(); // No need for a suffix for small numbers
const suffix = SI_SYMBOLS[tier];
const scale = Math.pow(10, tier * 3);const scaledValue = value / scale;
const formattedValue = scaledValue.toFixed(2);return formattedValue + suffix;
}Napsani dotazu cca 10 sekund, kontrola kodu cca 20.
Nic co bych nenapsal sam, ale ne za 30 sekund.Samozrejme, muzete si jak pitomci psat kazdou trivialitu sami, proc ne.
Ja jsem placeny za odvedenou funkcionalitu a zakaznikovi je srdecne u zadi, kde se kod vzal. -
Tohle je přesně to, o čem jsem se tu nedávno hádal s Filipem Jirsákem.
Od tohoto slouží už asi 70 let knihovny. Skutečně není potřeba pro každého zákazníka psát všechno od nuly. Firma si má budovat knihovnu, do které bude strkat všechny tyto jednoduché funkce. Tento konkrétní příklad jsme v kroužku programování psali někdy na základce v pascalu. V roce cca 1994. Jestli je na to v roce 2024 potřeba AI, tak je s IT jako s celkem něco opravdu hodně špatně.
-
To je pravda. Ještě by to ale chtělo zařídit, aby přestala halucinovat. Myslel jsem, jak budu AI používat a i to dělám, ale u spousty úkolů jsem toho musel nechat protože míra nejistoty, že to, co sepsala je taky pravda je hrozně nízká.
Dokud se člověk ptá obecně a o věci nic neví, je to skvělá věc k zorientování se, ale jakmile člověk začne chtít detailní informace, je potřeba v podstatě všechno ověřovat. A to tak, že je když člověk alespoň trochu tuší rychlejší najít si to sám.
-
Tenhle komentář taky napsala AI? Se podívej na diskusi níže. Ten příklad rozhodně není v pořádku.
O to víc času ale potom zbyde na řešení opravdu důležitých věcí, takže efektivita práce roste.
Ano, tohle se ví od dob průmyslové revoluce. Jenom je potřeba všechny ty stupně udělat dobře. Až tehdy, kdy jsou udělané dobře, tak je můžu pustit z hlavy a věnovat se něčemu dalšímu. Pokud někdo nějakou fci zbastlí (ať už sám, nebo pomocí AI), tak ten program zhavaruje v nejhorší možnou situaci. A potom nastane fáze řešení problémů. Takže efektivita práce roste pouze v případě, kdy je to uděláno dobře.
-
pár zásahy
No ale těch pár zásahů má právě udělat ten nástroj.
Možná je to jen můj pohled, který je daný tím, čím se celý život zabývám. Ale já mám počítač od toho, aby mi přísně a nekompromisně pohlídal konzistenci dat, přesně spočítal pár věcí (pro člověka nespočítatelné) a pohlídal moje chyby a moji nepozornost. A tak dále.
Takže nástroj pro generování kódu má sám ohlídat všechny corner-cases, protože ty jsou známy. Má mít katalog všech problémů, které byly v minulosti identifikovány.
Iterovat AI prompt do uspokojivého výsledku je sice hezké (asi, možná, pro někoho), ale já osobně od IT nástroje požaduju spíše to, že na to sám upozorní, případně rovnou dá do kódu kontroly.
Takhle přece postupuje systémový inženýr. Na každou chybu, která se vyskytne, se navrhne řešení, testy atd. a ta chyba už příště buď nestane, vůbec se nedostane do kódu, infrastruktury apod., nebo na ni bude alespoň včas upozorněno.
-
Heh, to jsou kecy. Zrovna tato funkce slouzi pro zobrazeni prenesenych bajtu na specifickem interface na specifickem device za jeden den.
Vystaveno je to na klasicke MIB tabulce ifXtable, soucet hodnot ifInOctets a ifOutOctets - rozdil hodnot mezi pulnocema.
Uz z definice MIBky tam nemuze byt nic jineho, nez UINT.Tohle numero si nacte SprinBoot backend, ktery to spolu s jinyma atributama vystavi na REST endpointu.
Pricemz ten REST endpoint neni nic jinyho, nez JSON serializovany Java Bean, ktery ma dany atribut jako typ "int" - opet, vubec neni mozne tam mit neco jineho nez integer.Vue3 frontend si nacte REST API response, prozene to AI vygenerovanou funkci, ktera je pro tyto potreby NAPROSTO DOSTATECNA.
AI nemuze resit corner cases z jednoduche priciny, ze je nezna. Od toho jsem tu ja, abych AI patricne instruoval.
Popravde uz dlouho jsem nevidel vetsi kktinu, nez pracne zabezpecovat primitivni formatovaci funkci na eventuality, ktere nemuzou nastat.
-
Už jsem zažil jednoho blba, co něco neošetřil pod záminkou "tohle je int32, to se vejde", a po letech celkem dlouho jsem pak hledal divné chyby v logice, které naprosto neměly zjevnou příčinu.
No když jsem pak přišel na to, že je to proto, že se v upstreamu změnil ten typ na short, tak jsem měl hodně chuť slabomyslného autora onoho kódu nakopat do gluteus maximus. Jenže, ono se to dělá dost těžko, kopat se do vlastní.
Tož tolik k tématu "nemůže nastat".
-
Spíš jestli to vypadá jako kód, který napsal schopný vývojář, nebo nezkušený/lempl. Protože schopný vývojář se zeptá "Potřebuješ i vstupy v tomhle rozsahu?". A pokud ne, tak tam dá komentář s varováním, assert či něco podobného.
Prostě takové základy vycházející z toho, že 80% práce vývojáře se točí kolem louskání starého a ne psaní nového kódu. Že to není studenský projektík typu odevzdej a zapomeň. -
No tak si to tam pridej, nebo rekni AI, at to dodela.
AI si pamatuje kontext, staci ji rikat doplnujici pozadavky, dodela to.
Ted jsem otevrel znovu chatGPT, aktivoval jsem z historie staou session a dolnujici dotaz (presne takhle, i s tema preklepama):
"Please modify the funtion, return "n/a" in case of any error and truvcate value if it is not integer."
Vysledek:
function formatNumber(value) {
// Check if value is a valid number
if (isNaN(value)) return "n/a";// Truncate non-integer values
value = Math.trunc(value);const absValue = Math.abs(value);
const SI_SYMBOLS = ["", "k", "M", "G", "T", "P", "E"];
const tier = Math.log10(absValue) / 3 | 0;if (tier === 0) return value.toString(); // No need for a suffix for small numbers
const suffix = SI_SYMBOLS[tier];
const scale = Math.pow(10, tier * 3);const scaledValue = value / scale;
const formattedValue = scaledValue.toFixed(2);return formattedValue + suffixes[suffixIndex];
} -
Tady nejde o to, že té AI můžu říct, ať to předělá. To jde i pro kód psaný juniorním lemplem. (mimochodem, mám pocit že furt nepokryl třeba nekonečna). Jde o to, že ho musím hlídat i u takové triviality jako formátování čísla.
Když použiju nějakou oblíbenou knihovnu, tak tam takovéhle pakárny hrozí podstatně míň. Protože ji používají různí lidé různými způsoby. Když místo toho ten kód nageneruju AI, tak musí veškerou údržbu odedřít já.
-
Je to tak. A takové neblahé paměti třeba jQuery pluginy, to teprve bylo dílo. Přemýšlím, jestli jsem kdy narazil na nějaký, který alespoň nebyl totální bastl. Jenomže problém je, že spoustu z nich psali podobní lidé, jako ti, co si dnes nechají podobnou hrůzu vygenerovat AI a celkem nepřekvapivě jim vůbec nepřijde divné, jak výsledek vypadá.
18. 4. 2024, 14:55 editováno autorem komentáře
-
Kdysi v začátcích se pracovalo (prasilo) stylem „Něco to dělá, úkol splněn. Prodat a zapomenout.“
Postupně jsme se naučili, že:
číst, kontrolovat, analyzovat cizí kód je mnohem víc vyčerpávající než to napsat znova a úplně jinak a správně,
napsat to nějak a pak opravovat — debugovat — opravovat je mnohem pomalejší než hodit nohy na stůl — dát si kafe — promyslet si to — napsat dobře,
prasit a prodávat se dalo v době kdy žádné updaty neexistovaly a zákazník nevěděl co je to zdroják,
hledat chyby stojí mnohem víc peněz než naučit se je nedělat — tedy používat správné myšlenkové procesy vždy — i v maličkostech,
každý program obsahuje chyby — i triviální na pár znaků může mít hloupé přehlédnutí (třeba zanedbaný předpoklad) vyžadující hodiny času na analýzu kdovíkdy v budoucnu — stačí málo myšlení od autora na začátku a nějaký šikovný šťoural to zkontroluje za autora a ten exploit rád použije,
kdybych takhle dělal mojí práci, omlátí mi to o hlavu a kopnou mě do outputu,
… a mnoho dalšího. Ale kdo nedokáže pochopit historii a poučit se z ní, je odsouzen si ji zopakovat, jak snad všichni víme. AI bude mít smysl až bude inteligentnější a hlavně zodpovědnější než člověk, což jistě bude brzo. Ale ne dnes.
-
To není o ludditech ale o tom, že AI momentálně není ve stavu, aby generovala kvalitní výstupy. Srandovní jsou hlavně bastliči, co tomuhle říkají výstup své práce. A ti byli i před AI. Jediný rozdíl byl v tom, že tehdy bastlili bez AI, ale jejich pochopení toho, jak vypadá kvalitní kód bylo zcela stejné.
-
Není potřeba. Úkol už byl přece splněn, tedy můžete řešení hezky zařadit do knihovny, ať to může kterýkoliv programátor na světě použít. Jedna ze základních zásad je, nic nedělat zbytečně dvakrát.
Ano, píšu to jako ironii či satiru. Samozřejmě to nemyslím vážně, takový kód bych v kvalitní knihovně viděl dost nerad.
18. 4. 2024, 14:15 editováno autorem komentáře
-
Nenapíšu, javascript neznám. Krátce popíšu odlišnosti mojeho postupu pro C++ (případně, na vyžádání, třeba pro bash script nebo makefile nebo něco jiného co jsem ještě nezapomněl :-)).
Jsem samozřejmě zvyklý ne psát, ale přemýšlet v C/C++ a pak specificky dle koncepce projektu a s ohledem na maximální efektivnost. Tedy už zadání automaticky vnímám jinak:
Rozlišuju int a float a jiné typy a podle toho teprve vidím algoritmus.
Zde, neznám projekt, předpokládám tedy že je to počitadlo, nejlépe uint64_t. Ani mě nenapadne použít float funkci jako je třeba logaritmus. Pro float typy bych to řešil asi zase jinak. To vidím ve vteřině, automaticky.
Druhá koncepční chyba v zadání: zaokrouhluje se na konkrétní počet platných číslic, nikdy ne na konstantní počet číslic za desetinnou čárkou. Uvědomím si v průběhu psaní. V jednou vytvořeném kódu bych si této chyby ale už nevšiml.
Použil bych 4 platné, ale dodám pro uvedených 5 platných i když je to moc.
Třetí chyba: locales. Nebudu řešit. Též jsem si uvědomil až při psaní, tedy AI je pro mě překážka, způsobující skryté vady.
#include <string> #include <unistd.h> using namespace std; string formatNumber( uint64_t value ) { // only positive numbers const char * SI_SYMBOLS = "kMGTPEZYRQ"; // ZYRQ not used for uint64_t string formatted = to_string(value); const unsigned length = formatted.length(); if (length > 5) formatted.resize(5); // limit to 5 significant digits // if (length > 4) formatted.resize(4); // or limit to 4 significant digits if (length > 3) { // add a decimal point and SI prefix formatted.insert((length+2) % 3 + 1, "."); formatted += " "; formatted += SI_SYMBOLS[(length-4)/3]; // can't overflow for uint64_t } return formatted; }Pro klasické C by to bylo stejně, jen místo typu string by byly manipulace s bufferem typu char * .
Možností jak to napsat je samozřejmě víc, určitě by to šlo i líp, já to napsal takhle.
V původním kódu též nevidím explicitně ohlídaný či zmíněný rozsah pole SI předpon.
Pole SI předpon v původním programu je pole řetězců. Proč ne jeden řetězec, pole znaků?
Ostatní neohlídané věci už tu byly zmíněné: pro float taky malé předpony, nejen velké a nutná jiná kontrola rozsahu pole. Explicitně určit co se zápornými čísly.
Analýza chyb a nedostatků by mi zabrala víc času než napsat to znova. Na některé nedostatky bych pouhou analýzou nepřišel, ale při psaní bych se jim díky mým postupům vyhnul nebo bych je automaticky vyřešil.
-
KateStříbrný podporovatel
To opravdu při psaní funkce nikdy nepočítáš s možností že bude přepoužitá v jiném kontextu? To že tady taková chyba nenastane je hezké, ale tím že se u „tebou psaného“ kódu nedá spolehnout na to, že nesestřelí program když ho použiju jinde z toho dělá peklo v jakémkoliv rozsáhlejším vývoji.
Další problém generování kódu je ve faktu, že programátor běžně tráví mnohem víc času čtením kódu než jeho psaním. Nechávat to psaní na něčem co nemusí generovat nejčitelnější kód není zrovna ideální nápad.
-
Další problém generování kódu je ve faktu, že programátor běžně tráví mnohem víc času čtením kódu než jeho psaním.
Tak toto zatím vidím jako jednu z nejvíce relevantních myšlenek v této diskuzi (spolu s licencí, kdy dostanu kód, který může podléhat právům). Kód se nejen píše, ale měl by projít i přes nějaké review, případně ho časem bude číst někdo jiný a bude se snažit pochopit, co původní autor zamýšlel. A pomůže-li to "rádobyautorovi" kódu, že má za půlminuty hotovo, o to více času se stráví v budoucnu hledáním záhadné chyby. Takže stále platí, používat AI s rozumem a brát, že může být dobrý sluha, ale zlý pán.
-
KateStříbrný podporovatel
> Kód se nejen píše, ale měl by projít i přes nějaké review, případně ho časem bude číst někdo jiný a bude se snažit pochopit, co původní autor zamýšlel.
Tohle mimochodem přináší další problémy.
1) psát rozsáhlejší věci s LLM je jako psát s horším juniorem a dělat po něm code reviews. S tím rozdílem, že na rozdíl od reálného juniora se nenaučí programovat líp, takže je to nekonečný cyklus. Protože LLM už z principu nechápe co dělá.
2) kolik lidí reálně baví dělat code reviews víc než psaní kódu? Vtípky na lidi co na 2000 řádkový merge request odpoví LGTM a dají approve jsou běžné. Fakt nevěřím že člověk co si zvykne odklepávat generovaný kód nezačne přehlížet chyby.
3) a tohle bude zajímavé sledovat, pokud se opravdu povede nahradit juniory generátorem, může být za pár let problém shánět seniory. -
Z autopsie môžem povedať, že v prípade ChatGPT/Python, je ten kód dobre čitateľný a keď ho trošku pobuzerujem, tak vie aj peknú procedurálnu dekompozíciu spraviť. Možno niekedy na prvú dobrú to nedá, ale dá si dohovoriť. Ak obsluha robota má rada guče, robot guču niekedy dodá.
Samozrejme to používam len na hobby projekty, aby som nebol pozadu.
-
Náhodou jsem tohle potřeboval pár dní zpátky pro jednoduchý výpočet a i když python určitě má knihovnu na zobrazování suffixu, zbastlil jsem to do cca minuty zcela bez AI:
def prettysize(size) -> str: s='' if size > 1024: size /= 1024; s = 'K' if size > 1024: size /= 1024; s = 'M' if size > 1024: size /= 1024; s = 'G' if size > 1024: size /= 1024; s = 'T' if size > 1024: size /= 1024; s = 'P' if size > 1024: size /= 1024; s = 'E' if size > 1024: size /= 1024; s = 'Z' if size > 1024: size /= 1024; s = 'Y' return f'{size:14.3f}{s}'(Za ty středníky se omlouvám.)
-
Zeptal jsem se AI, co si o tom kodu mysli, jestli ho neudela lip.
A vratila mi tohle:
def prettysize(size) -> str: suffixes = ['', 'K', 'M', 'G', 'T', 'P', 'E', 'Z', 'Y'] for suffix in suffixes: if size < 1024: return f"{size:14.3f}{suffix}" size /= 1024 return f"{size:14.3f}{'Y'}"Tenhle kod neprochazi vsechny ify, ale skonci na prvni nule, je tudiz efektivnejsi.
-
radekmStříbrný podporovatel
Na prvni pohled to vypada, ze tam je chyba. Pro posledni suffix 'Y' - kdyz je size mensi nez 1024, tak to vrati s jednotkou 'Y', a kdyz je vetsi nebo rovno, tak to vydeli a zase vrati s jednotkou 'Y' (protoze skonci ten for cyklus a za nim je return zase s 'Y').
