Dobre praktyki pracy z AI

Tak sobie pomyslalem o podejściu do AI — jedni są zachwyceni, drudzy sceptyczni i można godzinami debatować nad tym, co AI potrafi dziś, a co ogarnie za parę lat.
Większość devòw i tak już korzysta lub zaraz będzie korzystać z LLM-ów przy codziennej pracy — czy to do klepania testów, szukania pomysłów na architekturę, czy po prostu do opieprzania się i commitowania tego co wypluje AI.
Pewnie każdy zdążył już wyrobić sobie jakieś swoje nawyki i zauważyć, co działa, a na czym można się przejechać. Może warto zebrać w tym wątku przetestowane dobre praktyki na pracę z LLM-ami?

Generowanie testów.

Nie warto prosić model o kod i testy do niego w jednym prompcie. LLM korzysta wtedy z tego samego kontekstu i bezmyślnie powiela swoje własne błędy logiczne z implementacji. Zdecydowanie lepiej najpierw wygenerować samą logikę, przejrzeć ja, a po testy uderzyć w nowym prompcie z opisem edge casow.
Jak to wygląda u Was? Macie jakieś swoje sprawdzone wzorce, zasady albo system prompty, które realnie oszczędzają czas?
Z tymi testami trzeba tego LLMa trochę oszukać, trochę go przemodelować

Jak opisałeś Twój przykład "mądrzejszego użycia", to faktycznie zrozumiałem jak głupie było proszenie od razu o testy. :) Dzięki @QA

QA napisał(a):

Generowanie testów.

Nie warto prosić model o kod i testy do niego w jednym prompcie. LLM korzysta wtedy z tego samego kontekstu i bezmyślnie powiela swoje własne błędy logiczne z implementacji. Zdecydowanie lepiej najpierw wygenerować samą logikę, przejrzeć ja, a po testy uderzyć w nowym prompcie z opisem edge casow.

w nowej sesji konkretnie, bo 'nowy prompt' może oznaczać kolejną wiadomość w konwersacji, a wtedy przecież poprzednio wygenerowane w tej samej sesji pliki są nadal w konktekście. poza tym jak ktoś ma włączoną 'pamięć' w czatbocie (włączając webowe wersje), to wtedy dane z czatów są współdzielone między nimi. mimo wszystko, nie testowałem jaki rodzaj podziału jak skutecznie działa.

Jak zakładam, że chcę by agent wykonał powtarzalną czynność, zamiast zlecać wykonanie czynności 100 razy w ciemno zlecam zautomatyzowanie czynności, dry-run, wykonanie na pojedynczych przykładach i potem odpalenie jej 100 razy. Mogę przejrzeć kod zanim zostanie wykonane coś trudnego do odkręcenia, dać jakieś uwagi, poprawki itp.

Obecnie testuję wykorzystanie RFC 2119 i stosowanie słów jak MUST, SHOULD itd. do pisania specyfikacji, wymagań funkcjonalnych i niefunkcjonalnych, metod weryfikacji rezultatów itd. Jak na razie jako tako się sprawdza, choć wprowadzenie RFC 2119 prowadzi do pewnego łapania za słówka i wytykania niespójności, jeśli gdy po drodze wynikną nowe przypadki brzegowe, jakieś założenia stracą sens albo trzeba je osłabić / zmodyfikować itd. Generalnie wolę to niż zmienianie planu lub zgadywanie intencji cichaczem, ale nie jest to zachowanie w pełni deterministyczne, wciąż pojawiają się halucynacje.

Robienie rzeczy "w ciemno" i zakładanie, że agent sam znajdzie, wymyśli itd. to ślepa uliczka. Skoro nie wiesz, jak rozwiązać problem, nie wiesz też, jak zweryfikować, czy agent nie zmyśla i nie robi czegoś niepoprawnego lub niebezpiecznego, a może nawet niemożliwego. Jeśli wiesz, czego chcesz, ustaliłeś, co jest wykonalne, a następnie to zlecisz i opiszesz precyzyjnie założenia i ograniczenia, masz większe szanse, że ten jednoręki bandyta zwróci nagrodę, niż jeśli robisz to nie mając rozeznania w temacie.

Przełączam modele żeby nie spalić w tydzień miesięcznego budżetu. Proste rzeczy i robienie "masówki" na kilku moich przykładach zazwyczaj da radę Sonnet. Poważniejsze rzeczy, migracje infrastruktury, eksperymenty gdzie może wyjść a może nie to już raczej Opus. Na Fable się może skuszę, jeśli podwoją mi kiedyś budżet podbnie Ultracode nawet nie próbowałem.

Zresztą, w infrastrukturze zapędzanie się w radosny vibe coding to trochę ślepa uliczka. Nigdy nie byłem nieproduktywny i nie marnowałem czasu tak, jak wtedy, gdy we dwóch z kolegą z zespołu przez miesiąc vibe kodowaliśmy rozwiązanie, podczas gdy manager brzęczał nad głową czemu nie jest zrobione? będzie na za parę godzin? macie przecież ejaja tylko... model w kółko halucynował i obiecywał nam rozwiązanie, którego vendor nie wspierał, ale z managerem wiszącym nad głową i żądającym wyników natychmiast biegaliśmy w kołowrotku bez chwili przerwy na przejrzenie dokumentacji vendora. Już nie mówiąc o tym, co by było, gdybyś zvibe-kodował sobie rozwiązanie na wyścigi w monorepo z IaC kilkunastu zespołów i niechcący zbrickował sobie CI/CD błędem w ustawieniach RBACa

Fable w Jetbrains AI działa fatalnie: jest tak powolny z wyższym effort że to mija się z celem, a żre kredyty 2 razy szybciej niż Opus. W Claude Code nie testowałem, bo każą dodatkowo płacić a z tego co czytałem od Opus wcale tak odczuwalnie lepszy nie jest

Moje spostrzeżenia:
twardy tooling jest kluczowy. Jak jakiś problem się powtarza i jest do automatyzacji to proszę AI do napisania jakiegoś lintera zamiast pisać coś do CLAUDE.md czy jakiegoś skilla. Output z lintera odpalany w CI nie może być olany przez AI, gdzie takie sugestie w markdowanch niestety często są

Jak bym klepał jakiś projekt od zera i miał nad nim pełną władzę (tj. nikt mi nie powie, że wymyślam) to pewnie zacząłbym do zrobienia riserczu jak i co lintować, żeby było dobrze. Przykładowo jak piszę projekt w Go to:

• ogarnałbym w repozytorium infrastrukturę do swobodnego rozszerzenia standardowego golangci-lint jeśli są to aspekty, które można wyczytać z plików .go
• do innych plików (jakieś yamle): szukam odpowiednich technologi do tych zastosowań
• jakieś głupoty (skrypty CI, rzadkie sytuacje): jakieś głupie i proste skrypty, które robią to co mają zrobić w najprostrzy sposób

Ogarnięcie dobrych testów E2E dla mojej aplikacji. Jak klepię backend to chcę mieć dobry setup dla pisania testów, które są tak blisko jak się tylko da do produkcji. Czyli przykładowo ogarniam jak pisać testy, które potrafią szybko/często/wspołbieżnie stawiać bazę postgresową, jeżeli moja aplikacja tego wymaga. Vibeowałem jedną taką typową backendową apkę i takie testy były całkiem przyjemne do weryfikacji tego co agent wypocił, bo testy w stylu po tej serii POSTów wołam GETa i co się wydarzy zrozumie nawet małpa, która nigdy nie widziała tego konkretnego projektu

Jak i zawiodą to pakuję się w skilsy. Przykładowo w moim projekcie czasami muszę analizować informacje, które nie są proste dla AI do przemielenia (obrazki, wideo). Do usprawnienia devexp w takim przypadku potrzebuję:

• historię moich promptów. Wystarczy zapytać agenta z czym zazwyczaj były problem w przeszłości
• specjalną zvibowaną apkę, która jest zoptymalizowana pod konkretny przypadek użycia np. wizualizacja albo analiza danych
• odpowiedni skill, który sam się załącza gdy kontekst prompta jest zgodny z tym spejcalnych przypadkiem

Nie wiem czy to są dobre praktyki, ale u mnie się to sprawdza

Aktualnie używam dwóch agentów do pracy: Gemini i Claude.
Najczęściej są odpalane w ramach Android Studio - Gemini w ramach wbudowanego do AS okienka "agent", a Claude w ramach plugina (taka nakładka na CLI Claudowe, w sumie to wiele się nie różni od tego, jakbym odpalił gołego CLI i tam działał, ale jednak plugin posiada pewne integracje z IDE).

W katalogu projektu mam plik AI.txt oraz katalog AI.
W pliku mam ogólne wytyczne - że na początku pracy ma się zapoznać ze strukturą i zawartością projektu oraz paru bibliotek/dodatków, które są poza projektem, ale z których projekt korzysta. Następnie ma wczytać pliki z katalogu AI.

W tym katalogu jest ok. 10 plików. Nie pamiętam teraz wszystkich, a nie chce mi się odpalać innego kompa na którym to mam, więc piszę z pamęci

• AI-rules - tutaj są główne zasady działania AI: w stylu że przed zmianami ma mnie pytać o zgodę/akceptację, że w określonych miejscach jest całkowity zakaz grzebania, że zmiany mają być tagowane w określonych miejscach itp.
• AI-biznes - zasady biznesowe i wytyczne dot. tej konkretnej aplikacji: co i w jaki sposób robimy, jakich zasad się trzymamy, z jakich bibliotek korzystamy etc
• AI-todo-soon - rzeczy do ogarnięcia już niedługo - np. nad czymś siedzieliśmy ale nie dokończyliśmy, albo podczas robienia czegoś pojawiła się potrzeba, żeby coś innego ogarnąć itp. Takie zadania na najbliższe posiedzenia
• AI-todo-later - rzeczy które trzeba będzie kiedyś-tam ogarnąć, ale to dalsza przyszłość. Wiele z tych tematów to są mocki, które trzeba będzie podmienić na docelowe funkcje w późniejszym terminie (przykładowo - serwer nie jest jeszcze gotowy, więc funkcje pobierające dane zwracają obecnie coś wpisanego na pałę, ale docelowo ma być prawdziwa komunikacja), albo jakieś kolejne ficzery, bez których na razie działamy, ale później trzeba będzie dodać
• AI-changelog - jak nazwa wskazuje, po wprowadzeniu jakichś większych zmian, zapisujemy co było robione. To trochę odpowiednik opisu przy commicie do gita. Jest tagowane CL/GM w zależności od tego, który agent dokonywał zmian. W pliku z zasadami działania AI (AI-rules) jest zaznaczone, żeby trzymać tylko kilka (chyba 15) ostatnich zmian. Nie jest to całkowita historia tego co było robione, ale ostatnie kilka sesji - żeby pamiętać w którym kierunku jedziemy, co robiliśmy ostatnio i też w kontekście takiej historii analizować pliki todo
• AI-gemini oraz AI-claude to są pliki, w których każdy z agentów może zapisywać jakieś swoje prywatne rzeczy, sugestie, przemyślenia itp. (np. ostatnio Claude tam sobie dodał, żeby podczas pracy z plikami projektu nie stosować komend shella typu grep ale korzystać z wbudowanych mechanizmów w IDE). W pliku rules jest wyraźny całkowity zakaz grzebania w pliku kolegi - każdy agent może jedynie pisać do swojego pliku, ale jednocześnie ma obowiązek czytać to, co drugi napisał w swoim
• AI-dialog - plik do komunikacji między agentami. Ostatnio Claude dostał polecenie żeby coś sprawdził i przy okazji znalazł parę miejsc do poprawy - jakieś nieużywane flagi/argumenty, które pozostały po jakichś zmianach, ale już są niepotrzebne, albo stare funkcje zostawione for reference purposes. Ponieważ początkowo w projekcie działał tylko Gemini, a sam Claude został dołożony później, więc wolałem się upewnić, czy na pewno to są rzeczy do usunięcia. Stąd pojawił się pomysł żeby jakoś agenty gadały ze sobą, ale jednocześnie żebym miał nad tym kontrolę - więc pojawił się plik dialogowy. W zasadach AI-rules jest opisane jak mają z niego korzystać. Ponieważ nie lubię jak za wiele się dzieje samo, stworzyłem 3 polecenia dot. prowadzenia dialogu:
  • AI-dialog-rozpocznij: agent ma problem/kwestię, która aktualnie omawiamy dodać do pliku dialogowego jako nowy wątek
  • AI-dialog-odpowiedz: drugi agent odczytuje zadane pytania. Jeśli jest jedno to się do niego odnosi, jeśli kilka - pyta mnie na które ma odpowiedzieć. Zapisuje do pliku dialogowego odpowiedź/uwagi/przemyślenia/cokolwiek
  • AI-dialog-kontynuuj: agent zadający pytanie zapoznaje się z odpowiedzią i albo dopytuje dalej (jeśli odpowiedź jest niepełna/niejasna) albo (jeśli czuje się zaspokojony) wykonuje czynności konieczne do realizacji odpowiedzi a potem sam wątek dot. tej sprawy usuwa z pliku dialogowego.

