Czas onboardingu — setup <1 dzień z bootstrap script

Pytanie 19 (Wzmacnianie organizacji): Jak długo trwa “time to productive AI workflow” dla nowego inżyniera?

Odpowiedź na maksimum: <1 dzień: bootstrap script instaluje CLAUDE.md, hooks, skills, MCP; buddy + przykładowe sesje pierwszego dnia.

Dlaczego to ważne: Tarcie przy setupie jest niewidoczne dla organizacji, ale bardzo widoczne w pierwszej ocenie nowego pracownika. Onboarding krótszy niż dzień dramatycznie wpływa na retencję.

Dlaczego to ma znaczenie w 2026 (wpływ na retencję)

W połowie 2026 różnica między silną a borykającą się organizacją inżynierską nie polega na tym, czy używają Claude Code lub Cursora — używają wszyscy poważni. Różnica polega na tym, jak długo nowy pracownik dochodzi do dziennej produktywności porównywalnej z medianą zespołu. W 2023 ta luka mierzyła się w miesiącach. W 2024 skurczyła się do tygodni. W 2026, w zespołach które zainwestowały w onboarding AI-native, mierzy się w godzinach — a zespoły które nie zainwestowały, tracą seniorów odmawiających spędzenia pierwszego tygodnia na debugowaniu dotfiles.

Mechanizm jest prosty i brutalny: tarcie przy setupie jest niewidoczne dla zarządu, ale głośne w głowie nowego pracownika. Senior dołączający do Twojego zespołu właśnie wyszedł z miejsca, gdzie był produktywny pierwszego dnia. Kalibruje się względem tego doświadczenia. Każda godzina spędzona na “zaraz, jak uwierzytelnić MCP?” albo “jaki jest kanoniczny CLAUDE.md dla tego repo?” czyta się wewnętrznie jako “to miejsce nie jest poważne”. Pomnóż przez pierwszy tydzień i już utrudniłeś sobie rozmowę o retencji bardziej, niż musisz — nawet jeśli inżynier nigdy nie powie tego głośno.

Reframe na 2026 polega na tym, że “time to productive AI workflow” jest metryką onboardingu pierwszej klasy, obok time-to-first-commit i time-to-first-PR. Zespoły traktujące to w ten sposób raportują liczby, które dwa lata temu byłyby nie do pomyślenia. Publiczne opisy zespołów stosujących onboarding bootstrap-script opisują zastąpienie “12-stronicowego setup wiki pojedynczym bootstrap scriptem, który robi wszystko — skrypt jest dokumentacją, a onboarding spadł z tygodni do mniej niż 5 minut”. Szersze dane branżowe o onboardingu wspartym AI wskazują w tym samym kierunku: ustrukturyzowane programy onboardingowe AI redukują time-to-productivity o około 50% wobec starego wzorca “przeczytaj wiki, zapytaj na Slacku”, z mierzalnym wzrostem retencji w 90 dni.

Jest też efekt drugiego rzędu, jeszcze ważniejszy dla kierownictwa inżynierskiego: organizacja, która onboarduje seniora do “productive AI workflow” w mniej niż dzień, jest organizacją, która przy okazji rozwiązała większość problemów z wewnętrznym tooling. Bootstrap script nie kłamie. Jeśli działa pierwszego dnia, znaczy to, że Twój CLAUDE.md jest kanoniczny, hooks są versioned, skills repo jest realne, katalog MCP jest curated, a przykładowe workflow są udokumentowane. Każda organizacja z maxem na Q19 trafia jednocześnie w Q5, Q6, Q7, Q17 i Q18 — dlatego to pytanie jest silnym proxy dla ogólnej dojrzałości organizacji.

Jak wygląda “max score” w praktyce (bootstrap + buddy + przykładowe sesje pierwszego dnia)

Trzy komponenty zaprojektowane tak, by skompresować to, co kiedyś trwało tydzień, do jednego dnia roboczego:

