Szukaj...
Zaloguj się
GRYOnline.pl:
tvgry.pl:
GRYOnline.pl:
tvgry.pl:
Według tego geniusza, powinny mijać już 2 lata od pierwszego załogowego lotu na Marsa... A no i w tym roku wypuści grę w całości zrobioną przez AI, która będzie lepsza od gier AAA, a do końca roku wygeneruje lepszą wersję Odysei, też za pomocą AI, odklejony kretyn i kłamca.
Ale to jest farmazon jeden - assembler dalej ma się dobrze, tak samo jak kod źródłowy będzie się miał dobrze :) to że używamy języków wysokiego poziomu to wcale nie oznacza że nikt nie używa assemblera :D
Zaraz ci jakis madry napisze "Ale przeciez rakiety buduje!".
To odpowiadam: Nie on buduje. On to np. przyczynil sie do zaorania NASA.
Zreszta calkiem mozliwe ze SpaceX pojdzie na stracenie, zeby zasilic cos nowego. Bo jak muskowy system fundowania kolejnego interesu za pomoca innych, spekulacji i klamania inwestorom zatrzyma sie choc raz to je...nie az milo.
Moze nawet i by to na zle nie wyszlo bo IMHO udoskonalanie na sile rakiet w obecnej formie to troche slepa uliczka. Wolalbym takie same pieniadze przeznaczyc na badania innych form napedow (bezpieczniejszych, ekologiczniejszych, itd...) .
Co do tematu to jest wszystko wlasnie takie pierdzielenie pod inwestorow, ktorzy to czytaja. Wydaje im sie ze Musk wie o czym mowi. I tak sie ta karuzela wiadomo czego kreci.
Gdyby programiści mieli tworzyć całe aplikacje na bazie treści zbudowanych przy użyciu zwykłego języka, to prompty byłyby długości kodu źródłowego.
Strzele ze bylyby dluzsze. I pewnie bardziej skomplikowane. Zeby miec jaka taka kontrole nad generowanym obrazem to mozna walic prompty po kilkaset znakow. Co dopiero kod.
Większej bredni dawno od niego nie słyszałem, a to już coś, bo chłop bredzi regularnie :D
Już pomijając fakt, że nikt o zdrowych zmysłach nie odpali oprogramowania bez jakichkolwiek gwarancji zgodności z prawem ogólnie, GDPR, prawem finansowym czy księgowością to dodatkowo nikt nie podpisze się pod wdrożeniem oprogramowania, które może narobić szkód w firmie zawierając jakieś backdoory czy inny syf. Gość już odleciał ze swoimi kretynizmami na, nomen omen, Marsa i pokazuje, że nie ma bladego pojęcia o czym mówi.
Świetny pomysł - nie ma to jak generować kilkaset tysięcy linii kodu od zera (a w tym tysiące potencjalnych bugów i dziur), bo user chciał żeby mu kolor checkboxa zmienić z szarego na czarny. W dodatku aplikacja nigdy po przebudowie nie będzie wyglądała tak samo (będzie podobna, ale LLMy jak artykuł wspomina nie są deterministyczne). UI odrobinkę inne przy każdym przebudowaniu projektu, brzmi jak marzenie i final boss UX designu.
Już widzę te komentarze przy commitach ("masz tu 8243472389427 zmienionych linii, wygląda ok?") do review.
PS. Drop bazy produkcyjnej czy wyczyszczenie dysku w gratisie, jak się LLMowi akurat zdarzy przyhalucynować w tym kierunku (a wiemy że robią to sporadycznie, ale robią).
Robią, bo mi zaproponował taki kod :D Tak z ciekawości napisałem prompta, zeby mi napisał rozwiązanie robienie czystego kopiowania danych pomiędzy tabelami z bazy do bazy. Zaproponował skrypt, który kopiuje dane z tabeli źródłowej do tymczasowej, USUWA dane ze źródłowej, kopiuje z tabeli tymczasowej do docelowej i czyści tabelę tymczasową. Pierwszy red flag to usuwanie danych ze źródła PRZED zakończeniem kopiowania do docelowej tabeli i gdybym to odpalił na produkcji, to już bym się witał z backupem. Nazwy tabeli tymczasowej się nie zgadzały w skrypcie... dane ze źródła kopiował do tabeli #temp_source, a tabelę docelową próbował zapełnić danymi z tabeli #temp_target. Skrypt by się nie wywalił, bo zainicjował obie tabele na początku, tylko że druga była cały czas pusta. Oczywiście na koniec wszystko elegancko czyścił truncatem - obie tymczasowe i źródłową.
GRYOnline.pl:
tvgry.pl: