AI-Assisted Engineering: Dlaczego AI nie zastąpi programisty, ale programista bez AI zostanie w tyle

Wrzucasz prompt do ChatGPT, dostajesz gotową stronę internetową, wdrażasz na serwer i idziesz na kawę. Brzmi pięknie, prawda? Problem w tym, że tak to nie działa. I jeszcze długo nie będzie działać, wbrew temu, co wieszczą LinkedInowi guru. 

Ale jest druga strona tego medalu. Jeśli w 2025 roku nadal piszesz każdą linijkę kodu ręcznie, ręcznie szukasz w dokumentacji składni funkcji, którą używałeś sto razy, i nie korzystasz z żadnego narzędzia AI w swoim workflow to po prostu oddajesz przewagę konkurencyjną. I to sporą.

Porozmawiajmy o tym, jak wygląda realna praca z AI w inżynierii oprogramowania. Bez marketingowego bełkotu, bez obietnic że „AI zrobi wszystko”, ale też bez udawania, że te narzędzia nie istnieją.

AI nie zbuduje za Ciebie strony. Kropka.

Zacznijmy od słonia w pokoju. Mimo że modele językowe potrafią dziś generować kod, który kompiluje się i uruchamia, to daleka droga od „zbudowania produktu”. Kod to nie jest produkt. Produkt to architektura, decyzje biznesowe, UX, bezpieczeństwo, wydajność, utrzymywalność i tysiąc innych rzeczy, o których AI nie ma pojęcia, jeśli mu o nich nie powiesz.

Wrzuć do dowolnego agenta kodującego prompt „zrób mi sklep internetowy” i zobacz co dostaniesz. Dostaniesz coś, co wygląda jak sklep internetowy. Będzie miało produkty, koszyk, może nawet jakiś formularz zamówienia. Ale pod spodem? Brak obsługi płatności zgodnej z PCI DSS, brak obsługi RODO, zero testów, architektura, która padnie przy pierwszych stu użytkownikach, i CSS, który rozjedzie się na każdym urządzeniu innym niż to, na którym testowała AI.

AI generuje kod. Nie podejmuje decyzji architektonicznych. Nie zna Twojego biznesu. Nie wie, że Twój klient potrzebuje integracji z konkretnym systemem ERP, albo że regulacje w Twojej branży wymagają logowania każdej operacji. To nadal jest Twoja robota.

Ale ignorowanie AI to strzelanie sobie w stopę

Skoro AI nie zrobi wszystkiego, to po co z tego korzystać? Bo robi cholernie dużo.

Pomyśl o tym w ten sposób: AI to nie jest zastępczy programista. To jest turbodoładowanie dla programisty, który wie co robi. Różnica między developerem, który korzysta z AI, a developerem, który tego nie robi, nie polega na tym, że jeden pisze lepszy kod. Polega na tym, że jeden dostarcza rozwiązanie w dwa dni, a drugi w dwa tygodnie.

Generowanie boilerplate’u, scaffolding nowych komponentów, pisanie testów jednostkowych, refaktoryzacja istniejącego kodu, generowanie dokumentacji, tłumaczenie między językami programowania, debugowanie dziwnych edge case’ów: to wszystko rzeczy, które AI robi szybko i dobrze. Nie perfekcyjnie, ale wystarczająco dobrze, żeby zaoszczędzić Ci godziny ręcznej roboty każdego dnia.

Kluczowe słowo to „wystarczająco dobrze”. AI nie wyprodukuje kodu produkcyjnego, który możesz ślepo wdrożyć. Ale wyprodukuje solidną bazę, którą doświadczony developer przejrzy, poprawi i doprowadzi do stanu produkcyjnego w ułamku czasu, który potrzebowałby na pisanie tego od zera.

Wiedza domenowa jako mnożnik: zasada 80%

I tu dochodzimy do sedna sprawy. AI w rękach juniora i AI w rękach seniora to dwa kompletnie różne narzędzia.

