Agenda '26

2025 i 2026 to lata ciekawych zmian w naszej branży. Jest intensywnie, chaotycznie i trochę niepewnie. Ciężko jednoznacznie ocenić, jak będzie wyglądał rynek i na co będzie zapotrzebowanie. Mam swoje przewidywania i chcę się nimi podzielić na tej prezentacji, by trochę obniżyć poziom niepewności, ale też zmienić mapy mentalne innym, świeżym punktem widzenia.

Gdy wchodziłem na rynek (18 lat temu), bazą w naszym zawodzie była znajomość języka i frameworku, pisanie kodu czy specjalistyczna wiedza techniczna. Na tym budowało się seniority. Dzisiaj jednak coraz częściej mówi się o tym, że wartość inżyniera odsuwa się od pisania kodu w stronę odpowiedzialności za efekt. Ta rewolucja nie jest do końca rewolucją, jest ewolucją procesów, które zachodziły już od lat. LLM-y i AI są tutaj tylko akceleratorem, a nie czymś, co fundamentalnie zmienia zasady gry. Nowym fundamentem inżyniera staje się triada: odpowiedzialność za efekt, ownership problemu i sprawczość, czyli zdolność, żeby realnie coś dowieźć i wygenerować wartość. To one, a nie znajomość narzędzi, zaczynają definiować seniority. Junior/mid/senior przestaje znaczyć „zna framework”, a zaczyna znaczyć „potrafi samodzielnie wziąć problem na siebie i go dowieźć”.

Ten chaotyczny galimatias powoduje, że na rynku zaczęły pojawiać się nowe role, takie jak Staff Engineer czy Staff+ Engineer. Na przykładzie tej roli opowiem, jak ewoluowała branża i co dziś ceni.

Prawie każdy zespół ma jakiś diagram architektury. Kwadraty, beczki, strzałki. Widać, co gdzie stoi i co się z czym łączy. Problem zaczyna się wtedy, gdy ktoś pyta, gdzie właściwie kończy się odpowiedzialność jednego zespołu, a zaczyna drugiego. Wtedy diagram milczy, bo pokazuje technikę, a pytanie dotyczy podziału domeny.

Mapa kontekstów odpowiada dokładnie na tę drugą warstwę. Dobra wiadomość jest taka, że nie trzeba jej rysować od zera, bo w dużej części siedzi już w tym, co macie na ścianie.

Pokażę, jak przełożyć diagram architektury na mapę kontekstów, a potem jak dołożyć do niej trzy rzeczy, dzięki którym zaczyna odpowiadać na konkretne pytania. Gdzie przebiega granica, kiedy każdy zespół uważa, że dana funkcjonalność należy do niego. Dlaczego zmiana w jednym miejscu wysypuje coś, co teoretycznie nie ma z nią nic wspólnego. Gdzie warto zainwestować czas dobrego zespołu, a co spokojnie można kupić.

Czytelna, przejrzysta i kompletna, a przede wszystkim aktualna! Zapraszam wszystkich, którzy mieliby problem, żeby opisać w ten sposób swoją dokumentację architektoniczną.

W środowisku, w którym wiele zespołów równolegle wprowadza zmiany, a system jest rozproszony, często niełatwo jest się odnaleźć. I to nie tylko nowym pracownikom. Na prezentacji pokażę, jak można stworzyć „żywy” diagram architektury całego systemu, nawet gdy używa się multi-repo. Zademonstruję architekturę jako integralną część kodu, a jej zmiany jako element PR i Code Review.

Język programowania nie ma tu znaczenia, a znajomość Backstage nie jest potrzebna. Udokumentujemy nasz system z użyciem YAML-a, a Backstage nam go zwizualizuje.

W świecie zdominowanym trendem AI nie powinniśmy zapominać o innej rewolucji, która dzieje się na naszych oczach – Quantum. Programowanie kwantowe brzmi jak coś z laboratorium fizyków, ale dzięki Azure Quantum coraz częściej trafia w ręce specjalistów IT.

W tej sesji pokażę, jak wygląda pierwsze spotkanie ze światem kubitów, superpozycji i algorytmów kwantowych. Porozmawiamy o tym: czym naprawdę jest programowanie kwantowe, jakie problemy może rozwiązywać, czy to przyszłość IT, czy raczej odległa ciekawostka. Na koniec przejdziemy do praktyki: napiszemy prosty program w Q# i uruchomimy go na prawdziwym komputerze kwantowym dostępnym przez Azure Quantum.

