Salesforce stawia na mniej kodu – co to zmienia

Ponad 365 pomysłów z IdeaExchange trafiło do realizacji w ciągu ostatniego roku, a najważniejszy sygnał z TDX 2026 jest prosty: Salesforce chce ograniczać zależność platformy od tradycyjnego kodu (Salesforce Ben). Dla praktyków to nie jest marketingowy detal, tylko wskazówka architektoniczna na najbliższe kwartały. Jeśli roadmapa rzeczywiście ma premiować Flow, lepsze API i headless access do funkcji platformy, to decyzje o nowych customizacjach w Apex i LWC trzeba podejmować ostrożniej. Szczególnie teraz, gdy AI może przyspieszyć development, ale równie łatwo zwiększyć bałagan w orgu.

Mniej kodu jako kierunek platformy, nie chwilowe hasło

Najmocniejsza deklaracja z sesji True to the Core dotyczyła ograniczania ilości kodu. Chodzi nie tylko o klasyczne low-code, ale o szersze podejście do utrzymania orgów w czasie, gdy AI zaczyna generować coraz więcej artefaktów developerskich. W praktyce problem nie polega na samym tworzeniu kodu, lecz na jego późniejszym utrzymaniu, testowaniu, dokumentowaniu i dopasowywaniu do zmian release’owych.

To dobrze wpisuje się w kierunek, w którym Salesforce dalej inwestuje w Flow. Zapowiedź jest jasna: narzędzia declarative mają być rozwijane, natomiast istniejący złożony Apex u klientów nie będzie modernizowany centralnie. Dla zespołów oznacza to konieczność rozdzielenia dwóch porządków. Pierwszy to legacy, które trzeba utrzymać odpowiedzialnie. Drugi to nowe wdrożenia, gdzie domyślnym wyborem coraz częściej powinien być mechanizm bez kodu albo z minimalną ilością kodu.

Nie oznacza to końca roli developera. Oznacza raczej zmianę miejsca, w którym developer wnosi największą wartość – mniej w prostych automatyzacjach, bardziej w architekturze, integracjach, jakości danych i kontroli nad złożonością. W tym kontekście rośnie znaczenie podejścia, które już widać przy rozwoju Flow Orchestration jako standardowego typu Flow: platforma próbuje przenieść coraz większą część logiki biznesowej do warstwy łatwiejszej w utrzymaniu.

Praktyczny wniosek dla polskich orgów jest prosty. Każdy nowy requirement warto dziś filtrować pytaniem: czy ten przypadek naprawdę wymaga Apex, czy tylko przyzwyczailiśmy się do kodowania? Jeśli odpowiedź nie jest jednoznaczna, trzeba policzyć koszt utrzymania za 2-3 release’y, a nie tylko koszt dostarczenia w tym sprincie.

Headless 360 i core platform mają rosnąć równolegle

Drugim istotnym sygnałem jest Headless 360 – projekt, w którym elementy Salesforce mają być dostępne jako API, narzędzia MCP oraz komendy CLI dla agentów. MCP oznacza tu model kontekstowego wywoływania narzędzi przez AI, a CLI pozostaje istotne dla zespołów budujących automatyzację i procesy developerskie. To ważne, bo pokazuje, że Salesforce chce otworzyć funkcje platformy na nowe sposoby użycia, nie zamykając ich w klasycznym UI.

Jednocześnie padła wyraźna deklaracja, że headless nie ma być wymówką do zaniedbania interfejsów. To istotne z perspektywy adminów i konsultantów, którzy od miesięcy obserwują napięcie między inwestycjami w Agentforce i Data Cloud a oczekiwaniami wobec bazowej platformy. Obawy społeczności są konkretne: Known Issues ciągnące się latami, problemy z plikami i obiektami powiązanymi, limity oraz koszty danych, a także niedokończone obszary migracji z Classic do Lightning.

W praktyce oznacza to, że architektura Salesforce będzie coraz bardziej dwutorowa. Z jednej strony rośnie warstwa headless i agentowa. Z drugiej strony organizacje nadal potrzebują stabilnego, przewidywalnego core, który da się administrować bez obchodzenia ograniczeń platformy. Dlatego przy planowaniu nowych rozwiązań AI warto patrzeć szerzej niż na samo demo agenta. Jeśli fundamentem są słabe metadane, niespójne dane i nierozwiązane problemy w core, to nawet najlepszy interfejs agentowy nie poprawi jakości działania.

Ten kierunek dobrze łączy się z szerszą zmianą opisaną przy otwieraniu metadata layer dla AI w Spring ’26. Im więcej funkcji Salesforce będzie dostępnych programowo dla agentów, tym większego znaczenia nabierze governance, kontrola uprawnień i przewidywalność zachowania platformy.

Administrator nie znika – rośnie znaczenie danych i metadanych

Wątek przyszłości administratorów został postawiony dość jednoznacznie: automatyzacja może przejąć część zadań, ale nie zmniejsza potrzeby posiadania adminów. Zmienia natomiast profil tej roli. Skuteczne wsparcie AI wymaga lepszej jakości metadanych i danych systemowych, a to właśnie obszar, w którym admin, analityk i architekt mają dziś największy wpływ na powodzenie wdrożeń.

To ważne także dla osób wchodzących do ekosystemu. Zamiast czekać na idealną pierwszą rolę stricte salesforce’ową, sensowną ścieżką ma być praca przylegająca do platformy – w zespołach korzystających z Salesforce na co dzień. Taki start buduje rozumienie procesów, danych i realnych ograniczeń orga, czyli kompetencji trudniejszych do zastąpienia niż sama znajomość ekranu Setup.

Równolegle Trailhead ma być bardziej dostępny bezpośrednio w miejscu pracy, także przez Slack. To nie jest drobna zmiana edukacyjna. Jeśli nauka i guidance wejdą do codziennego workflow, wzrośnie znaczenie uczenia kontekstowego – dokładnie tam, gdzie użytkownik wykonuje zadanie. W połączeniu z agentami może to skrócić drogę od pytania do wykonania akcji, ale tylko wtedy, gdy org ma uporządkowane nazewnictwo, role, uprawnienia i logikę procesów.

Dla praktyka oznacza to trzy priorytety. Po pierwsze, warto ograniczać nowy dług techniczny, zwłaszcza ten generowany szybko przez AI. Po drugie, trzeba porządkować metadane i dane, bo to one staną się paliwem dla kolejnych warstw automatyzacji. Po trzecie, nie wolno ignorować starych problemów platformy – od offline po pliki i Known Issues – bo to właśnie one najczęściej decydują, czy ambitna roadmapa działa w prawdziwym orgu. Ten sam problem widać też w dyskusji o długu technicznym napędzanym przez vibe-coding, gdzie szybkość budowy łatwo zamienia się w koszt utrzymania.

Najważniejszy wniosek z TDX 2026 jest więc dość trzeźwy: Salesforce nie odwraca się od AI, ale próbuje ustawić ją na fundamencie mocniejszego core i mniejszej ilości kodu. Pytanie brzmi, czy tempo naprawiania starych problemów nadąży za tempem dokładania nowych warstw platformy. Dla adminów, devów i architektów to dobry moment, by zrewidować własne standardy budowy orga. Gdzie w waszym środowisku kod nadal daje przewagę, a gdzie stał się już tylko kosztownym nawykiem?