Wstep

Jednym z największych problemów w codziennej pracy programisty jest ciągłe przełączanie kontekstu – raz edytor, raz terminal, potem dokumentacja, przeglądarka, a czasem jeszcze Slack czy e-mail. Każde takie „skakanie” wybija z rytmu i zabiera skupienie. Ile razy zdarzyło Ci się zapomnieć, nad czym właśnie pracowałeś, bo musiałeś sprawdzić składnię polecenia git rebase albo znaleźć rozwiązanie na Stack Overflow? Właśnie ten problem próbuje rozwiązać Gemini CLI – nowe narzędzie od Google, które wprowadza inteligentnego asystenta bezpośrednio do terminala, tam gdzie i tak spędzasz większość dnia.

Gemini CLI to nie kolejny generator kodu, ale asystent, który faktycznie rozumie kontekst Twojej pracy. Potrafi czytać pliki, analizować błędy, generować klasy, refaktoryzować kod, pisać testy i to wszystko w naturalnym języku, bez wychodzenia z terminala. W tym wpisie pokażę Ci, jak szybko uruchomić i skonfigurować Gemini CLI, a potem wykorzystać je w praktyce na przykładzie projektu Spring Boot. Pokażę też, jak może realnie pomóc w codziennej pracy i jak wypada na tle innych podobnych narzędzi.

Czym tak naprawdę jest Gemini CLI?

Na pierwszy rzut oka Gemini CLI wygląda jak kolejny interfejs do rozmowy z modelem językowym w terminalu. Wpisujesz pytanie, dostajesz odpowiedź – proste. Ale jeśli zatrzymasz się na chwilę, zobaczysz, że to narzędzie działa zupełnie inaczej niż klasyczny chatbot.

Google określa Gemini CLI jako eksperymentalny interfejs wiersza poleceń, który pozwala korzystać z możliwości modeli Gemini bezpośrednio w Twoim środowisku developerskim – bez przeglądarki, bez wtyczek, bez przełączania kontekstu.

Sednem działania Gemini CLI jest pętla „Pomyśl → Działaj → Obserwuj” (Think → Act → Observe). To właśnie ten mechanizm sprawia, że narzędzie potrafi realnie pracować z Twoim kodem, a nie tylko go komentować.

• Pomyśl (Think) – Gemini analizuje Twoje polecenie napisane w języku naturalnym, bierze pod uwagę kontekst projektu (np. pliki, które wskazałeś, zawartość GEMINI.md, wcześniejsze interakcje) i planuje, co dokładnie powinno się wydarzyć.
• Działaj (Act) – wykonuje zaplanowane kroki, korzystając z wbudowanych lub własnych narzędzi. Może odczytać plik, wykonać polecenie powłoki (git status, mvn clean install), przeszukać kod albo nawet zmodyfikować fragment klasy.
• Obserwuj (Observe) – analizuje wyniki, np. output z terminala czy zawartość pliku, i na tej podstawie podejmuje kolejne decyzje lub przygotowuje końcową odpowiedź.

Ta pętla pozwala Gemini CLI na rozwiązywanie bardziej skomplikowanych problemów niż tylko proste odpowiadanie na pytania. Narzędzie aktywnie współpracuje z Twoim systemem plików i powłoką, działając bardziej jak inteligentny agent niż pasywny rozmówca.

Infrastruktura jako Konwersacja

Tradycyjnie, gdy mówimy o automatyzacji infrastruktury, myślimy o podejściu „Infrastructure as Code” (IaC) – czyli definiowaniu wszystkiego za pomocą plików konfiguracyjnych, takich jak Terraform, Ansible czy CloudFormation.
To działa świetnie, ale wymaga znajomości składni, modułów, zależności i często kończy się wertowaniem dokumentacji, żeby przypomnieć sobie nazwę konkretnego parametru.

Gemini CLI idzie krok dalej i proponuje coś, co Google nazywa „Infrastrukturą jako Konwersacją” (Infrastructure as Conversation). Zamiast pisać długie skrypty, po prostu mówisz, co chcesz zrobić – tak jakbyś tłumaczył to koledze z zespołu.

Przykład z życia: zamiast tworzyć basha z find i sed, możesz napisać w terminalu:

„Znajdź w całym projekcie wystąpienia funkcji staraMetoda i zamień ją na nowaMetoda w plikach .java.”

