Nowe mnożniki za Copilota, nie tylko Anthropic liczy więcej niż wcześniej

https://docs.github.com/en/copilot/reference/copilot-billing/models-and-pricing#model-multipliers-for-annual-copilot-pro-and-copilot-pro-subscribers

Cena razy 9 w sumie....
Czy to początek podwyżek i w końcu realne ceny za LLM, czy dopiero początek i będą jeszcze podnosić?
Ktoś jest bardziej w tym temacie?

IMHO będzie jeszcze drożej. To nie moja opinia, a eksperta z USA u którego się uczę.

Fala za falą:

• najpierw fala zwolnień
• potem fala podwyżek
  

każdego ej aja można zastąpić skończoną ilością studentów

Zaczyna pękać

A czy jest jakiś powód by twierdzić, że nawet po takiej podwyżce to będzie za drogo? Wszystko będzie kręcić się dopóty, dopóki np 1 programista + AI będzie dowoził to samo taniej i szybciej niz np kilku bez AI (a czas też przelicza sie na pieniądze). Do tego czasu, warto będzie kupować tokeny nawet drożej niż dziś.

P.S. mnie osobiście dziwi czasem, jak widzę że ktoś kto jest przecież niezłym programistą totalnie nie potrafi pisać takich promptów, by uzyskać wartościowe odpowiedzi i przez to twierdzi, że lepiej żadnego AI nie używać i nie odróżnia nawet fazy planowaia od fazy implentacji.

P.S. chyba już to tu pisałem: na spaghetti code bez testów i AI nic nie poradzi - zawsze będzie sie to rozjeżdżać, a każda poprawka jednego błędu będzie generować wybuchy w innych miejscach, choćby był to najlepszy model, a pierwotnym powodem tego jest fakt, że nie ma sposobu na automatyczne sprawdzenie, czy zmiana niczego nie popsuła, więc nie ma iteracyjnego automatycznego poprawiania.

Także, jeśli ktoś liczy, że AI mu pomoże w grzebaniu w kupie, to się przeliczy niestety.

John Gordon napisał(a):

P.S. mnie osobiście dziwi czasem, jak widzę że ktoś kto jest przecież niezłym programistą totalnie nie potrafi pisać takich promptów, by uzyskać wartościowe odpowiedzi i przez to twierdzi, że lepiej żadnego AI nie używać i nie odróżnia nawet fazy planowaia od fazy implentacji.

Bo to się zrobiła wojenka jak w polskiej polityce. Albo jedni, albo drudzy. Nie ma nic pomiędzy.

Każdy ogarnięty programista jest w stanie napisać prompt. To tak jak programista potrafi napisać sensowny ticket w JIRA. Oczywiście są osoby, które tego nie potrafią i trzeba potem je dopytywać. Niekorzystanie z LLM-ów jest po prostu brakiem pewniej kompetencji, ale nadmierne korzystanie z nich, szczególnie generowanie kodu na produkcji, bo zrobiło się review*, to jeszcze gorszy rak.

John Gordon napisał(a):

A czy jest jakiś powód by twierdzić, że nawet po takiej podwyżce to będzie za drogo? Wszystko będzie kręcić się dopóty, dopóki np 1 programista + AI będzie dowoził to samo taniej i szybciej niz np kilku bez AI (a czas też przelicza sie na pieniądze). Do tego czasu, warto będzie kupować tokeny nawet drożej niż dziś.

P.S. mnie osobiście dziwi czasem, jak widzę że ktoś kto jest przecież niezłym programistą totalnie nie potrafi pisać takich promptów, by uzyskać wartościowe odpowiedzi i przez to twierdzi, że lepiej żadnego AI nie używać i nie odróżnia nawet fazy planowaia od fazy implentacji.

P.S. chyba już to tu pisałem: na spaghetti code bez testów i AI nic nie poradzi - zawsze będzie sie to rozjeżdżać, a każda poprawka jednego błędu będzie generować wybuchy w innych miejscach, choćby był to najlepszy model, a pierwotnym powodem tego jest fakt, że nie ma sposobu na automatyczne sprawdzenie, czy zmiana niczego nie popsuła, więc nie ma iteracyjnego automatycznego poprawiania.

