Czy edytujecie kod ręcznie?

W mojej obecnej pracy cały zespół używa Codexa. Ja używam modelu Sol Extra High do typowych zadań. Od prawie 3 miesięcy nie otworzyłem IDE, żeby coś zmienić w kodzie. Jeżeli coś mi się nie podoba to piszę o tym w chacie i codex edytuje kod. Stack w projekcie: C#, MassTransit, React. Czy w pracy edytujecie jeszcze kod ręcznie?

Czytam by zrozumieć i poprawiam, bo czasami pisze głupoty i przekombinowuje.

Tak, ale od czasu do czasu piszę ręcznie ale to bardziej jakieś małe drobne rzeczy, w zależności od sprawy. Głównie stawiam na Codex Sol w różnych ustawieniach albo przeplatam go z Claude Code Fable 5.

Nie, używam Claude Code, Opus 5 z ustawieniem Ultracode. Nie ma potrzeby tak naprawdę poprawiać ręcznie prawie nigdy.

To pytanie nie ma sensu, bo zwykle to jest całe spectrum, gdzie na jednym końcu masz amatorów, którzy tylko wydają polecenia LLM-owi, a na drugim końcu masz konserwatystów, którzy nawet nie tykają LLM-ów i piszą wszystko ręcznie. Ja jestem bliżej tej drugiej grupy, bo jak zacząłem robić jak pierwsza grupa + weryfikować output, to okazało się, że bardziej optymalne i szybsze jest:

• Przegadanie koncepcji i sprawdzenie, co jest na czasie w danym zagadnieniu,
• Dostosowanie rozwiązania do problemu, nie bazowanie na generalizacji, czyli tym do czego stworzono LLM-y,
• Używanie LLM-a jako tab completions w momencie, gdy dokładnie wiesz, co chcesz napisać.

Głównie kod generuję, potem sprawdzam i poprawiam ręcznie lub jak widzę że jest więcej zmian i mi się nie chcę robić typowego kopiuj wklej pozamieniane, to biorę szybszy model i mówię, o co mi chodzi

Już nie pamiętam kiedy napisałem kompletną metodę.
Projektowanie i kierowanie moim małym zespołem bez pisania kodu nadal sprawia frajdę.
Poruszam się z AI małymi krokami, dość dokładnie analizuje czy się zrozumieliśmy i muszę korygować kierunek.
Zacząłem pisać masę testów choć w życiu nigdy tego nie robiłem (to znaczy zaczęliśmy :D )
Trochę też zacząłem inaczej projektować aby wygodniej testowało się AI i mi wygodniej analizował się wyniki
Używam tylko codex + vscode

Zauważyłem, że ludzie z branży podzielili sie na kilka wyraźnych grup:

• grupa 1: Od tego AI to z daleka, ja tam piszę wszystko dalej z palca, AI - a komu to potrzebne? A na co? Ja tam swoje zrobię sam. Raz odpalił kiedyś jakiegoś ChatGPT, zobaczył że halucynuje albo nawet nie odpałał niczego - wsłuchuje sie w narzekania influencerów IT - oni potwierdzają że ma rację.
• grupa 2: podstawowa świadomość, że istnieją różne modele, różne ustawienia, czasem używają podstawowych modeli do refactoringu albo wygenerowania jakiejś klasy. Nigdy nie zlecają agentowi nawet projektu architektury, choć mają świadomość że istnieje coś takiego jak planowanie bez implementacji, gdzie ma się wpływ na każdy etap to uważają że lepiej jak architekturę zaprojektują sami. Nie mają świadomośći, jak skonfigurować agenta - guidelines, skills aby działał zgodnie z wytycznymi. AI to taki lepszy refactor tylko i wyłącznie.
• grupa 3: zgłębia temat. Wie jakie modele są najlepsze do jakiego zadania, potrafi konfigurować subagentów, potrafi ustawiać ograniczenia i narzucać konwencję agentom, aby generowany był jak najlepszy kod, wie jakie prompty pisać aby osiągnąć efekt.