Gemini CLI sam znajdzie odpowiednie pliki, pokaże Ci diff i zaproponuje wykonanie zmian. Ty tylko akceptujesz albo poprawiasz – zero kombinowania ze składnią, zero grep-ów i xargs.

To podejście ma duży sens w codziennej pracy. Nie zastępuje klasycznego IaC, ale uzupełnia je, pozwalając szybciej wykonywać jednorazowe, eksploracyjne zadania. Świetnie sprawdza się w momentach, gdy chcesz coś „ogarnąć na szybko”, ale nie pamiętasz dokładnej komendy lub nie chcesz tworzyć kolejnego skryptu tylko po to, żeby zmienić kilka linii w projekcie.

Co wyróżnica Gemini CLI?

Gemini CLI nie jest tylko kolejnym terminalowym „chatem z modelem”. To narzędzie, które zostało zbudowane tak, żeby realnie dało się z niego korzystać w codziennej pracy programisty. Kilka rzeczy naprawdę robi tu różnicę:

1. Open Source – Kod źródłowy Gemini CLI jest publicznie dostępny na GitHubie. Oznacza to transparentność, możliwość zgłaszania błędów, proponowania ulepszeń, a nawet tworzenia własnych forków i modyfikacji. Społeczność może aktywnie uczestniczyć w rozwoju narzędzia.
2. Darmowy plan – Google oferuje hojny darmowy plan w ramach Gemini API, który w większości przypadków jest w zupełności wystarczający do codziennej pracy indywidualnego programisty (limit zapytań do 60 na minutę i 1000 na dzień). Oczywiście, istnieją płatne opcje dla bardziej wymagających zastosowań, ale nam sam początek ten darmowy powinien być w zupełności wystarczający.
3. Model Gemini – Narzędzie napędzane jest przez jedne z najbardziej zaawansowanych modeli językowych od Google – Gemini Pro (dostęp do okna kontekstowego do 1 miliona tokenów). Zapewnia to wysoką jakość rozumienia języka naturalnego, generowania kodu i planowania złożonych zadań
4. Rozszerzalność – Gemini CLI zostało zaprojektowane z myślą o rozszerzalności. Dzięki Model Context Protocol i systemowi Extensions, deweloperzy mogą tworzyć własne narzędzia i integracje, dostosowując Gemini CLI do specyficznych potrzeb projektów czy przepływów pracy. Można na przykład dodać narzędzie do interakcji z firmowym systemem CI/CD czy specyficzną bazą danych.

Pierwsze kroki – Instalacja i konfiguracja w 5 minut

Uruchomienie Gemini CLI jest naprawdę szybkie i proste. Jeśli masz już zainstalowane środowisko Node.js, cały proces nie powinien zająć więcej niż kilka minut.

Wymagania

Jedynym wymaganiem jest posiadanie zainstalowanego Node.js w wersji 20 lub nowszej (wraz z menedżerem pakietów npm). Możesz sprawdzić swoją wersję, wpisując w terminalu:

node -v
npm -v

Instalacja

Najprościej jest sobie dodać paczkę gemini globalnie do npm. Możemy to zrobić wywołując poniższą komende:

npm install -g @google/gemini-cli

Po zakończeniu instalacji, polecenie gemini będzie dostępne bezpośrednio w Twoim terminalu z dowolnego miejsca.

Autoryzacja z Google

Zanim jeszcze zaczniemy prace z Gemini CLI potrzebujemy zautoryzować konto w Google.

Na początek wpisz w terminalu komendę gemini. Po uruchomieniu powinno Ci się wyświetlić poniższe okno:

Mając to okno mamy 3 opcje do wyboru do autoryzacji. Najprościej będzie to zrobić przez zalogowanie się do konta Google.

Po wybraniu pierwszej opcji zostaniesz przekierowany na stronę Google w celu autoryzacji. Po pomyślnej autoryzacji w przeglądarce, wróć do terminala. Gemini CLI powinno automatycznie wykryć pomyślną autoryzację. Od teraz możesz już korzystać z Gemini CLI lokalnie.

Weryfikacja instalacji

Po pomyślnym zalogowaniu wszystko powinno już działać poprawnie.
Sprawdźmy więc, czy Gemini faktycznie reaguje na polecenia – spróbujmy utworzyć prosty plik tekstowy w naszym systemie:

Utwórz mi plik tekstowy zawierający losowe zdanie. Cytat wybierz sam.

W odpowiedzi dostajemy prośbę od o autoryzację do stworzenia pliku:

Możesz jednorazowo zaakceptować utworzenie pliku albo ustawić stałą zgodę na takie operacje – wybór zostawiam już Tobie.

Po autoryzacji gemini powinien nam utworzyć plik random_sentence.txt w bieżącym katalogu. Pamiętaj, że AI nie jest deterministyczne, więc u Ciebie może być inna nazwa, ale zawsze możesz w poleceniu wymusić nazwę pliku jaką chcesz utworzyć.

Jeśli byśmy chcieli jeszcze sprawdzić jaką obecnie mamy wersję zainstalowaną gemini w systemie, to po wejściu do terminala wystarczy, że wpiszemy poniższą komendę

gemini --version

Podstawy pracy z Gemini CLI

Teraz, gdy masz już zainstalowane i skonfigurowane Gemini CLI, czas poznać podstawy jego działania. Narzędzie oferuje dwa główne tryby interakcji: tryb pojedynczej komendy oraz tryb interaktywny.

Tryb pojedynczej komendy (Single-shot)

Jest to podstawowy sposób wywołania, gdzie każde zadanie rozpoczynasz od gemini, podajesz prompt i ewentualne pliki, a po uzyskaniu odpowiedzi wracasz do standardowej powłoki systemowej.

Przykładowo chcemy znaleźć wszystkie główne cechy dla Javy 21:

Jak pewnie zauważyłeś, ten tryb jest mało czytelny. Co więcej, jeśli zechcesz rozwinąć temat, nie będzie to możliwe – kolejne polecenie, np. „powiedz mi coś więcej o tych cechach”, nie zadziała, bo Gemini nie zna już wcześniejszego kontekstu. Tyle co pracowałem z Gemini CLI to bardzo rzadko stosuję tą wersję. Jak już zaczynam coś robić to zawsze wchodzę w ten drugi tryb.

Ten tryb sprawdza się głównie wtedy, gdy chcesz szybko wykonać pojedyncze polecenie lub przetestować, jak narzędzie reaguje na proste instrukcje.

Tryb interaktywny (Interactive Session)

Uruchamiasz go, wpisując samo gemini i naciskając Enter. Narzędzie pozostaje aktywne, prezentując własny znak zachęty (>), i utrzymuje kontekst rozmowy między poleceniami. W tym trybie nie musisz powtarzać gemini przed każdym pytaniem. Jest to znacznie wygodniejsze przy złożonych zadaniach i eksploracji.

To teraz zróbmy ten sam przykład co wcześniej z Java 21 tylko dla tego trybu:

Jak widać mamy kontekst zachowany, a dodatkowo nie mamy samej ściany tekstu, a tekst, który jest odpowiednio sformatowany – oczywiście jak na możliwości konsoli.

Osobiście polecam tę wersję – odpowiedzi są zauważalnie szybsze, a pracując nad jednym projektem, łatwiej zachować pełny kontekst. W dalszej części wpisu również będziemy zakładać pracę w trybie interaktywnym, ponieważ najlepiej oddaje on konwersacyjny charakter narzędzia i zwykle jest po prostu wygodniejszy w codziennym użyciu.

Składnia poleceń w trybie interaktywnym

Pracując w sesji interaktywnej (po znaku zachęty >), składnia jest uproszczona:

> <PROMPT> [REFERENCJE_DO_PLIKÓW...] [-- <KOMENDY_POWŁOKI...>]

• <PROMPT> – Twoje polecenie lub pytanie w języku naturalnym (już bez cudzysłowów, chyba że są częścią samego polecenia).
• [REFERENCJE_DO_PLIKÓW...] – Ścieżki do plików, które mają być uwzględnione w kontekście. Możesz użyć @ przed ścieżką (np. @src/main/MyClass.java) dla jawnego wskazania, że to plik. Gemini wtedy dodatkowo zaczyna podpowiadać foldery i pliki.
• [-- <KOMENDY_POWŁOKI...>] – Podobnie jak w trybie pojedynczej komendy, możesz przekazać output z komend powłoki (poprzedzając je podwójnym myślnikiem, jeśli narzędzie tego wymaga w danym kontekście).

