Kategoria: Insights PL

Kwiecień 2024. Właśnie wrzuciłem pierwszą działającą wersję naswoim.org na produkcję. Aplikacja działa. Użytkownicy mogą się logować. Dane są w Supabase. Na papierze — sukces.

Pod maską: dwa konkurujące ze sobą design systemy, siedemnaście zduplikowanych funkcji pomocniczych rozsianych po dwunastu plikach i polityka Supabase RLS, która po cichu zawodzi w jednym konkretnym przypadku brzegowym — który odkryję dopiero za trzy tygodnie.

Vibe coding działa. Ale zawodzi w sposób niewidoczny — aż przestaje być niewidoczny.

Szybki kontekst: co zbudowałem

W ciągu mniej więcej dwunastu miesięcy zbudowałem trzy aplikacje z użyciem vibe codingu — prawie bez zewnętrznych developerów:

• naswoim.org — platforma dla inwestorów budowlanych: checklisty, budżety, dokumenty, marketplace ekspertów, mapy działek, asystent AI. Web + Android + iOS + portal admina.
• industrverse.com — B2B SaaS do szkoleń VR w przemyśle: 7 ról użytkowników, 9 dashboardów na rolę, komunikacja real-time, gateway sesji VR, pełne API backendu.
• marcinpaszkiewicz.com — ta strona. Astro SSR + WordPress headless. Prostsza, ale też pouczająca.

Claude Code był moim głównym narzędziem, z okazjonalną pomocą Cursora. Napisałem w ten sposób gdzieś między 40 000 a 60 000 linii kodu produkcyjnego. Wszystko wyszło. Wszystko działa.

Oto co zrobiłem źle.

Błąd #1: Pozwoliłem AI wybrać architekturę

Kiedy zaczynałem naswoim.org, opisałem projekt Claude’owi i zapytałem, jaki stack poleca. Dostałem solidną odpowiedź: React 19, Vite, Supabase, Tailwind CSS 4. Świetne wybory.

Potem zapytałem o komponenty UI. Zaproponował MUI 7. Zgodziłem się — był szybki, miał wszystko czego potrzebowałem.

Problem: już używałem Tailwind CSS 4. Teraz miałem dwa design systemy:

Co bym zrobił inaczej: napisał jednostronicowy dokument decyzji architekturalnych przed pierwszym promptem. Nie pełna specyfikacja — tylko: co jest jedynym źródłem prawdy o stylach? Jakie jest podejście do zarządzania stanem? Jak dzielimy moduły? Daj AI ograniczenia, nie blank permission.

Błąd #2: AI nigdy nie mówi „nie” — i to jest niebezpieczne

Po trzech miesiącach pracy nad industrverse backend miał 13 modułów NestJS, 7 ról użytkowników i 9 osobnych dashboardów. Każda rola miała własną logikę dostępu do danych, własny system powiadomień, własny workflow.

Nic z tego nie było w oryginalnej specyfikacji.

Oto co się dzieje: masz pomysł o 23:00. Opisujesz go Claude’owi. Buduje go w dwadzieścia minut. Działa. Wrzucasz to. Trzy tygodnie później zauważasz, że dodanie tej funkcji zepsuło model mentalny dla następnej funkcji. Ale AI ci tego nie mówi — po prostu buduje to, o co go prosisz.

Każdy developer w zespole ma kolegę, który mówi „chwila — czy na pewno tego potrzebujemy?” AI nie mówi chwila. AI mówi tak.

Mam teraz regułę przed każdą nową funkcją: piszę jedno zdanie o tym, jaki problem rozwiązuje dla konkretnego użytkownika. Jeśli nie potrafię tego zdania napisać, nie piszę promptu.

Błąd #3: Debugowanie kodu, którego nie pisałeś, jest wolniejsze niż wygląda

W naswoim.org miałem błąd w politykach Supabase Row Level Security. Użytkownicy w jednej roli mogli okazjonalnie widzieć dokumenty, których nie powinni — ale tylko gdy wcześniej zaszła konkretna sekwencja operacji.

Szukanie tego zajęło mi trzy dni.

Nie dlatego, że błąd był skomplikowany. Dlatego, że kod był generowany przez AI i nie przeczytałem go wystarczająco uważnie w momencie powstawania. Polityka RLS wyglądała poprawnie. Była poprawna składniowo. Przechodziła moje podstawowe testy. Przypadek brzegowy był subtelny — kombinacja dwóch różnych warunków polityki, które oddziaływały na siebie w nieoczywisty sposób.

Kiedy piszesz kod sam, budujesz model mentalny w trakcie pisania. Kiedy pisze AI, recenzujesz — co jest szybsze, ale płytsze. Model w głowie jest mniej kompletny. A płytkie modele mentalne spowalniają debugowanie.

Błąd #4: Kontekst się kończy — i AI „zapomina” wszystko

W długiej sesji Claude Code widzi wszystko, co razem zbudowaliście. Zna Twoje konwencje nazewnicze, wzorce, preferencje. Jest spójny.

W następnej sesji zaczyna od zera.

