VibeCoding, narzędzia, dobre praktyki

Vibecoding, czyli tworzenie oprogramowania z użyciem AI. Jakie są Wasze doświadczenia?
Moje, muszę przyznać, bardzo obiecujące.
Używam Codexa, jakoś generalnie najlepiej pracuje mi się z narzędziami od Open AI.
Z publicznych rzeczy, którymi mogę i chcę się pochwalić to na ten moment przede wszystkim prosty dodatek do NVDA, który mierzy zajętość naszego łącza i zdecydowanie grubszy temat, jakim jest SARA, czyli oprogramowanie dla radiowców.
W przyszłości prawdopodobnie będzie też narzędzie do tworzenia dostępnych i wyglądających OK pod względem wizualnym plików PDF oraz narzędzie do sprawdzania dostępności dokumentów pakietu Office.
https://github.com/michaldziwisz/networkSpeed
https://github.com/michaldziwisz/sara
Z moich obserwacji, modele do tworzenia kodu idą w bardzo dobrym kierunku, ale to też nie jest tak, że jednym promptem zbudujemy sobie appkę. Osobiście dla mnie zawsze problemem było kodowanie jako takie. Nauka poleceń języka, potrzeba kontroli, debugowania, nigdy nie miałem kłopotów natomiast z definiowaniem problemów oraz tego, w jaki sposób mają być one rozwiązane. Dla takich osób narzędzia pokroju Codexa czy Claudea są świetnym rozwiązaniem, ale programowanie w dalszym ciągu jest dużym wyzwaniem dla osób mało, lub wcale technicznych i pewien poziom wiedzy będzie jeszcze długo wymagany.
A Wy jak tam, próbowaliście, odnosiliście sukcesy, czy raczej nie?
A jeśli sukces był, to z miłą chęcią poczytam o dobrych praktykach, jakie stosujecie, żeby kod był czytelny i w miarę możliwości uporządkowany.

Z mojej perspektywy pół na pół.
Jak długo chodzi o zadania proste, wyniki są świetne, zarówno Gemini 3 Pro, jak i GPT 5. I chcę tu sprecyzować, że proste nie oznacza że coś wymaga mało pracy, tylko jest stosunkowo proste programistycznie.
Ale gdy chodzi o coś złożonego, kod AI regularnie miewa trzy wady. Albo jest na tyle nieoptymalny lub źle napisany, że w dużym projekcie wadzi, albo po prostu nie działa albo, a to jest najbardziej niebezpieczne, ma w sobie podatności.
Wspomagam się mocno AI przy pracy nad nowym backendem Eltena i tam to widać jak na dłoni. Gdy chodzi o coś, co wymaga często naprawdę godziny albo więcej pracy, GPT5 Thinking potrafi zrobić to w 5 minut. Ale przy skomplikowanych kwerendach regularnie wypluwa albo taki kod, który nie działa, albo który ma podatności jak stąd na Księżyc.

@Pajper, próbowałeś GPT 5.2? Jeśli nie, spróbuj. Ja zauważam bardzo dużą różnicę w porównaniu do wcześniejszych modeli. I fakt, kwestie bezpieczeństwa to coś, czego również niewolno pomijać szczególnie, jeśli tworzymy narzędzia sieciowe. Zastanawia mnie to jak bardzo język, w którym każemy pisać modelowi ma wpływ na to, jaka jest jakość kodu.

Właśnie przetestowałem na pewnym bardzo konkretnym zadaniu i 5.2 też poległ.
Zadanie jest pozornie proste, ale na tyle nietypowe, że GPT sobie z nim kompletnie nie radzi. Tak naprawdę kompletnie.

Tłumacząc z języka technicznego, chodzi o stworzenie skryptu, który przerobi model 3D w ten sposób, by wypełnić cały dół i odda tylko górną warstwę. Czyli, dla przykładu, gdybyśmy mieli kostkę do gry, model zostałby zamieniony, wypełniając wszystkie kropki i zostawiając tylko te na górze.
Ta zamiana jest czasem bardzo przydatna w modelowaniu 3D, gdy chcemy szybko przekształcić dowolną pustą w środku makietę, mechanizm czy cokolwiek, by oddać tylko zewnętrzny kształt. I GPT kompletnie nie umie tego zrobić.
I to nie jest jakieś zadanie bardzo trudne. Python ma do tego bardzo poprawne biblioteki, on nawet je wskazuje i importuje, ale ponieważ zadanie jest zaskakująco matematyczne i nie tak oczywiste, wypluwa kompletne bzdury. Skrypty które działają, ale robią zupełnie nie to, co powinny.

