Koniec eldorado w IT

https://www.msn.com/en-in/technology/artificial-intelligence/when-ai-costs-spiral-a-company-accidentally-spent-500-million-in-one-month-on-claude-ai-what-went-wrong/ar-AA24kr2j

Kurde to AI miało być tańsze od ludzi i coś poszło nie tak :S Ciekawe czy za te 500 milionów USD dowieźli przynajmniej coś epickiego i akcję firmy podrożały przynajmniej o 200%, bo jak nie to to trzeba chyba napisać do CEO firmy, że za tyle hajsu to on będzie miał na utrzymanie biura z programistami w Polsce przez kilka lat

Teraz ciśnienie jest na tworzenie systemów opartych wokół agentów.

W idealnym świecie to zastąpienie scruma kontrolą pracy agentów. Potrzebne są dobrze zdefiniowane metryki, by ai ocenić, ograniczenia dostępów, by każdy AI miał dostęp tylko do tego czego potrzebuje, kontroli zużycia tokenów per task, odpowiednich baz wiedzy o organizacji, procesach i dostepach.

Wtedy w idealnym świecie wrzucamy tickety/projekty, a grupa AI nad nimi pracuje, gdzie człowiek nadzoruje proces/reviewuje output.

Samo w sobie jest to ciężkie, by takie środowisko stworzyć. Ale jeśli stworzymy nawet taki proces, to mamy potencjalnie 10x więcej kodu. Z tym też musimy sobie poradzić. Częstszy release, jak wygląda feedback loop, jak wygląda synchronizacja pracy agentów i rozwiązywanie przez nich konfliktów.

W dużych zaśniedzialych firmach to powinni wręcz zatrudniać więcej ludzi, bo dojście do takiego eldorado korporacji wymagać będzie mnóstwo zasobów. I tak naprawdę nikt nie jest pewny jak to zadziała na olbrzymią skalę

ple123 napisał(a):

AI piszę kod ale żeby zadać mu pytanie i złożyć/lub poprawić w całość to co wygenerowało to trzeba mieć wiedzę programistyczną. Osoba bez tej wiedzy nie da sobie rady.

To jest to ryzyko, że ktoś nie mając wiedzy albo nie będąc pewny, zaufa że podany kod jest dobry i tego nie zweryfikuje. Siłą rzeczy, gdy się coś kopiowało ze stackoverflow lub dokumentacji, to się taki kod dostosowywało do własnego problemu i się go weryfikowało. Teraz zwolennicy vibe codingu tego nie robią, uzasadniając że taki Claude Code sam się sprawdzi, wywoła kod, poprawi, etc. Ewentualnie uważają, że zrobią review i problem z głowy, tylko czy ich review pokrywa logikę aplikacji, wydajność i warunki brzegowe? Czy tylko sprowadza się do sprawdzenia estetyki kodu?

Kurde to AI miało być tańsze od ludzi i coś poszło nie tak :S Ciekawe czy za te 500 milionów USD dowieźli przynajmniej coś epickiego

A ile razy człowiek wygenerował miliony $$$ szkód - bo np. spowodował lawinę regałów na magazynie waląc w pierwszy z nich widlakiem, albo przypadkowo powodując pożar podczas prac i w ten sposób spalił połowę jednej z najbardziej znanych na świecie katedr.

I żeby była jasność - nie bronię AI, jedynie wytykam błąd w takim podejściu do tematu/błąd w założeniach. OK, w tym przypadku doszło do przepalenia kosmicznej kasy, ale należy to traktować w kategorii błędu. A błędy się zdarzają - Czarnobyl to także był błąd ludzki, a konsekwencje na pewno były znacznie wyższe niż to, co podlinkowałeś. Zresztą (nie czytałem szczegółów dot. tych 500 baniek) tutaj i tak podejrzewam, że jest to w dużej mierze wina człowieka - bo nie ustawił limitów, bo źle wydał polecenia, albo (nawet jeśli wytyczne były jasne) nie monitorował co i jak się działo. Ale oczywiście - łatwiej jest napisać szyderczy wpis że AI przepaliło 500 milionów, bez zastanawiania się kto temu EjAj dał możliwość tyle kasy rozwalić, kto go nie pilnował, dlaczego były błędy w procedurach które na to pozwoliły itp.