W naswoim.org zacząłem nową sesję po dwudniowej przerwie i poprosiłem Claude’a o zbudowanie nowego komponentu. Wygenerował coś, co działało — ale używało zupełnie innych wzorców niż reszta kodu. Inne podejście do zarządzania stanem. Inny styl obsługi błędów. Inne nazewnictwo.

Po czterech miesiącach codebase miał trzy wyraźne „ery” — każda odzwierciedlająca konwencje z rozmów prowadzonych w danym czasie.

Błąd #5: Security jest niewidoczna — dopóki nie jest

AI generuje działający kod. Nie generuje niezawodnie bezpiecznego kodu.

W industrverse miałem endpoint API dostępny tylko dla użytkowników z rolą „trainer”. Endpoint działał poprawnie. Zwracał właściwe dane. Obsługiwał błędy elegancko.

Nie weryfikował też roszczenia roli JWT przy jednej konkretnej metodzie HTTP. Użytkownik z dowolnym uwierzytelnionym tokenem mógł go wywołać.

Znalazłem to podczas ręcznego przeglądu bezpieczeństwa — nie dlatego, że Claude to oznaczył, nie dlatego, że moje testy to wyłapały. Bo pewnego popołudnia usiadłem i przeczytałem każdy endpoint związany z auth.

Co bym zrobił inaczej: 6 reguł

Gdybym zaczynał dzisiaj, z całą tą wiedzą:

Czego nie mówię

Nie mówię, że vibe coding jest wadliwy ani że narzędzia AI są zawodne. Wszystkie trzy projekty, które zbudowałem, działają. Mają prawdziwych użytkowników. Rozwiązują prawdziwe problemy. Zysk produktywności jest realny — zbudowałem w rok to, co trzyosobowy zespół zrobiłby w osiemnaście miesięcy.

Mówię, że tryby awarii są konkretne i nieoczywiste na starcie.

Największe ryzyko w vibe codingu nie jest to, że AI pisze zły kod. Jest to, że AI pisze kod, który wygląda dobrze — aż coś idzie nie tak. I wtedy patrzysz na codebase, który na wpół rozumiesz, z bugiem, którego nie napisałeś, i modelem mentalnym mającym luki dokładnie w złych miejscach.

Prędkość jest realna. Zbuduj nawyki, które sprawią, że będzie bezpieczna.

W lutym 2025 roku Andrej Karpathy — współzałożyciel OpenAI i były szef AI w Tesli — wrzucił post na X, który zmienił sposób, w jaki branża rozmawia o programowaniu. Napisał: „There’s a new kind of coding I call 'vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

Do marca Merriam-Webster dodał termin do słownika jako „slang & trending”. W grudniu 2025 Collins Dictionary ogłosił vibe coding słowem roku. W tym samym roku pojawiło się kilkanaście recenzowanych prac naukowych próbujących odpowiedzieć na pytanie, które branża zadawała sobie od miesięcy: czy to naprawdę działa?

Odpowiedź jest bardziej złożona niż większość nagłówków sugeruje.

Definicja, którą warto uściślić

Vibe coding to nie to samo co no-code. Nie chodzi też o kopiowanie odpowiedzi z ChatGPT. Badacze z ICSE 2026 definiują go jako iteracyjny cykl: sformułowanie celu w języku naturalnym → prompt → przegląd kodu → test → korekta. Człowiek jest product ownerem i architektem. AI — partnerem implementacyjnym.

To zmienia wymagania względem dewelopera, ale ich nie eliminuje. Nie musisz wiedzieć, jak napisać hook React z optymistyczną aktualizacją UI. Musisz wiedzieć, że jej potrzebujesz i dlaczego.

Co mówią badania — produktywność

W 2025 roku ukazało się kilka istotnych prac. Zebrałem dane z najważniejszych.

Co mówią badania — jakość kodu

Tutaj dane są mniej wygodne dla entuzjastów vibe codingu.

GitClear przeanalizował 211 milionów zmienionych linii kodu z lat 2020–2024 i wskazał na zjawisko, które nazywa AI-induced tech debt. Wyniki są niepokojące:

Niezależna analiza CodeRabbit z grudnia 2025 (470 pull requestów) potwierdziła: kod z udziałem AI zawiera 1,7x więcej poważnych błędów — głównie błędy logiczne, wadliwy control flow i błędne zależności.

Paradoks vibe codingu: 55% szybciej, ale 2,74x więcej luk bezpieczeństwa. Obie liczby są prawdziwe jednocześnie.

Refaktoryzacja kodu spadła z 25% zmienionych linii w 2021 do poniżej 10% w 2024. Duplikacja wzrosła 8-krotnie. Copy-paste code przewyższył moved code po raz pierwszy od dwóch dekad.

Porównanie narzędzi do vibe codingu

Ekosystem rozwinął się błyskawicznie. Dwie kategorie: asystenci w IDE (Claude Code, Cursor, Windsurf, Codex) i app buildery (Lovable, Bolt, v0). Różnią się fundamentalnie grupą docelową i use case.

SWE-bench: jak mierzy się realne zdolności agentów