Lubię ten przykład, bo jest dokładnie tym, o czym pisałem. To jest zadanie tak bardzo nietypowe, tak nieschematyczne, że on się wykłada, mimo że wymaga 30, może 45 minut pisania.
A inne, dużo bardziej czasochłonne, ale bardziej schematyczne zadania robi bez trudu.

To prawda. Rzeczy, które są mniej typowe stanowią dla tych narzędzi spore wyzwanie. Z przykładów, które ja przechodziłem w tworzeniu SARy największym kłopotem był... Dodatek do NVDA który miał spowodować, że aplikacja będzie gadała mniej. Tak na prawdę to jeszcze nie mam tego do końca dopracowanego jak bym chciał bo wiem, że zajmie mi to sporo czasu, więc wolałem skupić się na rozwiązaniach, które spowodują, że tego programu wogóle da się używać, na polerkę jeszcze przyjdzie czas. :)

Ale, żeby nie było, mam przykład w drugą dosłownie z niedzieli, kontrolowany z osobą widzącą.
Na podstawie makiety, pomysłu na stronę Internetową narysowanej jako obrazek, nie stworzonej w dedykowanym narzędziu, po prostu narysowanej, poprosiliśmy GPT o stworzenie kodu CSS, który da maksymalnie zbliżony efekt do układu na załączonym pliku PNG.
CSS nie wymagał żadnej poprawki, zrobił dokładnie to, co było narysowane, tylko na podstawie obrazka. Więc, tak, gdy zadanie jest typowe, jak właśnie CSS w tym przypadku, to AI potrafi robić rzeczy niesamowite i oszczędzać godziny pracy.

Nie mówię o prostych 10 linijkach. Mówię o 126 liniach kodu z cieniami, kontrastami, warunkowaniem od rozdzielczości, układem zależnym od scrollowania itd.

Dla mnie w tym wszystkim chyba najbardziej przykre jest to, że nawet doświadczeni programiści mocno się tym zachwycają, jak to nie potrafi pomagać w różnych problemach, rozwiązywać te problemy, zdejmować z barków obowiazek żmudngoklepania ciagle tego samego, itd. więc im dają coraz to trudniejsze i trudniejsze zadania... Mało się móœi, albo zdecydowanie mniej w mainstreamie o tym, że jednak nie radzą sobie modele ze wszystkim.

@zywek: Do doświadczonego programisty mi daleko, ale ja po prostu widzę efekty swoich działań. W kilka miesięcy po godzinach byłem w stanie stworzyć oprogramowanie, które po prostu wykonuje zadanie, jakie mu powierzam. Czy jest zrobione optymalnie? Nie wiem. Czy jest bezpieczne? Nie wiem. Z drugiej strony, tego nie wiem nigdy w przypadku jakiegokolwiek programu, który instaluję na swoim komputerze, bo jeśli bym chciał to wiedzieć, musiałbym przeanalizować kod. Teoretycznie wydaje się to spoko opcją, ale nie sądzę, żeby wiele osób tak robiło. Wydaje mi się też, że taki vibecoding jest kolejnym poziomem programowania. Wiesz, ja pamiętam te czasy, kiedy np. śmiano się z Pythona, PHP czy VB. Tylko czyste C, a najlepiej asembler. Ludzie wyśmiewali wszelkie frameworki, bo przecież dobry programista powinien wszystko sam napisać, bo tylko wtedy wie, co stworzył. Korzystanie z jakichkolwiek bibliotek to zło, bo pracujesz z kodem, którego nie znasz, którego nie stworzyłeś. No i co? Dziś to się zmieniło diametralnie. Przypuszczam, że twórcy modeli też nie powiedzieli jeszcze ostatniego słowa i będzie to wszystko ewoluować. Ja rozumiem frustrację ludzi, którzy część życia poświęcili na naukę programowania, a teraz przychodzi sobie ktoś z LLMem i robi to co oni w porównywalnym czasie, albo nawet czasem krótszym. Z drugiej strony wydaje mi się, że takie podejście, o którym wspomniał @pajper jest najbardziej optymalne. Wycisnąć z modeli to, w czym są dobre samemu kodując te rzeczy, których LLM nie jest w stanie zrobić dobrze.
I jeszcze jedna, dla niewidomych myślę, że bardzo istotna rzecz. Dostaliśmy narzędzie, które pozwala nam tworzyć programy nawet na własny użytek. Nie odkrywamy koła, a np. budujemy bardziej dostępny dla nas interfejs, bo z tym bardzo często jest problem, oprogramowanie istnieje, ale jego dostępność leży.
Dla mnie to właśnie było motywacją do stworzenia Sary. Autor programu Mairlist, na którym dość mocno się wzoruję powiedział mi wprost, nie zrobi dostępności, bo mu się to nie opłaca. Inne dostępne dla nas programy radiowe z kolei nie mają niektórych funkcji, na jakich mi zależy. Mając dostęp do Codexa mogę w cenie kilkudziesięciu złotych miesięcznie zrobić coś, co będzie spełniało moje oczekiwania i jeszcze podzielić się tym z innymi.

