London AI Engineer Summit 2026 miał być świętem postępu. Zamiast tego poczułem się jak lustro trzymane przed zawodem w samym środku załamania nerwowego.
Przez trzy dni na początku kwietnia setki inżynierów AI, budowniczych platform i badaczy zebrało się, aby podzielić się tym, czego się nauczyli. Pojawił się wzorzec: wszyscy budują z agentami, nikt nie wymyślił, jak je kontrolować, branża jest podzielona co do tego, czy działać szybko, czy myśleć ostrożnie, a cała przesłanka, że AI uczyni nas bardziej produktywnymi, została odwrócona w coś mroczniejszego.
Oto, czego naprawdę się nauczyliśmy.
Dlaczego inżynierowie AI kodują z agentami, których nie potrafią kontrolować?
Najszczersza rozmowa na summicie odbyła się na korytarzu, a nie na scenie. Inżynier ze średniej wielkości firmy fintech opisał problem tak: “Uruchamiam prompt, a trzy godziny później mój agent przepisał połowę codebase, dodał funkcje, o które nie prosiłem, i pochłonął £800 mocy obliczeniowej. Nie mogę odejść od biurka.”
To jest FOMAT: Fear of Missing Attention Time. To nie żart - to definiujący niepokój AI Engineering 2026.
Wąskie gardło orkiestracji
Wszyscy na summicie używali agentów. GitHub Copilot, Claude, niestandardowe frameworki agentowe - narzędzia dojrzały. Ale orkiestracja nie. Luka między “mam agenta” a “mój agent robi to, co zamierzałem, i nic więcej” jest ogromna.
Problem przejawia się na trzy sposoby:
Ucieczka tokenów. Agenci nie mają naturalnych punktów zatrzymania. Bez wyraźnych zabezpieczeń iterują w nieskończoność. “Jeszcze jeden refaktoring,” myśli agent, i nagle spaliłeś swój miesięczny budżet.
Rozszerzenie zakresu. Prośba o “poprawienie obsługi błędów” staje się “przepisz cały system obsługi błędów, dodaj obserwowalność, zrefaktoruj warstwę logowania i zaimplementuj rozproszone śledzenie.” Agent nie pomylił się - był dokładny. Ale to nie było to, o co prosiłeś.
Nieprzewidywalna latencja. Nie można wiedzieć, jak długo potrwa zadanie agentowe. Zależy to od tego, ile podzadań agent zdecyduje się uruchomić, ile błędów napotka i czy zdecyduje się ponowić próbę czy zmienić kierunek. To sprawia, że przepływy pracy sterowane agentami są niemożliwe do zaplanowania w systemach produkcyjnych.
Jaki był konsensus summitu (a jaki nie)
Nie było konsensusu co do rozwiązań. Niektóre zespoły używają twardych limitów tokenów. Inne wdrażają “punkty kontrolne agenta” - zmuszające agentów do zatrzymania się i poproszenia o pozwolenie przed kontynuowaniem. Kilka zmierza w kierunku hierarchicznych systemów agentowych, gdzie “agent-menadżer” nadzoruje agentów roboczych i może je przerwać.
Podejście FlowHunt - jawne definicje przepływów z węzłami agentów, obsługą błędów i logiką rozgałęziania - zostało wymienione kilka razy jako potencjalny wzorzec. Idea: nie pozwól agentom decydować o strukturze przepływu pracy. Zdefiniuj ją z góry, a następnie pozwól agentom wykonywać poszczególne kroki.
Ale nawet to wydawało się plastrem. Prawdziwy problem polega na tym, że zachowanie agenta jest z natury probabilistyczne. Można zmniejszyć wariancję, ale nie można jej wyeliminować.
Jak podział OpenAI-Anthropic przekształcił to, co znaczy “dobry kod”?
W poniedziałek rano Ryan Lopopolo z OpenAI wszedł na scenę i wygłosił keynote, który można podsumować jako: Przestań czytać kod. Zostań miliarderem tokenów.
Jego argument: w świecie agentowym objętość kodu jest metryką, która się liczy. Twój agent powinien generować tysiące linii dziennie. Twoim zadaniem jest zdefiniowanie specyfikacji outputu i pozwolenie agentowi maksymalizować przepustowość. Czytanie i rozumienie każdej linii jest wąskim gardłem. Zaufaj testom. Zaufaj agentowi. Działaj szybko.
W środę Mario Zechner z Anthropic wygłosił kontr-keynote: Zwolnij i przeczytaj ten pieprzony kod.
Jego argument: prędkość to pułapka. Każda linia kodu, którą napisze twój agent, jest zobowiązaniem. Musisz ją zrozumieć, rozumować o niej i umieć ją utrzymać. Zespoły, które wygrają za pięć lat, to te, które przedkładają jasność i intencję nad szybkość. Agenci powinni być narzędziami do myślenia, a nie do bezmyślnego generowania kodu.
Spektrum
Summit podzielił się z grubsza na trzy obozy:
| Pozycja | Zwolennicy | Podejście | Ryzyko |
|---|---|---|---|
| Maksymalista tokenów | OpenAI, niektórzy inżynierowie scale-up | Pozwól agentom agresywnie generować; skup się na jakości outputu poprzez testowanie | Niemożliwe do utrzymania codebasy, dług bezpieczeństwa, kruchość techniczna |
| Intencjonalny środek | Większość inżynierów enterprise | Używaj agentów do rusztowania; ludzie dostarczają architekturę i gust | Wolniejsza prędkość, ale bardziej stabilne systemy |
| Kod-najpierw | Anthropic, niektórzy inżynierowie badawczy | Agenci wspomagają ludzkie myślenie; ludzie piszą większość kodu | Niższa przepustowość, ale najwyższa jakość kodu |
Żadna ze stron nie jest w błędzie. Spór dotyczy tego, jak wygląda porażka. Lopopolo optymalizuje pod kątem szybkości iteracji. Zechner optymalizuje pod kątem zrównoważoności. W 2026 roku zespoły uczą się, że nie można optymalizować obu.
Problem rozmów kwalifikacyjnych
Jedna konkretna konsekwencja: rekrutacja jest zepsuta. Jeśli jesteś maksymalistą tokenów, nie obchodzi cię, czy kandydat potrafi kodować - obchodzi cię, czy potrafi efektywnie tworzyć prompty i oceniać output agenta. Jeśli jesteś kod-najpierw, chcesz widzieć głębokie techniczne rozumowanie.
Więc kiedy kandydat wchodzi na rozmowę, ani rozmówca, ani kandydat nie wiedzą, według jakiego frameworka są oceniani. Jeden z uczestników summitu opisał to jako “rozmowę kwalifikacyjną we mgle.”
Gotowy na rozwój swojej firmy?
Rozpocznij bezpłatny okres próbny już dziś i zobacz rezultaty w ciągu kilku dni.
Dlaczego IDE umierają, podczas gdy ruch na GitHubie eksploduje?
GitHub zgłosił 15-krotny wzrost ruchu rok do roku. Cloudflare odnotował podobne skoki. Tymczasem tradycyjne IDE - VS Code, JetBrains, Sublime - widzą spadek użytkowania w zespołach AI-native.
To wydaje się sprzeczne, dopóki nie zrozumiesz, co się naprawdę dzieje.
IDE było lokalnym narzędziem do myślenia
IDE zostało zaprojektowane dla pojedynczego dewelopera, aby pisać kod lokalnie. Miało podświetlanie składni, autouzupełnianie, narzędzia do debugowania i drzewo plików. Było samodzielnym środowiskiem.
Ten model się załamuje, gdy twoim “deweloperem” jest agent. Agent nie potrzebuje podświetlania składni. Nie potrzebuje debuggera. Potrzebuje:
- Dostępu do wielu plików jednocześnie
- Możliwości uruchamiania kodu i oglądania wyników
- Integracji z kontrolą wersji
- Funkcji współpracy (ponieważ agent i człowiek pracują razem)
Wszystko to żyje teraz w przeglądarce. GitHub Codespaces, VS Code Web i podobne narzędzia zastępują lokalne IDE.
Co naprawdę rośnie
Skok ruchu na GitHubie to nie deweloperzy piszący kod w przeglądarce. To deweloperzy przeglądający, komentujący i łączący kod generowany przez agentów. To warstwa współpracy eksploduje, a nie warstwa edycji.
Dlatego Cloudflare również widzi skoki ruchu - deweloperzy używają infrastruktury chmurowej do uruchamiania agentów i orkiestrowania przepływów pracy. Model “lokalne IDE + lokalne środowisko deweloperskie” jest zastępowany przez “cloud-native orkiestracja agentów + przegląd w przeglądarce.”
L33T C0d3 jest martwy
Jedna sesja miała dokładnie taki tytuł. Punkt: romantyczne pojęcie genialnego inżyniera, samotnego przy klawiaturze, tworzącego elegancki kod - to koniec. Kod jest teraz wynikiem współpracy między człowiekiem a agentem. Umiejętności, które się liczą, to:
- Prompt engineering (jak określić, czego chcesz)
- Ocena outputu (czy kod agenta jest dobry?)
- Myślenie architektoniczne (w jakiej strukturze agent powinien pracować?)
- Integracja (jak kod generowany przez agenta pasuje do istniejących systemów?)
Pisanie eleganckiego kodu nie jest już podstawową umiejętnością. To coś, co robią agenci. Ludzie robią wszystko inne.
Co naprawdę dzieje się z MCP - martwe czy kwitnące?
To była najbardziej myląca debata na summicie.
Z jednej strony indywidualni AIE i opiekunowie frameworków agentów mówili: “MCP jest martwe. Nie potrzebujemy go. Nasi agenci mogą po prostu bezpośrednio wywoływać API.”
Z drugiej strony architekci enterprise i zespoły bezpieczeństwa mówili: “Adopcja MCP przyspiesza szybciej, niż możemy dla niej budować narzędzia.”
Oba stwierdzenia są prawdziwe. Opisują różne populacje.
Dlaczego AIE myślą, że MCP jest martwe
Dla samotnego dewelopera budującego prostego agenta MCP dodaje tarcia. Musisz:
- Definiować serwery MCP dla swoich narzędzi
- Zarządzać narzutem protokołu
- Obsługiwać uwierzytelnianie i autoryzację
- Wdrażać i utrzymywać serwery
Łatwiej po prostu dać agentowi bezpośredni dostęp do API i pozwolić mu ogarnąć resztę.
Dlaczego przedsiębiorstwa szybko adoptują MCP
Dla organizacji uruchamiającej agentów w produkcji MCP staje się nagle niezbędne. Oto dlaczego:
Izolacja bezpieczeństwa. Nie chcesz, aby agenci mieli bezpośredni dostęp do twojej bazy danych, systemu płatności lub danych klientów. MCP pozwala utworzyć kontrolowany interfejs, który agenci mogą wywoływać bez ujawniania podstawowych systemów.
Audytowalność. Każda akcja agenta przechodzi przez serwer MCP, który ją loguje. Masz pełny zapis tego, co agent zrobił i dlaczego.
Zarządzanie danymi uwierzytelniającymi. Zamiast osadzać klucze API w promptach agenta lub zmiennych środowiskowych, serwery MCP bezpiecznie zarządzają danymi uwierzytelniającymi.
Ograniczanie prędkości i egzekwowanie kwot. Możesz kontrolować, ile zasobów agent może skonsumować.
Według CData Software 80% firm z listy Fortune 500 ocenia lub wdraża MCP na początku 2026 roku, głównie z tych powodów.
Rozwiązanie
Konsensus summitu: MCP nie jest martwe. Po prostu nie jest istotne dla 80% rozwoju AI, który jest eksperymentalny i solowy. Ale dla 20%, który jest produkcyjny i wielozespołowy, MCP staje się wymogiem.
Dlatego MCP Apps się mnożą. Anthropic, OpenAI i dostawcy zewnętrzni budują gotowe serwery MCP dla popularnych narzędzi (Salesforce, Slack, Jira, bazy danych). Przedsiębiorstwa mogą je adoptować bez budowania niestandardowych serwerów.
Dołącz do naszego newslettera
Otrzymuj najnowsze wskazówki, trendy i oferty za darmo.
Czy AI czyni nas bardziej produktywnymi, czy po prostu bardziej przepracowanymi?
Tutaj summit stał się mroczny.
AI miało być mnożnikiem siły. Mieliście spędzać mniej czasu na rutynowych zadaniach, a więcej na strategicznym myśleniu. Produktywność miała wystrzelić w górę.
Zamiast tego produktywność wystrzeliła w górę - a wraz z nią oczekiwania dotyczące obciążenia pracą.
Paradoks Jevonsa w czasie rzeczywistym
Paradoks Jevonsa, pierwotnie zastosowany do zużycia węgla, mówi: Kiedy zasób staje się bardziej wydajny, całkowite zużycie wzrasta, ponieważ zasób staje się tańszy i bardziej atrakcyjny.
W kontekście AI: Agenci uczynili generowanie kodu tańszym i szybszym, więc menadżerowie oczekują teraz, że każdy inżynier:
- Dostarczy 10x więcej outputu
- Napisze wyczerpującą dokumentację
- Zbuduje pełne zestawy testów
- Obsłuży internacjonalizację (i18n)
- Obsłuży przypadki brzegowe
- Zrobi to wszystko sam
Wzrost produktywności został pochłonięty przez zawyżone oczekiwania.
Co mówili inżynierowie
Jeden inżynier z londyńskiego startupu: “Kiedyś pisałem 500 linii kodu dziennie i czułem się produktywny. Teraz piszę 5000 linii dziennie - generowanych przez agentów - i jestem wyczerpany, ponieważ muszę to wszystko przeglądać, testować, dokumentować i wyjaśniać interesariuszom. Pracuję 60 godzin tygodniowo.”
Inny: “Mój menadżer mówi: ‘Masz teraz agenta, więc powinieneś być w stanie obsłużyć dwa razy więcej projektów.’ Nie jestem bardziej produktywny. Jestem po prostu bardziej zajęty.”
Badacz: “Agenci są dobrzy w generowaniu kodu. Nie są dobrzy w decydowaniu, jaki kod wygenerować. Ten ciężar decyzyjny przeniósł się całkowicie na ludzi. Nie automatyzujemy trudnej części; automatyzujemy łatwą część i zmuszamy ludzi do więcej myślenia.”
Martwy punkt produktywności
California Management Review UC Berkeley opublikowało badania w styczniu 2026 roku dokumentujące to zjawisko. Kluczowa myśl: Wdrożenie AI nie zmniejsza pracy; zmienia jej naturę.
Stara praca: pisanie kodu. Nowa praca: kierowanie agentami, ocenianie outputu, utrzymywanie jakości, zarządzanie rozszerzaniem zakresu.
Nowa praca jest trudniejsza poznawczo, nawet jeśli mniej pisania.
Dlaczego Europa jest tak niezdecydowana wobec AI Engineering?
Summit miał silny kontyngent europejski, a ich przesłanie było spójne: Europa nie porusza się tak szybko jak USA w adopcji AI Engineering.
Ciężar regulacyjny
EU AI Act jest wciąż wdrażany. Firmy nie są pewne co do odpowiedzialności. Jeśli agent AI podejmie decyzję, która zaszkodzi klientowi, kto jest odpowiedzialny? Firma? Dostawca modelu? Inżynier?
Ta niepewność jest paraliżująca. Wiele europejskich firm czeka, aby zobaczyć, jak potoczą się pierwsze procesy, zanim zbudują poważne systemy agentowe.
Luka umiejętnościowa
Tradycyjni inżynierowie oprogramowania w Europie nie stają się inżynierami AI w tym samym tempie co w USA. Istnieje sceptycyzm co do tego, czy umiejętności są przenośne. Wielu europejskich inżynierów czeka, aby zobaczyć, czy AI Engineering to prawdziwa ścieżka kariery, czy cykl hype’u.
Obawy dotyczące prywatności
Europa jest również bardziej ostrożna w kwestii obsługi danych. Agenci potrzebują dostępu do danych, aby być użyteczni. Ale europejskie firmy wahają się dać agentom dostęp do danych klientów, nawet z zabezpieczeniami MCP.
Droga naprzód
Europejscy inżynierowie na summicie nie byli anty-AI. Byli pro-ostrożnością. Nastawienie: “USA porusza się szybko i łamie rzeczy. My poruszamy się wolniej i staramy się nie łamać tak wiele. Za pięć lat zobaczymy, kto miał rację.”
Jak naprawdę zmieniają się role w AI Engineering?
Pod koniec summitu pojawił się wzorzec: Tradycyjne role inżynierów oprogramowania są wydrążane i zastępowane przez trzy nowe archetypy.
Trzy role
| Rola | Odpowiedzialność | Umiejętności |
|---|---|---|
| AI PM | Definiuje zachowanie agenta, metryki sukcesu, ograniczenia | Myślenie produktowe, projektowanie promptów, frameworki oceny |
| Niańka agenta | Monitoruje wykonanie, wyłapuje błędy, interweniuje w razie potrzeby | Debugowanie, obserwowalność, obsługa błędów, reagowanie na incydenty |
| Kształtujący gust | Ocenia jakość outputu, dostarcza feedback, kieruje udoskonalaniem | Code review, myślenie architektoniczne, ocena estetyczna |
Żadna z tych ról nie obejmuje pisania kodu w tradycyjnym sensie. Wszystkie obejmują kierowanie, ocenianie i udoskonalanie zachowania agenta.
Co znika
Role “juniora” są kompresowane. Nie ma już wyraźnej ścieżki od “mogę pisać prosty kod” do “mogę projektować systemy.” Pośrednie kroki są automatyzowane.
To tworzy urwisko umiejętnościowe: albo jesteś dobry w promptowaniu i ocenianiu (w takim przypadku jesteś wartościowy), albo nie (w takim przypadku konkurujesz z agentami).
Co rośnie
Role wymagające gustu, osądu i myślenia architektonicznego rosną. Podobnie jak role wymagające głębokiej wiedzy dziedzinowej (ponieważ agenci potrzebują ludzi do oceny, czy rozwiązują właściwy problem).
Summit nie miał konsensusu co do tego, czy to dobrze, czy źle. Niektórzy widzieli to jako wyzwolenie od rutynowego kodowania. Inni widzieli w tym zagrożenie dla zawodu.
Co zmieniło się między grudniem 2025 a lutym 2026?
Jedna sekcja summitu była poświęcona konkretnemu punktowi zwrotnemu: coś się zmieniło w ekosystemie agentów AI na przełomie roku.
Samoulepszające się oprogramowanie stało się realne
OpenClaw i podobne frameworki zaczęły umożliwiać agentom iteracyjne ulepszanie własnych wyników bez ciągłego promptowania przez człowieka. Zamiast “agencie, napisz funkcję do obliczenia X,” stało się “agencie, napisz funkcję do obliczenia X i ulepszaj ją, aż przejdzie wszystkie testy i obsłuży przypadki brzegowe.”
Kluczowa myśl, wyartykułowana przez kilku badaczy: Przestańcie prosić agentów o trywialne porady.
Zamiast prosić agenta, aby “ulepszył tę funkcję”, poproś go, aby “uczynił tę funkcję kuloodporną”. Pozwól mu zdecydować, co to znaczy. Agent:
- Napisze testy
- Znajdzie przypadki brzegowe
- Zrefaktoryzuje dla jasności
- Doda obsługę błędów
- Udokumentuje logikę
Wszystko bez proszenia o każdy krok.
To zmieniło model mentalny z “agent jako narzędzie” na “agent jako autonomiczny współtwórca”. I zmieniło dynamikę obciążenia pracą: zamiast agentów zmniejszających pracę ludzi, zwiększyli ją (ponieważ ludzie musieli teraz oceniać znacznie bardziej wyrafinowany output agenta).
Sprzeczności, z którymi żyjemy
Summit zakończył się bez rozstrzygnięcia, co wydawało się szczere. Oto sprzeczności, które definiują AI Engineering w kwietniu 2026:
Sprzeczność 1: Agenci są wystarczająco potężni, aby być niebezpieczni (FOMAT jest realny), ale nie wystarczająco potężni, aby można im było zaufać bez nadzoru.
Sprzeczność 2: Szybkość i jakość są traktowane jako przeciwieństwa, ale obie są konieczne.
Sprzeczność 3: MCP jest jednocześnie martwe (dla osób indywidualnych) i kwitnące (dla przedsiębiorstw).
Sprzeczność 4: AI uczyniło nas bardziej produktywnymi, ale też bardziej przepracowanymi.
Sprzeczność 5: Wszyscy budują z agentami, ale nikt nie wymyślił, jak dobrze z nimi budować.
Sprzeczność 6: AI Engineering to prawdziwa ścieżka kariery, ale umiejętności, o których myśleliśmy, że będą się liczyć (pisanie kodu), już się nie liczą.
To nie są problemy do rozwiązania. To napięcia do zarządzania. Zespoły, które wygrają w 2026 roku, to te, które uznają te sprzeczności, zamiast udawać, że nie istnieją.
Najczęściej zadawane pytania
Co zabieramy ze sobą
Summit w Londynie był migawką zawodu w okresie przejściowym. AI Engineering jest realne, ale nie jest tym, czym myśleliśmy, że będzie. Jest bardziej chaotyczne, bardziej sprzeczne i bardziej zależne od ludzi, niż sugerował hype.
Najlepsi inżynierowie na summicie nie byli tymi z najbardziej wyrafinowanymi agentami. Byli tymi, którzy rozumieli, że agenci to narzędzie do myślenia, a nie jego zastępstwo. Byli tymi, którzy zbudowali procesy do zarządzania zachowaniem agenta, oceniania outputu i utrzymywania jakości. Byli tymi, którzy zaakceptowali, że wzrosty produktywności wiążą się z nowymi rodzajami pracy, a nie z mniejszą ilością pracy.
Jeśli budujesz systemy AI w 2026 roku, lekcje z summitu są jasne:
Orkiestracja liczy się bardziej niż zdolności agenta. Mierny agent z dobrą orkiestracją bije genialnego agenta bez kontroli.
Jasność jest cenniejsza niż szybkość. Szybkie poruszanie się i łamanie rzeczy działa, dopóki nie przestanie działać. W skali, nie działa.
Adopcja enterprise jest realna, ale indywidualna adopcja jest wciąż eksperymentalna. Jeśli jesteś samotnym deweloperem, możesz poruszać się szybko. Jeśli jesteś zespołem, potrzebujesz zabezpieczeń.
Umiejętności, które się liczą, zmieniły się. Prompt engineering, ocena outputu i myślenie architektoniczne to nowe kluczowe kompetencje.
Spodziewaj się pracować ciężej, nie łatwiej. AI jest mnożnikiem produktywności, ale zyski są pochłaniane przez wyższe oczekiwania. Planuj odpowiednio.
Summit nie odpowiedział na pytanie “Jak wygląda AI Engineering?” Pokazał nam odpowiedź: wygląda jak my, próbujący to ogarnąć w czasie rzeczywistym.
{{ cta-dark-panel heading=“Przestań ręcznie orkiestrować agentów” description=“Kreator przepływów FlowHunt pozwala definiować zachowanie agenta, ustawiać zabezpieczenia i automatyzować wieloetapowe zadania AI. Koniec z FOMAT. Koniec ze zgadywaniem, co robią twoi agenci.” ctaPrimaryText=“Wypróbuj FlowHunt za darmo” ctaPrimaryURL=“https://app.flowhunt.io/sign-in" ctaSecondaryText=“Zarezerwuj demo” ctaSecondaryURL=“https://www.flowhunt.io/demo/" gradientStartColor="#667eea” gradientEndColor="#764ba2” gradientId=“aie-summit-cta” }}
