AI migruje Aura do LWC lepiej niż junior. Co to zmienia?

W wielu polskich orgach nadal działa kilkaset do kilku tysięcy komponentów Aura, a ich ręczna migracja do LWC oznacza miesiące pracy i ryzyko regresji. Tymczasem Agentforce Vibes, korzystając z Salesforce DX MCP Server, potrafi przeprowadzić pełną migrację pojedynczego komponentu w około 30 minut (Salesforce). To pierwszy moment, w którym AI realnie skraca czas refaktoryzacji frontendu Lightning, zamiast generować dodatkowy chaos. W artykule pokazuję, jak działa ten proces pod maską, jakie są jego ograniczenia i jak przygotować polski org do migracji, żeby nie utknąć na zależnościach, eventach i integracjach. To praktyczny przewodnik dla adminów, developerów i architektów, którzy chcą wreszcie wygasić Aura bez ryzyka produkcyjnej awarii.

Agentforce Vibes i MCP – nowa warstwa automatyzacji migracji

Vibes nie jest klasycznym generatorem kodu, ale multi-agentowym systemem, który steruje zestawem ponad 60 narzędzi MCP podłączonych do orga. Salesforce uruchamia je jako procesy dostępne dla LLM, dzięki czemu agent może nie tylko pisać kod, ale też interpretować strukturę Aura, generować blueprinty i wykonywać transformacje. Kluczowy jest tutaj pipeline pięciu narzędzi dedykowanych migracji Aura do LWC: orchestrate_aura_migration, create_aura_blueprint_draft, enhance_aura_blueprint_draft, transition_prd_to_lwc i create_lwc_component_from_prd (źródło: Salesforce). To pierwszy raz, kiedy migracja komponentu jest prowadzona jako formalny proces inżynieryjny, a nie kreatywna interpretacja modelu LLM.

Od strony technicznej agent buduje YAML blueprint opisujący referencje, child components, interakcje, stan i używane dane. To ogromna różnica wobec poprzednich generacji AI, które miały problem z analizą istniejącego repo. Blueprint eliminuje zgadywanie – jest jednoznacznym inputem dla generatora LWC. W praktyce oznacza to, że agent radzi sobie nie tylko z HTML i JS, ale także z kontekstem eventów czy zależności między komponentami.

Dla praktyków w Polsce oznacza to, że migracja przestaje być projektem typu big bang, a staje się operacją punktową na dowolnym komponencie. Decyzję o migracji można podejmować w sprintach, a nie w ramach osobnego budżetu transformacyjnego. Co ważne, MCP działa lokalnie w środowisku deweloperskim, nie wymaga Hyperforce ani dodatkowych licencji. Integruje się naturalnie z CLI, co ułatwia wdrożenie w dojrzałych orgach.

W szerszym trendzie jest to kolejny dowód, że agentic AI przenosi ciężar pracy z tworzenia funkcjonalności na utrzymanie i modernizację istniejącego kodu. Warto tu zauważyć zbieżność z wnioskami z analizy modernizacji AI w polskich centrach service, gdzie automatyzacja procesów stała się kluczową przewagą w transformacji operacji.

Gdzie AI się zatrzymuje: komunikacja między komponentami i LMS

Nawet najlepszy pipeline MCP nie rozwiązuje wszystkich problemów automatycznie. Najwięcej błędów przy migracji dotyczy interakcji między komponentami, szczególnie tam, gdzie Aura używa systemowych eventów. W przykładzie z PropertySummary agent wygenerował LWC, ale stan nie aktualizował się po kliknięciu kafelka, bo LWC nie obsługuje ltng:selectSObject. Agent zasygnalizował to w task summary, ale nie dodał od razu komunikacji alternatywnej. Dopiero drugi prompt spowodował wygenerowanie poprawnego Lightning Message Channel.

Ta sytuacja pokazuje techniczne ograniczenia migracji: agent potrafi wskazać lukę, ale musi dostać zgodę na zaprojektowanie architektury komunikacji. LMS działa w LWC, Aura i Visualforce, dzięki czemu jest naturalnym następcą starych eventów, ale wymaga bardziej jednoznacznych struktur danych. Najczęściej migracja kończy się problemem typu [object Object], bo agent musi na nowo mapować pola w JS. To nie błąd modelu, ale konsekwencja braku typowania i słabego kontraktu między komponentami w legacy Aura.

Implikacja dla polskich zespołów jest jednoznaczna: komponenty trzeba migrwać w kontekście komunikacji domenowej. Samo przepięcie HTML do LWC nie wystarczy. Trzeba wiedzieć, w jaki sposób komponent publikuje i konsumuje zdarzenia oraz jakim stanem zarządza. W wielu orgach w Polsce, szczególnie tam, gdzie rozwój trwał ponad 5 lat, komunikacja mieszana (Aura events + Application events + LMS) jest normą. Tam agent działa najlepiej, jeśli architekt najpierw oczyści przepływy.

To też pokrywa się z obserwacjami z wdrożeń multi-agentowych workflowów, które analizowaliśmy w tekście o skalowaniu automatyzacji w procesach sprzedaży. Gdy integracje są niejednoznaczne, agent musi dostać jasne granice działania.

Styl, dostęp do danych i to, czego AI nie zrobi za nas

W migracji dużych komponentów kluczowym elementem jest różnica w modelu dostępu do danych między Aura a LWC. Aura miała tendencję do manipulowania danymi „jak leci”, natomiast LWC wymaga jawnych getterów, destrukturyzacji i bezpośrednich referencji. To dlatego agent często generuje komponent działający funkcjonalnie, ale łamiący layout albo wyświetlający błędne wartości. W przykładzie z PropertySummary konieczne było poprawienie sposobu pobierania pól, bo agent założył, że rekord jest płaskim obiektem, a nie zagnieżdżonym JSON-em.

To prowadzi do najważniejszej lekcji: 80% migracji wykona za nas AI, ale ostatnie 20% wymaga człowieka. Są to miejsca, gdzie potrzebna jest wiedza domenowa, zależności z backendem lub logika ukryta w Apex. Agent nie może sam refaktorować triggerów ani optymalizować danych pod governor limits, więc nadal potrzebny jest developer, który oceni, czy blueprint rzeczywiście oddaje zamiary komponentu.

Jednocześnie AI potrafi zrobić coś, czego ludzie nie robią: wykrywa nieintencjonalne błędy. W przykładzie z Salesforce komponent Aura miał bug – ikonę edycji wyświetlaną bez warunku. Migracja do LWC naprawiła to przypadkiem, bo agent zasugerował kontrolę stanu. W polskich orgach, gdzie komponenty ewoluują przez lata, takie „bonusowe naprawy” mogą realnie zmniejszyć liczbę regresji po migracji.

To kolejny sygnał, że AI w CRM przechodzi od generowania do utrzymania kodu. Podobny trend obserwowaliśmy przy automatyzacji analizy logów i incydentów w środowiskach produkcyjnych, gdzie agent znajdował błędy szybciej niż człowiek, ale finalna decyzja pozostawała po stronie zespołu.

Jak podejść do migracji Aura w polskim orgu – ramy operacyjne

Największy błąd, jaki popełniają firmy, to rozpoczynanie migracji od dużych ekranów i komponentów typu container. AI również nie poradzi sobie wtedy dobrze, bo blueprint stanie się zbyt złożony. Dlatego najlepsza strategia to migracja inkrementalna: zaczynamy od child components, potem migrujemy komponenty po stronie danych i dopiero na końcu elementy layoutu. Vibes jest narzędziem optymalnym do tej strategii, bo pozwala wykonywać punktowe migracje bez dużego upfront planningu.

Drugi krok to porządkowanie komunikacji. Przed każdym promptem warto ręcznie opisać agentowi kontekst interakcji między komponentami. Jeśli w orgu są eventy aplikacyjne z czasów Classic, agent sobie z nimi nie poradzi. Jeśli istnieją mieszane dependency między Aura a Visualforce, MCP także tego nie wykryje. Trzeba zdefiniować kontrakty wymiany danych, zanim agent wygeneruje blueprint.

Trzecim elementem jest bezpieczeństwo i RODO. Migracja komponentów często odkrywa pola, których widoczność nie była kontrolowana, bo UI Aura wyświetlał je warunkowo. LWC, zgodnie z nowymi zasadami, wymaga jawnych deklaracji pól. W polskich orgach, gdzie dane osobowe i dane handlowe są szczególnie regulowane, migracja jest dobrym momentem na reset kontroli uprawnień i usunięcie customowych hacków w Apex.

Patrząc szerzej, dzięki agentom migracja jest teraz zadaniem CI/CD, a nie projektem developerskim. Można ją zamknąć w pipeline, zestandaryzować i wykonywać falami. To zmienia pracę zespołów – nie potrzebujesz armii developerów Aura, potrzebujesz architekta, który potrafi zarządzać przepływami i kontraktami komponentów. W tym kierunku zmierza cała modernizacja Salesforce.

Podsumowanie

Automatyczna migracja Aura do LWC nie jest już futurystycznym obietnicą, tylko powtarzalnym procesem, który realnie skraca czas modernizacji frontendu Lightning. Agenci wykonują większość pracy, ale nadal potrzebują kierunku i decyzji architekta. Największa wartość pojawia się nie w generowaniu kodu, ale w uporządkowaniu przepływów, komunikacji i zależności. Jeśli Twój org nadal stoi na Aura, 2026 to moment, w którym migracja przestaje być problemem, a zaczyna być inwestycją w stabilność i bezpieczeństwo. Pytanie brzmi: które komponenty w Twoim orgu są dobrymi kandydatami do migracji w pierwszej kolejności?