Poniżej kilka przykładów:

> Jaka jest różnica między List a Set w Javie?
> Znajdź potencjalne błędy w @src/main/java/com/example/UserService.java
> Zrefaktoryzuj tę pętlę for w pliku @src/utils/DataProcessor.java aby używała Stream API
> Znajdź wszystkie wystąpienia 'TODO:' w plikach .java w katalogu src/main
> Opisz co oznaczają te zmiany -- git status

Odkrywanie dostępnych funkcji: komenda /help

Pracując w trybie interaktywnym, możesz w każdej chwili uzyskać pomoc dotyczącą dostępnych funkcji i specjalnych komend. Wystarczy wpisać:

> /help

Gemini CLI wyświetli listę dostępnych komend wewnętrznych (zazwyczaj zaczynających się od /, jak /exit czy /help), opis składni, a czasem także informacje o załadowanych rozszerzeniach czy dostępnych narzędziach. Jest to świetny sposób, aby szybko dowiedzieć się, co jeszcze potrafi narzędzie i jak z niego efektywniej korzystać.

Przegląd wbudowanych narzędzi

Prawdziwa siła Gemini CLI tkwi w tym, że potrafi realnie współpracować z Twoim środowiskiem, korzystając z wbudowanych narzędzi. To właśnie one pozwalają mu nie tylko „rozmawiać”, ale też wykonywać konkretne akcje w projekcie.

Domyślnie dostępnych jest kilka podstawowych modułów:

• Odczyt plików (file_reader) – umożliwia wgląd w zawartość lokalnych plików, np. gdy wskazujesz coś w stylu @plik.txt.
• Wyszukiwanie (code_search, file_search) – pozwala przeszukiwać projekt, np. „znajdź definicję metody calculateTotal”.
• Edycja plików (code_editor) –-służy do modyfikowania lub tworzenia nowych plików. Gemini może zaproponować konkretne zmiany, a Ty decydujesz, czy je zatwierdzić.
• Polecenia powłoki (shell) – wykonuje komendy w Twoim systemie (bash, zsh, PowerShell itp.), zawsze po Twojej akceptacji.
• Dostęp do sieci (network) – pozwala np. pobrać zawartość strony lub sprawdzić odpowiedź z API (choć ten moduł ma pewne ograniczenia bezpieczeństwa).

Dzięki temu Gemini CLI nie jest tylko tekstowym interfejsem do modelu językowego, ale aktywnym asystentem, który potrafi działać w Twoim środowisku dokładnie tak, jak doświadczony członek zespołu.

Mechanizm bezpieczeństwa

Mechanizm HITL (Human-in-the-Loop) działa tak samo w obu trybach. Za każdym razem, gdy Gemini CLI planuje wykonać potencjalnie niebezpieczną operację – np. zmodyfikować plik lub uruchomić komendę systemową – najpierw:

• Prezentuje plan – pokazuje dokładnie, co zamierza zrobić (np. komendę, diff zmian lub podgląd edycji).
• Prosi o zgodę – czeka na Twoje potwierdzenie. Dostajesz 4 opcje do wyboru:
  • Tak, pozwól raz
  • Tak, zawsze pozwalaj
  • Zmodyfikuj przy użyciu zewnętrznego edytora
  • Nie, zasugeruj zmiany (esc)

Dzięki temu nawet w trybie interaktywnym zawsze zachowujesz pełną kontrolę nad tym, co dzieje się w Twoim systemie. Warto jednak każdorazowo przejrzeć proponowane akcje, zanim je zatwierdzisz.

W punkcie z weryfikacją instalacji pokazywałem jak to przykładowo działa. Ale na przykład chcielibyśmy tam dołożyć 10 nowych cytatów:

To gemini nas zapyta czy na pewno chcemy to zrobić. Tak więc, niezależnie czy jest tworzony nowy plik czy też go aktualizujemy gemini nas pyta a potwierdzenie takowej akcji.

Gemini CLI w praktyce – praca z projektem

Teoria jest ważna, ale prawdziwą wartość Gemini CLI zobaczymy dopiero w działaniu. Prześledźmy kilka typowych scenariuszy, w których to narzędzie może znacząco usprawnić pracę.

