Inżynier, który nie używa AI, jest nieefektywny. Rozmawiamy z szefem rozwoju w Snowflake

Warszawskie centrum Snowflake zatrudnia inżynierów pracujących nad produktami używanymi przez tysiące firm na całym świecie. To stąd widać wyraźnie, jak AI przebudowuje nie tylko narzędzia pracy, ale też jej organizację, podział ról i oczekiwania wobec specjalistów. Projekty, które wymagały półrocznej pracy dziesięcioosobowego zespołu, realizuje dziś pięć osób w cztery miesiące. Granica między backendem a frontendem rozmywa się, a od programistów coraz częściej oczekuje się myślenia produktowego.

Rozmawiamy z Michałem Gdakiem (na zdjęciu poniżej) o tym, jak zmienia się rynek pracy dla juniorów i seniorów, czym jest forward deployed engineer i dlaczego feedback od klienta staje się ważniejszy niż kiedykolwiek wcześniej. W tle przewija się też odwieczne pytanie: czy AI odbierze pracę programistom, czy tylko zmusi ich do zmiany tego, jak pracują?

Karol Kopańko: Kierujesz pracą inżynierów w waszym warszawskim centrum. Jak zmienia się ona pod wpływem AI?

Michał Gdak, AI R&D Director i Warsaw Site Lead w Snowflake: W marcu zeszłego roku mieliśmy serię meetupów. Mówiłem tam o vibe codingu, do którego wszyscy podchodzili z przymrużeniem oka. Dziś pracownik, który nie wspomaga się AI, jest po prostu nieefektywny.

Ile kodu dziś generujecie z AI?

Nie wiem, czy da się to dokładnie zmierzyć, ale nie ma inżyniera, który nie używa Cursora. Wszystko, co produkujemy, w większym bądź mniejszym stopniu jest generowane z pomocą LLM-ów.

Jak wpływa to na pracowników?

Poprzeczka idzie w górę. Dotychczas mogłeś być inżynierem, który po prostu siada i koduje. W zespole miałeś dziesięciu innych specjalistów i dowoziłeś nową funkcję przez pół roku. Teraz ten sam projekt robi pięć osób w cztery miesiące. Wszystko przyspiesza.

Ba, dziś pojedynczy pracownicy biorą na siebie zadania od A do Z. Podam przykład z tworzenia wskaźnika pewności dla modeli. Samo w sobie nie jest to trywialne zadanie, bo w grę wchodzi zaprojektowanie logiki, jej implementacja, kalibracja systemu i dostarczenie rozwiązania. Tym wszystkim zajmuje się jedna osoba.

Więc podział na backendowca i frontendowca odchodzi do lamusa?

Jest tego coraz mniej. Oczywiście zawsze istniała i dalej istnieje specjalizacja, bo systemy są złożone i nie każdy zna się na wszystkim, ale przechodzimy od "potrzebuję dwóch tygodni onboardingu" do "potrzebuję czterech godzin na implementację".

Skoro LLM potrafi wytworzyć kod, od programistów oczekuje się myślenia produktowego i zrozumienia potrzeb rynku. Nie mogą zwracać się do swojego PM-a z każdą wątpliwością, bo ten PM dotychczas zarządzał dziesięcioma ficzerami, a skoro wszystko przyspieszyło, to teraz zajmuje się dwudziestoma.

Jak wpływa to na rynek pracy? Czy zmienia się zapotrzebowanie - mniej juniorów, więcej seniorów?

Zatrudniamy w Warszawie około dwudziestu stażystów rocznie, ale liczba ofert pracy na rynku jest mniejsza. Ludzie rzadziej rotują między firmami i po raz pierwszy w tym wieku spadła liczba chętnych na studia programistyczne na MIT.

A myśleliśmy, że eldorado się nie skończy...

Rynek po prostu się nasyca.

A sam nie musisz skalować zatrudnienia w dół?

Nie, ponieważ problem braku nowych funkcji do dowiezienia jest mi obcy. Nie czuję też, abym musiał skalować w górę, żeby dostarczać więcej. Ważniejsze jest zwiększenie produktywności i praca bliżej klienta.

Właśnie! Zauważyłem, że na waszych stronach karier pojawiła się oferta pracy dla forward deployed engineera. Kto to taki?

To inżynier, który pracuje bardzo blisko klienta. Na tyle blisko, że może nawet wpływać na kierunek rozwoju produktu na podstawie jego wymagań. To zupełnie inne podejście niż klasyczny pre-sales czy konsulting.

Mam zresztą osobisty stosunek do tej metody, bo FDE działają podobnie do tego, jak budowałem swój startup, który później kupił Snowflake. Kiedy rozwijasz firmę, starasz się zadowolić każde życzenie klienta - prototypujesz, zdobywasz feedback i iterujesz, a potem sprzedajesz. Następnie cały zespół zajmuje się porządną implementacją w produkcie.

Takie podejście ma przewagę w stosunku do integratorów systemowych. Jesteś bliżej produktu, widzisz jego braki i możesz coś naprawdę zmienić. Integrator systemowy tego nie może, bo produkt nie należy do niego.

Ten feedback jest tak ważny?

Im większa firma, tym dłuższa ścieżka od wymyślenia produktu do jego wykorzystania przez klienta. Snowflake nie jest gigantyczną firmą (mamy nieco ponad dwa tysiące inżynierów oprogramowania), ale wśród gigantów tech inżynier może budować coś przez pół roku, żeby potem się dowiedzieć, że nikt z tego nie korzysta. FDE skraca tę ścieżkę.

Kto dobrze radzi sobie w tej roli?

Dobry FDE łączy umiejętności techniczne z miękkimi. Musi być "twarzą Snowflake'a" na spotkaniach.

Stereotypowo osoby techniczne są postrzegane jako mające słabsze umiejętności miękkie. Czy to nie jest wyzwanie rekrutacyjne?

Wbrew pozorom nie. Kiedy pracujesz z ambitnymi ludźmi, którzy świadomie wybierają tę rolę, uczą się bardzo szybko. Miałem sytuację, w której przez dwa tygodnie mój pracownik nie odezwał się do klienta ani słowem. Zero. A w trzecim tygodniu sam pojechał, poprowadził spotkanie i doprowadził cały projekt do końca. Sam przyznał, że był w szoku, jak dobrze sobie poradził.

Dziś sama wiedza inżynierska już nie wystarczy. Bez umiejętności pracy z klientem nie zrobi się kolejnego kroku w karierze. Dlatego szukamy ludzi, którzy chcą rosnąć wraz z jej rozwojem.

Szukacie tzw. A-playerów - wyróżniających się specjalistów?

Dario Amodei mówił o tym jakieś dwa lata temu w wywiadzie u Lexa Fridmana: on woli mieć dwustu A-playerów niż sześciuset pracowników, wśród których jest dwustu bystrzaków i czterystu przeciętniaków. Gdy masz odpowiednią gęstość intelektu i głód postępu, dużo łatwiej dowozi się projekty.