Granica nie broni się sama

Jakiś czas temu pisałem o decyzjach, których nie oddam AI — o drzwiach jednokierunkowych, wyborach zbyt drogich, żeby je potem odkręcać. Granice modułów, model danych, semantyka błędów. Decyzje, które zostawiam sobie.

Kiedy wróciłem do tamtego tekstu, zauważyłem coś, co było w nim założone, ale nigdy nie zostało powiedziane wprost: że to ja stoję przy drzwiach.

We własnym repozytorium — jasne. Tam faktycznie jestem tymi drzwiami. Widzę kształt systemu. Wiem, które szwy mają znaczenie. Wiem, które skróty są nieszkodliwe, a które po cichu zmieniają architekturę.

Tylko że nie tam spędzam większość dnia.

Prowadzę dziesięcioosobowy zespół i prawda jest taka, że nie ma mnie przy większości kodu, który powstaje. Granica, którą tak starannie wyznaczyłem w tamtym tekście, nie idzie za mną. Nie pojawia się automatycznie w decyzjach innych ludzi. Zostaje w mojej głowie.

A granica, która istnieje tylko w głowie jednej osoby, nie jest granicą.

Jest nadzieją.

Twój system był człowiekiem

AI nie sprawiło, że zespół nagle stał się mniej zdyscyplinowany. Pokazało coś mniej wygodnego: że nasza dyscyplina była skupiona w jednej osobie.

To jest ten moment, który trudno przyjąć.

To, co często nazywamy „naszą architekturą”, bywa w praktyce jednym seniorem, który po cichu pilnuje spójności. Granice trzymają się dlatego, że ta osoba widzi wystarczająco dużo pull requestów, żeby wyłapać dryf. Słownictwo pozostaje spójne, bo ktoś pamięta, jak umówiliśmy się nazywać dane rzeczy. Semantyka błędów nie rozjeżdża się, bo ktoś ma wyczucie — budowane latami — co do czego należy.

To nigdy nie był do końca system.

To był nawyk.

I przez jakiś czas to wystarczało. Tempo było na tyle wolne, że nawyk działał. Wątpliwa abstrakcja potrzebowała kilku dni, żeby w ogóle pojawić się w kodzie. Złą granicę trzeba było napisać ręcznie, przepchnąć przez dyskusję, zderzyć z oporem, poprawić. W pracy było tarcie, a to tarcie dawało zespołowi czas, żeby zauważyć, że coś jest nie tak.

AI to zmienia.

Nie dlatego, że pisze zły kod. Zwykle nie pisze. Pisze kod wiarygodny. Czysty. Wyglądający jak przetestowany. Kod, który pasuje do lokalnego zadania.

I właśnie w tym jest problem.

Granicę przekracza się lokalnie

Tak naprawdę granica nie pęka w jednym spektakularnym momencie.

Nie przez jedną oczywiście złą decyzję. Nie przez jedną osobę, która postanawia zignorować architekturę. Nie przez dramatyczny commit, który później można wskazać palcem i powiedzieć: „to tutaj ją straciliśmy”.

Granica znika przez dziesięć osób, z których każda podejmuje decyzję lokalnie rozsądną.

Jedna sięga poza granicę modułu, bo import był pod ręką, a termin gonił. Druga wprowadza drugą nazwę dla tego samego pojęcia, bo pierwsza nie była zapisana nigdzie, gdzie łatwo było ją znaleźć. Ktoś prosi AI o wygenerowanie małego helpera, a ten helper po cichu duplikuje logikę, która już miała swoje miejsce. Ktoś inny akceptuje refactor, który upraszcza jeden ekran, ale utrudnia zobaczenie kształtu całego systemu.

Nikt nie robi nic złego.

Każdy diff wygląda czysto. Każda decyzja ma sens w małej skali. Każdy pull request można zrecenzować i zaakceptować bez poczucia, że ktoś coś zaniedbał.

A architektura i tak dryfuje.

Jeden rozsądny commit po drugim znika kształt, który chciałeś chronić. Zanim się zorientujesz, nikt nie potrafi wskazać momentu, w którym to się stało.

Kiedyś ten problem rozwijał się powoli.

Już nie.

Szybkość zabrała tarcie, które cię ratowało

To, co kiedyś chroniło zespół, nie było samą dyscypliną.

Było nim tarcie.

Budowanie złej rzeczy trwało. Zła granica potrzebowała czasu, żeby wejść do kodu. Po drodze było dość wahania, dość pytań, dość dyskusji i dość momentów typu „czemu to jest takie trudne?”, żeby ktoś zwykle zauważył problem, zanim zdążył się rozlać.

Koszt złej decyzji był płacony na tyle wolno, że dało się ją zatrzymać.

AI usuwa to opóźnienie.

Dziś zła granica może wejść w jedno popołudnie — czysta, przetestowana, wyglądająca jak po review i błędna dokładnie w taki sposób, którego nie widać w diffie. Każdy w zespole porusza się szybciej, czasem dużo szybciej, więc szybciej pojawiają się też wszystkie decyzje.

Również te, które nigdy nie powinny zostać podjęte.

Dryf nie przyspieszył dlatego, że ludzie stali się gorsi.

Przyspieszył, bo puściły hamulce.

Granica musi wyjść z twojej głowy

Praca, o której pisałem w tamtym pierwszym tekście — decydowanie, gdzie przebiegają granice — okazała się tylko połową zadania.

Wyznaczanie granic to ta część, którą lubię.

