Jak w temacie, polecicie jakiś? W szczególności do pracy i zmian w C#. Czy może jednak korzystanie z płatnych modeli podnosi jakość zwracanego kodu na wyższy poziom?
Lub po prostu Copilot i inne zintegrowane z IDE rozwiązania?
Jak w temacie, polecicie jakiś? W szczególności do pracy i zmian w C#. Czy może jednak korzystanie z płatnych modeli podnosi jakość zwracanego kodu na wyższy poziom?
Lub po prostu Copilot i inne zintegrowane z IDE rozwiązania?
Nie zauważyłem żeby płatne narzędzia sklecały znacznie lepszy kod, bardziej kwestia szczęścia i prompta. Płatne mają po prostu większe limity.
Do kodu obecnie najlepsze jest chyba gemini 3 pro, claude, grok. Chatgpt, copilot w moim doświadczeniu jest gdzieś na końcu i nawet już nie próbuje ich używać do kodu, choć github copilot jest wbudowany w vs i vs code więc tak na co dzień do prostych tasków używam, do większych zmian - nie. Wszystko się mogło zmienić od wczoraj, ciężko nadążyć. Ale tak z wstępnych testów to gemini kładzie konkurencje i może warto zapłacić.
obscurity napisał(a):
do prostych tasków używam, do większych zmian - nie.
Pytanie jak definiujesz proste taski a jak większe zmiany? Gdzie jest granica?
bakunet napisał(a):
obscurity napisał(a):
do prostych tasków używam, do większych zmian - nie.
Pytanie jak definiujesz proste taski a jak większe zmiany? Gdzie jest granica?
No dość prosto - prosty task: pojedyncza metoda, a nawet linijka, ewentualnie cała klasa typu kontroler, czy inny boilerplate / konfiguracja. Coś co kiedyś znalazłbym na stackoverflow w ciągu paru sekund.
Większa zmiana - zaprojektowanie szkieletu całego feature'a, albo nawet rozpoczęcie całej nowej aplikacji, refaktoryzacja wielu klas, napisanie zbiorowych testów. Coś na co kiedyś bym poświęcił kilka godzin.
Ogólnie może gemini już nie jest takie głupie ale wcześniej llmy nauczyły mnie że albo coś robisz jednym promptem albo wcale. Próba połatania, wprowadzania nowych funkcji do już wygenerowanego kodu zazwyczaj powoduje motanie się w miejscu, tworzenie w kółko tych samych bugów, naprawianie jednej rzeczy kosztem drugiej która już dobrze działała. Ale w zasadzie tak samo to działa z ludzkimi devami.
Zazwyczaj więc zaczynam od zera używając kilku topowych modeli, daję im ten sam prompt na aplikacje / feature i wybieram ten który mi najbardziej pasuje a dalej już większość koduję "po staremu" wspomagając się jedynie wbudowanym copilotem do autouzupełniania.
@obscurity: Z Twoich propozycji póki co Claude dzisiaj najlepiej się sprawdzał do optymalizacji kodu. Dzięki!
Może off top ale chciałbym już żeby kadra menadżerska w IT zdjęła te różowe okulary pt. AI jest rozwiązaniem na wszystko.
W dobrze rozbudowanym produkcie jest gorsza od pijanej małpy, bo pijana małpa nie jest w stanie narobić nic złego, gdzie agent robi niemiłosierny i nie do utrzymania syf.
Niech pisze unity i utility funkcje (ofc te powtarzalne i proste) i wystarczy.
Anthropic się ostatnio popisało, gdzie mówili inżynierowie, że pół roku i software development is dead po czym kupili sobie team developerów, rozwijający Bun - hipokryzja marketingu 101.
Copilot to tylko interface do LLM-ów.
Jeśli przyjrzysz się jego opcją do powinieneś zauważyć, że pozwala on używać różne LLM:
U mnie to wygląda tak:

Jak widać mam włączony Claude Sonnet 4.5 (domyślna opcja).
Próbowałem niektóre inne i Claude był najlepszy, ale nie były to poważne testy.
Przy czym z moich obserwacji wynika, że generowany kod produkcyjny jest do d..y.
Za to, jak napiszę troszkę testów, to supper je uzupełnia. Szczególnie jak napisze Data Driven Test, to poprawnie uzupełnia dane testowe.
Fajną opcją jest tez "Code Review". Przed "commit" sprawdza różnice i daje komentarze. Jakość ich jest różna, ale ogólnie oszczędza mi to czasu przy ludzkim review, bo Copilot zapewnia natychmiastową informację zwrotną i łapie wszystkie literówki i gramatyczne błędy.
Najlepszy według moich doświadczeń jest copilot z modelem Claude Sonnet 4.5, szczególnie jeśli chodzi o jakieś generyczne zmiany.
Warto zrobić plik copilot-instructions.md łatwiej wtedy nakierować model co ma robić a co nie, chociaż bywa nieposłuszny
bakunet napisał(a):
@obscurity: Z Twoich propozycji póki co Claude dzisiaj najlepiej się sprawdzał do optymalizacji kodu. Dzięki!
Najbardziej lubię w nim to, że jak każesz mu zmigrować z biblioteki A na B, i gdy w trakcie takiej migracji natrafi na nierozwiązywalny dla niego problem, to wpada na genialny pomysł, że w sumie, to zamiast B można użyć A, i w efekcie zmigruje z A na A.
Masz trzy zmienne:
Osobiście używam Claude Code + Sonnet 4.5. Próbowałem też tego nowego Opus 4.5, ale mi nie podszedł. Próbowałem też GPT 5 (przez Jetbrainsowe Junie) i generalnie było słabo. Używałem też Junie z Sonnetem ale podnieśli bardzo ceny, więc zmigrowałem na Claude w terminalu.
Szczerze mówiąc to cały temat jest bardzo złożony bo co chwile się coś zmienia i zgaduję, że tak jak mi nie chce ci się doktoryzować i eksperymentyzować na własnej skórze co najlepiej działa. Ja używam tego Clauda za 20 euro/m i mi się sprawdza. Możliwe, że za parę miesięcy poeksperymentuję z czymś innym
somekind napisał(a):
bakunet napisał(a):
@obscurity: Z Twoich propozycji póki co Claude dzisiaj najlepiej się sprawdzał do optymalizacji kodu. Dzięki!
Najbardziej lubię w nim to, że jak każesz mu zmigrować z biblioteki A na B, i gdy w trakcie takiej migracji natrafi na nierozwiązywalny dla niego problem, to wpada na genialny pomysł, że w sumie, to zamiast B można użyć A, i w efekcie zmigruje z A na A.
Brzmi genialnie ;) Stąd zawsze integracyjnie testuję wszystko co mi do tej pory zaproponował :)
bakunet napisał(a):
Brzmi genialnie ;) Stąd zawsze integracyjnie testuję wszystko co mi do tej pory zaproponował :)
Ale po co? Czat sam wie, że jeśli po jego zmianach testy nie przechodzą, to jest to wina danych, niezwiązana z kodem, więc te testy usuwa.
Póki co mi się sprawdza. Jak Cloude coś odwali, to wychodzi mi na integracji.
Przyznaję, że uzupełnia moje braki w wiedzy i niedociągnięcia, sugerując bardziej wydajne lub nowsze rozwiązania składniowe po tym jak "już działa".