piątek, 17 lipca 2026

Smart Home & IoT w przestrzeniach: Jak skonfigurować zestaw do słuchania muzyki z adapteru na pasywnych głośnikach?

Chciałem słuchać muzyki z adapteru i gramofonu na normalnych, pasywnych głośnikach. Sam adapter miał własne niewielkie głośniki, ale ich jakość oraz głośność były dalekie od tego, czego oczekiwałem.



Miałem już Raspberry Pi z systemem Volumio, nakładkę HiFiBerry Amp2 oraz parę pasywnych głośników. Początkowo wydawało się więc, że wystarczy podłączyć adapter do Raspberry Pi, a następnie skierować dźwięk do HiFiBerry.

Problem polegał na tym, że HiFiBerry Amp2 jest wyłącznie urządzeniem wyjściowym. Odbiera cyfrowy dźwięk z Raspberry Pi, wzmacnia go i wysyła do głośników, ale nie ma analogowego wejścia RCA, do którego można bezpośrednio podłączyć adapter lub gramofon.

Rozwiązaniem okazał się zewnętrzny interfejs audio USB Behringer UCA202.

Finalnie powstał zestaw, który może działać w dwóch trybach: jako streamer Volumio oraz jako cyfrowy most pomiędzy adapterem, gramofonem i pasywnymi głośnikami.

Co chciałem osiągnąć?

Docelowy system miał umożliwiać:

  • słuchanie muzyki z gramofonu na pasywnych głośnikach,
  • wykorzystanie HiFiBerry Amp2 jako wzmacniacza,
  • zachowanie Volumio jako odtwarzacza radia internetowego, Spotify i AirPlay,
  • przełączanie źródła bez każdorazowego logowania przez SSH,
  • sterowanie całością z prostego panelu WWW.

Architektura rozwiązania

Finalny tor sygnału wygląda następująco:

Adapter / gramofon
wyjście LINE OUT RCA
        │
        ▼
Behringer UCA202
wejście INPUT L/R
        │
        │ USB
        ▼
Raspberry Pi z Volumio
        │
        │ I2S
        ▼
HiFiBerry Amp / Amp2
        │
        │ przewody głośnikowe
        ▼
Pasywne głośniki

Raspberry Pi pełni tutaj rolę cyfrowego routera audio.

Analogowy sygnał z adapteru trafia do Behringera UCA202. Interfejs zamienia go na cyfrowe audio przesyłane przez USB. Raspberry Pi odbiera strumień za pomocą ALSA, a następnie wysyła go do HiFiBerry. HiFiBerry wzmacnia sygnał i napędza pasywne głośniki.

Najważniejszy jest podział odpowiedzialności pomiędzy urządzeniami:

  • Behringer UCA202 pełni rolę wejścia audio,
  • Raspberry Pi przekazuje i kontroluje strumień,
  • HiFiBerry Amp2 jest wyjściem audio i wzmacniaczem.

Zaciski głośnikowe HiFiBerry nie są wejściem audio. Nie wolno podłączać do nich wyjścia RCA adapteru ani gramofonu.

Potrzebny sprzęt

Element Rola
Adapter lub gramofon z LINE OUT Analogowe źródło dźwięku
Behringer UCA202 Konwersja analogowego sygnału RCA na cyfrowe audio USB
Raspberry Pi Uruchomienie Volumio, ALSA, usług systemowych i panelu sterującego
HiFiBerry Amp lub Amp2 Wyjście audio oraz wzmacniacz dla głośników pasywnych
Pasywne głośniki Docelowe odtwarzanie dźwięku
Kabel 2 × RCA Połączenie wyjścia LINE OUT adapteru z wejściem Behringera
Przewody głośnikowe Połączenie HiFiBerry z lewym i prawym głośnikiem

Podłączenie sprzętu

Adapter lub gramofon do Behringera

Wyjście LINE OUT urządzenia podłączamy do wejść Behringera UCA202:

  • biały RCA do kanału lewego L,
  • czerwony RCA do kanału prawego R,
  • przewody muszą trafić do złączy oznaczonych jako INPUT.

Następnie Behringera podłączamy przewodem USB do Raspberry Pi.

HiFiBerry do głośników

Pasywne głośniki podłączamy przewodami głośnikowymi bezpośrednio do zacisków HiFiBerry. Należy zachować poprawne przypisanie kanałów oraz polaryzację przewodów.

Przed pierwszym testem warto ustawić niski poziom głośności, a dopiero później stopniowo go zwiększać.

Konfiguracja Volumio i HiFiBerry

Po uruchomieniu Raspberry Pi panel Volumio powinien być dostępny pod adresem:

http://volumio.local

Jeżeli nazwa lokalna nie działa, należy użyć adresu IP Raspberry Pi:

http://192.z.y.z

Ten sam adres wykorzystujemy do połączenia SSH:

ssh volumio@192.z.y.z

Jeżeli SSH jest wyłączone, można je aktywować na stronie developerskiej:

http://ADRES_IP_VOLUMIO/dev

W panelu Volumio przechodzimy do:

Settings → Playback Options

Następnie ustawiamy:

  • I2S DAC: ON,
  • DAC Model: HiFiBerry Amp/Amp2 lub zgodny model,
  • Mixer Type: Hardware, jeżeli jest dostępny,
  • niski początkowy poziom głośności.

Po zapisaniu ustawień restartujemy system.

Sprawdzenie urządzeń ALSA

Przed uruchomieniem przekazywania dźwięku trzeba sprawdzić, czy system widzi wejście Behringera i wyjście HiFiBerry.

Urządzenia nagrywające wyświetlamy poleceniem:

arecord -l

Urządzenia odtwarzające:

aplay -l

W opisywanej konfiguracji urządzenia zostały wykryte jako:

Behringer UCA202:
card 5, device 0
plughw:5,0

HiFiBerry:
card 2, device 0
plughw:2,0

Składnia plughw:<card>,<device> określa numer karty i urządzenia ALSA.

Numery kart mogą zmienić się po restarcie systemu albo przepięciu urządzenia USB. Przed modyfikacją konfiguracji zawsze warto ponownie wykonać arecord -l i aplay -l.

Test HiFiBerry i głośników

Najpierw sprawdzamy sam tor wyjściowy:

amixer -c 2 sset 'Digital' 90% unmute
volumio volume 80
speaker-test -D plughw:2,0 -c 2 -t sine -f 440

Jeżeli z głośników słychać sygnał testowy, oznacza to, że:

  • HiFiBerry zostało poprawnie wykryte,
  • wzmacniacz działa,
  • głośniki są właściwie podłączone,
  • możemy przejść do testowania wejścia Behringera.

Test nagrania z adapteru lub gramofonu

Nagrywamy dziesięciosekundową próbkę:

arecord \
  -D plughw:5,0 \
  -f S16_LE \
  -r 44100 \
  -c 2 \
  -V stereo \
  -d 10 \
  /tmp/adapter.wav

Następnie odtwarzamy ją przez HiFiBerry:

aplay -D plughw:2,0 /tmp/adapter.wav

Parametr -V stereo pokazuje poziom odbieranego sygnału. Jeżeli wskaźnik reaguje podczas odtwarzania muzyki, Behringer poprawnie odbiera dźwięk.

W przypadku UCA202 program alsamixer może wyświetlić komunikat:

This sound device does not have any capture controls

Jest to normalne. Komunikat oznacza jedynie, że urządzenie nie udostępnia programowego suwaka poziomu wejścia.

Odsłuch na żywo

Po potwierdzeniu działania wejścia i wyjścia łączymy oba urządzenia prostym potokiem:

arecord \
  -D plughw:5,0 \
  -f S16_LE \
  -r 44100 \
  -c 2 \
  --buffer-time=500000 \
| aplay \
  -D plughw:2,0 \
  -f S16_LE \
  -r 44100 \
  -c 2 \
  --buffer-time=500000

arecord odbiera dźwięk z Behringera, a aplay przekazuje go do HiFiBerry.

W tym momencie muzyka z adapteru powinna być słyszalna na pasywnych głośnikach.

Usługa systemd dla wejścia audio

Ręczna komenda działa tylko do chwili zamknięcia terminala. Dlatego tworzymy usługę systemową:

sudo nano /etc/systemd/system/turntable.service

Zawartość pliku:

[Unit]
Description=Turntable line-in from Behringer UCA202 to HiFiBerry
After=sound.target
Wants=sound.target

[Service]
Type=simple
User=volumio
Group=audio
ExecStart=/bin/bash -c 'arecord -D plughw:5,0 -f S16_LE -r 44100 -c 2 --buffer-time=500000 | aplay -D plughw:2,0 -f S16_LE -r 44100 -c 2 --buffer-time=500000'
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Przeładowujemy konfigurację:

sudo systemctl daemon-reload

Usługę uruchamiamy poleceniem:

sudo systemctl start turntable.service

Status sprawdzamy przez:

sudo systemctl status turntable.service

Konflikt pomiędzy adapterem a Volumio

Podczas działania potoku arecord | aplay proces aplay zajmuje urządzenie HiFiBerry.

Volumio próbuje korzystać z tej samej karty dźwiękowej. Może więc pojawić się błąd:

device busy

Dlatego zestaw działa w dwóch rozłącznych trybach:

Tryb Aktywne źródło Zatrzymane procesy
Adapter ON Behringer → Raspberry Pi → HiFiBerry Volumio i MPD
Volumio ON Radio, Spotify lub AirPlay turntable.service, arecord i aplay

Usługa wejścia audio nie powinna uruchamiać się automatycznie przy starcie:

sudo systemctl disable turntable.service

Skrypt uruchamiający adapter

sudo nano /usr/local/bin/gramofon-on
#!/bin/bash

volumio stop 2>/dev/null || true
systemctl stop mpd 2>/dev/null || true
systemctl stop turntable.service 2>/dev/null || true

pkill arecord 2>/dev/null || true
pkill aplay 2>/dev/null || true

amixer -c 2 sset 'Digital' 90% unmute 2>/dev/null || true
volumio volume 80 2>/dev/null || true

systemctl start turntable.service

exit 0

Skrypt przywracający Volumio

sudo nano /usr/local/bin/gramofon-off
#!/bin/bash

systemctl stop turntable.service 2>/dev/null || true

pkill arecord 2>/dev/null || true
pkill aplay 2>/dev/null || true

sleep 1

systemctl restart mpd 2>/dev/null || true

sleep 2

volumio vrestart 2>/dev/null \
  || systemctl restart volumio.service 2>/dev/null \
  || true

sleep 5

volumio volume 80 2>/dev/null || true

exit 0

Skrypt sprawdzający status

sudo nano /usr/local/bin/gramofon-status
#!/bin/bash

echo "=== turntable.service ==="
systemctl status turntable.service --no-pager -l || true

echo ""
echo "=== arecord / aplay ==="
ps -ef | egrep 'arecord|aplay' | grep -v grep || true

echo ""
echo "=== audio users ==="
fuser -v /dev/snd/* 2>/dev/null || true

exit 0

Ustawiamy prawa:

sudo chown root:root \
  /usr/local/bin/gramofon-on \
  /usr/local/bin/gramofon-off \
  /usr/local/bin/gramofon-status

sudo chmod 755 \
  /usr/local/bin/gramofon-on \
  /usr/local/bin/gramofon-off \
  /usr/local/bin/gramofon-status

Panel WWW do przełączania trybów

Logowanie przez SSH za każdym razem byłoby niewygodne. Dlatego powstał prosty panel WWW działający na porcie 8090.

Panel udostępnia trzy akcje:

  • Gramofon ON – uruchamia wejście z Behringera,
  • Gramofon OFF / Volumio ON – przywraca streaming,
  • Status – pokazuje procesy korzystające z urządzeń audio.

Panel jest dostępny pod adresem:

http://ADRES_IP_VOLUMIO:8090

Przykładowo:

http://192.168.1.250:8090

Panel powinien być dostępny wyłącznie w sieci domowej. Portu 8090 nie należy wystawiać bezpośrednio do internetu.

Minimalne uprawnienia sudo

Panel działa jako użytkownik volumio, ale skrypty sterujące usługami wymagają uprawnień administratora.

Zamiast uruchamiać cały serwer Node.js jako root, nadajemy użytkownikowi możliwość wykonywania tylko konkretnych skryptów.

sudo visudo -f /etc/sudoers.d/zz_turntable_web

Dodajemy:

Cmnd_Alias TURNTABLE_CMDS = /usr/local/bin/gramofon-on, /usr/local/bin/gramofon-off, /usr/local/bin/gramofon-status
volumio ALL=(root) NOPASSWD: TURNTABLE_CMDS

Następnie:

sudo chown root:root /etc/sudoers.d/zz_turntable_web
sudo chmod 440 /etc/sudoers.d/zz_turntable_web
sudo visudo -c

Reguły testujemy poleceniami:

sudo -k
sudo -n /usr/local/bin/gramofon-status

sudo -k
sudo -n /usr/local/bin/gramofon-on

sudo -k
sudo -n /usr/local/bin/gramofon-off

Najczęstsze problemy

Volumio nie działa przez volumio.local

Należy użyć adresu IP:

ssh volumio@192.168.1.250
http://192.168.1.250
http://192.168.1.250:8090

Brak capture controls w Behringerze

W przypadku UCA202 jest to normalne. Wejście testujemy przez arecord, a nie suwaki w alsamixer.

Volumio nie gra po wyłączeniu adapteru

sudo systemctl stop turntable.service
sudo pkill arecord 2>/dev/null
sudo pkill aplay 2>/dev/null
sudo systemctl restart mpd 2>/dev/null
volumio vrestart 2>/dev/null \
  || sudo systemctl restart volumio.service

Dźwięk z adapteru jest bardzo cichy

Należy sprawdzić:

  • czy używane jest wyjście LINE OUT,
  • czy RCA są podłączone do wejścia INPUT Behringera,
  • czy poziom wejścia reaguje w arecord -V stereo,
  • czy HiFiBerry poprawnie odtwarza sygnał testowy,
  • czy regulator głośności adapteru wpływa na LINE OUT.

Procesy arecord lub aplay nadal działają

ps -ef | egrep 'arecord|aplay' | grep -v grep
sudo fuser -v /dev/snd/*
sudo pkill arecord 2>/dev/null
sudo pkill aplay 2>/dev/null

Czego nauczył mnie ten projekt?

Samo przekazanie dźwięku z Behringera do HiFiBerry można uruchomić jedną komendą. To jednak nie wystarczy, jeżeli zestaw ma być wygodny w codziennym użyciu.

Trzeba dodatkowo rozwiązać kilka typowo systemowych problemów:

  • wykrywanie urządzeń audio,
  • zarządzanie dostępem do współdzielonej karty dźwiękowej,
  • kontrolowanie procesów,
  • automatyzację za pomocą systemd,
  • ograniczenie uprawnień administratora,
  • udostępnienie prostego interfejsu użytkownika.

Mały domowy projekt audio okazał się więc dobrym przykładem integracji sprzętu, Linuksa, usług systemowych oraz prostej aplikacji webowej.

Podsumowanie

Finalnie powstał system pozwalający korzystać z tych samych pasywnych głośników zarówno podczas słuchania muzyki z adapteru lub gramofonu, jak i podczas streamowania przez Volumio.

Tor dla źródła analogowego wygląda następująco:

Adapter lub gramofon
→ Behringer UCA202
→ Raspberry Pi
→ HiFiBerry Amp2
→ pasywne głośniki

Volumio pozostaje natomiast źródłem radia internetowego, Spotify oraz AirPlay.

Przełączanie pomiędzy źródłami odbywa się z prostego panelu WWW, bez ręcznego logowania przez SSH.

Najważniejsza rekomendacja: w autostarcie powinien działać tylko panel WWW. Usługę przekazującą dźwięk z adapteru uruchamiamy dopiero w momencie wybrania trybu gramofonu.

poniedziałek, 22 czerwca 2026

{dev} forge - Jak pisać specyfikacje pod AI?

Jednym z największych nieporozumień ery AI-assisted development jest przekonanie, że wystarczy nauczyć się pisać lepsze prompty.

Przez ostatnie dwa lata internet zalały poradniki o prompt engineeringu:

  • jak pisać prompty,
  • jak używać odpowiednich słów,
  • jak budować role,
  • jak poprawnie instruować modele.

To wszystko jest przydatne.

Ale w większych projektach problem szybko przestaje dotyczyć promptów.

Problemem staje się jakość specyfikacji.



Bo niezależnie od tego, czy używasz Codex, Claude Code, Cursor, Gemini CLI czy OpenSpec – wszystkie te narzędzia mają jedną wspólną cechę:

Jakość wyjścia jest ograniczona jakością wejścia.

I właśnie dlatego umiejętność pisania specyfikacji pod AI staje się jedną z najważniejszych kompetencji nowoczesnego software engineeringu.

Największy błąd: traktowanie AI jak człowieka

Większość źle napisanych specyfikacji wynika z jednego założenia:

Autor zakłada, że AI rozumie kontekst tak samo jak człowiek.

To nieprawda.

Doświadczony developer potrafi:

  • dopytać o szczegóły,
  • wyłapać nieścisłości,
  • domyślić się intencji biznesowej,
  • rozpoznać brakujące wymagania.

AI działa inaczej.

Jeśli czegoś nie opiszesz, model najczęściej:

  • założy własną interpretację,
  • uzupełni luki statystycznie,
  • wygeneruje „najbardziej prawdopodobne” rozwiązanie.

To właśnie dlatego dobra specyfikacja dla AI musi być bardziej precyzyjna niż specyfikacja dla człowieka.

Zasada #1: Zacznij od intencji, nie od rozwiązania

Najczęstszy antywzorzec wygląda tak:

Dodaj tabelę customer_discount
oraz endpoint GET /discounts.

Problem?

Opisujesz rozwiązanie, a nie problem.

Znacznie lepiej napisać:

Intent:
Klienci premium powinni otrzymywać rabaty
zależne od wartości zakupów.

Business Goal:
Zwiększenie retencji klientów premium.

Success Metric:
Wzrost liczby ponownych zakupów o 10%.

W ten sposób AI rozumie nie tylko co ma zrobić, ale również dlaczego.

Zasada #2: Opisuj domenę przed implementacją

Większość projektów nie upada przez błędne API.

Upada przez błędne zrozumienie domeny.

Zanim opiszesz endpointy, opisz:

  • encje,
  • relacje,
  • słownik pojęć,
  • reguły biznesowe.

Przykład:

Entities:
- Customer
- LoyaltyAccount
- LoyaltyTransaction

Rules:
- Jeden klient może mieć tylko jedno konto lojalnościowe
- Punkty wygasają po 365 dniach
- Zwrot zamówienia usuwa przyznane punkty

AI dużo lepiej radzi sobie z implementacją, gdy najpierw rozumie model domenowy.

Zasada #3: Używaj przykładów zamiast opisów

To jedna z najważniejszych lekcji wyniesionych z BDD i Specification by Example.

Zamiast pisać:

System powinien poprawnie naliczać punkty.

Napisz:

Scenario:
Customer places order worth 100 PLN

Given:
Customer is Premium

When:
Order is completed

Then:
100 loyalty points are added

Dla AI przykład jest znacznie bardziej jednoznaczny niż ogólny opis.

Zasada #4: Dokumentuj edge case'y

Większość błędów nie pojawia się w głównym scenariuszu.

Pojawia się na obrzeżach systemu.

Dlatego dobra specyfikacja zawsze zawiera sekcję:

Edge Cases

Na przykład:

Edge Cases:

- Refund after points were spent
- Customer account merged
- Loyalty account deleted
- Promotion expired during checkout

Jeśli nie opiszesz edge case'ów, AI je wymyśli.

I nie zawsze będą to właściwe założenia.

Zasada #5: Definiuj kontrakty

AI świetnie generuje kod.

Jeszcze lepiej generuje kod na podstawie kontraktów.

Dlatego specyfikacja powinna zawierać:

  • API Contract
  • Event Contract
  • Data Contract

Przykład:

POST /loyalty/points

Request:
{
  "customerId": "123",
  "orderValue": 100
}

Response:
{
  "pointsAdded": 100,
  "currentBalance": 1200
}

To eliminuje ogromną część niejednoznaczności.

Zasada #6: Opisuj ograniczenia architektoniczne

AI nie zna architektury Twojej organizacji.

Dlatego trzeba ją opisać.

Na przykład:

Constraints:

- Java 21
- Spring Boot 3
- PostgreSQL
- Event-driven architecture
- Kafka only
- No synchronous communication

Dzięki temu AI nie zaproponuje rozwiązania sprzecznego z kierunkiem architektonicznym organizacji.

Zasada #7: Opisuj kryteria walidacji

Jednym z największych błędów jest kończenie specyfikacji na implementacji.

Dobra specyfikacja odpowiada również na pytanie:

Skąd będziemy wiedzieć, że rozwiązanie jest poprawne?

Przykład:

Validation:

- Unit tests coverage > 80%
- Integration tests pass
- API contract tests pass
- Loyalty points calculation verified

To pozwala AI nie tylko wygenerować kod, ale również zrozumieć sposób jego weryfikacji.

Przykład pełnej specyfikacji pod AI

Intent:
Introduce loyalty program.

Business Goal:
Increase customer retention.

Entities:
Customer
LoyaltyAccount
LoyaltyTransaction

Rules:
1 point per 1 PLN.
Points expire after 365 days.

Scenario:
Given Premium Customer
When Order Completed
Then Points Added

API:
POST /loyalty/points

Edge Cases:
Refunds
Expired points

Constraints:
Java 21
Spring Boot 3
Kafka

Validation:
Unit Tests
Contract Tests
Integration Tests

Zauważ, że taka specyfikacja jest:

  • krótka,
  • jednoznaczna,
  • łatwa do wersjonowania,
  • czytelna dla człowieka,
  • bardzo czytelna dla AI.

Najważniejsza zmiana mentalna

Przez wiele lat specyfikacja była czymś, co prowadziło do kodu.

W erze AI zaczyna być czymś więcej.

Specyfikacja staje się:

  • kontraktem,
  • źródłem prawdy,
  • interfejsem pomiędzy człowiekiem a AI.

I właśnie dlatego coraz częściej słyszymy o Spec-Driven Development.

Nie dlatego, że AI wymaga więcej dokumentacji.

Ale dlatego, że AI wymaga lepszej dokumentacji.

Podsumowanie

Jeśli miałbym sprowadzić cały artykuł do jednego zdania, brzmiałoby ono tak:

Nie pisz specyfikacji tak, jakby czytał ją człowiek. Pisz ją tak, jakby miała zostać wykonana przez maszynę.

Bo właśnie do tego zmierza nowoczesny software engineering.

Coraz częściej nie programujemy bezpośrednio systemów.

Projektujemy specyfikacje, które systemy budują.

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.