Myślę, że największym zagrożeniem jest tutaj coś innego. LM'y mają pewne ograniczenia. I to nie są ograniczenia w rodzaju rozwiążemy je wydając GPT 7.5, ale problemy w rodzaju ograniczeń w samej matematycznej podstawie sieci neuronowych. Może kiedyś je rozwiążemy, tworząc nowe algorytmy, ale na tym etapie od wydania GPT 2.0 matematyka stojąca za Gemini, GPT, DeepSeek jest wciąż ta sama.
Na pewno sieci neuronowe nie powiedziały jeszcze ostatniego słowa i nas zaskoczą, na pewno bardzo dużo zmienią i przetasują, ale na tym etapie będą wciąż miały pewne luki, których nie rozwiąże trening. Luki w jakości kodu, w bezpieczeństwie, w zadaniach nie do przeskoczenia.
I teraz tylko od rozsądku ludzi, sensownych zasad audytu kodu, doświadczenia i ogólnego podejścia do tematu zależy czy AI okaże się ogromnym ułatwieniem, czy wstępem do katastrofy i kryzysu programistycznego.
Na szczęście na ten moment wydaje mi się, że mimo pewnego irytującego hype w niektórych kręgach, podejście do tematu jest bardzo rozsądne i firmy oraz projekty open-source sensownie balansują użycie AI i człowieka.

@midzi ja nie twierdzę, że używanie AI to zło. Ja twierdzę, że zachwycnie się tym i bezmyślne tego używanie jest średnie. Wiem mniej więcej, co to ułatwia, mogę się domyślać, czego nie jest w stanie zrobić dobrze i nikomu nie bronię z tgo korzystać. Trzeba sobie ułatwiać życie tam, gdzie się da. Jedyne co to bezmyślne klepanie promptów i zachwycanie się średnim produktem, który może nie być doskonały mnie drażni. I wiadomo, programista człowiek też nie napisze niczego idealnie, albo prawie niczego. Ciekawe tylko ile średniego softu wyprodukują różni ludzie teraz, gdy to wszystko stało się zdecydowanie łatwiejsze... I spoko, Ty potrafisz opisać problem, to w jaki sposób można go rozwiązać, a ile jest osób, którzy tego nie potrafią, więc napiszą "Napisz m program, który coś, coś i coś..." i z czegoś takiego wytworzą gniota, który może i robi to, co powinien, ale robi to tylko jakoś.

