Branża tworzenia oprogramowania zmienia się — na stałe

W 2003 roku założyłem DCSL Software, które później stało się One Beyond. Odszedłem w 2023 roku po umiędzynarodowieniu firmy i rozwinięciu jej do ponad 300 osób. Od tego czasu założyłem start-up robotyczny i pozyskałem ponad 4 miliony funtów w finansowaniu zalążkowym.  

Nigdy nie spodziewałem się, że znowu będę pisał oprogramowanie produkcyjne. Przestałem kodować na co dzień w 2014 roku, nie dlatego, że nie mogłem tego robić, ale dlatego, że tak się dzieje, gdy firma się rozwija. Zatrudniasz ludzi, którzy są lepsi od ciebie w wykonaniu, skupiasz się na przywództwie, a stopniowo klawiatura oddala się. Przez prawie dziesięć lat wydawało się to całkowicie naturalne.  

Czego nie oczekiwałem, to tego, że prawie dziesięć lat później znowu znajdę się na miejscu programisty — nie z nostalgii, ale praktycznie. Nie eksperymentując, ale budując naprawdę złożoną platformę robotyczną. I nie poprzez ponowne uczenie się każdego frameworka czy języka, który mnie ominął, ale poprzez pracę w fundamentalnie inny sposób.  

Ta osobista zmiana jest najwyraźniejszym sygnałem, jaki widziałem, że coś strukturalnego zmieniło się w tworzeniu oprogramowania.  

Jak projektowaliśmy oprogramowanie — i dlaczego  

Kiedy zaczynałem, byliśmy mocno w erze kaskadowej. To nie była ideologia, to była ekonomia. Oprogramowanie było wolne i drogie w budowie, więc jedynym rozsądnym podejściem było bardzo dokładne przemyślenie wszystkiego z góry.  

Pisaliśmy szczegółowe specyfikacje, ponieważ musieliśmy. Umowy od nich zależały. Dostawa od nich zależała. Pisanie dobrej specyfikacji było specjalistyczną umiejętnością, w której akurat byłem dość dobry. Mogłem wyobrazić sobie, jak może wyglądać gotowy produkt, zanim zaistniał, przewidzieć obszary złożoności i opisać zachowanie z wystarczającą precyzją, aby zespół mógł to zbudować.  

Ta umiejętność była rzadka i trudna do nauczenia. Wiele osób miało z tym problem, ponieważ wyobrażenie sobie złożonego systemu, który jeszcze nie istnieje, jest naprawdę trudne. Ale to miało znaczenie, ponieważ popełnienie błędów późno w procesie było bolesne i kosztowne.  

Z czasem branża przeszła w kierunku Agile. Publicznie zostało to przedstawione jako lepszy sposób reagowania na zmiany. Po cichu było to również uznanie, że w przypadku dużych, długotrwałych systemów żadna specyfikacja nie przetrwa nienaruszona. Firmy się zmieniają, użytkownicy się zmieniają, technologia się zmienia, a udawanie inaczej często powodowało więcej szkody niż pożytku.  

Agile było pragmatyczne, ale wiązało się z kosztem. W dużej mierze porzuciliśmy głębokie projektowanie z góry i zastąpiliśmy je stopniowym odkrywaniem. To działało, ale też znormalizowało sposób myślenia, w którym myślenie zbyt daleko do przodu było postrzegane jako niepotrzebne, a nawet ryzykowne.  

Co się zmieniło — i dlaczego zacząłem znowu budować  

Powodem, dla którego mogłem wrócić do praktycznego programowania, nie jest to, że nagle znalazłem czas lub chęć, aby ponownie nauczyć się dekady narzędzi. To dlatego, że AI fundamentalnie zmieniła koszt eksperymentowania.  

To jest część, która jest często źle rozumiana. Prawdziwa zmiana nie polega na tym, że kod jest szybszy do napisania. Chodzi o to, że próbowanie rzeczy jest teraz tanie, szybkie i w dużej mierze odwracalne.  

Rzeczy, które kiedyś zajęłyby tygodnie pracy programisty, można teraz wypróbować w kilka minut. Możesz zbadać podejście, zobaczyć, jak się sprawdza, całkowicie je odrzucić i spróbować innego kierunku z bardzo małą karą. To po prostu nie było możliwe wcześniej.  

W przeszłości istniało silne emocjonalne i finansowe przywiązanie do kodu. Jeśli coś zajęło dwóm programistom trzy tygodnie budowy, byłeś zrozumiale niechętny, aby to wyrzucić. Decyzje twardniały wcześnie, nie zawsze dlatego, że były właściwe, ale dlatego, że ich cofnięcie było zbyt kosztowne.  

To ograniczenie zniknęło i to właśnie mnie z powrotem wciągnęło. Mogę teraz działać na poziomie, w którym jestem najsilniejszy — rozumienie problemu, kształtowanie systemu, zauważanie, kiedy wkrada się złożoność — podczas gdy AI zajmuje się mechaniką. Nie piszę kodu w sposób, w jaki robiłem to po dwudziestce. Kieruję nim, udoskonalam go, poprawiam i czasami powstrzymuję przed pójściem w całkowicie złym kierunku. W praktyce przypomina to bardziej kierowanie zespołem niż pisanie kodu. Jesteś faktycznie szefem — wyznaczasz kierunek, przeglądasz wyniki, wyłapujesz leniwe skróty i odrzucasz, gdy coś nie wydaje się właściwe. 

Dlaczego projektowanie nadal ma znaczenie — bardziej niż kiedykolwiek   

Łatwo byłoby założyć, że ta nowa wolność sprawia, że projektowanie jest mniej ważne. W rzeczywistości sprawia, że jest ważniejsze.   

Posiadanie jasnego, szczegółowego pomysłu na to, co próbujesz zbudować, jest nadal niezwykle cenne. W rzeczywistości aktywnie poprawia wyniki AI. Im jaśniejszy zamiar, tym lepsze rezultaty. Niejasne myślenie po prostu szybciej produkuje niejasne systemy.  Co ważne do zrozumienia, to że AI zachowuje się bardzo podobnie do osoby. Chce być pomocna. Chce dać ci odpowiedź. Jeśli jesteś niejasny, wypełni luki. Jeśli jesteś niedbały, przyjmie założenia. Jeśli nie zakwestionujesz, pewnie pójdzie dalej złą ścieżką.  

Różnica polega na tym, że projektowanie nie jest już kruchym, jednorazowym artefaktem, który musi przetrwać niezmieniony przez lata. Stało się przewodnikiem do eksperymentowania, a nie jego ograniczeniem. Możesz mieć silną wizję tego, dokąd zmierzasz, będąc jednocześnie gotowym próbować, odrzucać i rozwijać ścieżkę, która cię tam doprowadzi.   

Nową umiejętnością jest wiedza, kiedy eksploracja jest produktywna, a kiedy to tylko szum. AI będzie z radością generować strukturę długo po tym, jak powinna zostać uproszczona. Nie wie, kiedy plik stał się zbyt duży, kiedy abstrakcja przecieka, lub kiedy coś, co „działa" dzisiaj, spowoduje ból później. Te instynkty nadal pochodzą z doświadczenia.  

Co to zmienia w branży  

Gdy eksperymentowanie staje się tanie, wiele długo utrzymywanych założeń przestaje się sprawdzać. Planowanie nie polega już na zablokowaniu wszystkiego z góry. Chodzi o wyznaczenie intencji, ograniczeń i granic.  

Szacowanie staje się mniej o przewidywaniu wysiłku, a bardziej o zrozumieniu przestrzeni, którą eksplorujesz.  

A nasz związek z kodem całkowicie się zmienia. Jest znacznie mniej przywiązania do konkretnych implementacji i znacznie więcej skupienia na zachowaniu, strukturze i wynikach.  

Dlatego branża tworzenia oprogramowania czuje się niespokojnie. Wiele osób próbuje zastosować stare modele mentalne do nowych narzędzi. To działa przez jakiś czas, ale mija się z celem.  

Prawdziwa zmiana  

Powodem, dla którego jestem pewien, że ta zmiana jest trwała, jest prosty: nie buduję znowu inaczej.  

Jedynym powodem, dla którego mogę wiarygodnie wrócić do praktycznego programowania po dekadzie nieobecności, jest to, że ograniczenia, które mnie wypchnęły na początku, już nie obowiązują. Oprogramowanie może teraz ewoluować poprzez kierowane eksperymentowanie w sposób, który po prostu nie był możliwy wcześniej.  

To nie oznacza, że doświadczenie ma mniejsze znaczenie. Oznacza to, że ma znaczenie inaczej. Wartość nie polega już na zapamiętywaniu składni czy frameworków. Chodzi o osąd, strukturę i wiedzę, kiedy przestać.  

To nie jest koniec tworzenia oprogramowania. Ale to jest koniec starego modelu. A gdy już pracowałeś w ten sposób, nie ma odwrotu.