Junior poprosi AI o „stworzenie formularza logowania” i dostanie formularz logowania. Senior poprosi AI o „stworzenie formularza logowania z walidacją po stronie klienta i serwera, obsługą CSRF tokenów, rate limitingiem na endpoincie, zgodnego z WCAG 2.1 AA, używającego istniejącego design systemu z katalogu /components/ui” — i dostanie coś, co faktycznie można wdrożyć.

Różnica nie leży w AI. Leży w osobie, która z nim rozmawia.

W dobrych rękach, z solidną wiedzą domenową i umiejętnością precyzyjnego komunikowania wymagań, AI jest w stanie wykonać 80% pracy. Tych 80% to najczęściej powtarzalna, mechaniczna robota: generowanie struktur, implementowanie znanych wzorców, pisanie testów, tworzenie migracji bazy danych, konfiguracja narzędzi. Pozostałe 20% — decyzje architektoniczne, code review, optymalizacja, rozwiązywanie niestandardowych problemów — to nadal domena człowieka.

I właśnie ta proporcja 80/20 sprawia, że AI-Assisted Engineering ma sens. Nie chodzi o zastąpienie programistów. Chodzi o to, żeby programiści mogli skupić się na tych 20%, które faktycznie wymagają ludzkiej kreatywności i doświadczenia, zamiast tracić czas na klepanie boilerplate’u.

Dokumentacja wdrożeniowa: fundament, o którym wszyscy zapominają

Teraz przechodzimy do czegoś, o czym mało kto mówi w kontekście AI-Assisted Engineering, a co w praktyce okazuje się absolutnie kluczowe: dokumentacja wdrożeniowa.

Wiesz, dlaczego większość ludzi narzeka, że „AI generuje byle jaki kod”? Bo dają AI zerowy kontekst. Piszą „zrób mi REST API” i są zaskoczeni, że AI nie wie, że projekt używa NestJS z Prisma, że autoryzacja idzie przez Keycloak, że baza danych to PostgreSQL 16, i że konwencja nazewnictwa w zespole wymaga snake_case w endpointach.

AI działa tak dobrze, jak dobry jest kontekst, który mu dostarczysz. I tu wchodzi dokumentacja wdrożeniowa.

Dobra wiadomość jest taka, że tę dokumentację też możesz stworzyć z pomocą AI. Opisz mu swój projekt w rozmowie, opowiedz o stacku technologicznym, o konwencjach, o architekturze — a potem poproś o wygenerowanie ustrukturyzowanej dokumentacji. Następnie ją przejrzyj, popraw, uzupełnij o rzeczy, które AI nie mogło wiedzieć, i masz gotowy fundament pod produktywną współpracę z agentem kodującym.

AGENTS.md: Twój plik konfiguracyjny dla AI

Jeśli pracujesz z agentami kodującymi jak Claude Code czy OpenAI Codex, jednym z najpotężniejszych narzędzi w Twoim arsenale jest plik AGENTS.md (w przypadku Claude Code nazywa się on CLAUDE.md, ale idea jest identyczna).

To plik markdown umieszczany w katalogu głównym projektu, który zawiera wszystko, co AI musi wiedzieć, żeby generować kod zgodny z Twoim projektem. Pomyśl o nim jak o onboardingu dla nowego developera, tyle że tym developerem jest AI.

Co powinien zawierać taki plik? Przede wszystkim opis architektury projektu i użytych technologii. Jakie frameworki, jakie biblioteki, jaka struktura katalogów. Dalej — konwencje kodowania: formatowanie, nazewnictwo, wzorce projektowe, które stosujecie w zespole. Potem informacje o środowisku: jak uruchomić projekt, jakie zmienne środowiskowe są potrzebne, jak wyglądają procesy CI/CD. Na koniec — zasady i ograniczenia specyficzne dla projektu: co wolno, czego nie wolno, jakie są wymagania bezpieczeństwa, jakie standardy muszą być spełnione.

Ten plik to Twoja kotwica. Bez niego AI będzie zgadywać i generować kod w stylu „generycznym”, który może nie pasować do Twojego projektu. Z nim — AI pracuje w ramach ustalonych przez Ciebie reguł. To różnica między chaotycznym „vibe codingiem” a systematycznym, powtarzalnym procesem inżynieryjnym.

