Gdy sztuczna inteligencja pisze kod: umiejętności inżynierskie, które zyskują na wartości
Agenci kodujący obecnie projektują funkcje od początku do końca. Co należy studiować, jak przeglądać generowany kod oraz dlaczego osąd, wiedza o systemach i weryfikacja są ważniejsze niż tylko pisanie.
Pisanie kodu staje się najłatwiejszą częścią pracy w dziedzinie oprogramowania. Decydowanie o tym, co należy stworzyć, sprawdzanie tego, co wygenerowała sztuczna inteligencja, oraz rozpoznawanie błędów to umiejętności, które są teraz najważniejsze.
Ciągle pojawia się pytanie: jeśli sztuczna inteligencja potrafi napisać większość kodu, co pozostaje dla programistów? To błędne pytanie. Lepsze brzmi tak: czego powinien się nauczyć osoba rozpoczynająca karierę w oprogramowaniu dzisiaj, czego sztuczna inteligencja nie może łatwo zastąpić?
Najwyraźniej coś się zmieniło. Narzędzia takie jak Claude Code, Codex, Copilot, Cursor i podobne dawno przewyższyły możliwości automatycznego uzupełniania tekstu. Potrafią czytać całe repozytoria, edytować kilka plików, wykonywać polecenia, pisać testy, rozwiązywać problemy i pracować nad zadaniami aż do ich ukończenia. Szczególnie Claude Code dawno przekroczył poziom prostego polecenia „napisz mi funkcję” i działa bardziej jak agent inżynieryjny działający wewnątrz repozytorium. To zmienia charakter tej pracy.
Kod staje się tani
Niedawno programista mógł poświęcić pół dnia na jedną funkcjonalność. Teraz tę funkcjonalność można opisać agentowi:
Add JWT authentication.
Create login and refresh-token APIs.
Add PostgreSQL persistence.
Write integration tests.
Run the test suite.
Fix failures.
Następnie agent zabiera się do pracy. Tworzy pliki, edytuje istniejące klasy, uruchamia testy, napotyka błędy, dostosowuje implementację i ponownie uruchamia testy. Nic z tego nie jest już hipotetyczne.
Co wyróżnia się, to fakt, że programista nie zniknął z tego procesu. Programista stał się osobą odpowiedzialną za wynik, a ta różnica ma znaczenie.
Gdzie pokazuje przykład Anthropic
Anthropic jest jednym z najwyraźniejszych przykładów, ponieważ tam używa się Claude Code do poważnego programowania. Jego twórca, Boris Cherny, publicznie mówił o tym, jak bardzo zmieniła się praca inżynierska w firmie, a raporty z początku tego roku opisywały sytuacje, w których sztuczna inteligencja tworzyła niemal cały kod w niektórych z ich procesów inżynieryjnych.
Rozwijający powinni skupić się na jednym aspekcie: większa ilość wygenerowanego kodu nie oznacza mniej pracy inżynierskiej. Może to oznaczać większą odpowiedzialność. Załóżmy, że Claude wygeneruje 5 000 wierszy kodu. Ktoś musi teraz odpowiedzieć na pytanie:
Is the architecture correct?
Is authentication secure?What happens under 10,000 requests?Can this transaction fail halfway?Will this leak memory?What happens when Redis is unavailable?What happens when the database is slow?Did the AI introduce a race condition?
Sztuczna inteligencja może zapewnić implementację, ale to ty nadal ponosisz konsekwencje.
Szerzej o tym temacie
Zgodnie z doniesieniami prasowymi, były badacz w Anthropic, Jacob Coxon, ogłosił rezygnację we wrześniu 2026 roku. Jego ostrzeżenie nie dotyczyło tego, czy Claude potrafi pisać przyzwoity JavaScript, czy też czy sztuczna inteligencja może stworzyć API typu Spring Boot. Chodziło o to, w jakim kierunku zmierzają coraz bardziej zaawansowane systemy sztucznej inteligencji. Jego wpis na platformie X dotarł, jak podaje się, do ponad 100 milionów osób i argumentował, że czołowe laboratoria rozwijają zbyt szybko autonomiczne, a potencjalnie niebezpieczne systemy.
Jego słowa mają wagę, ponieważ pochodzą od osoby, która pracowała w firmie rozwijającej tę technologię. Dyskusja stała się na tyle poważna, że dyrektor generalny Anthropic, Dario Amodei, również wezwał do wolniejszego tempa rozwoju nowoczesnych technologii oraz do bardziej rygorystycznej, niezależnej oceny systemów sztucznej inteligencji.
Zatem rok 2026 przedstawia ciekawy obraz. Jedna grupa twierdzi, że sztuczna inteligencja może znacznie przyspieszyć rozwój oprogramowania. Inna, składająca się z osób tworzących te systemy, uważa, że wszyscy powinni być o wiele bardziej ostrożni co do tego, dokąd prowadzi to przyspieszenie. Obie te tezy mogą być prawdziwe jednocześnie.
Największy błąd
Największym błędem nie jest unikanie sztucznej inteligencji. Jest nim jej używanie bez zrozumienia tego, co wytwarza. Weźmy to jako przykład:
@GetMapping("/users")
public List<User> getUsers() {
return userRepository.findAll();
}
Sztuczna inteligencja może to napisać w dwie sekundy. Czy powinno się to wprowadzić? Być może. Ale co, jeśli tabela zawiera 20 milionów wierszy? A co, jeśli nie ma paginacji? Albo jeśli endpoint jest publiczny, a typ User zawiera poufne pola, albo jeśli pięć tysięcy osób korzysta z niego jednocześnie? Kod jest technicznie poprawny, ale decyzja inżynieryjna nadal może być fatalna. W tym właśnie polega różnica.
Czego zamiast tego należy się nauczyć
Ktoś, kto rozpoczyna karierę w 2026 roku, powinien poświęcić mniej czasu zapamiętywaniu składni, a więcej temu, jak naprawdę działają systemy:
- projektowanie systemów i systemy rozproszone
- bazy danych, API i sieciowanie
- bezpieczeństwo
- debugowanie i testowanie
- wydajność i obserwowalność
- infrastruktura chmurowa
- sposób działania agentów AI
Pisanie kodu wciąż ma znaczenie, ale miara umiejętności programisty przesuwa się od liczby wstukanych linijek ku zdolności przekształcenia skomplikowanego problemu w niezawodny system. Sztuczna inteligencja jest już bardzo dobra w radzeniu sobie z takimi zadaniami:
Write this.
Refactor this.
Explain this.
Test this.
Fix this.
Convert this.
Często bardziej cenionym programistą jest ten, który potrafi odpowiedzieć coś w tym stylu:
Don't build it this way.
Here's why.
Here's the simpler architecture.
Here's the failure mode you missed.
Here's what we should measure in production.
Sztuczna inteligencja nie eliminuje potrzeby myślenia
Oto nieprzyjemna kwestia. Sztuczna inteligencja ułatwia programowanie, co może prowadzić do powstania słabszych programistów, jeśli przestaną myśleć. Istnieją już pewne dowody: badanie przeprowadzone przez Anthropic wykazało, że programiści korzystający z pomocy sztucznej inteligencji radzili sobie gorzej w testach zrozumienia podczas nauki nieznanych bibliotek programistycznych, mimo że sztuczna inteligencja przynosi rzeczywiste korzyści produktywnościowe w innych sytuacjach.
Lekcją nie jest przestanie używać sztucznej inteligencji, lecz unikanie całkowitego przekazywania jej zadania uczenia się. Gdy Claude napisał rozwiązanie, przeczytaj je, przeanalizuj, zmień, zapytaj, dlaczego działa i gdzie zawodzi. Spróbuj samodzielnie stworzyć wersję uproszczoną, a następnie wróć do sztucznej inteligencji. To znacznie lepsze rozwiązanie niż ten błędny cykl:
Prompt → Copy → Commit → Next task
Nowy inżynier oprogramowania
Inżynier nie znika, ale praca staje się trudniejsza. Juniorowy programista, który jedynie przekształca wymagania na kod typu CRUD, znajduje się w znacznie słabszej sytuacji niż wcześniej. Osoba, która rozumie problem biznesowy, architekturę, kwestie bezpieczeństwa, jak awarie występują w środowisku produkcyjnym oraz jak korzystać z narzędzi AI, staje się znacznie bardziej kompetentna. Jeden inżynier z dobrymi narzędziami może teraz badać pomysły, które kiedyś wymagały małego zespołu.
To ekscytujące, ale jednocześnie niebezpieczne, ponieważ gdy produkcja oprogramowania staje się tańsza, tanieje również jego jakość. Wkrótce może pojawić się miliony aplikacji napisanych przy użyciu AI. Ich tworzenie nie będzie trudne. Trudniejsze będzie określenie, które z nich zasługują na istnienie.
Co robić dziś jako programista
Rywalizacja z AI w pisaniu kodu to strata czasu. Wykorzystuj AI intensywnie i doskonal się w jego analizowaniu. Dowiedz się, jak zawodzą rzeczywiste systemy. Zrozum bazę danych stojącą za API oraz to, co dzieje się po wdrożeniu. Przestudiuj kwestie bezpieczeństwa i sposób działania agentów. Zachowaj umiejętność tworzenia czegoś bez użycia AI, gdy to konieczne.
Przyszłość prawdopodobnie nie będzie polegać na konfrontacji człowieka z AI. Będzie bardziej przypominać starcie programisty z AI z programistą bez niego. A na jeszcze wyższym poziomie programiści, którzy wiedzą, co i dlaczego budować oraz kiedy tego unikać, mogą okazać się cenniejsi od tych, którzy jedynie generują kod. AI sprawia, że tworzenie kodu staje się tańsze, a osąd inżynierski zyskuje na wartości.
Literatura pokrewna
- Kto pisze kod, gdy agenci dołączają do przepływu pracy? — Mapowanie asystentów kodowania od funkcji automatycznego uzupełniania do zespołów agentów oraz dopasowywanie poziomów do zasięgu oddziaływania, testów i punktów weryfikacji.
- Umiejętności plus MCP: narzędzia dostarczają wsparcie, umiejętności uczą przepływu pracy — MCP ujawnia dostępne możliwości; pakiet Skills organizuje przepływy pracy i zasady bezpieczeństwa, dzięki czemu agenci wiedzą, jakie narzędzia użyć, w jakiej kolejności i kiedy poprosić o zatwierdzenie.
- Pięć poziomów projektów inżynierii SI, od chatbotów do samodoskonalących się agentów — Drabina pięciu poziomów projektów inżynierii SI, od opakowań API po RAG, agenty, systemy wieloagentowe i pętle samodoskonalenia, z ćwiczeniem do wykonania przy każdym poziomie.