Moim zdaniem ludzie z grupy 1 popracują w branży jeszcze kilka lat, a potem na bruk, bo przyjdzie ktoś młodszy, kto zrobi to samo co oni, tak samo dobrze ale 10 razy szybciej. Moim zdaniem można sobie zamykać oczy na rzeczywistość, ale ucieczki od AI już nie ma. Modele są coraz lepsze - to co było jeszcze 2 lata temu a co jest teraz to przepaść. Co będzie za 5 lat? Zobaczymy. Moim zdaniem, 90% to będzie vibe coding, a generowany kod juz mało kto będzie czytał - wystarczą metryki testy automatyczne. Tak samo jak dziś nikt nie czyta kodu assmeblera, który jest generowany przez kompilator C++ ani nikt nie czyta kodu autogenerated generowanego przez różne biblkioteki i toole. Jeśli agent zaprojektuje architekturę, a potem wypluje imeplemntację na 20 klas i tysiące linii kodu, to czytanie tego linia po linii stanie się zbędne - wystarczy odpalenie metryk, które sprawdzą czy naprawdę kod trzyma się projektu architektury i testy aby sprawdzić czy działa tak jak powinien.

Ciągnąc dyskusję z komentarzy, gdy mam np test taki jak ten:

blocTest<UserManagementBloc, UserManagementState>(
        'emituje [loading, unauthenticated] przy bledzie API',
        setUp: () {
          stubAuthLoginThrows();
          stubGetUserInfoNotNeeded();
        },
        build: () => userManagementBloc,
        seed: () => const UserManagementState.unauthenticated(),
        act: (bloc) =>
            bloc.add(const UserManagementEvent.loginRequested(
              cityId: '1',
              method: LoginMethod.credentials(),
              username: 'admin@test.com',
              password: 'admin',
            )),
        expect: () => [
          const UserManagementState.loading(),
          const UserManagementState.unauthenticated(
            error: strings.loginErrorInvalidCredentials,
          ),
        ],
      );

To wiem, że logika jest prawidłowa: gdyby api rzuciło wyjątkiem, dzieje sie to co ma się dziać, czyli ustawiany jest odpowiedni stan. Jeśli nasłuchuje jakieś gui, to wyświetli co trzeba, jeśli nie to nie ważne że test sprawdza logikę i w sumie wszystko co sie dzieje w aplikacji można pokryć takimi testami jak ten. I AI bardzo dobrze sobie radzi z generowaniem takich testów - potem wiadomo czy nie ma gdzieś regresji, a prawie wszystkie te testy można puścić równolegle i wykonują się błyskawicznie.

Testy gui też są szybkie - bo wystarczy podstawić wszystkie możliwe stany i sprawdzić czy wyświetlane jest to co trzeba i to może być też być uruchamiane niezależnie.

Ostatnio dostałem zadanie przepisać starą appkę w javie 4 czy tam javie 5 na javę 21. Stary kod to od groma klas, jakiś plików .jsp, różnych dziwnych configów.
Gdybym miał to analizować ręcznie i wszystko czytać i przeklikiwać wywołania metod sam to bym po miesiącu nie ruszył z miejsca.
Wrzucałem co wlezie w copilota wraz z dokmentacją wymagań w wordzie. Potem napisałem prompt co potrzebuję. Wygenerowało mi klasy w Javie i od razu testy i front. Odpalam i działa. Byłem zaskoczony tym jak mało musiałem poprawiać ręcznie. Przy takim flow, gdzie prawie wszystko działa od razu to faktycznie można pisać szybciej.

Jestem sobie w stanie wyobrazić jak ktoś uzbrojony w armię agnetów będzie napie*dalać aplikacje jak szalony. Zapewne w niektórych instytucjach będzie się to wdrażać wolniej. Zapewne będą jakieś modele korzystające tylko z jakiś lokalnych, zaufanych centrów danych, może powstaną jakieś mniejsze, mniej zasobożerne narzędzia, które będzie się uruchamiać na własnym sprzęcie.

Dalej podtrzymuję moją analogię do TIRowców i naczep mega. Miało zabraknąć pracy dla kierowców a po prostu wozi się 5x więcej towarów.
Tak samo będzie z kodem. Ale to nie wydarzy się z dnia na dzień. Stopniowo co raz więcej firm będzie przechodzić z ręcznego pisania na generowanie przynajmniej tak długo jak tokeny są tanie.

