Tabnine, asystent kodu dla firm

Tabnine, czyli asystent kodu, który przestał być dla wszystkich

Tabnine był przez lata jednym z pierwszych asystentów uzupełniających kod i przez długi czas najpopularniejszą alternatywą dla rozwiązań od dostawców chmurowych, głównie dzięki naciskowi na prywatność.

Ta pozycja się zmieniła i zmiana jest na tyle zasadnicza, że musi otwierać ten tekst. Plan bezpłatny został wycofany na początku 2025 roku, a plan dla pojedynczych programistów zniknął jesienią tego samego roku. Dziś oferta obejmuje wyłącznie plany firmowe, rozliczane rocznie.

Jeśli szukasz asystenta do własnych projektów albo do pracy jako osoba niezależna, to narzędzie nie jest już dla Ciebie, i możesz przejść od razu do sekcji o alternatywach. Jeśli reprezentujesz firmę z wymogami dotyczącymi tego, gdzie trafia kod, poniżej opisuję, co dostajesz w zamian za cenę.

Doszła do tego druga zmiana, świeższa. 30 lipca 2026 roku producenta przejął Tricentis, dostawca narzędzi do testowania oprogramowania, zapowiadając wbudowanie silnika kontekstu Tabnine we własną platformę. Produkt sprzedaje się dalej pod swoją nazwą i z tą samą ofertą, ale przy umowie rocznej warto zapytać o plany rozwoju na piśmie, bo po przejęciu priorytety bywają inne.

Prywatność jako produkt

Cała propozycja opiera się na jednej rzeczy: kod nie opuszcza Twojej kontroli, a producent nie zatrzymuje go u siebie.

Zapytania są przetwarzane ulotnie, wyłącznie po to, żeby wygenerować podpowiedź, i odrzucane zaraz potem. Nie ma zbioru, w którym gromadzi się Twój kod, i nie ma trenowania modeli na tym, co napisali Twoi programiści.

To rozróżnienie warto rozumieć, bo w tej kategorii jest kilka poziomów. Zapewnienie, że kod nie służy do trenowania, jest częste. Zapewnienie, że nie jest w ogóle przechowywany, rzadsze. Możliwość uruchomienia całości bez połączenia z internetem, wyjątkowa.

Dostępne są cztery warianty wdrożenia, ułożone od najwygodniejszego do najbardziej zamkniętego. Usługa zarządzana przez producenta. Wdrożenie w Twojej chmurze prywatnej. Wdrożenie na własnych serwerach. Oraz wariant całkowicie odcięty od sieci, bez jakiegokolwiek połączenia wychodzącego.

Ten ostatni jest tu prawdziwym wyróżnikiem. Instytucja finansowa, podmiot z sektora obronnego albo zespół pracujący na danych objętych klauzulą nie mogą użyć narzędzia wysyłającego cokolwiek na zewnątrz, i dla nich wybór jest znacznie węższy, niż sugerują zestawienia asystentów kodu.

Co dostajesz poza uzupełnianiem

Oferta rozszerzyła się poza podpowiadanie kolejnych linii, i warto wiedzieć, na czym dziś stoi.

Uzupełnianie kodu działa w edytorze i jest tym, od czego wszystko się zaczęło. Podpowiedzi uwzględniają kontekst projektu, a nie wyłącznie bieżący plik.

Agent wykonujący zadania to nowsza warstwa i przedmiot droższego z dwóch planów. Obejmuje wprowadzanie zmian obejmujących wiele plików, generowanie testów oraz przegląd zmian przed scaleniem.

Przegląd kodu działa według reguł ustalonych przez organizację, a nie wyłącznie ogólnych zasad. To ma znaczenie w firmach z własnymi standardami, gdzie ogólne narzędzie zgłasza rzeczy nieistotne i pomija te ważne.

Dostosowanie do własnego kodu jest funkcją, o której warto wspomnieć osobno. Model uczy się wzorców z Twoich repozytoriów, więc podpowiedzi zaczynają przypominać sposób pisania przyjęty w organizacji, a nie uśredniony styl z publicznego kodu.

Zastrzeżenie: to ostatnie działa najlepiej przy dużej i spójnej bazie kodu. Przy repozytorium liczącym kilkanaście tysięcy linii, pisanym przez trzy osoby w trzech stylach, zysk jest niewielki.

Ceny i dla kogo to jest

