Koniec inżyniera aplikacji: Dlaczego następne 10 lat należy do twórców agentów AI

Historia ma zabawny zwyczaj rymowania się, zazwyczaj dokładnie wtedy, gdy zaczynamy czuć się zbyt komfortowo.

Wyobraź sobie końcówkę lat 90. Jeśli potrafiłeś zmusić HTML i odrobinę Perla lub PHP do działania jako funkcjonująca strona internetowa, byłeś czarodziejem. Byłeś Inżynierem Webowym (Web Engineer), a świat stał przed tobą otworem. Budowałeś witryny sklepowe internetu.

Przewińmy do 2009 roku. iPhone właśnie otworzył świat na nowo. Nagle nikogo już tak bardzo nie obchodziła twoja statyczna strona. Energia przeniosła się na Objective-C i Javę. Jeśli byłeś Inżynierem Aplikacji Mobilnych, pisałeś przyszłość. Budowałeś narzędzia, które ludzie nosili w kieszeniach.

A teraz spójrz na rok 2024. Powietrze znów wydaje się rzadkie i statyczne. App Store’y są przesycone; sieć jest zatłoczona. Ale pod powierzchnią zachodzi tektoniczna zmiana. Opuszczamy erę Interfejsu i wkraczamy w erę Agenta.

W nadchodzącej dekadzie najbardziej wartościowym tytułem nie będzie "Full Stack Developer" czy "iOS Engineer". Będzie nim AI Agent Engineer (Inżynier Agentów AI).

Nowa zmiana tektoniczna

To nie jest kolejna wojna frameworków ani nowy język programowania do nauki. To fundamentalna zmiana w tym, kto wykonuje pracę.

Przez ostatnie dwadzieścia lat inżynieria oprogramowania polegała na budowaniu jasnych, deterministycznych ścieżek, przez które ludzie mogli się przeklikiwać. Ty budowałeś przycisk; człowiek go klikał; kod wykonywał funkcję. Człowiek był mózgiem; oprogramowanie było mięśniami.

Ta dynamika właśnie się odwraca.

W Erze Agentów (Agentic Era) oprogramowanie dostarcza mózg. Twoim zadaniem nie jest już budowanie przycisku do kliknięcia dla człowieka. Twoim zadaniem jest zbudowanie cyfrowego pracownika, który decyduje, kiedy kliknąć przycisk, albo jeszcze lepiej – dochodzi do wniosku, że przycisk w ogóle nie jest potrzebny.

Buduję produkty od ponad dziesięciu lat i czuję, jak ziemia się porusza. Jeśli potrafisz dziś napisać agenta – takiego, który służy tobie, automatyzuje twój workflow lub obsługuje twoich klientów – masz taką samą dźwignię, jak ten dzieciak w 1999 roku, który właśnie nauczył się, jak wrzucić biznes do sieci.

Ale oto brutalna prawda: Jeśli odmówisz nauki tego, jeśli będziesz kurczowo trzymać się czysto deterministycznego kodowania, ryzykujesz, że staniesz się cyfrowym odpowiednikiem zecera w erze desktop publishing.

Odczarowywanie magii: Narzędzia i Kontekst

Kiedy ludzie słyszą "AI Agent", wyobrażają sobie Skynet albo jakąś niemożliwie skomplikowaną architekturę sieci neuronowej. Przebijmy się przez ten szum.

Budowanie agenta to nie magia. To inżynieria. I sprowadza się do dwóch rzeczy: Narzędzi (Tools) i Kontekstu (Context).

Zauważyłem, że większość programistów zbytnio to komplikuje. Myślą, że muszą trenować modele. Nie musisz. Modele – Claude, GPT-4, Llama – są wystarczająco bystre. Twoim zadaniem jest dać im ręce i pamięć.

1. Narzędzia (Dawanie modelowi rąk)

Duży Model Językowy (LLM) to tylko mózg w słoiku. Potrafi myśleć, ale nie może dotknąć świata. "Agent" to po prostu LLM, któremu dano dostęp do endpointów API lub komend CLI.

Mówisz modelowi: "Oto narzędzie o nazwie list_files. Oto narzędzie o nazwie read_file. Oto narzędzie o nazwie send_email".

2. Kontekst (Nadawanie modelowi kierunku)

Następnie definiujesz rolę. "Jesteś starszym inżynierem QA (Senior QA Engineer). Twoim celem jest naprawienie błędów typowania w tym repozytorium".

To wszystko. To jest główna pętla.

Jeśli używałeś Cursor lub Claude Code, widziałeś to w akcji. Nie mikrozarządzasz edycjami. Mówisz: "Napraw błędy typów w utils.ts".

Agent myśli: Okej, najpierw muszę zobaczyć plik. Decyduje się użyć narzędzia ls. Potem decyduje się użyć grep lub read. Zauważa błąd. Decyduje się napisać poprawkę. Uruchamia kompilator, żeby sprawdzić swoją pracę.