@zywek: Osobiście nigdy nawet nie próbowałem pisać promptów w rodzaju napisz mi appkę do tego czy tamtego, jeśli czegoś nie wiedziałem ewentualnie prosiłem AI o propozycje biblioteki, która to zrobi, ale raczej stoję na stanowisku że to ja mówię modelowi co on ma zrobić, a on to robi wg zadanych wytycznych, bo jeśli pozwolić mu na zbytnią inwencję twórczą, to przeważnie kończy się to źle. Zawsze jeśli ma mi coś zrobić sam, to dodaję w instrukcji że przed zrobieniem czegokolwiek ma rozpisać dokładny plan działania, który czytam i ewentualnie modyfikuję. Dzięki temu wiem, czego mogę się spodziewać w efekcie danej zmiany a jeśli coś pójdzie nie tak, gdzie szukać błędu. Tylko z moich obserwacji, jeśli ktoś się kompletnie na tym nie zna, to nawet nie siądzie do Codexa czy Claude Code, bo go to przerośnie. Praca z LLMami to nie jest jeden prompt, to są godziny ślęczenia nawet nad drobną pierdołą, sprawdzanie, testowanie, podchodzenie do danego problemu z różnych stron. Podejrzewam, że np. potrafiąc pisać w danym języku byłbym w stanie zdecydowanie częściej nakierować model na prawidłowe rozwiązanie, no ale cóż, chyba po prostu do kodowania głowa nie ta, więc pozostaje działać w oparciu o to, co mam. Prawda też jest taka, że często żeby usprawnić sobie pracę nie potrzebujemy systemu klasy enterprise. Potrzebujemy programu / narzędzia, które zrobi dobrze jakąś jedną, konkretną rzecz. Jeśli znamy się na tym i potrafimy precyzyjnie opisywać modelowi efekty, to po działaniuprogramu jesteśmy w stanie je zweryfikować. Katastrofą jednak będzie gdy ktoś, kto nie ma pojęcia o programowaniu zabierze się za aplikację, której stworzenie zlecił mu ktoś, a ta aplikacja robi coś, na czym ta osoba kompletnie się nie zna.
@pajper niestety, ale problemy zaczynają się już pojawiać jeśli chodzi o zatrudnianie programistów, szczególnie juniorów w różnych softwarehouseach. Jest tych stanowisk znacznie mniej, bo większość juniorów zastąpić można AI. Sęk tylko w tym, że to jest strasznie krótkowzroczne rozumowanie managementu. Bo skoro nie dopuszczamy do pracy juniorów, to skąd za kilka / kilkanaście lat brać nowy narybek programistów?
AI moim zdaniem pozwala rozwinąć kreatywność, natomiast z drugiej strony potrafi też rozleniwić. Wszystko zależy, jak do tego podejdziemy. To jest po prostu kolejne narzędzie, którego nie należy się bać ani przesadnie wielbić, tylko po prostu z głową używać.

Widzę problem, o którym piszesz, ale może po prostu trzeba zmienić definicję zakresu obowiązków Juniora?
W wielu, bardzo wielu firmach juniorzy mieli za zadanie być właściwie klikaczami, odklepywać regularny, powtarzalny kod albo wyklikiwać UX, względnie pisać nudne, powtarzalne kwerendy do SQL.
Nie, przepraszam, przesadzam, na poziomie juniora Django, Railsa czy Symfony nawet nie dochodzili do pisania kwerend, tylko relacji i transakcji.
Może po prostu za kilka lat firmy zrozumieją, że tę robotę zrobi AI, a od juniorów zacznie się wymagać pisania czegoś bardziej sensownego.

Odkopuje wątek, bo minęło 9 miesięcy, rynek się zmienił, modele rozwinęły się bardzo i mam kilka swoich prywatnych spostrzeżeń, wyciągniętych przede wszystkim z tego co się dzieje wokół Eltena, ale też z kilku innych repo.

Przyznam, że wszystko potoczyło się w troszkę innym kierunku, niż się spodziewałem. Obecne modele, jak GPT 6 czy Fable 5.1, potrafią bardzo dużo zrobić, ale troszkę przypominają mi takiego typowego akademika, czyli mogą robić do woli, ale do końca nigdy nie zastanowią się dlaczego.

Co mam na myśli? Widać to bardzo po programach pisanych dla Eltena, które są... technicznie poprawne. Działają. Spełniają swoją funkcję. Ale architektonicznie, yyyyy. No lepiej nie komentować.

Czy to źle? Nie, bo działają, a gdyby nie AI, prawdopodobnie nigdy by nie powstały. Ale jednak widać na milę, że to vibe-coding, i to w tym złym sensie.


Główne ograniczenie narzędzi AI, przynajmniej z mojej perspektywy, staje się bardzo oczywiste, one potrafią zrobić kod tak dobry, jak potrafi zaplanować go prompter. A żeby zaplanować naprawdę dobry kod, trzeba mieć doświadczenie. I wpadamy w pętlę.

Widzę to nawet po sobie. Oczywiście, można AI dać bardzo konkretne instrukcje: w funkcji X użyj intrinsic, funkcja Y powinna przyjmować wskaźnik a nie strukturę, a funkcja C powinna nie używać sztucznej lambdy. I AI to zrobi.
Tylko najpierw programista musi umieć przeczytać kod, zrozumieć jego słabe punkty i wiedzieć, co można zrobić lepiej.