Także, jeśli ktoś liczy, że AI mu pomoże w grzebaniu w kupie, to się przeliczy niestety.

Ale jeden programista i ej aj nie "dowozi" (swoją drogą co za kretyński termin, to już używajmy tego memicznego "dostarcza", przynajmniej wiadomo, że jest szydera z tępej kalki z angielskiego) szybciej niż kilku bez, bo wąskim gardłem nie jest generowanie kodu. Wydajność wzrasta może o 10%, a może o 50% (wątpliwe), ale to w żaden sposób nie uzasadnia tak drogich narzędzi i tak wielkich nakładów kapitałowych na ich rozwój. Cały hype bazował przecież na "agent driven development", ale jest już oczywiste nawet dla biznesu, że to jest chybione podejście.

John Gordon napisał(a):

A czy jest jakiś powód by twierdzić, że nawet po takiej podwyżce to będzie za drogo? Wszystko będzie kręcić się dopóty, dopóki np 1 programista + AI będzie dowoził to samo taniej i szybciej niz np kilku bez AI (a czas też przelicza sie na pieniądze). Do tego czasu, warto będzie kupować tokeny nawet drożej niż dziś.

Nigdy nie będzie za drogo. Nawet glupie AI, którego prompty będą proste tj. rozbij mi klasę na dwie części, przenieś jedną do innego pakietu, bla bla bla będzie pozytywnie wpływał na wydajność w porównaniu do powrotu do ery sprzed AI

Wszystko oczywiście rozchodzi się o koszta tj. jakie poziomy AI będziemy mieli za ile przy przewidywanym mocnym podbiciu cen. W najgorszym wypadku jedyną ekonomiczną opcją będą otwarte modele hostowane przez niezależne serwerownie, które też jakieś tragiczne nie są

szok napisał(a):

Czy to początek podwyżek i w końcu realne ceny za LLM, czy dopiero początek i będą jeszcze podnosić?
Ktoś jest bardziej w tym temacie?

Jeden youtuber poprawnie to przewidział, mówi że jesteśmy na etapie 2 a potem już nie będzie miesięcznych subskrypcji. To niestety nadal nie są realne ceny za LLM

kilemile napisał(a):

Ale jeden programista i ej aj nie "dowozi" (swoją drogą co za kretyński termin, to już używajmy tego memicznego "dostarcza", przynajmniej wiadomo, że jest szydera z tępej kalki z angielskiego) szybciej niż kilku bez, bo wąskim gardłem nie jest generowanie kodu. Wydajność wzrasta może o 10%, a może o 50% (wątpliwe),

Bo ja wiem? Co będzie szybsze: napisać prompt -> Claude napisze kod taki jak chcesz, czy pisać go z palca. A refactoring? To już jest małpia robota - prosta, żmudna i czasochłonna. Planowanie? Tu też Claude (najnowszy, Opus) nie jest taki zły. To znów sprowadza się do tego, co pisałem wcześniej i co jest już zresztą ujęte w innych wątkach w tym dziale: nie możesz napisać tylko "zrób mi to i to" i czekać aż zrobi za ciebie.

A i jeszcze jedno: samodzielnie dużo tracisz na wyszukiwanie rozwiązań problemów, okiełznania jakiegoś liba, szperanie w dokumentacji, poprawianiu kodu gdy coś się sypnie. AI to już w dużej mierze potrafi ogarnąć - zagląda nawet do kodów biblioek i wyciąga wnioski. To co byś sam robił, tyle że zajmie ci to dłużej.

W komentarzu mi się nie zmieściło:

I tu wracamy do testów automatycznych. Nie wiem jakiego modelu używasz: Claude po prostu odpali test -> okaże się że źle, leci kolejna iteracja aż dojdzie do prawdy. Tak samo w międzyczasie wielokrotnie odpala projket, wyciąga wnioski z logów i stactkrace i leci z kolejną iteracją. No ale rzeczywiście: jeśli tylko napiszesz pojedynczy prompt -> coś dostaniejsz, sprawdzasz -> źle to zgodzę się że to niewiele daje. A jeszcze jak masz kiepski kod, mały kontekst (model nie widzi wszystkiego), to ci rozwali coś gdzieś indziej i o tym "nie wie". Wtedy to faktycznie już traci sens

