AI w pracy programisty

Dla kogo jest artykuł i co w nim znajdziesz?

W poniższym artykule znajdziesz porady dotyczące lepszego wykorzystania LLM w codziennej pracy programisty. Przedstawię w nim 23 wnioski i porady, do których doszedłem podczas codziennej pracy z wykorzystaniem AI. Wypracowałem je podczas testowania 2 wtyczek do VS Code: Roo Code i GitHub Copiliot. Korzystałem również z kilku modeli w tym Chat Gpt 4.1, Clode Sonnet 3.7, Cloude Sonnet 4.5, modeli abonamentowych od z.ai i darmowych z Roo Code Cloude (ci dwaj dostawcy co chwilę zmieniają dostępne modele, więc nie wypisuję ich). Wypracowane porady i zasady stosuję codziennie podczas konstruowania swoich promtpów i dzielę się nimi w zespole w pracy. Osobiście widzę wiele korzyści z korzystania z nich, a największą jest to, że udaje mi się coraz częściej wdrożyć zamówiony feature dzięki jednemu, kompletnemu promptowi, bez dodatkowych kombinacji. 

Jak doszedłem do poniższych wniosków?

Jak pisałem wyżej, testowałem wiele kombinacji podczas wdrażania codziennych zadań w pracy. Główna część mojej pracy to tworzenie i rozbudowywanie narzędzi, CRM, mikro serwisów i platformy raportowej dla klientów. Testy były prowadzone w różnych środowiskach od legacy kodu w PHP 5.6 w wielkiej kuli błota po lekkie mikro serwisy spełniające pojedyncze funkcjonalności w TypeScript. Nie były to badania, więc również rozkład próbek na pewno nie był równy, nie mniej uważam, że udało mi się wypracować uniwersalny zbiór porad, który w każdym środowisku poprawiał skuteczność i wydajność pracy z LLM. 

Wnioski

Przejdźmy zatem do konkretów. Poniżej prezentuje 23 punkty, podzielone tematycznie na 6 grup. Nie jest to jakiś sztywny podział, a raczej coś, co wynikło z moich potrzeb sensownego dzielenia pomysłów w głowie.

Model modelowi nierówny

Doszedłem do wniosków z tej grupy m.in. po kilkugodzinnej próbie rozwiązania problemu z brakiem poprawnej autoryzacji akcji w serwisie. Korzystałem wtedy z darmowej wersji modelu i rozszerzenia RooCode. Całość trwała 2-3 godzinki, ale na swoje usprawiedliwienie powiem, że celowo pozwalałem chatowi na wiele samodzielnych prób (oglądając w tym czasie YouTube, o tym trochę więcej powiem w dalszej części artykułu). Następnie już lekko sfrustrowany zacząłem analizować problem samodzielnie. Już po kilku minutach wiedziałem, że problemem było niepoprawne przekazywanie tokenu przez frontend. Wiedząc, co jest przyczyną, dawałem wskazówki chatowi, otwierałem nowe chaty, ale do momentu, aż nie wskazałem, co dokładnie ma zrobić, nie był w stanie rozwiązać problemu. Cofnąłem zmiany i z ciekawości przetestowałem również Roo Code, ale tym razem z Sonnet 3.7. Napisałem lakonicznego prompta, bez wskazówek czego i gdzie szukać, tylko opisałem problem, który widzę. Ku mojemu zdziwieniu, problem został rozwiązany w niecałe 5 min… 5 minut wystarczyło innemu modelowi, aby rozwiązać problem, z którym darmowy model męczył się praktycznie bez końca! Dziś w celu optymalizacji kosztów korzystam z kilku modeli. Darmowych do prostych zadań, ale wyzbyłem się oporów, aby przełączyć na płatny model, jeżeli mierzę się z trudniejszym zadaniem - polecam to samo, każdemu. Poniżej przedstawiam pierwsze 3 wnioski, jakie wysunąłem z powyższej i kilku innych, podobnych sytuacji.

• Czasem lepiej zapłacić więcej i rozwiązać problem jednym, precyzyjnym poleceniem.

• Tańszy model może prowadzić do straty czasu i braku satysfakcjonującego rozwiązania.

• W celu ograniczenia kosztów trzeba świadomie wybierać model adekwatnie do trudności zadania.

Kontekst jest kluczowy

Gdzieś kiedyś słyszałem, że „kontekst jest królem”. Nie pamiętam, skąd i nie chcę nawet tego sprawdzać (jeżeli czujecie potrzebę to śmiało), ale w przypadku pracy z LLM, mogę śmiało podpisać się pod tym stwierdzeniem.

