AI przyspiesza, ale legacy zostaje. 2026 będzie rokiem długu technicznego

Polskie organizacje na Salesforce wchodzą w 2026 z rosnącą presją na wdrażanie AI, ale równolegle z rekordowym nagromadzeniem długu technicznego. W wielu orgach pojawia się paradoks: narzędzia takie jak Agentforce Vibes pozwalają budować szybciej niż kiedykolwiek, lecz jakość danych i architektury nie nadąża za tempem. Efekt to projekty AI, które nie skalują się lub wręcz destabilizują istniejące procesy. 

Vibe-coding tworzy nowy typ długu technicznego

Vibe-coding, czyli generowanie komponentów, Flow, Apex i konfiguracji na podstawie naturalnego języka, stało się najczęściej używaną ścieżką tworzenia funkcjonalności w nowych orgach. Jak zauważa Paul Battisson w rozmowie z SF Ben, możliwość tworzenia szybciej nie oznacza automatycznie tworzenia lepiej. Mechanizm Vibes działa na metadanych, przeszukując je i generując zmiany oparte o statystyczne dopasowanie do istniejącej architektury, co w organizacjach pełnych historycznych konfiguracji prowadzi do powielania przestarzałych wzorców. Automatyzacja recenzji metadanych pomaga, ale nie rozwiązuje problemu ich jakości.

Technicznie rzecz biorąc, Agentforce Vibes operuje na zestawach metadanych pobieranych przez MCP i interpretuje je w kontekście istniejącej struktury obiektów, Flow i Apex. Jeśli dane są niespójne lub architektura nie ma klarownych naming conventions, model generuje komponenty dokładnie w takim duchu, w jakim została zbudowana historyczna org – często chaotycznie. W polskich firmach, gdzie część systemu była tworzona przed wdrożeniem CI/CD, vibe-coding nieuchronnie wzmacnia starsze antywzorce.

Dla praktyków oznacza to powstawanie tzw. compound debt: stary dług techniczny zostaje nadbudowany nowymi elementami tworzonymi przez modele. Gdy do tego dojdzie automatyczne generowanie Flow i LWC, każde błędne założenie jest replikowane w wielu komponentach jednocześnie. To ryzyko przypomina to, co opisywaliśmy w analizie jak Agentforce Vibes buduje 80 procent aplikacji w 10 procent czasu, gdzie masowa produkcja logiki bez governance może zdestabilizować org szybciej niż ręczny development.

Trend jest jasny: w 2026 najszybciej rozrastającym się elementem długu technicznego nie będzie Apex, ale warstwa metadanych generowanych przez agentów. Firmy, które wchodzą w AI bez uprzedniego uporządkowania struktury danych i procesów, zauważą problemy dopiero przy próbie uruchomienia automatycznego reasoning w Agentforce 360.

Dane i architektura stają się barierą dla AI

Wartość AI w Salesforce jest ograniczona przez jakość danych – to temat, który powraca w każdym projekcie, ale według rozmówców cytowanych przez Salesforce Ben (źródło: Salesforce Ben) dopiero teraz staje się kluczowy. Modele Agentforce wymagają data fabric o wysokiej spójności, podczas gdy większość polskich orgów nadal opiera się na rozproszonych integracjach, duplikatach i logice procesowej rozlanej między Flow, Apex, PT i zewnętrzne usługi. AI potrafi zidentyfikować problem, ale nie naprawi źle zaprojektowanego modelu danych.

Od strony technicznej widać to wyraźnie w Data 360: system zakłada normalizację i harmonizację danych klientów przed uruchomieniem reasoning i scoringu. Gdy próbuje się wykonać agentowe automatyzacje na niespójnych rekordach, pojawiają się problemy z routingiem, deduplikacją i kontekstową interpretacją intencji użytkownika. W analizie architektury agentów w dużych organizacjach podkreślaliśmy, że AI wymaga spójnego data fabric, a nie kolejnych warstw automatyzacji.

W praktyce oznacza to, że polskie firmy, które deklarują chęć uruchomienia AI w sprzedaży lub service, zaczynają od końca. Automatyzacja działa poprawnie tylko wtedy, gdy dane są jednorodne i logiczne, a procesy zmapowane. Bez tego agent przetworzy dane takimi, jakie są, co w kontekście legacy sprowadza się do replikowania bałaganu. Firmy, które pominęły etap data readiness, zobaczą w 2026 nie tyle ROI z AI, co wysyp błędów operacyjnych.