1. Bootstrap script instalujący CLAUDE.md, hooks, skills i MCP. Jedna komenda — curl -fsSL https://acme.dev/dev-bootstrap | bash, lub npx @acme/dev-setup, lub ./bootstrap.sh z firmowego dotfiles repo — która bierze świeżo zaimagowany laptop i zamienia go w w pełni skonfigurowane środowisko AI dev. Klonuje firmowe dotfiles do ~/.claude/ i ~/.codex/, sadzi kanoniczny projektowy CLAUDE.md, gdy nowy pracownik klonuje pierwsze repo, rejestruje hooki SessionStart i PreToolUse, które organizacja standaryzuje, symlinkuje wspólne skills repo i wpisuje katalog MCP do właściwych configów z placeholderami na per-user secrets, które nowy pracownik wypełnia raz.

2. Buddy sparowany na pierwszy tydzień. Nazwany senior inżynier, którego praca w pierwszym tygodniu to bycie pierwszym kontaktem dla nowego pracownika. Buddy nie jest code reviewerem ani managerem — jest osobą, której zadajesz pytania “czy to jest normalne?” bez poczucia, że robisz z siebie głupka. Siedzi z nowym pracownikiem przy bootstrapie pierwszego dnia, obserwuje pierwszą sesję z agentem i dwa razy dziennie sprawdza, jak idzie, przez pierwsze trzy dni. Rola buddy rotuje kwartalnie, żeby ta sama osoba nie nosiła jej zawsze, i żeby każdy senior był po obu stronach relacji.

3. Przykładowe sesje pierwszego dnia. Od trzech do pięciu nagranych “pokaż mi, jak shipnąć małą funkcję” — video lub live walkthroughs pokazujące house style pracy z agentem na Waszym kodzie. Nie “jak używać Claude Code” w ogóle — to oczywistość — ale “tak właśnie my promptujemy route handler change w tym repo, tak wygląda plan-mode flow przy migracjach, tak używamy worktree skill do shippowania dwóch równoległych zmian”. To nie dokumentacja, tylko przykłady. Nowy pracownik ogląda je pierwszego dnia i kopiuje wzorce.

4. Cel deliverable na pierwszy dzień. Mały, prawdziwy PR przechodzący całą pętlę — branch, sesja z agentem, code review (człowiek + bot), CI, merge — do końca pierwszego dnia. Nie sztuczne zadanie. Coś naprawdę małego z backlogu, które buddy z góry zwalidował jako “wykonalne w cztery godziny z agentem”. Shipnięcie prawdziwego zmergowanego PR pierwszego dnia to najlepszy sygnał, że onboarding faktycznie zadziałał.

Czysta wersja timeline’u nowego pracownika:

Dzień 0 (przyjazd laptopa)
  └─ Laptop zaimagowany z firmowym dev image. Nic więcej.

Dzień 1, godzina 0–1
  └─ Bootstrap script uruchamia się.
     - Dotfiles sklonowane do ~/.claude, ~/.codex
     - Wspólne skills zsymlinkowane
     - Hooki zarejestrowane w settings.json
     - Katalog MCP zapisany; prompt o sekrety
     - Agent zweryfikowany /skills, /mcp checks

Dzień 1, godzina 1–3
  └─ Buddy prowadzi przez 1 przykładową sesję live.
     - Nowy pracownik obserwuje worktree + plan-mode flow.
     - Otwiera własną sesję w sandbox repo.

Dzień 1, godzina 3–7
  └─ Nowy pracownik shipuje mały zwalidowany PR end-to-end.
     - Branch, sesja, PR, review, CI, merge.
     - Buddy on-call przy blockerach, ale nie prowadzi.

Dzień 1, koniec dnia
  └─ Zmergowany PR. Działający AI workflow. Ta sama
     powierzchnia produktywności co reszta zespołu.

Ta ostatnia linia to bramka. Nowy pracownik kończy dzień 1 z tą samą powierzchnią produktywności co reszta — te same skills załadowane, te same hooki działają, ten sam katalog MCP, ten sam house style promptowania. Od dnia 2 jest normalnym członkiem zespołu, który po prostu jest nowy.

Aktualny krajobraz (zweryfikowany web-searchem)

Bootstrap script (klonuje dotfiles, instaluje ~/.claude, ~/.codex, ustawia MCPs, sadzi CLAUDE.md)

Wzorzec na 2026 to jednokomendowy, idempotentny, multi-tool bootstrap. Zespoły publikujące własny — open-source’owe repo alinaqi/claude-bootstrap jest reprezentatywnym przykładem — opisują go jako “opiniowany setup kit Claude Code, który zamienił się w autonomiczne AI engineering command center”. Elementy strukturalne są dziś dobrze ustalone:

Jeden entry point. curl | bash, npx @org/dev-setup albo ./bootstrap.sh. Nowy pracownik nigdy nie musi czytać setup docs, żeby wiedzieć, co uruchomić.
Dotfiles, nie kopie. Skrypt klonuje firmowe dotfiles do stabilnej lokalizacji (~/.acme-dotfiles) i symlinkuje z niej ~/.claude/, ~/.codex/, ~/.cursor/ itd. Jedno git pull aktualizuje wszystkie narzędzia naraz, a nowy pracownik nigdy nie edytuje katalogów konfiguracyjnych agenta bezpośrednio.
Idempotentny. Uruchom go pięć razy z rzędu i stan końcowy jest identyczny. To ma znaczenie, bo buddy nieuchronnie odpali go ponownie w pierwszym tygodniu, żeby coś naprawić — nie może zostawić laptopa w stanie w połowie złamanym.
Sadzi projektowy CLAUDE.md. Gdy nowy pracownik klonuje pierwsze robocze repo, krok setupu (target make setup, postinstall w package.json, albo git config core.hooksPath wskazujący w dotfiles) podstawia kanoniczny projektowy CLAUDE.md, jeśli go tam jeszcze nie ma. To pomost między org-level dotfiles a repo-level rules.
Katalog MCP z promptami o sekrety. Organizacja utrzymuje kurowaną listę zaakceptowanych serwerów MCP (zob. Q7). Bootstrap zapisuje katalog do właściwych configów i pyta nowego pracownika o per-user secrets (osobiste tokeny API, flow OAuth do Linear/GitHub/Sentry itd.). Nowy pracownik nigdy nie musi znać schematu — skrypt to wie.
Krok weryfikacji. Skrypt kończy się odpaleniem nieinteraktywnej sesji agenta, która uruchamia /skills, /mcp i mały “hello world” tool call, po czym drukuje zielony checklist. Jeśli coś nie wyszło, skrypt mówi dokładnie, co i jak naprawić.

Instalacje krótsze niż 5 minut są raportowane przez zespoły zainwestowane w ten wzorzec. Zespoły, które nie zainwestowały, mają zwykle zamiast tego “setup wiki” — stronę w Notion lub Confluence z dwudziestoma siedmioma ręcznymi krokami, z których cztery są przeterminowane w dowolnym momencie. Wzorzec wiki to dokładnie to, co zastępuje bootstrap script, i ta luka jest powodem, dla którego Q19 oddziela organizacje Optimized od Strategic Leader.

Buddy system (sparowany senior na pierwszy tydzień)

Wzorzec buddy jest starszy niż dev AI-native, ale w 2026 został przemyślany specjalnie pod workflow z agentami. Chodzi nie o uczenie nowego pracownika, jak pisać kod — to już umie — tylko o przekazanie tacit style promptowania zespołu. Buddy tłumaczy rzeczy takie jak:

“Zawsze uruchamiamy plan-mode przed jakąkolwiek migracją. Jest hook, który to wymusza, ale powiem ci dlaczego.”
“Gdy refactorujesz API route, załaduj skill refactor-auth — ma w środku nasze konwencje.”
“Nie pchaj agenta przez --dangerously-skip-permissions na tym repo, SessionStart hook to wyłapie.”
“Jeśli agent sugeruje dodanie nowego MCP, najpierw zapytaj na #ai-tooling. Mamy katalog nie bez powodu.”

To są zasady, które nie mieszczą się czysto w CLAUDE.md ani w skillu — kulturalne. Buddy przekazuje je w dniach zamiast w miesiącach.

Publikowane opisy z 2026 opisują równoległą ewolucję: systemy AI-onboarding-buddy, w których to AI staje się buddy, odpowiadając na pytania “czy to jest normalne?” z kurowanego korpusu wewnętrznych docs. Zespół inżynierski Manychat opisał taki system, używający AI buddy do odpowiadania na pierwszą falę pytań onboardingowych, co uwalnia ludzkiego buddy do rzeczy, które potrafi tylko człowiek (decyzje judgmentalne, kontekst dynamiki zespołu, “powinieneś o tym pogadać z X”). Mocny wzorzec na 2026 to jedno i drugie: AI buddy odpowiadający natychmiastowo na FAQ, plus człowiek buddy niosący relację i transmisję kulturową.

