Piaskownica Mega-kontekst: jak przestaliśmy tłumaczyć narzędziom, o co chodzi w projekcie

Uwaga o danych: wszystkie liczby w tym materiale pochodzą z odczytu systemu z 25 sierpnia 2026 i są weryfikowalne w repozytoriach oraz w telemetrii. Tam, gdzie dane są młode albo obarczone zastrzeżeniem, mówimy to wprost — zamiast zaokrąglać w swoją stronę. Zrzuty ekranu są niezmienione.

Problem: kontekst, który nie przeżywa urlopu

Agencja marketingowa jest maszyną do produkowania kontekstu. Co miesiąc powstają raporty, audyty, rekomendacje, ustalenia z rozmów, decyzje o budżetach. Problem w tym, że ten kontekst prawie nigdy nie ma miejsca, w którym mieszka.

Mieszka więc wszędzie po trochu: w głowie PM-a, w wątku na czacie sprzed trzech tygodni, w arkuszu na czyimś dysku, w mailu do klienta. Dopóki wszyscy siedzą przy jednym projekcie od roku, jakoś to działa. Przestaje działać w momencie, gdy ktoś idzie na urlop, projekt przejmuje nowa osoba albo — coraz częściej — do pracy siada narzędzie AI.

Bo narzędzie AI ma dokładnie ten sam problem co nowy człowiek w projekcie: nie wie nic. Każda sesja zaczynała się od tego samego rytuału — wklej dane, wytłumacz, o co chodzi, przypomnij, co ustaliliśmy w zeszłym miesiącu, wyjaśnij, że ten klient mówi po angielsku, a tamten po polsku. Zanim padło pierwsze sensowne pytanie, mijało kilkanaście minut, a jakość odpowiedzi zależała od tego, ile komuś chciało się wkleić.

To był ten sam koszt, który agencja płaci przy każdym onboardingu człowieka — tylko ponoszony codziennie, przy każdej sesji, przez każdą osobę.

Wbijanie się w te projekty czasami nie jest najprzyjemniejszą rzeczą, bo ktoś jest na urlopie, kogoś nie ma, ktoś nie ma czasu. A posiadając repozytoria jesteśmy w stanie kumulować tę pracę ludzi i wiedzę w jednym miejscu. W pięć minut, zamiast łapać się z PM-em i przekazywać wszystko z ust do ust.

Decyzja: jednostką kontekstu jest repozytorium, nie folder

Kontekst klienta dostaje własne repozytorium git, a nie folder na dysku.

To wygląda na wybór techniczny, a jest organizacyjny. Repozytorium daje cztery rzeczy, których folder nie da nigdy: historię (widać, kto co zmienił i dlaczego), uprawnienia (wiadomo, kto ma dostęp), jedno źródło prawdy zamiast czternastu kopii, oraz — co okazało się najważniejsze — strukturę, którą da się wymusić z zewnątrz.

Bo jeśli wszystkie 113 piaskownic mają identyczny układ, to reguła napisana raz obowiązuje wszędzie. Nowy skill trafia do wszystkich w jednym przebiegu. Poprawka bezpieczeństwa też. A człowiek, który przechodzi z projektu na projekt, nie uczy się nowego układu — trafia w to samo miejsce.

Świadomie odrzuciliśmy podejście „jedna wielka baza wiedzy dla wszystkich klientów”. Powodem jestrozdzielność danych klientów. Piaskownica jednego klienta nie widzi danych drugiego: każda jest osobnym repozytorium, a dostępy nadaje się per zespół, a nie na całą grupę. Przy wspólnej bazie ta granica jest kwestią dyscypliny; tutaj jest kwestią architektury.

Dane pobieramy przez bramkę i nie kopiujemy ich do repozytorium. Piaskownica wie, gdzie są dane i jak po nie sięgnąć, ale ich u siebie nie trzyma. Dzięki temu klucze do systemów klienta nigdy nie lądują w repozytorium, a dane są zawsze aktualne, a nie z ostatniego eksportu.

Jak to działa: anatomia jednej sesji

Prześledźmy, co się dzieje między otwarciem projektu a pierwszą odpowiedzią.

