Workflow z Devinem od zera – plan, implementacja i weryfikacja krok po kroku

Devin (dawniej Windsurf) to potężne narzędzie, ale bez dobrego workflowu szybko skończysz z kodem, który nie działa, a agent „zgaduje" zamiast rozumieć projekt. Ten poradnik pokazuje, jak pracować z Devinem krok po kroku - od konfiguracji, przez planowanie, po weryfikację - tak, żeby na końcu dostać kod, który faktycznie działa.

Krok 0: Konfiguracja zanim zaczniesz

Najczęstszy błąd początkujących to otwarcie Devina i od razu pisanie „zrób mi aplikację". Zanim cokolwiek poprosisz agenta o kod, poświęć 10 minut na konfigurację. To zwróci się wielokrotnie.

Katalog .devin/ i reguły projektu

Devin czyta pliki z katalogu .devin/ w projekcie, żeby zrozumieć kontekst. Najważniejsze z nich to:

.devin/rules lub .windsurfrules - reguły stylu kodu, stack technologiczny, czego unikać
.devinignore - pliki, których agent nie powinien czytać ani modyfikować (np. .env, build artifacts)
.devin/skills/ - umiejętności, które rozszerzają możliwości agenta o konkretne procedury

Przykładowy plik reguł, który drastycznie poprawia jakość kodu:

# Stack
- TypeScript, Next.js 16, TailwindCSS
- Testuj w Vitest

# Styl kodu
- Funkcje max 30 linii, jedną odpowiedzialność
- Zawsze typuj parametry i return values (no any)
- Nazwy zmiennych po angielsku, komentarze po polsku

# Czego unikać
- Nie instaluj nowych bibliotek bez pytania
- Nie usuwaj istniejących testów
- Nie modyfikuj plików w node_modules/

Dzięki temu agent nie będzie zgadywał stacku ani wprowadzał zależności, których nie chcesz.

Krok 1: Plan Mode - najpierw plan, potem kod

Devin Local ma Plan Mode - tryb, w którym agent najpierw tworzy plik planu, a dopiero po Twojej akceptacji przystępuje do implementacji. Dla początkujących to najważniejsza funkcja produktu.

Jak tego używać w praktyce:

Opisz zadanie konkretnie - nie „zrób logowanie", ale „dodaj stronę logowania z formularzem email+hasło, walidacją po stronie klienta, i endpointem API /api/auth/login"
Poproś o plan - np. „Najpierw stwórz plan w Plan Mode, nie pisz kodu dopóki nie zatwierdzę"
Przeczytaj plan krytycznie - czy agent zrozumiał zadanie? Czy nie pominął istniejącego kodu? Czy nie chce instalować niepotrzebnych bibliotek?
Popraw plan, jeśli trzeba - łatwiej zmienić plan niż gotowy kod
Dopiero zatwierdź implementację

„Zatwierdzenie planu kosztuje 2 minuty. Poprawa źle napisanego kodu kosztuje 30 minut i nerwy. Plan Mode to najlepsza inwestycja czasu początkującego."

Krok 2: Implementacja - małe kroki, nie wielkie skoki

Nawet z dobrym planem, nie każ agentowi implementować wszystkiego naraz. Dziel pracę na małe, weryfikowalne kroki:

Jedna funkcjonalność na raz - zamiast „zrób cały CRUD", rób: endpoint list → endpoint create → formularz → walidacja
Proś o diff, nie o nadpisanie - „pokaż mi co zmienisz zanim zastosujesz"
Używaj subagentów do równoległych zadań - Devin Local obsługuje subagentów, ale tylko dla naprawdę niezależnych zadań (np. testy + dokumentacja)

Krok 3: Weryfikacja - nigdy nie ufaj ślepo

To krok, którego początkujący najczęściej pomijają, a który decyduje o tym, czy kod faktycznie działa. AI może wygenerować kod, który wygląda poprawnie, ale nie jest - halucynacje to realny problem.

Co sprawdzać po każdej zmianie agenta

Przejrzyj diff - Devin pokazuje diff przed zastosowaniem. Czy agent nie usunął czegoś ważnego? Czy nie dodał niepotrzebnych importów?
Uruchom build - npm run build lub odpowiednik. Jeśli nie przechodzi, nie idź dalej
Uruchom testy - npm test. Jeśli agent napisał kod, niech napisze też testy
Sprawdź bezpieczeństwo - szczególnie w obszarach autentykacji, walidacji inputów, zapytań SQL. AI często pomienia walidację
Nie wklejaj sekretów - nigdy nie podawaj agentowi kluczy API, haseł, danych produkcyjnych

Krok 4: Iteracja - jak poprawiać, zamiast pisać od nowa

Kiedy kod nie działa, nie każ agentowi „napraw to" - to często prowadzi do jeszcze większego bałaganu. Zamiast tego:

Podaj konkretny błąd - wklej komunikat błędu z builda/testów
Wskaż plik i linię - „błąd jest w src/auth/login.ts linia 42"
Opisz oczekiwane vs faktyczne zachowanie - „powinno zwracać 200, zwraca 500"
Proś o minimalną zmianę - „napraw tylko ten błąd, nie refaktoryzuj"

Praktyczny przykład - pierwszy projekt od zera

Oto jak wygląda kompletny workflow na prostym przykładzie: prosta aplikacja „lista zadań" w Next.js.

Sesja 1: Konfiguracja (10 min)

Utwórz .devin/rules ze stackiem i stylem
Utwórz .devinignore z .env, node_modules/, out/

Sesja 2: Plan (5 min)

Prompt: „Stwórz plan w Plan Mode dla aplikacji lista zadań: model danych (Task: id, title, done, createdAt), endpointy API (list, create, toggle, delete), strona główna z formularzem i listą. Next.js 16 App Router, TypeScript, Tailwind. Nie pisz kodu, tylko plan."

Sesja 3: Implementacja krok po kroku (30 min)

Krok 1: model danych i schema → sprawdź, uruchom build
Krok 2: endpoint list → test ręczny w przeglądarce
Krok 3: endpoint create → test z curl/postman
Krok 4: komponent UI → sprawdź wizualnie
Krok 5: połączenie UI z API → pełny test przepływu

Sesja 4: Testy i weryfikacja (15 min)

Prompt: „Napisz testy Vitest dla endpointów API i komponentu listy. Uruchom testy i napraw ewentualne błędy."

Częste pułapki początkujących

„Zrób mi całą aplikację" - zbyt duże zadanie = chaos. Dziel na małe kroki
Ślepe zatwierdzanie diffów - zawsze czytaj, co agent zmienia
Brak reguł projektu - bez .devin/rules agent zgaduje stack i styl
Zaufanie bez weryfikacji - kod, który „wygląda dobrze", może nie działać. Build + testy to minimum
Wklejanie sekretów - klucze API, hasła, dane klientów nigdy nie trafiają do agenta
Ignorowanie halucynacji - jeśli agent używa biblioteki/funkcji, której nie znasz, sprawdź czy istnieje

Podsumowanie

Dobry workflow z Devinem to nie magia - to konfiguracja → plan → małe kroki → weryfikacja → iteracja. Poświęcenie 10 minut na konfigurację i 5 na plan oszczędza godziny poprawek. Plan Mode to Twoja najważniejsza funkcja jako początkującego - używaj jej zawsze.

Pamiętaj: Devin to asystent, nie autorytet. Ty odpowiadasz za kod - agent tylko proponuje. Weryfikuj, testuj, nie ufaj ślepie. To jedyna droga do kodu, który faktycznie działa w produkcji.