Przez lata produktywność inżyniera oprogramowania była w dużej mierze kojarzona z jego umiejętnością tworzenia dobrego kodu. Innymi słowy: modele będą coraz bardziej powszechne, ale to kontekst pozostanie tym, co nadaje im realną wartość. Dlatego ten punkt ciężkości zaczyna się przesuwać. Nie dlatego, że kod przestaje być ważny, ale dlatego, że dzięki generatywnej AI można tworzyć go znacznie szybciej. W efekcie coraz częściej wąskim gardłem projektu nie jest już sama implementacja. Jest nim dobre zdefiniowanie problemu. Wyzwaniem jest wiedza, która w wielu organizacjach pozostaje rozproszona i nieskodyfikowana. AI może pomóc ją uporządkować, wydobyć i udostępnić tam, gdzie jest potrzebna. Autorem komentarza jest Michał Gdak, AI R&D Director i Warsaw Site Lead w Snowflake.
To fundamentalna zmiana. Jeżeli stworzenie kolejnej wersji aplikacji, pipeline’u danych czy prototypu zajmuje godziny lub dni zamiast tygodni, to przewaga inżyniera nie polega już tylko na tym, że potrafi szybciej przełożyć specyfikację na kod. Coraz większą wartość ma osoba, która potrafi wcześniej zakwestionować samą specyfikację: zrozumieć, czego właściwie potrzebuje użytkownik, jakie dane są dostępne, jak rozwiązanie powinno działać w istniejącej architekturze i po czym poznamy, że rzeczywiście przyniosło oczekiwany efekt.
Programista, analityk i konsultant w jednej osobie
W praktyce jedna osoba coraz częściej prowadzi zadanie od początku do końca. W projektach realizowanych dla klientów granica między backendem a frontendem przestaje istnieć. Narzędzia AI dodatkowo skracają czas potrzebny na wejście w nieznany fragment systemu czy pracę poza własną specjalizacją. Jednocześnie zespoły mogą równolegle realizować więcej zadań, a przede wszystkim znacznie szybciej i niższym kosztem testować nowe produkty, kolejne ich wersje i sprawdzać, czy rzeczywiście odpowiadają na potrzeby rynku.
Inżynier nie może więc konsultować każdej decyzji z menedżerem produktu. Musi samodzielnie myśleć także o produkcie, jego zastosowaniu i rezultacie, który ma przynieść.
Dobrze widać to przy wprowadzaniu nowego produktu na rynek. Samo zbudowanie jego pierwszej wersji jest dziś coraz łatwiejsze. Trudniejsze staje się zrozumienie, jaki problem produkt ma rozwiązać, dla kogo jest i czy rzeczywiście odpowiada na potrzeby rynku. Inżynier coraz częściej uczestniczy więc nie tylko w tworzeniu technologii, ale też w jej ocenie z perspektywy użytkownika. Musi rozumieć rynek, na którym działa produkt i potrafić ocenić konsekwencje podejmowanych decyzji.
Żeby właściwie ustawić ten próg, inżynier musi przeanalizować dane jak analityk, ale też zrozumieć proces biznesowy i odpowiedzieć na pytanie, ile organizację kosztuje błąd, a ile ręczna kontrola. W tym momencie decyzja przestaje być wyłącznie techniczna i zaczyna wymagać także myślenia charakterystycznego dla konsultanta. Kolejną kwestią jest konieczność zmiany mentalności menedżerów w firmach: przejścia od automatyzacji opartej na regułach do automatyzacji opartej na prawdopodobieństwie.
Tę zmianę dobrze widać także w inżynierii danych. Raport MIT Technology Review Insights przygotowany we współpracy ze Snowflake pokazuje, że 72 proc. menedżerów technologicznych uważa inżynierów danych za kluczowych dla sukcesu firmy, a 77 proc. wskazuje, że zakres ich pracy rośnie. Przyszłość AI zaczyna się nie od modeli, ale od odpowiednio przygotowanych danych. Bez strategii danych nie ma strategii AI. Przybywa źródeł danych, zastosowań AI i procesów, które trzeba zasilać odpowiednimi informacjami. Nie da się odpowiadać na ten wzrost wyłącznie poprzez zwiększanie zespołów. Dlatego inżynier coraz rzadziej musi ręcznie budować każdy element przepływu danych, a coraz częściej projektuje architekturę, definiuje reguły i testy oraz nadzoruje pracę narzędzi wspieranych przez AI i wskazuje właściwe kierunki rozwoju biznesu. Zmierzamy w stronę autonomicznej inżynierii danych, w której agenci odpowiadają za tworzenie, utrzymanie i optymalizację produktów w całym cyklu, a rola człowieka skupia się przede wszystkim na podejmowaniu decyzji, nie na wykonywaniu każdego etapu procesu.
Zaprojektowanie odpowiednich zabezpieczeń i zasad kontroli staje się więc jednym z ważniejszych zadań inżyniera. Wdrażanie sztucznej inteligencji postępuje szybciej niż rozwój ram zarządzania, dlatego zaufanie, bezpieczeństwo i niezawodność powinny być traktowane jako integralna część rozwiązania, a nie jedynie dodatek.
Forward deployed engineer pokazuje, dokąd zmierza zawód
Najpełniej ten model pracy realizuje forward deployed engineer (FDE). To inżynier, który pracuje bezpośrednio z klientem, jego problemem i danymi. Nie dostaje gotowej listy wymagań. Najpierw ustala, jaki rezultat chce osiągnąć organizacja. Potem szybko buduje rozwiązanie, sprawdza je w docelowym środowisku i rozwija kolejne wersje.
FDE różni się od klasycznej roli przedsprzedażowej czy integracyjnej przede wszystkim zakresem odpowiedzialności. Nie ogranicza się do prezentacji istniejącego rozwiązania ani jego wdrożenia. Pracuje z klientem nad konkretnym problemem, a wiedza zdobyta podczas takiej współpracy może później wrócić do zespołu produktowego i wpłynąć na rozwój samego produktu.
Znam ten sposób pracy z czasów, gdy rozwijałem startup AI: prototyp, uwagi klienta, poprawka i dopiero potem sprzedaż. FDE rozmawia z użytkownikiem bez pośrednika, rozumie jego proces, buduje prototyp, pracuje na danych i ocenia ograniczenia technologii. Jednocześnie myśli o tym, czy rozwiązanie da się później skalować. Te kompetencje wkrótce będą potrzebne w większości ról technicznych.
Co to daje biznesowi
Dla firmy ta zmiana oznacza przede wszystkim szybsze wdrożenia. Projekt, który wcześniej wymagał 60 osobomiesięcy pracy, dziś może wymagać ich 20. Firma szybciej sprawdza, czy pomysł działa i szybciej rezygnuje z tych, które nie przynoszą oczekiwanego efektu.
Druga korzyść to krótsza droga od problemu do produktu. Gdy inżynier słyszy o problemie bezpośrednio od klienta, informacja nie musi przechodzić przez kilka kolejnych osób, zanim dotrze do zespołu technicznego. Prototyp powstaje blisko użytkownika, a jego uwagi szybciej wracają do zespołu odpowiedzialnego za rozwój produktu.
Trzecia korzyść to mniejsze zespoły zdolne do realizacji bardziej złożonych projektów. Jedna osoba z pomocą AI może dziś prowadzić zadanie, które wcześniej wymagało zaangażowania kilku specjalistów. Czwarta korzyść jest najrzadziej liczona: mniejsze ryzyko budowania funkcji, których nikt nie używa. Każda taka funkcja generuje podwójny koszt: pochłania pracę zespołu, a jednocześnie zabiera czas, który można było przeznaczyć na rozwiązanie rzeczywistego problemu użytkownika.
Czego powinni uczyć się przyszli inżynierowie
AI nie odbiera sensu nauce programowania. Zmienia odpowiedź na pytanie, po co ta umiejętność jest potrzebna. Bez znajomości języka trudno ocenić jakość wygenerowanego kodu, znaleźć błąd czy podjąć dobrą decyzję architektoniczną. Sama znajomość zasad programowania będzie jednak coraz słabszym wyróżnikiem na rynku pracy.
Przewagę dadzą trzy kompetencje. Pierwsza to rozkładanie niejasnego problemu na konkretne zadania. Druga to przede wszystkim dokładne zrozumienie problemu i zaproponowanie rozwiązania technicznego, które na niego odpowiada. O sukcesie AI w firmie decyduje bowiem znacznie mniej zaawansowanie samego modelu, a znacznie bardziej jakość, dostępność i sposób zarządzania danymi, na których się opiera. Trzecia to rozmowa z ludźmi, którzy nie są inżynierami oraz znajomość języka ich branży. Dwie ostatnie najszybciej rozwija praca nad projektem dla prawdziwego użytkownika, a nie zadanie na zaliczenie.
Inżynier przyszłości nie będzie więc programistą, który pisze kod dwa razy szybciej. Będzie osobą, która dzięki technologii weźmie odpowiedzialność za dużo większą część problemu. Dziś, gdy kod można wygenerować w kilka minut lub godzin, przewagą nie jest samo pisanie kolejnych linijek. Liczy się przede wszystkim wiedza, co warto zbudować i jaki problem ma to rozwiązać.