SWE-bench Verified to benchmark oparty na prawdziwych bugach z GitHuba — nie syntetycznych zadaniach. Model dostaje repozytorium i issue, musi samodzielnie napisać patch, który przejdzie testy. Najbardziej wiarygodny pomiar zdolności agenta do realnego programowania.

Które narzędzie wybrać — mapa decyzji

Vibe coding — co z tego wynika

Karpathy, który ukuł termin, rok później przyznał publicznie, że do swojego nowego projektu napisał kod ręcznie — bo wymagał precyzji, której vibe coding nie dał. To dobra metafora dla całego zjawiska.

Vibe coding nie zastępuje programowania. Radykalnie obniża próg wejścia — i tyle. Dane pokazują 55% wzrost prędkości przy 2,74x więcej lukach bezpieczeństwa. Obydwie liczby są prawdziwe jednocześnie. Pytanie nie brzmi „czy używać AI do pisania kodu” — to pytanie jest już za nami.

Pytanie brzmi: kiedy wchodzi człowiek i bierze odpowiedzialność za to, co AI napisało? W prototypie — może nigdy. W systemie, który przetwarza dane użytkowników — zawsze, zanim kod trafi do produkcji.

Źródła: Karpathy (X, luty 2025) · arxiv 2510.00328 / 2510.12399 (ICSE 2026) · IJSAT 2025 · GitHub/Microsoft Research 2024 (n=95) · GitClear 2025 (211M linii) · CodeRabbit (470 PR, grudzień 2025) · ZoomInfo Enterprise Study (styczeń 2025) · METR RCT arxiv 2507.09089 · arxiv 2601.15494 „Vibe Coding Kills OSS” · arxiv 2603.14133 · Faros AI (22K deweloperów) · SWE-bench (kwiecień 2026) · Collins Dictionary Word of the Year 2025

Ostatnio szukałem konkretnego sprzętu do kupienia. Zamiast najpierw przemyśleć czego tak naprawdę potrzebuję, otworzyłem ChatGPT i napisałem zapytanie. Dostałem odpowiedź. Podjąłem decyzję. Sprawną, szybką — ale cudzą.

Zorientowałem się po fakcie, że nawet nie sformułowałem własnego zdania. AI wypełniło lukę zanim w ogóle zdążyła powstać.

To niegroźne przy zakupie słuchawek. W rekrutacji — już niekoniecznie.

Dlaczego w HR to ma większe znaczenie niż gdzie indziej

W większości zawodów jeśli AI „pomyśli za Ciebie” — konsekwencją jest gorszy dokument, stracona godzina, poprawka w arkuszu. W HR konsekwencją jest człowiek, który nie dostał pracy na którą zasługiwał. Albo firma, która zatrudniła kogoś, kto na papierze pasował idealnie — i się nie sprawdził.

AI w rekrutacji operuje na danych o ludziach. To jedyna dziedzina, gdzie błąd modelu ma twarz.

Działy HR sięgają po AI coraz częściej i słusznie — narzędzia rzeczywiście odciążają od powtarzalnej pracy. Ale jest subtelna różnica między „AI przyspiesza moją pracę” a „AI myśli zamiast mnie”. I ta różnica w rekrutacji jest kluczowa.

Gdzie AI w HR naprawdę pomaga

Zanim przejdę do ostrzeżeń — fair use. Dane mówią wyraźnie, gdzie modele językowe robią robotę dobrze:

Wzorzec jest czytelny: AI jest najchętniej adoptowane do zadań powtarzalnych i administracyjnych. To też miejsca, gdzie błąd modelu jest łatwy do wychwycenia i poprawienia. Konkretne narzędzia do poszczególnych zadań:

Gdzie zaczyna się problem

Problem pojawia się, gdy AI wkracza w obszary wymagające ludzkiego osądu — i robi to niepostrzeżenie.

Framework: najpierw Ty, potem AI

Zasada, którą stosuję w swojej pracy i którą proponuję działom HR:

AI jest jak dobry asystent — nie jak dobry rekruter

Dobry asystent odciąży Cię od papierkologii, przyśpieszy research, przygotuje szkice. Ale nie zastąpi Twojej oceny człowieka. Nie wyczuje napięcia w głosie kandydata. Nie zauważy, że ktoś jest świetny mimo niedoskonałego CV. Nie poczuje, że mimo idealnych kompetencji — ktoś nie pasuje do kultury Waszego zespołu.

Te rzeczy są nieprzenoszalne. I właśnie dlatego są Twoją przewagą — niezależnie od tego ile modeli pojawi się na rynku.

Narzędzia wymienione w artykule: Granola (granola.so) | ChatGPT (openai.com) | Claude (claude.ai) | Bielik (speakleash.org) | Dane: LinkedIn Talent Trends 2024

2018 rok. Stoimy z grupą operatorów w hali odlewni Krakodlew. Za chwilę zakładają gogle VR i pierwsze raz w życiu wchodzą do wirtualnego środowiska pracy. Jeden z nich — 20 lat przy piecu, doświadczony — mówi do mnie: „To dla młodych. Ja swoje wiem.”