Wiem, że tak to działa, ale to jest fascynacja dzieciaka, który dostał dostęp do półki ze słodyczami. Co z tego, że się poprawi? Testy też Ci napisał i w oparciu o te testy sam się poprawia. Trochę takie gadanie, jakbyś iteracyjnie chciał poprawiać błędy LLM-a tym samym LLM-emem. A jeszcze jak masz kiepski kod, mały kontekst - najłatwiej zwalić na słaby kod. Jak masz dobry kod, to żaden LLM-em nie musi go rozwijać. Możesz się nim wspomagać, omówić jakąś strategię, lepsze rozwiązanie etc. Jak masz nawet idealny kod (ten co uszył w całości Claude), to jak aplikacja jest duża, to i tak zgubi kontekst.

Pyxis napisał(a):

Wiem, że tak to działa, ale to jest fascynacja dzieciaka, który dostał dostęp do półki ze słodyczami.

No szczerze ja nie myślę tymi kategoriami. Jeśli coś mogę zrobić szybciej i łatwiej - korzystam z tego. To nie "fascynacja" tylko pragmatyzm, tak bym to określił.

Pyxis napisał(a):

Testy też Ci napisał i w oparciu o te testy sam się poprawia.

Tak, dokładnie. Tylko że możesz mu narzucić coś w rodzaju TDD - testy działające masz najpierw, a służą one potem do walidacji implementacji. Do wygenerowania testu nie potrzeba dużego kontekstu. Jeśli masz to sensownie podzielone - to masz dużo testów, testujących pojedyncze rzeczy, najlepiej testy od siebie niezależne i możesz mieć nawet 1000 testów - wystarczy że jeden się wywali, żeby wiadomo było co jest źle - i w ten sposób nie potrzebujesz dużego kontekstu aby automatycznie poprawił złą implementację. Model nie musi wtedy ogarniać całego projektu - wystarczy mu rezulatat wykoanania testów - po tym od razu wie, co trzeba poprawić.

Pyxis napisał(a):

Testy też Ci napisał i w oparciu o te testy sam się poprawia.
Trochę takie gadanie, jakbyś iteracyjnie chciał poprawiać błędy LLM-a tym samym LLM-emem. A jeszcze jak masz kiepski kod, mały kontekst - najłatwiej zwalić na słaby kod. Jak masz dobry kod, to żaden LLM-em nie musi go rozwijać. Możesz się nim wspomagać, omówić jakąś strategię, lepsze rozwiązanie etc. Jak masz nawet idealny kod (ten co uszył w całości Claude), to jak aplikacja jest duża, to i tak zgubi kontekst.

Pewnie że nie musisz. Tak samo jak nie muisz używać recactoringu w IDE albo Znajdź -> Zamień. Zrobisz wszystko sam, tylko czy w tym samym czasie?

Tak BTW: zapewne jak zwykle "to zależy" - od technologii, frameworku do testów i jeszcze wielu innych rzeczy, ja piszę z perspektywy mojej własnej. W innych technologiach może się okazać, że np AI jest słabiej wytrenowane, nie możesz mieć w dużym projekcie 2000 testów, które odpalają się w 30 sekund, a większości rzeczy nie przetestujesz automatycznie w ogóle. Ale to już by trzeba było wejść w jakiś konkretny use case.

No szczerze ja nie myślę tymi kategoriami. Jeśli coś mogę zrobić szybciej i łatwiej - korzystam z tego. To nie "fascynacja" tylko pragmatyzm, tak bym to określił.

Z tą fascynacją chodzi mi o to:

