Pokayoke: Jak zabezpieczyć repozytorium przed błędami w erze AI

W latach 60. japoński inżynier Shigeo Shingo wymyślił termin pokayoke. W wolnym tłumaczeniu chodzi o coś w stylu " idiotoodporność" - projektowanie systemów tak, żeby pomyłki były niemożliwe albo od razu rzucały się w oczy.

Brzmi znajomo? Powinniście to znać.

Zasada działania jest prosta

Zamiast liczyć na to, że ludzie będą perfekcyjnie przestrzegać zasad, budujesz mechanizmy, które automatycznie wyłapują odstępstwa. W fabryce to czujnik zatrzymujący linię, gdy coś nie pasuje. W kodzie? Narzędzie, które mówi "stop" zanim błąd dotrze do produkcji.

Pokayoke.codes przenosi tę filozofię do repozytoriów kodu, ale z jednym twistem - to narzędzie zaprojektowane z myślą o AI.

Czego nie załatwi tradycyjny linter

Większość zespołów ma już lintery. ESLint pilnuje zmiennych. Prettier dba o formatowanie. TypeScript łapie błędy typów. Te narzędzia robią swoje, ale nie przechwytują wiedzy milczącej - zasad, które wszyscy znają, ale nikt nigdzie nie spisał.

Może wasze API ma określony schemat nazewnictwa. Albo macie wewnętrzne zasady dotyczące tego, które pakiety można używać. Albo nieformalne ustalenia o organizacji plików, które gdzieś tam sobie są, ale nikt ich nigdzie nie egzekwuje.

Tu wkracza pokayoke. Pozwala zamienić te repozytoryjne invariaty w coś konkretnego - zasady, które można egzekwować automatycznie.

AI na pierwszym miejscu

To jest to, co wyróżnia to narzędzie. Zostało zaprojektowane z myślą o agentach AI.

Współczesne asystenty kodowania potrafią nawigować po projekcie, pisać nowe funkcje, refaktoryzować kod. Ale utrzymać je w zgodzie z konwencjami zespołu? To nadal ręczna robota. Dodajesz zasady do system promptu, ale agent zapomina, halucynuje albo po prostu nie wie, co dla ciebie ważne.

Pokayoke rozwiązuje to traktując reguły polityki jako pełnoprawnych obywateli, których agenci mogą czytać, rozumieć i których się trzymać. Polecenie pokayoke agent SKILL.md uruchamia agentów w trybie autonomicznym, a same zasady są zaprojektowane tak, żeby mogły być pisane i utrzymywane przez AI.

Jeśli budujesz workflow typu Vibe Coding, gdzie AI robi ciężką pracę, pokayoke daje ci sposób na komunikowanie standardów w formacie, który naprawdę zostaje w pamięci.

Nie musisz wyrzucać tego, co już masz

Obawa przed nowymi narzędziami jest zrozumiała. Masz ESLint, Prettier, Husky i dziesięć innych rzeczy utrzymujących porządek. Dodanie pokayoke nie oznacza zastępowania czegokolwiek - oznacza rozszerzenie tego, co już masz.

Dokumentacja podkreśla, że pokayoke jest niearbitralne. Nie interesuje go formatowanie (to Prettier), nie zajmuje się ogólną jakością kodu (to robi ESLint). Zamiast tego skupia się na invariatach specyficznych dla projektu - tych, które zna tylko twój zespół.

Zasady TypeScript są lokalne dla repo i weryfikują to, co ma znaczenie dla twojej konkretnej konfiguracji. Traktuj to jako dodatkową warstwę walidacji na szczycie standardowych narzędzi.

Od czego zacząć

Instalacja jest prosta:

npx skills add rorz/pokayoke

Potem definiujesz zasady, które odpowiadają konwencjom twojego zespołu. Reguły są zaprojektowane tak, żeby same siebie dokumentowały - zarówno ludzie, jak i agenci mogą je przeczytać i zrozumieć, jakie polityki obowiązują i dlaczego.

Szerszy kontekst

Pokayoke reprezentuje ciekawą zmianę w myśleniu o narzędziach do jakości kodu. Tradycyjne lintery egzekwują składnię i styl. Analizatory statyczne łapią bugi. Ale gdy asystenci AI stają się głównymi współpracownikami, potrzebujemy nowych kategorii narzędzi, które komunikują intencję w sposób zrozumiały dla agentów.

Chodzi o coś więcej niż łapanie błędów. Chodzi o to, żeby twoje standardy były maszynowo czytelne, przyjazne dla agentów i trudne do złamania - niezależnie od tego, czy kod pochodzi od człowieka, czy od AI.

W tym sensie pokayoke może być jednym z pierwszych narzędzi zbudowanych pod to, jak będziemy wszyscy pisać kod za kilka lat. Warto mieć oko na ten projekt.