Dwie godziny później ten sam człowiek pyta, kiedy jest następna sesja.

Nauczanie technologii — szczególnie AI i narzędzi opartych na AI — ma ten sam wzorzec. Bariera wejścia jest psychologiczna, nie techniczna. I kiedy ją pokonasz właściwą metodą, reszta przychodzi zaskakująco szybko.

W ciągu ostatnich kilku lat pracowałem z ludźmi, którzy nigdy nie napisali linii kodu: operatorami maszyn, menedżerami produkcji, kadrą zarządzającą, studentami szkół zawodowych. Oto co faktycznie działa.

Błąd nr 1: zacznij od technologii

Większość kursów i warsztatów AI zaczyna tak: „Dziś poznasz modele językowe. LLM to model trenowany na dużych zbiorach danych…”

Tracisz ucznia w czwartym zdaniu.

Dorośli uczą się inaczej niż dzieci. Nie przyswajają abstrakcji a potem szukają zastosowania — przyswajają konkret i potem szukają teorii, która go wyjaśnia. Andragogika (pedagogika dorosłych) mówi to od lat sześćdziesiątych. Problem w tym, że większość instruktorów AI to inżynierowie, którzy uczą tak, jak sami się uczyli.

W odlewni nie zaczęliśmy od „jak działa VR”. Zaczęliśmy od: „Pokażę ci sytuację, w której doszło do wypadku w podobnym zakładzie. Jak byś zareagował?” Technologia stała się narzędziem do rozwiązania konkretnego, realnego problemu. Nie demonstracją.

Framework, który działa: „Dotknij, potem wyjaśnij”

W szkoleniach VR wypracowałem sekwencję, którą nazywam „dotknij, potem wyjaśnij”. Działa tak samo w nauce AI i vibe codingu:

• 1. Zrób to razem — nie wyjaśniaj najpierw. Daj uczestnikowi proste zadanie do wykonania od razu. Błąd w bezpiecznym środowisku to więcej niż godzina wykładu.
• 2. Nazwijcie to wspólnie — kiedy coś zadziała (lub nie), zapytaj: „Co się stało? Dlaczego, jak myślisz?” Uczeń buduje model mentalny z własnego doświadczenia.
• 3. Teraz wyjaśnij mechanizm — dopiero po tym pojęcia takie jak „token”, „kontekst”, „temperatura” mają znaczenie. Bo masz konkretną sytuację, do której można je przykleić.
• 4. Daj im problem do rozwiązania samodzielnie — nie „ćwiczenie z instrukcją”. Problem, którego nie rozwiązywałeś z nimi wcześniej.

Te liczby dotyczą VR, ale wzorzec jest ten sam: kiedy uczysz przez działanie, a nie przez słuchanie, wyniki są drastycznie inne.

Co blokuje uczenie się AI — i jak to usunąć

Nauczając AI i vibe coding, napotkasz kilka stałych barier:

„To nie dla mnie, jestem za stary / za mało techniczny”

Antidotum: pokaż konkretny przykład osoby podobnej do ucznia, która to robi. Nie Elona Muska. Kogoś, kto prowadzi mały biznes i używa Claude do pisania ofert. Kogoś, kto jest operatorem i nauczył się programować robota na kursie. Identyfikacja przed aspiracją.

„Nie wiem, co powiedzieć do AI”

Antidotum: daj szablony. Nie jako sztywne formularze, ale jako punkty startowe. „Jestem [rola], próbuję [cel], mam problem z [konkret].” Uczniowie potrzebują rusztowania, zanim zbudują własny styl promptowania.

„Skąd wiem, że odpowiedź jest poprawna?”

To najlepsza bariera, bo jest uzasadniona. Krytyczne myślenie wobec outputu AI to kluczowa umiejętność — nie przeszkoda w nauce. Naucz ucznia weryfikować: cross-check z innym źródłem, test „czy to ma sens w moim kontekście”, pytanie zwrotne do AI („sprawdź czy nie popełniłeś błędu w założeniu X”).

Najlepsi uczniowie AI to nie ci, którzy ufają mu bezwarunkowo — to ci, którzy umieją prowadzić dialog: pytają, weryfikują, poprawiają, iterują.

Robotyka jako wejście do AI dla młodszych uczniów

W XR FabLab w Chrzanowie pracowaliśmy z uczniami szkół zawodowych. Próg wejścia do abstrakcyjnego „AI” był za wysoki. Robotyka okazała się idealnym pomostem.

Dlaczego robotyka działa:

• Natychmiastowa pętla zwrotna — robot jedzie lub nie. Nie ma dwuznaczności. Uczeń widzi efekt swojej decyzji w ciągu sekund, nie dni.
• Fizyczny artefakt — można go dotknąć, pokazać rodzicom, zepsuć i naprawić. Kod na ekranie jest abstrakcyjny. Robot jest rzeczywisty.
• Programowanie jako rozkazy — uczniowie instynktownie rozumieją sekwencję rozkazów. To prosta analogia do promptowania AI.
• Element rywalizacji — wyścigi, wyzwania, rankingi. Motywacja zewnętrzna, dopóki nie pojawi się wewnętrzna.

