AI coding agents w Salesforce: sygnał dla zespołów

Około 15 tys. inżynierów, niemal bez wzrostu zatrudnienia od 2024 roku, to mocny sygnał, że AI coding agents zaczynają realnie wpływać na model budowy oprogramowania w Salesforce (Times of India). Dla praktyków platformy ważne jest nie samo hasło o AI, ale zmiana proporcji między liczbą ludzi a wolumenem pracy, który firma chce dowieźć. Jeśli kod coraz częściej powstaje z udziałem agentów, rośnie znaczenie kontroli, nadzoru i odpowiedzialności za wynik. To zmienia oczekiwania wobec developerów, architektów i liderów delivery także poza samym Salesforce.

Mniej hiringu inżynierów nie oznacza końca roli developera

Najważniejszy komunikat nie brzmi: inżynierowie przestają być potrzebni. Brzmi raczej: ich praca przesuwa się z ręcznego wytwarzania w stronę zarządzania systemem produkcji kodu wspieranego przez modele AI. Marc Benioff wskazał, że Salesforce przez ostatnie dwa lata prawie nie zatrudniał nowych inżynierów, a liczba osób w engineeringu pozostała w większości płaska. Jednocześnie podkreślił, że modele nie działają jeszcze autonomicznie i nadal wymagają człowieka.

Dla zespołów Salesforce to bardzo praktyczna zmiana. Developer nie jest już tylko wykonawcą ticketów w Apex czy LWC. Coraz częściej staje się operatorem i recenzentem pracy agentów, którzy generują fragmenty kodu, pomagają w refaktoryzacji albo przyspieszają tworzenie rozwiązań. To oznacza większy nacisk na jakość promptów, walidację wyniku, bezpieczeństwo oraz umiejętność rozpoznania, kiedy sugestia modelu nadaje się do wdrożenia, a kiedy podnosi ryzyko techniczne.

W tym modelu rośnie znaczenie kompetencji, które wcześniej bywały traktowane jako drugorzędne – architektury, code review, testów, governance i obserwowalności. To spójne z szerszym ruchem na rynku, gdzie coraz mniej chodzi o samo „pisanie szybciej”, a bardziej o to, kto kontroluje jakość i odpowiedzialność za efekt. W praktyce podobny kierunek widać też w dyskusji o luce między obietnicą a wdrożeniem AI, którą opisaliśmy przy różnicy między demo Agentforce a produkcją.

Co z tym zrobić w polskim zespole Salesforce? Po pierwsze, nie planować rozwoju kompetencji wyłącznie wokół składni i frameworków. Po drugie, wzmacniać role odpowiedzialne za kontrolę jakości kodu i decyzje architektoniczne. Po trzecie, mierzyć produktywność szerzej niż liczbą story pointów – także przez czas dostarczenia, liczbę poprawek i stabilność wdrożeń.

AI przejmuje część zadań, ale budżet i headcount idą tam, gdzie nadal potrzebny jest człowiek

Równolegle Salesforce przesuwa zasoby do sprzedaży. Benioff wskazał, że dziś najgorętsze rekrutacje nie dotyczą inżynierów, lecz ról sprzedażowych, a funkcje wymagające bezpośredniej komunikacji z klientem pozostają mocno ludzkie. To ważny kontrast: AI może przejąć część kodowania i wsparcia, ale nie zastępuje jeszcze relacji, negocjacji i prowadzenia wzrostu.

Widać to także po cięciach w support. W ubiegłym roku firma zredukowała około 4 tys. ról wsparcia, a ich obowiązki przejęły agenty AI. To nie jest już eksperyment laboratoryjny, tylko zmiana kosztowa i operacyjna. Dla adminów i konsultantów oznacza to, że projekty AI będą coraz częściej oceniane nie przez atrakcyjność demo, lecz przez twarde pytania: które zadania znikają, jakie role zmieniają zakres i jak policzyć koszt działania modeli.

Tu szczególnie istotny jest plan wydania 300 mln USD w 2026 roku na tokeny Anthropic. To pokazuje, że część budżetu przesuwa się z klasycznego hiringu na zużycie modeli. Dla organizacji korzystających z Salesforce to cenna lekcja – koszt AI nie kończy się na licencji. Obejmuje też wykorzystanie modeli, routing zapytań, kontrolę jakości i nadzór nad tym, gdzie automatyzacja naprawdę daje zwrot. Ten wątek szerzej rozbieraliśmy w analizie 300 mln USD na tokeny Anthropic.

Praktyczny wniosek jest prosty: jeśli zespół wdraża AI do developmentu albo service, musi równolegle budować model odpowiedzialności. Kto akceptuje wynik agenta? Kto mierzy błędy? Kto decyduje, czy tańszy jest kolejny etat, czy kolejna pula tokenów? Bez takich odpowiedzi łatwo wpaść w pułapkę pozornej oszczędności.

Warto też patrzeć szerzej niż na sam development. Skoro Salesforce pokazuje, że automatyzacja najpierw obniża koszty, a potem ma wspierać wzrost, to podobny porządek myślenia ma sens w wielu orgach. Najpierw uporządkowanie procesu, potem automatyzacja, a dopiero później skalowanie. Ten schemat dobrze uzupełnia analiza, jak przejść od oszczędności AI do wpływu na revenue.

Salesforce nie pokazuje więc świata bez inżynierów, tylko świat z inną ekonomią pracy technicznej. Mniej liczy się sama liczba osób, bardziej – zdolność jednego zespołu do kontrolowania większej ilości pracy wykonywanej wspólnie z agentami. Pytanie dla praktyków brzmi nie czy AI wejdzie do delivery, ale jak ustawić role, metryki i odpowiedzialność, żeby ten model nie pogorszył jakości systemu.