piątek, 19 czerwca 2026

{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.

poniedziałek, 18 maja 2026

{dev} forge – Jak budować specyfikację w OpenSpec pod AI coding agents

Do tej pory w serii {dev} forge – How software is forged with AI rozmawialiśmy głównie o ideach:

  • czym jest Spec-Driven Development,
  • dlaczego promptowanie nie skaluje się w projektach,
  • jak wygląda dobra specyfikacja,
  • oraz dlaczego AI potrzebuje kontraktu zamiast luźnej rozmowy.


Pora więc przejść do praktyki.

W tym artykule pokażę, jak wygląda realny workflow pracy z AI w podejściu spec-driven przy użyciu OpenSpec oraz Codex CLI.

I właśnie tutaj zaczyna się najciekawsza część całego trendu.

Bo kiedy pierwszy raz zobaczysz, że AI nie pracuje już na pojedynczym promptcie, tylko na uporządkowanej specyfikacji, bardzo szybko zrozumiesz jedną rzecz:

przyszłość AI-assisted development nie wygląda jak chat. Wygląda jak pipeline specyfikacji.

Czym właściwie jest OpenSpec?

OpenSpec to lekki framework do Spec-Driven Development, którego celem jest uporządkowanie współpracy z AI coding assistantami wokół trwałych artefaktów zamiast ulotnych rozmów.

Projekt wspiera wiele narzędzi AI, między innymi:

  • Codex,
  • Claude Code,
  • Cursor,
  • GitHub Copilot,
  • Gemini CLI.

OpenSpec opisuje się jako:

  • open source,
  • universal,
  • bez API keys,
  • bez MCP.

Najważniejsze jednak jest coś innego:

OpenSpec zamienia specyfikację w aktywny artefakt procesu developmentu.

Źródła:

Jak wygląda workflow OpenSpec?

Domyślny workflow wygląda mniej więcej tak:

Propose → Explore → Apply → Validate → Archive

Czyli:

  • najpierw definiujesz zmianę,
  • potem eksplorujesz rozwiązanie,
  • następnie AI implementuje zmianę,
  • na końcu walidujesz rezultat i archiwizujesz decyzję.

To jest ogromna różnica względem klasycznego „wrzuć prompt i zobacz co wyjdzie”.

OpenSpec wymusza bowiem myślenie o zmianie jako o procesie opartym o trwałe artefakty.

Instalacja OpenSpec

OpenSpec działa jako pakiet npm.

Instalacja jest bardzo prosta:

npm install -g @fission-ai/openspec@latest

Po instalacji możesz sprawdzić wersję:

openspec --version

Źródła:

Inicjalizacja projektu

Następnie przechodzisz do repozytorium projektu:

cd my-project

I uruchamiasz:

openspec init

OpenSpec skonfiguruje workflow oraz zainstaluje odpowiednie skills i komendy dla wybranego narzędzia AI.

Domyślnie aktywowany jest profil core, który zawiera workflow:

  • propose
  • explore
  • apply
  • sync
  • archive

Źródło:

OpenSpec + Codex

I tutaj robi się naprawdę ciekawie.

OpenSpec ma natywne wsparcie dla Codex.

Podczas inicjalizacji może instalować:

  • skills,
  • workflow commands,
  • spec-driven prompts.

Dla Codex instalowane są między innymi:

.codex/skills/openspec-*/SKILL.md

oraz workflow commands:

$CODEX_HOME/prompts/opsx-*

Źródło:

Jak działają skills?

Skills to jeden z najważniejszych elementów nowoczesnego AI-assisted development.

Można je traktować jak:

  • procedury operacyjne dla AI,
  • specjalizowane instrukcje,
  • trwałą wiedzę domenową.

Zamiast za każdym razem tłumaczyć AI:

  • jak wygląda architektura projektu,
  • jakie są standardy kodowania,
  • jakie obowiązują reguły bezpieczeństwa,
  • jakie są konwencje nazewnicze,

skills dostarczają ten kontekst automatycznie.

To właśnie tutaj zaczynamy odchodzić od „AI jako chat” w stronę „AI jako uczestnik procesu engineeringowego”.

Instalacja skills w Codex

Codex wspiera skills w bardzo podobny sposób do Claude Code.

Skills można instalować:

  • globalnie,
  • per projekt,
  • bezpośrednio z repozytoriów.

Przykładowo Codex wykrywa skills w katalogach:

~/.codex/skills/

lub:

.codex/skills/

Codex automatycznie ładuje skills przy starcie sesji.

Źródła:

Praktyczny przykład – budowa feature’a

Załóżmy, że chcemy dodać nowy feature:

„Program lojalnościowy dla klientów premium w sklepie online”

W klasycznym prompt-driven development moglibyśmy napisać:

Dodaj loyalty program dla klientów premium.

I AI prawdopodobnie wygenerowałoby jakiś kod.

W OpenSpec zaczynamy zupełnie inaczej.

Krok 1 – Propose

Najpierw definiujemy zmianę.

Powstaje proposal zawierający:

  • cel biznesowy,
  • zakres,
  • model domenowy,
  • scenariusze,
  • kontrakty API,
  • edge case’y.

Przykład:

# Premium Loyalty Program

## Goal
Introduce loyalty tiers for premium customers.

## Rules
- Customer earns points per order
- Premium threshold: 1000 points
- Discount applies only to eligible categories

## API
POST /loyalty/points
GET /loyalty/status

## Edge Cases
- Refund removes points
- Expired points cannot be reused

To jest gigantyczna różnica względem pojedynczego prompta.

AI dostaje:

  • intencję,
  • reguły,
  • kontrakt,
  • granice rozwiązania.

Krok 2 – Explore

Następnie AI eksploruje rozwiązanie.

To etap, w którym:

  • analizowana jest architektura,
  • sprawdzane są zależności,
  • identyfikowane są ryzyka.

To bardzo ważne, bo AI przestaje działać „na ślepo”.

Krok 3 – Apply

Dopiero teraz Codex przechodzi do implementacji.

I to jest moment, w którym naprawdę widać przewagę spec-driven development.

AI nie generuje już „jakiegoś rozwiązania”.

AI implementuje konkretną specyfikację.

To ogromna różnica jakościowa.

Krok 4 – Validate

Na końcu następuje walidacja:

  • czy feature spełnia scenariusze,
  • czy kontrakty API są poprawne,
  • czy edge case’y są obsłużone.

To właśnie tutaj wraca DNA V-Modelu i BDD.

Spec nie kończy się na implementacji.

Spec definiuje również sposób walidacji.

Największa zmiana mentalna

Najciekawsze w całym OpenSpec nie jest samo narzędzie.

Najważniejsza jest zmiana sposobu myślenia.

W klasycznym AI-assisted development często wygląda to tak:

Human → Prompt → AI → Code

W podejściu spec-driven wygląda to bardziej tak:

Human → Spec → Workflow → AI → Validate → Codebase

To zupełnie inny poziom dojrzałości procesu.

Dlaczego to jest ważne?

Bo AI coding assistants są coraz lepsze.

A im lepsze są modele, tym większe znaczenie ma jakość wejścia.

Prompt może wystarczyć do:

  • małego taska,
  • eksperymentu,
  • prototypu.

Ale jeśli chcesz budować:

  • większy system,
  • zespół AI-assisted developers,
  • powtarzalny proces engineeringowy,
  • kontrolę jakości i traceability,

to potrzebujesz czegoś więcej.

Potrzebujesz specyfikacji jako centralnego artefaktu procesu.

Podsumowanie

OpenSpec pokazuje bardzo wyraźnie, w jakim kierunku zmierza AI-assisted development.

Nie chodzi już tylko o „pisanie promptów”.

Chodzi o budowanie:

  • workflowów,
  • skills,
  • specyfikacji,
  • kontraktów,
  • procesów walidacji.

I właśnie dlatego uważam, że:

przyszłość AI programming nie będzie oparta o chat.

Będzie oparta o spec-driven workflows.

A OpenSpec jest dziś jednym z najciekawszych praktycznych przykładów tego kierunku.

niedziela, 26 kwietnia 2026

{dev} forge – Kto odpowiada za kod generowany przez AI?

AI coding assistants zmieniły sposób, w jaki powstaje software. Kod, który kiedyś był efektem godzin pracy developera, dziś może powstać w kilka minut. Prompt, kilka iteracji i gotowe. Szybkość robi wrażenie. Problem w tym, że wraz z tą zmianą pojawia się pytanie, które wielu zespołów jeszcze nie zadaje wystarczająco głośno:

kto odpowiada za kod generowany przez AI?



To nie jest pytanie filozoficzne. To jest pytanie bardzo praktyczne. Dotyczy jakości, bezpieczeństwa, odpowiedzialności prawnej i – co najważniejsze – odpowiedzialności inżynierskiej.

W świecie, w którym kod powstaje coraz częściej przy udziale modeli językowych, nie możemy pozwolić sobie na brak jasnej odpowiedzi.

Mit: „AI wygenerowało, więc to nie moja odpowiedzialność”

Jednym z najbardziej niebezpiecznych mitów, jakie pojawiły się wraz z popularyzacją AI, jest przekonanie, że skoro kod został wygenerowany przez model, to odpowiedzialność za jego jakość jest „rozmyta”.

To bardzo wygodna narracja. Ale całkowicie nieprawdziwa.

AI nie jest członkiem zespołu. Nie bierze odpowiedzialności. Nie podpisuje się pod commitami w sensie inżynierskim. Nie odpowiada przed klientem, audytem ani produkcją.

AI jest narzędziem. Bardzo zaawansowanym, ale nadal narzędziem.

A odpowiedzialność za efekt użycia narzędzia zawsze pozostaje po stronie człowieka i organizacji.

To nie pierwszy raz w historii

Warto zauważyć, że to nie jest zupełnie nowy problem. Historia software engineeringu zna już podobne momenty.

Kiedy pojawiły się frameworki, biblioteki open source, code generators czy low-code platforms, również pojawiało się pytanie: kto odpowiada za kod, którego nie napisaliśmy w 100% sami?

Odpowiedź zawsze była taka sama:

odpowiada ten, kto decyduje o użyciu i wdrożeniu.

To, że nie napisałeś każdej linijki ręcznie, nie zwalnia Cię z odpowiedzialności za system, który trafia na produkcję.

AI tylko podnosi stawkę, bo zwiększa skalę i tempo generowania kodu.

Problem numer jeden: iluzja poprawności

Jednym z największych zagrożeń przy pracy z AI jest to, że generowany kod wygląda poprawnie.

Ma sensowną strukturę. Kompiluje się. Często przechodzi nawet podstawowe testy. Komentarze brzmią przekonująco. Nazwy są logiczne. Wszystko sprawia wrażenie profesjonalne.

Ale „wygląda poprawnie” to nie to samo, co „jest poprawne”.

Model nie rozumie Twojego systemu w taki sposób, jak robi to doświadczony inżynier. Nie zna wszystkich kontekstów biznesowych. Nie zna ograniczeń infrastrukturalnych. Nie zna kompromisów, które zostały wcześniej podjęte.

W rezultacie może wygenerować rozwiązanie, które:

I to wszystko bez żadnego ostrzeżenia.

Problem numer dwa: brak świadomości decyzji

Kiedy developer pisze kod ręcznie, podejmuje serię mikrodecyzji. Każda linijka ma swoje uzasadnienie. Każda konstrukcja wynika z jakiejś intencji.

W przypadku kodu generowanego przez AI część tych decyzji jest ukryta. Model generuje rozwiązanie, ale nie zawsze jasno komunikuje, dlaczego wybrał właśnie takie podejście.

To prowadzi do bardzo niebezpiecznej sytuacji:

zespół zaczyna utrzymywać kod, którego w pełni nie rozumie.

A utrzymywanie kodu bez zrozumienia to prosta droga do problemów.

Problem numer trzy: odpowiedzialność rozproszona

W klasycznym modelu developmentu odpowiedzialność jest względnie jasna. Wiemy, kto implementował feature, kto go reviewował, kto zatwierdził wdrożenie.

W modelu opartym o AI bardzo łatwo tę odpowiedzialność rozmyć:

  • „AI to wygenerowało”
  • „to było tylko sugestią”
  • „nie zmieniałem tego, bo wyglądało dobrze”

Jeśli zespół nie zdefiniuje jasno zasad pracy z AI, bardzo szybko może dojść do sytuacji, w której nikt nie czuje się właścicielem kodu.

A brak właściciela to brak jakości.

Jak powinna wyglądać odpowiedzialność w erze AI?

Moim zdaniem odpowiedź jest prostsza, niż się wydaje:

odpowiedzialność się nie zmienia. Zmieniają się narzędzia.

To nadal:

  • developer odpowiada za kod, który commitował,
  • reviewer odpowiada za code review,
  • architekt odpowiada za spójność systemu,
  • organizacja odpowiada za to, co trafia na produkcję.

AI nie znosi tych ról. Ono tylko zmienia sposób, w jaki wykonujemy pracę.

Nowa kompetencja: AI Code Review

Wraz z AI pojawia się nowa, bardzo ważna kompetencja: umiejętność reviewowania kodu generowanego przez model.

To nie jest dokładnie to samo, co klasyczny code review. Trzeba nauczyć się patrzeć na kod trochę inaczej.

Na co zwracać uwagę?

  • Czy rozwiązanie jest zgodne z architekturą systemu?
  • Czy nie wprowadza ukrytych założeń?
  • Czy obsługuje edge case’y?
  • Czy nie „overengineeruje” problemu?
  • Czy nie pomija ważnych aspektów (np. bezpieczeństwa, walidacji, logowania)?

AI potrafi być bardzo przekonujące. Dlatego review musi być jeszcze bardziej świadome.

Rola Spec-Driven Development

I tutaj wracamy do jednego z głównych tematów tej serii.

Jeśli chcemy realnie zarządzać odpowiedzialnością za kod generowany przez AI, potrzebujemy stabilnego punktu odniesienia. Czegoś, co pozwala jasno powiedzieć:

„to jest poprawne, a to nie”.

Właśnie tę rolę pełni specyfikacja.

W podejściu spec-driven:

  • AI nie „zgaduje” rozwiązania, tylko realizuje spec,
  • kod można walidować względem scenariuszy i kontraktów,
  • odpowiedzialność jest powiązana z artefaktami, a nie rozmową,
  • łatwiej przeprowadzić audyt i analizę decyzji.

To nie eliminuje potrzeby myślenia. Ale znacząco zmniejsza ryzyko chaosu.

Najważniejsza zasada

Jeśli miałbym sprowadzić cały temat do jednej zasady, brzmiałaby ona tak:

Jeśli wrzucasz kod na produkcję, bierzesz za niego odpowiedzialność – niezależnie od tego, czy napisałeś go sam, czy wygenerowało go AI.

To podejście jest brutalnie proste. Ale właśnie dlatego działa.

Podsumowanie

AI zmienia sposób, w jaki tworzymy software. Przyspiesza development, obniża barierę wejścia i pozwala realizować pomysły szybciej niż kiedykolwiek wcześniej.

Ale nie zmienia jednego:

odpowiedzialności za system.

Nie możemy traktować AI jako wymówki. Nie możemy zrzucać na nie decyzji. Nie możemy zakładać, że skoro coś zostało wygenerowane, to jest automatycznie poprawne.

W erze AI dobry inżynier to nie ten, kto pisze najwięcej kodu. To ten, kto potrafi ocenić, który kod powinien istnieć.

A do tego potrzebujemy nie tylko promptów, ale przede wszystkim dobrze zbudowanych specyfikacji.