Kluczem jest dostarczenie AI surowego materiału — rzeczywistego diffa lub kodu — i poprosienie o konkretny, konwencjonalny format. AI jest dobre w zamienianiu zmian na jasną prozę, ale tylko jeśli widzi, co się zmieniło.
Dlaczego to ważne
- Podaj mu diff, nie niejasny opis:
git diff --staged | <your AI tool>. - Poproś o znaną konwencję — Conventional Commits (
feat:,fix:,docs:), lub twój styl changelog. - Utrzymuj dokładność i zwięzłość — wiersz subject poniżej ~50 znaków, body wyjaśniające dlaczego.
- Sprawdź, czy odpowiada diffowi. AI może wymyślić zmiany, których tam nie ma; musisz to sprawdzić.
Przed / po
Leniwa wiadomość commitu:
fixed stuff
Po podaniu diffa i poproszeniu o styl Conventional Commit:
fix(auth): reject expired tokens in session middleware
The middleware only checked token signature, not expiry, so expired
sessions stayed valid. Added an `exp` claim check that returns 401.
Druga wersja mówi recenzentowi co się zmieniło i dlaczego — znacznie bardziej przydatne w git log sześć miesięcy później.
W czym AI jest dobre
- Docstringi i READMEs — podsumowuj cel i użycie modułu.
- Changelogi — grupuj commity w sekcje Added / Fixed / Changed.
- Wiadomości commitów — zamieniaj diff na czysty, konwencjonalny komunikat.
Zawsze porównaj wynik z rzeczywistą zmianą. AI nie zna twojego zamiaru — zna tylko kod, który mu pokazałeś — więc może błędnie oznaczyć fix jako feat lub twierdzić o efekcie ubocznym, który nie istnieje.
Dlaczego to ważne
Dobre wiadomości commitów i dokumentacja to sposób, w jaki Ty i Twoi współpracownicy rozumiecie dlaczego kod istnieje. AI eliminuje tarcie przy pisaniu ich dobrze, ale dokładność jest na Tobie: pewnie błędny changelog jest gorszy niż brak. Podaj mu rzeczywiste wejście, wymagaj rzeczywistej konwencji i sprawdź przed commitowaniem.