Kilka dni temu fajnie widziałem to na Asemblerze, który akurat jest w pisaniu, nie oszukujmy się, tragiczny. Chciałem, żeby GPT6 na poziomie Max wygenerował mi Asembler do optymalnego resamplingu, używając AVX/512. Asembler ten w benchmarkach okazał się gorszy od wzorcowego kodu w C. I to był świetny punkt pod testy. Kazałem modelowi to zoptymalizować.
Próļbował biedny, palił tokeny, siedział nad tym 3 godziny i nie dał rady.
Dzisiaj zerknąłem na ten kod i zrozumiałem problem. Problemem była pętla, która się zagnieżdżała i przepisywała wielokrotnie rejestry.
Opisałem mu co jest nie tak, dałem konkretne wytyczne jak ma naprawić i to zrobił, a owszem, bardzo ładnie. Ale ktoś, kto nie znałby Asemblera, kto nie potrafiłby przeczytać tego kodu, nigdy by nie wiedział jak poinstruować AI.

Asembler może jest nieco ekstremalnym przykładem, ale to samo widzę w API Eltena. Ile razy patrzę na kod AI i mówię mu jak zmieniać, optymalizować, stawiać granice architektoniczne. Rzeczywiście dochodzimy do punktu, w którym AI robi bardzo dużo roboty za nas: pisze powtarzalny kod, wykonuje zmiany na poziomie całego projektu itd. TO ogromny atut szybkości pracy, co właściwie widać ostatnio w każdym ważnym projekcie open-source.
A z drugiej strony tym bardziej widać kluczowe umiejętności czytania kodu, rozumienia architektury, wzorców projektowych, logiki aplikacji, działania systemów, planowania integracji itp.

Zastanawiam się tylko co będzie po nas. Ja i moje pokolenie, nawet troszkę młodsi programiści, zdobywali doświadczenie, pisząc setki tysięcy, miliony linii kodu, popełniając swoje błędy i ucząc się na swoim przykładzie. Troszkę martwię się, jak doświadczenia mogą nabrać świeży programiści, skoro mało komu będzie się chciało uczyć pisania prostych programów, skoro AI zrobi to za nich.
Może się mylę, nie wykluczam, czas pokaże.

Na razie ja widzę w AI bardzo jasny podział:
* Z jednej strony są małe lub średnie w pełni vibecodowane aplikacje spełniające konkretne funkcje, o kodzie powiedzmy otwarcie pozostawiającym wiele do życzenia, ale nie ma to znaczenia;
* Z drugiej strony są duże projekty asystowane przez AI, prowadzone przez doświadczonych maintainerów i z bardzo silną zasadą code review, które rzeczywiście strzelają do przodu, żeby daleko nie szukać: Linux, Opus, Ruby, nawet Elten.
* I, co ciekawe, ja nie widzę nic po środku, między tymi dwiema grupami.

Pytanie tylko co dalej. Ja tego nie wiem.

@Pajper, zgadza się. Narzędzie jest tak dobre, jak jego operator. A wraz ze skomplikowaniem kodu rośnie złożoność problemów, z jakim to narzędzie musi sobie radzić. Jeśli wiesz jak i o co pytać, odniesiesz sukces. Natomiast świetne jest to, że możesz być specjalistą w jakiejś dziedzinie, niekoniecznie programowaniu i zrobić sobie na własne potrzeby czy nawet publicznie dostępne narzędzie, które rozwiązuje jakiś problem. Dla mnie to jest właśnie przełomem, bo tworzenie złożonych systemów, które pracują w różnych instytucjach, pomagają biznesom to jeszcze długo będzie domena człowieka specjalisty. Z pewnością wspomagającego się AI, ale faktycznie kogoś kto rozumie architekturę, kto wie jak radzić sobie z równoległą pracą wielu użytkowników na danych, kto rozumie sieć. Choćby dlatego, że nawet jeśli w przyszłości promptowanie będzie banalne i od strzała będzie powstawał dobry kod, to ktoś będzie i tak musiał się zająć napisaniem zlecenia na ten kod a następnie jego odbiorem.

Tak, sam to podkreślałem wielokrotnie, my sami jeszcze nie do końca zrozumieliśmy jak cenne narzędzie też po prostu dostępnościowe dostaliśmy. Na razie głównie, nie ukrywajmy, to zabawa i pisanie modów dostępnościowych do Wiedźmina, Civilization i innych gier, ale przecież ta sama zasada oznacza, że osoba niewidoma może napisać, o ile jest to możliwe, skrypt dostępnościowe, narzędzie do obejścia problemu, własny programik do przetworzenia czegoś niedostępnego etc.
Oczywiście nie we wszystkim i nie oznacza to uczynienie IT 100% dostępnym, ale mamy narzędzia dla zwykłych użytkowników, których nigdy nie mieli.

