Integracja Element z LinkedIn uruchomiona, podsumowanie projektu

5 maja 2026

Wprowadzenie

LinkedIn potwierdził dziś, że feed XML Elementu został zaakceptowany, a oferty pracy naszych klientów są publikowane bezpośrednio na platformie. Po stronie technicznej to pełna integracja z LinkedIn Jobs XML Specification v1.2: jeden publiczny endpoint agreguje oferty wszystkich klientów platformy w jeden plik XML, który LinkedIn pobiera i indeksuje. Po stronie ludzkiej istotniejsze jest co innego: ten projekt napisałem od zera do produkcji w trybie vibe codingu z Claude Code, a sam nie jestem programistą.

To trzeci wpis o tej integracji. Pierwszy ukazał się we wrześniu 2025 i zapowiadał projekt jako test dla tezy, że osoba bez wykształcenia inżynierskiego może budować poważne rozwiązania cyfrowe wspólnie z modelem językowym. Po ośmiu miesiącach mam odpowiedź popartą danymi.

Co to znaczy, że nie-programista zbudował integrację enterprise

Jestem CEO Elementu, konsultantem i wdrożeniowcem AI dla firm, prowadzę warsztaty z praktycznego użycia sztucznej inteligencji w procesach biznesowych. Konfiguruję systemy, projektuję procesy, waliduję architekturę, a kodu produkcyjnego nie pisałem nigdy. Dotąd integracje z zewnętrznymi platformami zlecałem zespołowi developerów: backlog, estymata, sprint, code review, deploy. Tym razem cały cykl, od pierwszego draftu architektury po finalny fix bezpieczeństwa, przeszedłem sam wspólnie z Claude Code. Element wciąż ma zespół developerów, ale ten konkretny projekt wziąłem na siebie jako eksperyment, w duchu tego, czego sam uczę klientów: przejścia od ciekawości AI do operacyjnego użycia narzędzi w realnej pracy.

Wynik: 8 miesięcy kalendarzowych, 75 commitów w bieżącym cyklu i 18 pull requestów. Stack to PHP 8.1+, Symfony 5.4, Angular 13 i TypeScript. Architektura backendu opiera się na DDD z CQRS i event sourcingiem, jest multi-tenantowa, z osobnym read modelem w bazie konfiguracyjnej, bo LinkedIn wymagał jednego XML-a dla wszystkich tenantów platformy. Coverage zamknął się na 540 zielonych testach integracyjnych i 800 zielonych scenariuszach Behat.

Vibe coding to nie skrót, tylko dyscyplina

Pierwsze podejście zakończyło się porażką. Sześć pull requestów zostało zamkniętych bez merge’a po code review zespołu. Architektura była zbyt monolityczna, granice modułów rozmyte, projekcja zdarzeń wpleciona w kontroler. Zespół miał rację, a model językowy bez ostrego briefu poszedł najprostszą ścieżką, czyli wpychania całej logiki w jedno miejsce.

Reset projektu wymusił dekompozycję pracy na trzy fazy z czystymi granicami: Phase 1 to integracja providera LinkedIn z istniejącą fabryką, Phase 2 to read model agregujący oferty z baz wszystkich tenantów, a Phase 3 to publiczny endpoint XML zgodny ze specyfikacją LinkedIn Jobs. Drugie podejście weszło bez większych korekt. Vibe coding nie polega na klepaniu promptów do skutku, tylko na uważnym słuchaniu feedbacku i przeplanowaniu, gdy plan się sypie. Claude Code złapał feedback z code review, sam zaproponował dekompozycję i wrócił z lepszą strukturą, ale tylko dlatego, że nie próbowałem pchać poprzedniej wersji na siłę.

Ping-pong z LinkedIn LTS Support

Wdrożenie pierwszej wersji feedu na produkcję 17 października 2025 nie zamknęło projektu. LinkedIn odrzucił feed po pierwszej walidacji, bo pole company było zaszyte na sztywno jako Element.app zamiast nazw klientów. Przy okazji wyszło, że nazwy pól nie pasują do specyfikacji: niewłaściwy case, zła struktura industry kontra industryCodes, daty w formacie ISO 8601 zamiast MM/DD/YYYY. Jeden duży pull request dorzucił 740 linii i przemapował pięć enumów na kody LinkedIn, gdzie engineering stało się eng, technology stało się 6, a mid_senior_level stało się MID_SENIOR_LEVEL. Wszystko z 540 zielonymi testami integracyjnymi.