Rozliczenie idzie za osobę miesięcznie, przy zobowiązaniu rocznym. Plan z uzupełnianiem kodu i czatem osadzonym w Twoim repozytorium kosztuje 39 dolarów za osobę miesięcznie, a plan obejmujący warstwę agentową i silnik kontekstu 59 dolarów. Obie stawki są wyraźnie wyższe niż u konkurencji nastawionej na pojedynczych programistów. Wdrożenia zamknięte, w tym wariant odcięty od sieci, wyceniane są indywidualnie.

Stawka za osobę nie jest jednak całym rachunkiem, i to jest rzecz, którą cennik zapisuje gwiazdką. Nielimitowane użycie obejmuje wyłącznie pracę na własnym modelu, uruchomionym u siebie albo pod własnym adresem w chmurze. Jeśli sięgasz po modele udostępniane przez producenta, dochodzi opłata za wykupioną z góry pulę tokenów, liczona według cen dostawcy modelu powiększonych o pięć procent prowizji.

Wniosek jest prosty i warto go postawić bez owijania. Przy zespole dziesięciu osób roczny koszt idzie w tysiące dolarów, więc uzasadnienie musi leżeć poza samą jakością podpowiedzi. Tym uzasadnieniem jest zwykle zgodność: wymóg, żeby kod nie opuszczał infrastruktury, którego nie da się spełnić inaczej.

Jeśli takiego wymogu nie masz, konkurencja daje porównywalną jakość taniej. To nie jest zarzut wobec produktu, tylko opis rynku: producent świadomie zrezygnował z segmentu, w którym konkurencja cenowa jest ostra, i skupił się na tym, gdzie ma przewagę.

Warto też policzyć koszt wariantu własnego. Wdrożenie na swoich serwerach oznacza sprzęt, utrzymanie i aktualizacje, więc do stawki za osobę dochodzą pozycje, których w usłudze zarządzanej nie ma.

Przy zobowiązaniu rocznym dochodzi jeszcze jedna rzecz warta uwagi: brak możliwości szybkiego wyjścia. Narzędzie kupione na rok trzeba wykorzystać przez rok, nawet jeśli po dwóch miesiącach okaże się, że zespół go nie używa. Dlatego okres próbny przed podpisaniem umowy jest tu ważniejszy niż przy rozwiązaniach rozliczanych miesięcznie, gdzie pomyłka kosztuje jeden miesiąc.

Co oznacza wdrożenie odcięte od sieci

Warto rozwinąć ten wątek, bo określenie brzmi jednoznacznie, a w praktyce oznacza kilka rzeczy naraz i wiąże się z konkretnymi obowiązkami po Twojej stronie.

Model działa na Twoim sprzęcie, więc potrzebujesz kart graficznych. To jest pierwsza pozycja kosztowa i zarazem najczęściej niedoszacowana, bo obsługa kilkudziesięciu programistów wymaga czegoś więcej niż jednej maszyny.

Aktualizacje przestają dziać się same. Nowa wersja modelu albo poprawka bezpieczeństwa trafiają do Ciebie jako paczka, którą ktoś musi wgrać, przetestować i wdrożyć. Przy środowisku odciętym od sieci ten proces bywa formalny i długi.

Diagnostyka również jest po Twojej stronie. Gdy podpowiedzi przestaną działać, nie ma zdalnego wsparcia patrzącego na Twoje dzienniki, więc ktoś w organizacji musi rozumieć, jak to działa.

W zamian dostajesz coś, czego żadna umowa nie zapewni: pewność wynikającą z braku fizycznej możliwości wysłania danych. To jest różnica jakościowa wobec zapewnień o retencji, i przy części wymogów formalnych jedyna, która się liczy.

Praktyczna wskazówka przy takim wdrożeniu: ustal na początku, kto po Twojej stronie odpowiada za utrzymanie, i policz jego czas w koszcie. Rozwiązanie bez wskazanego właściciela działa do pierwszej awarii, a potem staje się narzędziem, którego nikt nie naprawia.

Niezależnie od wybranego narzędzia warto też sprawdzić, co w ogóle leży w repozytorium i mogłoby trafić do indeksu. To jedno polecenie zwykle przynosi niespodzianki.

git ls-files | grep -iE '\.(env|pem|key|p12|pfx)$|secret|credential'
git log --all --diff-filter=A --name-only --pretty=format: | sort -u | grep -iE '\.env'

