Aider, programowanie z AI w terminalu

Aider, programowanie z AI w terminalu

Aider to narzędzie wiersza poleceń, które zmienia pliki w Twoim repozytorium na podstawie tego, co mu napiszesz, i po każdej zmianie robi commit z opisem. Nie zmienia edytora, nie wymaga rozszerzenia i nie wiąże Cię z jednym dostawcą modeli.

To ostatnie odróżnia je od większości konkurencji w tej kategorii. Podajesz klucz do dowolnego dostawcy albo wskazujesz model uruchomiony lokalnie, a narzędzie zajmuje się resztą: wyborem plików, wprowadzeniem zmian i zapisaniem ich w historii.

Instalacja i pierwsze uruchomienie

pip install aider-chat
cd moje-repozytorium
aider --model sonnet

Po uruchomieniu jesteś w rozmowie. Opisujesz, co ma się zmienić, narzędzie proponuje zmiany, stosuje je i zapisuje w historii wersji.

Bieżące wydanie nosi numer 0.86.2 i zostało opublikowane dwunastego lutego 2026 roku, a wymagany Python mieści się w przedziale od 3.10 do 3.12. Ta data zasługuje na uwagę i wrócę do niej niżej, bo ma znaczenie przy podejmowaniu decyzji.

Do rozmowy dokładasz pliki, nad którymi pracujesz:

/add src/uslugi/zamowienia.py src/testy/test_zamowienia.py
/ask jak dziala anulowanie zamowienia
/code dodaj obsluge czesciowego zwrotu

Rozdzielenie pytań od poleceń jest tu przydatne. Tryb pytań czyta i odpowiada bez dotykania plików, tryb zmian pisze. Zaczynanie od pytania przy nieznanym kodzie oszczędza cofania niepotrzebnych zmian.

Gdy zmiana pójdzie w złą stronę, cofnięcie jest jedną komendą, bo narzędzie zapisuje własne zmiany osobno.

/undo
/diff
/drop src/testy/test_zamowienia.py
/tokens

Ostatnia komenda pokazuje, ile kontekstu zajmują dodane pliki i historia rozmowy. To jest najprostszy sposób, żeby zauważyć, że rozmowa urosła do rozmiaru, przy którym każdy kolejny krok kosztuje wielokrotnie więcej niż pierwszy, a odpowiedzi zaczynają gubić wątek.

Mapa repozytorium

To jest element, który najbardziej odróżnia to narzędzie od prostszych asystentów, i warto rozumieć, co robi.

Cały projekt nie mieści się w kontekście modelu, więc narzędzie buduje jego skróconą reprezentację: nazwy plików, sygnatury funkcji, definicje klas, importy. Model widzi dzięki temu strukturę całości, choć treść ma tylko z plików dodanych do rozmowy.

Praktyczny skutek jest taki, że zmiana wprowadzona w jednym pliku używa istniejących funkcji z innych zamiast wymyślać nowe o podobnym działaniu. To jest najczęstsza wada narzędzi bez takiej mapy: kod poprawny, tylko duplikujący coś, co już w projekcie było.

Mapa ma swoje granice. W bardzo dużym repozytorium sama zaczyna zajmować sporo kontekstu, więc warto wskazywać pliki jawnie zamiast liczyć, że model sam trafi. Pomaga też podanie w poleceniu nazwy katalogu, bo zawęża obszar poszukiwań skuteczniej niż dokładniejszy opis zadania.

Tryb architekta

Domyślnie jeden model planuje i pisze. Tryb architekta rozdziela to na dwa: jeden model układa plan zmian, drugi zamienia go na konkretne edycje w plikach.

Zysk jest mierzalny przy zadaniach obejmujących wiele plików. Model rozumujący dłużej planuje lepiej, ale częściej myli się przy dokładnym formacie edycji, a model szybszy odwrotnie. Rozdzielenie ról pozwala wykorzystać obie mocne strony.