Kiedy uczeń rozumie, że robot wykonuje dokładnie to, co mu powiedział (i nie więcej, i nie mniej), rozumie też, dlaczego precyzja w promptowaniu ma znaczenie. To jest moment transferu.

Co różni dobrego instruktora AI od złego

Dobry instruktor AI nie jest tym, który zna API dokumentację na pamięć. Jest tym, który:

• Pamięta, jak to było nie wiedzieć — i potrafi wyobrazić sobie perspektywę ucznia
• Cieszy się, kiedy uczeń go zaskoczy nowym zastosowaniem narzędzia
• Traktuje błąd ucznia jako informację diagnostyczną, nie porażkę
• Sam nadal się uczy — AI zmienia się co kilka miesięcy, kto stoi w miejscu, zostaje w tyle

Praktyczny punkt startowy

Jeśli projektujesz kurs lub warsztat AI od zera, jeden schemat który polecam:

• Sesja 1: Problem uczestnika → pierwsze zetknięcie z narzędziem → zaskoczenie (dobre lub złe) → wspólna analiza
• Sesja 2: Budowanie słownika → szablony promptów → pierwsze samodzielne zadanie
• Sesja 3+: Projekt własny uczestnika → iteracja → prezentacja wyniku

Projekt własny jest kluczowy. Kiedy uczestnik rozwiązuje swój problem (nie ćwiczenie z instrukcją), a AI mu w tym pomaga — w tym momencie narzędzie staje się jego.

Kogo w twojej organizacji lub klasie jest najtrudniej przekonać do AI — i co jest ich główną barierą?

Autor wdrażał szkolenia VR w środowiskach przemysłowych od 2018 r. (Krakodlew, XR FabLab Chrzanów). Uczy AI, automatyzacji i kodowania wspomaganego AI w kontekście praktycznym — w Polsce i za granicą. Źródła: PwC VR Soft Skills Study 2020 (n=10 000); dane własne Krakodlew/Industrverse 2018–2024.

W 2023 roku postanowiłem zbudować platformę dla inwestorów budowlanych. Listy kontrolne zakupu działki, śledzenie budżetu, dokumenty, eksperci, mapy w jednym miejscu. Aplikacja mobilna na iOS i Android, plus wersja web.

Nie miałem ani jednego developera w zespole.

Nie szukałem też freelancera. Zamiast tego wziąłem laptop, otworzyłem Claude Code i zacząłem pisać prompty.

Dziś naswoim.org działa. Użytkownicy zalogowani. Dane w Supabase. Wersja mobilna w App Store i Google Play. I przez cały czas budowałem ją równolegle z dwoma innymi projektami.

Czym jest vibe coding?

Vibe coding to nie to samo co no-code. Nadal piszesz kod. Ale nie piszesz go sam od zera — piszesz go razem z modelem AI, który generuje implementację na podstawie twojej specyfikacji.

Nie chodzi też o wklejanie pytań do ChatGPT i kopiowanie odpowiedzi. Chodzi o precyzyjne myślenie o problemie i opisywanie go w sposób, który AI może przetworzyć na działający kod.

To zmienia wymagania. Nie musisz wiedzieć, jak napisać hook React z optymistyczną aktualizacją UI. Musisz wiedzieć, że jej potrzebujesz i dlaczego.

Trzy produkty, zero zewnętrznych developerów

marcinpaszkiewicz.com — ta strona. Astro SSR, WordPress Headless jako CMS, deploy na Vercel. Każda zmiana — nowy artykuł, poprawka layoutu, nowa funkcja — powstaje przez Claude Code. Czas od pomysłu do działającej zmiany: zwykle poniżej godziny.

naswoim.org — pełny stack: React 19 + Vite, Tailwind CSS, Supabase (PostgreSQL + Auth + Storage + Realtime), Capacitor na iOS i Android. Dwadzieścia stron, kilkanaście hooków domenowych, dwadzieścia kilka komponentów feature. System uprawnień (RLS), 20 migracji SQL, integracja z mapami Leaflet. Wszystko zbudowane bez rekrutacji.

industrverse.com — najtrudniejszy technicznie. Frontend: Next.js + React 19. Backend: NestJS z 13 modułami, Prisma + PostgreSQL, Redis, JWT/Passport, Socket.io (WebSockets do sesji VR w czasie rzeczywistym), Swagger, integracje Google API. Docker Compose z czterema serwisami. Monorepo npm. Siedem ról użytkownika. Dziewięć dashboardów zależnych od roli.

Żaden z tych projektów nie byłby możliwy w rozsądnym czasie i budżecie bez AI jako partnera programistycznego. Z AI — każdy z nich stał się wykonywalny dla jednej osoby.

Jak wygląda mój workflow

Nie ma jednego narzędzia. Używam kilku, zależnie od zadania:

• Claude Code (CLI) — do głębokiej pracy z plikami: nowe funkcje, refaktoring, debugowanie w kontekście całego projektu. Rozumie strukturę repozytorium, czyta wiele plików naraz, proponuje zmiany z dokładnością do linii.
• Claude.ai — do planowania architektury, omawiania decyzji projektowych, szybkich pytań na etapie design. Tutaj rozmawiamy o tym, co budujemy, zanim zacznę go kodować.
• GitHub Copilot — do autouzupełniania w edytorze, szczególnie przy powtarzalnych fragmentach (komponenty, testy, migracje SQL).

Iteracja wygląda tak: definiuję zadanie precyzyjnie → AI generuje szkielet → przeglądam i prowadzę → AI poprawia → testuję → powtarzam. Kluczowe jest „prowadzę” — to nie jest automat. Ty jesteś kierowcą.

Co AI robi dobrze

• Scaffolding i boilerplate — nowy endpoint API, nowy komponent, nowa migracja SQL. AI wie, jak to wygląda, i generuje to szybko i poprawnie.
• Debugowanie z kontekstem — wklej błąd + relevantny kod → AI diagnozuje. Zwykle trafnie. To oszczędza godziny poszukiwań na Stack Overflow.
• Refaktoring — zmiana nazwy, restrukturyzacja, dodanie typów TypeScript do istniejącego kodu JavaScript. AI jest w tym bezbłędne i szybkie.
• Tłumaczenie między warstwami — „mam tę logikę w backendzie, napisz odpowiadający hook na frontendzie”. AI rozumie obie strony.

Gdzie nadal potrzebny jest człowiek

Vibe coding nie eliminuje potrzeby myślenia. Zmienia tylko to, o czym myślisz.

• Decyzje architektoniczne — jak podzielić system, gdzie umieścić logikę, jakie kompromisy przyjąć. AI proponuje, ale decydujesz ty.
• UX i product design — co powinien czuć użytkownik w danym momencie. AI nie zna twoich użytkowników.
• Bezpieczeństwo — każdy kod dotyczący auth, danych wrażliwych, uprawnień wymaga twojej weryfikacji. AI popełnia błędy w RLS, w walidacji wejścia, w ekspozycji API.
• Złożony stan w dużej bazie kodu — przy projekcie powyżej pewnego rozmiaru AI traci kontekst. Musisz go prowadzić precyzyjnie.

Czego nauczyłem się po drodze

Największa pułapka: traktowanie AI jak automat do kodu. Wklejasz opis, otrzymujesz kod, wklejasz do projektu bez czytania. To kończy się błędami bezpieczeństwa, niespójnym stylem i długiem technicznym, który zrozumiesz dopiero za sześć miesięcy.

Druga pułapka: zbyt ogólne prompty. „Napisz mi aplikację do zarządzania budżetem” daje wynik generyczny i bezużyteczny. „Napisz hook useProjectBudget, który subskrybuje się do tabeli expenses w Supabase przez Realtime, agreguje sumy per category i zwraca isLoading, error, totals oraz addExpense” — daje dokładnie to, czego potrzebujesz.

Vibe coding nie wymaga znajomości każdej linijki kodu. Wymaga precyzyjnego myślenia o problemie — i to jest umiejętność, którą można rozwinąć celowo.

Od czego zacząć

Jeśli chcesz zacząć budować w modelu vibe coding, trzy rzeczy dają największy zwrot:

• Podstawy Git — commit, push, branch, merge. Bez tego nie możesz bezpiecznie eksperymentować. Git to twoja siatka bezpieczeństwa.
• Umiejętność czytania błędów — nie musisz rozumieć każdej linii kodu, ale musisz umieć przeczytać komunikat błędu i wkleić go do AI z kontekstem. To 80% debugowania.
• Podstawy SQL — większość aplikacji ma bazę danych. Rozumienie SELECT, INSERT, JOIN i podstaw schematu pozwala ci prowadzić AI przez warstwy danych.

Następny krok: wybierz narzędzie. Claude Code, Cursor, GitHub Copilot — każde ma swoje mocne strony. Zacznij od jednego, na małym projekcie. Nie od razu od aplikacji z bazą danych.

Jaki problem chciałbyś rozwiązać swoim pierwszym vibe coding projektem?

Autor buduje w modelu vibe coding od 2023 r. Stack naswoim.org: React 19, Supabase, Capacitor. Stack industrverse.com: NestJS, Next.js, PostgreSQL, Redis, Docker. Stack tej strony: Astro SSR, WordPress Headless, Vercel.

2018 rok. Stoję przed zarządem jednej z największych polskich odlewni i tłumaczę, dlaczego wdrożenie szkoleń VR ma sens. Na sali siedzą ludzie, którzy szkolili pracowników przez 30 lat metodą „mistrz–uczeń” — i przez 30 lat to działało.

Pytanie, które padło, było przewidywalne: „Po co płacić za wirtualną rzeczywistość, skoro mamy e-learning?”

To dobre pytanie. Ale źle postawione.

Bo problem nie leży w koszcie technologii — leży w tym, do czego jej używasz.

Co mówią dane — PwC 2020

W 2020 roku PwC opublikowało jedno z największych badań porównawczych szkoleń VR w środowisku korporacyjnym. 10 000 uczestników. Trzy metody: szkolenie w sali, e-learning, VR. Wyniki były jednoznaczne.