• Twórz rozbudowane i precyzyjne prompty.

Pewnie podobną radę znajdziecie w każdym poradniku do kodowania z pomocą LLM, ale to jest naprawdę kluczowe. Lakoniczne propmpty w stylu „nie działa mi abc”, „zrób tak, by było ładnie”, „nie podoba mi się, popraw” będą prowadzić do nieprzewidzianych efektów. Im bardziej rozbudowany będzie prompt, im więcej przykładów dasz, tym lepszego wyniku można się spodziewać.

• Wskaż dokładnie, co ma być edytowane, w jakim widoku i obok jakiego elementu.

Powyższa rada jest użyteczna, chyba w każdej sytuacji, ale dostrzeżecie korzyści z jej stosowania w momencie gdy zaczniecie pracować z legacy code lub w wielkiej kuli błota, gdzie niekoniecznie nazwy modelu, funkcji czy zmiennych mają sens. Często to naszą rolą może być właśnie poprawienie tego stanu rzeczy i tutaj nie ma co ukrywać, sami programiści mogą pogubić się w kodzie, w którym stosuje się złe nazewnictwo. Dlatego wskazanie konkretnych plików (np. przy pomocy skrótów z poziomu okienka prompta) znacząco poprawia jakość kontekstu, który jest przekazywany do modelu, a tym samym zwiększa szansę na lepszy efekt.

• Musisz wiedzieć, jaki cel chcesz osiągnąć za pomocą polecenia.

Jak każesz czatowi coś zrobić ładnie, minimalistycznie czy jakkolwiek, zrobi to, ale nie jest powiedziane, że będzie to efekt, którego oczekujesz. Często jest tak, że może popłynąć podczas wdrażania rozwiązania i nakierowanie go na docelowe rozwiązanie, będzie wymagało dodatkowej pracy. Dlatego uważam, że zanim zaczniemy pisać prompta, powinniśmy wiedzieć do jakiego stanu chcemy doprowadzić kod. Czy widok ma być podzielone na 2 kolumny, może 4 karty? Czy chcemy całość klasy zaimplementować za jednym razem, a może zacząć od jednej funkcji? Zatrzymanie się na moment i zastanowienie nad celem często ułatwi nam pisanie samego prompta, a to na pewno przełoży się na lepszą pracę modelu.

• Brak zdefiniowanych standardów i chaos w poleceniach obniża jakość odpowiedzi modelu.

Ponownie wniosek wyciągnięty podczas pracy w legacy kodzie z brakiem standardów w nazewnictwie czy strukturze plików. Nie będę się tutaj rozpisywał, brak standardów w projekcie utrudnia orientacje programiście i tak samo dzieje się z AI.

• Chat łatwo zapomina kontekst, czasem trzeba mu podpowiedzieć np. gdzie są logi (warto je czyścić regularnie podczas developmentu)

W RooCode podczas pracy z każdym modelem mamy o nim kilka dodatkowych informacji m.in. ilość tokenów, długość wiadomości czy parametry cache’owania rozmów. W skrócie, podczas pracy trzeba mieć te parametry z tyłu głowy (chodź w przypadku RooCode doświadczymy często samodzielnych prób kondensowania dłuższych rozmów do podsumowań, tak by dalej prowadzić rozmowę z zachowanym kontekstem). Osobiście staram się prawie w każdym rozbudowanym promptcie wskazać, które pliki warto przeglądnąć, czy do jakich warto się odnieść. Pomogło mi to nie raz, natomiast np. nie załączanie logów (czyśćmy je regularnie), przeważnie wydłużało pracę chata, bo musiał sam je znaleźć - szkoda czasu.

Model wspiera projektowanie, ale nie zastąpi projektanta

• Zachęcaj model, aby zadawał pytania w celu lepszego zrozumienia Twoich potrzeb.

Czasami nie zawsze wiemy, co chcemy osiągnąć lub nie wiemy, co pominęliśmy. Spoiler! Chat też tego nie wie, ale może nam pomóc zmniejszyć tę lukę wiedzy. Jeżeli czujecie, że coś możecie przeoczyć, nie bójcie poinstruować chata, by zadawał wam pytania lub szukał dziury w całym, czasem kilka dodatkowych promptów pozwoli wam zaoszczędzić dużo czasu podczas wycofywania się z jakiegoś ślepego zaułku.

• Często w trakcie odpowiadania na te pytania sam wpadasz na najlepsze rozwiązanie.

Bądź mi kaczką! Czasem trzeba coś powiedzieć na głos lub wytłumaczyć coś kaczce. Szczególnie nim przejdziemy do wdrożenia, warto zapytać chata o nasz pomysł. Często nawet nie będziemy potrzebowali, aby nam odpowiedział, już podczas pisania zorientujemy się, że coś trzeba zmienić lub czegoś brakuje.

