Budowanie staniało. To, co zawsze było trudne - nadal jest drogie.

Dlaczego budowanie oprogramowania stało się darmowe… w 1992 roku? Kto pisał kod na papierze? Co w tworzeniu oprogramowania jest trudne i takie pozostanie? Czy bootcamp z JavaScriptu to w 2026 roku dobry pomysł? Czy ludzie, którzy nie są programistami, mogą budować dobre systemy? I wreszcie: co to wszystko oznacza dla naszych klientów i dla modeli biznesowych? Na te pytania próbuję odpowiedzieć, zastanawiając się, co rewolucja AI zmieni w tworzeniu oprogramowania w najbliższych latach. I czego nie zmieni. Opieram się na dwudziestu latach pracy zawodowej i odrobinie grzebania w dawniejszej historii.

Zbierając materiały do tego tekstu, trafiłem na kilka ciekawych artykułów. W jednym z nich padło zdanie: Oprogramowanie jest tanie w budowie. Nie chodzi o to, że jest niedrogie; jest tak tanie, że niemal darmowe. Dziś może to nie brzmieć absurdalnie, ale kiedy się wie, że napisał je Jack Reeves w „C++ Journal” w 1992 roku, sprawa wygląda inaczej. Wiele osób, które przez ostatnie dekady pracowały przy projektach IT i widziały rachunki, chętnie by z tym polemizowało.

Jeżeli wczytać się dokładnie w artykuł, robi się jeszcze ciekawiej, zwłaszcza z perspektywy dzisiejszego boomu na AI. Reeves twierdzi, że w gruncie rzeczy oprogramowanie jest tanie w budowie, ale niezwykle drogie w projektowaniu. Kreśli przy tym kilka paraleli z przemysłem hardware IT i dowodzi, że jedynym prawdziwym projektem, który spełnia formalne kryteria w sensie inżynierskim, jest kod źródłowy. Tanie, a nawet darmowe dzięki postępowi technologicznemu i wciąż taniejącemu sprzętowi (to akurat zestarzało się średnio…) jest to, co wytwarzają kompilatory i linkery. Reeves zwraca też uwagę na ważną rzecz: budowanie i projektowanie wymagają innych kompetencji.

Dziś rzadko o tym pamiętamy, ale w nie tak odległej przeszłości ludzie pisali programy w asemblerze. Kiedy mój ojciec zaczynał karierę, "pisał" programy na kartach perforowanych. Niektórzy moi koledzy pisali kod na kartce na egzaminie na studiach, żeby udowodnić, że rozumieją algorytmy. Do tego trzeba było tęgich głów, a dziś te umiejętności są w dużej mierze zbędne. Czy ta zmiana sprawiła, że tworzenie oprogramowania stało się darmowe?

Przez ostatnie dekady każdy większy przełom technologiczny w inżynierii oprogramowania miał jeden cel: uczynić programowanie bardziej abstrakcyjnym, dostępnym i łatwiejszym. Można o tym myśleć jak o kolejnych warstwach nakładanych na kod maszynowy.

Kiedy pojawiły się języki strukturalne, a potem obiektowe, produktywność wystrzeliła. Były też łatwiejsze do zrozumienia niż asembler. Wymagały jednak nieco innych umiejętności. Przejście od pisania w asemblerze do projektowania systemów (w rozumieniu Reevesa) - czy to już czegoś nie przypomina?

I choć samo rzemiosło pisania kodu stawało się dostępne dla coraz szerszego grona dzięki lepszym IDE, nowoczesnym językom programowania, autouzupełnianiu, Stack Overflow (R.I.P.) i wielu innym narzędziom, kilka rzeczy jakby się nie zmienia. Mówił o tym inny ciekawy tekst, tym razem z 1986 roku (!), autorstwa Fredericka Brooksa. Warto przytoczyć cały akapit:

Najtrudniejszym elementem budowy systemu oprogramowania jest precyzyjne ustalenie, co zbudować. Żadna inna część pracy koncepcyjnej nie jest tak trudna jak określenie szczegółowych wymagań technicznych, łącznie ze wszystkimi interfejsami do ludzi, do maszyn i do innych systemów oprogramowania. Żadna inna część pracy, źle wykonana, nie okalecza powstającego systemu tak bardzo. Żadnej innej nie jest tak trudno później naprawić.

Frederick Brooks, 1986