Despite widespread adoption, the impact of AI tools on software development in the wild remains understudied. We conduct a randomized controlled trial (RCT) to understand how AI tools at the February-June 2025 frontier affect the productivity of experienced open-source developers. 16 developers with moderate AI experience complete 246 tasks in mature projects on which they have an average of 5 years of prior experience. Each task is randomly assigned to allow or disallow usage of early 2025 AI tools. When AI tools are allowed, developers primarily use Cursor Pro, a popular code editor, and Claude 3.5/3.7 Sonnet. Before starting tasks, developers forecast that allowing AI will reduce completion time by 24%. After completing the study, developers estimate that allowing AI reduced completion time by 20%. Surprisingly, we find that allowing AI actually increases completion time by 19%--AI tooling slowed developers down. This slowdown also contradicts predictions from experts in economics (39% shorter) and ML (38% shorter). To understand this result, we collect and evaluate evidence for 20 properties of our setting that a priori could contribute to the observed slowdown effect--for example, the size and quality standards of projects, or prior developer experience with AI tooling. Although the influence of experimental artifacts cannot be entirely ruled out, the robustness of the slowdown effect across our analyses suggests it is unlikely to primarily be a function of our experimental design.

https://arxiv.org/abs/2507.09089
Ja to widzę tak, masowe używanie LLM-ów to trochę jak scrollowanie rolek. Masz efekt, ale nie myślisz o konsekwencjach. Na rolkach tracisz masę czasu, nic z tego nie wynika, płacisz swoim czasem reklamodawcom. Podobnie jest z LLM-ami, przy czym płacisz za tokeny. Jak robiłem studia wiele lat temu, to kadra naukowa wspominała, jak to spędzała czas w bibliotekach, gdzie publikacje naukowe wydawane cyklicznie w postaci książek. Mówili nam, że mając teraz Internet jest im prościej, a więc dla nas ukończenie studiów powinno być łatwiejsze niż kiedyś, bo wiedza jest na wyciągnięcie ręki.

To była jednak częściowo tylko prawda, bo swoje trzeba było przepracować. Nieważne czy czytając publikację w PDF, czy w wersji drukowanej. Ostatnio się dowiedziałem, że współcześni studenci piszą prace magisterskie robiąc je od A do Z z LLM-ami. To już nie jest automatyzacja. To wrażenie, że się robi szybciej, nie dotyka się sedna, tylko traktuje temat powierzchownie. Jak będziemy tworzyć taki powierzchowny kod, to utracimy kreatywność i innowacje. To jest to zagrożenie. Twoje porównanie Znajdź -> Zamień vs ręcznie zmieniaj jest chybione. Nie o to tutaj chodzi.

do tego co @Pyxis napisał. Pracuję od 2012 roku. Pamiętam magiczne stałe z pierwszej pracy. 9999 w bazie oznaczało połączenie z operatorem. 9998 to był kafelek/id inny specjalny. Teraz generuję kod który nie wiem ja działa. Próbuję ogarnać nowego angulara. PoC hobbystyczny. Wygenerowałem kod z pomocą codexa i cursora i skończyły się darmowe tokeny, ale coś tam działa. Teraz męcze to czatem gpt i włos mi się na głowie jeży. Czat mi pisze że ten kod wygląda jak angular 10 zmigrowany do 14. Pomógł mi go zmigrować na 21. Wtedy skończyły mi się tokeny do droższego modelu. Tańszy mówi iż angular 21 jeszcze nie jest wydany. 3 razy migrowałem między signals a reactive forms i dalej nie wiem co lepsze. W każdym komponencie mam inaczej napisany kod

Tak trochę obok tematu.. testowałem Claude, GPT i Gemini i muszę stwierdzić, że obecnie Claude znacznie wyprzedza te 2 pozostałe, gdybym chciał robić tak jak napisałem używając GPT albo Gemini to po prostu by się to nie udało. GPT nic nie potrafił zaplanować, kręcił się w kółko, po kolejnym prompcie sam sobie zaprzeczał, Gemini był chyba nawet gorszy.

No i faktycznie - najgorzej to wygenerować coś przez AI, skończą się tokeny, a ty zostajesz z kodem, którego nie rozumiesz. Nie wiem jak sie ma Cursor do np Jetbrains AI, którego używam - u mnie sam wykonuje polecenie bash, jak ma zrobic reactoring, to generuje sobie skrypty pythona lub bash w /tmp i je odpala - wydaje mi się że takie rzeczy to nie tylko kwestia modelu. Więc tu może nakładać się wiele czynników wpływających na końcowy efekt.

Robię IaC i liczba przypadków, gdy LLM zwyczajnie coś zmyśla, jest wprost absurdalna.