Potem zaczęła się iteracja z LinkedIn LTS Support. Każde zgłoszenie to mikroincydent: pole nazywa się CompanyId zamiast linkedInCompanyId, opis ma być surowym HTML-em zamiast escape’owanego stringa, brakuje pola city, lokalizacja jest ignorowana, niektóre oferty nie mają country ani city, jeden tenant wciąż bez kraju w configu. Siedem pull requestów spec-compliance, każdy 1 do 3 dni od zgłoszenia LinkedIn do wdrożenia na produkcję. Pełen flow vibe codingu na każdym kroku: investigation, plan w pliku, kod, testy, code review, build, deploy, status update.

Defensive engineering, czyli incydent z Element.app

Kilka tygodni po pierwszej zielonej walidacji wróciła nieprzyjemna informacja od LinkedIn: w feedzie pojawiły się oferty, ale dwie z nich znów wyświetlały Element.app jako pracodawcę. Powód leżał w asymetrii walidacji frontendu i backendu, czyli w tym, że formularz wymagał nazwy firmy jako pola obowiązkowego, ale system po stronie serwera traktował je jako opcjonalne. Każdy niestandardowy sposób utworzenia oferty (stary cache w przeglądarce, bezpośrednie wywołanie API albo migracja starszych danych) potrafił obejść formularz i zostawić puste pole, a wtedy wewnętrzny mechanizm awaryjny schodził aż do nazwy platformy, czyli Element.app.

Naprawa nie polegała na poprawieniu tych dwóch konkretnych ofert. Zamknąłem cały mechanizm tak, żeby Element.app nie mógł już nigdy trafić do feedu, niezależnie od tego, jak oferta została utworzona. Walidacja po stronie backendu została zrównana z formularzem, a jeśli z jakiegokolwiek powodu nazwa pracodawcy jest pusta, oferta nie trafia do feedu i system loguje ostrzeżenie. Lepiej nie opublikować oferty, niż wypuścić ją pod nazwą platformy. Tak właśnie działa ATS, kiedy ma być stabilny w produkcji z prawdziwymi klientami: nie chodzi o łapanie pojedynczych przypadków, tylko o zamykanie całych klas błędów na poziomie systemu.

Rola zespołu Element w review

Vibe coding nie odbywał się w izolacji. Przez całe osiem miesięcy każdy plan, który pisałem, oraz każdy pull request trafiał do code review naszego zespołu programistów Elementu. To oni wyłapali problemy w pierwszym podejściu i wymusili dekompozycję na trzy fazy, oni pilnowali, żeby kod produkcyjny spełniał te same standardy co reszta repo, oni wskazywali architektoniczne ślepe uliczki, w które model językowy chętnie wchodził. Bez ich review do produkcji nie trafiłby ani jeden commit z tej integracji.

To trzeba powiedzieć wprost: ten projekt nie jest dowodem na to, że programiści przestają być potrzebni. Jest dowodem na coś innego, czyli że osoba rozumiejąca domenę plus model językowy plus zdyscyplinowany zespół review to konfiguracja, która działa. Vibe coding bez review jest projektem hobbystycznym, dopiero z review staje się procesem produkcyjnym.

Chcę w tym miejscu publicznie podziękować zespołowi developerskiemu Elementu za wkład w ten projekt. Każdy zielony „merge” pod pull requestem był ich decyzją, nie moją. Ten artykuł nie powstałby, gdyby nie ich gotowość, żeby cierpliwie przejść przez pierwsze podejście, wskazać błędy, a potem przepuścić drugie podejście przez dokładnie ten sam standard, co kod pisany ręcznie. Dziękuję.

Co z tego wynika dla osoby, która nie pisze kodu