• Model nigdy nie pozna potrzeby tak dobrze jak Ty, wspieraj się nim, ale to Ty rób robotę.

To jest chyba jeden z ważniejszych wniosków z tych wszystkich. Nie ufaj wieszczom, którzy zapowiadają utratę pracy wszystkich programistów. Bańka pęka, a ograniczenia technologii są coraz bardziej widoczne. Nie przeczę korzyściom z umiejętnego korzystania z LLM w pracy programisty, ale trzeba pamiętać, że nigdy chat nie pozna tak dobrze historii, potrzeb zespołu i projektu jak Ty. Nawet gdybyś nie wiem jak bardzo chciał to dobrze opisać, na pewno coś pominiesz lub przekręcisz, dlatego nie możesz zdawać się w 100% na bota (może maks w 80%). Nadal to Ty odpowiadasz za projekt i za dostarczenie narzędzia zgodnego z zapotrzebowaniem i to Ty wiesz, co najlepiej się sprawdzi, a nie chat.

• Akceptowanie zmian bez weryfikacji nie przyspieszy pracy 

(chyba, że to etap stawiania projektu od zera gdzie generujemy całą strukturę, wtedy wiadomo, że akceptowanie każdej zmiany byłoby przesadą, ten punkt tyczy się pracy w już postawionym projekcie)

• Zawsze analizuj kod wygenerowany przez AI – może zawierać proste błędy lub pomijać oczywiste rozwiązania.

• Jeśli nie rozumiesz kodu, jesteś całkowicie zależny od sugestii modelu.

• Modele mają tendencję do komplikowania rozwiązań (np. przez dodawanie zbędnych logów, klas czy funkcji testowych).

• Uważaj na generowanie niepotrzebnych zadań, które można wykonać prościej (np. dodatkowe restartowanie aplikacji, która już jest w trybie hot reload).
  
  Do powyższych 5 punktów będę miał kolejną historyjkę. Pod wpływem endorfin i ogólnej radości z jakości działania LLM rozpocząłem tworzenie nowego projektu w Laravel i Vue3. Projekt odpalony poprzez composer run dev. Po jednej stronie ekranu - przeładowująca się automatycznie wersja live strony, po prawej kod, na środku okno chatu. Niczym Hypecoder piszę, co mi się nie podoba w widoku po lewej stronie, a chat w kodzie na prawo wprowadza zmiany. Chcę nową funkcję, piszę prompta lub dwa i cyk, jest. Nowy standard programowania! Chwalę się swojej dziewczynie, by zobaczyła, jak to wygląda. Piszę, co chcę zmienić, przełączam się na YouTube i oglądam filmik, podczas gdy chat pracuje. Gdy widzę, że skończył, wracam ocenić efekt, piszę prompta i tak dalej. Wszystko ładnie, pięknie… do czasu, gdy zerknę w kod, co takiego chat właściwie zrobił. W moim przypadku wdrożył 3 niezależne systemy tagów zamiast jednego uniwersalnego. Każdy w inny sposób, jeden trzymany w enum’ach, drugi na sztywno w jednej kolumnie w bazie (o zgrozo), trzeci jako osobna tabela tagów z relacjami do pożądanego modelu. Finalnie miałem trzy wersje tego samego, a nic nie było spójne, ale działało i wyglądało dobrze… Historia skończyła się tak, że musiałem posprzątać i uspójnić system tak, aby zostawić tylko jedną wersję. Sprzątanie i usuwanie niepotrzebnych funkcji, następnie przywracanie widoków do działania zajęło mi naprawdę o wiele dłużej niż „zaoszczędzony czas”, który poświęciłem na oglądanie tych filmików. Wystarczyło tylko rzucić okiem na zmiany i od razu bym widział, że chat zaczyna płynąć i wdraża jakieś nowe rozwiązanie, zamiast skorzystać z istniejącego. 

Małe zadania - lepsze rozwiązania

Szczególnie w dużych projektach lub skomplikowanych funkcjonalnościach, lepiej podzielić zadanie na mniejsze elementy. Możemy to zrobić samodzielnie albo skonstruować prompt tak, aby sam podzielił zadanie, np. czekając na waszą akceptację nim przejdzie do następnego kroku.

• Modele AI najlepiej radzą sobie z małymi, dobrze zdefiniowanymi zadaniami.

• Większe zadania wymagają wstępnej analizy i podziału na etapy, co pozwala uniknąć marnowania zasobów.