Warto dodać, że AGENTS.md to nie jest rzecz, którą piszesz raz i zapominasz. To żywy dokument, który ewoluuje razem z projektem. Dodajesz nową bibliotekę? Zaktualizuj plik. Zmieniacie konwencję nazewnictwa? Zaktualizuj plik. To niewielki nakład pracy, który procentuje przy każdej interakcji z AI.

Skills: uczenie AI Twoich narzędzi i metod

AGENTS.md daje AI kontekst o projekcie. Ale co z kontekstem o konkretnych technologiach i metodologiach?

Tu wchodzą pliki Skills. To kolejny element ekosystemu AI-Assisted Engineering, który zyskuje ogromną popularność. Skill to folder zawierający plik SKILL.md z instrukcjami, skryptami i zasobami, które uczą agenta AI, jak korzystać z konkretnej technologii lub wykonywać konkretne zadanie.

Wyobraź sobie, że Twój projekt używa specyficznego frameworka do testów, albo ma niestandardowy proces deploymentu, albo wymaga generowania dokumentów w konkretnym formacie. Zamiast za każdym razem opisywać te rzeczy w prompcie, tworzysz Skill – raz, porządnie – i od tego momentu AI wie, jak to robić.

Format SKILL.md został pierwotnie opracowany przez Anthropic i szybko stał się otwartym standardem przyjętym przez większość agentów kodujących na rynku: Claude Code, OpenAI Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf i wiele innych.

I co najlepsze — nie musisz pisać wszystkich Skills od zera. Istnieje rosnący ekosystem gotowych do użycia Skills tworzonych przez społeczność i firmy technologiczne.

skills.sh: otwarte repozytorium gotowych Skills

Jednym z najciekawszych miejsc w tym ekosystemie jest skills.sh — otwarty katalog i leaderboard Agent Skills. Na moment pisania tego artykułu zawiera ponad 36 000 Skills, które możesz zainstalować jedną komendą:

npx skills add <owner/repo>

Znajdziesz tam Skills od Vercela z best practices dla React i Next.js, oficjalne Skills od Anthropic dotyczące tworzenia dokumentów i projektowania frontendu, Skills do code review, optymalizacji SEO, pracy z konkretnymi frameworkami i dziesiątki innych kategorii.

Warto tam zajrzeć nie tylko po gotowe Skills do instalacji, ale też po inspirację do tworzenia własnych. Bo tak naprawdę najcenniejsze Skills to te, które napiszesz sam — dopasowane do Twojego projektu, Twojego zespołu i Twoich procesów.

Istnieją też inne marketplace’y: SkillsMP, SkillsDirectory czy oficjalne repozytoria Anthropic i OpenAI na GitHubie. Ekosystem rośnie szybko i warto go śledzić.

Claude Code vs Codex: dwa podejścia do tego samego problemu

Na rynku agentów kodujących wyraźnie wyłoniła się dwójka liderów: Claude Code od Anthropic i Codex od OpenAI. Oba narzędzia rozwiązują ten sam problem — pomagają programistom pisać kod szybciej i lepiej — ale robią to w fundamentalnie odmienny sposób.

Claude Code to interaktywny partner do pair programmingu. Działa w Twoim terminalu, lokalnie, na Twoim kodzie. Filozofia jest prosta: programista prowadzi, AI asystuje. Claude Code jest wyjątkowy w głębokim rozumowaniu nad kodem, wyjaśnianiu swoich decyzji i zadawaniu pytań, zanim zacznie działać. Ma ogromne okno kontekstowe (200 000 tokenów, rozszerzalne do miliona), natywne wsparcie dla MCP (Model Context Protocol), rozbudowany system Skills i poleceń slash. Claude Code sprawdza się szczególnie przy złożonych refaktoryzacjach, pracy z dużymi bazami kodu i zadaniach wymagających zrozumienia szerszego kontekstu architektonicznego. Wymaga więcej konfiguracji (CLAUDE.md, Skills, MCP), ale ta inwestycja procentuje lepszymi wynikami. Wielu developerów opisuje go jako „senior developera, z którym konsultujesz decyzje”.

