[straggler2]

#programista15k #programowanie #sztucznainteligencja
Nie wiem jak wy promptokodujecie, że nie osiągacie ogromnego wzrostu wydajności lub otrzymany kod jest do bani. Ja w pracy w ostatnie 4 dni robocze zrobiłem eksperyment i przez ten czas polegałem całkowicie na vibekodowaniu. Mój setup to github copilot + claude opus 4.5/sonnet 4.5 - zmieniałem je w trakcie, by dostrzec różnice między nimi( jest niewielka).

W efekcie zaoszczędziłem 90% czasu na wykonanie zadań. W prawdzie robię w najbardziej oklepanej branży, za to w legacy, które jest tak stare, że nie używa żadnego frameworka, a także przypadek jest szczególny, bo testowanie zajęło z powodu natury zadań niewiele czasu.

Pomimo swej skuteczności popełnia rażące błędy:
- potrafił usunąć cześć zapytania SQL ważną w podstawowym use case aplikacji.
- popełniał błędy składniowe(mam wrażenie, że wcześniejsze modele nie miały z tym problemu) nawet tak trywialne jak nie zamknięcie nawiasu
- wpadał w pętle zmian w kodzie skutkujących brakiem poprawnego działania aplikacji i nie pomagało podanie danych wejściowych, otrzymanych błędnych wyników i poprawnych wyników, wycofywałem także wszystkie zmiany i zaczynałem od początku - bez uzyskania poprawy
- problemy z regexem(klasyczne pomijanie części wymagań)

Jednakże powyższe jest łatwe do wychwycenia i po naprowadzeniu dawał dobre rozwiązania. Nie napisałem nawet jednego wyrażenia do kodu źródłowego, cofałem tylko zmiany, promptowałem i testowałem, z czasem zacząłem robić pobieżną analizę kodu, by szybciej wkroczyć z naprowadzaniem.

Lepiej radzi z sobie z frontendem niż backendem, domyśla się nawet przy nieprecyzyjnym naprowadzaniu w przypadku FE i w przypadku BE rzadko dostarcza wszystkie oczywiste warunki brzegowe.

Rezultat jest bardziej spaghetti od tego co robię na co dzień.
Dodam, że zawsze miałem wrażenie, że jestem powolnym programistą - inni nie zastanawiali się nad składnią i również szybciej projektowali całokształt funkcji, za to znam się na architekturze co pomaga w promptowaniu.

[Ksiega_dusz]

@straggler2:
Po pierwsze:

Ogólnie to w pracy przez to, że szybciej robisz teraz to nie pokazuj tego aż tak bo Ci jeszcze bardziej śrubę będą dokręcać. Ja wolny czas przeznaczam na samorozwój.

Wracając

[niedorzecznybubr]

Nie wiem jak wy promptokodujecie, że nie osiągacie ogromnego wzrostu wydajności lub otrzymany kod jest do bani

@straggler2: 99% pracy programisty to nie jest pisanie kodu, więc zyski są niewielkie. A jak się zajmuje poważnymi rzeczami, a nie frontendem czy CRUDami, to AI wymięka i nie radzi sobie

[groman43]

@straggler2: A nie przyszło Ci do głowy, że ludzie czasem pracują nad czymś bardziej skomplikowanym niż typowy krud?

[polskie-k0rpo]

@straggler2: to co koledzy wyżej napisali, do tego "znanie sie na architekturze" to największy cope crudziarza w ostatnich latach, sam go przeżywałem będąc krudziarzem. architekturę to możesz mieć w CPU - do wyboru, do koloru SPARC, AVR, MIPS, x86, ARM... wymieniać dalej? XD Tymczasem biznesowi korpo klepacze "architekci" doszukują się architektury w przekomplikowywaniu prostej wymiany danych w wysokopoziomowych aplikacjach, bo chcą brzmieć poważnie, w praktyce generują problemy, bo zamiast nauczyć

[some_ONE]

@polskie-k0rpo: "moja architektura jest lepsza niż twoja"

ego top

[polskie-k0rpo]

@some_ONE: nie moja vs twoja bo jak pisałem sam taki byłem i to giga cope by w łatwy sposób brzmieć mądrze. W praktyce taki architekt jest słaby w komputery no bo on przecież operuje tylko na umownych abstrakcjach, a to jak coś działa to tylko zaledwie „detal implementacyjny” - żeby nie było, cytuję wielkich myślicieli, architektów pokroju Sobótki czy Aniserowicza xD