Pierwszy wniosek jest oczywisty, ale często pomijany: AI nie zastępuje kompetencji architektonicznych, tylko je wzmacnia. Reset projektu po pierwszym code review pokazał, że bez umiejętności czytania feedbacku i przeplanowania nawet najlepszy model językowy nie wyciągnie projektu z dołka. Mój wkład jako CEO Elementu i architekta rozwiązań AI polegał na zrozumieniu, że granice modułów są rozmyte, na zaakceptowaniu krytyki i na poprowadzeniu modelu w stronę dekompozycji.

Drugi wniosek dotyczy dyscypliny w utrzymaniu planu. Każda nietrywialna zmiana ma własny plik planu z linkami do PR-ów, decyzjami i risk logiem, a plany są aktualizowane w trakcie implementacji, nie zapisywane raz i porzucane. To samo dotyczy testów: 800 scenariuszy Behat nie powstało dlatego, że Claude Code lubi pisać testy, tylko dlatego, że konsekwentnie wymagałem ich do każdego mikroincydentu.

Trzeci wniosek jest dla mnie najważniejszy: vibe coding ma sens wtedy, kiedy temat naprawdę rozumiesz biznesowo. Nigdy nie pisałem kodu produkcyjnego, ale od kilkunastu lat siedzę w rekrutacji, ATS-ach i integracjach z portalami pracy. Dlatego potrafiłem ocenić, czy Claude Code idzie we właściwą stronę, kiedy proponował fallback chain dla country na podstawie słownika miast. Bez tej domeny model klepałby kod, który przechodzi testy, ale nie spina się z biznesem.

Stan na dziś

Integracja jest stabilna, CI zielone, regression vector zamknięty, a komunikat od LinkedIn potwierdza, że oferty są już publikowane. Z perspektywy biznesowej Element właśnie otworzył nowy kanał dystrybucji ofert pracy dla wszystkich klientów platformy, bez konieczności ręcznej publikacji ogłoszeń przez rekruterów na LinkedIn.

Z perspektywy osobistej zbudowałem od zera enterprise’ową integrację XML w trybie vibe codingu, w stacku, którego nigdy nie pisałem ręcznie. To lekcja na przyszłość pracy w erze AI. Programistów nie zastąpią modele językowe, ale osoby, które rozumieją domenę biznesową, mogą teraz brać się za rzeczy, które jeszcze rok temu wymagały zespołu seniorów. Pisałem zresztą o tym szerzej w tekście Agenci AI nie zmienią firm, które nie zmienią się same, przy okazji wystąpienia Arona Levie z Box.

Jeśli prowadzisz firmę i zastanawiasz się, czy AI to dobre narzędzie do budowy własnych integracji, odpowiedź brzmi: tak, pod warunkiem że masz kogoś, kto rozumie domenę i ma dyscyplinę w utrzymaniu planu. Jeśli szukasz systemu rekrutacyjnego, który publikuje oferty na LinkedIn automatycznie, sprawdź Element.

Najczęściej czytane:

  1. Darmowe ogłoszenia o pracę i największa lista źródeł kandydatów – największa w Polsce lista bezpłatnych i płatnych źródeł kandydatów
  2. Praca w HR – najnowsze oferty pracy i aktualne średnie wynagrodzenia w branży HR
  3. Akademia Rekrutacji – zbiór wiedzy na temat rekrutacji oraz raporty z rynku pracy.
  4. Gowork – jak reagować na negatywne opinie o pracodawcach – Kompleksowy poradnik dla pracodawców.
  5. Jak napisać CV i profil LinkedIn – kompleksowy poradnik tworzenia CV i profilów LinkedIn
  6. RODO w rekrutacji – sourcing, direct search, ogłoszenia. Wszystko co musisz wiedzieć – kompleksowy poradnik RODO w rekrutacji z naciskiem na działania typu direct search / sourcing.
  7. Wszystko o systemach ATS – poradnik wyboru systemu rekrutacyjnego
  8. Umowy przedwstępne i listy intencyjne w procesach rekrutacyjnych – wszystko, co musisz wiedzieć o prawnych zabezpieczeniach zobowiązania do zatrudnienia.
Picture of Maciej Michalewski

Maciej Michalewski

Founder & CEO @ Element

Element cennik baner

Nasze artykuły przeczytasz także na Medium, LinkedIn, Substack, Reddit

Ostatnie wpisy: