Koniec szybkiego kodowania: co naprawdę znaczy bycie seniorem w erze AI
Dlaczego sama umiejętność pisania kodu nie jest już największym wyróżnikiem - i co naprawdę się dziś liczy.
Przez lata jednym z najwyraźniejszych sygnałów klasy inżyniera była szybkość.
Jak szybko potrafisz wziąć pomysł, przełożyć go na kod i dowieźć coś, co działa?
To pytanie wciąż jest ważne. Ale już nie tak samo jak kiedyś.
Bo wchodzimy w świat, w którym AI w kilka minut generuje komponenty, endpointy, testy, refactory i całe szkice implementacji. Czasem w kilka sekund. To zmienia ekonomię wytwarzania oprogramowania. A kiedy zmienia się ekonomia, zmienia się też to, co uznajemy za wartościowe.
Dlatego jestem co do jednego głęboko przekonany:
W erze AI bycie seniorem coraz mniej zależy od szybkiego pisania kodu, a coraz bardziej od trafnych decyzji w złożonych sytuacjach.
Kod wciąż się liczy. Głęboka wiedza techniczna wciąż się liczy. Ale samo pisanie kodu nie jest już największym wyróżnikiem. Dziś bardziej liczy się to, co dzieje się wokół kodu: jak przechodzi review, jak wpasowuje się w architekturę, czy odpowiada realiom domeny i czy faktycznie popycha produkt do przodu.
To właśnie tu klasa seniora staje się naprawdę widoczna.
Kod przestał być dobrem rzadkim
Jedna z najważniejszych zmian, jakie przynosi AI, jest taka: sam kod tanieje.
Nie staje się bezwartościowy. Nie przestaje być istotny. Ale tanieje.
Pierwszą wersję rozwiązania da się dziś napisać łatwiej niż kiedykolwiek. Boilerplate, formularze, warstwy CRUD, schematy walidacji, wrappery do integracji, testy, scaffolding UI - to wszystko powstaje znacznie szybciej niż dawniej. To przyspieszenie jest realne i już zmienia codzienną pracę inżyniera.
Ale w większości zespołów to nie sama szybkość pisania kodu była wąskim gardłem.
Większe problemy zwykle leżały gdzie indziej: niejasne wymagania, płytkie rozumienie domeny, słabe granice w systemie, lokalna optymalizacja kosztem utrzymania na dłuższą metę albo praca techniczna oderwana od wartości biznesowej.
AI pomaga zespołom produkować więcej. Nie gwarantuje lepszego osądu.
I ta różnica jest kluczowa.
Bo kiedy kod łatwiej wygenerować, realna dźwignia przesuwa się w stronę ludzi, którzy potrafią odpowiedzieć na trudniejsze pytania:
- Czy to rozwiązuje właściwy problem?
- Czy to właściwa abstrakcja, czy tylko taka, która robi wrażenie?
- Czy to pasuje do systemu, który budujemy?
- Jaką złożoność tu wprowadzamy?
- Czy ten kompromis się opłaca?
- Budujemy coś użytecznego, czy tylko coś ciekawego technicznie?
Dlatego nie uważam, żeby AI obniżało wartość seniorów.
Uważam, że obnaża to, w czym seniorzy zawsze mieli być dobrzy.
Prawdziwa praca zaczyna się po pierwszym szkicu
Jeden z wzorców, które widzę najwyraźniej, to ten, że pierwsza wersja kodu liczy się mniej niż kiedyś.
To nie znaczy, że jest nieważna. Znaczy tyle, że to już niekoniecznie tam powstaje najcenniejszy inżynierski wkład.
Dziś pierwszy szkic może pochodzić z wielu miejsc: od programisty, który dobrze używa AI, z wewnętrznego procesu generowania kodu albo od kogoś, kto z nowoczesnymi narzędziami pracuje ekstremalnie szybko. Coraz częściej to nie ten pierwszy szkic jest wąskim gardłem.
Wąskim gardłem jest to, co dzieje się dalej.
Widziałem sytuacje, w których kod napisany z pomocą AI na pierwszy rzut oka wyglądał zupełnie dobrze. Kompilował się, flow działał, struktura wydawała się sensowna. Ale kiedy spojrzeć na niego w kontekście całego systemu, robiło się jasne, że wprowadzał złą granicę odpowiedzialności, duplikował logikę, która powinna zostać w jednym miejscu, albo leczył objaw zamiast prawdziwego problemu w domenie.
To właśnie tę część ludzie często niedoceniają.
Mnóstwo dzisiejszego kodu da się wygenerować. Niewielkiej części można zaufać bez osądu.
I dlatego uważam, że code review staje się jedną z kluczowych kompetencji seniora w tej epoce.
Nie review jako pilnowanie stylu. Nie review jako odhaczanie checklisty. Review jako głębokie myślenie - techniczne i produktowe.
Dobry recenzent nie pyta tylko, czy kod działa. Pyta, czy ten kod tu pasuje, czy się wyskaluje, czy jest spójny z architekturą, czy nie tworzy przyszłego balastu i czy dobrze oddaje zrozumienie problemu biznesowego.
To zupełnie inna umiejętność niż samo tempo pisania kodu.
I w wielu zespołach to właśnie ona jest dziś cenniejsza.
Architektura przestała być opcją
Kiedy kod tanieje, architektura staje się jeszcze ważniejsza.
Czuję to bardzo mocno, bo im szybciej zespół się porusza, tym łatwiej o niewidzialny chaos.
Przy wolnym tempie złe decyzje architektoniczne bolą. Przy szybkim - stają się groźne.
Kiedy AI przyspiesza pracę, zespół potrafi błyskawicznie wygenerować dużo lokalnie poprawnego kodu. Ale bez mocnego myślenia o architekturze tak naprawdę produkuje fragmentację: zduplikowane wzorce, niejasną odpowiedzialność, niespójne abstrakcje i systemy, które z każdym sprintem trudniej rozwijać.
Senior, który potrafi trzymać w głowie kształt całego systemu - który widzi, gdzie nowa funkcja zacznie napierać na istniejącą granicę, który rozpoznaje, kiedy dzisiejszy skrót zamieni się w jutrzejszą migrację - staje się cenniejszy, nie mniej cenny.
Bo AI nie trzyma systemu w głowie. Generuje kolejny prawdopodobny token.
To fundamentalna różnica.
Co to znaczy dla tego, jak oceniamy inżynierów
Jeśli to prawda, to sposób, w jaki oceniamy seniorów, musi się zmienić.
Przez lata rozmowy rekrutacyjne i systemy ocen mocno stawiały na implementację: rozwiążesz ten algorytm, zbudujesz tę funkcję, napiszesz ten kod pod presją?
Te sygnały wciąż coś znaczą. Ale są coraz bardziej niepełne.
Pytania, które stają się ważniejsze, trudniej sprawdzić w 45-minutowej rozmowie:
- Czy potrafisz wychwycić, kiedy proponowane rozwiązanie jest technicznie poprawne, ale architektonicznie błędne?
- Czy potrafisz nazwać długoterminowy koszt decyzji, która dziś wygląda tanio?
- Czy potrafisz zakwestionować wymaganie - nie dlatego, że nie chce Ci się go zrobić, ale dlatego, że na tyle rozumiesz domenę, by widzieć, że jest błędne?
- Czy potrafisz przejrzeć pull request i zobaczyć nie tylko to, co kod robi, ale co oznacza dla systemu?
To kompetencje osądu. Rozwijają się przez doświadczenie, przez porażki, przez pracę nad systemami, które żyją dłużej niż ich pierwsza wersja.
AI nie skraca tej drogi. Jeśli już - sprawia, że staje się pilniejsza.
Szansa ukryta w tej zmianie
Warto powiedzieć to wprost: ta zmiana nie jest tylko zagrożeniem dla przeciętnych inżynierów. To ogromna szansa dla tych dobrych.
Jeśli zawsze bardziej zależało Ci na jakości systemu niż na tempie produkcji, ten moment gra na Twoją korzyść. Umiejętności, które bywały niedoceniane - uważne myślenie, mocne review, osąd architektoniczny, głębokie rozumienie domeny - stają się bardziej widoczne i ważniejsze.
Szum zaczyna się przesiewać.
Kiedy każdy potrafi wygenerować pierwszy szkic, wyróżnikiem nie jest już to, kto zrobi to najszybciej. Wyróżnikiem jest to, kto weźmie ten szkic i doprowadzi go do porządku - dobrze dla systemu, dobrze dla zespołu, dobrze dla biznesu.
I o to w byciu seniorem zawsze chodziło.
AI po prostu sprawia, że trudniej to udawać.
Myśl na koniec
Koniec szybkiego kodowania jako głównego wyznacznika klasy seniora to nie strata.
To korekta.
Inżynierowie, którzy w najbliższych latach będą liczyć się najbardziej, to nie ci, którzy wygenerują najwięcej kodu. To ci, którzy podejmą najlepsze decyzje: jaki kod napisać, jak go napisać i czy w ogóle powinien powstać.
To zawsze była ta praca.
Po prostu w końcu budujemy narzędzia, które wreszcie to uwidaczniają.