Pułapka Płaskowyżu

Niedawno napisałem o zmęczeniu AI, argumentując, że to, co doświadczają inżynierowie, nie jest przewlekłym stanem, ale bólem treningowym. Przełam go, dostosuj się, wyjdź silniejszy.

To wszystko jest dobre i słuszne, ale jest więcej do tej historii, i staje się coraz bardziej oczywiste. Prawdziste ryzyko, które stoi przed zespołami inżynierskimi w tej chwili, nie jest wypalenie. To płaskowyż.

Nowy Podział

Prawie każdy starszy inżynier używa teraz AI. Copilot, Claude, Cursor, Codex, wymień je. Ta część jest uregulowana. Jeśli prowadzisz organizację inżynierską, prawdopodobnie widzisz szerokie liczby przyjęć i czujesz się dobrze z tym.

Nie powinieneś.

Liczba przyjęć jest bez znaczenia. To, co się liczy, to podział, który zachodzi pod nią. Twój zespół dzieli się na dwie grupy. Są inżynierowie, którzy otrzymali wzrost wydajności i osiedli, i inżynierowie, którzy ciągle się rozwijają. Nowe przepływy pracy, nowe konfiguracje agentów, nowe sposoby dekompozycji problemów, aby AI mogła je rozwiązać.

Obie grupy pojawiają się w Twoich pulpictach jako “użytkownicy AI”. Ale jedna jest na progresywnym programie treningowym. Druga zatrzymała się na pierwszym ciężarze, który wydawał się wygodny.

Sześć miesięcy temu przepaść między tymi dwiema grupami była ledwo widoczna. Teraz jest oczywista dla każdego, kto zwraca uwagę. W ciągu kolejnych sześciu miesięcy stanie się strukturalna.

Czym Tak Naprawdę Jest Płaskowyż

Inżynier, który osiągnął płaskowyż, nie robi nic złego w klasycznym sensie. Jest kompetentny. Wysyła. Używa swojego agenta do prostych zadań i sprząta po nim. Otrzymał może 20-30% wzrost wydajności i uznał, że to wystarczy.

Problem polega na tym, że inżynier obok niego nie zatrzymał się tam. Ten inżynier teraz prowadzi wieloagentowe przepływy pracy, poprawia pętle weryfikacyjne, dekomponuje całe funkcje w AI-wykonalne kawałki, przegląda na poziomie architektonicznym, a nie linijka po linijce, i wysyła z dwukrotnie lub trzykrotnie większą szybkością niż wcześniej. Nie dlatego, że są bardziej utalentowani. Dlatego, że ciągle trenowali, podczas gdy wszyscy inni brali dzień wolny, który przerodził się w kwartał wolny.

To nie jest kwestia entuzjazmu AI ani bycia wczesnym użytkownikiem. Faza wczesnego przyjęcia jest skończona. To jest kwestia ciągłej adaptacji versus jednorazowej regulacji. A różnica między tymi dwiema podejściami staje się nie do pominięcia.

Rywalizacja Jest Rzeczywista i Przyspiesza

Jeśli Twoje zespoły miały luksus adaptacji według własnego harmonogramu, problem płaskowyżu byłby kwestią zarządzania wydajnością. Irrytującym, ale zarzadzalnym.

Ale jeśli spojrzy się na szerszą sytuację w branży oprogramowania, szansa jest taka, że nie masz tego luksusu.

Branża oprogramowania, w dużej mierze, została stworzona, aby pomóc ludziom w pracy cyfrowej: pomagać agentom wsparcia widzieć przychodzące przypadki, śledzić odpowiedzi klientów, zarządzać przepływami pracy. Teraz agenci AI wypierają cały przepływ pracy i destabilizują podstawowe platformy SaaS. Dodatkowo, AI staje się coraz bardziej zdolna, a Twoi klienci zaczynają zadawać pytanie: “Czy nadal musimy kupować to, czy możemy to zbudować sami?” AI zaczęła zmniejszać barierę między “kupnem” a “zbudowaniem” dla rosnącego zestawu przypadków użycia. Przywiązanie, które chroniło Twoje przychody, osłabia się co kwartał.

Twoi inżynierowie, którzy osiągnęli płaskowyż, pracują w tempie skalibrowanym dla środowiska konkurencyjnego, które już nie istnieje.

Cytat, Który Zmienił Wszystko Dla Mnie

Słyszałem to więcej niż raz, od menedżerów produktów, którzy zwinęli rękawy i zaprojektowali funkcje, od liderów inżynierskich, którzy przebudowali nieudane architektury, w różnych firmach, w różnych kontekstach:

“Było łatwiej dla mnie iterować nad tym z moimi agentami, niż z tym inżynierem.”

Pierwszy raz, kiedy to usłyszałem, pomyślałem, że to przesada. Trzeci raz, zrozumiałem, że to wskaźnik wiodący.

Widzę to w ten sposób: są inżynierowie, którzy będą prosperować w tym nowym świecie i będą “mnożnikami” możliwości AI. Aby to zrobić, muszą być silni w dwóch obszarach, oba z których mogą być samodzielnie rozwijane z wystarczającą motywacją wewnętrzną i ciekawością intelektualną:

• Pracują “na tej samej fali” co ich stakeholderzy (menedżerowie produktów, menedżerowie inżynierscy itp.). Rozumieją, co jest dobre, więc nie musisz im nic wyjaśniać. Bo jeśli produkują tyle samo niezrozumień, co Twój agent kodujący, agent zawsze wygra tę bitwę. Jest dostępny natychmiast, 24/7, i nieznużony.
• Ciągle poprawiają swoje konfiguracje AI, więc kiedy im coś dasz, wiesz, że będzie to zrobione nie tylko dobrze (patrz powyżej), ale także wystarczająco szybko, aby nadążyć za nowym tempem rynku.

