Świat programowania zmienia się szybciej niż kiedykolwiek. Sztuczna inteligencja to już nie tylko trend. To realny element procesu wytwarzania oprogramowania. W tym przewodniku podzielę się własnym doświadczeniem pracy z agentami AI i dam Ci praktyczne wskazówki, jak używać ich w projektach opartych na Angularze. Dowiesz się, czym różni się Vibe Coding od AI-Assisted Codingu oraz jak wdrożyć agenta AI, by działał tak jak dodatkowy członek zespołu, pisząc kod zgodny z Twoimi zasadami, przewidywalny i łatwy do sprawdzenia.
Czym właściwie jest AI Agent?
AI agent to system programistyczny, który wykonuje zadania i podejmuje decyzje autonomicznie na podstawie zdefiniowanych reguł.
Potrafi rozumować, planować, uczyć się i adaptować. Może działać przy minimalnej interwencji człowieka, wchodzić w interakcję ze środowiskiem developerskim i korzystać z narzędzi, aby realizować złożone, wieloetapowe procesy.
Popularne agenty AI:
- GPT Codex
- Claude Code
- GitHub Copilot
- Cursor
- Windsurf
- Kiro
Niektóre z nich “żyją” w Twojej przeglądarce, inne w CLI, a jeszcze inne wymagają dedykowanego IDE (Cursor, Windsurf, Kiro) albo integrują się z Twoim obecnym edytorem. Każde podejście ma swoje plusy i minusy. Przejdziemy przez nie w tym artykule.
Dlaczego warto korzystać z agenta AI?
Dużą ilość pracy można zautomatyzować, pozwalając programistom skupić się na bardziej złożonych zadaniach. Dobrze wdrożeni agenci AI dostarczają wysokiej jakości kod zgodny z dobrymi praktykami i łatwy w utrzymaniu. Mogą przejmować powtarzalne i żmudne zadania. Pomyśl o nich jak o dodatkowych developerach w zespole – z jednym haczykiem: wymagają odpowiedniego onboardingu, aby były skuteczne.
Vibe Coding vs. AI-Assisted Coding
Vibe Coding oznacza pozwolenie AI na swobodne generowanie kodu bez większego wsparcia ze strony programisty. Najlepiej nadaje się do szybkiego prototypowania lub eksperymentowania, ale zwykle kończy się: nieefektywną architekturą, słabą skalowalnością, niskim poziomem bezpieczeństwa i masą trudnego do utrzymania kodu. Dlatego Vibe Coding jest bardzo ryzykowny w aplikacjach typu enterprise.
Można to porównać do junior developera, który przepracował cały weekend i w poniedziałek wręcza Ci wszystko naraz do review.
AI-Assisted Coding traktuje agenta jak kolejnego członka zespołu. Po odpowiednim onboardingu agent przestrzega Twoich reguł, konwencji nazewniczych, wzorców architektonicznych i standardów kodowania. Każda zmiana jest przewidywalna, ograniczona do zdefiniowanego mu scope’u i testowalna. Wygenerowany kod jest mniejszy, łatwiejszy do review i integracji z istniejącym codebasem.
W tym artykule skupię się wyłącznie na AI-Assisted Codingu, bo według mnie jedynie to podejście daje realną wartość w profesjonalnych projektach Angularowych.
Jak wdrożyć agenta, aby był jak najbardziej efektywny?
Prawda jest taka: Agent AI będzie działał efektywnie tylko wtedy, jeśli stworzysz mu odpowiednie środowisko. Ostatnio sporo eksperymentowałem z różnymi agentami AI w moim side projekcie. Starałem się im stworzyć jak najefektywniejsze środowisko. W tym celu wykorzystałem fullstackowe monorepo Nx’a. Zaletą tego podejścia było posiadanie backendu i frontendu napisanego w jednym języku (TypeScript).
Zalety jakie otrzymałem po użyciu monorepo:
- Jedno repozytorium = jeden prompt = wspólny model mentalny dla człowieka i agenta.
- Mniejsza złożoność promptów – nie trzeba ich dostosowywać do wielu języków czy usług.
- Większa spójność – agentowi łatwiej stosować wzorce, nazewnictwo i architekturę.
Pomóż agentowi zrozumieć Twój model danych
Umieszczając definicję schematu bazy danych w repozytorium (np. używając biblioteki Prisma), agent zyskuje pełen wgląd w: struktury danych, relacje, enumy. Dzięki temu może generować warstwy CRUD’a, DTO’sy czy walidatory, zgodnie ze zdefiniowanym modelem danych.
Daj AI pełen kontekst środowiska uruchomieniowego
Dodaj do repo pliki CI/CD (YAML), Dockerfile i README.md. Agent będzie rozumiał, jak przebiega cały proces developmentu: build, testy, deployment. Dzięki temu wygeneruje kod dopasowany do twojego pipeline’u, a także dowie się, jak uruchamiać linter, testy i inne zadania.
Twórz Małe dobrze zdefiniowane prompty
W AI-Assisted Codingu nie powinieneś oczekiwać, że całe story powstanie w jednym Pull Requeście czy po jednym promptcie. Zmiany muszą być małe, przewidywalne i łatwe do review.
Dlatego architektura ma znaczenie: luźno powiązane elementy pozwalają podzielić pracę na wiele niezależnych zadań i uruchomić je jednocześnie np. używając agenta w Twojej przeglądarce.
Na przykład:
- Serwis danych i jego kontrakt API powinny być oddzielone od warstwy UI.
- Elementy UI i komponenty Smart powinny być odseparowane od całych stron i routingu.
- Każdy element powinien znajdować się w małych plikach, aby agent mógł je analizować i rozszerzać bez niepożądanych efektów ubocznych.
Jawne nazewnictwo plików i klas
Agenci AI najlepiej działają, gdy kod ma opisowe, spójne nazwy. Dzięki temu szybciej rozpoznają wzorce, a Twoje prompty stają się bardziej zwięzłe i łatwiejsze do zrozumienia przez agenta.
Na przykład zamiast niejasnych nazw typu product.ts, używaj nazw jednoznacznych, które od razu wskazują ich rolę i dziedzinę:
Kontrakty (API layer / DTOs)
- contract-product-read-many.ts
- contract-product-read-one.ts
- contract-product-delete-one.ts
- contract-product-create-one.ts
- contract-product-quick-search-many.ts
Komponenty UI
- ui-product-list-item.component.ts
- ui-product-card.component.ts
- ui-input.component.ts
- ui-input-search.component.ts
- ui-input-autocomplete.component.ts
- ui-input-upload.component.ts
Features (logika biznesowa, feature state)
- feature-product-list.ts
- feature-product-details.ts
- feature-product-delete.ts
- feature-product-create.ts
- feature-product-add-to-cart.ts
- feature-product-quick-search.ts
Pages (połączenie elementów UI z jasnym wskazaniem routingu)
- page-product-list.component.ts
- page-product-details.component.ts
- page-product-form.component.ts
Reużywalne komponenty z reużywalną logiką i UI
- product-quick-search.component.ts
Agenci lepiej rozumieją zdarzenia niż stan
Zdarzenia (np. UserLoggedInEvent) dają kontekst “dlaczego” coś się stało, a nie tylko “co się zmieniło”. To ułatwia agentowi rozumowanie i generowanie kodu.
// State-driven: jedynie sprawdza "czy wartość jest true"
if (user) {
this.showWelcomeToast(user.name);
}
// Event-driven: reaguje wtedy "kiedy coś konkretnego się stało"
this.messageBus.subscribe(UserLoggedInEvent, (event) => {
this.showWelcomeToast(event.username);
});Behavior-Driven Tests: uczenie AI przez stories
Testy BDD (np. pisane w Gherkinie) nie tylko walidują kod. Dają AI agentowi kontekst tego, dlaczego coś powinno działać. Zamiast jedynie sprawdzać, czy kod się uruchamia, BDD opisuje cele użytkownika, przepływy danych, przypadki brzegowe i oczekiwane rezultaty w prostym języku. Dzięki temu agent potrafi generować rozwiązania dopasowane do rzeczywistych scenariuszy, a nie tylko tworzyć niepowiązane „działające” funkcje. Spróbuj osadzić testy BDD bezpośrednio w swoim repozytorium – szybko zauważysz korzyści, zarówno w sposobie, w jaki agent rozumie Twój system, jak i w tym, jak dużo łatwiejsze staje się review oraz zaufanie do jego wyników.
UI to najdroższy element do refaktoryzacji
Zacznij od minimalnego UI, pozwól agentom budować fundamenty (logikę, kontrakty, architekturę), a dopiero później rozwijaj warstwę wizualną. Aktualne modele słabo radzą sobie z tworzeniem interfejsów od zera. Zamiast tego lepiej przygotować podobną stronę (page) z połączonymi elementami i wskazać AI, aby przeniosło wybrane rozwiązanie do innego komponentu. Dzięki temu agent działa w oparciu o istniejący kontekst i wzorce, co znacząco zwiększa spójność i jakość wygenerowanego UI.
Tworzenie instrukcji dla agenta AI
Różne AI agenty rozumieją instrukcje w nieco inny sposób. Na przykład GPT-Codex korzysta z plików agents.md, podczas gdy inne agenty mogą opierać się na odmiennych nazwach plików czy formatach. Sedno pozostaje jednak to samo: używaj naturalnego języka, aby kierować zachowaniem agenta w określonym kontekście.
Plik agents.md zwykle umieszcza się blisko kodu źródłowego i lokalizuje instrukcje dla konkretnej funkcjonalności, folderu czy domeny. Pozwala on opisać reguły, konwencje nazewnicze, struktury klas, a także określić, jak pewny musi być agent, zanim wygeneruje kod. Na przykład:
# agents.md
- Generuj kod tylko wtedy, gdy jesteś pewny mojego zamiaru w co najmniej 90%.
- Jeśli nie masz pewności, NIE zgaduj. Podsumuj swój plan i poproś o potwierdzenie.
Example:
Planuję utworzyć:
- contract-todo-create-one.ts
- contract-todo-read-many.ts
Umieszczone w: contracts/todo/
Możesz również zdefiniować globalne zasady tylko dla klas kontraktów:
# Zasady kontraktów (Globalne dla /contracts)
## Konwencja nazewnictwa plików
- Używaj formatu: `Contract<Domain><Action>`
- Przykłady:
- `ContractProductReadMany`
- `ContractUserCreateOne`
- `ContractOrderDeleteOne`
- Sufiksy muszą jednoznacznie odzwierciedlać operację:
- `ReadOne`
- `ReadMany`
- `CreateOne`
- `UpdateOne`
- `DeleteOne`
- Nazwa klasy i nazwa pliku muszą być identyczne.
## Struktura klasy
Każdy kontrakt powinien:
- Rozszerzać bazową klasę generyczną:
Contract<ReqBody, Query, PathParams, Header, Response, Extra>
- Być samodzielną klasą.
- Eksportować potrzebne typy request/response obok klasy.
- Zawierać statyczne pole url oraz definiować metodę HTTP w konstruktorze.
export class ContractDomainAction extends Contract<...> {
static readonly url = '/some-url';
constructor(...) {
super(ContractDomainAction.url, 'METHOD');
}
}
Moje przemyślenia na temat Agentów AI ich przyszłości
Najskuteczniejszy workflow odkryłem, używając GPT-Codex w przeglądarce. Mogłem dawać agentowi wiele równoległych promptów, kontynuując pracę w IDE, bez czekania, aż agent zakończy swoje zadania. Później przeglądałem wygenerowany kod, przełączałem się na utworzone branche i wprowadzałem własne poprawki. Dzięki temu mogłem dłużej utrzymać stan flow, ponieważ zawsze robiłem coś wartościowego i posuwałem projekt do przodu, bez oczekiwania i wykonywania powtarzalnych, nudnych zadań.
Jednocześnie warto wspomnieć o ryzyku. Nie każda firma zgodzi się na używanie AI agentów, którzy przetwarzają kod produkcyjny na zewnętrznych serwerach. Rodzi to poważne obawy dotyczące własności intelektualnej i danych.
Warto też zauważyć, że pojawiają się nowe zagrożenia.
- Ataki typu prompt injection mogą oszukać agenta i sprawić, że wykona coś, czego nigdy nie zamierzałeś.
- Agent działający lokalnie może potencjalnie wykonać niechciane operacje na Twoim komputerze, jeśli nie jest odpowiednio odizolowany (sandboxed).
Oprócz tego jest jeszcze wiele do poprawy. Agenci czasami nie potrafią sobie poradzić z niektórymi zadaniami, które są proste dla deweloperów. To jednak szybko się zmienia. Dobrym porównaniem jest maszyna do szycia: kiedy ją wyobrażano, ludzie myśleli o robotycznych rękach trzymających igły, naśladujących ruchy człowieka. Wszyscy wiemy, jak wyglądają współczesne maszyny do szycia, wcale nie przypominają tamtej pierwotnej wizji.
Dziś wciąż próbujemy „dokleić” AI do ręcznie pisanych baz kodu. Prawdziwe pytanie brzmi: czy w końcu stworzymy środowiska projektowane specjalnie dla agentów? Czy te środowiska mogą wyglądać zupełnie inaczej niż nasze, i czy nasza rola może ograniczyć się jedynie do ich obsługi?
Jak uważasz: czy zmierzamy w kierunku środowisk projektowanych specjalnie dla agentów, czy AI zawsze będzie tylko dodatkiem do naszych obecnych narzędzi? Podziel się swoimi przemyśleniami w komentarzach!