Ja w swoim wpisie nie tyle krytykowałem użycie AI, bo absolutnie nie. Ja raczej martwię się trochę innym pytaniem: skąd weźmiemy doświadczonych ludzi za 20, 30 lat? Bo albo AI w 20 lat stanie się zupełnie autonomiczne, co wciąż wydaje mi się wątpliwe, a gdyby nawet to ludzie powinni się bardzo martwić, albo zabraknie nam ludzi z odpowiednią wiedzą i doświadczeniem. Już teraz firmy nie chcą rekrutować Juniorów.

@Pajper, czyli martwimy się o to samo. :) Wziąwszy pod uwagę jak duży postęp osiągnęło AI przez tych kilka lat, ja mam jednak jakąś tam nadzieję, że przez 20, 30 lat to będzie miało szanse zostać samograjem. Oczywiście ja tam sobie mogę mieć nadzieję, Ty możesz się bardziej martwić, ale prawda jest taka, że to nie nam powinno spędzać to sen z powiek a raczej ludziom, którzy decydują o znacznie istotniejszych dla świata klockach infrastruktury niż TyfloPodcast czy Elten. :) Na ten moment, jeśli ktoś decyduje, że zamiast inwestować w juniorów cały budżet inwestuje w AI, jest to moim zdaniem niczym nieuzasadniony optymizm.

Na chwilę obecną wydaje mi się, że będzie jak z programowaniem niskopoziomowym. Już dawno są te tam różne Pythony, Javy i inne takie, znaczna większość kodu powstaje w tych, pewnie mało optymalnych językach, ale nadal są takie dziedziny lub programy, które starają się być przede wszystkim szybkie i maksymalnie sprawne. Myślę, że mamy kolejny poziom, na który będzie w stanie wejść dużo więcej ludziów niż teraz, ale czy zmniejszy się ilość specjalistów od super optymalizacji? chyba nie, ale procentowo będzie to znacznie mniej.
Przykładem może być chociażby Midzi albo i ja. Czy zrobilibyśmy cokolwiek bez ai? wątpię. było na to masę czasu, ale jakoś nic się nie pojawiło. Tym czasem od kiedy weszły Codexy i im podobne, na githubie Midziego jest już co najmniej kilka rzeczy stworzonych w zasadzie od zera. Osobiście raczej nie wezmę się za programowanie sensu stricte, bo jakoś nie mam do tego serca. Z drugiej strony wydaje mi się, że nawet jeśli powstanie, a raczej powstanie jakaś ai dla producentó muzyki, która dodaje efekty, tworzy partie instrumentów itd to nawet gdybym dopiero wchodził w ten świat, z moją ciekawością dźwiękową nadal zgłębiałbym przy najmniej częściowo te wszystkie różności. Być może nie dokładnie tak, jak teraz, ale jest to dla mnie zwyczajnie niezmiernie interesujące.

@Tomecki, dla muzyków jest np. Strudel. Podstawową różnicą między językami wyższego poziomu a AI, które programuje w czym kolwiek jest brak deterministyczności tego drugiego. Co prompt i co model to będzie to wyglądało inaczej. Są oczywiście mechanizmy, które mają nad tym zapanować, ale tego króliczka jeszcze nie dogoniliśmy i wydaje mi się, że tak szybko nie dogonimy.

Fajnie się was czyta z dzisiejszej perspektywy, , szczególnie te pierwsze posty, a to zaledwie nie cały rok minął :-)
Pamiętam Mikołaja, jak potwierdził mi, że GPT naprawdę jest, naprawdę istnieje, iu trzeba sobie kupić API Open AI, żeby w ogóle z nim pogadać.
Nie pamiętam co to było, chyba nawet starsze niż gpt 2.5,pamiętam ustawiałem temperaturę na maksa i podziwiałem głupoty i halucynacje.

W sumie czy tak wiele się zmieniło w naszej dyskusji? Chyba nie.
Rozwinęły się bardzo narzędzia, ale na poziomie naszej rozmowy chyba nie, co najwyżej delikatnie rozciągnęły się definicje.