Ale w zespole naprawdę liczy się coś innego: sprawienie, żeby te granice istniały gdzieś poza moją głową.

Przez jakiś czas się przed tym broniłem, bo brzmi to jak biurokracja. Pisz więcej dokumentacji. Dodawaj procesy. Twórz checklisty. Zamień architekturę w papierologię.

Tylko że to nie jest rozwiązanie.

Strona na wiki, której nikt nie otwiera, nie oznacza, że granica wyszła z twojej głowy. To nadal twoja głowa — tylko przepisana, a potem zignorowana.

Granica wychodzi z głowy dopiero wtedy, gdy pojawia się w momencie podejmowania decyzji.

W pull requeście. Przy konkretnym kodzie. Wtedy, gdy zmiana jest jeszcze tania.

Reguła o granicach modułów, która żyje w dokumencie, łatwo wypada z pamięci. Ta sama reguła pokazana przy konkretnym imporcie, który tę granicę przekracza, staje się realna. Konwencja nazewnicza zakopana w onboardingu jest preferencją. Ta sama konwencja, która odzywa się wtedy, gdy ktoś wprowadza drugą nazwę na to samo pojęcie, staje się barierką.

To rozróżnienie ma znaczenie.

Nie chodzi o to, żeby dokumentować wszystko. Chodzi o to, żeby decyzje nośne przenieść tam, gdzie naprawdę zapadają.

Nie po fakcie. Nie na kwartalnym przeglądzie architektury. Nie wtedy, gdy szkoda już rozlała się po kodzie.

W szwie.

Za każdym razem.

Na tyle automatycznie, żeby nikt nie musiał pamiętać, że dana reguła istnieje.

Bo standard, który działa tylko wtedy, gdy osobiście patrzysz, nie jest standardem zespołu. To twoja dostępność przebrana za architekturę.

AI jest lustrem

To zajęło mi najwięcej czasu.

Wąskim gardłem nigdy tak naprawdę nie była jakość AI.

AI potrafi pisać dobry kod. Potrafi trzymać się wzorców. Potrafi wygenerować testy. Potrafi szybko przejść przez szczegóły implementacyjne, które wcześniej zabierały godziny. Ta część nie jest już najtrudniejszym problemem.

Prawdziwe pytanie brzmi: czy standardy twojego zespołu istnieją poza głową jednej osoby?

W wielu zespołach — w moim też — często nie istnieją.

AI jest lustrem przystawionym do tego układu. Działa na tyle szybko, że pokazuje, że twój „system” był człowiekiem. W momencie, gdy ta osoba nie może być przy każdym review — bo jest więcej zmian, więcej branchy, więcej wygenerowanego kodu i więcej małych decyzji podejmowanych równolegle — spójność zaczyna znikać.

Nie dlatego, że zespołowi przestało zależeć.

Dlatego, że struktura nigdy naprawdę nie została wyniesiona na zewnątrz.

Architekturę trzymały pamięć, gust i uwaga.

To mocne rzeczy. Ale też kruche.

Nie skalują się razem z prędkością.

Kiedy granicę warto wyznaczyć?

Nie da się spisać wszystkiego.

I nie warto próbować.

Większość kodu naprawdę powinna zostać pozostawiona osądowi — ludzkiemu, wspieranemu przez AI, zespołowemu. Nie każda decyzja potrzebuje reguły. Nie każda niespójność ma znaczenie. Nie każdy wzorzec zasługuje na to, żeby stać się polityką.

Prawdziwa umiejętność nie polega więc na dokumentowaniu większej liczby rzeczy.

Polega na rozpoznaniu, które granice są nośne.

Pomagają mi w tym trzy pytania.

Pierwsze: jeśli dwie osoby odpowiedzą na to inaczej, czy kod popsuje się później?

Jeśli różnica jest nieszkodliwa, zostaw ją gustowi. Jeśli zacznie się kumulować — dwie nazwy na jedno pojęcie, dwie drogi przez tę samą granicę, dwa miejsca z tą samą regułą — to jest rzecz nośna.

Drugie: czy wyłapałbym to na review, gdybym akurat zobaczył ten pull request?

Jeśli tak, to znaczy, że reguła żyje obecnie w mojej głowie i nigdzie indziej. Czyli znika w chwili, gdy nie patrzę. To są pierwsze reguły, które warto przenieść do systemu.

Trzecie: czy teraz jest tanie, a później będzie drogie?

Granice warte obrony to te, które na początku kosztują prawie nic, a po rozlaniu się po kodzie zabierają weekend. Import, którego nie powinno być. Pojęcie nazwane inaczej niż reszta systemu. Stan umieszczony w złej warstwie. Skrót, który wydaje się niewinny, dopóki nie zacznie od niego zależeć pięć kolejnych funkcji.

Wszystko, co nie przechodzi przez żadne z tych trzech pytań, staram się odpuścić.

Zespół — i AI — powinny móc poruszać się pełną prędkością w całej reszcie.

Granica nie broni się sama

Pierwszy tekst był o drzwiach, które zostawiam sobie.

Ten jest o tym, co wtedy pominąłem: drzwi, których pilnuję jako jedyny, tak naprawdę nie są pilnowane.

Są po prostu zamknięte do momentu, aż ktoś się o nie oprze.

Praca nie przesunęła się tylko z pisania kodu na wyznaczanie granic. Poszła krok dalej.

Z wyznaczania granicy na sprawienie, żeby trzymała się także wtedy, gdy już przy niej nie stoję.