Dlaczego To Jest Problem Liderów, A Nie Indywidualny

To kuszące, aby to ujmować jako odpowiedzialność indywidualnego inżyniera. “Dorównaj lub zostanie w tyle.” Ale jeśli prowadzisz organizację inżynierską, to ujęcie pozwala ci uniknąć odpowiedzialności.

Twoi inżynierowie, którzy osiągnęli płaskowyż, nie osiągnęli go w próżni. Osiągnęli go, bo nic w ich środowisku nie pchnęło ich dalej niż początkowa regulacja. Osiągnęli rozsądnego wyglądu wzrostu wydajności, nikt ich nie wyzwalał do dalszego rozwoju, a bezwładność zrobiła resztę.

Inżynierowie, którzy ciągle się rozwijali? Większość z nich jest samodzielnie zmotywowana. Rozwijaliby się niezależnie. Ale nie możesz obsadzać organizacji inżynierskiej wyłącznie samodzielnie zmotywowanymi pionierami. Pytanie dla liderów brzmi: jak przenieść środek?

To jest problem zarządzania zmianą, a jeden z moich ulubionych ram zarządzania zmianą pochodzi z książki braci Heath Switch. Krótko mówiąc: musisz dać ludziom jasny kierunek, sprawić, by czuli, dlaczego to się liczy, i zmienić środowisko tak, aby nowe zachowanie było ścieżką najmniejszego oporu. Zastosowane do zespołów inżynierskich, wygląda to tak:

Znajdź swoje jasne punkty i spraw, by były widoczne. Zidentyfikuj inżynierów, którzy posunęli się najdalej w swoich przepływach pracy AI i niech będą demo dla zespołu regularnie. Nie sesje szkoleniowe. Żywe przewodniki po prawdziwej pracy. Kiedy środek Twojego zespołu widzi różnicę między swoim przepływem pracy a przepływem pracy najlepszego adaptera, tworzy produktywny dyskomfort, którego nie może dorównać żadne zarządzenie.

• Zmniejsz zmianę. “Przyjmij AI” jest zbyt abstrakcyjne, aby na niego działać. Ten sprint, przybij e2e testowanie agentów, następny sprint wdroży to w całej organizacji, itd. Konkretne, zarzadzalne kroki biją ambitne programy transformacji za każdym razem, a małe zwycięstwa mają znaczenie.
• Zmienione domyślne ustawienia. Skodyfikuj proces weryfikacji w umiejętnościach AI i upewnij się, że są one wdrożone w Twoim zespole i we wszystkich ich agentach. Zdefiniuj swoje przepływy pracy i użyj narzędzi, które to wspierają. Zrób nowy sposób pracy ścieżką najmniejszego oporu, aby ludzie nieświadomie zmierzali w tym kierunku, zamiast walczyć, aby tam dojść.

Okno Zamyka Się

To jest część, która sprawia, że to jest pilne, a nie tylko ważne.

W tej chwili luka adaptacyjna jest różnicą wydajności. Twoi inżynierowie, którzy osiągnęli płaskowyż, są wolniejsi niż Twoi inżynierowie, którzy się rozwijają, ale nadal są produktywni. Nadal przyczyniają się. Możesz ich dalej wspierać.

To okno zamyka się. Im szybciej rosną możliwości AI i im bardziej nasilają się presje konkurencyjne, tym bardziej rośnie minimalna wydajność pracy inżynierskiej. “Dostatecznie dobry” inżynier dzisiaj nie jest gwarantowany, aby być wystarczająco dobrym w następnym kwartale. Nie dlatego, że się pogorszył, ale dlatego, że podłoga poszła w górę.

Organizacje, które rozwiążą, jak przenieść cały swój zespół w górę krzywej adaptacji, a nie tylko wczesnych użytkowników, będą miały zwiększającą się strukturalną przewagę. Te, które nie zrobią, odkryją, że są obsadzone dla tempa konkurencji, które już nie istnieje.

Każdy lider inżynierski, z którym rozmawiam, rozumie to intelektualnie. Bardzo niewielu zmieniło, jak prowadzą swoje zespoły w odpowiedzi. Przerwa między zrozumieniem a działaniem jest swoistym rodzajem płaskowyżu.

Nie Ma Wygodnego Tempa

W artykule o zmęczeniu AI argumentowałem, że ból jest dowodem, że trening działa. To nadal prawda. Ale następna prawda jest trudniejsza: ciężar cały czas rośnie.

W normalnej siłowni możesz wybrać wygodny ciężar i utrzymać go na zawsze. Nikt nie dodaje talerzy do Twojej sztangi bez pytania. W obecnej krajobrazie oprogramowania każde nowe wydanie modelu, każda nowa funkcjonalność agenta, każdy nowy przepływ pracy, który ktoś wymyśla i udostępnia, sztanga się przesuwa. Stój w miejscu i waga w końcu cię przypnie.

Nie ma wygodnego miejsca w branży oprogramowania w tej chwili. Nie dla indywidualnych inżynierów, nie dla zespołów, na które pracują, nie dla firm, które te zespoły budują. Jedyna bezpieczna pozycja to ciągły ruch. A jedynym pytaniem, które ma znaczenie dla liderów inżynierskich, jest to, czy cały Twój zespół się porusza, czy tylko ci, którzy i tak by się poruszyli.