Nowy standard w AI dla developerów: jak TEX zmienia pisanie testów

W 2025 modele AI osiągnęły 74.4 procent skuteczności na SWE-Bench (Salesforce), ale branża przeoczyła coś kluczowego: te benchmarki ledwo dotykają jakości testów. TEX – nowy sposób skalowania AI w czasie wykonania – przesuwa akcent z samego pisania kodu na budowanie testów, które faktycznie wykrywają błędy. W praktyce oznacza to, że agent AI nie tylko generuje patch, ale weryfikuje go testami napisanymi przez inne modele. Dla praktyków Salesforce to zwiastun zmiany: agentyczne AI zacznie zachowywać się jak realny zespół developerów. 

Techniczne fundamenty TEX – AI uczy się przez wykonywanie cudzych testów

W świecie LLM dominowały dwa podejścia: modele rozpisujące wewnętrzne rozumowanie token po tokenie oraz równoległe próbkowanie wielu odpowiedzi. Pierwsze poprawia jakość, ale działa wolno. Drugie jest szybkie, ale trudne do oceny, szczególnie w złożonych zadaniach, takich jak naprawa kodu. TEX łączy oba podejścia, bazując nie na porównywaniu tekstu, ale na wykonywaniu testów jednego agenta na kodzie drugiego. Ten mechanizm cross-candidate execution działa jak techniczne code review, w którym każdy agent jest jednocześnie testerem i developerem.

Kluczowy element to uruchamianie wszystkich wygenerowanych patchy na wszystkich wygenerowanych testach. Dzięki temu agent nie musi czytać długich śladów działania innego modelu ani streszczeń, które zwykle prowadzą do utraty kontekstu. Dostaje za to twarde wyniki: test przeszedł albo nie, a jeśli nie – otrzymuje konkretny stacktrace. Dla LLM to znacznie precyzyjniejsza informacja zwrotna niż jakikolwiek tekstowy feedback.

W praktyce daje to efekt podobny do pair programmingu w zespołach dev: kilka implementacji, wiele testów, szybka walidacja. TEX osiągnął dzięki temu ponad 6 procent wzrost pass@1 na SWT-Bench i rezultat przewyższający poprzedni rekord 84 procent. To rzadki przykład, gdy testy generowane przez AI stają się realnie używalne, a nie są jedynie syntaktyczną dekoracją.

Trend jest spójny z kierunkiem, w którym idzie Agentforce – rozwój agentów opartych na feedbacku wykonawczym zamiast oceny heurystycznej. Podobny kierunek opisaliśmy w kontekście agentów MCP z deterministycznym dostępem do narzędzi, gdzie kluczem była kontrolowana, mierzalna interakcja modelu z systemem.

Dlaczego to ma znaczenie dla developerów Salesforce

Salesforce nie jest środowiskiem Pythonowym, a Apex nie daje takiej swobody jak agentic scaffolding z benchmarków. Mimo to widać wyraźny kierunek: AI, które naprawdę pomaga developerom, musi umieć pisać testy, nie tylko klasy produkcyjne. W ekosystemie Salesforce testy od zawsze były obowiązkowym elementem deployu, ale AI do tej pory radziło sobie z nimi przeciętnie. TEX sugeruje, że najlepsze testy powstają wtedy, gdy model podejmuje próbę naprawienia błędu, zamiast pisać testy w izolacji.

Dla developerów Apex oznacza to możliwy nowy workflow: agent pisze patch, agent pisze test, agent wykonuje self-check, agent wykonuje cross-check z innymi wariantami testów. W Agentforce może to przypominać działanie kilku równoległych instancji Vibes lub Code Assist, które walidują się nawzajem poprzez uruchamianie testów na scratch org albo sandbox. To zupełnie inna jakość niż pojedyncze promptowanie o testy pokryciowe.

Co ważne, mechanizm TEX nie wymaga trenowania modelu. To tylko strategia korzystania z istniejących agentów, co otwiera drogę do implementacji podobnego procesu w narzędziach low-code/no-code. W praktyce oznacza to, że Salesforce może łatwo adaptować schemat TEX w przyszłych wersjach Agentforce Builders – podobnie jak zaadaptowano multiagentowy model decyzji w incident response automation.

Implikacje dla architektury Salesforce – od pojedynczego agenta do zespołu AI

