Blog

  • zrodelko.org — how I built a full-stack nursery website with WCAG 3.0, ElevenLabs TTS and a GSC pipeline

    zrodelko.org — how I built a full-stack nursery website with WCAG 3.0, ElevenLabs TTS and a GSC pipeline

    When Źródełko — a nursery and kindergarten in Gruszowiec in the Beskid Wyspowy mountains — reached out for a new website, I had a clear picture of where we were starting: a site built in Canva, no CMS, no accessibility, no bilingual support. And no way to grow.

    I could have deployed WordPress and called it done in a week. Instead, I made a decision I stand behind: a custom full stack that could scale for years.

    What took shape over several months became one of the technically most interesting projects I have delivered.

    Stack: why Next.js 15 + Payload CMS 3

    The key architectural decision: I wanted a CMS embedded in the Next.js application, not a separate process. Payload CMS 3 makes exactly that possible — a single Vercel deployment, admin panel at /admin, PostgreSQL database on Railway.

    Full stack:

    Layer Technology
    Framework Next.js 15.4 + React 19, App Router, TypeScript 5.7
    CMS Payload CMS 3 (embedded, Lexical editor, PL/EN localisation)
    Database PostgreSQL (Railway), 8 collections + 2 globals
    Styling Tailwind CSS 3 + CSS custom properties (:root variables)
    AI / TTS ElevenLabs (article audio generation) + Media Session API
    Integrations Facebook Graph API v19 (ISR 2h, cron revalidation)
    SEO analytics Google Search Console API + Supabase Edge Functions + GitHub Actions
    Python Pillow, OpenCV, face_recognition (HOG), rembg, FFmpeg
    Infrastructure Vercel (SSR + CI/CD) + Railway (PostgreSQL) + Supabase (Edge Functions)

    WCAG 3.0 — accessibility toolbar built from scratch

    Most institutional websites pretend to be „accessible” — they have alt text on images and call it done. I implemented a full WCAG 3.0 accessibility toolbar with nine independent parameters controlled by CSS custom properties on :root.

    The AccessibilityToolbar component lets users control:

    Typography
    Text size (0.8×–1.6×)
    Line height
    Letter and word spacing
    Dyslexia-friendly font

    Visual
    High contrast
    Dark mode (CSS invert)
    Reduce motion
    Enhanced focus ring

    Every parameter works through a CSS variable set on document.documentElement. For example, text size is font-size: calc(16px * var(--text-size-scale)) on html — changing one variable scales everything on the page proportionally. State is persisted in localStorage and restored on every visit.

    Why this matters for a public benefit organisation: OPP entities have a legal obligation to provide digital accessibility (WCAG 2.1 AA as a minimum). Źródełko welcomes children with disabilities — it makes sense that the website is accessible to all parents.

    ElevenLabs TTS + AudioPlayer + Media Session API

    The Parent Zone is a hub of expert articles on parenting, child development, and Pikler methodology. I decided that key articles should have an audio version — narrated by a female voice generated in ElevenLabs.

    The pipeline:

    1
    Audio generation (Python)
    A Python script calls the ElevenLabs SDK with a multilingual TTS model, converting article text into a high-quality MP3 served statically by Next.js.
    2
    AudioPlayer component (React)
    A custom player with a progress bar, play/pause button, timer, and click-to-seek. Zero external libraries — 125 lines of TypeScript.
    3
    Media Session API
    OS-level integration: the article title and narrator avatar appear on the phone lock screen. Play/pause and ±10s skip controls work from headphones or Bluetooth.

    Result: a parent can start an article, pocket their phone, and listen while cooking lunch.

    Facebook ISR — news feed without an admin panel

    Źródełko actively posts on Facebook — it is the natural communication hub with the community. Instead of asking staff to copy-paste posts twice, I built an automatic sync.

    The FacebookPosts component is a Server Component with ISR (Incremental Static Regeneration) — Next.js builds the page with fresh data from Facebook Graph API and holds the cache for 2 hours. Post content, image, and date are fetched automatically; the title is extracted from the first line, the rest becomes an excerpt. Dates are localised to the site’s language. A separate endpoint allows cache invalidation via an external cron.

    GSC pipeline: GitHub Actions → Supabase Edge → email

    I built a fully serverless analytics pipeline for Google Search Console — so the client receives a weekly email with visibility data every Monday, and historical data is available for analysis.

    Supabase Edge Function (Deno)
    Runs daily, fetching clicks, impressions, CTR and position from the GSC Search Analytics API — broken down by query, page and date. Everything lands in Supabase PostgreSQL with history and weekly summary views.
    📧
    GitHub Actions: weekly report
    Every Monday a workflow generates an HTML email with top queries and pages from the last 7 days and delivers it via SMTP. Historical data is committed to the repository.
    🗄
    PostgreSQL: history and views
    Data is stored with uniqueness per day and query/page. SQL views aggregate weekly summaries ready for display or inclusion in the report.

    Cost of this pipeline: zero. The entire setup runs on free tiers — GitHub Actions, Supabase Edge Functions and PostgreSQL all fit within the free limits at this traffic scale.

    Python: automated children’s photo processing

    The nursery has thousands of photos of children from activities. Problem: GDPR requires that recognisable children’s faces not be published without individual parental consent.

    Solution: a Python script using face_recognition (dlib HOG) for face detection and cv2.GaussianBlur to blur them. A separate script uses rembg to remove backgrounds from staff photos. FFmpeg compresses video to a sensible size — photos don’t balloon on the server.

    Registration form: 5 steps, age validation, email to parent

    The RegistrationForm component is 617 lines of TypeScript handling the full enrolment flow: choose nursery/kindergarten → child details → parent details → health information → GDPR consents.

    One feature that works particularly well: auto-suggest for the start date. Based on the child’s date of birth and the selected facility type, the system automatically proposes the nearest recruitment term (March or September) when the child will be in the correct age bracket. Nursery: 10–36 months. Kindergarten: 30–72 months.

    On submit, the endpoint saves data to Payload CMS, sends a confirmation email to the parent, and an internal email to administration — all through SMTP configured via @payloadcms/email-nodemailer.

    JSON-LD and LLMO/GEO: optimising for AI search engines

    Standard SEO is not enough if you care about visibility in AI Overviews (Google SGE) and ChatGPT/Perplexity answers. LLMO (Large Language Model Optimisation) and GEO (Generative Engine Optimisation) mean structuring content for language models — not just crawlers.

    What was implemented:

    • Organization schema with type ChildCare + LocalBusiness, geolocation (621 m a.s.l.), and areaServed for Dobra commune and Limanowa county
    • Article schema with author (Person), dateModified, inLanguage, and mainEntityOfPage for every article in the Parent Zone
    • FAQPage schema on the homepage and fees page — questions and answers that AI can serve directly
    • BreadcrumbList on every sub-page
    • Answers written in encyclopaedic style — complete sentences, no fragments stripped of context

    Result: the site has a real chance of appearing in AI answers to queries like „nursery Beskidy mountains”, „nursery Dobra Limanowa”, or „nursery WCAG accessible” — not only in traditional search results.

    Summary

    zrodelko.org started as „a new website for a nursery”. It ended as a project that taught me several things:

    • Payload CMS 3 embedded in Next.js is a genuinely mature solution — no separate backend, one repo, one deploy
    • WCAG 3.0 via CSS custom properties is an elegant approach — one point of change, the entire UI responds
    • The Media Session API is deeply underrated — it raises audio UX by an order of magnitude at zero cost
    • A serverless GSC pipeline (Edge Functions + GitHub Actions) runs reliably and practically for free

    The project is live at zrodelko.org. If you run a small organisation and are wondering whether this stack makes sense — yes, it does. Especially when you want a site that grows, and that the client can manage independently.

  • zrodelko.org — jak zbudowałem full-stack stronę dla żłobka z WCAG 3.0, ElevenLabs i pipelinem GSC

    zrodelko.org — jak zbudowałem full-stack stronę dla żłobka z WCAG 3.0, ElevenLabs i pipelinem GSC

    Kiedy Źródełko — żłobek i przedszkole w Gruszowcu w Beskidzie Wyspowym — zwróciło się do mnie z prośbą o nową stronę, miałem jasny obraz punktu startowego: strona zbudowana w Canva, bez zarządzania treścią, bez dostępności, bez dwujęzyczności. I bez żadnej drogi do rozbudowy.

    Mógłbym postawić WordPress i skończyć w tydzień. Zamiast tego podjąłem decyzję, której nie żałuję: pełny custom stack, który dałoby się rozwijać latami.

    To co powstawało przez kilka miesięcy stało się jednym z technicznie ciekawszych projektów, które zrealizowałem.

    Stack: dlaczego Next.js 15 + Payload CMS 3

    Kluczowa decyzja architekturalna: chciałem CMS-a wbudowanego w aplikację Next.js, a nie osobnego procesu. Payload CMS 3 umożliwia dokładnie to — jeden deployment na Vercel, panel admina pod /admin, baza PostgreSQL na Railway.

    Pełny stack:

    Warstwa Technologia
    Framework Next.js 15.4 + React 19, App Router, TypeScript 5.7
    CMS Payload CMS 3 (embedded, Lexical editor, lokalizacja PL/EN)
    Baza danych PostgreSQL (Railway), 8 kolekcji + 2 globale
    Stylowanie Tailwind CSS 3 + CSS custom properties (:root variables)
    AI / TTS ElevenLabs (generowanie audio artykułów) + Media Session API
    Integracje Facebook Graph API v19 (ISR 2h, cron revalidation)
    Analityka SEO Google Search Console API + Supabase Edge Functions + GitHub Actions
    Python Pillow, OpenCV, face_recognition (HOG), rembg, FFmpeg
    Infra Vercel (SSR + CI/CD) + Railway (PostgreSQL) + Supabase (Edge Functions)

    WCAG 3.0 — toolbar dostępności zbudowany od zera

    Większość stron instytucjonalnych udaje, że „jest dostępna” — ma alt w obrazkach i na tym koniec. Zdecydowałem się zaimplementować pełny toolbar dostępności zgodny z WCAG 3.0, z dziewięcioma niezależnymi parametrami sterowanymi przez CSS custom properties na :root.

    Komponent AccessibilityToolbar pozwala użytkownikowi regulować:

    Typografia
    Rozmiar tekstu (0.8×–1.6×)
    Wysokość linii
    Odstęp liter i słów
    Czcionka dyslektyczna

    Wizualne
    Wysoki kontrast
    Tryb ciemny (CSS invert)
    Redukcja animacji
    Wzmocniony focus ring

    Każdy parametr działa przez zmienną CSS ustawianą na document.documentElement. Np. rozmiar tekstu to font-size: calc(16px * var(--text-size-scale)) na html — zmiana jednej zmiennej skaluje wszystko na stronie proporcjonalnie. Stan zapisywany jest w localStorage i przywracany przy każdej wizycie.

    Dlaczego to ważne dla OPP: Organizacje pożytku publicznego mają prawny obowiązek zapewnienia dostępności cyfrowej (WCAG 2.1 AA jako minimum). Źródełko przyjmuje dzieci z niepełnosprawnościami — rozsądne, żeby strona była dostępna dla wszystkich rodziców.

    ElevenLabs TTS + AudioPlayer + Media Session API

    Strefa Rodziców to hub z artykułami eksperckimi o wychowaniu, rozwoju dziecka i metodyce Pikler. Postanowiłem, że kluczowe artykuły będą miały wersję audio — czytaną przez lektorkę z głosem wygenerowanym w ElevenLabs.

    Pipeline wygląda tak:

    1
    Generowanie audio (Python)
    Skrypt Python wywołuje ElevenLabs SDK z multilingualnym modelem TTS — tekst artykułu zamieniany jest na wysokiej jakości MP3 serwowany statycznie przez Next.js.
    2
    Komponent AudioPlayer (React)
    Własny player z paskiem postępu, przyciskiem play/pause, timerem i seekiem klikowym. Zero zewnętrznych bibliotek — 125 linii TypeScript.
    3
    Media Session API
    Integracja z systemem operacyjnym: tytuł artykułu i avatar lektorki pojawiają się na ekranie blokady telefonu. Działają przyciski play/pause i przewijanie ±10s z poziomu słuchawek lub Bluetooth.

    Efekt: rodzic może uruchomić artykuł, schować telefon do kieszeni i słuchać podczas gotowania obiadu.

    Facebook ISR — aktualności bez panelu admina

    Źródełko aktywnie publikuje na Facebooku — to naturalne centrum komunikacji ze społecznością. Zamiast prosić obsługę o podwójne wklejanie postów, zbudowałem automatyczną synchronizację.

    Komponent FacebookPosts to Server Component z ISR (Incremental Static Regeneration) — Next.js buduje stronę ze świeżymi danymi z Facebook Graph API i trzyma cache przez 2 godziny. Treść posta, zdjęcie i data są pobierane automatycznie; tytuł wyciągany z pierwszej linii, reszta staje się excerptm. Daty lokalizowane są do języka strony. Dodatkowy endpoint pozwala wymusić odświeżenie przez zewnętrzny cron.

    Pipeline GSC: GitHub Actions → Supabase Edge → email

    Zbudowałem pełny, bezserwerowy pipeline analityczny dla Google Search Console — żeby klient dostawał co poniedziałek email z raportem widoczności strony, a dane historyczne były dostępne do analizy.

    Supabase Edge Function (Deno)
    Codziennie pobiera dane z GSC Search Analytics API — kliki, wyświetlenia, CTR i pozycja dla frazy, strony i daty. Wszystko trafia do Supabase PostgreSQL z historią i widokami tygodniowymi.
    📧
    GitHub Actions: tygodniowy raport
    Co poniedziałek workflow generuje HTML email z top frazami i stronami ostatnich 7 dni i wysyła przez SMTP. Historia danych jest commitowana do repozytorium.
    🗄
    PostgreSQL: historia i widoki
    Dane przechowywane są z unikalnością per dzień i fraza/strona. Widoki SQL agregują tygodniowe podsumowania gotowe do wyświetlenia lub wysłania w raporcie.

    Koszt tego pipeline’u: zero. Cały setup działa na darmowych tierach — GitHub Actions, Supabase Edge Functions i PostgreSQL mieszczą się w bezpłatnych limitach przy tej skali ruchu.

    Python: automatyczne przetwarzanie zdjęć dzieci

    Żłobek ma tysiące zdjęć dzieci z zajęć. Problem: RODO wymaga, żeby nie publikować rozpoznawalnych twarzy dzieci bez osobnej zgody każdego z rodziców.

    Rozwiązanie: skrypt Python używający face_recognition (dlib HOG) do wykrywania twarzy i cv2.GaussianBlur do ich rozmycia. Dodatkowy skrypt z rembg do usuwania tła ze zdjęć pracowników. FFmpeg kompresuje filmy do rozsądnego rozmiaru — zdjęcia nie puchną na serwerze.

    Formularz zapisu: 5 kroków, walidacja wieku, email do rodzica

    Komponent RegistrationForm to 617 linii TypeScript obsługujących pełny proces rekrutacji: wybór żłobek/przedszkole → dane dziecka → dane rodzica → zdrowie → zgody RODO.

    Jeden element, który naprawdę działa dobrze: auto-suggest daty rozpoczęcia. Na podstawie daty urodzenia dziecka i wybranego typu placówki system automatycznie proponuje najbliższy termin rekrutacyjny (marzec lub wrzesień), kiedy dziecko będzie w odpowiednim przedziale wiekowym. Żłobek: 10–36 miesięcy. Przedszkole: 30–72 miesiące.

    Po submicie endpoint zapisuje dane do Payload CMS, wysyła email potwierdzający do rodzica i email wewnętrzny do administracji — przez SMTP skonfigurowany przez @payloadcms/email-nodemailer.

    JSON-LD i LLMO/GEO: optymalizacja pod AI search engines

    Standardowe SEO to za mało, jeśli zależy ci na widoczności w AI Overviews (Google SGE) i odpowiedziach ChatGPT/Perplexity. LLMO (Large Language Model Optimization) i GEO (Generative Engine Optimization) to optymalizacja struktury treści pod modele językowe — nie tylko pod crawlery.

    Co zostało zaimplementowane:

    • Organization schema z typem ChildCare + LocalBusiness, z geolokalizacją (621 m n.p.m.) i areaServed dla gminy Dobra i powiatu limanowskiego
    • Article schema z author (Person), dateModified, inLanguage i mainEntityOfPage dla każdego artykułu w Strefie Rodziców
    • FAQPage schema na stronie głównej i podstronie planu owego — pytania i odpowiedzi, które AI może serwować bezpośrednio
    • BreadcrumbList na każdej podstronie
    • Odpowiedzi pisane w stylu encyklopedycznym — kompletne zdania, bez fragmentów wyrwanych z kontekstu

    Efekt: strona ma szansę pojawiać się w odpowiedziach AI na zapytania o „żłobek Beskidy”, „żłobek Dobra Limanowa” czy „żłobek WCAG” — nie tylko w tradycyjnych wynikach wyszukiwania.

    Podsumowanie

    zrodelko.org zaczęło się jako „nowa strona dla żłobka”. Skończyło się jako projekt, który nauczył mnie kilku rzeczy:

    • Payload CMS 3 embedded w Next.js to naprawdę dojrzałe rozwiązanie — zero osobnego backendu, jedno repo, jeden deploy
    • WCAG 3.0 przez CSS custom properties to eleganckie podejście — jeden punkt zmiany, cały UI reaguje
    • Media Session API jest bardzo niedoceniana — podwyższa UX audio o rząd wielkości bez żadnego kosztu
    • Bezserwerowy pipeline GSC (Edge Functions + GitHub Actions) działa niezawodnie i praktycznie za darmo

    Projekt jest wdrożony produkcyjnie na zrodelko.org. Jeśli prowadzisz małą organizację i zastanawiasz się, czy taki stack ma sens — tak, ma. Zwłaszcza jeśli zależy ci na rosnącej stronie, którą klient może obsługiwać samodzielnie.

  • 6 Months of Vibe Coding — What Broke and What I’d Never Do Again

    6 Months of Vibe Coding — What Broke and What I’d Never Do Again

    April 2024. I’ve just pushed the first working version of naswoim.org to production. The app runs. Users can log in. Data persists in Supabase. On paper, it’s a success.

    Under the hood: two competing design systems, seventeen duplicate utility functions scattered across twelve files, and a Supabase RLS policy that silently fails for one specific edge case I won’t discover for three more weeks.

    Vibe coding works. But it fails in ways that are invisible — until they aren’t.

    Code on screen with neon lighting
    Photo: Jakub Żerdzicki / Unsplash

    Quick context: what I built

    Over roughly twelve months, I built three applications using vibe coding — almost without external developers:

    • naswoim.org — a platform for property investors: checklists, budgets, documents, expert marketplace, land maps, AI assistant. Web + Android + iOS + admin portal.
    • industrverse.com — B2B SaaS for industrial VR training: 7 user roles, 9 dashboards per role, real-time communication, VR session gateway, full backend API.
    • marcinpaszkiewicz.com — this site. Astro SSR + WordPress headless. Simpler, but instructive.

    I used Claude Code as my primary tool, with occasional help from Cursor. I wrote somewhere between 40,000 and 60,000 lines of production code this way. I shipped everything. It all works.

    Here’s what I got wrong.

    Mistake #1: I let AI pick the architecture

    When I started naswoim.org, I described the project to Claude and asked what stack it recommended. It gave me a solid answer: React 19, Vite, Supabase, Tailwind CSS 4. All excellent choices.

    Then I asked about UI components. It suggested MUI 7. I said yes — it was fast, it had everything I needed.

    The problem: I was already using Tailwind CSS 4. Now I had two design systems:

    Diagram — konflikt design systemów / design system conflict

    Tailwind CSS 4
    ▸ utility-first
    ▸ spacing: rem scale
    ▸ breakpoints: sm/md/lg/xl
    ▸ tokens: CSS vars

    każdy
    nowy ekran

    MUI 7
    ▸ component-first
    ▸ spacing: 8px grid
    ▸ breakpoints: xs/sm/md/lg
    ▸ tokens: theme object

    Dwa systemy spacingu. Dwie filozofie responsywności. Dwie warstwy CSS do utrzymania. — Two spacing systems. Two responsiveness philosophies. Two CSS layers to maintain.

    The lesson: AI doesn’t know your 18-month vision. It optimizes for „working right now.” Architecture decisions — especially around design systems, data models, and module boundaries — must come from you. AI implements. You decide what to implement.

    What I’d do differently: write a one-page architecture decision record before the first prompt. Not a full spec — just: what’s the single source of styling truth? What’s the state management philosophy? How are we splitting modules? Give AI constraints, not blank permission.

    Mistake #2: AI never says no — and that’s dangerous

    By the time I was three months into industrverse, the backend had 13 NestJS modules, 7 user roles, and 9 separate dashboards. Each role had its own data access logic, its own notification system, its own workflow.

    None of it was in the original spec.

    industrverse — MVP plan vs reality

    Backend modules
    planned 5 → actual 13

    User roles
    planned 3 → actual 7

    Dashboards
    planned 3 → actual 9

    Each element made sense in isolation. The problem appears when you add up all the 11pm decisions.
    Wall covered in sticky notes — what happens when scope has no limits
    Photo: Jakub Żerdzicki / Unsplash

    Here’s what happens: you have an idea at 11pm. You describe it to Claude. It builds it in twenty minutes. It works. You ship it. Three weeks later, you realize that adding this feature broke the mental model for the next feature. But AI doesn’t tell you this — it just builds what you ask.

    Every developer on a team has a colleague who says „wait — are we sure we need this?” AI doesn’t say wait. AI says yes.

    The lesson: You must be the PM for your AI. Not just the visionary — the person who says no. The question isn’t „can AI build this?” (it can). The question is „should this exist at all?”

    I now have a rule before any new feature: write one sentence about what problem this solves for a specific user. If I can’t write that sentence, I don’t prompt it.

    Mistake #3: Debugging code you didn’t write is slower than it looks

    Magnifying glass over a maze — hunting for a bug in AI-generated code
    Photo: TSD Studio / Unsplash

    In naswoim.org, I had a bug in the Supabase Row Level Security policies. Users in one role could occasionally see documents they shouldn’t — but only when a specific sequence of operations had happened first.

    It took me three days to find it.

    Not because the bug was complex. Because the code was AI-generated and I hadn’t read it carefully enough when it was written. The RLS policy looked right. It was syntactically correct. It passed my basic tests. The edge case was subtle — a combination of two different policy conditions that interacted in a non-obvious way.

    When you write code yourself, you build a mental model of it as you write. When AI writes it, you review it — which is faster, but shallower. The model in your head is less complete. And shallow mental models make debugging slow.

    The lesson: Never merge AI code you can’t explain line by line. For anything touching auth, data access, or business-critical logic: read it like a code reviewer, not like someone checking a shopping list.

    Mistake #4: Context ends — and AI „forgets” everything

    In a long Claude Code session, the AI sees everything you’ve built together. It knows your naming conventions, your patterns, your preferences. It’s coherent.

    In the next session, it starts fresh.

    Schemat — pamięć kontekstu między sesjami / context memory across sessions

    Sesja 1
    ▸ React hooks
    ▸ TanStack Query
    ▸ Zustand atoms

    ↺ reset
    Sesja 2
    ▸ useEffect pattern
    ▸ local useState
    ▸ API calls inline

    ↺ reset
    Sesja 3
    ▸ custom hooks
    ▸ Context API
    ▸ Axios interceptors

    Każda sesja generowała spójny kod — ale każda sesja nie wiedziała nic o poprzedniej. — Each session generated coherent code — but knew nothing about the previous one.

    In naswoim.org, I started a new session after a two-day break and asked Claude to build a new feature component. It generated something that worked — but used completely different patterns from everything else in the codebase. Different state management approach. Different error handling style. Different naming.

    By month four, the codebase had three distinct „eras” — each reflecting the conventions of whoever I’d been talking to at that time.

    The lesson: A CLAUDE.md file is not optional. Set it up on day one. It should contain: naming conventions, patterns to follow, patterns to avoid, which libraries to use for which problems. This is the persistent memory that bridges sessions.

    Mistake #5: Security is invisible until it isn’t

    AI generates working code. It doesn’t reliably generate secure code.

    Red padlock on a keyboard — security invisible until it isn't
    Photo: FlyD / Unsplash

    In industrverse, I had an API endpoint that was supposed to be accessible only to users with the „trainer” role. The endpoint worked correctly. It returned the right data. It handled errors gracefully.

    It also didn’t verify the JWT role claim on one specific HTTP method. A user with any authenticated token could call it.

    I found this in a manual security review — not because Claude flagged it, not because my tests caught it. Because I sat down and read through every auth-related endpoint one afternoon.

    Security review — checklista po każdym auth feature


    Czy każdy endpoint weryfikuje JWT/session?
    Is every endpoint verifying JWT/session?

    Czy rola użytkownika jest sprawdzana server-side?
    Is the user role checked server-side?

    Czy RLS działa dla wszystkich kombinacji ról?
    Does RLS work for all role combinations?

    Czy input jest walidowany przed zapisem do bazy?
    Is input validated before writing to DB?

    Czy wrażliwe pola są filtrowane w response?
    Are sensitive fields filtered in the response?

    Czy edge case (brak roli, wygasły token) jest obsłużony?
    Is the edge case (missing role, expired token) handled?

    The lesson: After every feature that touches authentication, authorization, or user data — do a manual security review. Not a vibe. A checklist.

    What I’d do differently: 6 rules

    If I started today, with everything I know now:

    1
    Write an architecture brief before the first prompt
    One page. What’s the design system? What’s the state management approach? What are the module boundaries? Give AI constraints, not blank permission.

    2
    One design system. Zero exceptions.
    Pick either a component library or a utility CSS framework. Not both. If you pick Tailwind, every component is Tailwind. If you pick MUI, every component is MUI.

    3
    One-sentence problem statement before every new feature
    „This solves [specific problem] for [specific user].” If you can’t write this sentence, you’re not ready to prompt.

    4
    If you can’t explain it line by line, don’t merge it
    Especially for anything touching auth, RLS, permissions, or data models. Review it like a code reviewer — not like someone checking a shopping list.

    5
    CLAUDE.md from day one
    Naming conventions, preferred patterns, libraries to use for which problems, patterns to avoid. Update it every time you make a significant decision. This is the persistent memory between sessions.

    6
    Schedule a security review after every auth-related feature
    It’s not optional. AI generates working code, not secure code. Treat auth, RLS, and input validation as areas where you always read manually.

    What I’m not saying

    I’m not saying vibe coding is flawed or that AI tools are unreliable. All three projects I built work. They have real users. They solve real problems. The productivity gain is genuine — I built in one year what a team of three would have taken eighteen months to build.

    What I’m saying is that the failure modes are specific, and they’re not obvious at the start.

    The biggest risk in vibe coding isn’t that AI writes bad code. It’s that AI writes code that looks fine — until something goes wrong. And by then, you’re looking at a codebase you half-understand, with a bug you didn’t write, and a mental model that has gaps in exactly the wrong places.

    The speed is real. Build the habits that make it safe.

  • Vibe coding — 6 miesięcy później: co się posypało i czego nie zrobiłbym ponownie

    Vibe coding — 6 miesięcy później: co się posypało i czego nie zrobiłbym ponownie

    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.

    Ekran z kodem w neonowym podświetleniu
    Foto: Jakub Żerdzicki / Unsplash

    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:

    Diagram — konflikt design systemów / design system conflict

    Tailwind CSS 4
    ▸ utility-first
    ▸ spacing: rem scale
    ▸ breakpoints: sm/md/lg/xl
    ▸ tokens: CSS vars

    każdy
    nowy ekran

    MUI 7
    ▸ component-first
    ▸ spacing: 8px grid
    ▸ breakpoints: xs/sm/md/lg
    ▸ tokens: theme object

    Dwa systemy spacingu. Dwie filozofie responsywności. Dwie warstwy CSS do utrzymania. — Two spacing systems. Two responsiveness philosophies. Two CSS layers to maintain.

    Wniosek: AI nie zna Twojej wizji na osiemnaście miesięcy do przodu. Optymalizuje pod „działające teraz”. Decyzje architekturalne — szczególnie dotyczące design systemów, modeli danych i granic modułów — muszą wychodzić od Ciebie. AI implementuje. Ty decydujesz co implementować.

    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.

    industrverse — plan MVP vs rzeczywistość

    Moduły backendu
    plan 5 → rzeczywistość 13

    Role użytkowników
    plan 3 → rzeczywistość 7

    Dashboardy
    plan 3 → rzeczywistość 9

    Każdy z tych elementów miał sens w izolacji. Problem pojawia się, gdy zsumuje się wszystkie decyzje z 11:00 wieczorem.
    Ściana pokryta kolorowymi karteczkami — efekt braku ograniczeń scope
    Foto: Jakub Żerdzicki / Unsplash

    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.

    Wniosek: Musisz być PM-em dla swojego AI. Nie tylko wizjonerem — osobą, która mówi nie. Pytanie nie brzmi „czy AI to zbuduje?” (zbuduje). Pytanie brzmi „czy to w ogóle powinno istnieć?”

    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

    Lupa nad labiryntem — szukanie bugu w kodzie
    Foto: TSD Studio / Unsplash

    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.

    Wniosek: Nigdy nie merguj kodu AI, którego nie potrafisz wyjaśnić linijka po linijce. W szczególności dla wszystkiego, co dotyczy auth, dostępu do danych i logiki krytycznej dla biznesu: czytaj jak code reviewer, nie jak ktoś sprawdzający listę zakupów.

    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.

    Schemat — pamięć kontekstu między sesjami / context memory across sessions

    Sesja 1
    ▸ React hooks
    ▸ TanStack Query
    ▸ Zustand atoms

    ↺ reset
    Sesja 2
    ▸ useEffect pattern
    ▸ local useState
    ▸ API calls inline

    ↺ reset
    Sesja 3
    ▸ custom hooks
    ▸ Context API
    ▸ Axios interceptors

    Każda sesja generowała spójny kod — ale każda sesja nie wiedziała nic o poprzedniej. — Each session generated coherent code — but knew nothing about the previous one.

    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.

    Wniosek: Plik CLAUDE.md nie jest opcjonalny. Ustaw go pierwszego dnia. Powinien zawierać: konwencje nazewnicze, wzorce do stosowania, wzorce do unikania, których bibliotek używać do jakich problemów. To jest trwała pamięć między sesjami.

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

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

    Czerwona kłódka na klawiaturze — security niewidoczna dopóki jej nie ma
    Foto: FlyD / Unsplash

    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.

    Security review — checklista po każdym auth feature


    Czy każdy endpoint weryfikuje JWT/session?
    Is every endpoint verifying JWT/session?

    Czy rola użytkownika jest sprawdzana server-side?
    Is the user role checked server-side?

    Czy RLS działa dla wszystkich kombinacji ról?
    Does RLS work for all role combinations?

    Czy input jest walidowany przed zapisem do bazy?
    Is input validated before writing to DB?

    Czy wrażliwe pola są filtrowane w response?
    Are sensitive fields filtered in the response?

    Czy edge case (brak roli, wygasły token) jest obsłużony?
    Is the edge case (missing role, expired token) handled?

    Wniosek: Po każdej funkcji dotykającej autentykacji, autoryzacji lub danych użytkownika — rób ręczny przegląd bezpieczeństwa. Nie vibe. Checklista.

    Co bym zrobił inaczej: 6 reguł

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

    1
    Napisz brief architekturalny przed pierwszym promptem
    Jedna strona. Co jest jedynym źródłem prawdy o stylach? Jakie jest podejście do stanu? Jakie są granice modułów? Daj AI ograniczenia, nie blank permission.

    2
    Jeden design system. Zero wyjątków.
    Albo biblioteka komponentów, albo utility CSS. Nie obydwa. Jeśli Tailwind — wszystko Tailwind. Jeśli MUI — wszystko MUI.

    3
    Jedno zdanie problemu przed każdą nową funkcją
    „To rozwiązuje [konkretny problem] dla [konkretnego użytkownika].” Jeśli nie potrafisz tego napisać — nie jesteś gotowy na prompt.

    4
    Jeśli nie rozumiesz linijka po linijce — nie merguj
    Szczególnie dla auth, RLS, uprawnień i modeli danych. Czytaj jak code reviewer, nie jak ktoś sprawdzający listę zakupów.

    5
    CLAUDE.md od pierwszego dnia
    Konwencje nazewnicze, preferowane wzorce, biblioteki do jakich problemów, wzorce do unikania. Aktualizuj przy każdej ważnej decyzji. To trwała pamięć między sesjami.

    6
    Zaplanuj przegląd bezpieczeństwa po każdej funkcji auth
    Nie opcjonalnie. AI generuje działający kod, nie bezpieczny. Auth, RLS i walidacja inputu — tu zawsze czytasz ręcznie.

    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.

  • Vibe Coding: What the Research Says, and a Tool Comparison

    Vibe Coding: What the Research Says, and a Tool Comparison

    In February 2025, Andrej Karpathy — co-founder of OpenAI and former Tesla AI director — posted on X what would become one of the most-quoted developer statements of the year: „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.”

    By March, Merriam-Webster had listed the term as „slang & trending”. By December, Collins Dictionary had named it word of the year for 2025. And throughout that year, a wave of peer-reviewed research tried to answer the question the industry had been asking since February: does it actually work?

    The answer is more nuanced than most headlines suggest.

    A definition worth clarifying

    Vibe coding isn’t the same as no-code. It’s not copying ChatGPT outputs either. Researchers at ICSE 2026 define it as an iterative cycle: formulate a goal in natural language → prompt → review code → test → refine. The human remains the product owner and architect. AI is the implementation partner.

    This shifts what expertise is required — but doesn’t eliminate it. You don’t need to know how to write a React hook with optimistic UI updates. You need to know that you need one and why.

    What the research says — productivity

    Several significant studies were published in 2025. Here’s what the data shows.

    Key studies — 2025

    101 practitioner sources, 518 documented first-hand accounts of vibe coding. Top motivations: faster prototyping, accessibility for non-developers, idea exploration. Top challenges: security vulnerabilities, technical debt, lack of understanding of generated code.

    Multiple real-world apps built using vibe coding. Result: 60–80% faster prototyping, increased creativity, but human oversight required for security, quality, and maintainability.

    Task completion time: 2h41min → 1h11min (55% faster). Success rate: 70% → 78%. 87% of developers reported maintaining flow on complex tasks. 31% faster feature development cycles at team level.

    AI suggestion acceptance rate: 33%, line-of-code acceptance: 20%. Developer satisfaction score: 72/100. Key takeaway: AI accelerates — it doesn’t replace the thinking process.

    New studies — 2026

    16 experienced open-source developers, 246 tasks in mature projects (average 5 years of repo experience). Surprising result: AI increased completion time by 19%. Before tasks, developers predicted 24% speedup — misreading subjective feeling for reality. Context: applies to complex, existing codebases — not greenfield projects.

    Economic analysis by researchers at CEU Budapest and Kiel Institute. Vibe coding boosts productivity by making open-source easier to use — but simultaneously eliminates user engagement (bug reports, docs, maintainer support) that sustains the OSS ecosystem. Conclusion: under widespread vibe coding, existing OSS business models are financially unsustainable.

    Preregistered cross-sectional study, N=100 students. Result: writing ability and CS knowledge are the strongest predictors of vibe coding effectiveness — stronger than general cognitive ability. Vibe coding does not eliminate the knowledge barrier — those with solid CS fundamentals and clear thinking extract far more value from it.

    Data from task management, IDE, static analysis and CI/CD systems over 2 years. Over 75% of developers use AI coding assistants — but organisational productivity gains are just ~10%. Developers feel faster; company-level software delivery metrics don’t confirm it.

    Task completion time with and without AI (minutes, GitHub Research 2024, n=95)

    Controlled conditions, 95 professional developers. 55% time reduction with Copilot, over 67% with advanced agents.

    What the research says — code quality

    This is where the data gets less comfortable for vibe coding enthusiasts.

    GitClear analysed 211 million changed lines of code from 2020–2024 and identified what they call AI-induced tech debt. The results are sobering:

    Code quality degradation — GitClear 2025 metrics (value „1” = 2020 baseline / human-written code)

    Source: GitClear AI Copilot Code Quality Research 2025, 211M lines of code. CodeRabbit (470 PRs, December 2025): AI co-authored code has 1.7x more „major issues”.

    An independent CodeRabbit analysis from December 2025 (470 pull requests) confirmed: AI-assisted code contains 1.7x more serious defects — primarily logic errors, flawed control flow, and incorrect dependencies.

    The vibe coding paradox: 55% faster, but 2.74x more security vulnerabilities. Both numbers are true simultaneously.

    Code refactoring dropped from 25% of changed lines in 2021 to under 10% in 2024. Duplication grew 8x. Copy-pasted code exceeded moved code for the first time in two decades.

    Security case — Lovable (May 2025)

    170 out of 1,645 apps built with Lovable had a vulnerability allowing access to user personal data without authentication. The apps were live in production. None displayed any security warning.

    Tool comparison

    The ecosystem grew fast. Two categories: IDE assistants (Claude Code, Cursor, Windsurf, Codex) and app builders (Lovable, Bolt, v0). They differ fundamentally in target audience and use case.

    Tool Best for Strengths Weaknesses $/mo
    Claude Code Senior devs, complex projects SWE-bench leader (79.6% Sonnet 4.6, 87.6% Opus 4.7). Best context retention across 40+ files simultaneously. Precise cross-file refactoring. Terminal-first, no unnecessary GUI. Terminal only — no GUI. Slower on simple one-off tasks. Higher cost under heavy usage. $20–200
    Cursor Developers, teams Full IDE (VS Code fork), 1M+ users. Up to 8 parallel agents with auto-judge. .cursorrules for project context. Largest ecosystem (360k paying customers, $29.3B valuation). Loses context on very large refactors. Lock-in to its own IDE — no JetBrains/Vim support. $20
    Windsurf Devs, multi-IDE users Cascade (persistent agentic context, self-recovery). Plugins for 40+ IDEs (JetBrains, Vim, XCode, NeoVim). #1 LogRocket AI Dev Tool Rankings (Feb 2026). Acquired by Cognition for $250M. Smaller ecosystem than Cursor. Strategic uncertainty post-acquisition by Cognition (makers of Devin). $20
    Codex (OpenAI) Devs, enterprise GPT Open-source CLI. Built-in web search enabled by default. MCP server support. SWE-bench ~85% (GPT-5.3-Codex). Low-latency optimised. Image input support (screenshots, wireframes). Newer tool, smaller community. Interface less polished than Cursor/Claude Code. Less control over the execution environment. in ChatGPT plan
    Lovable Non-devs, MVPs Fastest start — from description to working app in minutes. Great UI/UX output. Zero technical knowledge required. Perfect for validating an idea fast. Documented security vulnerabilities (170/1,645 apps). Struggles with changing requirements. Not suitable for complex systems. $25–50
    Bolt.new Non-devs, prototypes StackBlitz in the browser — zero installation. Fast start. Good for demos and showcases. Loses coherence on requirement changes. Similar limitations to Lovable — not production-ready without audit. $20
    v0 (Vercel) Designers, frontend devs Best for UI components (React/Next.js/shadcn). Perfect Vercel integration. Precise styling output. Great for designers with minimal JS knowledge. Narrow scope — frontend/UI only. Doesn’t replace a full coding assistant. $20

    SWE-bench: how real coding ability is measured

    SWE-bench Verified is a benchmark built from real GitHub bugs — not synthetic tasks. The model receives a repository and an issue, and must independently write a patch that passes the tests. It’s the most credible measure of an AI agent’s real-world coding capability.

    SWE-bench Verified — top model scores (April 2026, % of issues resolved)

    From 48.5% (GPT-4 Turbo, November 2023) to 87.6% (Claude Opus 4.7, April 2026) in under 2.5 years. The rate of improvement is as striking as the score itself.

    Which tool to choose — decision map

    🎯
    Large codebase, deep refactoring, 40+ files at once?
    → Claude Code. Best context retention, SWE-bench leader.

    Want a full AI-native IDE, largest ecosystem, parallel agents?
    → Cursor. Market leader, 1M+ users, VS Code fork.

    🔧
    JetBrains, Vim, XCode — don’t want to switch editors?
    → Windsurf. Only tool with plugins for 40+ IDEs.

    🌐
    OpenAI/GPT-5 ecosystem, need live web search and MCP?
    → Codex CLI. Open-source, built-in web search, good for tasks requiring current data.

    🚀
    Non-developer, want to test an app idea in an hour?
    → Lovable or Bolt. No technical knowledge required. Get a security audit before going live.

    The best 2026 strategy: Claude Code or Codex for complex agentic tasks; Cursor or Windsurf for everyday IDE coding; Lovable / Bolt / v0 for fast prototyping without technical expertise. Most experienced teams use multiple tools simultaneously — depending on the task.

    Vibe coding — what it means

    Karpathy, who coined the term, later admitted publicly that he hand-coded his next project — because it required precision that vibe coding couldn’t deliver. That’s a good metaphor for the whole phenomenon.

    Vibe coding doesn’t replace programming. It dramatically lowers the barrier to entry — and that’s it. The data shows 55% speed gains alongside 2.74x more security vulnerabilities. Both numbers are true simultaneously. The question is no longer „whether to use AI for coding” — that’s settled.

    The question is: when does a human step in and take responsibility for what AI wrote? For a prototype — maybe never. For a system processing real user data — always, before the code goes live.


    Sources: Karpathy (X, Feb 2025) · arxiv 2510.00328 / 2510.12399 (ICSE 2026) · IJSAT 2025 · GitHub/Microsoft Research 2024 (n=95) · GitClear 2025 (211M lines) · CodeRabbit (470 PRs, Dec 2025) · ZoomInfo Enterprise Study (Jan 2025) · METR RCT arxiv 2507.09089 · arxiv 2601.15494 „Vibe Coding Kills OSS” · arxiv 2603.14133 · Faros AI (22K devs) · SWE-bench (Apr 2026) · Collins Dictionary Word of the Year 2025

  • Vibe coding: co mówią badania naukowe, i porównanie narzędzi

    Vibe coding: co mówią badania naukowe, i porównanie narzędzi

    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.

    Kluczowe badania 2025

    101 źródeł z praktyki, 518 udokumentowanych przypadków użycia vibe codingu. Główne motywacje: szybsze prototypowanie, dostępność dla non-developerów, eksploracja pomysłów. Główne problemy: bezpieczeństwo, dług techniczny, brak rozumienia generowanego kodu.

    Kilka rzeczywistych aplikacji budowanych metodą vibe coding. Wynik: przyspieszenie prototypowania o 60–80%, wzrost kreatywności, ale konieczność nadzoru człowieka przy bezpieczeństwie i utrzymaniu kodu.

    Czas realizacji zadania: 2h41min → 1h11min (55% szybciej). Skuteczność: 70% → 78%. 87% deweloperów zgłosiło zachowanie flow przy złożonych zadaniach. 31% szybsze cykle feature development w teamach.

    Acceptance rate sugestii AI: 33%, akceptacja linii kodu: 20%. Developer satisfaction score: 72/100. Kluczowy wniosek: AI jest narzędziem do przyspieszania, nie zastępowania procesu myślowego.

    Nowe badania 2026

    16 doświadczonych deweloperów open-source, 246 zadań w dojrzałych projektach (średnio 5 lat doświadczenia z repozytorium). Wynik zaskakujący: AI wydłużyło czas realizacji o 19%. Przed zadaniami deweloperzy zakładali 24% przyspieszenie — mylili subiektywne odczucie z rzeczywistością. Kontekst: dotyczy złożonych, istniejących codebases, nie nowych projektów.

    Analiza ekonomiczna autorów z CEU Budapest i Kiel Institute. Vibe coding podnosi produktywność przez ułatwienie korzystania z open-source — ale jednocześnie eliminuje zaangażowanie użytkowników (bugi, dokumentacja, wsparcie maintainerów), z którego OSS czerpie utrzymanie. Wniosek: przy powszechnym vibe codingu obecne modele OSS nie są finansowo zrównoważone.

    Badanie preregistrowane, N=100 studentów. Wynik: umiejętności pisania i wiedza CS to najsilniejsze predyktory efektywności w vibe codingu — silniejsze niż ogólne zdolności poznawcze. Vibe coding nie niweluje bariery wiedzy — osoby z solidną bazą CS i umiejętnością precyzyjnego formułowania myśli korzystają z niego znacznie skuteczniej.

    Dane z systemów task management, IDE, statycznej analizy i CI/CD z 2 lat. Ponad 75% deweloperów używa AI coding assistants — ale organizacyjny wzrost produktywności wynosi zaledwie ~10%. Deweloperzy czują że są szybsi; firmowe metryki dostarczania oprogramowania tego nie potwierdzają.

    Czas realizacji zadania kodowania z AI i bez (minuty, GitHub Research 2024, n=95)

    Kontrolowane warunki, 95 profesjonalnych deweloperów. Redukcja czasu o 55% przy użyciu Copilot, ponad 67% przy zaawansowanych agentach.

    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:

    Degradacja jakości kodu — wskaźniki GitClear 2025 (wartość „1” = poziom bazowy 2020/human-written)

    Źródło: GitClear AI Copilot Code Quality Research 2025, 211M linii kodu. CodeRabbit (470 PR, grudzień 2025): kod AI ma 1,7x więcej „major issues”.

    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.

    Przypadek bezpieczeństwa — Lovable (maj 2025)

    170 z 1 645 aplikacji zbudowanych przez Lovable miało lukę, która umożliwiała dostęp do danych osobowych użytkowników bez uwierzytelnienia. Aplikacje były w produkcji. Żadna nie wysyłała ostrzeżenia o podatności.

    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.

    Narzędzie Dla kogo Mocne strony Słabe strony $/mies.
    Claude Code Senior dev, złożone projekty Lider SWE-bench (79,6% Sonnet 4.6, 87,6% Opus 4.7). Najlepszy kontekst przy 40+ plikach naraz. Precyzyjny refactoring cross-file. Terminal-first — bez zbędnego GUI. Terminal only — brak GUI. Wolniejszy przy prostych, jednorazowych zadaniach. Wyższy koszt przy intensywnym użyciu. $20–200
    Cursor Deweloperzy, teams Pełny IDE (fork VS Code), 1M+ użytkowników. Do 8 równoległych agentów z auto-judge. .cursorrules dla kontekstu projektu. Największy ekosystem na rynku (360k płatnych klientów). Traci kontekst przy bardzo dużych refaktoryzacjach. Lock-in do własnego IDE — nie działa w JetBrains/Vim. $20
    Windsurf Deweloperzy, multi-IDE Cascade (persistentny kontekst agentowy, self-recovery). Wtyczki do 40+ IDE (JetBrains, Vim, XCode, NeoVim). Nr 1 LogRocket AI Dev Tool Rankings (luty 2026). Przejęty przez Cognition za $250M. Mniejszy ekosystem niż Cursor. Niepewność strategiczna po przejęciu przez Cognition (twórca Devin). $20
    Codex (OpenAI) Dev, enterprise GPT Open-source CLI. Wbudowane web search domyślnie. Wsparcie MCP servers. SWE-bench ~85% (GPT-5.3-Codex). Zoptymalizowany pod niskie opóźnienia. Wsparcie obrazów (screenshoty/wireframes). Młodsze narzędzie, mniejsza społeczność. Interfejs mniej dopracowany niż Cursor/Claude Code. Mniejsza kontrola nad środowiskiem. w planie ChatGPT
    Lovable Non-dev, MVP Najszybszy start — od opisu do działającej aplikacji w minuty. Świetny output UI/UX. Zero wiedzy technicznej wymagane. Idealny do walidacji pomysłu. Udokumentowane luki bezpieczeństwa (170/1645 aplikacji). Słaby przy zmieniających się wymaganiach. Nie nadaje się do złożonych systemów. $25–50
    Bolt.new Non-dev, prototyp StackBlitz w przeglądarce — zero instalacji. Szybki start. Dobre do demo i showcase. Traci spójność przy zmianach wymagań. Podobne ograniczenia jak Lovable — nie do produkcji bez audytu. $20
    v0 (Vercel) Designerzy, frontend Najlepszy do UI komponentów (React/Next.js/shadcn). Idealna integracja z Vercel. Precyzyjny w stylowaniu. Dobry dla designerów z minimalną wiedzą JS. Wąski zakres — frontend/UI only. Nie zastępuje pełnego asystenta kodowania. $20

    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.

    SWE-bench Verified — wyniki głównych modeli (kwiecień 2026, % rozwiązanych issues)

    Wzrost z 48,5% (GPT-4 Turbo, listopad 2023) do 87,6% (Claude Opus 4.7, kwiecień 2026) w niecałe 2,5 roku. Szybkość poprawy jest równie imponująca jak sam wynik.

    Które narzędzie wybrać — mapa decyzji

    🎯
    Duża baza kodu, głęboki refactoring, 40+ plików na raz?
    → Claude Code. Najlepsza retencja kontekstu, lider SWE-bench.

    Chcesz pełne IDE z AI, największy ekosystem, równoległe agenty?
    → Cursor. Lider rynku, 1M+ użytkowników, fork VS Code.

    🔧
    JetBrains, Vim, XCode — nie chcesz zmieniać edytora?
    → Windsurf. Jedyne narzędzie z wtyczkami do 40+ IDE.

    🌐
    Ekosystem OpenAI/GPT-5, zależy Ci na web search i MCP?
    → Codex CLI. Open-source, wbudowane web search, dobry przy zapytaniach wymagających aktualnych danych.

    🚀
    Non-developer, chcesz przetestować pomysł na aplikację w godzinę?
    → Lovable lub Bolt. Bez żadnej wiedzy technicznej. Pamiętaj o audycie bezpieczeństwa przed produkcją.

    Najlepsza strategia w 2026: Claude Code lub Codex do złożonych zadań agentowych; Cursor lub Windsurf do codziennego kodowania w IDE; Lovable / Bolt / v0 do szybkiego prototypowania bez wiedzy technicznej. Większość doświadczonych zespołów używa kilku narzędzi jednocześnie — zależnie od zadania.

    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

  • AI w rekrutacji: jak delegować zadania, nie myślenie

    AI w rekrutacji: jak delegować zadania, nie myślenie

    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:

    Jak działy HR używają AI — regularne zastosowania (% respondentów, LinkedIn Talent Trends 2024)

    Widać wyraźnie: AI jest najchętniej używane do zadań administracyjnych — i właśnie tam daje największą wartość bez ryzyka.

    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ń:

    🎙️
    Granola
    Najlepszy do: notatek ze spotkań
    Transkrybuje i streszcza rozmowy w czasie rzeczywistym. Skupiasz się na kandydacie, nie na notatkach. Najlepsze narzędzie tego typu.

    🌐
    ChatGPT
    Najlepszy do: researchu online
    Dostęp do internetu w czasie rzeczywistym. Sprawdza firmy, zbiera kontekst branżowy, szkicuje ogłoszenia i szablony dokumentów.

    📄
    Claude
    Najlepszy do: długich dokumentów
    Analiza dłuższych CV, briefów, raportów. Duże okno kontekstowe — czyta cały plik naraz. Precyzyjny przy złożonych zapytaniach.

    🇵🇱
    Bielik
    Najlepszy do: wrażliwych danych
    Polski model open-source. Dane kandydatów przetwarzane lokalnie — bez wysyłania do zewnętrznych serwerów. Dobry dla RODO.

    Wspólny mianownik: AI pomaga tam, gdzie zadanie jest powtarzalne, ustrukturyzowane i nie wymaga oceny człowieka jako człowieka.

    Gdzie zaczyna się problem

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

    Sygnały ostrzegawcze — kiedy AI zaczyna myśleć za Ciebie

    Pytasz AI o opinię zanim wyrobisz własną
    „Oceń tego kandydata na podstawie CV” — zanim sam przejrzałeś dokument.

    Pytania rekrutacyjne generujesz w całości z AI
    Rozmowa jest technicznie poprawna, ale generyczna — nie wydobywa tego co ważne dla Twojego zespołu.

    AI podsumowuje rozmowę — i to staje się Twoim wspomnieniem kandydata
    Streszczenie jest dokładne, ale wycinasz z procesu własną intuicję i emocjonalny odbiór rozmowy.

    Decyzja „tak/nie” jest de facto decyzją modelu
    Skoring AI wyrzucił kandydata z procesu — i nikt nie sprawdził dlaczego.

    Framework: najpierw Ty, potem AI

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

    1

    Zanim zapytasz AI — 2 minuty własnej myśli
    Przejrzyj CV. Posłuchaj nagrania. Przeczytaj cover letter. Zrób mentalną notatkę. Dopiero potem użyj AI do weryfikacji lub rozwinięcia. To jedyna zasada, która wymaga dyscypliny — reszta jest łatwa.

    2

    AI przyspiesza, nie startuje
    Użyj modelu do usprawnienia czegoś, co już przemyślałeś — nie do wypełnienia luki zanim myśl powstała. Różnica jest subtelna, ale konsekwencje są zupełnie inne.

    3

    Każda decyzja o człowieku ma być Twoja
    AI może rekomendować, rankingować, sugerować. Ale „zatrudniamy” i „nie zatrudniamy” to zdania, za którymi stoi człowiek — nie model. To nie jest retoryka. To jest odpowiedzialność.

    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

  • AI in Recruitment: How to Delegate Tasks, Not Thinking

    AI in Recruitment: How to Delegate Tasks, Not Thinking

    Recently I was looking for a specific piece of equipment to buy. Instead of first thinking through what I actually needed, I opened ChatGPT and typed a query. Got an answer. Made a decision. Fast, efficient — but not mine.

    I realised afterwards that I hadn’t even formed my own opinion. AI filled the gap before it had a chance to exist.

    Harmless when buying headphones. In recruitment — not so much.

    Why this matters more in HR than anywhere else

    In most jobs, if AI „thinks for you” — the consequence is a worse document, a wasted hour, a correction in the spreadsheet. In HR, the consequence is a person who didn’t get a job they deserved. Or a company that hired someone who looked perfect on paper — and didn’t work out.

    AI in recruitment operates on data about people. It’s the only field where a model’s mistake has a face.

    HR teams are reaching for AI more and more, and rightly so — these tools genuinely reduce repetitive work. But there’s a subtle difference between „AI speeds up my work” and „AI thinks instead of me”. In recruitment, that difference is critical.

    Where AI in HR genuinely helps

    Before the caveats — fair use. The data is clear about where language models perform well:

    How HR teams use AI — regular applications (% of respondents, LinkedIn Talent Trends 2024)

    The pattern is clear: AI is most adopted for administrative tasks — and that’s precisely where it delivers the most value with the least risk.

    The pattern is clear: AI is most adopted for repetitive and administrative tasks. These are also the places where model errors are easy to catch and correct. Specific tools for specific tasks:

    🎙️
    Granola
    Best for: meeting notes
    Transcribes and summarises conversations in real time. You focus on the candidate, not note-taking. Best tool of its kind.

    🌐
    ChatGPT
    Best for: live research
    Real-time internet access. Checks companies, gathers industry context, drafts job ads and document templates.

    📄
    Claude
    Best for: long documents
    Analyses longer CVs, briefs, reports. Large context window — reads an entire file at once. Precise on complex queries.

    🇵🇱
    Bielik
    Best for: sensitive data
    Polish open-source model. Candidate data processed locally — no sending to external servers. Good for GDPR compliance.

    The common denominator: AI helps where the task is repetitive, structured and doesn’t require judging a person as a person.

    Where the problem starts

    The problem appears when AI moves into areas requiring human judgement — and does so quietly.

    Warning signs — when AI starts thinking for you

    You ask AI for an opinion before forming your own
    „Assess this candidate based on their CV” — before you’ve read it yourself.

    You generate interview questions entirely with AI
    The conversation is technically correct but generic — it doesn’t draw out what matters for your specific team.

    AI summarises the interview — and that becomes your memory of the candidate
    The summary is accurate, but you’ve cut your own intuition and emotional read of the conversation out of the process.

    The yes/no decision is effectively the model’s decision
    AI scoring dropped the candidate from the process — and nobody checked why.

    Framework: you first, then AI

    The principle I apply in my own work and propose to HR teams:

    1

    Before asking AI — 2 minutes of your own thinking
    Skim the CV. Listen to the recording. Read the cover letter. Make a mental note. Then use AI to verify or expand. This is the only rule that requires discipline — the rest is easy.

    2

    AI accelerates, it doesn’t initiate
    Use the model to improve something you’ve already thought through — not to fill the gap before the thought exists. The difference is subtle, but the consequences are completely different.

    3

    Every decision about a person must be yours
    AI can recommend, rank, suggest. But „we’re hiring” and „we’re not hiring” are sentences backed by a human — not a model. This isn’t rhetoric. It’s accountability.

    AI is like a good assistant — not a good recruiter

    A good assistant takes the admin off your plate, speeds up research, prepares drafts. But it doesn’t replace your judgement of a person. It can’t sense the tension in a candidate’s voice. It won’t notice that someone is excellent despite an imperfect CV. It won’t feel that despite perfect competencies — someone won’t fit your team’s culture.

    These things are non-transferable. And that’s exactly why they’re your advantage — regardless of how many models appear on the market.


    Tools mentioned: Granola (granola.so) | ChatGPT (openai.com) | Claude (claude.ai) | Bielik (speakleash.org) | Data: LinkedIn Talent Trends 2024

  • Jak uczyć AI ludzi, którzy nie są programistami — wnioski z wdrożeń

    Jak uczyć AI ludzi, którzy nie są programistami — wnioski z wdrożeń

    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.

    Zasada: zacznij od problemu, który uczestnik ma dziś. Nie od technologii, którą chcesz mu pokazać.

    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.
    ~40%

    krótszy czas onboardingu po VR vs. tradycyjne szkolenie (Krakodlew, 2018)
    0

    incydentów spowodowanych luką proceduralną w pierwszych 6 mies. pracy (ta sama kohorta)

    szybsze przyswajanie wiedzy w środowisku immersyjnym vs. sala (PwC 2020, n=10 000)

    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

    Najważniejsze zdanie, które możesz powiedzieć uczniowi: „Nie wiem, sprawdźmy razem.” To modeluje dokładnie ten rodzaj myślenia, który AI wymaga.

    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.

  • How to Teach AI to Non-Programmers — Lessons from Industrial Implementations

    How to Teach AI to Non-Programmers — Lessons from Industrial Implementations

    2018. I’m standing with a group of foundry operators at Krakodlew in Kraków. They’re about to put on VR headsets for the first time in their lives. One of them — 20 years at the furnace, deeply experienced — tells me: „This is for young people. I know what I’m doing.”

    Two hours later, that same person asks me when the next session is.

    Teaching technology — especially AI and AI-powered tools — follows the same pattern. The entry barrier is psychological, not technical. And when you break through it with the right method, the rest comes surprisingly quickly.

    Over the last several years I’ve worked with people who had never written a line of code: machine operators, production managers, executives, vocational school students. Here’s what actually works.

    Mistake #1: start with the technology

    Most AI courses and workshops begin like this: „Today you’ll learn about language models. An LLM is a model trained on large datasets…”

    You lose the learner by the fourth sentence.

    Adults learn differently from children. They don’t absorb abstractions first and then search for applications — they absorb concrete experience first and then find theory to explain it. Andragogy (adult learning theory) has been saying this since the 1960s. The problem is that most AI instructors are engineers who teach the way they themselves learned.

    Rule: start with a problem the participant has today. Not with the technology you want to show them.

    At the foundry, we didn’t start with „how VR works.” We started with: „Let me show you a situation where an accident happened at a similar plant. How would you respond?” The technology became a tool for solving a specific, real problem. Not a demonstration.

    The framework that works: „Touch first, explain after”

    Through VR training, I developed a sequence I call „touch first, explain after.” It works exactly the same in teaching AI and vibe coding:

    • 1. Do it together — don’t explain first. Give the participant a simple task to complete immediately. A mistake in a safe environment teaches more than an hour of lecture.
    • 2. Name it together — when something works (or doesn’t), ask: „What just happened? Why do you think that is?” The learner builds a mental model from their own experience.
    • 3. Now explain the mechanism — only now do concepts like „token,” „context,” „temperature” have meaning. Because you have a concrete situation to attach them to.
    • 4. Give them a problem to solve independently — not „an exercise with instructions.” A problem you haven’t walked through with them before.
    ~40%

    shorter onboarding time after VR vs. traditional training (Krakodlew, 2018)
    0

    incidents caused by procedure gaps in first 6 months (same cohort)

    faster knowledge acquisition in immersive environment vs. classroom (PwC 2020, n=10,000)

    These numbers are from VR training, but the pattern is the same: when you teach through doing, not through listening, outcomes are dramatically different.

    What blocks AI learning — and how to remove it

    Teaching AI and vibe coding, you’ll encounter the same barriers repeatedly:

    „This isn’t for me, I’m not technical enough”

    Antidote: show a specific example of someone similar to the learner who’s already doing it. Not Elon Musk. Someone who runs a small business and uses Claude to write proposals. Someone who’s an operator and learned to program a robot in a course. Identification before aspiration.

    „I don’t know what to say to AI”

    Antidote: give them templates. Not as rigid forms, but as starting points. „I am [role], I’m trying to [goal], I have a problem with [specific].” Learners need scaffolding before they build their own prompting style.

    „How do I know if the answer is correct?”

    This is the best barrier, because it’s legitimate. Critical thinking toward AI output is a key skill — not an obstacle to learning. Teach the learner to verify: cross-check with another source, test „does this make sense in my context,” ask AI a follow-up („check whether you made an error in assumption X”).

    The best AI learners aren’t those who trust it unconditionally — they’re those who can hold a dialogue: ask, verify, correct, iterate.

    Robotics as the entry point to AI for younger learners

    At XR FabLab in Chrzanów, we worked with vocational high school students. The threshold for abstract „AI” was too high. Robotics turned out to be the perfect bridge.

    Why robotics works:

    • Immediate feedback loop — the robot moves or it doesn’t. No ambiguity. The student sees the result of their decision within seconds, not days.
    • Physical artifact — they can touch it, show it to parents, break it and fix it. Code on a screen is abstract. A robot is real.
    • Programming as commands — students intuitively understand a sequence of instructions. It’s a direct analogy to prompting AI.
    • Competitive element — races, challenges, leaderboards. External motivation until intrinsic motivation develops.

    When a student understands that the robot does exactly what they told it to do — no more, no less — they also understand why precision in prompting matters. That’s the transfer moment.

    What separates a good AI instructor from a weak one

    A good AI instructor isn’t someone who has the API documentation memorised. It’s someone who:

    • Remembers what it felt like to not know — and can genuinely inhabit the learner’s perspective
    • Gets excited when a student surprises them with a new application of the tool
    • Treats a student’s mistake as diagnostic information, not failure
    • Is still learning themselves — AI changes every few months, and standing still means falling behind

    The most important sentence you can say to a learner: „I don’t know, let’s find out together.” That models exactly the kind of thinking AI requires.

    A practical starting framework

    If you’re designing an AI course or workshop from scratch, one structure I’d recommend:

    • Session 1: Participant’s problem → first contact with the tool → surprise (good or bad) → shared analysis
    • Session 2: Building vocabulary → prompt templates → first independent task
    • Session 3+: Participant’s own project → iteration → presenting the result

    The own project is critical. When a participant solves their own problem — not a practice exercise — and AI helps them do it, that’s when the tool becomes theirs.

    Who in your organisation or classroom is hardest to convince about AI — and what’s their main barrier?


    Author has been implementing VR training in industrial environments since 2018 (Krakodlew, XR FabLab Chrzanów). Teaches AI, automation and AI-assisted coding in practical contexts — in Poland and internationally. Sources: PwC VR Soft Skills Study 2020 (n=10,000); own data Krakodlew/Industrverse 2018–2024.