Cena jest równie prosta: dwa wywołania zamiast jednego przy każdym kroku i wyższy koszt, bo model planujący pracuje dłużej. Przy drobnej poprawce to marnotrawstwo, przy zmianie obejmującej sześć plików zwykle się opłaca.

Praktyczna zasada wychodzi po kilku dniach pracy. Tryb podstawowy do zmian, które umiesz opisać w jednym zdaniu. Tryb architekta wtedy, gdy sam musisz się chwilę zastanowić, w jakiej kolejności to zrobić.

Integracja z historią wersji

Każda zmiana trafia do osobnego commita z automatycznie napisanym opisem, i to jest cecha, która budzi najwięcej sprzecznych opinii.

Zaleta jest oczywista: każdy krok da się cofnąć osobno, a przegląd tego, co narzędzie zrobiło, sprowadza się do przejrzenia historii. Polecenie cofające ostatnią zmianę działa jednym słowem.

Wada również: historia zapełnia się drobnymi commitami, których nikt nie chce w gałęzi głównej. Rozwiązaniem jest praca na osobnej gałęzi i sklejenie wszystkiego przy scalaniu, albo wyłączenie automatycznego zapisywania i robienie commitów samodzielnie.

Jedna zasada obowiązuje niezależnie od wyboru: zaczynaj z czystym drzewem pracy. Zmiany wprowadzone przez narzędzie mieszają się wtedy z Twoimi własnymi, a rozdzielenie ich po fakcie jest osobnym zadaniem.

Tempo wydań i co z tego wynika

Ostatnie wydanie opublikowane w rejestrze pakietów pochodzi z lutego 2026 roku. Między nim a dniem dzisiejszym minęło niemal pół roku, co przy narzędziu z tej kategorii jest długim okresem.

Warto to nazwać wprost, bo ma znaczenie praktyczne. Narzędzie działa i nadal jest jednym z najlepszych rozwiązań w swojej niszy, natomiast obsługa nowych modeli, poprawki wydajności i zmiany nadążające za dostawcami przestały pojawiać się w dawnym tempie. Przy narzędziu, którego wartość zależy od tego, jak dobrze rozmawia z aktualnymi modelami, to jest realny czynnik.

Co z tym zrobić. Przed decyzją zajrzyj do repozytorium i sprawdź, kiedy była ostatnia aktywność i czy pojawiły się nowsze wydania po tej dacie, bo sytuacja mogła się zmienić od napisania tego tekstu. Sprawdź też, czy modele, których chcesz używać, są obsługiwane w wersji, którą instalujesz.

To nie jest powód, żeby rezygnować. To jest powód, żeby wiedzieć, na co się piszesz, i nie budować wokół tego narzędzia procesu, którego nie da się odtworzyć czymś innym. Na szczęście przy narzędziu terminalowym to jest łatwe, bo nie zmienia ono ani kodu, ani sposobu pracy zespołu.

Praca z modelem lokalnym

To jest scenariusz, dla którego część osób w ogóle sięga po to narzędzie, i wart osobnego opisania, bo wypada inaczej, niż wynikałoby z materiałów reklamowych.

Punktem wyjścia jest wymóg: kod nie może opuścić firmy. Przy narzędziach z wbudowanym dostawcą modeli nie ma tu żadnej drogi, bo wysyłanie treści plików na zewnątrz jest wpisane w ich działanie. Tutaj wskazujesz adres serwera z modelem uruchomionym u siebie i reszta działa tak samo.

Realia są jednak takie, że model lokalny mniejszej klasy radzi sobie z tym zadaniem gorzej, i różnica jest większa niż przy zwykłej rozmowie. Powód leży w formacie edycji: narzędzie oczekuje zmian zapisanych w ustalonej postaci, a słabszy model łamie ten format i zmiana się nie stosuje. Widać to jako powtarzające się próby i komunikaty o nieudanym dopasowaniu fragmentu.

Praktyczne wnioski są trzy. Model do tego zadania trzeba dobrać świadomie, bo nie każdy dobry w rozmowie jest dobry w edytowaniu plików. Zadania warto formułować drobniej niż przy modelu z chmury, bo krótsza zmiana rzadziej łamie format. Oraz: tryb architekta z modelem lokalnym w roli planującej i drugim w roli edytującej bywa lepszy niż jeden model w obu rolach.

Warto też zmierzyć czas. Model uruchomiony na typowej stacji roboczej odpowiada na tyle wolniej, że praca zmienia rytm: przestaje przypominać rozmowę, a zaczyna zlecanie zadań. Przy tym rytmie inne narzędzia bywają wygodniejsze, więc decyzja o modelu lokalnym powinna wynikać z wymogu, a nie z ciekawości.

Plik z wytycznymi i powtarzalność

Narzędzie czyta plik z wytycznymi umieszczony w repozytorium i to jest najtańszy sposób na poprawę wyników, jaki przy nim istnieje.

Bez niego model widzi kod i wyciąga z niego wnioski, co działa przy projekcie spójnym i zawodzi przy takim, który ma historię. Konwencja, od której odstępowano przez dwa lata, zostanie odczytana jako obie wersje naraz i wynik będzie losowy.

Co warto tam zapisać: używane biblioteki i te, których zespół świadomie unika, sposób nazywania, gdzie leżą testy i jak się je uruchamia, wersję języka oraz reguły, które nie wynikają z kodu.

# Konwencje projektu

Python 3.12, zaleznosci przez uv, formatowanie ruff.
Testy: pytest, uruchomienie przez `make test`.

Uzywamy:
- pydantic do walidacji danych wejsciowych
- httpx do wywolan sieciowych

Nie uzywamy:
- requests, migrujemy do httpx
- warstwa uslug nie siega bezposrednio do bazy, tylko przez repozytoria

Zadanie jest skonczone, gdy przechodzi `make check`.

Ostatnia linia jest tu najważniejsza. Narzędzie umiejące uruchomić jedno polecenie zbierające wszystkie sprawdzenia poprawia własne błędy samo, zamiast oddawać kod, który się nie kompiluje.

Efekt jest widoczny od pierwszego zadania, bo znika najczęstsza kategoria poprawek: kod poprawny technicznie i niepasujący do reszty projektu. Zamiast poprawiać to samo przy każdej zmianie, zapisujesz regułę raz.

Warto też trzymać w repozytorium zapis poleceń, które zadziałały. Sformułowanie, po którym narzędzie trafiło za pierwszym razem, jest w tym samym projekcie wielokrotnie użyteczne.

Ustawienia powtarzalne dla całego zespołu zapisz w pliku konfiguracyjnym obok wytycznych, zamiast wpisywać przełączniki przy każdym uruchomieniu.

model: sonnet
auto-commits: false
test-cmd: make check
auto-test: true
read:
  - KONWENCJE.md

Wyłączenie automatycznych zapisów w historii jest tu decyzją wartą świadomego podjęcia. Domyślnie każda zmiana trafia do historii od razu, co przy dobrym wyniku jest wygodne, a przy złym zostawia zapis, który trzeba cofać. Przy pracy nad nieznanym kodem wygodniej jest przejrzeć zmianę przed zapisem.

Aider kontra alternatywy

Główna przewaga pierwszego wiersza jest niezależnością. Narzędzie terminalowe wpina się w każdy stos, nie wymaga porzucenia konfiguracji edytora budowanej latami i pozwala wybrać model, w tym uruchomiony na własnym sprzęcie, jeśli kod nie może opuścić firmy.

Główna wada też jest oczywista: brak podpowiadania w czasie pisania. To jest inny sposób pracy, w którym opisujesz zadanie i oglądasz wynik, a nie pisze się kod razem z modelem linijka po linijce. Część osób woli jedno, część drugie, i to jest raczej kwestia nawyku niż wyższości.

Warto też zauważyć, że te narzędzia nie wykluczają się. Rozszerzenie do podpowiadania w edytorze i narzędzie terminalowe do większych zmian współistnieją bez konfliktów, bo działają w różnych momentach.

