✨ TechLead Amsterdam 2026 - Podsumowanie konferencji dla liderów i inżynierów.

Krótka notatka po TechLead Conf Amsterdam 2026 - dwudniowej edycji o adopcji AI w organizacjach, z perspektywy praktycznych wniosków dla liderów i inżynierów.

👀 Ogólne wrażenia

• Konferencja nastawiona na AI
• Większość prezentacji dobrze się słuchało, ale zdarzało się, że były to powielane trywializmy
• W jednym budynku (hali) odbywały się 3 różne konferencje, więc nasza miała zapewnione słuchawki (Silent Disco), aby dało się usłyszeć prelegenta
• Każda prelekcja kończyła się sekcją Q&A
• Duży nacisk na networking:
  • Before i After party
  • Każdy miał swój kolor naklejek z którymi można się było wymienić z innymi uczestnikami
  • Przy stolikach były Ice Breakers jakby ktoś nie wiedział jak zagadać

💡 Główne insighty

• AI przesuwa pracę inżyniera z „pisania kodu” na definiowanie problemu, produkt i orkiestrację zmian - Product Engineer.
• Samo używanie AI nie daje ROI. Warto mierzyć realny wpływ na workflow, lead time, jakość i wartość dla klienta.
• AI wzmacnia to, co już mamy: dobry proces przyspieszy, słaby proces szybciej wyprodukuje chaos, dług i słaby kod.
• AI nie zastąpi inżynierów, bo to inżynierowie podejmują decyzje. Jeżeli inżynierowie nie podejmują decyzji, to nie wykonują swojej pracy.

🎤 Prelekcje

🧠 Effective Thinking in the Age of Augmented Tooling

• AI przesuwa fokus z pisania składni, formatowania i boilerplate’u na logikę, produkt i innowację.
• Największa wartość człowieka jest dziś w myśleniu: definiowaniu problemu, zadawaniu pytań i ocenie wyników.
• Najważniejszym “językiem programowania” staje się angielski, bo jakość promptu wpływa na jakość rozwiązania.
• Słabe oprogramowanie często wynika nie ze słabego kodu, tylko ze źle zebranych wymagań.
• Nie zaczynaj od rozwiązania. Najpierw dobrze nazwij problem, kontekst, ograniczenia i target.
• To już nie jest tylko rola PM-a. Developerzy też muszą myśleć problemami, nie tylko implementacją.
• Dobre pytanie zmienia strategię. W dobie AI kluczowe jest nie “co agent ma napisać”, tylko “jaki cel ma osiągnąć”.
• Agent loop: mierz → zmieniaj → weryfikuj → powtórz.
• Pętla działa tylko wtedy, gdy jesteśmy gotowi przyznać, że założenie było błędne i zmienić kierunek.
• Ustawiaj guardraile dla agentów, np. maksymalnie 3 iteracje, żeby nie kręcić pętli bez końca.

🚀 Why Engineers Must Become Multipliers in the AI-Era

• AI zmienia sposób budowania oprogramowania: narzędzia są lepsze, AI-assisted engineering staje się standardem, a prototypy mogą tworzyć też osoby nietechniczne.
• Fokus inżyniera przesuwa się z samego wykonywania zadań na rozumienie problemu, celu i wpływu.
• Inżynierowie coraz częściej odpowiadają za what, why i when, a nie tylko za how.
• Coraz więcej inżynierów staje się tech leadami swoich tematów, nawet bez formalnej zmiany roli.
• Rola Product Engineer zyskuje na znaczeniu: product + engineering = Product Engineer.
• Teza z rynku pracy: najbardziej poszukiwani są świetni generaliści i wąscy specjaliści, a “środek” ma mniejszy popyt (brzmi dyskusyjnie).
• Kompetencje miękkie stają się coraz ważniejsze: komunikacja, leadership, teamwork, empatia i rozumienie biznesu.
• Umiejętności managerskie są przydatne także dla IC: delegowanie, dzielenie dużych tematów, dawanie feedbacku i jasne instrukcje.
• Dobry inżynier w AI-erze to nie tylko ktoś, kto zna technologię, ale ktoś, kto rozwiązuje problemy i podnosi skuteczność innych.
• Jeżeli sprawisz, że 5 osób wokół Ciebie będzie o 20% lepszych, tworzysz większą wartość niż podnosząc tylko siebie o 20%.

