Od lat żyjemy w świecie technologicznej propagandy sukcesu. Branża informatyczna nieustannie opowiada o przełomach: o chmurze obliczeniowej, architekturze mikroserwisowej, konteneryzacji, automatyzacji testów, ciągłym dostarczaniu, obserwowalności, inżynierii niezawodności serwisowej i wreszcie o sztucznej inteligencji, która rzekomo ma zaraz pisać za nas większość kodu.
Z tej narracji wynikałoby, że powinniśmy już mieszkać w świecie usług cyfrowych działających z precyzją szwajcarskiego zegarka. Tymczasem rzeczywistość wygląda znacznie mniej imponująco. Wciąż bez większego trudu można znaleźć banki, które nie potrafią poprawnie wyświetlić listy operacji na koncie, systemy transakcyjne, które nie pokazują potwierdzenia wykonanej operacji, oraz wielkie platformy handlowe, które przez tygodnie albo miesiące nie są w stanie ustabilizować procesu płatności.To nie jest drobna usterka.
To nie jest wypadek przy pracy. To jest diagnoza całej branży.Prawda jest taka, że mimo gigantycznego postępu w narzędziach, infrastrukturze i skali wdrożeń, jakość oprogramowania jako całości poprawiała się zaskakująco słabo. Owszem, mamy dziś lepsze serwery, dojrzalsze systemy operacyjne, tańszą redundancję sprzętową, powszechniej dostępne mechanizmy korekcji błędów pamięci operacyjnej, rozproszone systemy danych, gotowe platformy chmurowe i automatyzację niemal każdego etapu dostarczania.
Ale to wszystko rozwiązało głównie problem kosztu uruchomienia oraz kosztu zmiany. Nie rozwiązało problemu fundamentalnego, czyli rosnącej złożoności systemów, nad którą organizacje coraz częściej tracą kontrolę.To właśnie jest sedno sprawy. Branża nauczyła się produkować więcej kodu, szybciej wdrażać zmiany i szybciej skalować rozwiązania. Nie nauczyła się jednak równie skutecznie ograniczać złożoności, która ten postęp po cichu neutralizuje. W efekcie powstał świat, w którym systemy są jednocześnie bardziej zaawansowane i bardziej kruche.
Bardziej rozbudowane i mniej przewidywalne. Bogatsze w funkcje, ale uboższe w niezawodność.Przez lata wmawiano rynkowi, że problem jakości oprogramowania rozwiąże kolejna technologia. Najpierw miał to zrobić lepszy język programowania. Potem framework. Potem architektura zorientowana na usługi. Potem mikroserwisy. Potem kultura DevOps, czyli podejście łączące rozwój oprogramowania i operacje. Potem obserwowalność. Potem platformy chmurowe. Teraz tę rolę ma odegrać sztuczna inteligencja.
Problem polega na tym, że wszystkie te rozwiązania mogą poprawić produktywność, ale żadne z nich nie gwarantuje jakości. Jakość nie bierze się z posiadania nowoczesnego stosu technologicznego. Jakość bierze się z umiejętności utrzymania kontroli nad systemem jako całością.A z tym branża ma coraz większy problem, ponieważ dzisiejsze systemy nie są już po prostu programami. Są układami zależności między wieloma zespołami, dostawcami, interfejsami programistycznymi, systemami dziedzinowymi, platformami zewnętrznymi, warstwami bezpieczeństwa, narzędziami raportowymi, wymaganiami regulacyjnymi i historycznymi kompromisami, których nikt już nawet dobrze nie pamięta.
Użytkownik widzi tylko to, że aplikacja bankowa nie pokazuje mu historii operacji. Inżynier widzi pod spodem dziesięć lat długu technicznego, trzy równoległe modele danych, pięć niespójnych warstw integracyjnych i dwa zespoły, które od dawna nie wiedzą już, gdzie kończy się odpowiedzialność jednego, a zaczyna drugiego.Najbardziej niewygodna prawda brzmi jednak jeszcze inaczej. Problem jakości oprogramowania nie wynika przede wszystkim z tego, że programiści są za słabi albo że brakuje dobrych praktyk. Problem wynika z tego, że większość organizacji jest zarządzana w sposób systemowo wrogi jakości.
Firmy nagradzają szybkość dostarczania nowych funkcji, zgodność z terminem, widoczność projektową i krótkoterminowy efekt biznesowy. Nie nagradzają redukcji złożoności, upraszczania architektury, eliminowania zbędnych wariantów, refaktoryzacji, poprawy spójności semantycznej ani usuwania sprzężeń między komponentami. Innymi słowy, organizacje regularnie finansują dokładnie te działania, które zwiększają prawdopodobieństwo przyszłych awarii, a zaniedbują te, które mogłyby ich uniknąć.
To dlatego można obserwować tak absurdalne sytuacje, w których ogromne instytucje z budżetami liczonymi w milionach lub miliardach nie są w stanie miesiącami usunąć błędów dotykających podstawowych funkcji produktu. Często nie chodzi o to, że nikt nie potrafi tego naprawić. Chodzi o to, że koszt organizacyjny bezpiecznego wprowadzenia poprawki w systemie o wysokiej złożoności jest już tak duży, że firma zaczyna bać się własnego oprogramowania.
Każda zmiana grozi naruszeniem innego obszaru, każda poprawka uruchamia lawinę zależności, a każda próba uporządkowania architektury przegrywa z kolejną pilną funkcją dla biznesu.I właśnie w takim stanie branża wchodzi w epokę sztucznej inteligencji.
To może być moment przełomowy, ale niekoniecznie w takim sensie, w jakim większość ludzi sobie wyobraża. Sztuczna inteligencja rzeczywiście potrafi już dziś znacząco przyspieszać implementację. Potrafi generować warstwę dostępu do danych, kod aplikacyjny, testy jednostkowe, interfejsy użytkownika, integracje, transformacje danych, a nawet całe szkielety usług. Dla wielu organizacji będzie to oznaczało gwałtowny spadek kosztu produkcji kodu. I tu właśnie pojawia się największe ryzyko.Jeżeli dotąd problemem było to, że firmy tworzyły zbyt dużo złożoności ręcznie, to teraz będą mogły tworzyć jeszcze więcej złożoności niemal za darmo.
To jest punkt, który w publicznej debacie bywa kompletnie pomijany. Kod nie jest najcenniejszym zasobem inżynierii oprogramowania. Kod jest tylko materializacją decyzji. Jeżeli decyzje są złe, to szybsze generowanie kodu nie poprawia jakości, tylko przyspiesza rozpad. Sztuczna inteligencja nie rozwiązuje automatycznie problemu błędnych granic modułów, niespójnych modeli domenowych, źle zaprojektowanych kontraktów integracyjnych, niekontrolowanej liczby wyjątków biznesowych ani chaosu odpowiedzialności między zespołami. Ona tylko sprawia, że wszystkie te problemy mogą materializować się szybciej i na większą skalę.
Można wręcz postawić tezę, że sztuczna inteligencja nie tyle obniży znaczenie inżynierii oprogramowania, ile brutalnie obnaży, czym inżynieria naprawdę jest. Przez lata wielu ludzi utożsamiało ją z pisaniem kodu. Tymczasem w rzeczywistości najtrudniejsza część tej pracy nigdy nie polegała na samym kodowaniu. Najtrudniejsze było ustalenie, co w ogóle powinno zostać zbudowane, jak podzielić system na sensowne granice odpowiedzialności, jak zaprojektować przepływy danych, jak wymusić zgodność semantyczną, jak ograniczyć liczbę wariantów, jak zabezpieczyć system przed awarią części komponentów i jak sprawić, aby po roku, trzech albo pięciu latach nadal dało się go bezpiecznie rozwijać.
W świecie, w którym sztuczna inteligencja może napisać większość kodu, ta prawda stanie się jeszcze wyraźniejsza. Wąskim gardłem nie będzie już szybkość implementacji. Wąskim gardłem stanie się jakość decyzji architektonicznych, zdolność do walidacji zmian oraz umiejętność odrzucania tych funkcji, integracji i wyjątków, które zwiększają entropię systemu bardziej, niż zwiększają wartość biznesową.
To oznacza, że przyszłość jakości oprogramowania nie rozegra się na poziomie pytania, czy model językowy umie wygenerować poprawną klasę, endpoint albo zapytanie. Rozegra się na poziomie organizacyjnym i architektonicznym. Zwyciężą nie ci, którzy wygenerują najwięcej kodu, lecz ci, którzy najlepiej opanują dyscyplinę ograniczania złożoności.
Co to oznacza w praktyce? Przede wszystkim trzeba porzucić złudzenie, że sama produktywność implementacyjna jest miarą dojrzałości technologicznej. W nadchodzących latach niemal każda organizacja będzie w stanie wytwarzać więcej kodu niż dawniej. To nie będzie przewaga. Przewagą stanie się zdolność do utrzymywania prostoty tam, gdzie inni produkują chaos. Zdolność do budowania systemów o jasnych kontraktach, spójnych modelach stanów, przewidywalnych wzorcach obsługi błędów i ograniczonej liczbie wyjątków.
Drugim koniecznym krokiem jest potraktowanie architektury na serio, nie jako ozdobnika do slajdów zarządczych, lecz jako mechanizmu obronnego przeciwko entropii. W epoce taniego kodu architektura przestaje być luksusem. Staje się koniecznością operacyjną. Jeżeli organizacja nie zdefiniuje twardych reguł dotyczących granic usług, modelu danych, zasad wersjonowania, retry, idempotencji, telemetrii, autoryzacji i degradacji usług, sztuczna inteligencja bardzo chętnie wypełni tę pustkę lokalnie sensownymi, ale globalnie niespójnymi rozwiązaniami.
Trzecim krokiem jest radykalne wzmocnienie procesu walidacji. Skoro kod będzie powstawał szybciej, to znacznie szybciej musi też działać system jego kwalifikowania. Nie chodzi tylko o klasyczne testy jednostkowe. Potrzebne będą testy kontraktowe, testy end-to-end, testy odpornościowe, testy bezpieczeństwa, testy migracyjne, testy spójności semantycznej oraz testy zachowania systemu w warunkach degradacji. W świecie sztucznej inteligencji podstawową kompetencją przestaje być samo tworzenie zmian. Podstawową kompetencją staje się zdolność do szybkiego i wiarygodnego wykrywania tych zmian, które nie powinny wejść na produkcję.
Czwartym krokiem jest zmiana kultury odpowiedzialności. Kod generowany przez sztuczną inteligencję nie może być traktowany jako coś domyślnie poprawnego tylko dlatego, że wygląda profesjonalnie i kompiluje się bez błędów. Taki kod powinien być traktowany dokładnie tak samo jak komponent pochodzący z zewnętrznego źródła: jako potencjalnie użyteczny, ale wymagający rygorystycznej kwalifikacji. Każda zmiana musi być oceniana nie tylko pod kątem tego, czy działa, ale także pod kątem tego, jakie nowe sprzężenia wprowadza, jakie stany pośrednie tworzy, jak zachowuje się przy awarii zależności oraz czy nie narusza podstawowego modelu domenowego.
Piątym i być może najważniejszym krokiem jest odzyskanie zdolności do mówienia „nie”. Branża przez lata cierpiała na chroniczny brak dyscypliny w odrzucaniu zmian, które nie powinny trafić do systemu. Jeżeli sztuczna inteligencja dodatkowo obniży koszt implementacji, to pokusa akceptowania wszystkiego stanie się jeszcze większa. Tymczasem jakość nie poprawia się wtedy, gdy organizacja umie szybko zbudować każdą funkcję. Jakość poprawia się wtedy, gdy organizacja potrafi skutecznie odfiltrować te funkcje, które nie są warte swojego kosztu złożoności.
To prowadzi do wniosku, który dla części branży może być niewygodny. Epoka sztucznej inteligencji nie będzie triumfem programowania rozumianego jako produkcja kodu. Będzie testem dojrzałości inżynierii rozumianej jako zarządzanie złożonością. Firmy, które pomylą te dwie rzeczy, najprawdopodobniej wygenerują ogromne ilości kodu, a wraz z nim ogromne ilości niestabilności. Firmy, które zrozumieją różnicę, mogą realnie poprawić jakość swoich produktów.
Jeżeli więc dziś użytkownik widzi bank, który nie potrafi poprawnie pokazać historii operacji, albo platformę handlową, która nie potrafi ustabilizować płatności, to nie patrzy na brak technologii. Patrzy na skutek wieloletniej utraty kontroli nad złożonością. I dokładnie od tego punktu trzeba zacząć rozmowę o przyszłości jakości oprogramowania.
Nie od pytania, czy sztuczna inteligencja potrafi napisać kod.
Od pytania, czy człowiek i organizacja nadal potrafią narzucić temu kodowi porządek.