Gdy stakeholderzy się upomną o dywidendę to zobaczmy czy wtedy bańka nie pęknie. Podejrzewam, że jeszcze wejdą ulepszenia wydajnościowe by generowanie kodu zżerało mniej energii.

No tak, tylko jeśli chodzi o transport - to jest co wozić. Pytanie czy będzie aż tyle aplikacji do stworzenia i aż tyle kodu do napisania. Tak btw - podałeś fajny case, faktycznie - przepisywanie legacy to jest coś, do czego AI wybitnie się nadaje, bo potrafi ogarnąć całą logikę, która była przedtem i z tego zrobić plan imeplementacji - a tak, musiałbyś sam podawać mu specyfikację, co bywa uciążliwe. Analogicznie: przepisywanie na inną technologię.

Ja jestem grupa 4. Wiem, że istnieją różne modele, że można się bawić w odgrywanie ról z agentami, ale mam to gdzieś. Jeśli to ma być inteligencja, więc sama ma wiedzieć, co jej wolno, a co nie, kiedy może zdecydować sama, a kiedy mnie dopytać.

Tak, ale najpierw się bawię w pisanie specyfikacji i innych takich, po czym palę trochę tokenów, potem poprawiam specyfikację, potem palę trochę więcej, a na końcu sam robię to, na czym agent się wyłożył.

Był taki złoty czas, gdy nie musiałem aż tak często edytować kodu ręcznie, ale Anthropic wypuścił Claude 5...

grupa 2: podstawowa świadomość, że istnieją różne modele, różne ustawienia, czasem używają podstawowych modeli do refactoringu albo wygenerowania jakiejś klasy. Nigdy nie zlecają agentowi nawet projektu architektury, choć mają świadomość że istnieje coś takiego jak planowanie bez implementacji, gdzie ma się wpływ na każdy etap to uważają że lepiej jak architekturę zaprojektują sami. Nie mają świadomośći, jak skonfigurować agenta - guidelines, skills aby działał zgodnie z wytycznymi. AI to taki lepszy refactor tylko i wyłącznie.

IMO kocopoły.

• Możesz pisać tyle guidelines, ile tylko chcesz, a agent w dowolnym momencie może uznać, że je zignoruje, albo założyć, że jak mówisz nie, to masz na myśli tak.
• Możesz zablokować agentowi dostęp do wybranych komend / subkomend, tylko co z tego, jak wytyczne do tego, jak ma być zrealizowane zadanie, już ciężej weryfikować bez wkładu przekraczającego samodzielne rozwiązanie zadania.
• Nigdy nie zlecają agentowi projektu architektury PRZEDE WSZYSTKIM nie zlecam agentom projektu czegokolwiek. Modele językowe nie mają zdolności myślenia, a już tym bardziej myślenia abstrakcyjnego i krytycznego, więc dlaczego mam zlecać najbardziej wymagającą poznawczo część zadania modelowi statystycznemu? Jeśli zlecę projekt, spędzę więcej czasu na poprawianiu go, lub na poprawianiu błędów jeśli coś przeoczę, niż gdybym wpierw rozpoznał temat, podjął kluczowe decyzje, zaplanował sobie jak ma być skonstruowane rozwiązanie, a dopiero potem opisał to w specyfikacji. W przeciwnym razie agent napisze mi dokument pełen przeróżnych założeń, które się posypią przy pierwszej próbie weryfikacji. Agent implementuje moją specyfikację i to tyle, weryfikując ją w sposób, jaki mu nakreślę.
• lepszy refactor kłóciłbym się, czy lepszy, po zmarnowaniu setek roboczo-godzin na próbach dokonania refaktoru przez agenta realizującego jakąś specyfikację. Jedyny sensowny refaktor, jaki udawało się tym zrobić, to opieranie się o przykłady, jak się np. przetransformowało struktury danych albo moduł samemu, i jak należy zmienić pozostałe. Nie miałem jeszcze sytuacji, bym zlecił agentowi refaktor jedynie na bazie słowno-muzycznego opisu, czego chcę, że ma być YAGNI, KISS i w ogóle, żeby agent nie wysadził mi kodu w powietrze. Przy czym ja głównie piszę IaC.

