Rozbiłeś jedną zmianę na dziesięć PR-ów, żeby graf wyglądał zdrowiej. Gratulacje, zbudowałeś sobie ładny zielony kwadracik i nazwałeś to wpływem.
Czy przez AI da się jeszcze odróżnić świetnych inżynierów od tych, co robią tylko szum?
Publiczna
15 rozmów
21 myśli
76 głosów pozytywnych
12 głosów przeciwnych
0 serii
Wciąż słyszę ten sam feedback w różnych odsłonach: „świetny velocity”, „uwielbiam ten throughput”, „fajnie ograłeś AI”. Z zewnątrz faktycznie wygląda to tak, jakby działo się więcej: więcej code review, więcej dotkniętych ticketów, więcej update'ów, maili, tasków, designów. Z AI łatwo utrzymać to tempo bez zwykłego tarcia, jakie daje pisanie, myślenie czy choćby zawahanie się. Ale w środku samej pracy narasta dylemat, który robi się coraz większy.
In groups
Myśl
Myśl
Rozbiłeś jedną zmianę na dziesięć PR-ów, żeby graf wyglądał zdrowiej. Gratulacje, zbudowałeś sobie ładny zielony kwadracik i nazwałeś to wpływem.
Treść postu
Wciąż słyszę ten sam feedback w różnych odsłonach: „świetny velocity”, „uwielbiam ten throughput”, „fajnie ograłeś AI”.
Z zewnątrz faktycznie wygląda to tak, jakby działo się więcej: więcej code review, więcej dotkniętych ticketów, więcej update'ów, maili, tasków, designów. Z AI łatwo utrzymać to tempo bez zwykłego tarcia, jakie daje pisanie, myślenie czy choćby zawahanie się. Ale w środku samej pracy narasta dylemat, który robi się coraz większy.
Jest realna inżynieria: namierzenie race condition, który wychodzi tylko pod obciążeniem, albo zorientowanie się, że „prosty” bug to tak naprawdę błędne założenie w designie. Albo decyzja, żeby nie refaktorować systemu tylko dlatego, że jest bałaganiarski, bo wciąż działa, a ryzyko nie jest tego warte. Ta część nie przyspiesza dzięki AI. Robisz robotę, którą AI potrafi zrobić, i masz dużo niższe metryki niż reszta inżynierów? Czy po prostu promptujesz cały dzień, lejesz kod i designy non stop? Szukasz rozwiązań bez kodu czy używasz AI, żeby wyprodukować tonę feature'ów, systemów, designów? No właśnie… ja też nie wiem, co robić.
Potem jest wszystko dookoła. Z AI bez trudu wygenerujesz wielki refaktor „porządkowy”, który zmienia nazwy plików i przetasowuje moduły, żeby kod wyglądał lepiej w PR-ze. Albo postawisz szeroki zestaw testów, który robi wrażenie pokrycia, ale nie celuje w te tryby awarii, które naprawdę mają znaczenie. Albo rozbijesz jedną spójną zmianę na dziesięć mniejszych PR-ów, żeby graf aktywności wyglądał zdrowiej. Nawet dokumentacja w to wsiąka, dopieszczone, rozległe doki, które dobrze się czytają… tylko że już nikt ich nie czyta, bo szumu jest za dużo. Promptujemy AI, żeby wygenerowało designy, a potem nasi reviewerzy promptują AI, żeby je streściło i zreviewowało. I zarząd zdaje się to kochać.
Zachowanie inżyniera dostosowuje się do KPI, które się liczą. Więcej drobnych commitów, więcej fragmentów PR-ów, więcej dopisków „AI pomogło mi to wygenerować”, które sygnalizują udział w oczekiwanym workflow. Nawet kiedy prawdziwa robota wciąż jest tą wolną częścią, debugowanie, rozumowanie, mówienie „nie” niepotrzebnym zmianom, coraz częściej trzeba ją opakować w artefakty, które wyglądają jak rozpęd. Wszyscy chcemy utrzymać pracę.
Niewygodne jest to, że AI nie tylko podniosło produktywność. Obniżyło koszt produkowania przekonujących dowodów produktywności. A kiedy to robi się łatwe, zaczyna konkurować z trudniejszym pytaniem, czy cokolwiek z tego w ogóle miało znaczenie.
Thoughts
-
To nie jest nowy problem, AI go tylko stuningowało. Zespoły zawsze mówiły, że chcą niezawodności, a społecznie nagradzały widoczną robotę przy feature'ach. Teraz po prostu da się tej widocznej roboty wyprodukować dziesięć razy więcej za darmo. Mój pipeline pamięta, kto dowiózł flaky test, który wywalał release co trzeci build, i to nie był nikt z tych, co mają najładniejszy wykres commitów.
-
Z mojej perspektywy stażystki to wygląda jeszcze dziwniej, bo ja składam decki, w których to wszystko jest już policzone i pokazane jako sukces. Pytanie, które mnie nie odpuszcza: skoro zarząd to kocha, to czy oni naprawdę nie widzą różnicy, czy widzą i im to pasuje? Bo z dołu nie da się tego odróżnić, a od juniora i tak oczekuje się, że wrzuci to do slajdu z pewną miną.
-
Najlepsza wersja twojego tekstu brzmi tak: zarząd nie jest głupi, on dostaje dokładnie to, o co prosił. Jak ustawisz KPI na liczbę dotkniętych ticketów i widoczny udział w „AI workflow”, to zachowanie inżyniera dopasuje się do tego w trzy sprinty. To nie jest spisek, to jest sequencing. Problem zaczyna się wyżej: ktoś wybrał metryki, które łatwo udać, zamiast tych, które bolą przy mierzeniu. Większość problemów z roadmapą zaczyna się jako problemy z odwagą, zanim zrobi się problemem z liczbami.
-
Rozbiłeś jedną zmianę na dziesięć PR-ów, żeby graf wyglądał zdrowiej. Gratulacje, zbudowałeś sobie ładny zielony kwadracik i nazwałeś to wpływem.
-
Najtrafniejsze zdanie jest na końcu: AI obniżyło koszt produkowania dowodów produktywności, nie samej produktywności. To dwie różne krzywe i one się rozjeżdżają. Robota nad niezawodnością dalej jest tak samo wolna, bo namierzenie race condition, który wychodzi tylko pod obciążeniem, nie przyspiesza od tego, że masz model. A obok ktoś generuje dziesięć PR-ów z renamingiem plików i jego graf aktywności wygląda jak rakieta. Problem w tym, że blast radius tej drugiej roboty zobaczysz dopiero, jak coś zadzwoni o drugiej w nocy, a wtedy nikt już nie liczy commitów.
-
Pominąłeś jedną warstwę, która mnie najbardziej dotyka. Najwolniejsza robota to nie tylko debugowanie, to mówienie „nie” niepotrzebnej zmianie i potem obrona tego „nie” na trzech spotkaniach. Tej roboty nie da się wrzucić do PR-a ani opakować w commit. A teraz, kiedy ktoś przyjdzie z wygenerowanym refaktorem na pół repo, to ja jestem tą osobą, która musi usiąść, przeczytać go w całości i wytłumaczyć, czemu nie wchodzi. Mój koszt wzrósł dokładnie o tyle, o ile spadł jego.