{dev} forge – Developer czy Spec Engineer? Jak AI zmienia rolę programisty

Przez ostatnie kilkadziesiąt lat odpowiedź na pytanie „czym zajmuje się programista?” była stosunkowo prosta.

Programista analizował wymagania, projektował rozwiązanie i pisał kod.

Oczywiście w zależności od doświadczenia dochodziły dodatkowe obowiązki związane z architekturą, analizą biznesową czy mentoringiem, ale rdzeń zawodu pozostawał ten sam:

Developer był przede wszystkim producentem kodu.

Dziś jednak znajdujemy się w momencie, który może okazać się jedną z największych zmian w historii software engineeringu.

Po raz pierwszy od dekad produkcja kodu przestaje być głównym ograniczeniem procesu wytwarzania oprogramowania.

Modele takie jak Codex, Claude Code, Gemini CLI czy Cursor potrafią wygenerować w kilka minut ilość kodu, której napisanie zajmowało kiedyś wiele godzin.

To prowadzi do bardzo ciekawego pytania:

Czy przyszłością programisty jest bycie lepszym coderem, czy raczej lepszym projektantem specyfikacji?

Od rzemieślnika kodu do projektanta systemów

Przez wiele lat produktywność programisty była mocno związana z szybkością tworzenia kodu.

Znajomość frameworków, języków programowania i bibliotek była głównym źródłem przewagi.

Dziś sytuacja zaczyna się zmieniać.

Coraz częściej obserwujemy, że największą wartość dostarcza nie osoba, która najszybciej pisze kod, ale osoba, która najlepiej definiuje problem.

AI potrafi napisać endpoint.

AI potrafi wygenerować testy.

AI potrafi stworzyć dokumentację.

Ale nadal nie potrafi samodzielnie odpowiedzieć na pytania:

• Jaki problem biznesowy rozwiązujemy?
• Jakie są reguły domenowe?
• Jakie są granice systemu?
• Jakie kompromisy architektoniczne akceptujemy?
• Jak zmierzymy sukces rozwiązania?

I właśnie tutaj zaczyna pojawiać się nowa specjalizacja.

Kim jest Spec Engineer?

Nie jest to jeszcze oficjalny zawód.

Nie znajdziesz go w większości struktur organizacyjnych.

A jednak coraz więcej zespołów zaczyna wykonywać dokładnie tę pracę.

Spec Engineer to osoba odpowiedzialna za stworzenie specyfikacji, która pozwala ludziom i AI budować rozwiązania w sposób przewidywalny.

Jej zadaniem nie jest przede wszystkim pisanie kodu.

Jej zadaniem jest zaprojektowanie warunków, w których poprawny kod może powstać.

To subtelna, ale fundamentalna różnica.

Nowy łańcuch wartości

Przez lata dominował model:

Requirements → Developer → Code

W świecie AI coraz częściej wygląda to tak:

Requirements → Specification → AI → Code

Lub nawet:

Business Intent
        ↓
Specification
        ↓
Plan
        ↓
Tasks
        ↓
AI Agents
        ↓
Validation
        ↓
Production

Zauważmy coś ciekawego.

Kod nie zniknął.

Ale przestał być centralnym artefaktem procesu.

Coraz częściej staje się produktem ubocznym dobrze przygotowanej specyfikacji.

Dlaczego seniorzy nadal są tak cenni?

Jednym z argumentów często pojawiających się w dyskusjach o AI jest:

„Skoro AI potrafi pisać kod, to po co nam doświadczeni developerzy?”

To pytanie wynika z błędnego założenia.

Zakłada bowiem, że główną wartością seniora jest szybkość kodowania.

W rzeczywistości seniorzy od dawna zarabiają na czymś innym.

Na podejmowaniu decyzji.

Doświadczony architekt lub senior developer potrafi:

• zidentyfikować ryzyka,
• zauważyć brakujące wymagania,
• przewidzieć skutki decyzji architektonicznych,
• rozpoznać błędne założenia biznesowe,
• zaprojektować rozwiązanie możliwe do utrzymania za kilka lat.

To są kompetencje, których nie zastępuje automatyczne generowanie kodu.

Wręcz przeciwnie.

Ich znaczenie rośnie.

Czy juniorzy mają problem?

To jeden z najbardziej kontrowersyjnych tematów związanych z AI.

Przez lata junior zdobywał doświadczenie poprzez pisanie dużej ilości kodu.

W ten sposób poznawał:

• wzorce projektowe,
• architekturę systemów,
• debugowanie,
• integracje,
• procesy jakościowe.

Jeśli znaczną część tej pracy przejmie AI, pojawia się pytanie:

Skąd przyszli seniorzy będą zdobywać doświadczenie?

Moim zdaniem odpowiedzią jest zmiana sposobu nauki.

Przyszły senior będzie musiał szybciej rozwijać:

• myślenie systemowe,
• analizę domenową,
• modelowanie procesów,
• projektowanie specyfikacji.

Kod pozostanie ważny, ale przestanie być jedynym źródłem nauki.

Najcenniejsze kompetencje dekady AI

Jeżeli miałbym wskazać kompetencje, których warto rozwijać najwięcej w latach 2026–2030, byłyby to:

1. Domain Modeling

Rozumienie biznesu i domeny problemowej.

2. Systems Thinking

Myślenie o zależnościach między elementami systemu.

3. Architecture

Projektowanie rozwiązań odpornych na zmiany.

4. Specification Design

Umiejętność tworzenia jednoznacznych specyfikacji dla ludzi i AI.

5. Validation Engineering

Definiowanie sposobów walidacji i kontroli jakości.

Warto zauważyć, że tylko jedna z tych kompetencji dotyczy bezpośrednio kodowania.

Spec Engineer jako naturalna ewolucja developera

Nie sądzę, aby zawód developera zniknął.

Nie wierzę również w wizję świata, w którym wszyscy staną się wyłącznie analitykami piszącymi prompty.

Bardziej prawdopodobny wydaje się inny scenariusz.

Developerzy będą stopniowo przesuwać się wyżej w stosie abstrakcji.

Tak jak kiedyś przeszliśmy od assemblera do języków wysokiego poziomu.

Tak jak później przeszliśmy od ręcznego zarządzania serwerami do chmury.

Tak samo dziś przechodzimy od:

Code First

do:

Specification First

Nie oznacza to końca programowania.

Oznacza zmianę punktu ciężkości.

Podsumowanie

Największą zmianą, jaką przynosi AI, nie jest automatyczne generowanie kodu.

Największą zmianą jest przesunięcie wartości z implementacji na intencję.

Coraz mniej istotne staje się to, kto napisze kod szybciej.

Coraz ważniejsze staje się to, kto potrafi lepiej zdefiniować problem, ograniczenia i oczekiwany rezultat.

Dlatego uważam, że w ciągu najbliższych kilku lat będziemy obserwować narodziny nowej specjalizacji:

Spec Engineer – osoby odpowiedzialnej za projektowanie specyfikacji, na podstawie których ludzie i AI wspólnie tworzą oprogramowanie.

Bo jeśli software ma być kuty z pomocą AI, to ktoś musi najpierw przygotować formę, do której ten metal zostanie wlany.