Jedyny przypadek, gdzie z powodzeniem udaje mi się wykorzystywać agentów to wówczas, gdy najpierw samemu porządnie zgłębię temat, zamiast liczyć na to, że jak napiszę sobie super skilla, świetny guardrail i pocałuję fotografię Altmana, to za którymś razem w końcu ten jednoręki bandyta na sterydach zwróci zadowalający wynik.

grupa 3: zgłębia temat. Wie jakie modele są najlepsze do jakiego zadania, potrafi konfigurować subagentów, potrafi ustawiać ograniczenia i narzucać konwencję agentom, aby generowany był jak najlepszy kod, wie jakie prompty pisać aby osiągnąć efekt

Ponownie, kocopoły. Jeśli w robocie mam dostęp do modeli firmy X, to używam modeli firmy X, a nie płacę z własnej kieszeni za modele firmy Y, które mają być "lepsze". Co więcej nie zamierzam ryzykować konsekwencji dyscyplinarnych, gdyby wskutek takich zabaw z subskrypcjami, w których firma nie ma ustawionej wajchy Enterprise a.k.a. "zapłacimy ekstra byście nie trenowali na naszych danych" wyciekły jakiekolwiek poufne/niejawne informacje lub kontekst. Nie mówiąc o tym, że nie uważam za stosowne płacić za możliwość pracy, krzesła biurowego i monitorów też nie przynoszę do biura swoich, więc dlaczego miałbym kupować sobie subskrypcję po naczytaniu się na blogach, jaki to Fikus Mikus jest lepszy od Biggus Dickus. Na modele, do których mam dostęp, też mam pewien budżet do wykorzystania, także nie będę pakował się w Fable do każdej durnoty, bo jest "lepszy" niż Sonnet czy tam Opus, jeśli w konsekwencji przez 2 tygodnie będę musiał dłubać ręcznie albo świecić oczami..

LOL. Claude Opus 5 + Ulracode nigdy nie uznał że zrobi coś inaczej niż przedtem było w planie. Podejrzewam że nie odróżniasz nawet Opus od Sonnet i Haiku ani trybu planowania od implementacji. Na etapie planu sam zadaje szczegółowe pytania, gdzie wybierasz opcje lub wpisujesz jak ma być, a plan przed zatwierdzeniem możesz dowolnie poprawiać.

W sumie mniej to nawet cieszy że większość nie potrafi posługiwać się tymi narzędziami, dzięki temu jestem zawsze do przodu.

John Gordon napisał(a):

Podejrzewam że nie odróżniasz nawet Opus od Sonnet i Haiku ani trybu planowania od implementacji.
W sumie mniej to nawet cieszy że większość nie potrafi posługiwać się tymi narzędziami, dzięki temu jestem zawsze do przodu.

Jeśli szczyt Twoich możliwości to wycieczki personalne, mogłeś przynajmniej napisać prompta, by model wygenerował Ci odpowiedź.

Parafrazując Twoją wypowiedź, podejrzewam, że albo nie przeczytałeś mojej odpowiedzi, albo nie byłeś w stanie jej zrozumieć, w sumie mnie to nawet cieszy, dzięki temu jestem zawsze do przodu.

Po prostu to wszystko co piszesz potwierdza się tylko wtedy, gdy używasz najgorszych modeli Claude, np Sonnet albo Haiku, z niskimi ustawieniami wnioskowania. Piszesz ogólnie "Claude 5", co wskazuje na to że nie odróżniasz tych ustawień, można podejrzewać że odpaliłeś sobie "Claude 5" tak jak ci się akurat uruchomił, dałeś prompta i to tyle.

No i podtrzymuję - dla mnie to dobrze, że większość najwyraźniej nie potrafi posługiwać się tymi narzędziami, dzięki temu ja mam więcej zleceń i zadowolonych klientów, a więcej zleceń to więcej kasy. Gdy pozostali 10 razy dłużej piszą ręcznie, co kto woli

John Gordon napisał(a):

Po prostu to wszystko co piszesz potwierdza się tylko wtedy, gdy używasz najgorszych modeli Claude, np Sonnet albo Haiku, z niskimi ustawieniami wnioskowania. Piszesz ogólnie "Claude 5", co wskazuje na to że nie odróżniasz tych ustawień, można podejrzewać że odpaliłeś sobie "Claude 5" tak jak ci się akurat uruchomił, dałeś prompta i to tyle.