• Mniejszy zakres projektu lub mniejsza liczba plików ułatwiają modelowi trzymanie się narzuconych standardów.

Uwaga na nieaktualną wiedzę modelu

• Pamiętaj, że wiedza modelu może być nieaktualna.

• Model może proponować rozwiązania oparte na przestarzałych wersjach bibliotek

• Zawsze weryfikuj kluczowe informacje w oficjalnej dokumentacji (korzystaj z MCP).

Do powyższych wniosków doszedłem podczas wczesnych wersji GitHub Copiliot, kiedy jeszcze nie było dostępu do MCP Context 7. Moja historyjka nie będzie długa. Bull MQ w najnowszej wersji korzysta z innego zestawu stanów ticketów niż wersja poprzednia. Co za tym idzie chat proponował mi rozwiązania ze starszej wersji biblioteki zamiast z najnowszej, której dokumentację przeglądałem. To, co stworzył, było niespójne z nią, nawet jak zlokalizowałem problem i wskazałem mu, z której wersji ma korzystać. 

Podobne trudności napotkałem jak próbowałem wytłumaczyć chatowi, żeby korzystał z Laravel 12. Twierdził, że ta wersja jeszcze nie została wydana… Obecnie chaty korzystają z MCP, w tym wspomnianego MCP Context 7, ale trzeba mieć na uwadze, że różne modele różnie wywołują narzędzia MCP, więc czasem warto wskazać w promptcie, że oczekujesz, że sprawdzi najnowszą wersję lub chociaż tę wersję biblioteki, której używacie w projekcie.

Czasem trzeba wziąć sprawy w swoje ręce

• Bolączka zapętlania się chata wokół ograniczonych propozycji rozwiązań

To jest problem, którego raczej nie rozwiążemy samodzielnie, ani się na niego nie uodpornimy, ale chciałem go wskazać, by trochę przestrzec przed takim hypecodoing, szczególnie jak pracujemy na modelach płatnych. Narzędzia korzystające z LLM są naprawdę silnym wsparciem, ale nie są idealne. Mają swoje problemy i bolączki i uważam, że warto mieć na oku to jak działają.

• Niechęć do zmiany treści promptów i udzielania pomocnych sugestii chatowi

Ten punkt stricte dotyczy nas samych jako programistów. Nie raz słyszałem, że „dobry programista to leniwy programista”, co w wielu sytuacjach jest prawdą, ale nie może to być naszym mottem. Niechęć do pisania rozbudowanych chatów, pomocy w przygotowaniu kontekstu, czy niskie zainteresowanie zmianami w kodzie, jakie chat wykonuje, może niejednokrotnie dodać nam pracy, zamiast tak naprawdę ją nam przyśpieszyć.

Uwagi i doświadczenia

Poniższe punkty nie należą do dwudziestu trzech wniosków powyżej. Podczas prezentacji, którą przedstawiłem zespołowi, ta sekcja była bardziej wnioskami i miejscem na wymianę doświadczeń. Uznałem, że warto je zawrzeć, bo pełnią swoiste dopełnienie tematu i wierzę, że będą wartościowe równie bardzo jak powyższe.

• Zaplanuj sobie dodatkową pracę przy zadaniu, tak byś nie musiał oglądać YouTube.

Czasami chat będzie potrzebował czasu na wykonanie zadania (szczególnie tańsze lub darmowe LLM), oglądanie YT to pewien pomysł, ale nie polecam go. Łatwo stracić uwagę i nie patrzeć na to, co się dzieje kodzie. Dodatkowo popadamy w pułapkę częstej zmiany kontekstu. Osobiście preferuję, aby w momencie oczekiwania na wykonanie pracy przez LLM, zrobić coś powiązanego z projektem, może być to: rozplanowanie następnych zadań, aktualizacja zadania w ClikcUp, aktualizacja dokumentacji itp.

• Polskie znaki zabierają więcej tokenów.

To prawda, ale w świetle ostatnich badań (https://arxiv.org/html/2510.11560v1) nie przejmowałbym się tym. Język polski ma taką przewagę nad innymi, że jest bardzo precyzyjny i o ile raczej używanie języka angielskiego w pracy programisty jest naturalne, to przyznam, że często wolę realizować zadania pisząc po polsku, bo realnie lepiej jestem w stanie opisać cel, niż bym to zrobił w języku angielskim.

• Zaangażowanie programisty i zrozumienie kodu nadal jest kluczowe.

• Korzystanie z chata nie zwalnia z zachowywania standardów dobrego kodu.

I koniec. Trochę przydługawy wyszedł ten artykuł, ale wierzę, że pomoże wam w waszej codziennej pracy.