Napisałem instrukcję do własnego systemu. Dwanaście zdań w niej było nieprawdą

5 sierpnia 2026 usiadłem do przeczytania własnej instrukcji obsługi. Nie do poprawiania stylu — do sprawdzenia, czy ona jeszcze mówi prawdę. Brałem zdanie po zdaniu, szukałem w kodzie miejsca, które ma to zdanie czynić prawdziwym, i patrzyłem, czy tam jest.

Wyszło dwanaście zdań nieprawdziwych i dziewięć mechanizmów, o których instrukcja w ogóle nie wiedziała.

Jak stary jest tekst, którego nikt nie oznaczył jako starego

Zacząłem od najtańszego możliwego sprawdzenia: kiedy ostatni raz zmieniałem plik z tekstem instrukcji, i ile zmian weszło do systemu od tamtej pory. Odpowiedź: 51 commitów, w tym pięć przebudów zaplecza i dwa przejścia kontrolne przez cały system.

To jest jedna komenda i daje liczbę, która wystarcza do decyzji. Jeżeli licznik pokazuje kilkadziesiąt, instrukcja już kłamie — pytanie tylko gdzie.

Najważniejsza nieprawda nie była literówką

Wstęp instrukcji obiecywał: panel nigdy nie kontaktuje się z nikim za Ciebie.

To było nieprawdą, i to w najgorszym możliwym miejscu. Moduł windykacyjny wysyłał do klientów maile sam, z porannego przebiegu: po trzech dniach uprzejme przypomnienie, po dziesięciu stanowcze, a po dwudziestu jeden formalne wezwanie do zapłaty z odsetkami. Komentarz w kodzie nazywał to wprost najpoważniejszym krokiem, jaki system wykonuje bez pytania. Sam go tak podpisałem — kilka tygodni wcześniej, w innym pliku, i zdążyłem o tym zapomnieć.

Zdanie z instrukcji i komentarz z kodu opisywały dwa różne systemy. Prawdziwy był ten drugi.

Cztery nieprawdy z jednej przyczyny

Rozdział o ekranie startowym mówił o przycisku „+", o menu „…" i o sekcji o nazwie, której w panelu nie ma. Wszystkie trzy istnieją naprawdę — tyle że w aplikacji na telefonie. Rozdział napisałem, patrząc na telefon, a czyta się go głównie na komputerze.

Cztery z dwunastu nieprawd to ta jedna pomyłka, powtórzona cztery razy. Pozostałe moduły opisałem lepiej: mają osobne zdanie „Telefon i iPad: …". Ten jeden — nie.

Reszta to drobiazgi tej samej rodziny: pięć dróg wejścia leada zamiast sześciu, cztery rodzaje wiadomości zamiast pięciu, przycisk „Utwórz korektę", który od dawna nazywa się „Wystaw korektę", i pozycja w menu wskazana o jedno miejsce obok. Żadna z nich nie zepsuje niczego w bazie. Każda uczy, że w tym tekście nie warto sprawdzać, bo i tak się nie zgadza.

Czego nie zrobiłem

Nie zmieniłem ani jednej linijki zachowania systemu. Cały ten przegląd dotyczył wyłącznie tekstów. To było kuszące dokładnie w jednym miejscu: skoro zdanie „nigdy nie kontaktuje się z nikim za Ciebie" jest nieprawdziwe, można przecież wyłączyć automat i zdanie stanie się prawdą. Nie zrobiłem tego, bo to nie jest usterka, tylko pytanie handlowe: czy chcę, żeby formalne wezwanie do zapłaty szło samo, także do klienta, z którym rozmawiałem wczoraj przez telefon. Zapisałem w instrukcji, jak jest naprawdę, i zadałem pytanie osobno.

Odpowiedź przyszła dwa dni później i była pośrednia: przypomnienia po trzech i dziesięciu dniach zostają automatem, formalne wezwanie czeka na kliknięcie. Gdybym „naprawił" to od ręki tego samego wieczoru, wyszedłby wariant, którego nikt nie wybrał.

Nie napisałem instrukcji od nowa. Przepisanie całości wyglądałoby na porządek, a byłoby drugą wersją tego samego problemu: tekst pisany raz, w oderwaniu od kodu, tylko świeższy o dwa miesiące.

Trzy rzeczy, które z tego biorę

Dokumentacja starzeje się bez żadnego objawu. Kod, który przestaje działać, wywala test albo build. Zdanie, które przestaje być prawdziwe, nie robi nic: kompiluje się, renderuje, wygląda dokładnie tak samo jak w dniu, w którym było prawdą.

Rozdział pisany z jednego urządzenia kłamie na drugim. Nie dlatego, że autor się pomylił — dlatego, że opisał to, co miał przed oczami, a czytelnik ma przed oczami co innego.

Nieprawda w instrukcji bywa pytaniem do produktu, nie literówką w tekście. Najcenniejsze, co dał mi ten przegląd, to nie dwanaście poprawek. To jedno pytanie, którego bym sobie nie zadał, gdybym nie próbował opisać własnego systemu zdaniem prostym.

Wszystkie liczby — dwanaście zdań, dziewięć mechanizmów, 51 commitów — pochodzą z jednej sesji z 5 sierpnia 2026 i dotyczą systemu, który zbudowałem dla siebie. Liczbę commitów podaje historia repozytorium, resztę policzyłem ręcznie, przykładając zdanie do kodu.