Twój kod to nie tylko kod — to encyklopedia firmy

Pomyśl przez chwilę o swoim zespole. Nowa osoba dołącza do projektu. Dostaje dostęp do Notion, Confluence, może jakiegoś Google Drive'a pełnego dokumentacji. "To wszystko, co musisz wiedzieć," słyszy.

Kłamstwo.

Dokumentacja mówi tylko to, co ktoś uznał za warte zapisania — dawno temu, w zupełnie innych okolicznościach. Nie zawiera historii. Nie pokazuje, dlaczego zrezygnowano z alternatywnych rozwiązań. Nie tłumaczy, dlaczego wczorajsza decyzja architektoniczna wciąż obowiązuje.

Są rzeczy, których dokumentacja nigdy nie przechwyci. Ale czy to oznacza, że ta wiedza przepadła? Nowe badania sugerują, że wcale nie — po prostu szukaliśmy jej w złym miejscu.

Co Naur wiedział już w 1985

Peter Naur — ten sam od notacji Backusa-Naura — w swoim tekście "Programming as Theory Building" przedstawił prostą tezę. Program to nie tylko instrukcje dla maszyny. To wyraz "teorii" twórców o tym, jak rozwiązać dany problem. Dokumentacja może tę teorię opisać, ale nigdy w pełni nie uchwyci.

Kiedy programista z tą teorią w głowie odchodzi z firmy, teoria odchodzi razem z nim.

Brzmi pesymistycznie. I były to czasy, gdy jedynymi "czytelnikami" kodu był kompilator (który rozumie zero) oraz ludzie (którzy rozumieją wolno i drogo).

Ale świat się zmienił.

Trzeci czytelnik wszedł do gry

Duże modele językowe to coś, czego Naur nie mógł przewidzieć. To trzecia kategoria czytelników — taka, która rozumie kod na poziomie znaczenia, nie tylko wykonania.

Weźmy przykład z praktyki. System zarządzania konfiguracją przedsiębiorstwa ma logikę rozpoznawania tożsamości urządzeń. Jak to działa? Zamiast eseju konsultanta "nasza filozofia identyfikacji", mamy plik konfiguracyjny z wagami: numer seryjny (25), nazwa hosta (25), tag aktywów (25), adres IP (20), adres MAC (15). Do tego progi pewności i reguły rozstrzygania konfliktów.

Każda z tych liczb reprezentuje dyskusję, którą ktoś wygrał. Każdy typ konfliktu oznacza realne zdarzenie, które wydarzyło się w świecie rzeczywistym.

To nie opis polityki. To polityka — uruchamiana codziennie w środowisku produkcyjnym.

Co z tego wynika dla Twojego zespołu

Twój kod jest dokumentacją, którą ciągle walidujesz. W przeciwieństwie do wiki sprzed trzech lat, kod produkcyjny jest testowany nieustannie. Jeśli dokumentacja mówi co innego niż kod — dokumentacja kłamie.

Sztuczna inteligencja coraz lepiej wydobywa tę wiedzę. Zadaj AI pytanie "jak obsługujemy konflikty tożsamości urządzeń" — dostaniesz nie tylko dokument, ale prawdziwe rozumowanie wbudowane w wagi i progi.

Prawdziwa wiedza siedzi w edge cases. Główne ścieżki są zazwyczaj opisane. To wyjątki, specjalne obsługi, rozwiązania z lat pracy przy produkcji — tam kryje się głęboka wiedza instytucjonalna.

Sygnał ostrzegawczy

Jest też mroczna strona tej refleksji: jeśli logika biznesowa żyje tylko w kodzie, a Twój kod ma słabe pokrycie testami, niezrozumiałe nazewnictwo i chaos strukturalny — siedzisz na skarbcu wiedzy, którego nie potrafisz otworzyć.

Naur miał rację, że coś przepadnie. Ale badania pokazują też, że w kodzie przetrwało więcej, niż sądziliśmy. Potrzebowaliśmy tylko nowego rodzaju czytelnika.

Co robić dalej

Jeśli budujesz produkt lub zarządzasz zespołem technicznym:

1. Ufaj kodowi bardziej niż dokumentacji, gdy się różnią
2. Pisz kod, który dokumentuje swoje uzasadnienie — jasne nazwy, przemyślane funkcje, komentarze wyjaśniające DLACZEGO
3. Traktuj konfigurację jako wiedzę instytucjonalną — te wagi i progi to decyzje warte zachowania
4. Eksperymentuj z AI zdolnym do przeszukiwania i interpretacji codebase'u

Kod, który piszesz dzisiaj, będzie wiedzą instytucjonalną jutro. Warto, żeby był tego wart.