Rok temu mój feed na LinkedIn miał osobny gatunek. Program manager albo „delivery lead”, albo ktoś z Agile w nagłówku wrzucał screenshot, na którym AI pisze funkcję, dorzucał linijkę w stylu „a mówili, że ta robota jest pewna, wystarczy nauczyć się kodować” i zbierał czterysta lajków od ludzi, którzy robią dokładnie to samo. W domyśle zawsze było, że to klepanie kodu jest tą inżynierią — a skoro model już potrafi klepać, klasa klepiących się skończyła.
Moim zdaniem czytali ten org chart do góry nogami. I cieszę się, że się o tym przekonują
Jest coś, czego nikt po tamtej stronie feedu nie powie na głos. AI średnio radzi sobie z tą nośną częścią budowania, czyli z decydowaniem, co system ma w ogóle robić, z pamiętaniem, dlaczego padły trzy poprzednie podejścia, i z wyłapaniem, kiedy model z pełnym przekonaniem podał ci coś zepsutego. Za to w tej drugiej części jest naprawdę, aż wstyd, dobre. Status rollup. Release notes, których nikt nie czyta. Katalog feature'ów, który po tygodniu jest już nieaktualny. Test plan, który w większości jest przeformatowaniem acceptance criteria. Cotygodniowy update, który streszcza standup, który streszczał wątek na Slacku. To nie jest praca, z którą AI ma problem. To jest praca, do której AI się urodziło.
Więc popatrz, kto gdzie siedzi. Warstwa wsparcia istnieje z założenia po to, żeby robić te części, których inżynierowie robić nie chcieli. Trzymać tracker projektu aktualny. Ścigać ludzi o updaty. Zamienić dwa zdania inżyniera w akapit dla VP. Zamienić akapit inżyniera w dwa zdania dla VP. Pilnować dokumentacji. Prowadzić spotkanie, na którym wszyscy mówią to, co wczoraj napisali. Nie znęcam się tu nad nikim. Te zadania były realne, były upierdliwe i ktoś musiał je robić — i właśnie dlatego te role dostały finansowanie. Problem w tym, że „zrobić czysty skrót z inputów, które wytworzył ktoś inny” to dokładnie ten kształt rzeczy, które model językowy robi najlepiej, a „wytworzyć te inputy” to ta część, której wciąż nie ogarnie sam.
I tu jest asymetria, którą prorocy obsolescencji pominęli. Żeby dobrze korzystać z AI, trzeba umieć je sprawdzić. Trzeba przeczytać diff i wiedzieć, że jest błędny. Trzeba spojrzeć na wygenerowaną migrację i zauważyć, że nie ma rollbacku. Builder już to ma. To ta sama umiejętność, która zrobiła z niego buildera. Warstwa koordynacji z kolei była zatrudniana z wyraźnym założeniem, że kodu czytać nie będzie musiała — a teraz narzędzie, które ma jej oszczędzić pracy, produkuje output, któremu może zaufać tylko ktoś, kto kod czyta. Dostali do ręki piłę łańcuchową, a instrukcja jest w języku, którego — jak im obiecano — nigdy nie musieli się uczyć.
Dobry program manager to nie maszyna do status update'ów.
Tak, wiem. Ale z jakichś czterdziestu, których do tej pory poznałem w karierze, może dwóch takich było. Trzydziestu ośmiu to były ewidentnie maszyny do status update'ów. Prawdziwa robota, ta, za którą warto płacić, to ocena, co wyleci z zakresu, polityczny parasol, kiedy launch się ślizga, wyczucie, czyje „szybkie pytanie” jest groźbą, i doprowadzenie sześciu zespołów, które się nawzajem nie znoszą, do zgody na jedną datę. AI nie robi nic z tego. Nie weźmie na siebie winy w sali. Nie zdecyduje, że technicznie poprawna kolejność jest tą politycznie samobójczą. Sprowadzanie całej tej funkcji do „dba o to, żeby strona na Confluence nie wystygła” to najstarsza fantazja kodera i zawsze się myliła co do tych najlepszych w tej roli. Wiem.
Robota od oceny i osłaniania nigdy nie była całym headcountem. Pod każdym z tych naprawdę dobrych program managerów była warstwa ludzi, których faktyczny dzień to było utrzymywanie artefaktów, rollup, katalog, deck, który powtarzał poprzedni deck.
Ekipa „inżynierowie są skończeni” miała to na odwrót, bo pomyliła tego, kto wytwarza wartość, z tym, kto najgłośniej o tym wytwarzaniu mówi. Człowiek, który odróżni dobrą odpowiedź od pewnej siebie złej, to ten, którego AI czyni cenniejszym, nie mniej cennym. A ten człowiek zwykle budował. Rzadko był tym, który wrzucał screenshot.