Stworzyłem na te potrzeby prostą aplikację typu CRUD, gdzie możemy wykonywać proste zapytania API do dodawania, usuwania, aktualizowania i pobierania użytkowników – cały kod znajdziesz w repozytorium na GitHubie pod tym linkiem.

Zrozumienie kodu

Na początek chcemy sprawdzić, jakie serwisy odpowiadają za logikę biznesową aplikacji.
Pobraliśmy nowy projekt i chcemy szybko zorientować się, jak wygląda jego struktura i za co konkretnie odpowiada.
Zamiast otwierać IDE i przeklikiwać się przez kolejne pakiety, możemy po prostu zapytać Gemini CLI:

> Wymień mi klasy *service.java zawarte w projekcie i następnie wyjaśnij mi co one mogą robić

W odpowiedzi Gemini znalazł jedną klasę serwisową i od razu opisał wszystkie metody, które się w niej znajdują:

Taki sposób pracy świetnie sprawdza się przy onboardingu do nowego projektu – w kilka sekund możesz poznać strukturę aplikacji i zrozumieć, gdzie znajduje się logika biznesowa.
Nie musisz przeklikiwać się przez dziesiątki plików – Gemini robi to za Ciebie, a Ty możesz od razu przejść do analizy konkretnego fragmentu kodu.

Teraz możemy iść dalej z naszym przykładem. Przykładowo zainteresowała nas metoda create i chcielibyśmy poznać jej strukturę wraz z tym co dokładnie ten kod robi:

> Wypisz mi cała metodę 'create' z klasy  @src/main/java/pl/uprogramisty/demoapp/user/UserService.java. a następnie krok po kroku wyjaśnij mi co ona robi

W odpowiedzi dostajemy rozbudowany opis całej metody:

Jest to oczywiście dość prosta metodą i nie widać tutaj pełnego potencjału, ale w przypadku dużych, nieczytelnych metod może się to okazać bardzo pomocne.

Generowanie kodu

Po analizie kodu chcielibyśmy teraz dodać nową metodą do serwisu UserService, która miałaby za zadanie wyszukiwania użytkownika po adresie email oraz tą przygotowaną metodę chcielibyśmy wystawić na api.

Tak, więc przygotowujemy naszego prompta:

> Chcę dodać możliwość wyszukiwania użytkownika po emailu.
1. Do interfejsu @src/main/java/pl/uprogramisty/demoapp/user/UserRepository.java dodaj metodę 'findByEmail(String email)' zwracającą Optional<User>.
2. Do klasy @src/main/java/pl/uprogramisty/demoapp/user/UserService.java dodaj publiczną metodę 'findByEmail(String email)', która wywoła nową metodę repozytorium, zmapuje wynik na UserResponse i rzuci EntityNotFoundException, jeśli użytkownik nie zostanie znaleziony. Oznacz ją @Transactional(readOnly = true).
3. Do klasy @src/main/java/pl/uprogramisty/demoapp/user/UserController.java dodaj nowy endpoint GET obsługujący ścieżkę '/by-email/{email}', który wywoła nową metodę serwisu i zwróci UserResponse.

Na początku gemini zapytał mnie o możliwość aktualizacji pliku UserService:

Wszystko wygląda prawidłowo to akceptuje zmiany.

W następnej kolejności zostałem zapytany o zmiany w pliku UserController:

Oczywiście też akceptuję po weryfikacji.

Tym sposobem gemini zakończył swoją pracę… Ale co z UserRepository i dodaniem tam metody do wyszukiwania po emailu? Gemini CLI jest na tyle inteligentne, że jest wstanie wykryć, że taka metoda już istnieje i nie ma sensu jej dodawać. W odpowiedzi po zakończonym przetwarzaniu dostajemy informację zwrotną co gemini nam wykonało albo dlaczego pominął jakiś krok:

Tworzenie testów

Na koniec chcielibyśmy przygotować testy pod naszą nową metodę. W przykładzie skupmy się na przetestowaniu tylko warstwy serwisowej – chciałbym się tu skupić głównie na pokazaniu działania samego narzędzia, a nie na robieniu pełnych testów.

Przygotujmy naszego prompta pod przygotowanie testów:

> Chciałbym dla metody 'findByEmail' z klasy @src/main/java/pl/uprogramisty/demoapp/user/UserService.java  przygotować testy jednostkowe. Przygotuj 2 testy po jednym dla pozytywnej i negatywnej ścieżki  

W odpowiedzi dostajemy do akceptacji gotowe wygenerowane testy:

Po akceptacji dostajemy informacje, że plik z testami został utworzony wraz z informacją jakie testy zostały przygotowane.

Dostosowanie Gemini CLI do swojego projektu – plik GEMINI.md

Jedną z ciekawszych funkcji Gemini CLI jest możliwość dostosowania jego zachowania do konkretnego projektu za pomocą pliku konfiguracyjnego GEMINI.md.
To coś w rodzaju „konstytucji projektu” – dokumentu, który opisuje zasady, styl kodowania i ogólne wytyczne, jakimi Gemini powinno się kierować podczas pracy w danym repozytorium. Dzięki temu narzędzie rozumie nie tylko kod, ale też kontekst projektu i może działać zgodnie z Twoimi zasadami, a nie ogólnymi domyślnymi ustawieniami.

Rola pliku GEMINI.md

Plik GEMINI.md pełni rolę kontekstowego przewodnika dla Gemini CLI w obrębie konkretnego projektu. Można traktować go jak „instrukcję obsługi” repozytorium – opisującą zasady, architekturę i sposób pracy, jaki model powinien uwzględniać podczas interakcji. Dzięki temu Gemini działa w zgodzie z Twoim stylem i konwencjami, zamiast opierać się wyłącznie na ogólnej wiedzy.

Umieszczenie tego pliku w projekcie pozwala m.in. na:

• Opisanie specyfiki projektu – np. architektury, stosu technologicznego, głównych modułów czy założeń projektowych.
• Zdefiniowanie standardów kodowania – konwencje nazw, styl formatowania, preferowane biblioteki czy wzorce projektowe.
• Określenie zasad testowania – wskazanie frameworków testowych, poziomu pokrycia czy stylu pisania testów.
• Wyróżnienie kluczowych elementów projektu – np. plików konfiguracyjnych, modeli domenowych, README czy istotnych katalogów.
• Doprecyzowanie stylu komunikacji – możesz zasugerować, by odpowiedzi Gemini były krótsze, bardziej techniczne lub zawierały konkretne przykłady.
• Opisanie przepływów pracy – np. niestandardowych kroków budowania, wdrażania czy integracji.

Dzięki dobrze przygotowanemu plikowi GEMINI.md, asystent staje się dużo skuteczniejszy – rozumie kontekst projektu i potrafi generować kod oraz odpowiedzi spójne z Twoimi zasadami i stylem pracy.

Praktyczny przykład dla aplikacji

Stwórzmy przykładowy plik GEMINI.md jaki można byłoby wrzucić do projektu:

# Wytyczne dla Gemini w tym Projekcie

## Opis Projektu

Jest to aplikacja backendowa zbudowana przy użyciu Spring Boot [np. 3.x], Java [np. 21+], wykorzystująca [np. Spring Data JPA] do interakcji z bazą danych [np. PostgreSQL/H2]. Aplikacja wystawia REST API do [opisz główny cel aplikacji, np. zarządzania zasobami X]. Główne komponenty to kontrolery REST, serwisy (logika biznesowa) i repozytoria (dostęp do danych). Używamy [np. Maven/Gradle] do zarządzania zależnościami i budowania projektu.

## Styl Kodowania i Konwencje

* **Język:** Java [np. 21+]
* **Formatowanie:** Prosimy o stosowanie [np. standardowego formatowania IntelliJ IDEA / Google Java Style Guide]. Długość linii: [np. 120] znaków.
* **Nazewnictwo:**
    * Klasy: PascalCase (`MyService`, `ResourceDto`)
    * Metody i zmienne: camelCase (`processData`, `itemRepository`)
    * Stałe: UPPER\_SNAKE\_CASE (`DEFAULT_TIMEOUT`)
* **Preferencje:**
    * Używaj Stream API i `Optional` tam, gdzie poprawia to czytelność i bezpieczeństwo kodu.
    * Stosuj wstrzykiwanie zależności przez konstruktor (np. z użyciem Lombok `@RequiredArgsConstructor`).
    * Logikę mapowania między encjami a DTO umieszczaj w dedykowanych klasach/metodach mapperów [np. przy użyciu MapStruct lub ręcznie].
    * Oznaczaj metody serwisowe adnotacją `@Transactional` dla operacji modyfikujących i `readOnly = true` dla operacji odczytu.
    * Unikaj zwracania `null` z metod publicznych, preferuj `Optional` lub puste kolekcje.