UPDATE

Jednak zajrzałem do tego linku. Pierwszy akapit, pierwsze albo drugie zdaniem mówi że generated a $500 million bill in a single month after neglecting to place any usage limits on employee access to Anthropic's Claude platform. Czyli nie ma tutaj ani grama wątpliwości, to ludzie skopali sprawę, puścili AI samopas, pozwolili pracownikom z tego korzystać bez limitów. To jakby dać pracownikom karty kredytowe, nie dawać żadnych limitów płatności ani nie kontrolować na co wydają, a potem pisać jakie to banki naciągają uczciwych ludzi i jakie to karty są niedobre, bo mamy $500 do zapłaty za to, co ludzie wydali. Ten sam poziom naciągania faktów.

@cerrato, podsumowałbym Twoją wypowiedź jednym zdaniem: AI daje poczucie odsunięcia odpowiedzialności od człowieka. Ale to tak nie działa, o kasę/wyrządzone szkody zawsze jest się kto upomnieć. AI obnaża głupotę, jak kiedyś zrobił to Internet.

Pyxis napisał(a):

ple123 napisał(a):

AI piszę kod ale żeby zadać mu pytanie i złożyć/lub poprawić w całość to co wygenerowało to trzeba mieć wiedzę programistyczną. Osoba bez tej wiedzy nie da sobie rady.

To jest to ryzyko, że ktoś nie mając wiedzy albo nie będąc pewny, zaufa że podany kod jest dobry i tego nie zweryfikuje. Siłą rzeczy, gdy się coś kopiowało ze stackoverflow lub dokumentacji, to się taki kod dostosowywało do własnego problemu i się go weryfikowało. Teraz zwolennicy vibe codingu tego nie robią, uzasadniając że taki Claude Code sam się sprawdzi, wywoła kod, poprawi, etc. Ewentualnie uważają, że zrobią review i problem z głowy, tylko czy ich review pokrywa logikę aplikacji, wydajność i warunki brzegowe? Czy tylko sprowadza się do sprawdzenia estetyki kodu?

Stąd kwestia stworzenia dobrych metryk i monitoringu. Pracownicy też przecież wypuszczają babol za babolem, piszą kod spaghetti, wybierają złe technologie itd. nasze doświadczenie/wiedza zostały skompresowane w LLMach. Tak jak @cerrato napisał, trochę źle podchodzimy do tematu. Pisanie "kto to będzie sprawdzał" zakłada, że większość programistów w tym momencie napisze lepszy kod, niż AI I musi sprawdzać swojego glupiego brata. Jaką weryfikację jest w stanie zrobić przeciętny mod dev, której nie jest w stanie zrobić inny agent?

Jeśli człowiek coś wie, a LLM tego nie uwzględni, to najczęściej jest jakiś brak wewnętrznej wiedzy o projekcie/środowisku. A wtedy wystarczy tylko uzupełniać na bieżąco dokumentację. Przecież nowy developer przez parę miesięcy też zadaje głupie pytania i jest babysittowany. A tutaj wystarczy raz dobrze stworzyć opis środowiska i dostępy i możesz takich stu developerów na sterydach w sekundę wpuścić do systemu

Oddelegowując zadanie do LLM-ów dostajesz najbardziej prawdopodobne rozwiązania z punktu widzenia słów kluczowych, które były w opisie, czyli w prompcie. Na przykład pisząc z LLM-em o optymalnych rozwiązaniach w uczeniu maszynowym, dostaję standardową listę algorytmów. Problem w tym, że one nie działają tak, jakbym chciał, trzeba je dostosowywać do swoich potrzeb/danych/wymagań biznesowych.

nasze doświadczenie/wiedza zostały skompresowane w LLMach.

I to jest całe clou. LLM kompresując dane powoduje, że część z nich jest usuwana, a zostają tylko te, które najczęściej występują w danych treningowych. Zresztą na tym polega uogólnianie w AI/ML. Siłą rzeczy LLM jest wyszukiwarką na sterydach, niczym więcej. Występuje jakiś tam reasoning, ale w problemach zamkniętych, a nie otwartych, czyli nie jest kreatywny. Nie za bardzo wychodzi poza latent space. Człowiek wychodzi poza latent space przez lata doświadczeń. Tak więc pisząc z agentami kod ubijasz tę możliwość w zarodku. Zabijasz innowacje. Krótkofalowo masz zysk, dowiozłeś kupa-feature, długofalowo robisz dług technologiczny, rynek nie produkuje doświadczonych programistów, bo nie ma takiego zapotrzebowania. To jest nonsens.