Najbardziej przełomowa część TEX to nie testy, lecz to, że model nie pracuje sam. Architektura zakłada zespół AI: 4 agentów pracujących równolegle, uczących się jeden od drugiego na podstawie wyników wykonania kodu. To bardzo blisko koncepcji multi-agentowej orkiestracji Salesforce Engagement Agent, opisywanej w analizie skalowania agentów AI w Salesforce. W obu przypadkach najważniejsze jest zarządzanie interakcjami między agentami, a nie zwiększanie liczby tokenów myślenia.

W praktyce dla architektów Salesforce oznacza to nowe wymagania: środowiska developerskie muszą obsłużyć równoległe wykonania kodu, częste odpalanie testów, analizę błędów i szybkie odtwarzanie stanu. Sandboxy oraz ephemeral orgs staną się zasobem wykorzystywanym przez AI, nie tylko przez ludzi. Benchmarki typu TEX pokazują również, że agent AI wcale nie potrzebuje pełnej swobody CLI, aby być efektywny. W badaniu agent nie miał dostępu do bash ani zewnętrznych narzędzi, a mimo to poprawiał wyniki rundami iteracji.

Dla architektów oznacza to, że warto projektować procesy CI/CD tak, by agent AI mógł wykonywać własne testy, a później testy krzyżowe z innymi agentami lub innymi wersjami kodu. Można tu wykorzystać scratch orgs, ephemeral containers lub środowiska typu automation-only. To także silny argument, by oddzielić testy od logiki biznesowej w strukturze repo, bo AI będzie je konsumować inaczej niż developer.

Ostatecznie TEX sugeruje, że single-agent AI w CRM to droga donikąd. Warto przygotować się na architekturę, w której kilka zautomatyzowanych procesów AI współpracuje, waliduje się nawzajem i konkursowo generuje lepsze rozwiązania.

Strategia adopcji – jak przygotować Salesforce na agentów, którzy sami piszą testy

Organizations, które chcą wdrożyć podobny model w Salesforce, powinny zacząć od trzech obszarów. Po pierwsze: standaryzacja struktury testów Apex. AI będzie generować testy skuteczniej, jeśli metody są krótkie, klarowne i oparte na factory pattern, a nie duplikacji danych testowych. Po drugie: przygotowanie środowisk, które AI będzie mogło wykorzystać iteracyjnie. Oznacza to automatyczne tworzenie i niszczenie scratch orgs, z minimalnym zestawem danych oraz jasnymi limitami.

Po trzecie: governance agentów. TEX działa dobrze, ponieważ każdy agent pracuje niezależnie, ale otrzymuje wyniki testów od innych. Podobny model w Salesforce oznacza kontrolę nad tym, jakie uprawnienia ma agent, jakie testy może uruchamiać i jak wyniki wracają do modelu. W kontekście RODO ważne jest też, by dane testowe były syntetyczne, a nie produkcyjne.

Quick wins obejmują zautomatyzowanie generowania testów jednostkowych w prostych klasach Apex oraz walidację kodu patch poprzez agentic self-check. Długofalowo warto przygotować architekturę repo, która pozwala na równoległe porównywanie wielu patchy generowanych przez modele AI oraz ich wspólne uruchamianie testów w hermetycznych środowiskach.

Najważniejsze jest jednak to, że TEX dowodzi, że AI nie musi być trenowane na danych Salesforce, aby znacząco poprawić jakość testów. Wystarczy zmienić sposób pracy agentów – z pojedynczego modelu na współpracującą sieć agentów uczących się przez wykonanie kodu.

Wnioski – agent AI, który zachowuje się jak zespół developerów

TEX pokazuje kierunek, w którym będzie ewoluować AI w Salesforce: nie chodzi o zwiększanie mocy jednego modelu, ale o używanie wielu agentów pracujących równolegle i weryfikujących siebie nawzajem przez realne wykonanie kodu. To przełom dla developerów Apex, bo otwiera możliwość automatycznego pisania testów, które mają sens, a nie tylko zwiększają pokrycie. Dla architektów to sygnał, że orgi muszą być gotowe na multiagentowe procesy, z kontrolą zasobów, środowisk i danych. Pytanie na kolejne lata brzmi: kiedy Agentforce dostanie pierwszy natywny mechanizm cross-execution między agentami – i jak zmieni to nasze zespoły developerskie.