Jak podchodzić do programowania z agentami AI
Kontrola nad wynikiem, człowiek jako architekt i tester oraz skill, który zmusza agenta do wyjaśnienia projektu, zanim napisze kod.
Myślę, że panuje mnóstwo opinii na temat tego, jak poprawnie wykorzystywać agentów przy programowaniu. W tym artykule podzielę się swoim podejściem. Prawdopodobnie będzie się ono różnić od opinii innych, ale główne myśli na pewno będą bardzo podobne.
1. Jak zachować kontrolę nad tym, co tworzy agent
Uważam, że podstawą dobrego wykorzystania agentów w programowaniu jest kontrola nad wynikiem. Nie musimy znać każdej linijki kodu. Powinniśmy jednak znać każdą decyzję architektoniczną i ją rozumieć.
Jest w tym istotna różnica. Linijkę kodu można przepisać w minutę i przeważnie nic od niej nie zależy. Decyzja architektoniczna wraca do ciebie po pół roku, kiedy już nikt nie wie, dlaczego tak jest — a przepisać się jej nie da w minutę, tylko w tygodnie.
2. Jaką rolę pełni człowiek w programowaniu z agentami AI
Moim zdaniem człowiek w programowaniu z agentami musi być przede wszystkim architektem, projektantem UX i testerem. Oczywiście AI może pomagać również w tych rolach — ale człowiek musi tu wykonać znaczną część wysiłku przy sprawdzaniu.
To jest ta część, której nie da się oddelegować. Agent napisze ci kod, który działa. Czy jest to właściwy kod we właściwym miejscu i czy to, co zleciłeś, było w ogóle dobrym pomysłem — to zostaje po twojej stronie.
3. Jak napisać skill dla Claude Code, który wymusza projekt
Z własnego doświadczenia polecam stworzyć sobie skill, w którym mówisz agentowi, że przed jakąkolwiek implementacją musi ci najpierw wyjaśnić wybrane kroki architektoniczne — w postaci z góry zdefiniowanej struktury w pliku Markdown.
Powiedz agentowi, żeby obficie korzystał z diagramów mermaid, przykładów i wykresów. Diagram odsłania bzdurę, która w ciągłym tekście dobrze się chowa: kiedy agent narysuje przepływ danych i dwa komponenty rozmawiają ze sobą w obie strony, widać to na pierwszy rzut oka.
Taki skill może wyglądać na przykład tak:
.claude/skills/it-analysis/SKILL.md
---
name: it-analysis
description: Opracuj analizę IT
---
# Analityk IT
Jesteś starszym analitykiem IT. Specjalizujesz się w analizach IT systemów informatycznych + ich architektury.
## Workflow
1. **Zrozum, co masz rozwiązać** — Zrozum zadanie i zastanów się nad nim. Jak to rozwiązać? jakie są warianty rozwiązania? Edge cases?
2. **Opracuj analizę według szablonu template.md**
3. **Jeśli są odpowiedzi na istniejące pytania** - Przerób analizę na podstawie odpowiedzi na otwarte pytania. Otwartych pytań ani odpowiedzi nie usuwaj, zostaw oryginalne. Możesz dopisać kolejne pytania. Na końcu analizy umieść przegląd zmian (changelog).
## Rules
- Wynik musi być zgodny z szablonem `template.md`.claude/skills/it-analysis/template.md
# Szablon do tworzenia analiz
## Spis treści
1. [Architektura](#1-architektura)
2. [Baza danych](#2-baza-danych)
3. [Backend](#3-backend)
4. [Frontend](#4-frontend)
5. [Ryzyka implementacji](#5-ryzyka-implementacji)
6. [Otwarte pytania do decyzji](#6-otwarte-pytania-do-decyzji)
## 1) Architektura
W tej części zostanie omówiona proponowana architektura implementowanej funkcji. Jednocześnie zostanie omówione, w jaki sposób zmieni się istniejąca architektura + podłączenie do istniejącej architektury. Pożądane są odpowiednie diagramy UML w mermaid.
## 2) Baza danych
W tej części zostanie omówiony proponowany model bazy danych poprzez diagram ER. Jednocześnie zostaną omówione zmiany istniejącego modelu bazy danych + podłączenie do istniejącego modelu DB. Pożądane są diagramy ER.
## 3) Backend
Tutaj w postaci listy punktowanej zostaną omówione skutki dla backendu - czyli co trzeba będzie na backendzie dodać / usunąć / zmienić.
## 4) Frontend
Tutaj w postaci listy punktowanej zostaną omówione skutki dla frontendu - czyli co trzeba będzie na froncie dodać / usunąć / zmienić.
## 6) Otwarte pytania do decyzji
Numerowana lista z pytaniami do decyzji. Każdy punkt listy będzie wyglądał tak:
- **Opisowa nazwa pytania**: Szczegółowa treść pytania, z której muszę być w stanie zrozumieć, o co pytasz.
`Odpowiedź`: Treść odpowiedzi, ewentualnie `-` jeśli dotąd nie ma żadnej odpowiedzi.4. Dlaczego warto pozwolić agentowi najpierw zaprojektować rozwiązanie
Na podstawie tego skilla zawsze najpierw każesz sobie zaproponować rozwiązanie, które zawsze najpierw zatwierdzasz. Oczywiście trzeba wynik tego skilla porządnie sprawdzić, ale ten wynik na pewno jest tego wart.
Co więcej, moim zdaniem ważne jest rozumieć te zasadnicze kwestie, mimo że sam kod pisze agent. To jedyna część, w której rozstrzyga się, czy projekt za rok będzie jeszcze coś wart.
Sekcja z otwartymi pytaniami w szablonie jest właśnie po to. Agent ma skłonność do rozstrzygania niejednoznaczności samemu i po cichu — a ty dowiadujesz się o tym dopiero, gdy kod jest gotowy. Kiedy zmusisz go do wypisania pytań, dostajesz je zanim cokolwiek na nich stanie.
5. Jak omówić z agentem projekt, którego nie rozumiesz
Jeśli co do niektórych części dokumentu nie masz pewności, nie bój się omawiać ich z agentem iteracyjnie. Dzięki rozmowie z nim lepiej zrozumiesz proponowane rozwiązanie, a to pomoże ci dostarczyć dobry produkt.
Warto zauważyć, że ta rozmowa ma jeszcze drugi efekt. Kiedy o coś pytasz, a odpowiedź nie ma sensu, zwykle nie wynika to z tego, że czegoś nie zrozumiałeś — tylko z tego, że projekt jest wadliwy. Własna niepewność to przyzwoity detektor problemów.
6. Dlaczego traktować agenta AI jak juniora
Moim zdaniem do agenta AI powinniśmy zawsze podchodzić jak do juniora na określonym stanowisku — tym stanowisku, które akurat każemy mu pełnić.
Juniorowi zlecasz pracę, każesz sobie wyjaśnić, jak chce ją wykonać, i sprawdzasz wynik. Nie dajesz mu decyzji, które źle się cofa, i nie pozwalasz mu pracować tydzień bez zaglądania. Jednocześnie nie stoisz mu nad ramieniem przy każdej linijce, bo wtedy równie dobrze mógłbyś zrobić to sam.
Dokładnie tak sprawdziła mi się praca z agentem.
7. Podsumowanie: trzy zasady programowania z agentami
Ten sposób sprawdził mi się jak dotąd najlepiej. Podsumowałbym go w trzech zdaniach: znaj każdą decyzję architektoniczną, każ sobie ją wyjaśnić, zanim powstanie kod, i pytaj o wszystko, czego nie rozumiesz.
Masz inne zdanie? Napisz na support@coden-app.com.