Jeśli po wielu sesjach o AI chcesz zobaczyć technologię, którą już dziś powinieneś się zainteresować – zapraszam!

Kod piszemy szybciej niż kiedykolwiek, ale czas od zgłoszenia do produkcji prawie się nie zmienił. Raport „The State of DevOps” pokazuje dlaczego: praca stricte deweloperska w całym procesie się kurczy, a żmudna, powtarzalna praca wokół niej rośnie jeszcze szybciej.

Ta prezentacja pokazuje, jak zbudować system wiedzy, dzięki któremu przyspieszenie obejmuje cały proces dostarczania. Zobaczysz, jak zmapować proces dostarczania i wiedzę, z jakiej korzysta się na każdym jego etapie, jak przełożyć tę mapę na scenariusze, które prowadzą agenta przez rozwiązanie danego problemu, oraz jak utrzymać system wiedzy zgodny z rzeczywistością, kiedy system produkcyjny się zmienia.

W sezonie urlopowym 2026 r. nie ma już chyba na świecie szanującej się organizacji, która nie wdraża AI. Jak wiemy z materiałów reklamowych, to ekscytujący proces, prowadzący do zwielokrotnienia wartości firmy, przyśpieszenia procesów i uwolnienia ogromnych zasobów czasu. Armia agentów tylko czeka, by czuwać nad naszym sukcesem.

Materiały reklamowe nie zawsze są jednak pisane przez ludzi (tu można by już postawić kropkę) zaangażowanych operacyjnie. Może się zdarzyć, że nie pokazują całej rzeczywistości. Może też być tak, że jeśli składniki, z których próbujemy wyczarować AI-ową zupkę nie są pierwszej jakości, potrawa może nie dostać gwiazdki Michelin.

Piotrek podzieli się z nami doświadczeniem płynącym z bardziej i mniej udanych prób zastosowania AI w zespole marketingu Kuchni Vikinga. Będzie smacznie.

Pracując z klientami BIM Ally, wielokrotnie spotykaliśmy się z problemem, który początkowo wydawał się czysto organizacyjny: wiedza potrzebna do obsługi klientów, sprzedaży czy rozwoju produktu była rozproszona pomiędzy dokumentami, mailami, prezentacjami, systemami i — przede wszystkim — ludźmi.

Z czasem zauważyliśmy, że problem nie polega tylko na tym, że trudno znaleźć informację. Trudniejsze jest ustalenie, która informacja jest aktualna, skąd pochodzi, kto może jej zaufać i co zrobić, gdy różne źródła mówią coś innego.

Opowiem o tym, czego nauczyliśmy się, próbując wykorzystać AI w realnej organizacji — o miejscach, w których pojawia się chaos w firmowej wiedzy, o problemach, których nie widać na demonstracjach AI, oraz o tym, jak zmienia się podejście do sztucznej inteligencji, gdy przestajemy zakładać, że można jej bezgranicznie zaufać.

Praktyczne studium przypadku efektywnej cyfryzacji w branży produkcyjnej bez przepalania budżetu. Na przykładzie Showroomu 3D i aplikacji myINTERTECH prelegent omówi przechodzenie od celów biznesowych do działających narzędzi B2B. Dowiesz się, jak oceniać ROI, unikać nierentownych wdrożeń, optymalizować koszty IT oraz skutecznie wykorzystywać dofinansowania na rozwój oprogramowania. Konkretne lekcje ze styku biznesu, inżynierii i technologii.

Spojrzenie od strony konsultanta operacyjnego: jak jego klienci poradzili sobie z wdrożeniem systemu albo nie poradzili sobie wcale. Dlaczego jedni po 7 latach wciąż nie skończyli wdrożenia ERP, a inni dali radę.

Twoja architektura nikogo nie obchodzi, dopóki nie zacznie blokować dowożenia, kosztować fortunę albo wybuchnie na produkcji. Ta sesja jest o tym, jak naprawdę zapadają decyzje architektoniczne w firmach i dlaczego zawsze i tak wychodzi z tego problem.

Zamiast opowieści o „idealnej” architekturze, rozbierzemy na czynniki pierwsze to, co dzieje się naprawdę: dlaczego craftsmanship jako cel często przegrywa z dostarczaniem wartości, kto ma realne weto w decyzjach i jak projektować architekturę, która wygrywa w praktyce, bo pasuje do organizacji, a nie do diagramu.