niedawno używałem claude opus 5 xhigh i gubił polecenia. ogólnie w korpo mam wiele ograniczeń możliwości wywoływania programów, eskalacji uprawnień, trybów powershella i innych różnych rzeczy, więc tryb agenta w vscode github copilot chat musi kombinować w nietypowy sposób, żeby polecenia nie zostały (w ten czy inny sposób) zepsute przez korpo konfigurację. jak agent zapomni o ograniczeniach i zacznie optymistycznie zakładać że da się odpalić każdego rodzaju polecenie powershella, pythona, etc to widzę, że mu się wiele rzeczy nie udaje. gpt-6 astra lepiej się trzyma poleceń. jednak to bardzo subiektywne odczucia po w sumie niedużej liczbie zadań dla agentów.

tak czy siak, widać nadal (względnie) dynamiczny postęp. gpt-6 astra wydaje mi się dużo wygodniejszym narzędziem niż poprzednicy (używam i tak głównie gpt). jednak pewnie za kilka lat narzędzia będą znowu dużo dużo wygodniejsze w użyciu niż dzisiejsze. dzisiejsi entuzjaści ai przecierają szlaki dla ludzi, którzy dopiero powoli wdrażają się w narzędzia ai. czy jest sens doktoryzować się z narzędzi ai już teraz, skoro rozwój jest dalej dynamiczny i za rok, dwa, trzy będzie można się wdrożyć w całą otoczkę ai dużo łatwiej i szybciej niż teraz? to zależy jakie kto ma potrzeby.

No i podtrzymuję - dla mnie to dobrze, że większość najwyraźniej nie potrafi posługiwać się tymi narzędziami, dzięki temu ja mam więcej zleceń i zadowolonych klientów, a więcej zleceń to więcej kasy. Gdy pozostali 10 razy dłużej piszą ręcznie, co kto woli

aaaa, a więc robisz zlecenia, a nie pracujesz na (prawdziwym bądź udawanym) etacie? no to tutaj ai slop ma dużo więcej sensu, bo zlecenie kojarzy mi się z czymś a'la 'zakuć zdać zapić zapomnieć', a nie długodystansowym utrzymaniem nietrywialnego systemu. sam myślałem o tym, żeby wyrwać się z wysiadywanej dupo-godzinami i pato-dyżurami korpo-beznadziejności i zamiast tego zająć się produkowaniem ai slopu na zlecenie, ale i tak własnym tempem i według własnych preferencji, ale w sumie nie wiem jak się za to zabrać, żeby to miało sens.

aaaa, a więc robisz zlecenia, a nie pracujesz na (prawdziwym bądź udawanym) etacie?

Jedno i drugie. Natomiast, gdy napisałeś o blokadach coś innego mi przyszło do głowy. Ja pracuję na Linuksie, żadnych blokad tu nie ma. Agent wykonuje polecenia Bash (czasem po kilkadziesiąt na raz) i generuje skrypty Pythona w /tmp jeśli czegoś nie można ogarnąć bashem. Może to tu jest pies pogrzebany. Jak masz poblokowane rzeczy to wiele zmienia i ciekawe czy Powershell nie sprawia więcej problemów.

Pracuję zawsze w Opus 5, z Ultracode, w Claude Code Desktop. To jaki będzie rezultat może zależeć jeszcze od innych rzeczy, jaka jest konfiguracja subagentów, skills itd. Nie wiem jak w wersji konsolowej, może wersja Desktop przychodzi z jakimiś predefiniowanymi ustawieniami+ blokady o których piszesz, to może robić znaczną różnicę.

mi się zdarza napisać jakieś prototypowe sygnatury funkcji ręcznie, ale że okropnie bazgrzę, to jednak, nawet dopiero tworząc koncepcję, wolę pisać na klawiaturze