1. Człowiek otwiera repozytorium klienta i zaczyna sesję. Nic nie wkleja, niczego nie tłumaczy.
2. Kontekst wczytuje się sam — około 28 800 znaków. Hook startowy składa go z kilkunastu sekcji i podaje modelowi, zanim padnie pierwsze pytanie. Znajdują się tam między innymi: tożsamość projektu (klient, agencja, poziom dojrzałości), status uwierzytelnienia do bramki danych, świeżość danych z ostrzeżeniem, jeśli coś się zestarzało, lista skilli dostępnych w tym konkretnym repozytorium, mapa podłączonych źródeł danych, stan repozytorium oraz obowiązujące polityki.
3. Model wie, czym NIE dysponuje. W praktyce jest to ważniejsze niż poprzedni punkt. Sekcja o źródłach mówi wprost, co jest podłączone na żywo — żeby narzędzie nie odpowiadało „nie mam dostępu do Google Ads”, kiedy dostęp ma. Odwrotny błąd też jest zamknięty: brak danych za dany okres to komunikat „brak danych”, nie zaproszenie do zgadywania.
4. Praca idzie po szynach, nie ad hoc. W kontekście siedzi pięciofazowy szablon: wczytanie kontekstu, dopasowanie intencji, wykonanie po ustalonej ścieżce, bramka jakości, dostarczenie i utrwalenie. To nie jest ozdoba — ostatnia faza oznacza, że wynik ląduje w szufladce usługi w repozytorium, a nie na czyimś dysku.
5. Dane pobierane są przez bramkę na żądanie. Dwie bramki obsługują 27 źródeł: 17 do odczytu (m.in. Google Ads, Search Console, GA4, Meta Ads, Merchant Center, Bing Webmaster Tools, PageSpeed, transkrypty rozmów, CRM projektowy) i 10 do zapisu (m.in. Arkusze, Dysk, Forms, ClickUp, Firecrawl). Klucze zostają po stronie serwera.
6. Wynik zostaje w piaskownicy. Następna osoba — albo następna sesja — zaczyna od tego, co już wiadomo, a nie od zera. Kontekst rośnie, zamiast parować.

Ile kosztowało uruchomienie projektu przedtem

Zanim powstała piaskownica, postawienie środowiska AI pod jeden projekt było osobnym przedsięwzięciem. Trzeba było zdobyć i skonfigurować poświadczenia do każdego źródła osobno, podpiąć i przetestować konektory, napisać instrukcję opisującą klienta i reguły, ustawić cykliczne odpytywanie transkryptów i danych, rozdać uprawnienia, a na koniec sprawdzić, czy całość faktycznie działa.

Zera w prawej kolumnie nie znaczą, że tej pracy nie ma. Znaczą, że wykonuje się ją raz, centralnie — poświadczenia żyją w bramce, instrukcja powstaje z szablonu, odświeżanie danych po starcie biegnie w tle i nie zajmuje niczyjego czasu.

Uczciwie o tej liczbie: to szacunek wyliczony z rozpisanych kroków, nie pomiar stoperem. Baseline'u nie zbieraliśmy, zanim zaczęliśmy budować, więc podajemy przedział, a nie jedną wartość.

Bariery, których nie ustawia się per projekt

Druga oszczędność jest trudniejsza do wyrażenia w minutach. W każdej piaskownicy działa dziesięć automatów, których nikt nie konfiguruje przy zakładaniu projektu: linter treści klienckich, ochrona instrukcji projektu przed nadpisaniem, ostrzeżenie o commicie z niewłaściwej tożsamości, strażnik pilnujący, że artefakt trafia na swoje miejsce, skan sekretów przed każdym wypchnięciem i bramka jakości przed publikacją. Do tego dwie bramki danych: ta od odczytu blokuje zapis globalnie, ta od zapisu ma zamkniętą listę dozwolonych operacji.

Praktyczny skutek jest taki, że osoba, która dopiero uczy się pracy z AI, może pracować od pierwszego dnia — nie mogąc przy tym wypchnąć czegoś, czego nie powinna. Bez tej warstwy jedynym zabezpieczeniem byłoby ograniczanie dostępu, czyli spowalnianie ludzi dokładnie wtedy, gdy najbardziej potrzebują ćwiczyć.

Dwa zobowiązania leżą poza repozytorium i warto powiedzieć o nich wprost. Dostawca modelu działa na podstawie umowy powierzenia przetwarzania danych, a umowy z klientami zostały pod to zaktualizowane. Tam, gdzie AI współtworzy materiał dla klienta, klient jest o tym informowany, a materiał oznaczony.

Propagacja: jedno źródło prawdy dla 113 miejsc

Piaskownica nie byłaby nic warta, gdyby każda z nich żyła własnym życiem. Dlatego wszystko, co definiuje zachowanie — reguły, skille, hooki, szablony, zabezpieczenia — mieszka w jednym repozytorium-matce i jest rozsyłane w dół.

W praktyce oznacza to, że poprawka napisana raz trafia do 113 miejsc w jednym przebiegu, a nie w 113 rozmowach. Kosztem jest dyscyplina: skill edytuje się w kanonie, nigdy w kopii, bo kopia zostanie nadpisana przy następnej propagacji.

Ta sama warstwa pilnuje rzeczy, o których nikt nie chce pamiętać: czy repozytorium ma komplet plików onboardingowych, czy nie zostały w nim zacommitowane sekrety, czy struktura nie odjechała od standardu. Kontrole chodzą automatycznie i raportują odchylenia.

Od konsumenta do współautora

Na starcie skille pisała jedna osoba, a zespół ich używał. Dziś w kanonie jest 207 skilli, z czego 47 autorskich, sygnowanych nazwiskami 18 osób. Wśród autorów są specjaliści od Google Ads, SEO, analityki, kreacji i sprzedaży — czyli ludzie, którzy nie są programistami i nie mieli być.