Codex to autonomiczny agent, któremu delegujesz zadania. Działa w chmurze, w izolowanych sandboxach, i zwraca gotowe wyniki. Filozofia: napisz dobrą specyfikację, wyślij zadanie, idź robić coś innego, wróć po wyniki. Codex napędzany modelem GPT-5 jest wyjątkowo efektywny pod względem zużycia tokenów (często 3x mniej niż Claude przy tym samym zadaniu), co przekłada się na niższe koszty i możliwość generowania większych ilości kodu w ramach jednego planu. Ma głęboką integrację z GitHubem — potrafi bezpośrednio tworzyć PR-y i działać w tle. Sprawdza się świetnie, gdy masz jasno zdefiniowane zadanie i chcesz je po prostu zlecić.

Który wybrać? Szczerze mówiąc — oba, w zależności od sytuacji. Claude Code do eksploracji, planowania architektury, złożonych refaktoryzacji i zadań wymagających interakcji. Codex do jasno zdefiniowanych zadań implementacyjnych, które możesz zlecić i odebrać gotowe. Coraz więcej doświadczonych developerów pracuje właśnie w takim hybrydowym modelu, używając mocnych stron każdego narzędzia tam, gdzie mają największy sens.

Warto też wspomnieć, że oba narzędzia wspierają format Skills i pliki AGENTS.md/CLAUDE.md, więc Twoja inwestycja w dokumentację i konfigurację przenosi się między nimi.

Context Engineering: umiejętność, której nie uczą na bootcampach

Jest jeszcze jedna rzecz, o której chcę wspomnieć, bo uważam ją za kluczową, a rzadko pojawia się w dyskusjach o AI-Assisted Engineering.

Tradycyjny programista miał zestaw umiejętności: znajomość języka programowania, frameworków, wzorców projektowych, narzędzi. Programista pracujący z AI potrzebuje tego wszystkiego plus jedną dodatkową umiejętność: context engineering.

Context engineering to sztuka dostarczania AI właściwego kontekstu we właściwym momencie. To umiejętność pisania AGENTS.md, tworzenia Skills, strukturyzowania promptów, decydowania co AI musi wiedzieć, a czego nie musi, i budowania pipeline’u informacyjnego, który sprawia, że AI konsekwentnie generuje kod spójny z projektem.

To nie jest prompt engineering — to coś więcej. Prompt engineering to optymalizacja pojedynczego zapytania. Context engineering to projektowanie całego środowiska informacyjnego, w którym AI operuje. AGENTS.md, Skills, konfiguracja MCP, konwencje nazewnictwa plików, struktura katalogów — to wszystko jest częścią context engineeringu.

I szczerze? To chyba najważniejsza nowa umiejętność, którą programiści powinni rozwijać w 2025 i 2026 roku. Bo AI będzie stawało się coraz lepsze, modele będą coraz potężniejsze, ale różnica w jakości wyników między developerem, który umie dostarczyć kontekst, a developerem, który tego nie umie, będzie rosła, nie malała.

Na koniec: zmiana roli, nie koniec roli

AI-Assisted Engineering nie eliminuje potrzeby inżynierów oprogramowania. Zmienia natomiast to, na czym spędzają czas.

Mniej klepania boilerplate’u. Więcej myślenia o architekturze. Mniej ręcznego pisania testów. Więcej projektowania strategii testowania. Mniej walki ze składnią. Więcej rozwiązywania prawdziwych problemów biznesowych.

To jest ewolucja roli, nie jej eliminacja. I jeśli miałbym streścić cały ten artykuł w jednym zdaniu, brzmiałoby ono tak: AI nie zrobi za Ciebie strony, ale programista, który umie z AI współpracować, zrobi tę stronę trzy razy szybciej niż ten, który tego nie umie.

Warto być tym pierwszym.