Definition of Done - po co istnieje
W Scrum mamy Definition of Done. Brzmi biurokratycznie. W praktyce to coś bardzo prostego: umowa między ludźmi o tym, co znaczy słowo "koniec".
Bez DoD każdy ma inną definicję końca pracy.
Dla jednego "gotowe" oznacza: działa na moim laptopie. Dla drugiego: przeszło testy. Dla trzeciego: jest na produkcji i ma monitoring. Dla klienta: rozwiązuje mój problem.
Te cztery definicje mogą się drastycznie różnić. I różnią się, częściej niż chcemy przyznać.
Pracowałem z zespołem, który przez pół roku zamykał sprinty z zieloną planszą. Wszystkie story "done". Na demo wszystko działało. A potem przyszedł klient i zapytał o jedno konkretne zachowanie systemu. Cisza. "To jest na liście do zrobienia." "Ale to było w zakresie." "No... jakby tak na to patrzeć..."
DoD nie jest biurokracją. DoD jest odpowiedzią na pytanie: co tak naprawdę ma znaczyć słowo "zrobiłem"?
DoD dla promptów - co to znaczy w praktyce
Vibe coding ma problem, który na razie mało kto głośno nazywa: domyślny DoD to "działa". Uruchamia się, wyświetla coś na ekranie, nie crashuje od razu.
To jest naprawdę bardzo nisko ustawiona poprzeczka.
Karpathy sam to mówi - vibe coding świetnie sprawdza się przy prototypach, eksploracji, narzędziach jednorazowego użytku. Ale co, gdy prototype jedzie na produkcję? A jedzie. Zawsze jedzie.
Propozycja z posta, która mi siedzi w głowie: DoD w prompcie. Nie jako osobny dokument. Jako część opisu zadania.
Jak to wygląda w praktyce?
Zamiast: "Zrób mi komponent do logowania użytkownika"
Piszesz: "Zrób mi komponent do logowania użytkownika. Wymagania jakościowe: testy jednostkowe pokrywające min. 80% kodu, zero znanych vulnerability (OWASP Top 10), dokumentacja funkcji publicznych, kod gotowy do review przez człowieka."
To wciąż vibe. Tylko z ramą.
Lista DoD dla promptu - minimum, o które warto zadbać:
- Testy jednostkowe (i określony coverage)
- Security scan (np. czy nie ma hardcoded credentials, SQL injection, XSS)
- Dokumentacja - choćby podstawowy komentarz do każdej funkcji publicznej
- Error handling - co się dzieje, gdy coś pójdzie nie tak
- Code review - nawet jeśli to tylko "sprawdź, czy to jest czytelne dla człowieka"
Czy to wciąż "vibe"? Tak. Po prostu vibe z kręgosłupem.
Vibe coding + Agile - ewolucja, nie koniec
Słyszę czasem: "Agile nie ma sensu, skoro AI koduje sam." Albo: "Scrum jest zbędny, gdy wszystko da się zrobić w minutę."
To jest myślenie narzędziami, nie problemami.
Agile nie jest o tym, jak szybko piszesz kod. Jest o tym, jak dostarczasz wartość w warunkach niepewności. Jak uczysz się szybciej niż klient zmienia zdanie. Jak utrzymujesz jakość, gdy wszystko wokół się rusza.
AI przyspiesza pisanie kodu. Problem: jakość, sens, kontekst biznesowy i definicja "gotowe" - to nadal ludzkie pytania.
DoD nie znika, gdy AI koduje. DoD staje się ważniejsze. Bo AI generuje bardzo szybko i bardzo dużo. I jeśli nie wiesz, co znaczy "gotowe" - bardzo szybko dostaniesz bardzo dużo złego kodu.
Moja odpowiedź na "vibe coding + Agile = co?" jest prosta: to jest nowe narzędzie w starym procesie. Tak jak niegdyś pojawił się IDE. Potem testy automatyczne. Potem CI/CD. Każde narzędzie zmieniało rytm pracy - ale nie zwalniało zespołu z myślenia o jakości.
Vibe coding też nie zwalnia. Może tylko bardziej widać, gdy ktoś nie myśli.
Intuicja potrzebuje ramy
Jest pewien paradoks w vibe codingu, który mnie fascynuje.
Vibe - z angielskiego - to intuicja, nastrój, feeling. Coś nieuchwytnego. I to jest piękne przy eksploracji. Chcesz zbudować coś szybko, sprawdzić hipotezę, zobaczyć, czy pomysł ma sens.
Ale intuicja bez ramy jakości to trochę jak jazz bez znajomości gam. Można. Niektórzy twierdzą, że to nawet ciekawsze. Ale dobry jazzman zna teorię - i świadomie ją łamie. Nie dlatego, że jej nie zna.
Vibe coding bez DoD to nie jest wolność twórcza. To jest dług techniczny podany w atrakcyjnym opakowaniu.
Sam wpadłem w tę pułapkę. Prototyp w czterdzieści minut. Zachwyt. Tydzień później: "Czy to jest bezpieczne?" Nie wiedziałem. Musiałem zacząć od nowa. Tym razem z listą wymagań jakościowych w pierwszym prompcie.
Szybciej? Paradoksalnie tak.
Pytanie na koniec
Twój zespół ma DoD. Świetnie. Ale czy ten DoD mówi cokolwiek o AI-generowanym kodzie?
Kto w Waszym Definition of Done odpowiada za jakość czegoś, czego nikt w pełni nie napisał - i nie do końca rozumie? I w ogóle - kto powinien definiować DoD dla kodu generowanego przez AI? Developer? Tech lead? Ktoś z bezpieczeństwa? To nie jest pytanie retoryczne. To jest decyzja, którą warto podjąć zanim prototyp trafi na produkcję - nie po.
Jeśli jeszcze nie rozmawiałeś o tym z zespołem - to może jest dobry moment, żeby zacząć. Zanim kolejny prototyp w czterdzieści minut znajdzie się na produkcji.