To jest przełom. To już nie jest tylko "czatowanie". To pętla decyzyjna. Model wybiera, po które narzędzia sięgnąć, aby rozwiązać problem, który mu dałeś.

Od Chatbotów do Silników Decyzyjnych

Przez ostatnie dwa lata tkwiliśmy w fazie "Czatu". Traktujemy AI jak mądrego bibliotekarza – zadajemy pytanie, on daje odpowiedź.

Ta faza się kończy.

Faza Agentowa (Agentic phase) polega na egzekucji. Chodzi o patrzenie na CLI nie jak na miejsce, w którym ty piszesz, ale jak na plac zabaw dla modelu.

Pomyśl o implikacjach dla startupów. W przeszłości, jeśli chciałem zbudować usługę do obsługi zwrotów dla klientów, musiałem zbudować UI, backend, bazę danych i zatrudnić zespół wsparcia do klikania przycisków.

Dziś mogę napisać agenta. Daję mu dostęp do API Stripe (Narzędzie) i naszej historii mailowej (Kontekst). Daję mu politykę: "Zrób zwrot, jeśli użytkownik jest niezadowolony w ciągu 7 dni". Agent czyta przychodzącego maila, decyduje, czy spełnia kryteria, uruchamia narzędzie zwrotu w Stripe i redaguje odpowiedź.

Bez UI. Bez kolejki ticketów supportu. Tylko cel i zestaw narzędzi.

"Brudny środek" budowania Agentów

Nie chcę tu malować utopii. Spędziłem ostatnie sześć miesięcy głęboko w okopach budowania agentów i powiem wam: to jest brudna robota.

Tradycyjne kodowanie jest logiczne. If X then Y. Działa albo się sypie.

Inżynieria agentowa jest probabilistyczna. Budujesz agenta, dajesz mu narzędzia, a on czasami decyduje się użyć młotka do otwarcia okna. Czasami halucynuje parametr, który nie istnieje.

To tutaj leży nowy zestaw umiejętności.

Bycie Inżynierem Agentów to nie tylko skrypty w Pythonie. To:

• Prompt Engineering jako Architektura: Projektowanie promptów systemowych tak, by ograniczyć zachowanie modelu.
• Eval Driven Development (Rozwój oparty na ewaluacji): Nie napiszesz testów jednostkowych dla kreatywności, więc budujesz potoki ewaluacyjne, by mierzyć, jak często agentowi udaje się wykonać zadanie.
• Projektowanie Narzędzi (Tool Design): Tworzenie interfejsów API, które są wystarczająco "czyste", by model je zrozumiał bez gubienia się.

Widziałem agentów, którzy utknęli w nieskończonych pętlach, próbując naprawić błąd, który sami stworzyli. Widziałem, jak pewnie usuwają niewłaściwy plik. Taka jest rzeczywistość. Ale rozwiązywanie tych punktów tarcia jest dokładnie tym miejscem, gdzie tworzy się wartość.

Praktyczne wnioski: Jak zacząć dzisiaj

Gdybym zaczynał dziś od zera lub chciał zmienić kierunek kariery, oto co dokładnie bym zrobił:

1. Przestań budować GUI: Przynajmniej w swoich projektach pobocznych. Spróbuj rozwiązać problem bez frontendu. Czy potrafisz rozwiązać go za pomocą CLI i LLM?
2. Poznaj Protokół Interfejsu: Zrozum, jak działa function calling w OpenAI albo tool use w Anthropic. To jest TCP/IP ery agentów.
3. Buduj "Wykonawcę", a nie "Gadułę": Nie buduj bota, który odpowiada na pytania o twój kalendarz. Zbuduj bota, który zarządza twoim kalendarzem. Daj mu możliwość usuwania wydarzeń. Poczuj ten strach przed daniem AI dostępu do zapisu (write access). Wtedy naprawdę zaczynasz się uczyć.
4. Opanuj Zarządzanie Kontekstem: Naucz się, jak upchnąć właściwe informacje w oknie kontekstowym bez jego przepełniania. RAG (Retrieval-Augmented Generation) to dopiero początek.

Szansa przed nami

Patrzymy w przyszłość, w której pojedynczy programista, uzbrojony we flotę wyspecjalizowanych agentów, może wykonać pracę 20-osobowego startupu.

Bariery wejścia dla tworzenia spadają do zera. Ale bariery wejścia dla orkiestracji – dla zrozumienia, jak połączyć te mózgi razem – stają się nową fosą (moat).

Dziesięć lat temu zatrudniano cię do pisania kodu. Dziś zatrudnia się cię do zaprojektowania systemu, który pisze kod.

Pociąg odjeżdża ze stacji. Możesz albo stać na peronie, ściskając swoje stare frameworki, albo wskoczyć na pokład i pomóc budować tory.

Budujmy.