Ja aktualnie dopóki mnie nie zwolnią to doszedłem do etapu, gdzie to ja pytam agenta co mam poprawić i każę założyć mu GH issue i zaimplementować. Kilka minut dziennie, dwa prompty i wolne do końca dnia. Ale jestem w projekcie gdzie wszyscy AI slopują ale jakoś to działa. Nowsze AI pewnie to zreaktoruje no ale klienci płacą i używają. A ostatnio rok temu jak pisałem coś ręcznie w tym projekcie to poszło do kosza bo koncepcja się zmieniła to po co się zadręczać?

W ogóle mam wrażenie, że część osób komentujących utknęła na GPT 3.5 czy nawet 5 i nie korzystali z agentów z najnowszymi modelami choćby fable czy astra

Z tymi LLMami to jest tak, że idzie dobrze ale nagle zupełnie z doopy, (np tak jak mi) chat GPT odpowiedział, że na screenie z GitHuba widzi szafkę z umywalką.
W kolejnym prompcie już wszystko wróciło do normy xD

To tak w temacie tego czy modele robią co chcą xD

anonimowy napisał(a):

W ogóle mam wrażenie, że część osób komentujących utknęła na GPT 3.5 czy nawet 5 i nie korzystali z agentów z najnowszymi modelami choćby fable czy astra

Może być też taka sytuacja, że osoby którym to agenci piszą kod, bronią tych modeli, nie rozumiejąc ich ograniczeń. A ich argumentacja jest na pierwszy rzut oka sensowa: przecież to działa, aplikacja jest w porządku, klienci mogą z niej korzystać i chętnie płacą. I ok, to jest jakiś argument. A z drugiej strony masz osoby, które coś tam w życiu widziały więcej i wiedzą, że modele zmyślają, generalizują problemy i są projektowane tak, by zadowolić użytkownika. Co więcej, mają świadomość, że testy e2e i happy path nie oznaczają, że masz dobrze działającą aplikację i sensowną architekturę.

Poza tym tu nie chodzi o klepanie kodu ręcznie. Auto completion z AI pod spodem działa i przyspiesza pisanie kodu. Ale to wciąż jest większa kontrola niż ślepe zostawianie instrukcji w markdownie i oczekiwanie, że LLM poskleja to poprawnie. Łudzą się przy tym, że zrobią suche review i to załatwi sprawę. Jednocześnie znają się tylko na wąskiej działce, co jest jak najbardziej naturalne.

Pyxis napisał(a): Ale to wciąż jest większa kontrola niż ślepe zostawianie instrukcji w markdownie i oczekiwanie, że LLM poskleja to poprawnie. Łudzą się przy tym, że zrobią suche review i to załatwi sprawę.

Po co robić review slopu? Działa to działa i tyle. Jak wyjdzie, że coś nie działa to dorzucasz więcej slopu i tyle. Musicie zrozumieć, że nie każdy projekt wymaga 100% poprawności jak nie wiem np. PostgreSQL czy Linux. A nawet one posiadają błędy.

Ja całe życie pracuję w SaaS i tutaj wystarczy, że coś jako tako działa i klient jest zadowolony.

Tak samo jak jakieś demo, które kiedyś zajmowało 2 tygodnie a teraz zajmie 1h. Po co komuś poświęcać 2 tygodnie jak to potem leci do kosza? Albo jakieś mini projekty eksplorujace na które nie było czasu a teraz robią się same.

W ogóle AI wchodzi w etap, gdzie rozwiązało być może problem mielnijny a wy się dalej upieracie, że to tylko autocomplete...

anonimowy napisał(a):

Po co robić review slopu? Działa to działa i tyle. Jak wyjdzie, że coś nie działa to dorzucasz więcej slopu i tyle. Musicie zrozumieć, że nie każdy projekt wymaga 100% poprawności jak nie wiem np. PostgreSQL czy Linux. A nawet one posiadają błędy.

Ja całe życie pracuję w SaaS i tutaj wystarczy, że coś jako tako działa i klient jest zadowolony.

Czego świetnym przykładem jest https://www.githubstatus.com/

Dzięki temu podejściu można w rok doprowadzić dowolny system SaaS, on-prem lub jakikolwiek do stanu, w jakim często są 20-30 letnie kolubryny

• miliony linii kodu
• setki nieprzewidzianych efektów ubocznych dla dowolnej zmiany
• nikt do końca nie wie, jak działa system
• dodanie kolejnego bugfixa, o ficzerach nie wspomnę, to miesiące żmudnej dłubaniny