Cztery razy szybciej to nie margines statystyczny. To różnica między szkoleniem trwającym tydzień a szkoleniem trwającym dwa dni.

Różnica między „wiem jak to zrobić” a „czuję, że potrafię to zrobić” — to właśnie ta 275%. I w środowisku przemysłowym ta różnica ma bezpośrednie przełożenie na wypadki, błędy i jakość.

Kiedy VR wygrywa z e-learningiem

E-learning sprawdza się tam, gdzie chodzi o przekazanie informacji: procedury BHP, regulacje, wiedza produktowa. Można go zrobić tanio, szybko zaktualizować i uruchomić na każdym laptopie.

VR wygrywa, gdy chodzi o zbudowanie odruchu i pewności w sytuacjach, których nie możesz bezpiecznie powtarzać w rzeczywistości.

W odlewni scenariusze, które ćwiczyliśmy w VR, to sytuacje awaryjne przy piecu topielniczym — przegrzanie, wyciek metalu, nieprawidłowe odczyty temperatury. Żadnego z tych scenariuszy nie da się przećwiczyć „na żywo” bez ryzyka poważnego wypadku.

Ekonomia: kiedy VR przestaje być drogi

Główna obiekcja zarządów brzmi zawsze tak samo: „To jest drogie”. I to prawda — koszt tworzenia treści VR jest wyższy niż e-learningu. Ale to jest koszt jednostkowy tworzenia, nie koszt jednostkowy szkolenia.

Do tego dochodzą koszty, których e-learning nie eliminuje: zatrzymanie linii produkcyjnej na czas szkolenia, dojazdy, sala, instruktor. VR można przeprowadzić przy stanowisku, w 20 minut, bez zatrzymywania produkcji.

Kiedy e-learning jest lepszym wyborem

VR nie jest odpowiedzią na wszystko. Są sytuacje, gdzie e-learning jest obiektywnie lepszym wyborem:

• Szybkie aktualizacje treści — zmiana regulacji, nowy produkt, aktualizacja procedury. E-learning można zmienić w dzień. Treść VR wymaga rekonstrukcji 3D.
• Szkolenia czysto informacyjne — compliance, prawo pracy, onboarding ogólny. Nie potrzebujesz immersji żeby zapamiętać numer telefonu alarmowego.
• Mała skala jednorazowa — jeśli szkolisz 5 osób raz w roku, koszt produkcji treści VR nie zwróci się.
• Dostęp z każdego urządzenia — e-learning działa na telefonie w domu. VR wymaga sprzętu.

Pytanie nie brzmi „VR czy e-learning” — lecz „który proces wymaga której metody”.

Z praktyki: szkolenia VR w odlewni

W Krakodlew wdrożyliśmy szkolenia VR dla procedur bezpieczeństwa przy piecach topielniczych. Wynik: skrócenie czasu wdrożenia nowych operatorów o ok. 40%, zero incydentów wynikających z nieznajomości procedur w pierwszych 6 miesiącach pracy. Wzorzec, który później zastosowałem w kolejnych wdrożeniach dla przemysłu.

Praktyczna zasada decyzyjna

Zanim zdecydujesz o metodzie szkolenia, odpowiedz na trzy pytania:

• Czy błąd podczas szkolenia może być niebezpieczny lub bardzo kosztowny w rzeczywistości? → VR
• Czy szkolenie dotyczy fizycznych czynności i procedur, a nie samej wiedzy? → VR
• Czy będziesz szkolić tę samą treść dla 50+ osób przez kilka lat? → VR jest opłacalny

Jeśli odpowiedź na wszystkie trzy to „nie” — e-learning jest mądrzejszym wyborem.

Jakie szkolenia w Twojej organizacji byłyby najlepszym kandydatem do VR?

Źródła: PwC — VR Soft Skills Study 2020 (n=10 000) | Brandon Hall Group — Learning & Development Research | Dane własne: wdrożenia Krakodlew 2018–2024

2018 rok. Jestem w jednej z największych polskich odlewni. Zamiast szukać „oczywistego” kandydata do robotyzacji, zaczynam od stworzenia digital twin hali produkcyjnej — modelu odwzorowującego poszczególne odcinki procesu, który pozwala oceniać potencjał automatyzacji bez zatrzymywania linii.

Każdy odcinek opisuję przez zestaw parametrów: częstotliwość operacji, poziom zagrożeń BHP, podatność procesu na automatyzację, szacowany ROI. Dane zbieramy przy każdym stanowisku. Dopiero po tej analizie formułuję rekomendację.

Pytanie, które postawił zarząd: gdzie inwestujemy jako pierwsze?

Właściwe pytanie zmienia wszystko

Nie pytam „co jest najtańsze do zautomatyzowania”. Pytam: „gdzie człowiek jest najbardziej zagrożony?”

To nie sentimentalizm — to racjonalna ekonomia. Procesy z najwyższym poziomem hazardu mają też inne charakterystyki: wysoka rotacja pracowników, absencja chorobowa, koszty medyczne, ryzyko wypadków ze skutkami prawnymi. BHP i rachunek ekonomiczny wskazują tu w tym samym kierunku.

Kryteria analizy, w kolejności od najważniejszego:

• Zagrożenia dla życia i zdrowia (BHP) — czy automatyzacja eliminuje czynniki szkodliwe: temperaturę, hałas, pył, drgania, ryzyko wypadku? To kryterium nadrzędne.
• Powtarzalność procesu — czy robot może wykonywać to zadanie identycznie, za każdym razem, bez wyjątków?
• Czas zwrotu (ROI) — kiedy inwestycja się zwróci i jakie są ryzyka?
• Dojrzałość techniczna — czy technologia jest wystarczająco stabilna na środowisko produkcyjne?
• Odporność linii — co się dzieje z produkcją, gdy robot stanie nieoczekiwanie?

Rekomendacja #1: oczyszczanie odlewów wielkogabarytowych

To najbardziej fizycznie wyniszczająca praca na hali — szlifowanie, ciężkie dźwiganie, wysoka temperatura, hałas, pył, drgania. Operator narażony jest jednocześnie na wszystkie główne czynniki szkodliwe. Żaden inny analizowany proces nie wykazywał takiej kumulacji hazardów.

To nie tylko kwestia etyki. Oczyszczanie odlewów wielkogabarytowych ma też cechy sprzyjające automatyzacji — wysoka powtarzalność geometrii dużych odlewów, brak złożonej decyzyjności, mierzalny efekt (jakość powierzchni). Ochrona człowieka i rachunek ekonomiczny wskazują tu w tym samym kierunku.

Rekomendacja #2: pomiar temperatury w piecu odlewniczym

Drugi priorytet — i równie nieprzypadkowy. Praca operatora przy pomiarze temperatury w piecu wiąże się z bezpośrednim narażeniem na promieniowanie cieplne i ryzykiem ekstremalnych zdarzeń termicznych. Dodatkowy argument: błędny pomiar to wadliwy odlew — bezpośrednia strata finansowa i ryzyko jakościowe dla klienta. Wysoka powtarzalność, zerowa tolerancja błędu, klarowny ROI.

Polska kontra świat: skala wyzwania

Dane Międzynarodowej Federacji Robotyki (IFR 2024) pokazują, gdzie jesteśmy:

Polska ma 81 robotów na 10 000 pracowników — to prawie 3× poniżej średniej UE i 5× poniżej Niemiec (429/10 000). Jesteśmy największym rynkiem robotyki w Europie Środkowo-Wschodniej, ale przepaść jest ogromna. I właśnie dlatego jakość decyzji o automatyzacji jest tu szczególnie ważna — bo pieniędzy na błędy nie ma.

Przestroga: kiedy „oczywisty wybór” kosztuje miliardy

Historia Tesli z lat 2017–2018 to podręcznikowy przykład błędu, który zdarza się w każdej branży. Tesla zainstalowała setki robotów przemysłowych, żeby produkować 5 000 samochodów tygodniowo. Efekt? Nie mogła wyprodukować nawet 2 500.

Elon Musk przyznał publicznie: „Nadmierna automatyzacja była błędem. Ludzie są niedoceniani.”

Roboty wykonują powtarzalne czynności w stabilnym środowisku — i robią to doskonale. Ludzie pozostają niezastąpieni tam, gdzie wymagana jest elastyczność i decyzja w sytuacji wyjątkowej. Optymalne są rozwiązania hybrydowe — nie pełna automatyzacja.

Co faktycznie się automatyzuje

Globalne statystyki pokazują dominację paletyzacji i obsługi materiałów — procesów z jasnym ROI i niskim hazardem. W środowisku odlewniczym, gdzie kumulacja czynników szkodliwych jest wyjątkowo wysoka, analiza zaczyna się od innego miejsca.

Wniosek: analiza potencjału, nie lista życzeń

Po tej analizie w 2018 roku wróciłem do zarządu z rekomendacją, która zaskoczyła wielu. Spodziewali się wskazania tańszego, szybszego w implementacji celu. Argument był prosty: jeśli nie możemy uzasadnić priorytetyzacji robotyzacji tam, gdzie stawką jest zdrowie i życie operatora, nie możemy jej uzasadnić nigdzie.

Analiza potencjału robotyzacji nie jest dokumentem politycznym. Jest rankingiem, w którym ochrona człowieka i tworzenie trwałej wartości procesowej idą w parze — bo tylko takie projekty mają sens długoterminowo.

Czy widziałeś kiedyś w swoim zakładzie proces, który „wszyscy wiedzieli, że trzeba zautomatyzować” — ale nikt nie liczył prawdziwych kosztów jego braku automatyzacji dla ludzi?

Źródła: IFR — World Robotics 2024 (ifr.org) | B. Büchel, D. Floreano, IMD Case Study: Tesla 2018 | S. Gibbs, The Guardian, 16.04.2018 | AutomatykaOnline.pl — ROI automatyzacji | pro-assem.pl — zastosowania robotów przemysłowych | CentrumMaszynCNC.pl — kryteria wyboru procesów | Zdjęcia: archiwum własne, Krakodlew / GIFA 2019