Mocno przerysowując, ale może to do niektórych przemówi: to tak jakbyś powiedział teraz, że możesz wykonywać każdy zawód umysłowy, bo masz pod ręką LLM-a, który da Ci odpowiedź na każde pytanie z danej dziedziny.

Pyxis napisał(a):

Oddelegowując zadanie do LLM-ów dostajesz najbardziej prawdopodobne rozwiązania z punktu widzenia słów kluczowych, które były w opisie, czyli w prompcie. Na przykład pisząc z LLM-em o optymalnych rozwiązaniach w uczeniu maszynowym, dostaję standardową listę algorytmów. Problem w tym, że one nie działają tak, jakbym chciał, trzeba je dostosowywać do swoich potrzeb/danych/wymagań biznesowych.

nasze doświadczenie/wiedza zostały skompresowane w LLMach.

I to jest całe clou. LLM kompresując dane powoduje, że część z nich jest usuwana, a zostają tylko te, które najczęściej występują w danych treningowych. Zresztą na tym polega uogólnianie w AI/ML. Siłą rzeczy LLM jest wyszukiwarką na sterydach, niczym więcej. Występuje jakiś tam reasoning, ale w problemach zamkniętych, a nie otwartych, czyli nie jest kreatywny. Nie za bardzo wychodzi poza latent space. Człowiek wychodzi poza latent space przez lata doświadczeń. Tak więc pisząc z agentami kod ubijasz tę możliwość w zarodku. Zabijasz innowacje. Krótkofalowo masz zysk, dowiozłeś kupa-feature, długofalowo robisz dług technologiczny, rynek nie produkuje doświadczonych programistów, bo nie ma takiego zapotrzebowania. To jest nonsens.

Mocno przerysowując, ale może to do niektórych przemówi: to tak jakbyś powiedział teraz, że możesz wykonywać każdy zawód umysłowy, bo masz pod ręką LLM-a, który da Ci odpowiedź na każde pytanie z danej dziedziny.

Ale to dobrze, że dostajesz listę standardowych algorytmów. Człowiek też na początku wybiera najbardziej prawdopodobne rozwiązanie. Można je niuansować o swoją wiedzę, ale biorąc pod uwagę jak rozwija się IT, nie jest oczywiste, że twoje subiektywne doświadczenie o wyższości go nad javą jest aż takie niezbędne. Najczęściej lepiej wybrać odpowiedni zestaw narzędzi i iterować na podstawie problemów i bottlenecków, zamiast liczyć że wybierzemy coś idealnie. Jako iteracyjny proces, programowanie jest uzależnione od feedback loopów i w ten sposób też mogą ewoluować LLMy.

Zresztą już teraz powstają mini modele specjalizujące się w prawie czy finansach. Nie ma problemu by w podobny sposób nie powstały modele pod odpowiednią dziedzinę programowania, jeśli okaże się to niezbędne (w co wątpię).

LLM rozwiązał ostatnio 80 letni problem matematyczny. Oczywiście trochę za pomocą brute forcea, ale to tylko kwestia zasobów i algorytmów, by stało się to kosztowo nieodróżnialne od pojedynczego responsea

Najczęściej lepiej wybrać odpowiedni zestaw narzędzi i iterować na podstawie problemów i bottlenecków, zamiast liczyć że wybierzemy coś idealnie.

Pewnie idealnie nigdy się nie da. Ale to co opisujesz, to jak oddelegowanie zadania 100 juniorom zamiast 5 seniorom. Nawet jak tych 100 juniorów metodą siłową znajdzie rozwiązanie, to ono działa, ale nie bierze już pod uwagę architektury. Skupiają się, by działało i tyle. Sam to obserwowałem wielokrotnie, funkcją celu agenta nie było napisanego dobrego kodu, tylko działającego, szczególnie gdy było po drodze wiele błędów i agent się poprawiał iteracyjnie.