Moje środowisko pracy – czyli z czego korzystam na co dzień, pracując z agentami SI

Damian Giebas · 21 października 2026

Wprowadzenie #

Co jakiś czas ktoś pyta mnie, z czego korzystam w pracy: jaki system, jaki edytor, jakie narzędzia SI. Zamiast odpowiadać za każdym razem od nowa, postanowiłem to spisać. Od razu zaznaczę, że nie będzie tu rankingu najlepszych narzędzi ani poradnika konfiguracji. Opisuję po prostu, czym pracuję na co dzień, i krótko komentuję, dlaczego właśnie tym. Najpierw system i podstawowe narzędzia, potem narzędzia typowo programistyczne, a na koniec SI i harnessy, które dziś zajmują mi najwięcej uwagi.

System i podstawowe narzędzia #

Ubuntu z GNOME #

Pracuję na Ubuntu 26.04 LTS z domyślnym środowiskiem GNOME. Nic wymyślnego, żadnego Archa, żadnego ręcznie składanego menedżera okien. Jestem wielkim fanem open source, ale od systemu oczekuję przede wszystkim tego, że po aktualizacji rano się uruchomi i będę mógł usiąść do pracy. Wersje LTS to zapewniają, a ja wolę poświęcić czas na projekty niż na konfigurowanie pulpitu.

Terminal: Tilix i fish #

W terminalu spędzam większość dnia. Korzystam z Tilixa, emulatora terminala, który dzieli jedno okno na kilka paneli, w pionie i w poziomie co znacznie ułatwia pracę, szczególnie na monitorze ultra-wide. Przy pracy z agentami SI to bardzo wygodne: w jednym panelu pracuje agent, w drugim mam testy, a w trzecim podgląd logów aplikacji.

W terminalu działa powłoka fish. Fish ma od razu podpowiedzi na podstawie historii, kolorowanie składni i rozsądne domyślne ustawienia, i to bez kilkuset linii konfiguracji, jak to bywa z zsh. Wadą jest to, że jego składnia różni się od basha, więc skrypty znalezione w internecie czasem trzeba przepisać. Ale od tego mamy teraz agentów prawda? Jest więc to dla mnie akceptowalna cena.

Drobiazgi, bez których byłoby mi ciężko #

Narzędzia typowo programistyczne #

Kontrola wersji: git i jj #

Z ciekawości policzyłem, jakich poleceń używam najczęściej. Na pierwszym miejscu, z ogromną przewagą, jest git: ponad 4 tysiące wywołań w historii powłoki. Na drugim jj, czyli Jujutsu, system kontroli wersji kompatybilny z gitem, z którego korzystam w coraz większej liczbie projektów. Jujutsu nie ma osobnego „staging area”, każda zmiana w plikach od razu jest częścią bieżącej zmiany, a cofanie i przepisywanie historii jest dużo prostsze niż w gicie. Na początku trudno się do tego przyzwyczaić, ale potem powrót do git rebase -i boli.

Do tego gh i glab, czyli klienty GitHuba i GitLaba w terminalu, bo pracuję z repozytoriami na obu platformach.

Commity, które piszę sam, przechodzą przez better-commits. To interaktywny kreator w terminalu, który prowadzi przez kolejne pola wiadomości w formacie Conventional Commits: typ zmiany, zakres, numer zadania, tytuł, opis i informację o zmianach łamiących zgodność. Typ i numer zadania potrafi odczytać z nazwy brancha, więc przy dobrze nazwanym branchu większość pól jest wypełniona, zanim w ogóle zacznę pisać. Bardzo dobre narzędzie, a historia commitów w projekcie od razu wygląda porządniej.

Języki: Python i trochę Rusta #

Mój główny język to Python, a w nim Django, FastAPI i Flask. Zależnościami zarządzam przez Poetry, a w nowszych projektach coraz częściej przez uv, który jest po prostu szybszy. Wersje Pythona trzymam w pyenv, a wersje Node.js w nvm, bo frontend też czasem trzeba uruchomić. W zestawieniu najczęstszych poleceń zaraz za gitem są make, poetry, docker i uv, bo zajmuję się głównie backendem w Pythonie.

Prywatnie piszę też w Rust i Go, głównie w projektach hobbystycznych. Cargo jest w pierwszej dwudziestce moich najczęstszych poleceń, więc chyba nie jest to już takie „od czasu do czasu”.

Edytory: PyCharm, Zed i spółka #

Edytorem do większych projektów jest PyCharm Professional, a do baz danych DataGrip, oba od JetBrains. Obok nich korzystam z Zeda, edytora napisanego w Ruście, który uruchamia się w ułamku sekundy i nie zjada pamięci tak jak edytory oparte na Electronie. Do szybkich zmian sięgam też po VS Code albo zwykłego vima w terminalu.

Uczciwie przyznam, że im więcej pracuję z agentami SI, tym rzadziej otwieram ciężkie IDE. Coraz częściej to agent pisze kod, a ja go czytam i oceniam. Do czytania różnic w kodzie wystarcza lekki edytor albo terminal.