🏗️ Building Blocks of an Agentic Engineering Platform: What SRE Taught Us About Running Agents

• Agent jako węzeł jest niedeterministyczny i może zwrócić błędny wynik “po cichu”, nawet przy statusie 200 OK / success.
• Każde uruchomienie agenta powinno być izolowane: osobny sandbox/MicroVM, minimalne uprawnienia, filtrowane wejścia i wyjścia.
• Agent potrzebuje wersjonowanego, wyszukiwalnego obrazu świata: kontekstu systemu, architektury, właścicieli, decyzji i zależności.
• Najłatwiejsza adopcja AI jest w CLI/CI: code review, build repair, dependency bumps, szukanie bugów.
• Agenci powinni być krokami pipeline’u za deterministycznymi bramkami: testy, checki i approvale nadal decydują, co trafia dalej.
• Warto dodać model gateway, przez który przechodzą wszystkie wywołania modeli. Dzięki temu zmiana providera nie wymaga przepisywania narzędzi.
• Mierz opłacalność agentów: koszt per commit/PR, cache hit ratio, udział pracy agenta, koszt tokenów per outcome.
• Ułatwiaj bezpieczne użycie: gotowe szablony z sandboxem, gatewayem i evalami, wewnętrzny marketplace skill/MCP oraz dystrybucja kontekstu.
• Agenci powinni przekazywać pracę przez artefakty, nie luźny chat: spec, plan, summary, schema check i content verification.
• Model organizacyjny: małe “half-pizza teams” / trzyosobowe zespoły, gdzie jedna osoba odpowiada za produkt, jedna za AI harness/platformę, jedna za jakość.
• Zasada ownershipu: You prompt it, you own it. Zespół, który uruchamia agenta, odpowiada za jego output na produkcji.
• Skalowanie AI w organizacji to bardziej dyscyplina niż zakup narzędzia: pathfinders, champions, zespoły i organizacja.

📈 Lean Tech: How to Lead on Creating More Value With AI

• Problemem nie jest adopcja AI: ok. 80% firm już go używa.
• Problemem jest brak przełożenia AI na realną wartość dla klienta i produktu.
• AI często poprawia lokalną produktywność, ale nie skraca całego value streamu.
  • Np. podsumowanie maila to “lokalna produktywność”
• Lean Tech to system uczenia się i tworzenia wartości dla klienta, nie program wdrażania narzędzi.
• Najpierw nawiguj na problem i przepływ wartości, dopiero potem dobieraj AI.
• Regularne kaizeny pomagają zespołowi brać ownership za użycie AI i stale poprawiać proces.

🧩 The Monorepo Multiplier: 10x Your Team with Better Architecture

• Teza prelegenta: monorepo powinno być domyślnym wyborem, a polyrepo tworzy “multiple versions hell”.
• Monorepo != monolit: chodzi o jedno repozytorium dla wielu projektów, nie jeden deployowalny system.
• Główne argumenty: łatwiejsze współdzielenie kodu, atomic commits, wspólne zależności, jeden CI/CD i lepsza współpraca.
• Monorepo ma sens szczególnie przy shared libs/design systemie, breaking changes, zmianach API i dużych refaktorach.
• W dobie AI dochodzi dodatkowa korzyść: agent ma większy kontekst do zmian.
• AI może widzieć backend API, shared libraries, dependency graph, wzorce innych zespołów i potencjalne breaking changes.
• Brzmi kontrowersyjnie: skala, ownership, uprawnienia, CI/CD, security i koszt jednego repo mogą być ogromnym wyzwaniem.
• Bardziej praktyczny wniosek: niekoniecznie “wrzućmy wszystko do jednego repo”, tylko “zwiększmy wspólny kontekst dla ludzi i AI”.

🛡️ Your Platforms Matter More Than Ever With AI

• AI przesuwa pracę z samego pisania kodu na orkiestrację zmiany: plan, design, review, CI/CD i operacje.
• Wejście AI mocno zwiększa volume pracy: więcej PR-ów, pushy i eksperymentów.
• Bottleneck przenosi się z pisania kodu na review, jakość, wdrożenie i utrzymanie.
• Mirror effect: AI wzmacnia to, co już mamy. Słaby kod/proces da więcej słabego kodu/procesu.
• Platforma powinna dawać golden path: template’y, CI/CD, policy-as-code, quality gates i narzędzia dla agentów.
• Kontekst nie oznacza automatycznie lepiej. Liczy się just-in-time context: właściwy kontekst we właściwym momencie.
• Za dużo nieistotnego kontekstu zwiększa liczbę błędów; trzeba mierzyć, przycinać, re-rankować i iterować.
• Dobre platformy zmniejszają wariancję: mniej losowych decyzji, mocniejsze defaulty, mniej cognitive loadu.