Kontekst globalny potwierdza ten obraz: AI w CRM rozwija się szybciej niż możliwości przedsiębiorstw do utrzymania higieny danych. W Polsce dodatkowym ograniczeniem jest RODO i silne rozproszenie danych między systemy ERP, call center i zewnętrzne platformy e-commerce. AI nie obejdzie fundamentalnych barier architektury.

AI przyspiesza development, ale spowalnia organizacje

Vicki Moritz-Henry zwraca uwagę, że po 2025 weszliśmy w etap, gdzie największym ryzykiem nie jest brak adopcji AI, lecz adopcja zbyt szybka. Firmy generują nowe Flow, Apex i konfiguracje szybciej, niż zespoły są w stanie to udokumentować, zreviewować i przetestować. Modele robią 80 procent pracy, ale pozostałe 20 procent to manualne decyzje architektoniczne, które często nie są podejmowane. Rezultat to orgi z dużą ilością nowych funkcji, bez zrozumienia ich oddziaływania na limity, integracje czy procesy sprzedażowe.

Pod maską większości agentowych automatyzacji działa intensywne użycie MCP i interpretacji kontekstu, co wymaga dokładnych opisów procesów i poprawnych definicji pól. Jeśli nazwy obiektów są niejednoznaczne, agent może tworzyć logikę zależną od przypadkowych elementów orga, np. nieużywanych pól tekstowych, które model uzna za powiązane z procesem. Taki kod działa lokalnie, ale psuje spójność architektury.

Dla konsultantów i architektów w Polsce oznacza to konieczność zmiany podejścia do governance: code review nie wystarcza, bo dług techniczny powstaje na poziomie konfiguracji. Coraz więcej firm zaczyna wdrażać reguły AI governance podobne do tych stosowanych w CI/CD: kontrola naming conventions, blokady antywzorców Flow, walidacja semantycznych zależności między obiektami. To kierunek spójny z analizą, jaką prowadziliśmy w tekście o nowej roli admina w erze Agentforce, gdzie opisujemy przesunięcie kompetencji z konfiguracji na architekturę informacji.

Trend na 2026 jest jasny: organizacje będą miały więcej funkcji, ale mniejszą kontrolę nad ich pochodzeniem. AI przyspieszyło development, ale nie zlikwidowało długu technicznego – wręcz stworzyło nowe warstwy.

Strategia dla polskich orgów: low and slow zamiast AI panic mode

Gabie Caballero w rozmowie z Salesforce Ben mówi jasno: firmy, które wejdą w AI zbyt szybko, będą musiały wrócić i naprawiać własną architekturę po awariach operacyjnych (źródło: Salesforce Ben). W praktyce jest to cytat, który brzmi jak ostrzeżenie dla wielu polskich implementacji. Gdy agent tworzy błędne automatyzacje w service, czas odpowiedzi spada, ale rośnie liczba eskalacji i błędnych decyzji.

Technicznie oznacza to konieczność stworzenia warstwy kontrolnej przed każdą generacją metadanych: sandbox z pełnym kopiowaniem danych, testy E2E oraz walidatory logiki procesowej sterowane przez reguły. Salesforce zaczyna dostarczać narzędzia audytowe, ale ich skuteczność zależy od jakości procesów w firmie. Modele nie zrozumieją różnicy między obiektem, który jest legacy i powinien być usunięty, a obiektem, który jest kluczowy, ale rzadko używany.

Polskie organizacje mogą podejść do problemu podobnie jak do migracji danych przed wdrożeniem Data 360: najpierw higiena, potem automatyzacja. To wymaga trzech kroków: remediacja metadanych, ocena procesów pod kątem agent readiness oraz mechanizmy kontroli zmian generowanych przez AI. Jeśli te elementy zostaną wdrożone, agentowe automatyzacje zaczną działać stabilnie zamiast mnożyć błędów.

Kontrast globalny pokazuje, że firmy, które idą podejściem low and slow, osiągają lepsze ROI niż te, które używają AI do zastępowania ludzi bez przygotowania procesów. W 2026 to nie agentic AI będzie różnicą konkurencyjną, ale jakość fundamentów technicznych, na których agent pracuje.

Podsumowanie

Dług techniczny w Salesforce nie jest nowym problemem, ale vibe-coding i agentowe automatyzacje rozmnażają go szybciej, niż zespoły są w stanie reagować. AI nie naprawia błędów architektury, lecz je multiplikuje. Dla polskich orgów to moment, w którym trzeba przestać traktować dług jako poboczny temat i zacząć zarządzać nim strategicznie: najpierw dane i procesy, potem agentowe automatyzacje. Pytanie dla każdego architekta: czy org jest gotowy na AI, czy AI tylko ujawni to, co od lat było ukryte?