Mogę tego używać jako bardziej wypasiony Cmd+Shift+R i fajnie, dam mu przykład jak zedytowałem jeden plik i przejdzie walcem 150 kolejnych. Mogę sobie przyspieszyć googlowanie i jest fajnie, ewentualnie wygenerować jakiegoś Basha jeśli się nie muszę martwić że ktoś to będzie potem czytał (kto inny niż Klaudiusz). Tylko to w sumie tyle, bo generowanie IaC które musi być potem pod okiem automatów i człowieka to jest dramat, począwszy od tego, że Klaudiusz wymyśla ficzery Terraforma, których nie ma, wymyśla zasoby providera, których nie ma, a potem wymyśla API nawet tym, które istnieją, lub kompletnie myli wersje.

Ostatnio spaliliśmy miesiąc, bo ktoś zawierzył Klaudiuszowi, a nie dali nam czasu na research i studiowanie dokumentacji - przecież Klaudiusz zrobi szybciej... No i miesiąc stawialiśmy coś, co nawet gdyby udało się przymusić do działania nie byłoby wspierane przez nikogo, a już tym bardziej przez vendora

superdurszlak napisał(a):

Mogę tego używać jako bardziej wypasiony Cmd+Shift+R i fajnie, dam mu przykład jak zedytowałem jeden plik i przejdzie walcem 150 kolejnych. Mogę sobie przyspieszyć googlowanie i jest fajnie, ewentualnie wygenerować jakiegoś Basha jeśli się nie muszę martwić że ktoś to będzie potem czytał (kto inny niż Klaudiusz). Tylko to w sumie tyle, bo generowanie IaC które musi być potem pod okiem automatów i człowieka to jest dramat, począwszy od tego, że Klaudiusz wymyśla ficzery Terraforma, których nie ma, wymyśla zasoby providera, których nie ma, a potem wymyśla API nawet tym, które istnieją, lub kompletnie myli wersje.

w większości prawda, ale też brzmi trochę jak skill issue, klaudiusz nie napisze dobrego kodu jeśli go o to nie poprosisz, nie ustalisz sztywnych reguł i wymagań i nie dostarczysz dokumentacji, a najlepiej jak już ma przykład dobrze napisanego kodu i ma tylko zrobić analogiczny feature, wtedy nawet testy pisze z rozpędu bez pytania. Najlepiej używać go na małych płatach kodu które jesteś w stanie naprawdę przejrzeć i kontrolować; ostatnio się na przykład przejechałem na tym "dam mu przykład jak zedytowałem jeden plik i przejdzie walcem 150 kolejnych" bo po pierwszych paru replace'ach zaczyna mu się ufać a tu nagle odwala coś losowego, na przykład bez powodu poza tym co miał zrefaktorować zamienił przy okazji stringa w teście "9999995" na "99999 ninety-five"

superdurszlak napisał(a):

Mogę tego używać jako bardziej wypasiony Cmd+Shift+R i fajnie, dam mu przykład jak zedytowałem jeden plik i przejdzie walcem 150 kolejnych.

intellij ma takiego lepszego ctrl+shift+r: https://www.jetbrains.com/help/idea/structural-search-and-replace.html
może by się dało przymusić klaudiusza, żeby wygenerował templatki do structural search and replace? :]

p.s.
chatgpt zgubił historię moich czatów z ostatniego tygodnia. nawet niektóre z tych co zostały to się nie ładowały, ale chyba przynajmniej to się naprawiło. dodam, że mam subskrypcję chatgpt plus, więc nie powinni mnie traktować jak pariasa, no nie?

p.p.s.
chatgpt przywrócił historię tych czatów co ileś tam godzin wcześniej zgubił. heh, ciekawe, że github miał trochę podobny problem w tym samym czasie, tzn. na githubie nie wyświelała się część pull requestów na przykład.

CEO nigdy nie przyznaja, ze sa idiotami. AI zostanie zastapione tanim Offshorem.

pradoslaw napisał(a):

IMHO będzie jeszcze drożej. To nie moja opinia, a eksperta z USA u którego się uczę.

Jak się nie będzie biznesowo kalkulowało, to nikt z tego nie będzie korzystał na siłę. Dopóki taniej wyjdzie zatrudnić kogoś z Indii, to będzie to pierwszy wybór...