Rezultat pracy developera a AI

W zajawce serii zadałem pytanie, od którego zacząłem majową prezentację: co jest rezultatem pracy developera? Kod, nowa funkcjonalność, zamknięte tickety i poprawki błędów to wyniki, a rezultat to zaspokojona potrzeba użytkownika i korzyść, jaką daje to firmie. Zmiana u użytkownika nie musi oznaczać nowego nawyku. Często polega na tym, że coś znika z jego dnia, bo rozwiązanie zajmuje się potrzebą samo: telefon na infolinię albo ręczne przepisywanie danych. Na sali większość osób odpowiadała jednak wynikami, choć pytanie dotyczyło rezultatu. Ten wpis jest o tym, skąd bierze się to pomieszanie i jak sprawdzić rezultat w codziennej pracy zespołu.

Dlaczego pytani o rezultat odpowiadamy wynikami?

Bo wyniki widać od razu, a rezultat dopiero po czasie. Ticket ma status, PR ma datę scalenia, a liczbę wdrożeń da się policzyć w każdym narzędziu. To, czy potrzeba użytkownika została zaspokojona, widać tygodnie później, często w danych, do których zespół nie ma dostępu, albo w rozmowach, w których nie uczestniczy. Korzyść dla firmy, na przykład niższy koszt obsługi albo większy przychód, widać jeszcze później, w wynikach miesiąca albo kwartału.

Dochodzi do tego sposób rozliczania. Zespół, który na przeglądzie pokazuje, co dostarczył, i słyszy w odpowiedzi tylko pytanie o kolejne zadania, uczy się, że liczy się wynik. W notatkach do prezentacji zapisałem to jednym zdaniem: myśląc o rezultatach, skupiamy się na mechanice i na artefaktach, które z niej powstają. O tym, jak połączyć wynik z tym, co dzieje się u użytkownika i w biznesie, pisałem we wpisie o łączeniu perspektyw. Zmianę u użytkownika nazwałem tam outcome, a korzyść dla firmy impact. Rezultat, o który pytam w tej serii, obejmuje oba poziomy.

Co zmienia w tym AI?

AI sprawia, że wynik tanieje. Werner Vogels, CTO Amazona, w rozmowie z „Fortune” podał przykład małej strony internetowej, która kiedyś zajmowała trzy tygodnie, a z pomocą narzędzi AI powstaje w dwie godziny. W swoich prognozach na 2026 rok napisał, że generatywna AI pisze kod w kilka sekund, ale nie siedzi na spotkaniach budżetowych.

Kiedy kod kosztuje mniej, sama liczba zamkniętych ticketów mówi jeszcze mniej niż wcześniej. Rośnie za to wartość tego, czego narzędzie nie zrobi: zrozumienia, czyją potrzebę kod ma zaspokoić i co firma ma z tego mieć.

Kim jest renesansowy developer?

To developer, który łączy głęboką wiedzę techniczną z rozumieniem kontekstu, w jakim działa jego kod. Vogels nazwał go renaissance developer w listopadzie 2025 roku, a w grudniu na konferencji AWS re:Invent rozwinął ten pomysł w pięć cech: ciekawość, myślenie systemowe, precyzyjną komunikację, odpowiedzialność za to, co się buduje, i szerokie zainteresowania, czyli kształt litery T. Przy odpowiedzialności powtarzał, że praca należy do człowieka, który ją wykonał, niezależnie od tego, jakich narzędzi użył. Ostrzegał też przed długiem weryfikacji, czyli sytuacją, w której AI generuje kod szybciej, niż ktokolwiek zdąży go zrozumieć.

21 maja 2026, w dniu mojej prezentacji, Vogels powtórzył tych pięć cech na AWS Summit w Seulu.

Jakie są ostatnie wieści o renesansowym developerze?

Najświeższa pochodzi z 27 października 2026 roku. Amazon opublikował notatkę swoich liderów inżynierii do developerów i ich managerów o zmienionym opisie roli developera. We wstępie do niej pada zdanie, że jesteśmy w erze renesansowego developera, który łączy narzędzia AI z ludzkim osądem i wiedzą dziedzinową.

Dwa fragmenty tej notatki pasują wprost do pytania z prezentacji. Pierwszy: rezultaty, które się liczą, nie zmieniają się, nawet jeśli narzędzia i techniki zmieniają się szybciej niż kiedykolwiek, a liczy się wpływ na klientów, biznes i zespoły. Drugi: liczba zużytych tokenów, stopień użycia narzędzi AI i liczba zmian w kodzie to miary wejścia z wadami, których nie należy traktować jak celów. Do tego zachęta, żeby developerzy byli blisko klientów i kierunku rozwoju produktu, tym bardziej, im wyżej są w strukturze.

Jedna z największych firm technologicznych mówi więc swoim developerom wprost, że o wartości ich pracy decyduje wpływ na klienta, a tokeny i liczba zmian w kodzie pomagają go co najwyżej szukać.

Jak sprawdzić, czy moja praca dała rezultat?

Najprościej zapytać o to przed napisaniem pierwszej linii kodu. Czyją potrzebę ma zaspokoić to rozwiązanie? Co zyska na tym firma? Po czym poznamy jedno i drugie? Kiedy sprawdzimy? Jeśli zespół nie umie odpowiedzieć na te pytania, przynajmniej wie, że dostarcza wynik w ciemno.

Weźmy wymyślony, ale typowy ticket: „Dodać eksport raportu sprzedaży do CSV”. W wersji bez pytań kryteria akceptacji wyglądają tak: przycisk na ekranie raportu, plik się pobiera, kolumny zgodne z tabelą, testy przechodzą. Zespół zamyka ticket w dwa dni i na przeglądzie pokazuje działający przycisk. Wynik jest kompletny.

Ten sam ticket po tych pytaniach wygląda inaczej. Potrzebę ma osoba z działu finansów, która co miesiąc przepisuje dane z raportu do arkusza rozliczeń: chce zamknąć miesiąc bez przepisywania i bez błędów. Plik CSV to tylko jeden ze sposobów. Może się okazać, że lepiej, żeby dane same trafiały do arkusza i ta osoba nie musiała niczego eksportować. Firma zyska czas, który dział finansów co miesiąc traci na przepisywanie i poprawianie zestawienia, i szybciej zamknie miesiąc. Poznamy to po tym, że ręczne zestawienie zniknie razem ze zgłoszeniami o błędach w nim, a sprawdzimy po najbliższym zamknięciu miesiąca, w krótkiej rozmowie z tą osobą. Bez tych pytań plik się pobierze, dane nadal trzeba będzie przestawiać ręcznie, a firma nie zyska nic poza nowym przyciskiem.

Odpowiedzi nie muszą być pewne. Wystarczy, że są zapisane przy tickecie, bo wtedy po wdrożeniu jest co sprawdzić.

Po wdrożeniu przydaje się rozróżnienie z wpisu o weryfikacji i walidacji. Zielone testy mówią, że zbudowaliśmy to, co zamierzaliśmy. Czy to rozwiązuje problem użytkownika i czy firma coś na tym zyskała, pokazują dopiero dane z produkcji, rozmowy z klientem i wyniki biznesowe.

A u Was co jest rezultatem pracy developera? I kto w zespole sprawdza, czy się pojawił?

Bibliografia

Vogels, W. (2025, 25 listopada). Amazon CTO Werner Vogels predicts the renaissance developer era. About Amazon. https://www.aboutamazon.com/news/aws/werner-vogels-amazon-cto-predictions-2026
Brady, D. (2025, 25 listopada). Amazon CTO’s 2026 tech predictions include the dawn of the „renaissance developer”. Fortune. https://fortune.com/2025/11/25/amazon-cto-werner-vogels-2026-tech-predictions-renaissance-developer
Werner Vogels’ final keynote: The Renaissance Developer era (2025, 4 grudnia). Implicator.ai. Relacja z wystąpienia na AWS re:Invent 2025. https://www.implicator.ai/werner-vogels-hands-out-newspapers-at-his-likely-final-re-invent-the-man-who-built-the-cloud-isnt-done-teaching/
Amazon CTO: „In the AI Era, Evolve into a Renaissance Developer” (2026, 21 maja). BigGo Finance. Relacja z AWS Summit Seoul 2026. https://finance.biggo.com/news/PffVTZ4BDXrLZJaAAYxj
Terkowitz, T. (2026, 27 października). An update from Amazon engineering leadership on the role of the developer in the age of AI. About Amazon. https://aboutamazon.com/news/company-news/amazon-software-engineer-role-guideline-ai
Żelezny, T. (2026, 21 maja). Developer to dobry start. Inżynier produktu to kierunek. Prezentacja, slajdy 4–5.

Ten o rezultacie pracy developera