Wszystkie skille — te z piaskownic, te z pojedynczych repozytoriów i te z platformy The Forge — są widoczne w jednym katalogu z filtrami po obszarze, autorze i źródle. Każdy skill ma etykietę pochodzenia, więc widać, czy jest częścią mega-kontekstu, czy narzędziem lokalnym.

Katalog liczy dziś 250 skilli w 13 obszarach, od 19 autorów, obejmując 127 repozytoriów.

Nagle okazuje się, że możesz wyjąć kawałek mózgu i dać go komuś innemu w formie tego skilla. A wcześniej to nie było możliwe.

Efekty: liczby i zastrzeżenia

Skala po czterech miesiącach od pierwszego commitu (8 kwietnia 2026):

• 113 piaskownic — 95 projektowych, 17 rolowych, 1 szablonowa, w 8 agencjach grupy
• wzrost z 78 repozytoriów w czerwcu do 113 w sierpniu
• 207 skilli w kanonie wobec ~95 w czerwcu; 47 autorskich od 18 osób
• 27 źródeł danych przez dwie bramki (17 odczyt, 10 zapis)
• 96 domen z codzienną migawką danych
• 42 osoby pracujące w piaskownicach od kwietnia (2829 commitów, bez automatów)
• ~28 800 znaków kontekstu ładowanych automatycznie na starcie sesji

Jedna piaskownica zawiera dziś: instrukcję projektu na 1112 linii, 194 skille, 10 hooków, 31 komend i 13 szufladek usługowych.

Czego te liczby nie mówią

Trzy zastrzeżenia zmieniają sposób czytania tych liczb.

Telemetria użycia jest za młoda na wnioski. Zbieramy ją od 5 sierpnia 2026. W ostatnich 30 dniach odnotowaliśmy 270 wywołań 25 różnych skilli — ale 242 z nich to jeden automat cykliczny. Realne użycie przez ludzi to około 28 wywołań. To za mało, żeby mówić o adopcji, i za wcześnie, żeby pokazywać trend.

Liczba commitów myli, a tożsamości git jeszcze bardziej. Skan całej historii pokazał 43 700 commitów i 63 „autorów” — ale zdecydowana większość commitów pochodzi z automatów działających pod jedną tożsamością, a wielu „autorów” to ta sama osoba commitująca z trzech różnych konfiguracji gita. Po odjęciu automatów i scaleniu tożsamości zostają 42 osoby i 2829 commitów. Podajemy tę drugą liczbę, bo pierwsza brzmi lepiej i znaczy mniej.

Pomiar „przed i po” jest szacunkiem, nie stoperem. Tabela czasu uruchomienia projektu wyżej powstała z rozpisanych kroków i doświadczenia zespołu, a nie z pomiaru przed wdrożeniem — baseline'u nie zbieraliśmy, zanim zaczęliśmy budować. Podajemy więc przedział 3,5–7 h, nie jedną liczbę. Czego wciąż nie mamy, to pomiaru oszczędności w codziennej pracy, już po uruchomieniu projektu. Telemetria powstała właśnie po to i za kilka miesięcy powinna dać twardsze liczby.

Czego nauczyło nas to wdrożenie

Pół dnia spędzam, przełączając się między tymi sesjami. Siedemdziesiąt procent dnia spędzam w tym panelu. I wiesz, jaka będzie przyszłość wszystkich praktycznych specjalistów? Podejrzewam, że dokładnie taka.

Kontekst potrzebuje adresu. Można napisać najlepszą instrukcję projektu na świecie — jeśli leży w czyimś folderze, nie istnieje. Repozytorium daje kontekstowi adres, historię i uprawnienia.

Jednolitość sprawia, że jedna poprawka działa w 113 miejscach. Identyczna struktura we wszystkich piaskownicach to jedyny powód, dla którego poprawka napisana raz działa wszędzie. Każdy wyjątek od struktury to przyszła awaria, o której nikt nie będzie pamiętał.

Dane pobieraj, nie kopiuj. Kopia danych w repozytorium starzeje się od pierwszej minuty i zamienia repozytorium w miejsce, gdzie mogą wyciec klucze. Bramka rozwiązuje oba problemy naraz.

Mów narzędziu, czego NIE ma. Największym źródłem złych odpowiedzi nie jest brak danych, tylko brak wiedzy o tym, że danych brakuje. Jawna lista podłączonych źródeł i twardy komunikat „brak danych” są warte więcej niż kolejny skill.

Rozdzielność klientów wymuś architekturą, nie regulaminem. Osobne repozytorium z osobnymi uprawnieniami trzyma granicę samo. Wspólna baza wymaga dyscypliny — a dyscyplina zawodzi w piątek o siedemnastej.

Uruchom telemetrię, zanim ktokolwiek zapyta o wyniki. Największy brak tego wdrożenia to nie technologia, tylko nieuruchomiona na starcie telemetria. Bez baseline'u zostają liczby o skali, a nie o wartości.

Przeczytaj bliźniacze case study: The Forge