Jak komuś to nie przeszkadza, proszę bardzo. W szczególności jeśli ktoś robi jedynie zlecenia i dostarcza wywrotki slopu na zamówienie, a jego umiejętności inżynierskie sprowadzają się do przestawiania wajchy na "więcej, bardziej, drożej", to nie musi się nigdy przejmować konsekwencjami, bo i tak go nie dopadną. Komuś innemu ta wywrotka slopu spadnie na głowę.

Ja na ten przykład nie mam ochoty się tłumaczyć, dlaczego robiąc wdrożenie zmian w infrastrukturze otworzyłem dostęp po publicznej sieci do baz z danymi wrażliwymi. No ale przecież AI agent mógł uznać, że to dużo lepszy sposób, albo zmienił to bez konsultacji z użytkownikiem, realizując zupełnie inne zadanie - ot, wyszło mu, że skoro tyle danych treningowych miało niezabezpieczony dostęp, to taki dostęp jest spoko.

I jako przykład podajesz projekt, który nie jest AI slopem?
Github nie ma problemów przez to, że jest/był pisany w AI tylko dlatego, że w ostatnich miesiącach tak wzrosło obciążenie, że nie byli na to gotowi i wychodzą co róż nowe bottlenecki/problemy

Ja nie mówię, że AI slop projekt jest lepszy od kraftowego tylko, że jest miejsce na rynku i na to i na to

anonimowy napisał(a):

Po co robić review slopu? Działa to działa i tyle. Jak wyjdzie, że coś nie działa to dorzucasz więcej slopu i tyle.

Każdy software ma błędy. Odpowiednie testy pozwalają Ci tylko oddelegować ich wykrycie w czasie. Dokładnie to samo jest z tworzeniem kodu przez AI. On się tworzy i dziury możesz łatać kolejnym slopem. Ale przyjdzie taki moment, że aplikacja Ci przestanie działać. Będziesz wtedy miał niedostępną usługę. A teraz sobie pomyśl, że robisz taki software dla przemysłu czy lotnictwa, gdzie każde 5 min. opóźnienia jest na wagę złota.

W ogóle AI wchodzi w etap, gdzie rozwiązało być może problem mielnijny a wy się dalej upieracie, że to tylko autocomplete...

Po pierwsze, być może. I być może to wciąż autocomplete. Sam Instytut Clay podważa ich rozwiązanie i twierdzi, że będzie robił bardzo szczegółową weryfikację: https://www.implicator.ai/clay-institute-navier-stokes-openai-proof-claim/:

The forced-versus-unforced divide will sit at the center of that review. A smooth external force is allowed by the written problem, but it drives the method, and there is no public evidence that the construction works without it.

The forced case matters because Charles Fefferman’s official formulation permits it in statements C and D. Most working mathematicians picture the harder question without that push. OpenAI’s construction uses a smooth force to produce a vortex that spirals inward and stretches “like spaghetti,” with a shrinking center moving ever faster while total energy stays finite.

Po drugie, są niejasności wokół tego, czy firma nie ukradła pomysłów matematyków, którzy posiłkowali się Codexem. Po trzecie, firma przepaliła 130 miliardów tokenów (~15 mln $) na rozwiązanie problemu wartego 1 mln $. Oczywiście dla matematyki jako takiej pieniądze nie mają znaczenia, ale w kontekście "wydajności" o której wielu tutaj pisze, jakoby LLM-y przyspieszały pracę, to jej opłacalność stoi pod znakiem zapytania. Już nie mówię o zużyciu wody.

Jeśli Instytut wykaże, że modele wykorzystały pomysły matematyków, to w zasadzie nadal mamy problem, że modele nie potrafią ekstrapolować, a tylko interpolują, co na razie się potwierdza w tym, że nie potrafią rozwiązywać problemów otwartych, do których można zaliczyć np. bardziej złożone rozwiązania programistyczne.

Pyxis napisał(a):

A teraz sobie pomyśl, że robisz taki software dla przemysłu czy lotnictwa, gdzie każde 5 min. opóźnienia jest na wagę złota.