Infrastruktura: Docker, chmura i Kubernetes #

Prawie każdy projekt uruchamiam lokalnie w Dockerze, często przez docker compose. Dzięki temu baza danych, kolejka czy cache działają tak samo u mnie, u kolegi z zespołu i na serwerze. Do chmury mam w terminalu klienty AWS i Azure, a infrastrukturę opisuję w Terraformie. Tam, gdzie aplikacje działają w Kubernetesie, korzystam z kubectl i helm.

Nie jestem DevOpsem i nie udaję, że nim jestem. Ale programista backendu, który nie umie sam sprawdzić, dlaczego jego aplikacja nie wstała na środowisku testowym, traci mnóstwo czasu na czekanie na innych.

SI i harnessy #

Czym jest harness? #

Zanim przejdę do narzędzi, jedno pojęcie. Sam model językowy tylko generuje tekst. Żeby mógł czytać pliki, uruchamiać polecenia i wprowadzać zmiany w kodzie, potrzebuje „uprzęży”, po angielsku harness. To program, który daje modelowi narzędzia, pilnuje uprawnień i prowadzi pętlę: model proponuje krok, harness go wykonuje, model widzi wynik i decyduje, co dalej. Claude Code, OpenCode, Codex czy Gemini CLI to właśnie harnessy.

Claude Code w centrum #

Moim głównym harnessem jest Claude Code, agent SI działający w terminalu, który czyta kod, uruchamia polecenia, pisze testy i wprowadza zmiany. O samym Claude i firmie Anthropic pisałem więcej we wpisie „Świat SI poza ChatGPT”.

Kilka rzeczy, dzięki którym to u mnie działa w codziennej pracy, a nie tylko „robi wrażenie na demo”:

OpenCode, czyli harness niezależny od jednej firmy #

Drugim harnessem, z którego korzystam bardzo dużo, jest OpenCode. To otwartoźródłowy agent w terminalu, który działa podobnie jak Claude Code, ale nie jest przywiązany do modeli jednej firmy. Podpinam do niego dowolnego dostawcę, a u mnie są to głównie chińskie modele GLM od Zhipu AI i Qwen od Alibaby, udostępniane przez Ollamę. O tym, jak szybko te modele doganiają amerykańską czołówkę, pisałem we wpisie o świecie SI poza ChatGPT, a OpenCode to dla mnie najprostszy sposób, żeby sprawdzić to w codziennej pracy nad własnymi projektami, a nie tylko w benchmarkach.

OpenCode korzysta u mnie z tego samego zaplecza co Claude Code: te same komendy OpenSpec, wtyczkę RTK skracającą wyjście poleceń i dostęp do GitHuba przez MCP. Dzięki temu mogę dać to samo zadanie dwóm harnessom z różnymi modelami i porównać wyniki, bez przepisywania całego procesu od nowa.

Jev, czyli model do podejmowania decyzji #

Do obu harnessów mam podpiętego Jeva od firmy TypeSafe. Jev nie służy do rozmowy. Dostaje dane i konkretne pytanie, a odpowiada etykietą, „tak” lub „nie”, oceną albo rankingiem, zawsze z prawdopodobieństwem i nigdy w formie wypracowania. Agent przez cały dzień podejmuje drobne decyzje tego typu: które z kilkudziesięciu błędów w CI są prawdziwe, które pliki odpowiadają na pytanie, czy pull request robi to, co obiecuje jego opis, jak poważna jest dana uwaga z review. Zwykle robi to „na oko” albo wołając za każdym razem duży, drogi model. Jev odpowiada w kilkaset milisekund, a do tego zwraca liczbę, na której można oprzeć dalsze kroki, zamiast zdania, które trzeba jeszcze zinterpretować.

U mnie Jev jest podpięty do OpenCode przez MCP (paczka jev-code). Agent dostaje od niego pięć narzędzi (klasyfikację, sprawdzenie, ocenę, ranking i pytanie) oraz skill, który podpowiada, kiedy w ogóle warto po nie sięgnąć.

Codex, Gemini i lokalne modele #

Poza Claude Code i OpenCode mam też Codex od OpenAI i Gemini CLI od Google. Modele różnych firm mylą się w różnych miejscach, więc przy ważniejszych zmianach jeden model pisze plan albo kod, a model innej firmy go krytykuje. Zgodnie z tym, co pisałem wcześniej, do sumiennej, rzemieślniczej roboty sięgam po Claude, a gdy potrzebuję świeżego spojrzenia, po modele OpenAI.

Ollama służy mi do dwóch rzeczy. Pierwsza to lokalne modele do eksperymentów i zadań, w których dane nie powinny wychodzić poza mój komputer. Nie dorównują czołowym modelom, ale do prostych zadań i nauki w zupełności wystarczają. Druga to modele chmurowe Ollamy, czyli duże modele typu GLM czy Qwen, których nie uruchomię na domowym sprzęcie, ale które działają przez to samo, lokalne API. To z nich korzysta mój OpenCode.