Na koniec przesuniemy ciężar na to, co zmienia AI i vibe coding: mniej walki o perfekcyjny kod, więcej projektowania kontroli. Granice, kontrakty, bezpieczeństwo, standardy i guardrails, które pozwalają dowozić szybciej, ale bez chaosu, niekontrolowanego długu i niespodzianek na produkcji.

Ile naprawdę kosztuje, w energii, mocy obliczeniowej i zasobach, zastąpienie ludzkiego zadania przez LLM? Spojrzenie na efektywność AI przez pryzmat energii na jednostkę pracy oraz realnej ekonomii inteligencji ludzkiej i maszynowej.

Residuality Theory Barry'ego O'Reilly'ego to jedna z ciekawszych rzeczy, jaka wydarzyła się ostatnio w architekturze oprogramowania. Jest też jednocześnie często kwitowana zdaniem: „brzmi świetnie, ale jak to zastosować?”. Na tej prelekcji postaram się odpowiedzieć na to pytanie. Pokażę, jak użyliśmy Residuality Theory do przetestowania granic modularnego monolitu. Na warsztat weźmiemy krytyczną część produkcyjnej platformy dla branży insuretech: sprzedaż, rozliczenia i prowizje, czyli miejsce, gdzie płyną pieniądze i błędy kosztują najwięcej.

Najpierw przejdziemy przez projektowanie stresorów, czyli to, jak realnie zdefiniować zagrożenia dla systemu (od tąpnięć biznesowych po nagłe zmiany regulacyjne KNF). Następnie omówię pracę z macierzą incydencji i to, jak namierzyć kruche miejsca w architekturze. Analiza wskazała u nas zupełnie inny komponent, niż podpowiadała intuicja zespołu. Pokażę też przełożenie teorii na kod, czyli jak z wyników tej symulacji wyciągnęliśmy konkretne decyzje architektoniczne (ADR) i przebudowaliśmy system przed wdrożeniem.

Od 1 stycznia 2026 roku nie napisałem ręcznie ani jednej linii kodu. Na razie się udaje — choć droga od pierwszych eksperymentów z vibe codingiem do skutecznej pracy z agentami okazała się znacznie bardziej stroma, niż sugerują internetowe demonstracje.

Najczęstszy błąd? Usiąść przed komputerem, wpisać jeden prompt i oczekiwać gotowego, poprawnego i łatwego w utrzymaniu systemu. Kiedy rezultat okazuje się „AI slopem”, łatwo obwinić model. Tymczasem agent, podobnie jak człowiek, potrzebuje jasnych wymagań, informacji zwrotnej, odpowiednich narzędzi oraz procesu, który wymusza jakość.

Pokażę, jak przenieść do pracy z agentami praktyki, które od lat znamy z inżynierii oprogramowania: dopracowywanie ticketów, iteracyjne planowanie, TDD, testy jednostkowe i integracyjne, małe kroki, pull requesty oraz niezależne code review wykonywane przez innego agenta. Opowiem o błędach, które popełniłem, i o tym, jak zmienia się rola programisty: zamiast pisać każdą linię kodu, projektujemy środowisko, procedury i mechanizmy kontroli, dzięki którym agenci mogą dowozić oprogramowanie naprawdę nadające się do produkcji.

Niezależnie od tego, czy delegujesz agentom już cały proces tworzenia kodu, czy dopiero zaczynasz, wyjdziesz z konkretnym modelem pracy — a nie kolejnym zbiorem magicznych promptów.

System wyświetlał pozycje dronów, obserwacje i dane operacyjne. Komunikacja szyfrowana, profesjonalny panel, operatorzy mieli wszystkie powody, by ufać temu, co widzieli na mapie. Aż my, razem z 11 innymi zespołami, rozebraliśmy firmware i protokół, po czym wysłaliśmy ich drony w pilną misję prosto do wnętrza Ziemi.