## Wytyczne dla Testów

* **Framework:** JUnit 5
* **Mockowanie:** Mockito (przez `@Mock` i `@InjectMocks`)
* **Asercje:** AssertJ (preferowane)
* **Nazewnictwo testów:** Stosuj konwencję `metodaTestowana_warunki_oczekiwanyRezultat()` (np. `saveResource_validInput_returnsSavedResourceDto`).
* **Pokrycie kodu:** Dążymy do wysokiego pokrycia kodu dla warstwy serwisowej i kluczowych kontrolerów.
* **Rodzaje testów:** Pisz testy jednostkowe dla serwisów (mockując repozytoria) i kontrolerów (używając `@WebMvcTest`, mockując serwisy). Testy integracyjne (`@SpringBootTest`) powinny być stosowane dla weryfikacji kluczowych przepływów end-to-end.

## Kluczowe Technologie

* Spring Boot [wersja]
* Spring Web (dla REST API)
* Spring Data JPA / Spring JDBC [wybierz odpowiednie]
* [np. PostgreSQL, H2, MySQL] (Baza danych)
* Lombok (jeśli używany)
* [np. Maven / Gradle] (Narzędzie budowania)
* [Inne ważne biblioteki, np. Spring Security, Spring Batch, Kafka/RabbitMQ client]
* JUnit 5, Mockito, AssertJ (Testowanie)

## Ważne Pliki i Pakiety

* `pom.xml` / `build.gradle`: Definicja zależności i budowania.
* `application.properties` / `application.yml`: Główna konfiguracja aplikacji.
* W projekcie została użyta struktura katalogów package by feature
* `README.md`: Podstawowe informacje o projekcie i instrukcje uruchomienia.

## Ton Odpowiedzi

Proszę o udzielanie konkretnych odpowiedzi, dostarczanie przykładów kodu zgodnych z powyższymi wytycznymi i standardami Spring Boot. Generowany kod powinien być czysty, czytelny i zgodny z przyjętymi konwencjami. W przypadku proponowania zmian w istniejącym kodzie, przedstaw je w formie diffa.

Ten szablon możesz skopiować do pliku GEMINI.md w głównym katalogu projektu, a następnie dostosować go do swojej aplikacji – uzupełnić o wersje technologii, nazwy pakietów, używane biblioteki czy własne preferencje dotyczące stylu kodowania.

Hierarchia kontekstu

Gemini CLI obsługuje hierarchię plików GEMINI.md, dzięki czemu możesz precyzyjnie definiować kontekst pracy – od ogólnych zasad po szczegółowe wytyczne dla konkretnych modułów projektu.

• Kontekst globalny – możesz utworzyć plik ~/.GEMINI.md, który będzie używany jako domyślna konfiguracja dla wszystkich projektów.
• Kontekst projektowy – plik GEMINI.md w głównym katalogu projektu (np. app/GEMINI.md) nadpisuje lub uzupełnia ustawienia globalne.
• Kontekst lokalny – plik GEMINI.md umieszczony w podkatalogu (np. app/src/main/java/pl/uprogramisty/demoapp/user/GEMINI.md) może dodatkowo doprecyzować zasady dla danego pakietu, np. user, nadpisując ustawienia z wyższych poziomów.

Gemini automatycznie wykrywa i ładuje odpowiedni plik na podstawie Twojej bieżącej lokalizacji w repozytorium.
To właśnie dzięki tej hierarchii możesz przekształcić ogólny model językowy w asystenta, który naprawdę rozumie Twój projekt – jego strukturę, konwencje i sposób pisania kodu.

Gemini CLI, a inne rozwiązania

Gemini CLI nie jest jedynym narzędziem tego typu na rynku. Warto zestawić je z dwoma największymi konkurentami – Claude Code od Anthropic oraz OpenAI Codex CLI. Każde z tych narzędzi powstało z nieco inną filozofią w tle, co sprawia, że lepiej sprawdzają się w różnych scenariuszach.