Dokładnie czterdzieści lat później to wciąż prawda i od tego chciałbym wyjść. Udane wdrożenie systemu IT zawsze składało się z sześciu kluczowych elementów, czy też etapów:

1. Zrozumienie potrzeby
2. Zaprojektowanie rozwiązania
3. Zbudowanie oprogramowania
4. Hosting oprogramowania
5. Wdrożenie oprogramowania w organizacji
6. Wsparcie i rozwój oprogramowania

Całkowity koszt udanego wdrożenia to zawsze suma tych sześciu składników. Z czasem, z każdym postępem technologicznym czy organizacyjnym, niektóre z nich się zmieniały. Języki wysokiego poziomu i nowoczesne IDE sprawiły, że budowanie stało się tańsze i szybsze. Metodyki zwinne (podobno) usprawniły etapy rozumienia i projektowania. Upowszechnienie chmury pozwoliło firmom obniżyć koszty hostingu, uczyniło go dostępniejszym i zmniejszyło inwestycję na starcie. Po drodze zniknęły niektóre zawody i umiejętności (ilu programistów zna dziś asembler?), a pojawiły się nowe, jak Scrum Masterzy czy DevOpsi. Mniej pracy w jednym obszarze często oznaczało więcej pracy w innym.

Nie ma specjalnych powodów, by sądzić, że tym razem będzie inaczej. Dostaliśmy kolejną, bardzo sprawną warstwę nad nowoczesnymi językami programowania, dzięki której pisanie kodu jest dostępniejsze, szybsze i tańsze. I choć uważam, że skończyła się era tłumów kończących bootcampy z JavaScriptu, żeby zaczepić się w IT jako juniorzy, to pozostałe elementy się nie zmieniły, a nawet zyskały na znaczeniu. Ktoś wciąż musi zrozumieć, co trzeba zbudować i jak to ma działać. System musi gdzieś stać. I ktoś powinien odebrać telefon o drugiej w nocy, kiedy coś padnie, i wziąć za to odpowiedzialność. Aha, i dobrze by było, żeby ten ktoś wiedział, co robi.

Co to w takim razie oznacza dla tych, którzy kupują oprogramowanie? Oczywista odpowiedź brzmi: to samo oprogramowanie, tylko taniej i szybciej. Tyle że jakoś tak to nie działa. Moim zdaniem są scenariusze dużo ciekawsze i bardziej przełomowe.

Po pierwsze, skoro kod powstaje szybciej i taniej, można dużo szybciej prototypować. I nie mam na myśli tylko etapu przedsprzedaży, kiedy na drugie spotkanie z klientem przychodzi się z działającym PoC zamiast z PowerPointem i plikiem makiet. Mam na myśli każdy etap cyklu wytwarzania oprogramowania (SDLC).

Przez lata wkładaliśmy mnóstwo wysiłku w ograniczanie ryzyka na etapie analizy i projektowania, bo budowanie było drogie, a przerabianie tego, co już zbudowane, jeszcze droższe. Sporo pracy szło na starcie w to, żeby wszyscy na pewno rozumieli to samo. Mnóstwo złożoności brało się też z zabezpieczania rozwiązania na przyszłość. Bardzo często przed scenariuszami, które nigdy się nie wydarzyły. Kiedy masz tylko jedno podejście, wszyscy boją się, że coś pójdzie nie tak. I wkładają mnóstwo wysiłku w to, żeby nie poszło. A za ten wysiłek ktoś musi zapłacić.

Co więcej, kiedy na efekt budowy czeka się długo, ryzyko, że otoczenie się zmieni i całość się zdezaktualizuje, jest spore. Dziś to już tak nie działa. Budowanie i przebudowywanie jest teraz szybkie i tanie. Trzeba przepisać rozwiązanie na inny stos technologiczny? Proszę bardzo. Zmienić struktury danych? Żaden problem, potrzymaj mi Claude'a. Lepiej szybko zacząć coś budować, sprawdzić to z użytkownikami i wprowadzić ich uwagi, niż próbować wszystko zaplanować. Oczywiście działa to pod warunkiem, że ma się właściwe narzędzia do śledzenia, co się dzieje i dlaczego, oraz odpowiednie przygotowanie. I pamiętajmy, że to działa w obie strony: szybkie budowanie pozwala też szybko zbudować zły system.