📊 Beyond the Hype Cycle: Driving Real ROI with AI in Your Organization

• Samo używanie AI nie oznacza automatycznie szybszego dowożenia ani realnego ROI.
• Usage != adoption: mierzenie aktywności w narzędziu jest jak mierzenie produktywności liczbą linii kodu.
• Adoption != integration: ludzie mogą używać AI, ale workflow nadal działa po staremu.
• Integration != value: automatyzacja złego procesu tylko szybciej skaluje nieefektywność.
• Saved hours != saved money: odzyskany czas musi przełożyć się na koszt, lead time, jakość albo wynik biznesowy.
• Mierz na 3 poziomach: individual, team i business. Nie udawaj, że metryki lokalne są od razu wartością biznesową.
  • „Copilot zaoszczędził 1000 godzin” to poziom individual, a często przekładamy go bezpośrednio na business.
• Wartością nie są funkcje, których nikt nie chciał. AI ma pomagać dowozić potrzebne zmiany.

🤝 Friends Don’t Let Friends Agent Alone

• Pokusa: “zróbmy wszystko agentami”. Rzeczywistość: łatwo zacząć dużo rzeczy i nie skończyć nic dobrze.
• AI jest multiplikatorem dobrych i złych nawyków zespołu.
• Bottleneckiem nigdy nie było samo pisanie kodu, tylko decyzja jaki kod chcemy napisać i dlaczego.
• Szybsi indywidualni developerzy nie tworzą szybkiej firmy, jeśli brakuje alignmentu.
• Pair programming pomaga nie “agentować samemu”: wymusza wyjaśnianie intencji, dzielenie się wiedzą i nieakceptowanie “fine”.

🧪 Interviewing in the Post-LLM World

• Rekrutacja musi zaakceptować świat z LLM: zamiast banować AI, warto jasno zachęcać do użycia i oceniać reasoning, nie sam output.
• Hiring jest jednym z najważniejszych procesów firmy, bo świetni ludzie są najważniejszym assetem.
• Zanim rekrutujesz, opisz rolę: co osoba będzie robić, z kim pracować, jakie KPI, jaki poziom supportu i autonomii.
• Nowe formaty rozmów: deep dive w zbudowaną rzecz, czytanie kodu, code review, RFC i system design.
  • Deep dive: nie chodzi o wynik, tylko o proces, decyzje, naukę, trade-offy, krytyczne myślenie i rozumienie domeny.
  • Reviewing code sprawdza pracę z legacy, dokumentacją, niejednoznacznością, feedbackiem i komunikacją.
  • RFC i system design dobrze pokazują structured reasoning, system thinking, trade-off analysis i clarity.
• Tips: lepiej zadać 3 dobre pytania niż 10 średnich; preferuj depth over breadth.
• Nie opieraj wszystkiego na live interview. Można użyć take-home, async + sync review i realniejszej współpracy z inżynierami.
• Unikaj ekstremistów: dawaj dylematy, trade-offy i sprawdzaj, czy kandydat potrafi zmienić zdanie.
• Scorecards standaryzują ocenę i zmniejszają subiektywizm.
• Testuj etapy rekrutacji wewnętrznie i mierz sukces: czas, accuracy, feedback od inżynierów i kandydatów.

🎓 Training Engineers for AI Without Turning Them into Prompt Monkeys

• Problem: firmy uczą ludzi optymalizacji promptów zamiast myślenia. Efekt: szybki output, płytkie zrozumienie, kruche systemy i brak ownershipu.
• DRY w dobie AI jest jeszcze ważniejsze: AI szybko powiela duplikację, a rozjazd logiki może wydarzyć się w dni, nie miesiące.
• Ustal zasady projektowe: kontekst domeny, stack, antywzorce, testy, review, performance i linki do ADR-ów. Traktuj je jak żywą dokumentację.
• Dla agentów ustaw jasny cel, kontekst i granice. Agent wykonuje, ale człowiek reviewuje, integruje i bierze odpowiedzialność.
• Warto robić ćwiczenia bez AI, żeby nie zanikło samodzielne rozumowanie.