Amazon ostrzega, że więcej tokenów nie znaczy lepszej pracy

Amazon 27 października 2026 r. opublikował zaktualizowane wytyczne dotyczące roli inżynierów oprogramowania w epoce AI. Firma ostrzega, że większe zużycie tokenów samo w sobie nie dowodzi lepszej pracy. Gdy licznik użycia narzędzia staje się celem, może zachęcać do zwiększania kosztów bez poprawy tego, co zespół dostarcza klientom.

Autor publicznej notatki Amazona, Terk Terkowitz, wiceprezes i distinguished engineer w Worldwide Amazon Stores, zaleca menedżerom analizę 10. i 90. percentyla adopcji AI, a brak korzyści z narzędzia w konkretnym zadaniu określa słowami „a finding, not a failing”. Oznacza to ocenę przydatności AI przez wynik pracy, a nie przez sam fakt uruchomienia narzędzia.

Wytyczne zmieniają punkt ciężkości oceny

Notatka trafiła do inżynierów i menedżerów we wrześniu 2026 r.; IT Pro opisuje jej późniejszą publikację oraz wcześniejsze doniesienia o pracownikach, którzy używali AI do zbędnych zadań, by poprawić pozycję w wewnętrznym rankingu. Taki ranking może pokazywać aktywność, lecz nie odpowiada na pytanie, czy gotowe rozwiązanie było potrzebne i użyteczne. Presja na demonstracyjne korzystanie z narzędzia zmienia więc zachowanie, które wskaźnik miał jedynie obserwować.

Nowa wersja wytycznych nadal zachęca programistów do poznawania AI i stosowania go w codziennej pracy. Równocześnie utrzymuje odpowiedzialność inżyniera za rozumienie produktu, potrzeb klientów i skutków decyzji technicznych. Wybór narzędzia pozostaje częścią sposobu wykonania zadania; o wartości pracy ma świadczyć rezultat dla klientów, firmy i zespołu. To rozróżnienie ma znaczenie także dla menedżera, który widzi rosnące użycie AI, ale musi ustalić, co dzięki niemu faktycznie się poprawiło.

Tokeny i zmiany kodu mogą mylić

Zużycie tokenów i odsetek osób używających AI opisują nakłady oraz przyjęcie narzędzi. Liczba zmian w kodzie i przeglądów kodu pokazuje aktywność w procesie tworzenia oprogramowania. Żadna z tych miar, rozpatrywana osobno, nie mówi, czy rozwiązanie odpowiada potrzebie klienta, działa poprawnie i pozostaje łatwe w utrzymaniu. Wysokie wartości mogą towarzyszyć skutecznej pracy, ale mogą też wynikać z wielokrotnego poprawiania nietrafionego rozwiązania.

Przekształcenie miary w cel tworzy dwa różne ryzyka. Premia za zużycie tokenów może skłaniać do uruchamiania AI tam, gdzie nie wnosi ono wartości, podnosząc koszt obliczeń. Premia za objętość kodu może z kolei nagradzać rozbudowanie rozwiązania, choć prostsza wersja lepiej spełniałaby zadanie. Są to możliwe skutki źle dobranych bodźców, a nie opublikowany pomiar wzrostu kosztów lub złożoności po wprowadzeniu wytycznych.

Dane o aktywności wciąż mogą być użyteczne diagnostycznie. Jeżeli podobne zespoły osiągają różne wyniki przy odmiennym poziomie użycia AI, licznik wskazuje miejsce do zbadania. Wyjaśnienia trzeba jednak szukać w rodzaju zadań, jakości dostarczonego oprogramowania oraz nakładach potrzebnych do jego przygotowania i poprawienia. Sam wzrost użycia narzędzia nie rozstrzyga, czy to narzędzie spowodowało poprawę.

Skrajne zespoły pomagają znaleźć przyczynę

Analiza zespołów rzadko korzystających z AI ma ustalić, dlaczego tak się dzieje. Przyczyną może być charakter ich zadań, ograniczenie obecnych narzędzi albo przeszkoda w ich zastosowaniu. Niski poziom użycia nie pozwala wybrać jednej z tych odpowiedzi bez znajomości pracy zespołu. Menedżer powinien zestawić sposób wykonania zadań z ich efektami, zanim uzna mniejszą adopcję za problem wymagający zmiany.

Wśród zespołów korzystających z AI najintensywniej pytanie jest inne: czy większej aktywności odpowiada lepsze dostarczanie rezultatów. Nawet gdy zadania kończą się szybciej, znaczenie ma jakość gotowego kodu i wysiłek potrzebny później na poprawki. Takie porównanie pozwala oddzielić praktykę, którą warto upowszechnić, od efektownego wyniku w statystykach użycia. Wymaga też ostrożności: zespoły o różnych zadaniach i warunkach pracy nie tworzą automatycznie uczciwego porównania.

Brak korzyści z AI też jest ustaleniem

Jeśli obecne narzędzie nie pomaga w konkretnym zadaniu, inżynier ma udokumentować powód, podzielić się obserwacją z innymi i omówić ją z przełożonym. Taki opis może ujawnić ograniczenie narzędzia, problem z jego zastosowaniem lub typ pracy, dla którego lepsza jest inna metoda. Od pracownika oczekuje się tu osądu popartego doświadczeniem z rzeczywistego zadania, a nie deklaracji, że AI jest przydatne albo zbędne we wszystkich sytuacjach.

Podobne wymaganie dotyczy kierownictwa technicznego. Menedżer ma znać zastosowanie narzędzi w pracy nad produktem i umieć wskazać zadanie, w którym AI pomogło, oraz takie, w którym nie przyniosło korzyści. Rozmowa o adopcji może wtedy dotyczyć konkretnych warunków i skutków pracy. Pozwala to również przekazać twórcom narzędzi informację o ograniczeniach, zamiast ukrywać ją za rosnącą liczbą uruchomień.

Co z tych zasad wynika dla mniejszego zespołu

W mniejszym zespole ocenę wdrożenia AI można oprzeć na trzech powiązanych wielkościach: rezultacie, jakości i koszcie. Rezultat to wykonanie uzgodnionego zadania lub rozwiązanie problemu użytkownika. Jakość obejmuje poprawność działania oraz pracę potrzebną na późniejsze poprawki. Koszt to zarówno użycie narzędzi, jak i czas ludzi poświęcony na sprawdzanie oraz korygowanie ich wyników. Jest to model oceny, a nie zestaw nowych wskaźników produktywności ogłoszony przez Amazon.

Porównanie powinno dotyczyć zadań o zbliżonym celu i trudności. W warunkowym przykładzie funkcja przygotowana z AI trafia do użytkowników wcześniej, lecz wymaga więcej poprawek niż podobna funkcja wykonana bez niego. Sam czas dostarczenia wskazywałby korzyść, podczas gdy łączny koszt i jakość mogłyby prowadzić do innej oceny. Odwrotna sytuacja też jest możliwa: większe zużycie tokenów może być uzasadnione, jeśli ogranicza późniejszą pracę i poprawia gotowy produkt.

Tokeny, aktywacja narzędzia, zmiany kodu i przeglądy pozostają w takim modelu danymi pomocniczymi. Pomagają wyjaśnić, skąd wzięła się różnica między zadaniami, ale nie zastępują pomiaru efektu. Dla inżynierów oznacza to, że decyzję o użyciu AI warto wiązać z konkretną korzyścią w pracy nad produktem. Dla zespołów, które dziś mierzą głównie aktywność, najważniejszą zmianą jest możliwość zobaczenia kosztu pracy ukrytego za pozornie lepszym wynikiem licznika.

Przeczytaj także:

• Microsoft wpuszcza agentów do HR — wyników wdrożenia wciąż nie pokazuje
• Hybryda czy biuro? Dwa dni z domu nie obniżyły wyników w eksperymencie
• ETF czy fundusz TFI? Niższy TER nie pokazuje całego rachunku