Skasowałem to wszystko jednym ruchem, koło północy z poniedziałku na wtorek
ostatniego tygodnia marca. Generator, szablony, skrypty, dokumentacja
„architektury kompilacji”. Razem coś po dziewięciu, może trzynastu godzinach
pracy z lutego. Jedna linijka git rm, jeden commit z opisem „remove stale
files — replaced by markdown agents”, i koniec.
Nie żałowałem. Żałowałem tego, że nie zrobiłem tego sześć tygodni wcześniej.
Ironia, o której wiedziałem od początku
Na tym blogu — i na temat juz-ide w środowisku — nie raz pisałem o tym, jak cofałem przekombinowane rozwiązania w produkcie. Klastrowanie bazy zaimplementowane i skasowane następnego dnia, zanim miałem dziesiątego użytkownika. Cały moduł obsługi błędów, w którym AI nadprodukowała pięć tysięcy linii, wyrzucony w tym samym miesiącu. Ćwiczę „nie buduj na zapas” jak mantrę, gdy pracuję nad rzeczą, którą ktoś kiedyś zobaczy.
A potem przekombinowałem własne zaplecze. To, czego nikt poza mną nigdy nie zobaczy. I to ładnie, na osiem tygodni.
Cała ironia jest w tym, że gdy zaczynasz pisać o tym, że trzeba uważać, łatwo poczuć się odporny. „Ja to wiem. Mnie się to nie zdarza.” A potem łapiesz się akurat w tej części pracy, w której myślisz, że jesteś poza zasięgiem.
Uzasadnienie, które brzmiało dorośle
Każde przekombinowane rozwiązanie ma uzasadnienie, które brzmi rozsądnie. Moje brzmiało tak.
Pracuję nad kilkoma projektami równolegle. Każdy potrzebuje podobnej, ale nieidentycznej konfiguracji dla AI: te same role agentów lekko inaczej zdefiniowane, te same zasady kodowania lekko dopasowane do języka projektu, te same hooki dla różnych stosów technologicznych. Zamiast pisać to każdorazowo od zera, zbuduję generator. Wpiszę raz wzorce w szablony, zapuszczę skrypt, i nowy projekt dostanie swoje pliki w pół godziny zamiast w pół dnia.
Policzyłem nawet próg opłacalności. Dziewięć–trzynaście godzin na zbudowanie, potem pół godziny na każdy nowy projekt. Po dwóch projektach wychodzę na zero, trzeci to już zysk. Tabelka była ładna.
Czego tabelka nie pokazywała, to drugiej strony równania. Generator trzeba utrzymywać. Kiedy zmieniam sam wzorzec, muszę zmieniać go w maszynie, nie w pliku. Żeby zrozumieć, dlaczego wygenerowany plik wygląda tak a nie inaczej, trzeba przeczytać szablon, logikę szablonu i dane wejściowe — zamiast po prostu otworzyć plik i go przeczytać.
Zbudowałem warstwę abstrakcji nad czymś, co wcale nie było skomplikowane. I zacząłem płacić koszt utrzymania tej warstwy z każdym dniem, który mijał od jej powstania.
Pytanie, którego unikałem przez osiem tygodni
Po ośmiu tygodniach zrobiłem rzecz, która powinna być pierwsza: usiadłem i zapytałem siebie wprost — co się zepsuje, jeśli to wszystko skasuję?
Odpowiedź zajęła mi piętnaście minut sprawdzania. Nic. Pliki, które maszyna generowała, mogę po prostu trzymać wprost: jeden zwykły plik tekstowy na projekt, edytowany ręcznie, czytany ręcznie, kopiowany, gdy trzeba. Przy kilkunastu projektach to mniej pracy na przestrzeni roku niż utrzymywanie generatora.
Drugie pytanie, które się wtedy nasunęło, było gorsze: to dlaczego ja to w ogóle zbudowałem? I tu odpowiedź była mniej miła. Bo była rozrywką. Bo budowanie generatorów jest po prostu przyjemniejsze niż edytowanie plików konfiguracyjnych. To była praca, która wyglądała jak praca, ale nie służyła nikomu.
Skasowałem o północy, bo był to dokładnie ten moment, w którym się nareszcie rozzłościłem na siebie za to, że tego nie skasowałem już dawno.
Ten sam schemat gdzieś jeszcze — hooki
Skoro już otwarłem oczy na ten kształt, znalazłem go w sąsiednim katalogu.
Mam zestaw automatycznych „haczyków” — krótkich skryptów, które odpalają się, gdy coś dzieje się w trakcie pracy z AI: edytuję plik, sięgam po nowe narzędzie, zaczynam nową sesję. Hooki służą do automatyzacji rzeczy, których nie chce się robić ręcznie. Przy dobrym ułożeniu zaoszczędzą ci godziny tygodniowo. Z czasem rozrosły się u mnie do jedenastu, każdy z dobrym intencjonalnym uzasadnieniem.
Granica między narzędziem a hobby
Z tego wszystkiego najważniejsza była dla mnie reguła, której teraz pilnuję, gdy coś buduję w obrębie zaplecza.
Pytanie brzmi brutalnie prosto: gdybym to skasował, cokolwiek by się zepsuło? Jeśli odpowiedź brzmi „nie” — to nie jest narzędzie. To jest hobby, które udaje narzędzie. Hobby może być wartościowe samo w sobie, ale trzeba je rozpoznać jako hobby, nie wpisywać w jego koszty pracę nad produktem.
Mam słabość do budowania zaplecza — pisałem o tym, gdy wydzielałem swój sposób pracy z AI do osobnego repozytorium. To, że tym razem za daleko poszedłem akurat z generatorem, nie znaczy, że tamta decyzja była błędna. Wzorce, których brak boli — wyciągaj. Maszyny, które generują pliki identyczne z tymi, które napisałbyś ręcznie — odpuść.
Granica jest cienka, bo wygląda po obu stronach niemal tak samo. Tylko po jednej stronie jest praca, która zwraca się każdego dnia. Po drugiej jest przyjemność, której koszt płacisz miesiącami.
I tak — luksus, którego pewnie nie będę miał drugi raz
Dziewięć godzin spalonej pracy boli, ale w skali tego, na jakim etapie jestem, to jest tani błąd. Zero żywych danych. Zero ludzi, którzy by tego dotknęli. Mogłem zbudować coś głupiego i skasować bez konsekwencji dla nikogo poza sobą. To jest dokładnie ten sam luksus, o którym piszę przy każdej destrukcyjnej zmianie w produkcie na tym etapie.
Tylko że czas jest jedynym zasobem, którego jednoosobowa firma nie odzyska. Te dziewięć godzin to nie były godziny, w których ucierpiałby użytkownik — to były godziny, w których jeszcze nie pisałem dla niego niczego, co naprawdę chce zobaczyć. To jest właściwy koszt tej historii, nie żadne „złe praktyki inżynierskie”.