Przykładowe sesje (nagrane “pokaż mi, jak shipnąć małą funkcję”)

Pojedynczy artefakt onboardingowy o najwyższej dźwigni w 2026 to mała biblioteka nagranych sesji. Trzy do pięciu video, dziesięć do piętnastu minut każde, na których senior inżynierowie naprawdę shipują małą funkcję z agentem — z narracją, end-to-end, w prawdziwym firmowym kodzie. Gatunek, który działa:

“Dodaj kolumnę do tabeli D1 i wystaw ją w API.” Pokazuje flow migracji, plan-mode, schema-check hook i konwencję aktualizacji testów.
“Napraw buga w webhooku Polara.” Pokazuje, jak seniorzy używają worktree skill, debugging flow agenta i zespołowy wzorzec “zawsze najpierw test”.
“Zrefactoruj wolny komponent React.” Pokazuje Cursor + Claude Code równolegle, konwencje performance-test i jak zespół używa Sentry w pętli.
“Wypchnij małą landing page.” Pokazuje house style Astro/Next, importy z design-systemu i co blokuje linter.
“Triage przychodzącego bug reportu.” Pokazuje integrację z Sentry MCP, pipeline issue-to-PR i jak zespół pisze commit messages.

To nie są filmy szkoleniowe. To przykłady. Nowy pracownik ogląda je pierwszego dnia z buddy i przez osmozę uczy się firmowego stylu promptowania. Zespoły zainwestowane w taki korpus konsekwentnie raportują najwyższe liczby produktywności pierwszego dnia. Zespoły bez tego robią to samo tłumaczenie na żywo, jeden nowy pracownik na raz, w nieskończoność.

Cel deliverable na pierwszy dzień (jeden mały PR przez pełną pętlę)

Najostrzejszy test, czy onboarding zadziałał, to czy nowy pracownik shipuje prawdziwy, zmergowany PR pierwszego dnia. Nie “hello world”. Nie sandbox. Autentyczny, mały PR z backlogu, który buddy z góry zwalidował jako wykonalny w cztery godziny z agentem.

Kandydaci, którzy działają jako PR-y pierwszego dnia:

Fix copy lub i18n oznaczony w zeszłotygodniowym triage.
Mały refactor, na który linter narzeka od dawna.
Test, który leży w backlogu, bo nikt nie miał wolnej godziny.
Fix w wewnętrznym docs site.
Drobny tweak UI, który design już zspecyfikował.

PR to artefakt udowadniający, że pętla się zamknęła. Bootstrap się odpalił. Hooki strzeliły. Skills załadowane. MCP uwierzytelnione. Agent shipnął kod. CI przeszło. Reviewer (człowiek lub bot) zatwierdził. Merge się stał. Każdy krok AI workflow został przećwiczony. Jeśli którykolwiek krok cicho zawiódłby w starym wzorcu onboardingu — brakujący token MCP, nieświeży skill, hook, o którym nowy pracownik nie wiedział — wypłynie tutaj, pierwszego dnia, z buddy w pokoju, żeby to naprawić.

Krok po kroku: budowa onboardingu <1 dzień

Napisz bootstrap script i dogfooduj na czystym laptopie.

Trudność to nie napisanie skryptu, tylko przetestowanie go na naprawdę czystej maszynie. Pożycz świeży laptop, nie odpalaj zwykłego setupu dotfiles i zmierz, ile czasu zajmuje od “otwórz terminal” do “agent shipuje działającą komendę”. Jeśli to ponad godzinę — skrypt nie jest skończony. Stan końcowy powinien być: ~/.claude/ zapełnione, ~/.codex/ zapełnione, hooki zarejestrowane, skills zsymlinkowane, katalog MCP zapisany z promptami o sekrety, oraz krok weryfikacji potwierdzający, że każda część działa.
Wybierz kanoniczny template CLAUDE.md organizacji.