Możesz mieć własny format pakietów, stosować AES-ECB, efemeralne klucze z autodestrukcją, ale jeśli w autoryzacji jednego endpointa wprowadzisz głupiego buga, podszyjemy się pod Twoje urządzenie. Wyślemy poprawnie zaszyfrowaną, ale spreparowaną telemetrię, Twój frontend narysuje współrzędne idealnie, a reszta systemu i ludzie uwierzą w 100% w dane, które Ci wstrzyknęliśmy. Ta historia wydarzyła się podczas ćwiczeń Cyberlegionu, ale sam mechanizm jest zupełnie zwyczajny w całej branży. W ten sam sposób aplikacje ufają webhookom tylko dlatego, że przyszły przez HTTPS, tokenom JWT bez sprawdzania odbiorcy, wiadomościom z kolejki bez ochrony przed replay attack, czy danym z urządzeń, których nikt nie weryfikuje w kontekście biznesowym.

Podczas prezentacji przejdziemy od analizy pakietu przez pięć warstw zaufania: tożsamość nadawcy, integralność, świeżość, autoryzacja i sens danych. Uczestnicy wyjdą z prostym modelem przeglądu API i systemów zdarzeniowych, plus trzema testami, które od razu mogą wrzucić do backlogu, bez kosztownej przebudowy całej produkcji. Szyfrowanie powie Ci, że ktoś nie przeczytał wiadomości, ale nie odpowie, kto ją napisał, kiedy powstała i czy system powinien na jej podstawie cokolwiek zrobić.

Od bycia zalewanym wymaganiami klientów i działu handlowego oraz prób zadowolenia wszystkich, co kończyło się jedną wielką frustracją, do pipeline'u, który mamy dziś. Opowiem, jak go zbudowaliśmy, jak wciąż go ulepszamy i jak pilnujemy pewnych fundamentów — choćby tego, że Product Owner jest kluczowym decydentem.

W firmie transportowej jest jeden człowiek, który wie, ile naprawdę kosztuje kurs do Hamburga. W produkcyjnej — jeden technolog, który umie wycenić zapytanie. W spedycji — jedna osoba, która pamięta, że ten klient zawsze płaci po 60 dniach. Ta wiedza to największy majątek firmy i nigdzie nie jest zapisana. Kiedy pan Zbyszek odchodzi na emeryturę, majątek wychodzi razem z nim.

Badanie MIT na ponad 300 firmach pokazało, że 95% projektów z nowymi technologiami nie dało żadnego mierzalnego efektu finansowego, a w 2025 roku 42% firm porzuciło takie inicjatywy — rok wcześniej było to 17%. To nie technologia zawodzi, tylko podejście: wielki system, wdrażany latami, przebudowa całej firmy naraz. Czyli burzenie domu, w którym się mieszka.

Pokażę drogę na skróty, która działa: spisz jeden proces, uporządkuj dane w jednym miejscu i postaw obok pierwszego cyfrowego pomocnika. Dwutorowo — obok istniejących systemów, nie zamiast nich, więc niczego nie trzeba wyłączać. Będą konkretne przykłady z finansów, magazynu, spedycji, transportu i produkcji: oferta frachtu w 5 minut zamiast 40, rozliczenie miesiąca w godzinę zamiast trzech dni, wycena w 24 godziny zamiast trzech dni.

Będzie też ostrzeżenie z praktyki: jeśli przyspieszysz ofertowanie trzykrotnie, a produkcja nie nadąży, zrobisz zator w sąsiednim pokoju. Dlatego mierzy się cały przepływ, od zapytania do zapłaconej faktury, a nie jeden punkt. Wyjdziesz z sali z jednym konkretnym krokiem do zrobienia w przyszłym tygodniu.

Technologia to zaledwie 20% sukcesu wdrożenia. Pozostałe 80% to ludzie, którzy na co dzień będą z niej korzystać.

Wyobraź sobie, że wchodzisz do ulubionego sklepu pięć minut przed zamknięciem, a wszystkie produkty nagle leżą na zupełnie innych półkach. Frustracja? Chaos? Dokładnie tak samo reagują pracownicy na hali produkcyjnej, gdy z dnia na dzień obdarowujemy ich nowym systemem IT.

Inwestujemy w zaawansowane narzędzia klasy MES czy ERP, jednak wdrożenie rzadko rozbija się o samą technologię. Najczęściej zawodzi brak fundamentów, robienie rewolucji na siłę oraz opór zespołu. Pokutuje przekonanie, że wystarczy ogłosić zakup systemu, a reszta wydarzy się sama — tymczasem budowanie domu na słabych fundamentach zawsze kończy się tak samo.

