Miesiąc temu skończyłem projekt, który 3 lata wcześniej wymagałby zespołu 4-5 osób i minimum pół roku pracy.

Pełny brand. Strategia. Misja, wizja, wartości. UI/UX. Strona. Narzędzia wspierające. Sam. W ułamku tego czasu.

I nie chodzi o to, że jestem lepszy niż kiedyś. Chodzi o to, że moja rola się zmieniła.

Przez 16 lat w branży byłem programistą, który pisze kod. Dziś jestem dyrygentem, który orkiestruje jego powstawanie.

Stary model jest martwy

Tradycyjny developer to wykonawca. Dostaje ticket, pisze kod, pushuje, bierze następny ticket. Wartość mierzona w liniach kodu, commitach, story pointach.

Ten model umarł.

Nie dlatego, że AI “zabiera pracę”. Zabiera ją tym, którzy potrafią tylko wykonywać. Tym, którzy nie widzą szerszego obrazu. Tym, którzy nie potrafią myśleć biznesowo.

Reszcie? Reszcie zmienia zasady gry.

Framework: Dev jako Dyrygent

Moja praca dziś sprowadza się do trzech faz. Żadna z nich nie polega na pisaniu kodu.

Faza 1: Architekt Kontekstu

Zanim cokolwiek powstanie, buduję mapę.

W praktyce oznacza to:

• Rozplanowanie projektu w Asanie czy Jirze

• Zadania, opisy, kontekst, powiązania między elementami

• Rozbicie od ogółu do szczegółu - od wizji biznesowej do konkretnych komponentów

Co ciekawe - nawet to robię z AI. Claude pomaga mi strukturyzować myślenie, wyłapuje luki w planie, proponuje podział którego bym nie wymyślił.

Kluczowa umiejętność? Łączenie kropek. Widzenie jak decyzja w module A wpłynie na moduł B, C i całą architekturę za 6 miesięcy. To wymaga doświadczenia, którego AI nie ma - ale które AI potrafi wzmocnić.

Faza 2: Dyrygent Wykonania

Tu wchodzi Claude Code.

Próbowałem Copilota, próbowałem Cursora. Dla mnie to wciąż gloryfikowany autocomplete - zgaduje co chcę napisać, zamiast rozumieć co chcę zbudować.

Claude Code to coś innego. Daję mu zaplanowane zadanie z pełnym kontekstem. On realizuje. Pisze kod, tworzy struktury, implementuje logikę.

Moja rola? Pilnuję kierunku. Interweniuję gdy gubi kontekst (a gubi - okienko kontekstowe wciąż jest ograniczeniem). Dbam o spójność między komponentami. Orkiestruję, nie piszę.

To jak prowadzenie orkiestry. Nie gram na każdym instrumencie. Ale wiem, jak ma brzmieć całość.

Faza 3: Kontroler Jakości

Każdy kawałek kodu przechodzi przez moje ręce.

Sprawdzam go tak, jak sprawdzałbym pracę developera w zespole. Patrzę na rozwiązania, architekturę, edge cases, czytelność, maintainability.

Statystyka z mojego doświadczenia: około 80% jest ok od razu. 20% wymaga poprawek - czasem drobnych, czasem strukturalnych.

Te 20% to powód, dla którego “programista” wciąż jest potrzebny. AI nie wie, czego nie wie. Nie wyłapie, że rozwiązanie działa, ale za 3 miesiące będzie koszmarem do utrzymania. Nie zrozumie kontekstu biznesowego, który sprawia, że eleganckie rozwiązanie jest złym rozwiązaniem.

Tu 16 lat doświadczenia robi różnicę.

Co się zmieniło w mojej głowie

Przez lata budowałem tożsamość wokół umiejętności twardych. Znajomość języków, frameworków, patterns. To było moje CV, moja wartość.

Dziś? Te umiejętności stały się drugorzędne.

Liczą się:

• Ogarnianie szerszego kontekstu - nie wąska specjalizacja, ale rozumienie całości

• Myślenie biznesowe - nie “jak to zaimplementować” ale “czy to w ogóle warto implementować”

• Łączenie kropek - widzenie powiązań, których AI nie widzi

• Krytyczna ocena - filtrowanie tego co AI produkuje przez pryzmat doświadczenia

Brzmi jak opis roli architekta? Product ownera? Tech leada?

Dokładnie.

Granice się rozmyły. Developer który myśli tylko o kodzie jest jak muzyk który zna tylko nuty, ale nie rozumie muzyki.

Co to znaczy dla zespołów

Gdybym dziś budował zespół od zera, wyglądałby inaczej niż 3 lata temu.

Wtedy: Zespół specjalistów. Frontend dev, backend dev, DevOps, QA. Każdy w swojej działce.

Dziś: Zespół generalistów z drygiem do myślenia systemowego. Ludzie, którzy potrafią przeskakiwać między domenami, rozumieją biznes, umieją orkiestrować AI.

Wtedy: 8-10 osób na średni projekt.

Dziś: 2-3 osoby + AI na ten sam scope.

To nie znaczy, że specjalizacja umarła. Znaczy, że sama specjalizacja bez szerszego kontekstu straciła wartość.

Honest take: gdzie to nie działa

Nie jestem ewangelistą AI. Mam 2 lata doświadczenia z tym workflow i widzę ograniczenia.

Kontekst się gubi. Przy dużych projektach AI traci wątek. Wymaga ciągłego przypominania, re-feedowania kontekstem, pilnowania spójności. To kosztuje czas i uwagę.

Nie można ufać bezgranicznie. Każdy output wymaga weryfikacji. AI produkuje kod który działa, ale nie zawsze kod który jest dobry. To kwestia czasu - ale dziś tak jest.

Czas idzie gdzie indziej. Nie koduję, ale nie znaczy że mam wolne. Czas który szedł na pisanie, teraz idzie na planowanie i review. Ogromny progress i performance - ale nic innego już nie zrobię. Praca się transformowała, nie zniknęła.

Wymaga seniorności. To nie narzędzie dla kogoś, kto nie wie co robi. Musisz wiedzieć jak powinien wyglądać dobry kod, żeby ocenić czy AI go wyprodukował. Musisz rozumieć architekturę, żeby ją zaprojektować dla AI.

Junior z AI to wciąż junior. Senior z AI to siła, której branża jeszcze nie ogarnia.

Co dalej

Dziś jest łatwiej niż kiedykolwiek. Jutro będzie jeszcze prościej.

Okienka kontekstowe będą większe. Modele będą lepiej utrzymywać spójność. Zaufanie do outputu będzie rosło.

Ale fundamentalna zmiana już się dokonała.

Dev przestał być pisarzem kodu. Stał się architektem myśli, dyrygentem wykonania i kontrolerem jakości.

Ci, którzy to zrozumieją, zbudują więcej, szybciej, lepiej. Ci, którzy będą bronić starego modelu, zostaną w tyle.

Wybór jest prosty. Wykonanie - trudniejsze.

Jak wygląda Twoje doświadczenie z AI w development? Orkiestrujesz czy wciąż piszesz każdą linijkę sam?