Drugie polecenie jest ważniejsze od pierwszego, bo pokazuje pliki, które kiedykolwiek trafiły do historii, nawet jeśli dziś ich nie ma w drzewie roboczym. Plik usunięty rok temu nadal siedzi w historii i nadal jest czytelny dla wszystkiego, co indeksuje repozytorium.

Listę wykluczeń warto trzymać w repozytorium, bo przenosi się między narzędziami, gdy zmieniasz dostawcę.

.env
.env.*
**/*.pem
**/*.key
infra/secrets/
dane-testowe/produkcja-*.json

Uzupełnianie kodu a agent

Podział na dwa plany odpowiada dwóm różnym sposobom pracy i warto rozumieć, który potrzebujesz, bo różnica w cenie jest znacząca.

Uzupełnianie działa w tle podczas pisania. Podpowiada zakończenie linii, kolejną instrukcję, czasem całą funkcję. Nie przerywa pracy, nie wymaga formułowania poleceń i jest tym, co zwiększa tempo pisania o kilkanaście procent bez zmiany sposobu pracy.

Agent działa inaczej. Opisujesz zadanie, on wprowadza zmiany w kilku plikach, uruchamia testy i wraca z wynikiem. To zmienia sposób pracy, a nie tylko jej tempo, i przy dobrze opisanych zadaniach daje zysk znacznie większy.

Warto to rozstrzygnąć na podstawie tego, jak zespół pracuje dzisiaj, a nie na podstawie wrażeń. Odpowiedź daje się wyliczyć z historii repozytorium.

git log --since="3 months ago" --pretty=format:%H --no-merges |
  while read h; do git show --stat --format= "$h" | tail -1; done |
  awk '{print $1}' | sort -n | uniq -c

Rozkład liczby plików na zmianę mówi wprost, którego planu potrzebujesz. Przewaga zmian jedno i dwuplikowych oznacza, że zespół zyska najwięcej na uzupełnianiu w trakcie pisania. Duży udział zmian obejmujących pięć i więcej plików, na przykład migracje albo dodawanie pola przechodzącego przez całą aplikację, oznacza, że warstwa agentowa ma czym się wykazać.

Nie warto natomiast kupować droższego planu w nadziei, że zespół zacznie z niego korzystać. Warstwa agentowa wymaga zmiany nawyków, a nawyki zmieniają się wtedy, gdy ktoś pokaże, że to działa, a nie wtedy, gdy pojawi się w licencji.

Tabnine kontra alternatywy

Ostatni wiersz warto rozważyć uczciwie, bo dla osób indywidualnych jest dziś realną odpowiedzią na to samo pytanie. Model uruchomiony przez Ollamę i wpięty do edytora daje uzupełnianie kodu bez wysyłania czegokolwiek na zewnątrz, kosztem jakości podpowiedzi i wymagań sprzętowych.

Wybór między pierwszym a pozostałymi wierszami sprowadza się do jednego pytania: czy masz wymóg formalny, czy preferencję. Wymóg zawężający dostawców do tych oferujących wdrożenie odcięte od sieci uzasadnia różnicę w cenie. Preferencja, żeby kod nie krążył po internecie, jest zrozumiała i tańsza do zaspokojenia inaczej.

Jak ocenić takie narzędzie

Przy zakupie na skalę firmową warto mieć sposób oceny inny niż lista funkcji, bo ona wygląda podobnie u wszystkich.

Zacznij od pytania o retencję na piśmie. Nie o to, czy kod służy do trenowania, tylko czy jest przechowywany, jak długo i gdzie. Odpowiedź „nie używamy do trenowania" nie odpowiada na to pytanie.

Sprawdź, co dokładnie wychodzi na zewnątrz w wybranym wariancie. Nawet przy wdrożeniu na własnych serwerach część rozwiązań komunikuje się z producentem w sprawie licencji, telemetrii albo aktualizacji, i warto wiedzieć, co dokładnie jest przesyłane.

Zmierz jakość podpowiedzi na własnym kodzie, a nie na przykładach. Tydzień pracy dwóch osób na prawdziwym projekcie mówi więcej niż jakiekolwiek zestawienie, bo mierzy Twój język, Twoje biblioteki i Twój sposób pisania.

Żeby ten tydzień coś znaczył, warto zapisać wynik w liczbach, a nie we wrażeniach. Wystarczy prosty zapis prowadzony przez uczestników.

data,osoba,zadanie,podpowiedzi_przyjete,podpowiedzi_odrzucone,czas_min
2026-08-03,anna,formularz platnosci,34,51,95
2026-08-03,marek,migracja endpointow,12,9,140

Dwie kolumny wystarczą do rozstrzygnięcia. Udział przyjętych podpowiedzi poniżej jednej trzeciej oznacza, że narzędzie przeszkadza bardziej, niż pomaga, bo każda odrzucona podpowiedź kosztuje ułamek sekundy uwagi. Czas zadania porównany z podobnym zadaniem sprzed wdrożenia mówi resztę.

Policz pełny koszt, łącznie z wdrożeniem i utrzymaniem. Przy wariancie odciętym od sieci dochodzi sprzęt, jego wymiana i osoba, która to obsłuży.

Ostatnia rzecz: sprawdź, co się stanie po zakończeniu umowy. Asystent kodu nie tworzy danych do przeniesienia ani formatu, w którym coś zostaje zapisane, więc odejście jest tanie, i to jest argument za wypróbowaniem, a nie za odkładaniem decyzji na później.

Typowe błędy

Pierwszy to szukanie planu dla pojedynczej osoby. Nie istnieje od jesieni 2025 roku, a materiały opisujące tanie plany indywidualne są nieaktualne.

Drugi to mylenie braku trenowania na kodzie z brakiem przechowywania kodu. To dwie różne rzeczy i warto pytać o obie osobno.

Trzeci to zakup ze względu na prywatność bez formalnego wymogu. Jeśli nikt nie wymaga wdrożenia odciętego od sieci, konkurencja daje porównywalną jakość taniej.

Czwarty to pominięcie kosztu utrzymania przy wdrożeniu własnym. Sprzęt, aktualizacje i obsługa to pozycje, których w usłudze zarządzanej nie ma.

Piąty to ocena na podstawie przykładów zamiast na własnym kodzie. Jakość podpowiedzi zależy od języka i bibliotek, więc zestawienia ogólne niewiele mówią.

Szósty to oczekiwanie dużego zysku z dostosowania modelu przy małej bazie kodu. Ta funkcja działa dobrze przy dużym i spójnym repozytorium, a przy kilkunastu tysiącach linii pisanych w trzech stylach nie zmienia praktycznie nic.

Siódmy to podpisanie umowy rocznej bez okresu próbnego. Pomyłka kosztuje wtedy rok, a nie miesiąc, więc test na realnym projekcie przed decyzją jest tu wart znacznie więcej niż zwykle.

FAQ

Czy Tabnine ma jeszcze plan darmowy?

Nie. Plan bezpłatny został wycofany na początku 2025 roku, a plan dla pojedynczych programistów zniknął jesienią tego samego roku. Dostępne są wyłącznie plany firmowe, rozliczane rocznie.

Czym różni się od innych asystentów kodu?

Możliwością wdrożenia całkowicie odciętego od sieci, bez połączeń wychodzących, oraz zapewnieniem, że kod nie jest przechowywany po wygenerowaniu podpowiedzi. To zawęża grono realnych alternatyw dla organizacji, które mają taki wymóg formalny.

Czy kod naprawdę nie opuszcza firmy?

W wariancie odciętym od sieci nie ma połączeń wychodzących, więc nie ma czym go wysłać. W wariancie zarządzanym kod trafia do usługi producenta, jest przetwarzany ulotnie i odrzucany. Przy wymogu formalnym warto poprosić o to na piśmie.

Co wybrać jako osoba indywidualna?

To narzędzie nie jest już dostępne poza planami firmowymi. Przy nacisku na prywatność warto rozważyć model uruchomiony lokalnie, na przykład przez Ollamę, a przy nacisku na jakość podpowiedzi rozwiązania takie jak Cursor albo GitHub Copilot.

Jak sprawdzić, czy warto?

Tygodniem pracy dwóch osób na prawdziwym projekcie, a nie na przykładach z dokumentacji. Zmierz, ile podpowiedzi jest przyjmowanych i czy pasują do Waszego stylu. Odejście od asystenta kodu jest tanie, bo nie zostawia danych do przeniesienia, więc test jest tańszy niż długie rozważanie.

Opis podejścia do prywatności stoi na stronie producenta, a szczegóły planów w cenniku.