Bazując na doświadczeniach z wdrożeń w sektorze produkcyjnym MŚP, przyjrzymy się temu procesowi bez marketingowego lukru. Przeanalizujemy, dlaczego potrzeba zmiany u managera nie oznacza automatycznie potrzeby w zespole oraz co zrobić, by cyfryzacja przestała być narzuconą z góry rewolucją, a stała się procesem, który ludzie po prostu zaakceptują.

Wszyscy mówią o AI, ale w dużych firmach wdrożenia wciąż grzęzną — i wcale nie dlatego, że technologia zawodzi. Na tej prezentacji pokażę, gdzie naprawdę pękają transformacje AI: w ludziach sparaliżowanych strachem i przeciążeniem, w przestarzałych systemach zamkniętych na integracje, i w starym sposobie myślenia, w którym wciąż „ja robię zadanie”, zamiast pozwolić agentowi pracować za mnie.

W 30 minut rozłożę te przeszkody na czynniki pierwsze i pokażę, dlaczego atakowanie tylko jednej z nich to strata czasu. Wyjdziesz z konkretną mapą tego, co blokuje Twoją organizację — i wiedzą, od czego zacząć, żeby ruszyć z miejsca. Jeśli odpowiadasz za wdrażanie AI albo po prostu masz dość slajdów pełnych obietnic bez pokrycia, to jest prezentacja dla Ciebie.

Spojrzenie z drugiej strony stołu: nie dostawcy, tylko firmy, która kupuje i wdraża system u siebie.

Opowiem o tym, co skłoniło naszą firmę do zakupu oprogramowania, jak poszło nam samo wdrożenie, co moglibyśmy zrobić lepiej, żeby przebiegło sprawniej, oraz co mógłby zrobić dostawca oprogramowania, żeby było szybsze i łatwiejsze.

Decyzje zapadają na spotkaniach. Ustalenia giną w wątkach na Slacku. Pół roku później nikt nie pamięta, dlaczego coś zrobiliście tak, a nie inaczej. Wiki miała to rozwiązać, ale dokumentowanie to osobna praca, której nikt nie robi. Nagrywanie wszystkiego też nie pomaga — macie „wszystko”, tylko trzeba wiedzieć, czego szukać.

W Arkency zbudowaliśmy pamięć organizacji: graf wiedzy zasilany tym, co i tak codziennie wytwarzamy — transkryptami spotkań, wątkami ze Slacka, notatkami. AI wyciąga z nich ludzi, projekty, decyzje, ryzyka i zobowiązania. Nie robi tego na oko, tylko kieruje się ontologią: zamkniętą listą tego, co w naszej firmie uznajemy za wiedzę. Potem proponuje zmiany w grafie.

System działa u nas na produkcji od kilku miesięcy. W grafie jest kilka tysięcy węzłów i krawędzi zbudowanych na podstawie kilkuset źródeł. Opowiem, jak to działa od środka i jakie decyzje okazały się najważniejsze. Porównam graf wiedzy z prostszymi i alternatywnymi podejściami — od wiki, przez RAG nad transkryptami, po GraphRAG od Microsoftu — i pokażę, gdzie każde z nich się kończy. Będzie o roli człowieka w całym procesie, o śledzeniu pochodzenia każdego faktu i o tym, gdzie graf się u nas nie sprawdził.

To prelekcja na ścieżkę biznesową, bez wchodzenia w implementację.

O AI w pracy mówi się dużo, ale większość osób nietechnicznych kończy na tym samym: okno czatu, „napisz maila” i lekkie rozczarowanie. Gołe AI jest do niczego — model bez dostępu do niczego zna świat, ale nie zna Twojej firmy. Cała moc jest w podłączeniu: Microsoft 365, Google Docs, Calendar, Drive, SharePoint, a do tego warstwa własna, czyli baza wiedzy firmy i connectory do systemów sprzedażowo-księgowych.

Pokażę na żywo, jak od zera zbudować takiego asystenta: czym są connectory (demo na Google Calendar i KSeF MCP), czym jest skill, czyli rozpisana procedura zamiast pojedynczego zdania, oraz jak spiąć całość w Projects. Osobny blok poświęcę RODO i planowi Teams: brak trenowania modelu na danych firmy, administrator zarządzający connectorami, wymuszone konta firmowe i dashboard adopcji dla zarządu.

Wszystko na przykładach z mojej praktyki i ze szkoleń dla firm MŚP. Wyjdziesz z konkretnymi krokami na pierwszy tydzień wdrożenia — co kliknąć w poniedziałek rano.