Zacznijmy od samego modelu. Gemini CLI działa w oparciu o Gemini 2.5 Pro z ogromnym oknem kontekstowym (do 1 miliona tokenów), co pozwala analizować duże projekty i rozumieć złożone zależności między plikami. Claude Code korzysta z modeli Claude Sonnet 4.5, które świetnie radzą sobie z analizą semantyczną kodu i kontekstu, ale są zamknięte i niedostępne jako open source. Z kolei Codex CLI bazuje na modelu GPT-5 (ale również dostępny jest GPT-5 Codex) i jest bardziej zoptymalizowany pod wykonywanie krótkich komend programistycznych, często lokalnie.

Jeśli chodzi o filozofię – Gemini CLI to projekt open source (licencja Apache 2.0), rozwijany w duchu otwartości i współpracy ze społecznością. Claude Code jest rozwiązaniem zamkniętym, kierowanym głównie do środowisk korporacyjnych, gdzie kluczowe są kwestie bezpieczeństwa i zgodności. Codex CLI również jest open source, ale stawia mocniejszy nacisk na działanie lokalne („local-first”) i elastyczność integracji z modelami OpenAI.

Pod względem kosztów – Gemini CLI oferuje bezpłatny plan dla indywidualnych użytkowników, który w większości przypadków w zupełności wystarczy. Claude Code działa w modelu płatności „pay-as-you-go”, co przy intensywnym użyciu może być droższe. Codex CLI wymaga własnego klucza API OpenAI, więc koszt zależy od tego, z jakiego planu korzystasz.

Jeśli chodzi o kontekst projektu – Gemini wykorzystuje plik GEMINI.md, w którym można opisać zasady i konwencje projektu. Claude ma podobne rozwiązanie w postaci CLAUDE.md, a Codex używa plików codex.md lub agents.md do definiowania reguł pracy modelu.

W kwestii bezpieczeństwa, Gemini CLI stosuje prosty i skuteczny mechanizm Human-in-the-Loop (HITL) – przed każdą potencjalnie ryzykowną operacją (np. edycją pliku czy uruchomieniem komendy) wymaga Twojego potwierdzenia. Claude Code oferuje bardziej rozbudowany system uprawnień, a Codex CLI ma trzy tryby pracy: od pytania o wszystko po pełną automatyzację.

Na koniec – zastosowania. Gemini CLI sprawdza się świetnie przy refaktoryzacjach (dzięki dużemu kontekstowi), projektach z ograniczonym budżetem i oczywiście w pracy w ekosystemie Google. Claude Code będzie lepszy w dużych środowiskach korporacyjnych, gdzie liczy się bezpieczeństwo i jakość generowanego kodu. Codex CLI natomiast to dobra opcja dla tych, którzy wolą lokalne rozwiązania i pełną kontrolę nad danymi.

Podsumowanie

Gemini CLI to narzędzie, które może realnie zmienić sposób, w jaki programiści pracują w terminalu. To nie tylko interfejs do modelu językowego, ale inteligentny asystent, który rozumie kontekst projektu, potrafi wykonywać komendy systemowe, analizować kod i pomagać w codziennych zadaniach – od refaktoryzacji po generowanie testów. Działa bezpośrednio w wierszu poleceń, więc nie musisz już skakać między IDE, dokumentacją i przeglądarką.

Dla kogo jest Gemini CLI?

• Dla programistów, którzy większość czasu spędzają w terminalu i chcą ograniczyć przełączanie kontekstu.
• Dla osób, które chcą szybciej analizować, generować i testować kod w dowolnym języku programowania.
• Dla DevOpsów i administratorów, którym zależy na naturalnej interakcji z infrastrukturą i automatyzacji procesów.
• Dla tych, którzy lubią rozszerzać i dostosowywać narzędzia pod własny sposób pracy – Gemini CLI jest open source i bardzo elastyczny.

Jak każde narzędzie, wymaga chwili nauki i świadomego podejścia, ale warto dać mu szansę. Instalacja zajmuje kilka minut, a darmowy plan pozwala spokojnie przetestować jego możliwości.

A jakie są Twoje pierwsze wrażenia lub doświadczenia z Gemini CLI? Czy widzisz potencjał tego narzędzia w swojej codziennej pracy? Podziel się swoimi przemyśleniami w komentarzu poniżej!