Koszty i jak nimi sterować

Płacisz bezpośrednio dostawcy modelu, więc rachunek zależy od tego, jak pracujesz, a nie od abonamentu.

Największy wpływ ma liczba plików w rozmowie. Każdy dodany plik trafia do kontekstu przy każdym kolejnym poleceniu, więc rozmowa z piętnastoma plikami kosztuje wielokrotnie więcej niż z trzema. Polecenie usuwające pliki z rozmowy po skończeniu z nimi jest najprostszą oszczędnością.

Drugi czynnik to długość rozmowy. Kontekst rośnie z każdą turą, więc dziesiąte polecenie w tej samej sesji kosztuje znacznie więcej niż pierwsze. Zamknięcie sesji i rozpoczęcie nowej po skończeniu zadania bywa tańsze niż dalsze poprawianie.

Trzeci to dobór modelu. Zmiana nazwy zmiennej w pięciu plikach nie wymaga tego samego, co zaprojektowanie nowego modułu. Przełączanie modelu w trakcie pracy jest tu jedną komendą i warto z tego korzystać.

Czwarty, przy trybie architekta, to świadomy wybór pary modeli. Mocny do planowania i szybki do edycji daje zwykle lepszy stosunek wyniku do kosztu niż mocny do obu ról.

Typowe błędy

Pierwszy to uruchamianie na brudnym drzewie pracy. Zmiany narzędzia mieszają się z Twoimi i cofnięcie jednych bez drugich staje się kłopotliwe.

Drugi to trzymanie w rozmowie plików, których już nie potrzebujesz. Każdy z nich kosztuje przy każdym poleceniu.

Trzeci to zadania obejmujące zbyt wiele plików naraz. Zmiana, której nie da się przejrzeć, trafia do historii bez przeglądu.

Czwarty to praca bez testów. Narzędzie, które po zmianie widzi czerwony wynik, poprawia się samo. Bez tego całe sprawdzanie zostaje po Twojej stronie.

Piąty to pomijanie trybu pytań przy nieznanym kodzie. Zapytanie o działanie fragmentu przed jego zmianą kosztuje kilka groszy i oszczędza cofania.

Szósty to założenie, że narzędzie zna reguły projektu. Konwencje, których nie widać w plikach dodanych do rozmowy, zostaną złamane, więc to, co ma być przestrzegane, trzeba zapisać w pliku z wytycznymi.

FAQ

Czy Aider jest darmowy?

Samo narzędzie tak, jest projektem otwartym. Płacisz wyłącznie za wywołania modelu u wybranego dostawcy, a przy modelu uruchomionym na własnym sprzęcie koszt tokenów znika całkowicie, kosztem jakości i szybkości.

Jakiego modelu użyć?

Dowolnego, którego klucz podasz, w tym rodziny Claude i modeli lokalnych. Do zmian mechanicznych opłaca się model tańszy, do projektowania mocniejszy, a przełączenie w trakcie pracy jest jedną komendą.

Czy Aider jest nadal rozwijany?

Ostatnie wydanie w rejestrze pakietów pochodzi z lutego 2026 roku, więc tempo wydań wyraźnie zwolniło. Narzędzie działa i jest używane, natomiast przed wdrożeniem warto sprawdzić bieżącą aktywność w repozytorium oraz to, czy Twoje modele są obsługiwane.

Czym różni się od Cursora?

Postacią i niezależnością. Cursor jest osobnym edytorem z wbudowanym dostawcą modeli i podpowiadaniem w czasie pisania. Aider działa w terminalu, nie zmienia Twojego środowiska i pozwala wybrać dowolny model, w tym uruchomiony lokalnie.

Czy muszę używać gita?

Tak, narzędzie jest zbudowane wokół historii wersji i po każdej zmianie robi commit. Automatyczne zapisywanie da się wyłączyć, natomiast samo repozytorium jest potrzebne, bo na nim opiera się cofanie zmian.

Dokumentacja stoi na stronie projektu, a kod i wydania w repozytorium na GitHubie.