Od kilkunastu lat działam w branży technologicznej, głównie przy projektach enterprise, i w tym czasie zdążyłem zobaczyć kilka trendów, które miały zmienić wszystko. Były mikroserwisy, chmura, low-code, automatyzacja procesów, czy blockchain. Na początku pojawiała się euforia, za którą szły kolejne obietnice i konferencyjne case studies. Z czasem przychodziło lekkie rozczarowanie, aż w końcu technologia po prostu zostawała z nami, i po cichu zaczynała zmieniać sposób, w jaki pracujemy. Ze sztuczną inteligenecją jest podobnie, z jedną istotną różnicą - tym razem cicha zmiana, która zostanie na dłużej, nie dzieje się tam, gdzie wszyscy patrzą.
Dyskusja o AI w technologii skupia się dziś niemal wyłącznie na produktywności. O ile szybciej programista napisze kod? O ile skróci się projekt? Czy aplikację, której stworzenie kiedyś zajmowało pół roku, dziś da się zbudować w sześć tygodni? To naturalne pytania, bo efekty widać gołym okiem. Im dłużej jednak pracujemy w ten sposób, tym mocniej jestem przekonany, że szybkość pisania kodu to tylko najbardziej widowiskowy fragment znacznie głębszej zmiany. Zmienia się ekonomia tworzenia technologii, a wraz z nią sposób podejmowania decyzji, budowania zespołów i definiowania tego, za co klient w ogóle będzie chciał płacić firmie technologicznej.
Postawię tezę, do której wrócę na końcu - za kilka lat nikt poważny nie będzie kupował oprogramowania enterprise, płacąc za godziny pisania kodu. Nie dlatego, że AI potrafi pisać kod, ale dlatego, że zmienia to, co w całym procesie jest naprawdę drogie.
Szybciej nie oznacza proporcjonalnie krócej
Warto zacząć od uporządkowania nieporozumienia, które coraz częściej pojawia się w rozmowach z klientami. AI rzeczywiście mocno przyspiesza tworzenie oprogramowania - projekty, które jeszcze niedawno planowaliśmy na rok czy dwa lata, dziś realnie dostarczamy w kilka miesięcy.
W praktyce inżynier nie pisze już kodu linijka po linijce, ale prowadzi równolegle kilku agentów - jeden tworzy implementację, drugi testy, trzeci dokumentację. Człowiek z kolei projektuje zadania, pilnuje architektury i weryfikuje rezultaty. Każda zmiana dotycząca danych klienta, bezpieczeństwa czy integracji pozostaje przy tym pod ludzką kontrolą.
Nie jest jednak tak, że jeśli developer wykonuje zadanie o 40% szybciej, cały projekt automatycznie skraca się o 40% - duże projekty tak nie działają. AI przyspiesza elementy mechaniczne, np. boilerplate, testy jednostkowe, dokumentację API czy powtarzalne migracje. To znaczna oszczędność czasu, ale nie wszystkie etapy projektu da się przyspieszyć w takim samym stopniu. Znacznie mniej spektakularnie wygląda tam, gdzie trzeba zrozumieć procesy biznesowe klienta, zdecydować, który z kilku kierunków jest właściwy, jakie ryzyko warto zaakceptować albo czy dany element w ogóle powinien powstać. Do tego dochodzą bezpieczeństwo, zgodność z regulacjami, migracje danych i dziesiątki decyzji, których nie da się sprowadzić do wygenerowania kolejnego fragmentu kodu. Mówiąc krótko - przyspiesza się wykonanie, nie przyspiesza się myślenie. A im szybsza staje się technologia, tym wyraźniej widać, że wąskim gardłem projektu coraz częściej jest decyzja.
Im tańsze staje się wykonanie, tym więcej kosztuje zła decyzja
To moim zdaniem jeden z najważniejszych, a jednocześnie najrzadziej omawianych efektów AI. Jeszcze kilka lat temu wiele firm miało pomysły, których nie realizowało, bo dział technologiczny nie miał na nie czasu ani zasobów. Roadmapa była pełna, budżet ograniczony, a zespoły zajęte na miesiące do przodu. Dziś prototyp można przygotować szybko, a hipotezę biznesową sprawdzić za ułamek dawnego kosztu. Firma, która wcześniej mogła przetestować dwa pomysły, dziś może sprawdzić dziesięć. Problem w tym, że AI pogłębia kwestię wyboru. Możemy znacznie szybciej stworzyć funkcję, automatyzację czy produkt, ale równie szybko stworzyć coś, czego nikt nie potrzebuje. Jeśli punkt wyjścia jest zły, szybciej po prostu dotrzemy w nieodpowiednie miejsce.
Widać to również w materiałach, które otrzymujemy od klientów. Z jednej strony ich jakość rzeczywiście wzrosła - briefy są lepiej przygotowane, wymagania bardziej precyzyjne, a pierwsze historyjki użytkownika powstają jeszcze przed pierwszym spotkaniem z naszym zespołem. Z drugiej pojawiło się zjawisko, które roboczo nazywamy „AI slopem” - dokumenty wyglądające profesjonalnie, często liczące kilkadziesiąt stron, ale pozbawione najważniejszego elementu jakim są realne decyzje. W takich dokumentach wszystko jest opisane, ale niczego naprawdę nie rozstrzygnięto. Brakuje liczb tam, gdzie powinny się pojawić, konkretów i zdań, z którymi można się nie zgodzić.
AI bardzo ułatwiło tworzenie materiałów, które wyglądają jak efekt głębokiej analizy, choć sama analiza niekoniecznie się wydarzyła. A im łatwiej będzie stworzyć coś, co wygląda profesjonalnie, tym większą wartość będą mieli ludzie, którzy potrafią ocenić jakość, a nie tylko formę.
Inżynier przyszłości będzie mniej pisał, a więcej decydował
Najłatwiej zobaczyć tę zmianę na przykładzie samych inżynierów. Kilka lat temu wartość dobrego programisty była mocno związana z umiejętnością pisania dobrego kodu. Dziś kod nadal ma znaczenie, ale rdzeń roli przesuwa się gdzie indziej - w stronę organizowania pracy agentów, dostarczania im właściwego kontekstu, rozbijania niejednoznacznych problemów biznesowych na precyzyjne zadania i, co najtrudniejsze, krytycznej oceny rezultatu. AI potrafi wygenerować rozwiązanie, które się kompiluje, przechodzi testy i na pierwszy rzut oka wygląda bardzo dobrze. Doświadczony inżynier wciąż musi jednak odpowiedzieć na pytania, których żaden test nie zada - czy to będzie skalowalne, bezpieczne i możliwe do utrzymania za dwa lata, i czy w ogóle rozwiązuje właściwy problem?
Najtrudniejsza w tym wszystkim jest umiejętność rozpoznania momentu, w którym agent brnie w złym kierunku. Widziałem doświadczonych deweloperów, którzy godzinami akceptowali kolejne sugestie, bo każda pojedyncza zmiana wyglądała sensownie, a ich suma prowadziła architekturę w ślepy zaułek. Rozpoznanie tego wymaga czegoś, czego żaden model nie da za darmo - doświadczenia w tym, jak wyglądają systemy, które później nie działają.
Organizacje urosną szybciej niż zatrudnienie
Podobne przesunięcie widać w innych rolach. Analityk biznesowy samodzielnie przygotowuje zapytania SQL i pierwsze diagramy przepływów, tester manualny w kilka dni wchodzi w automatyzację, project manager bez zaplecza technicznego analizuje dokumentację na poziomie, który wcześniej wymagał wsparcia developera. To zmienia sposób, w jaki rekrutujemy i prowadzimy onboarding, mniej patrzymy na to, ile ktoś już potrafi, a bardziej na to, jak szybko i krytycznie uczy się w towarzystwie agenta.
Dla zarządów płyną z tego dwa wnioski:
- wzrost firmy przestaje wymagać proporcjonalnego wzrostu zatrudnienia,
- spłaszczenie kompetencji tworzy presję na strukturę wynagrodzeń i ścieżki kariery, do której większość organizacji, łącznie z naszą, jeszcze się nie przygotowała.
Wraca pytanie: budować, czy kupować?
AI podważa też zasadę, którą przez ostatnią dekadę uznawaliśmy za oczywistą - nie buduj tego, co możesz kupić. Gotowe produkty SaaS były szybsze, tańsze i zdejmowały z firmy ciężar utrzymania technologii. Dziś koszt stworzenia niewielkiego, wyspecjalizowanego narzędzia spadł tak mocno, że ta kalkulacja wygląda zupełnie inaczej.
Firmy budują własnych agentów wspierających sprzedaż i realizację projektów, automatyzują kontrolę jakości, tworzą narzędzia do raportowania czy asystentów wdrażania nowych pracowników, korzystających z wewnętrznej dokumentacji. Projekty, które jeszcze kilka lat temu nie dostałyby osobnego budżetu, dziś mogą powstać w tydzień dzięki dwuosobowemu zespołowi.
I właśnie tutaj może powstawać realna przewaga. Sam dostęp do modelu nią nie będzie, podobne modele będzie miał każdy. Przewagę daje ich połączenie z tym, czego konkurencja nie ma - własnymi procesami, danymi, kontekstem klientów i historią decyzji. Łatwość budowania ma jednak swoją pułapkę. Prototyp może powstać w tydzień, ale jeśli pół roku później korzystają z niego dziesiątki osób i przetwarza dane klientów, przestaje być eksperymentem, a staj się systemem, za który ktoś odpowiada.
Koniec sprzedawania godzin
Dla firm technologicznych ta zmiana ma jeszcze jeden, bardzo konkretny wymiar - pieniężny.
Przez lata spora część rynku działała w modelu, w którym klient kupował czas specjalistów, a wartość kontraktu była pochodną nakładu pracy. Sztuczna inteligencja podważa ten model, ponieważ kiedy czas potrzebny na wykonanie spada, a wartość dostarczana klientowi nie - godziny przestają być dobrym przybliżeniem wartości. Klienci są tego świadomi i sami korzystają z AI, więc coraz częściej pytają jaki jest realny koszt dostarczenia i utrzymania tego rozwiązania w perspektywie trzech lat.
Odpowiedzią, do której dochodzimy jako branża, są modele oparte na rezultacie i przejętym ryzyku. W praktyce oznacza to trzy zmiany:
- po pierwsze, wycenę od wartości biznesowej rozwiązania i gwarantowanych rezultatów, a nie od stawki razy liczba osobodni,
- po drugie, wyceniony komponent ryzyka - bierzemy na siebie odpowiedzialność za poprawność, bezpieczeństwo i zgodność systemu,
- po trzecie, marżę przestaje definiować arbitraż na kosztach pracy, a zaczyna ją definiować własność procesu.
Nie oznacza to końca time & material, który nadal ma sens tam, gdzie zakres jest zmienny i nie da się z góry przewidzieć wymagań. Oznacza natomiast, że każda firma technologiczna będzie musiała odpowiedzieć sobie, co właściwie sprzedaje. Jeśli odpowiedzią jest wyłącznie czas developerów, AI faktycznie jest zagrożeniem. Jeśli odpowiedzią jest zrozumienie biznesu klienta, zaprojektowanie właściwego rozwiązania oraz wzięcie odpowiedzialności za rezultat, sytuacja wygląda zupełnie inaczej.
Prawdziwa przewaga nie będzie polegała na "posiadaniu AI"
Za kilka lat informacja, że firma wykorzystuje AI nie będzie się wyróżniać. Dlatego znacznie bardziej interesuje mnie pytanie - co organizacja potrafi dzięki AI robić lepiej? Czy szybciej testuje pomysły? Lepiej wykorzystuje dane? Buduje własne narzędzia wokół unikalnych procesów? Zwiększa skalę bez proporcjonalnego rozbudowywania struktury?
Trwała przewaga nie będzie wynikać z wyboru konkretnego modelu AI, te będą zmieniać się zbyt szybko. Będzie wynikać z tego, jak organizacja buduje procesy, kompetencje, zasoby danych i kulturę weryfikacji, które pozwalają szybko wykorzystywać kolejne generacje modeli, jednocześnie zachowując kontrolę nad jakością, ryzykiem i sposobem ich wykorzystania.
Gdybym dziś patrzył na organizację w perspektywie trzech do pięciu lat, zacząłbym od tego, gdzie w naszym biznesie technologia była dotychczas ograniczeniem, których pomysłów nie realizowaliśmy ze względu na koszt, jakie kompetencje siedzą zamknięte w silosach i co posiadamy jako firma, czego konkurent nie skopiuje. Dopiero potem zastanawiałbym się, jak połączyć to z AI.
Największa zmiana jest prosta- technologia przestaje być największą barierą w budowaniu cyfrowego biznesu. Łatwiej będzie budować i generować rozwiązania, ale nadal trzeba będzie wiedzieć, co budować i jak ocenić, czy działa. Kod tanieje, a zrozumienie problemu zyskuje na wartości, dlatego płacenie za godziny pisania kodu będzie tracić sens, a o sukcesie projektów enterprise zdecydują przede wszystkim doświadczenie, znajomość biznesu, trafne decyzje i odpowiedzialność za ich skutki.
