Agentic engineering: jak budujemy platformy eCommerce z agentami AI

Agentic engineering to inżynieria oprogramowania, w której agent AI wykonuje większość pisania kodu, ale nie podejmuje decyzji i nie dotyka niczego nieodwracalnego bez zgody człowieka. Sedno jest przewrotne: skoro agent pisze wielokrotnie szybciej, to nie pisanie jest już wąskim gardłem, tylko weryfikacja. Dlatego cały proces budujemy wokół sprawdzania, a nie wokół generowania: automatyczne bramki (typecheck, build, testy, lint), adwersarialny przegląd przez drugi model i człowiek, który trzyma architekturę, ryzyko i rękę na akcjach nieodwracalnych, takich jak deploy, migracja bazy czy operacja na danych klienta. Dla klienta to znaczy jedno: szybciej i bezpieczniej naraz, bo tempo bierze się z agenta, a bezpieczeństwo z dyscypliny wokół niego. To nie jest "AI pisze kod, my patrzymy". To inżynieria, w której AI jest najszybszym narzędziem, a nie osobą odpowiedzialną.

Czym agentic engineering jest, a czym nie jest

Agentic engineering różni się od zwykłego "używania AI do kodu" jednym: agent działa w pętli, sam sięga po pliki, uruchamia testy, czyta błędy i poprawia, ale robi to wewnątrz ram, które ktoś dla niego ustawił. Przeciwieństwem jest vibe coding: klepanie promptami bez specyfikacji, bez testów i bez zrozumienia, co powstało. Vibe coding wygląda imponująco do pierwszego prawdziwego problemu, a potem nikt nie wie, dlaczego system robi to, co robi. Nas od tego dzieli nie lepszy prompt, tylko to, co agent dostaje na wejściu i co dzieje się z jego wynikiem.

Spec przed kodem: agent buduje na planie, nie na domysłach

Zanim agent napisze pierwszą linijkę, istnieje plan. U nas to etap Blueprint: opisane zachowanie systemu, model danych, konwencje repozytorium i granice zakresu. Agent buduje na podstawie tej specyfikacji, nie na podstawie domysłów, bo model, który zgaduje intencję, zgaduje też architekturę, a to najdroższy rodzaj pomyłki. Dobra specyfikacja jest zresztą tym, co sprawia, że agent w ogóle jest szybki: im mniej musi zgadywać, tym mniej rund poprawek.

Dlaczego weryfikacja, a nie pisanie, jest dziś wąskim gardłem

Kiedy generowanie kodu tanieje i przyspiesza kilkukrotnie, uwaga przenosi się na to, co nie przyspieszyło: potwierdzenie, że kod jest poprawny, bezpieczny i robi dokładnie to, co miał. To jest nowe wąskie gardło. Zespół, który tego nie rozumie, produkuje po prostu więcej niesprawdzonego kodu, czyli więcej długu, tyle że szybciej. Dlatego w agentic engineering większość wysiłku inżynierskiego przenosi się z pisania na weryfikację, a większość tej weryfikacji da się zautomatyzować.

Cztery bramki, które kod przechodzi zanim zobaczy go człowiek

Każda zmiana agenta przechodzi przez ten sam zestaw bramek co zmiana człowieka, tylko szybciej, bo agent uruchamia je sam w pętli:

• Typecheck w trybie strict wyłapuje całą klasę błędów, których model nie widzi, bo pisze lokalnie, a typ pilnuje spójności całego systemu.
• Build potwierdza, że projekt się składa i uruchamia, a nie tylko wygląda poprawnie w edytorze.
• Testy sprawdzają zachowanie, zwłaszcza tam, gdzie błąd kosztuje: płatności, stany magazynowe, migracje.
• Lint trzyma jeden styl i jedne konwencje, żeby kod od agenta wyglądał, jakby napisał go ten sam zespół.

Agent nie kończy zadania, dopóki wszystkie cztery nie są zielone. To pierwsza linia obrony i najtańsza, bo działa bez udziału człowieka. Ale zielone bramki mówią, że kod działa, nie że jest dobry.