Powyżej z grubsza podałem założenia. Pisałem z głowy, także mogłem coś przeoczyć, ale zasadniczo oddałem sens mojego mechanizmu.
Co do samych zasad - jest tego dużo, ale nie ma sensu żebym je teraz podawał. Zwłaszcza, że każdy może mieć inne założenia i inne podejście do tematu. Poza tym - zasady się pojawiają same podczas pracy - coś robimy i widzę, że dobrze by było ustalić na sztywno że coś ma być robione w określony sposób.
Pewnie część z Was uzna że niepotrzebnie komplikuję sobie życie, można po prostu puścić maszynę i niech sama robi co tylko sobie będzie chciała. Ale ja jednak wolę patrzeć na zmiany (zwłaszcza że czasem robi głupoty, które jak wyłapię i zwrócę uwagę to potem słyszę tak, rzeczywiście, masz rację - jakby zrobił to w ten sposób jak chciałem to wtedy mogłoby się stać XXXXXX i by był problem - więc chcę chociaż z grubsza trzymać rękę na pulsie i manualnie zatwierdzać zmiany. Nie chcę także (niektórzy tak robią - dają zadanie, agenci się odpalają, pracują kilka godzin i dają gotową i działającą apkę) puszczać AI bez kontroli, chcę prowadzić za rękę i na bieżaco wprowadzać zmiany - żeby było dokładnie zgodnie z moją wizą. Przy pełnej niezależności agenta nie jest to realne, chyba że bym wpisał na 20 stron wytyczne i opis jak wszystko powinno działać i wyglądać. Ale wolę po prostu, małymi kroczkami. Czyli z grubsza to działam tak samo jakbym sam pisał, tylko po prostu AI wyręcza mnie w tworzeniu kodu. Ale to ja mówię co teraz robimy, w jaki sposób, ja zatwierdzam zmiany w kodzie i daję informacje dot. poprawek.

Aaaa....
Jeszcze dodam, że nie korzystam z żadnych MCP czy skillsów. Aczkolwiek to kłamstwo - bo korzystam
Tyle że te dodatki (np. MCP z praktycznie cała bazą przepisów prawnych, orzeczeń sądów, ISAP itp.) są dodane do Claude - ale jedynie w zakresie tematów prawniczych. Do programowania mam po prostu wykupione licencje i korzystam z tego, co sam Claude i Gemini oferują. Dodatki są - ale w calkowicie innych branżach/zastosowaniach.

Ja mam coraz bardziej wrażenie, że sprawdzają się te same dobre praktyki, co przy zwykłym kodowaniu. Całe to nudne SOLID, YAGNI, DRY, TDD(!) i co chyba najważniejsze clean code sprawdzają się jeszcze bardziej niż przy zwykłym białko aj.
Podstawa to dobra dokumentacja wymagań (niespodzianka). Zapisuję w projekcie, w plikach .md cel biznesowy, road mapę, decision log. Czyli oprócz tego, co zwykle dostrawaliśmy od biznesu, potrzeba jeszcze mieć "na papierze" wszystkie zmiany, doprecyzowania, decyzje, opisaną architekturę. Do tego zamordystyczny podział na pojedyncze odpowiedzialności, pilnowanie, żeby pojedynczy plik nie miał więcej niż te 200-300 linii kodu, hermetyzacja.
Do tego, od czasu do czasu lub na koniec zadania warto tę dokumentację odświeżyć, uzupełnić, wywalić do innych plików wartości historyczne.

Wybitnie dobrze sprawdza mi się ~ TDD, czyli najpierw prompt o stworzenie testów, później prompt o stworzenie kodu do nich. Pokrycie testami też warto utrzymywać na bardzo wysokim poziomie, zarówno samego kodu, jak i pokrycie wymagań biznesowych.

Przed zapuszczeniem kodowania, zawsze trzeba zrobić sprawdzenie dokumentacji, zapytać o skutki uboczne, czy implementaion plan pokrywa to co chcemy osiągnąć, czy nie ma żadnych otwartych pytań.

Warto też popracować nad swoim agentem i dać mu dobre narzędzia. To, że Opus poradzi sobie z przemieleniem projektu i sprawdzeniem zależności, nie oznacza, że chcę za to płacić, więc wszelkie narzędzia zwracające strukturę kodu potrafią oszczędzić masę kasy. Jeżeli LLM zamiast przetrzepać cały plik z kodem, może uruchomić narzędzie do zrobienia outline tego kodu, to wyciągnie sobie do analizy jedynie fragment z interesującą go funkcją, a nie zużywa tokeny na przewalanie całości. Hint: https://tree-sitter.github.io/tree-sitter/

To co mi się kompletnie nie sprawdza, to wychwytywanie pojedynczych błędów i ganianie się z AI

Ogólnie, to pracując z jakimś projektem, warto zapytać swojego agenta, jakich narzędzi potrzebuje, żeby zużywać mniej tokenów, kazać mu je zainstalować i skonfigurować.

Kosztowo - dostęþne są albo złożone, wolne, ale "mądre" modele, albo takie tanie, szybkie, ale głupie. Kluczem jest wybranie właściwego, co konkretnego zadania. Czasami pomaga też naprowadzenie takiego modelu na sensowną ścieżkę "rozumowania". Jest dziwaczny błąd z którym nie może sobie poradzić - kazać mu przygotować listę hipotez, następnie zwalidować je, na końcu zrobić implementation plan i implementację.

Dodatkowo, już gdzies pisałem, u mnie sprawdza się połączenie lokalnego LLM z dużym modelem. Należy to uzupełnić tworząc SKILL'e, czyli dla powtarzalnych zadań niech sobie zrobi notatki. Jak zapuścić kompilator, jak zrobić deploy. Oszczędza sporo czasu i tokenów.

@piotrpo ja już dawno doszedłem do wniosku, że z AI masz wszystko dokładnie tak, jak ze średnio ogarniętym programistą, tylko 10x bardziej.

Więc to faktycznie takie narzędzie które czyni każdego 10x, tylko niekoniecznie w dobrym znaczeniu - jeśli ktoś robi bałagan, z AI będzie go robić 10x bardziej.