Konrad Kowalski (rootsher)Principal Platform & Reliability Architect100111100100101110000010101011001101111110001001

Od chatu do agenta: przestań zanosić kod do AI

data
kategoria
AI Agents
także w
AI Engineering · Automation · Engineering Practices
czytanie
3 min / 631 słów

Pierwszy sposób pracy z LLM-ami zna prawie każdy developer:

text
IDE
-> zaznacz kod
-> copy
-> ChatGPT / Claude
-> prompt
-> odpowiedź
-> copy
-> IDE

Działa.

Można tak naprawić błąd, napisać regex, wygenerować test albo dostać propozycję refaktoru.

Problem polega na tym, że cała prawdziwa praca nadal zostaje po Twojej stronie.

To Ty:

  • wybierasz pliki,
  • tłumaczysz strukturę projektu,
  • kopiujesz błąd,
  • aplikujesz zmianę,
  • odpalasz test,
  • kopiujesz kolejny błąd,
  • ponownie pytasz model.

AI jest konsultantem. Nie uczestnikiem SDLC.

Następny poziom: agent w repozytorium

Uruchom Claude Code bezpośrednio w repo.

Zamiast:

Jak napisać walidację dla tego endpointu?

spróbuj:

Dodaj walidację do tego endpointu. Najpierw sprawdź istniejące wzorce w projekcie, po zmianie uruchom odpowiednie testy.

Różnica jest fundamentalna.

Claude może teraz sam:

text
przeszukać repo
|
v
przeczytać odpowiednie pliki
|
v
zrozumieć istniejący kod
|
v
zmienić pliki
|
v
uruchomić testy
|
v
zobaczyć failure
|
v
poprawić implementację

Nie dostajesz tylko odpowiedzi.

Dostajesz wykonanie zadania.

Co właściwie zmieniło się technicznie?

Sam LLM nadal przyjmuje informacje i generuje odpowiedź.

Agent powstaje wtedy, gdy do modelu dokładamy:

  • narzędzia,
  • środowisko,
  • możliwość obserwowania wyników własnych działań,
  • pętlę, która pozwala wykonać więcej niż jeden krok.

Najprostszy model:

text
Claude
|
v
decyduje: muszę przeczytać plik
|
v
tool: read
|
v
wynik wraca do Claude
|
v
decyduje: muszę zmienić kod
|
v
tool: edit
|
v
wynik
|
v
decyduje: uruchamiam test
|
v
tool: shell
|
v
wynik
|
v
kolejna decyzja

To jest agent loop.

Można go sprowadzić do:

text
observe
-> decide
-> act
-> observe
-> decide
-> act
-> ...

Claude Code jest warstwą, która tę pętlę obsługuje. Czasem spotkasz określenie agent harness: kod i runtime dookoła modelu, który przekazuje mu narzędzia, wykonuje tool calle i zwraca wyniki.

Nie musisz pisać tego sam.

Dla developera ważniejsze jest zrozumienie jednej zmiany:

Przestajesz pytać model, jak Ty masz wykonać zadanie. Zaczynasz dawać mu warunki do wykonania zadania samodzielnie.

Built-in tools zmieniają sposób promptowania

Kiedy Claude może sam przeszukiwać repo, nie ma sensu od razu wskazywać mu każdego pliku.

Zamiast:

Otwórz src/services/UserService.ts, src/controllers/UserController.ts i tests/UserService.test.ts. Dodaj...

lepiej zacząć od celu:

Dodaj obsługę X. Sprawdź najpierw, gdzie w tym projekcie implementujemy podobne rzeczy.

To drobna zmiana, ale bardzo ważna.

Dajesz agentowi przestrzeń, żeby wykorzystał:

  • search,
  • grep,
  • glob,
  • odczyt plików,
  • git,
  • shell.

Jeżeli od razu karmisz go wyłącznie własnym wycinkiem repo, nadal częściowo pracujesz jak w erze copy/paste.

Gdzie to pomaga w normalnym SDLC?

Bugfix

Przed:

text
failure
-> kopiuję stack trace
-> pytam AI
-> szukam pliku
-> wprowadzam fix
-> odpalam test

Po:

text
"Znajdź przyczynę failing testu i napraw ją."
-> Claude uruchamia test
-> czyta failure
-> znajduje kod
-> poprawia
-> uruchamia test ponownie

Mały feature

Przed:

Wygeneruj mi komponent/endpoint/funkcję.

Po:

Zaimplementuj feature zgodnie z istniejącymi wzorcami projektu i zweryfikuj zmianę.

Refaktor

Przed:

Jak najlepiej zrefaktorować ten fragment?

Po:

Zrefaktoruj ten obszar bez zmiany zachowania. Najpierw znajdź zależne miejsca i po zmianie uruchom testy.

AI zaczyna brać udział nie tylko w coding, ale też w:

  • discovery,
  • verification,
  • debugging.

Czego jeszcze nie rozwiązaliśmy?

Claude ma dostęp do repo, ale nie oznacza to, że rozumie Twój projekt tak jak osoba pracująca nad nim od roku.

Nie wie automatycznie:

  • które zasady architektoniczne są naprawdę ważne,
  • jakie conventions obowiązują,
  • co oznacza "gotowe",
  • których operacji nie wolno wykonywać,
  • jakie testy są wymagane po konkretnej zmianie.

I właśnie to szybko staje się następnym bottleneckiem.

Ale najpierw zróbmy pierwszy upgrade.

Wdróż to dziś

1. Uruchom Claude Code w prawdziwym repo

Nie twórz projektu demonstracyjnego.

Weź repo, w którym normalnie pracujesz.

2. Wybierz mały, prawdziwy task

Najlepiej coś, co potrafiłbyś zrobić sam w kilkanaście albo kilkadziesiąt minut:

  • popraw failing test,
  • dodaj prostą walidację,
  • usuń deprecated API,
  • dopisz brakujący test,
  • wykonaj mały refaktor.

3. Podaj cel, nie instrukcję copy/paste

Nie:

Tutaj masz trzy pliki. Powiedz mi, co zmienić.

Tylko:

Napraw X. Najpierw sprawdź istniejący kod, po zmianie uruchom odpowiednie testy.

4. Pozwól Claude używać repo

Zanim wskażesz mu plik, sprawdź, czy sam go znajdzie.

Zanim skopiujesz failure, pozwól mu samemu uruchomić test.

5. Obserwuj pętlę

Zwróć uwagę na sekwencję:

text
search
-> read
-> edit
-> test
-> read
-> edit
-> test

To właśnie jest najważniejsza różnica między chatem i agentem.

Level complete

Poziom jest zaliczony, jeśli przy następnym małym tasku:

  • nie kopiujesz kodu z repo do chatu,
  • nie kopiujesz odpowiedzi z chatu do IDE,
  • Claude sam znajduje potrzebne pliki,
  • Claude sam wykonuje przynajmniej część verification.

Na następnym poziomie przestaniemy robić Claude onboarding projektu przy każdej nowej sesji.

Materiały