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.