Nakładki na harnessy: T3 Code i Agent Orchestrator #

Z jednym agentem w jednym terminalu sprawa jest prosta. Gorzej, gdy kilku agentów pracuje naraz w kilku projektach i trzeba pilnować, co który robi. Obecnie testujemy narzędzia do takiej pracy, a dwa z nich zostały u mnie na dłużej.

T3 Code to, jak sami autorzy go nazywają, „panel sterowania harnessami”. Sam nie jest agentem, tylko korzysta z tych, które już masz zainstalowane i zalogowane: Claude Code, Codex, OpenCode i kilku innych. Daje do nich jedną aplikację desktopową, wersję w przeglądarce i aplikację na telefon, więc sesję rozpoczętą przy biurku można podejrzeć albo popchnąć dalej z kanapy. Kod jest otwarty, a autorzy piszą wprost, że niczego nie sprzedają.

Agent Orchestrator idzie krok dalej. Każde zadanie dostaje w nim osobnego agenta i osobną kopię repozytorium (tzw. git worktree), więc kilku agentów może pracować równolegle i nie wchodzić sobie w drogę. Całość widać na tablicy Kanban: którzy agenci pracują, jakie otworzyli pull requesty, jak wygląda CI i co napisali recenzenci. Gdy CI się wyłoży albo w review pojawi się komentarz, informacja wraca do właściwego agenta, a nie do mnie.

Oba narzędzia są młode i szybko się zmieniają, więc nie traktuję ich jeszcze jako fundamentu.

Czego się nauczyłem, pracując z agentami #

Na koniec trzy wnioski.

Po pierwsze: agent nie zwalnia z myślenia. Agent potrafi z pełnym przekonaniem napisać „naprawione, testy przechodzą”, nie uruchamiając żadnego testu. Dlatego zasada „najpierw dowód, potem stwierdzenie” jest u mnie pierwsza na liście i dotyczy tak samo agenta, jak i mnie.

Po drugie: im mniejszy krok, tym lepiej. Jedna zmiana to jeden logiczny kawałek pracy. Agent, który dostał zadanie „zrób wszystko”, zwykle robi wszystko trochę źle.

Po trzecie: kopie bezpieczeństwa i kontrola wersji to nie opcja. Agent ma dostęp do plików i potrafi je usuwać. Jeśli coś pójdzie nie tak, ratuje mnie historia w jj albo w gicie, i dlatego tak często ich używam.

Podsumowanie #

Moje środowisko pracy to w gruncie rzeczy nudny fundament (Ubuntu, Tilix, git, Python i Docker), na którym stoją agenci SI i narzędzia do zarządzania nimi. Nudny fundament jest tu zaletą: im mniej rzeczy psuje się pod spodem, tym więcej uwagi mogę poświęcić pracy z agentami. A ta zmienia się tak szybko, że za pół roku pewnie ten wpis będzie trzeba zaktualizować.

Jeśli korzystasz z czegoś, co twoim zdaniem powinienem sprawdzić, daj znać, chętnie przetestuję.

Źródła #

  1. Ubuntu: https://ubuntu.com/
  2. Tilix: https://gnunn1.github.io/tilix-web/
  3. fish shell: https://fishshell.com/
  4. CopyQ: https://hluk.github.io/CopyQ/
  5. KeePassXC: https://keepassxc.org/
  6. Nextcloud: https://nextcloud.com/
  7. Obsidian: https://obsidian.md/
  8. Jujutsu (jj): https://jj-vcs.github.io/jj/
  9. better-commits: https://github.com/Everduin94/better-commits
  10. Poetry: https://python-poetry.org/
  11. uv: https://docs.astral.sh/uv/
  12. PyCharm: https://www.jetbrains.com/pycharm/
  13. DataGrip: https://www.jetbrains.com/datagrip/
  14. Zed: https://zed.dev/
  15. Docker: https://www.docker.com/
  16. Terraform: https://developer.hashicorp.com/terraform
  17. Claude Code: https://docs.anthropic.com/en/docs/claude-code/overview
  18. OpenAI Codex: https://openai.com/codex/
  19. Gemini CLI: https://github.com/google-gemini/gemini-cli
  20. RTK: https://github.com/rtk-ai/rtk
  21. Caveman: https://github.com/JuliusBrussee/caveman
  22. Ponytail: https://github.com/DietrichGebert/ponytail
  23. OpenSpec: https://github.com/Fission-AI/OpenSpec
  24. Ollama: https://ollama.com/
  25. OpenCode: https://opencode.ai/
  26. Jev (TypeSafe): https://typesafe.ai/
  27. jev-code: https://github.com/FrancoisChastel/jev-code
  28. T3 Code: https://t3.codes/ (kod: https://github.com/pingdotgg/t3code)
  29. Agent Orchestrator: https://github.com/Untrivial-ai/agent-orchestrator

← Wróć do listy wpisów