Co to oznacza w praktyce dla klienta? Poza tym, że dostaje działające oprogramowanie w kilka tygodni, a nie miesięcy, i za ułamek kosztu na starcie, takie podejście zdejmuje z projektu ryzyko. W typowym scenariuszu, kiedy nietechniczny klient przychodzi do dostawcy, obie strony dzieli spora przepaść we wzajemnym zrozumieniu. Jest mniejsza, jeśli dostawca zna branżę, robił podobne projekty albo specjalizuje się w danej dziedzinie, ale zwykle i tak istnieje. Nie ma lepszego sposobu, żeby ją zasypać, niż zacząć rozmawiać o czymś, co działa, i to ulepszać, zamiast rozmawiać o tablicach, dokumentacji projektowej i umowach.

To otwiera drogę do nowych, ciekawych modeli biznesowych. Ryzyko na starcie jest dużo mniejsze, więc kompetentny dostawca oprogramowania może wziąć jego część (albo całość) na siebie. Organizacje, które nie miały finansowych czy organizacyjnych możliwości, żeby zbudować własne oprogramowanie, mają je teraz w zasięgu ręki. Wiele projektów, które trafiły do zamrażarki, bo ryzyka nie dało się uzasadnić, można odmrozić za ułamek wysiłku. Można też budować inne modele finansowe, bo koszt wytworzenia oprogramowania nie wynika już z prostego równania „godziny x programiści”.

Kolejna bezpośrednia korzyść dla klienta: przy odpowiednich narzędziach i dobrze zaprojektowanym procesie wytwarzania oprogramowania, z właściwymi punktami kontroli po stronie ludzi, oprogramowanie mogą budować osoby, które nie są programistami w tradycyjnym sensie. W tradycyjnym modelu ci, którzy rozmawiali z klientem, rzadko byli tymi samymi ludźmi, którzy potem budowali rozwiązanie. W zależności od skali projektu między nimi bywało wiele warstw, a przy każdym przekazaniu sygnał się zniekształcał.

Dziś nie musi tak być. Ekspert dziedzinowy, który zna branżę klienta, mówi jego językiem i rozumie jego problemy, może zbudować działające oprogramowanie razem z klientem. Nie musi znać wszystkich technicznych szczegółów projektowania struktur danych, strojenia wydajności aplikacji czy wyboru stosu technologicznego. Część tych decyzji zostanie wbudowana w proces SDLC, który pilnuje spójności architektury. Inne sprawdzi i w razie potrzeby poprawi doświadczony starszy inżynier, który przegląda rozwiązanie w kolejnych punktach kontrolnych. W efekcie klient wkłada w wytłumaczenie problemu znacznie mniej wysiłku niż w tradycyjnym modelu, bo tłumaczy go osobie nastawionej na biznes, która ten biznes rozumie. Spada też ryzyko, że coś po drodze pójdzie nie tak.

Czy zatem AI jest rozwiązaniem wszystkich problemów świata w tworzeniu oprogramowania? Oczywiście, że nie. AI warto traktować jak zestaw narzędzi, które wzmacniają to, co i tak robimy. Jeśli jesteśmy w czymś dobrzy, powiedzmy w pisaniu makr w Excelu, rozumiemy arkusz, na którym pracujemy i wiemy, co chcemy osiągnąć, to jest spora szansa, że z AI napiszemy nowe makra dużo szybciej. Jeśli nie mamy pojęcia o Excelu i próbujemy przerobić skomplikowany arkusz z makrami, nie rozumiejąc w pełni jego obecnej struktury ani celu, to dużo bardziej prawdopodobne jest, że narobimy bałaganu. I stanie się to dużo szybciej.

W informatyce popularne jest powiedzenie garbage in, garbage out: jakość wyniku jest zawsze proporcjonalna do jakości danych wejściowych. Komputery nie naprawią magicznie złych danych.

Z oprogramowaniem i AI jest tak samo. Organizacje i ludzie z wieloletnim doświadczeniem w projektowaniu i budowaniu świetnego oprogramowania mogą teraz wykorzystać AI, żeby tworzyć świetne oprogramowanie wydajniej. Dobrze uporządkowana wiedza, wytyczne dla modeli, procesy wokół nich i profesjonalny nadzór ludzi pozwalają nam proponować klientom nowe sposoby współpracy, dzięki którym naprawdę korzystają na tej rewolucji. AI nie zastąpi tych fundamentów, przynajmniej nie tam, gdzie chodzi o coś bardziej złożonego niż prosta strona internetowa. A mimo to nigdy nie było lepszego momentu na budowanie oprogramowania.