Wiedza jest dziś o jeden prompt stąd, a rola staje się kwestią wyboru — nie ograniczenia. O zmianie, która zaskoczyła wszystkich, choć każdy mógł się jej spodziewać. Czy to chaos, czy najlepsze, co się przydarzyło zespołom produktowym?

Opis prelekcji wkrótce.

Największy błąd firm polega na tym, że traktują AI jako narzędzie produktywności dla pojedynczych osób, a nie jako impuls do zmiany sposobu działania całej organizacji.

czym różni się firma „używająca AI” od firmy „AI Native”,
jak AI zmienia sprzedaż, marketing, delivery, administrację, HR, zarządzanie wiedzą,
jak zidentyfikować procesy, które warto zautomatyzować jako pierwsze,
jak zacząć w małej/średniej firmie albo urzędzie bez wielkiego budżetu,
przykładowy model dojrzałości: od eksperymentów — do systemowego wdrożenia AI.

Jak projektować systemy, które nie tylko zbierają dane z urządzeń i procesów, ale realnie wspierają ludzi w podejmowaniu decyzji? Na przykładzie Ankiora pokażę architekturę safety-tech łączącą IoT, edge, integrację wielu dostawców urządzeń oraz AI jako warstwę kontekstowej analizy danych. Opowiem, jak edge działa u źródła: agreguje, porządkuje i ujednolica dane z różnych domen, tworząc solidną podstawę dla automatyzacji, analityki i niezawodnego działania operacyjnego. Następnie pokażę, jak AI skraca drogę od zdarzenia do reakcji: analizuje artefakty incydentów, wyciąga wnioski, ogranicza ilość informacji do ręcznej oceny, wspiera EnvControl w interpretacji danych środowiskowych oraz pomaga użytkownikom końcowym przez wirtualnego asystenta pierwszej pomocy w aplikacji mobilnej. To praktyczna opowieść o systemach, które nie dokładają kolejnego dashboardu, lecz zamieniają rozproszone sygnały w kontekst, decyzje, lepszą koordynację i szybsze działanie.

Wchodzisz jako pierwszy inżynier do startupu z 4M EUR fundingu. Platforma w miarę działa, klienci płacą, a pole boolean przyjmuje wartości: yes, no, true, false, null i puste. Gratulacje – to teraz Twój problem. No-code, vibe coding, Codex, Lovable – nieważne jakich narzędzi użyto. Ważne że produkt zarabia, ma klientów, więc nie możesz tego zaorać i przepisać od zera. Opowiem Ci, jak przeżyć pierwsze 90 dni: jak szybko przejąć kontrolę nad pożarami zanim wybuchną, czego potrzebujesz, żeby w ogóle zrozumieć co się dzieje, i jakie fundamenty wdrożyć, żeby cała konstrukcja się nie zawaliła. Backup, monitoring, CI/CD, kontrakty między komponentami – w kolejności, która ma sens dla żywego produktu. Historia oparta na dwóch prawdziwych przypadkach. Zero teorii, tylko sama praktyka, którą doświadczyłem na własnej skórze. I jedno pytanie na koniec: skoro AI pozwala zbudować MVP w weekend, to kto będzie ratował te produkty, gdy zaczną zarabiać?

Event Storming facilitation is becoming a new hard skill, but learning it is painfully slow. You only get better by running workshops, and most engineers don't get to run many – often in the same domains, with the same goals and with the same people over and over again. That's definitely not enough to develop real skills. So we asked a question: What if Event Storming participants weren't people at all? In this talk, we'll walk through our case study of building an agent-driven Event Storming learning tool using LangGraph. The core challenge turned out to be multi-agent collaboration: how agents communicate, coordinate and work together toward a shared goal. We'll show which communication structures worked for us, where collaboration patterns helped and what failed along the way. We'll also briefly touch on how we observe and debug such systems in practice, using real examples from a running multi-agent setup.

Większość z nas używa już AI w kodzie, niestety zwykle w pojedynkę. Pytanie, które się pojawia to co, gdy z AI ma korzystać cały zespół, na każdym etapie powstawania oprogramowania? Sprawdziliśmy to w kilku projektach w organizacji, gdzie AI pojawił się na każdym etapie cyklu – od wymagań, przez implementację i testy, po review i utrzymanie. Najwięcej nauczyliśmy się o granicach: co naprawdę warto zautomatyzować, a gdzie wciąż niezbędna jest akceptacja człowieka – w review, w decyzjach architektonicznych, w wyłapywaniu kodu, który tylko „wygląda dobrze". Dodatkowo, jak dzielić się wiedzą i wdrażać zespół, żeby nie skończyć z chaosem różnych konfiguracji oraz wysokimi fakturami za tokeny.

W ostatnich miesiącach brałem udział w eksperymencie AI-driven SDLC, którego celem było stworzenie narzędzia do autonomicznej budowy featurów. W trakcie projektu projektowałem i implementowałem agentów odpowiedzialnych za ocenę jakości oraz cały agentowy QA pipeline. Podczas prezentacji mógłbym opowiedzieć o architekturze rozwiązania, podejściu do weryfikacji pracy agentów, wyzwaniach, błędach, które popełniliśmy, oraz o tym, co faktycznie działa w praktyce. Na pewno chciałbym skupić się na realnych wnioskach, które słuchający będą mogli zaimplementować w swoich projektach.

Agentów AI jest dziś wszędzie pełno – ale prawie nikt nie daje im porządnej, utrzymywanej bazy wiedzy – a to ona decyduje, czy agent zgaduje, czy realnie ogarnia Twój kontekst. Pokażę na działającym przykładzie, skąd Twój agent może brać wiedzę: drugi mózg (LLM Wiki Karpathy'ego) — żywa baza w markdown, czytelna dla agenta i człowieka, z której agent czyta i którą sam utrzymuje. Bez teorii, bez sprzedaży: co, jak i czym to zbudować — i dlaczego context engineering bije prompt engineering.