GitHub w materiale datowanym na 2 października 2026 r. opisuje zmianę codziennej pracy programistów pod wpływem AI. Kodowanie pozostaje podstawową umiejętnością, ale rośnie znaczenie definiowania problemów, przekazywania kontekstu, kontroli kodu generowanego przez modele i podejmowania decyzji technicznych. Autorka materiału, Gwen Davis z GitHub, sprowadza przygotowanie do tej zmiany do trzech obszarów: kierowania AI, krytycznej oceny jego odpowiedzi oraz wykorzystywania zaoszczędzonego czasu do rozwiązywania trudniejszych problemów.
Programista nadal odpowiada za końcowy rezultat
Według GitHub zmienia się przede wszystkim sposób wykonania pracy. Programista nie musi samodzielnie implementować każdego elementu, jeżeli część zadań może przekazać agentom AI. Nadal jednak odpowiada za to, czy rozwiązanie spełnia wymagania, pasuje do istniejącego systemu i nadaje się do wdrożenia.
Oznacza to przesunięcie uwagi z samego tworzenia kodu na określenie, jaki problem należy rozwiązać. Potrzebne stają się precyzyjny opis zadania, właściwy kontekst i ocena rezultatów. Model może przygotować implementację, ale nie przejmuje odpowiedzialności za decyzje dotyczące produktu ani architektury.
GitHub podkreśla, że pisanie kodu nie traci znaczenia. Doświadczenie programistyczne pozwala rozpoznać, czy wygenerowane rozwiązanie jest czytelne, możliwe do utrzymania i zgodne z oczekiwaniami. Bez tej wiedzy trudno ocenić rezultat, nawet jeśli model szybko dostarcza działający fragment kodu.
Kierowanie agentem zaczyna się od zdefiniowania zadania
Pierwszą wskazaną umiejętnością jest kierowanie AI, a nie samo korzystanie z narzędzia. W praktyce programista powinien przekazać agentowi informacje, które pozwolą mu wykonać właściwe zadanie. Samo krótkie polecenie może nie wystarczyć, gdy praca dotyczy istniejącego projektu, określonych wymagań lub decyzji wpływających na inne części systemu.
GitHub ilustruje tę zmianę przykładem dodania nowego mechanizmu uwierzytelniania. W tradycyjnym przepływie programista wykonywałby kolejne części implementacji osobiście. W pracy z agentami więcej czasu przeznacza na opisanie zadania, sprawdzanie wyników i łączenie przygotowanych elementów w spójną całość.
Taki sposób pracy obejmuje kilka odpowiedzialności pozostających po stronie człowieka:
- jasne zdefiniowanie problemu i oczekiwanego rezultatu,
- przekazanie agentowi kontekstu potrzebnego do wykonania zadania,
- sprawdzenie wygenerowanego kodu i powiązanych testów,
- podjęcie decyzji, czy rozwiązanie jest gotowe do wdrożenia.
Te same kompetencje mają znaczenie przy koordynowaniu wielu agentów AI. Każdy z nich może realizować inną część pracy, lecz programista musi kontrolować zależności i ocenić całość. GitHub przedstawia więc agenta jako wykonawcę części implementacji, a nie jako podmiot samodzielnie rozstrzygający, co powinno trafić do produktu.
Pierwsza odpowiedź AI wymaga technicznej kontroli
Druga wskazówka dotyczy zaufania do rezultatów generowanych przez AI. Model może w kilka sekund przygotować rozwiązanie wyglądające na kompletne, lecz pierwsza odpowiedź nie musi być najlepsza. Szybkość uzyskania kodu nie zwalnia programisty z oceny jego jakości i przydatności.
GitHub proponuje, aby wynik pierwszego modelu przekazać do krytyki drugiemu modelowi. Dodatkowa perspektywa może ujawnić problemy, których nie rozpoznał pierwszy system. Ostateczna ocena nadal należy do programisty, który porównuje obie odpowiedzi i wykorzystuje własną wiedzę o projekcie.
Takie podejście stosuje wbudowany w GitHub Copilot agent Rubber Duck. Korzysta on z drugiego modelu, aby poddać krytyce plany, kod i testy przed przejściem do kolejnego etapu. GitHub uzasadnia ten mechanizm różnicami między modelami, ponieważ poszczególne systemy mogą mieć odmienne mocne strony i obszary, w których pomijają problemy.
Weryfikacja przez drugi model nie zastępuje przeglądu wykonywanego przez człowieka. Ma dostarczyć kolejnej opinii, którą programista musi zinterpretować. Szczególnego znaczenia nabiera tu wcześniejsze doświadczenie w tworzeniu czystego i możliwego do utrzymania kodu.
Czas zaoszczędzony na implementacji można przeznaczyć na większe problemy
Trzeci obszar dotyczy wykorzystania czasu, który AI może zaoszczędzić podczas implementacji. GitHub wskazuje, że programiści mogą przeznaczyć go na lepsze rozpoznanie potrzeb klientów, ocenę kompromisów oraz projektowanie systemów. Są to zadania wymagające szerszego spojrzenia niż przygotowanie pojedynczego fragmentu kodu.
Wraz ze wzrostem udziału AI w implementacji rośnie znaczenie trafnego osądu technicznego. Programista musi ocenić, które rozwiązanie pasuje do sytuacji, jakie kompromisy można zaakceptować i czy zespół zajmuje się właściwym problemem. Model może pomóc w wykonaniu zadania, lecz nie podejmuje za zespół wszystkich decyzji dotyczących produktu i systemu.
W tym ujęciu korzyścią z AI nie jest wyłącznie szybsze generowanie kodu. Narzędzia mają zwolnić część czasu potrzebnego na wykonanie, aby inżynierowie mogli skupić się na decyzjach wpływających na kierunek prac. Odpowiedzialność za te decyzje pozostaje po stronie ludzi.
Jak te wskazówki przekładają się na pracę zespołów
Materiał GitHub opisuje zmianę zestawu umiejętności, a nie zanik roli programisty. Znajomość kodowania stanowi podstawę do kontrolowania rezultatów AI, natomiast kierowanie agentami wymaga jasnego formułowania problemów. Do tego dochodzi zdolność porównywania rozwiązań i rozstrzygania kompromisów technicznych.
Tekst ma charakter poradnikowy. Nie przedstawia wyników badań, danych o produktywności ani pomiarów jakości kodu tworzonego w opisanym modelu pracy. Nie określa również, jaka część implementacji może zostać powierzona agentom w konkretnym projekcie.
Dla zespołów programistycznych w Polsce oznacza to potrzebę traktowania pracy z AI jako kompetencji inżynierskiej, a nie wyłącznie obsługi kolejnego narzędzia. Firmy, które włączają agentów do procesu tworzenia oprogramowania, powinny zachować po stronie ludzi kontrolę wyników i odpowiedzialność za decyzję o wdrożeniu.
Główna wskazówka GitHub jest jednoznaczna: AI można powierzać coraz większą część wykonania, ale nie należy pomijać przeglądu. Programista ma wyznaczać kierunek, oceniać rezultat i rozwijać osąd potrzebny zespołowi do podejmowania lepszych decyzji.