Czy Ty jesteś poważny!? Chcesz ryzykować życiem ludzkim żeby sobie ułatwić pracę? Oczywiście, że AI slop w takich sytuacjach nie powinien być praktykowany.

Po drugie, są niejasności wokół tego, czy firma nie ukradła pomysłów matematyków, którzy posiłkowali się Codexem. Po trzecie, firma przepaliła 130 miliardów tokenów (~15 mln $) na rozwiązanie problemu wartego 1 mln $. Oczywiście dla matematyki jako takiej pieniądze nie mają znaczenia, ale w kontekście "wydajności" o której wielu tutaj pisze, jakoby LLM-y przyspieszały pracę, to jej opłacalność stoi pod znakiem zapytania. Już nie mówię o zużyciu wody.

Dlatego napisałem "być może". Nie zmienia to faktu, że to wybitne osiągnięcie a Twoja wymyślona wartość tego 1 mln to jakiś nie śmieszny żart miałbyć? To, że jest nagroda za niego nie znaczy, że jest tyle wart. Jak wchodziło o3 to też za kilkaset tysięcy $ rozwiazywało problemy, które teraz można rozwiązać za 5$ to chyba jasne, że najpierw coś jest drogie? Przespałeś ostatnie 2 lata? I o ogóle teraz mieszasz tematy jakiejś wody gdzie możesz mieć DC z zamkniętym obiegiem Tak się nie da dyskutować jak rzucasz jakieś losowe teorie

Jeśli Instytut wykaże, że modele wykorzystały pomysły matematyków, to w zasadzie nadal mamy problem, że modele nie potrafią ekstrapolować, a tylko interpolują, co na razie się potwierdza w tym, że nie potrafią rozwiązywać problemów otwartych, do których można zaliczyć np. bardziej złożone rozwiązania programistyczne.

No niech najpierw wykaże a te złożone programistyczne problemy to 1% pracy

To, że jest nagroda za niego nie znaczy, że jest tyle wart.

Otóż to, dlatego napisałem, że dla matematyki nie ma to znaczenia. Z punktu widzenia biznesu może już mieć, w momencie kiedy firma musi wyłożyć gotówkę na kupno tokenów.

Jak wchodziło o3 to też za kilkaset tysięcy $ rozwiazywało problemy, które teraz można rozwiązać za 5$ to chyba jasne, że najpierw coś jest drogie?

Może zamiast jakiś dziwnych ekstrapolacji typu za rok AI będzie 10x lepsze warto wziąć pod uwagę to, co jest tu i teraz. Czyli drożejące modele i ograniczenia tokenów na miesiąc?

No niech najpierw wykaże a te złożone programistyczne problemy to 1% pracy

No ale rozwiązywanie takich właśnie problemów sprawia, że możesz mieć lepsze i szybsze modele, które tak chętnie prognozują zwolennicy vibe codingu, nie rozumiejąc jak się sieci trenuje.

Pyxis napisał(a):

Może zamiast jakiś dziwnych ekstrapolacji typu za rok AI będzie 10x lepsze warto wziąć pod uwagę to, co jest tu i teraz. Czyli drożejące modele i ograniczenia tokenów na miesiąc?

Skoro kłamiesz i wymyślasz dane to EOT z mojej strony. Modele są coraz tańsze per task a Ty wymyślasz, że coś coraz droższe

Ty bierzesz pod uwagę koszt API, ja biorę pod uwagę koszt trenowania modeli bo przecież to wpływa, że będą jeszcze "lepsze" niż te obecne. A te koszty rosną z każdą generacją.

Ponadto obecne modele mają rozumowanie pod spodem, co też wymaga wygenerowania więcej tokenów. I zgoda, proste pytanie, które generuje niewiele tokenów odpowiedzi z automatu, jest obecnie tańsze niż parę lat temu. Jednocześnie bardziej złożone pytania wymagają wygenerowania kilku ścieżek i oceny, która jest dobra. Z reguły tych tokenów nie widzisz, ale za nie płacisz. Szczególnie jak masz przeanalizować jakieś rozwiązanie albo zrobić debugging kodu. Innymi słowy, na starych modelach byś tego nie zrobił, bo rozumowanie nie było tak rozwinięte. Masz iluzję spadku kosztów.