Bootstrap script potrzebuje czegoś do zasadzenia, gdy nowy pracownik klonuje pierwsze repo. To coś to kanoniczny template projektowego CLAUDE.md — zob. Q5 po dłuższą wersję. Trzymaj go krótkim i project-shaped: stack, kluczowe komendy, architektura, konwencje. Bootstrap nie pisze CLAUDE.md od zera — kopiuje template, jeśli repo go nie ma, w przeciwnym razie zostawia w spokoju.
Skuruj katalog MCP i wpisz go do bootstrapu.

Każdy zaakceptowany serwer MCP, którego używa organizacja, trafia do pojedynczego configu zapisywanego przez bootstrap. Per-user secrets są pytane interaktywnie (lub pociągane z 1Password / secret managera). Katalog jest curated przez AI platform team — nowy pracownik nigdy nie pyta “których MCP my tu używamy?”, bo bootstrap zainstalował właściwe.
Nagraj trzy do pięciu przykładowych sesji w Waszym kodzie.

Wybierz najczęstsze rodzaje pracy w zespole — route handler, migracja, fix UI, sesja debug, update doc. Niech seniorzy nagrają, jak shipują każdą z nich z agentem, z narracją na bieżąco. Dziesięć do piętnastu minut każde. Wrzuć na Loom, internal Wiki lub współdzielony Drive. Zlinkuj bibliotekę z onboarding doc.
Wyznacz program buddy i rotuj go kwartalnie.

Dla każdego nowego pracownika wybierz buddy z rotacji seniorów. Obowiązki buddy w pierwszym tygodniu są jawne: posiedzieć przy bootstrapie pierwszego dnia, przeprowadzić nowego przez jedną przykładową sesję, być on-call (DM na Slacku, Zoom dostępny w 15 min) przez pierwsze trzy dni, dwa check-iny dziennie przez pierwszy tydzień. Rotuj buddy kwartalnie, żeby load był współdzielony i żeby każdy senior był po obu stronach.
Skuruj backlog ticketów klasy “day-1-PR”.

Engineering managerowie rezerwują mały zestaw zwalidowanych “wykonalnych w pół dnia z agentem” ticketów dla nowych pracowników. Buddy wybiera jeden, gdy nowy jest gotowy. To nie są tickety wyrzucane — trafiają na produkcję — ale mają jawne cechy: niski blast radius, dobrze zrozumiały zakres plikowy, brak migracji, jasne kryteria akceptacji.
Wepnij bootstrap, przykładowe sesje i buddy do oficjalnego onboarding doc.

Onboarding doc HR / engineering, który czyta każdy nowy pracownik dnia 0, ma na górze trzy pozycje: (a) odpal tę komendę, (b) obejrzyj te video z buddy, (c) oto Twój PR na dzień 1. Wszystko inne — ubezpieczenie, system zwrotu wydatków, harmonogram all-hands — idzie poniżej. Sygnał, jaki wysyłasz, jest taki, że techniczna produktywność pierwszego dnia to priorytet.
Mierz i przeglądaj kwartalnie.

Trackuj trzy metryki per nowy pracownik: (a) czas od przyjazdu laptopa do zmergowanego pierwszego PR, (b) liczba pytań do buddy zapisanych w 1. tygodniu, (c) self-report z 4. tygodnia o pewności siebie w AI workflow. Kwartalnie przeglądaj dane. Gdzie się zacinają? Która przykładowa sesja jest najczęściej oglądana? Który krok bootstrapu wywala się najczęściej? Bootstrap i biblioteka sample to żywe artefakty — gniją, jeśli nikt ich nie iteruje.
Używaj nowych pracowników do znajdowania rdzy.

Nowy pracownik jest jedyną osobą w zespole, która doświadcza Waszego toolingu na świeżo. Jeśli coś nie działa pierwszego dnia, dla reszty było zepsute od tygodni — po prostu nauczyli się to omijać. Każdy onboarding generuje dwa lub trzy PR-y przeciwko bootstrapowi, bibliotece sample lub dokumentom. Świętuj te PR-y publicznie — to praca konserwacyjna o najwyższej dźwigni w organizacji.

Najczęstsze pułapki