Adwersarialny review: drugi model szuka dziur, nie chwali

Dlatego dokładamy drugą warstwę: adwersarialny przegląd, w którym osobny model dostaje zadanie znaleźć w zmianie dziury, a nie ją pochwalić. Szuka przypadków brzegowych, założeń, które się nie utrzymają, luk bezpieczeństwa i miejsc, gdzie kod robi coś subtelnie innego niż specyfikacja. Model, który pisał, i model, który krytykuje, patrzą inaczej, i to napięcie wychwytuje rzeczy, które jednemu przejściu umykają. Dopiero po tym kod trafia do człowieka, już przefiltrowany.

Człowiek zostaje na decyzjach i ryzyku

Automat odsiewa błędy, ale nie podejmuje decyzji. Człowiek zostaje tam, gdzie stawką jest osąd: wybór architektury, kompromis między prostotą a elastycznością, ocena, czy dana zmiana jest warta ryzyka. To są rzeczy, których nie delegujemy agentowi, bo odpowiedzialność za platformę klienta jest po naszej stronie, nie po stronie modelu. Cały podział ról widać najprościej etap po etapie:

Agent przyspiesza każdy etap; człowiek trzyma decyzje i wszystko, czego nie da się cofnąć.

Akcje nieodwracalne to najtwardsza granica procesu

Kod można przepisać, test dopisać, źle nazwaną funkcję poprawić. Nie da się cofnąć wdrożenia, które zepsuło zamówienia w środku dnia, ani migracji, która nadpisała dane, ani skryptu, który skasował coś na produkcji. Dlatego wszystko z tej kategorii przechodzi przez człowieka, zawsze, niezależnie od tego, jak pewny jest agent. Zielona bramka to warunek konieczny, nie zgoda na wdrożenie.

Bezpieczeństwo: least-privilege i dane klienta na kopiach

Bezpieczeństwo w tym modelu pracy zaczyna się od dostępów. Agent działa na zasadzie least-privilege: dostaje minimum uprawnień potrzebnych do zadania i nic ponad to, więc nawet pomyłka ma ograniczony zasięg. Na danych klienta nie pracujemy w miejscu, gdzie żyją: agent i testy dostają kopie, a nie produkcyjną bazę. Sekrety i klucze trzymamy poza zasięgiem modelu. To nie jest nieufność wobec narzędzia, tylko ta sama zasada, którą stosuje się wobec każdego procesu automatycznego: zakładasz, że coś kiedyś pójdzie nie tak, i projektujesz tak, żeby skutek był mały.

Reużywalny rdzeń: kolejny projekt startuje z wyższego pułapu

Jest jeszcze jeden powód, dla którego ten sposób pracy jest szybki, i nie ma go w hasłach o AI. Kolejny projekt nie zaczyna się od zera. Sprawdzone fundamenty, wzorce integracji, warstwa automatyzacji i konwencje przenoszą się między wdrożeniami, więc agent startuje z wyższego pułapu, a bramki i review są już ustawione. To część tego, jak w ogóle da się dowozić platformę w stałej cenie i terminie: ryzyko wyceny bierzemy na siebie, bo duża część rdzenia jest już zbudowana i przetestowana. Sam etap budowy opisujemy szerzej na stronie Engineering, a warstwę automatyzacji, która wchodzi do środka platformy, na stronie AI Automation.

Agentic engineering nie jest obietnicą, że AI zbuduje sklep samo, ani straszeniem, że AI zepsuje wszystko. To trzeźwy środek: najszybsze dostępne narzędzie do pisania kodu, zamknięte w procesie, który to narzędzie kontroluje. Jak ten proces wygląda w praktyce na konkretnym zadaniu, pokazujemy krok po kroku w tekście o czyszczeniu katalogu z Claude Code. Różnica między platformą, która działa za dwa lata, a taką, którą ktoś będzie ratował, nie leży w tym, czy użyto AI. Leży w tym, co AI dostało na wejściu i kto sprawdził jego wynik.