[some_ONE]

W praktyce taki architekt jest słaby w komputery no bo on przecież operuje tylko na umownych abstrakcjach, a to jak coś działa to tylko zaledwie „detal implementacyjny”

@polskie-k0rpo: no, to tak samo jak te "SPARC, AVR, MIPS, x86, ARM", jedyna prawdziwa architektura to na poziomie krzemu i tranzystorów jest ( ͡° ͜ʖ ͡°)

[polskie-k0rpo]

@some_ONE: ???? na poziomie krzemu i tranzystorów tworzy się co najwyżej bramki logiczne

[some_ONE]

@polskie-k0rpo: dokładnie, a te całe SPARCi i x86 to tylko abstrakcja

[polskie-k0rpo]

@some_ONE: no jasne no i co w związku z tym xD co to ma do architektury? pisałeś o jakiejś architekturze na tym poziomie a nie o abstrakcji, to że jest tam abstrakcja do świetnie. zastanów się czy na poziomie 15 tej abstrakcji warto dokładać kolejne do wrzucania rzeczy do bazy danych xD

[tubkas12]

sam go przeżywałem będąc krudziarzem. architekturę to możesz mieć w CPU - do wyboru, do koloru SPARC, AVR, MIPS, x86, ARM... wymieniać dalej? XD Tymczasem biznesowi korpo klepacze "architekci" doszukują się architektury w przekomplikowywaniu prostej wymiany danych w wysokopoziomowych aplikacjach, bo chcą brzmieć poważnie, w praktyce generują problemy, bo zamiast nauczyć się prawdziwego CS to uczą się "ARCHITEKTURY CRUDÓW" by robić kolejne nakładki na klasy i więcej plików do repo dodać i

[polskie-k0rpo]

trafiłem na ciekawy ruch w programowaniu który j---ł OOP

@tubkas12: czyżby "handmade hero" i spółka? :)

i przy okazji dzięki za komentarz - przywracasz wiarę w ten tag bo myślałem, że tutaj ciężko kogoś z podobnym spojrzeniem spotkać.

[tubkas12]

czyżby "handmade hero" i spółka? :)

@polskie-k0rpo: tak

[TomSz]

Jakaś aplikacja crudowa której używa z 10 osób na godzinę jest napisana z użyciem mikroserwisów, mnóstwo bzdurnych patternów i do tego oczywiście musi być kubernetes i chmura.

@tubkas12: z mojego doświadczenia za pomocą AI tak najlepiej właśnie robić. AI może mniej zepsuć bo pracujemy nad jedną rzeczą na raz, można łatwiej iterować jak i wymienić cały komponent. Monolit łatwiej zepsuć, trudniej zrozumieć działanie i debugować. Jak AI nie daje sobie

[tubkas12]

@TomSz: chyba nie rozumiesz po co powstały mikroserwisy, mikroserwisy zaczęły być używane w dużych firmach bo rozwiązywały problem skalowania, a dokładnie dzięki mikroserwisom możesz łatwiej sobie skalować horyzontalnie. Mikroserwisy nie rozwiązują problemu struktury bo równie dobrze możesz mieć ten słynny modularny monolit i tak jest pisana większość dobrych monolitów.

Monolit łatwiej zepsuć, trudniej zrozumieć działanie i debugować.

Trudniej debugować monolit? Pracowałeś kiedyś przy dużym systemie z wieloma mikro-serwisami? Skoro gadasz

[TomSz]

@tubkas12: ta rozmowa jest o tym z czym AI sobie lepiej radzi, po co coś było robione przed AI, czy z czym sobie człowiek lepiej radzi nie ma nic do rzeczy

[tubkas12]

@TomSz: widać że jesteś vibe coderem bo nie masz zielonego pojęcia o czym ty gadasz.

[TomSz]

@tubkas12:

[tubkas12]

@TomSz: po prostu nie rozumiesz tego czym jest coupling i błędnie łączysz wysoki coupling z monolitem, a niski z mikroserwisami. Nie masz po prostu zielonego pojęcia co ty gadasz i możesz sobie wstawiać memy, ale widać że w głowie pustka

[TomSz]

@tubkas12: Ty po prostu wychodzisz z założenia że kogoś obchodzi Twoja architektura, 90%+ rynku IT ma to gdzieś bo ma być szybko i tanio. Ja rozumiem, że masz rację... odnośnie bardzo małej części rynku którą to obchodzi i która będzie się zmniejszać.