Brak bootstrap script (wszystko w wiki). Domyślny tryb awarii. Kroki setupu organizacji rozproszone po stronie Notion, trzech wątkach Slackowych i w głowie jednego seniora. Każdy nowy pracownik rekonstruuje setup z pomocą buddy, a setup dryfuje za każdym razem trochę bardziej. Bootstrap script to jedyny artefakt zapobiegający temu dryfowi — wymusza na organizacji pojedynczą, wykonywalną, version-controlled odpowiedź na “jak to się ustawia?”

Tygodniowy setup traktowany jako norma. Zaskakująca liczba organizacji w 2026 wciąż budżetuje “pierwszy tydzień jest na setup”. To akceptowalne, jeśli inżynierowie są wcześnie w karierze, a firma jest nowa — ale dla seniorów czyta się jako brak powagi. Onboarding <1 dzień nie jest już aspirational; to table-stakes sygnał organizacji inżynierskiej, która wie, co robi.

Brak buddy, lub buddy bez czasu. Wybranie buddy, który równocześnie shipuje launch w tym tygodniu, jest gorsze niż brak buddy — nowy pracownik czuje, że przeszkadza za każdym razem, gdy pisze. Rola buddy musi być w jego load-balancing na ten tydzień. Engineering managerowie wprost wykrawają czas.

Brak deliverable na dzień 1. “Nie oczekujemy od Ciebie niczego w pierwszym tygodniu.” Mówione życzliwie, ale daje efekt odwrotny. Nowy pracownik chce coś shipnąć. PR dnia 1 jest dowodem dla niego samego, że tooling działa i że może tu być produktywny. Pominięcie tego oznacza, że pierwszy tydzień kończy się bez własnego konkretnego artefaktu — a drugi tydzień zaczyna się z lękiem.

Generyczne przykładowe sesje zamiast specyficznych dla firmy. Link do generycznego tutoriala Claude Code na YouTube nie jest przykładową sesją. Sens przykładowej sesji to przekazanie stylu Twojego zespołu na Twoim kodzie. Generyczne video uczą składni agenta — którą nowy pracownik już zna — zamiast uczyć konwencji zespołu, co jest faktyczną brakującą wiedzą.

Bootstrap, który nie jest idempotentny. Bootstrap, który łamie się przy drugim odpaleniu, to bootstrap, który zawodzi za pierwszym razem, gdy buddy próbuje coś naprawić. Idempotencja to różnica między “skrypt jest narzędziem” a “skrypt jest rytuałem”. Test: odpal go pięć razy z rzędu na tym samym laptopie.

Brak kroku weryfikacji w bootstrapie. Skrypt deklaruje sukces, ale nie potwierdza, że agent faktycznie działa. Krok weryfikacji odpalający /skills, /mcp i mały tool call — i odmawiający wydrukowania “done”, jeśli któryś zawiódł — jest różnicą między bootstrapem a aspirational shell scriptem. Dodaj weryfikację.

Sekrety MCP pytane out of band. Jeśli bootstrap instaluje katalog MCP, ale zostawia setup sekretów na “napisz do #infra”, nowy pracownik jest zablokowany na pół dnia, czekając na odpowiedź IT. Albo pytaj o sekrety inline (z jasnymi instrukcjami, który token z której konsoli), albo wepnij bootstrap w secret manager (1Password CLI, Doppler, AWS Secrets Manager), żeby bootstrap pociągnął je automatycznie, gdy tylko dostęp do vaulta zostanie nadany.

Traktowanie artefaktów onboardingu jako statycznych. Bootstrap, przykładowe sesje i notatki buddy gniją. Zmieniona nazwa skillu, deprecated MCP, zaktualizowana konwencja CLAUDE.md — i onboarding zaczyna cicho zawodzić. Zaplanuj kwartalny przegląd wprost na odświeżenie.

Jak zweryfikować, że jesteś na maksie

Dalsza lektura

Q5 · Wspólne reguły agenta Kanoniczny template CLAUDE.md, który sadzi bootstrap — managed policy + per-repo rules.

Q6 · Wspólne skills Skills repo, które bootstrap symlinkuje agentom każdego nowego pracownika pierwszego dnia.

Q20 · Dzielenie wiedzy Brown-bag sessions i ai-toolkit-internal — nawyki utrzymujące artefakty onboardingu świeżymi.

Zrób CTO Scorecard 25 pytań, ~12 minut. Ocena tier + plan 30/60/90 + risk register.