Review Edits: jak weryfikować i akceptować zmiany AI

Czego się nauczysz

• Jak działa pending edits workflow po zmianach wykonanych przez agenta
• Jak reviewować pojedyncze edycje, całe pliki i całą sesję
• Jak review edits łączy się ze Source Control i ochroną wrażliwych plików

Agent może edytować pliki od razu, ale to jeszcze nie znaczy, że masz je zaakceptować

To jest jeden z najważniejszych elementów pracy z agentami w VS Code.

AI-generated edits są nakładane bezpośrednio na pliki i zapisywane na dysk. To może brzmieć groźnie, ale właśnie dlatego VS Code buduje wokół tego osobny workflow review.

Nie chodzi o to, żeby agent pisał kod “na gotowo bez Twojego udziału”. Chodzi o to, żeby mógł wykonać pracę szybko, a Ty miałeś wygodny interfejs do akceptowania lub cofania tego, co zrobił.

Czym są pending edits

Po zakończeniu pracy przez agenta VS Code pamięta, które pliki mają zmiany oczekujące na review. W Chat View widzisz listę edytowanych plików, a w Explorerze i kartach edytora pojawiają się wskaźniki pending edits.

To ważne z dwóch powodów:

• od razu widzisz zasięg zmian
• nie musisz szukać ręcznie, gdzie AI coś dotknęło

Dokumentacja podkreśla też, że ten stan jest pamiętany po ponownym otwarciu VS Code. To dobry detal, bo review wieloplikowych zmian nie zawsze kończy się w jednej sesji pracy.

Review odbywa się na kilku poziomach

To nie jest tylko przycisk “zaakceptuj wszystko”.

W praktyce masz co najmniej trzy poziomy kontroli:

• pojedyncza zmiana inline
• cały plik
• wszystkie zmiany w sesji

Po otwarciu pliku z pending edits dostajesz inline diff i overlay controls. Możesz przechodzić po zmianach i dla każdej z nich wybrać:

• Keep
• Undo

Możesz też zaakceptować albo odrzucić wszystko z poziomu Chat View.

To bardzo ważne, bo przy sensownym workflow nie akceptujesz zmian wyłącznie hurtowo. Najpierw patrzysz, czy agent dobrze zrozumiał intencję, a dopiero potem decydujesz o zakresie akceptacji.

Review edits to warstwa codziennej higieny, nie tryb awaryjny

Wiele osób traktuje review tylko jako zabezpieczenie “na wszelki wypadek”. To zaniża wartość tej funkcji.

Review edits powinno być normalną częścią każdej większej pracy agentowej, bo odpowiada na realne pytania:

• czy agent zmienił dokładnie to, o co prosiłem
• czy nie dotknął miejsc pobocznych bez potrzeby
• czy rozwiązanie jest spójne między plikami
• czy diff jest czytelny i utrzymywalny

To w praktyce jest to samo, co robisz przy review zmian kolegi, tylko szybciej i bliżej momentu generacji.

Source Control nie jest obok tego workflow, tylko w środku

Dokumentacja wyraźnie mówi o integracji ze Source Control:

• jeśli stage’ujesz zmiany, pending edits są automatycznie akceptowane
• jeśli discardujesz zmiany, pending edits też są odrzucane

To oznacza, że review edits i Git nie konkurują ze sobą. One działają warstwowo:

• najpierw reviewujesz zmiany AI w VS Code
• potem dopiero traktujesz je jak normalne zmiany do stage, commit i dalszego review zespołowego

Najgorszy skrót myślowy brzmi: “skoro diff jest już w Gicie, to review edits mogę pominąć”. Technicznie możesz. Operacyjnie zwykle tracisz wtedy szybszą warstwę kontroli jakości.

Auto-navigation i auto-accept są wygodne, ale trzeba wiedzieć, co robią

Po akceptacji albo cofnięciu edycji VS Code może automatycznie przejść do kolejnej zmiany. To steruje ustawienie chat.editing.revealNextChangeOnResolve.

To dobre domyślne zachowanie przy seriowym review, ale przy bardzo złożonym pliku możesz chcieć je wyłączyć i zostać w bieżącym miejscu.

Podobnie z chat.editing.autoAccept: możesz ustawić automatyczne akceptowanie zmian po określonym czasie. Dokumentacja słusznie ostrzega, że jeśli to włączasz, i tak powinieneś zrobić review przed commitem.

W praktyce auto-accept jest sensowne tylko tam, gdzie koszt pomyłki jest niski, a zmiany są małe i przewidywalne.

Sensitive files wymagają dodatkowej ostrożności

VS Code ma osobny mechanizm ochrony plików wrażliwych, takich jak konfiguracje workspace albo .env. Dla takich plików możesz wymagać jawnej akceptacji przed zastosowaniem edycji.

To ważne, bo agent może być świetny w implementacji kodu, ale pliki konfiguracyjne i sekrety mają inny profil ryzyka.

Jeżeli pracujesz z agentami regularnie, warto skonfigurować chat.tools.edits.autoApprove tak, żeby newralgiczne miejsca nie były zmieniane bez Twojego świadomego potwierdzenia.

Sessions list pozwala wrócić do review później

Dokumentacja wspomina też o review zmian z poziomu listy sesji. To szczególnie przydatne, gdy wracasz do starszej pracy albo chcesz zrozumieć, jaki był bilans zmian w konkretnej sesji agenta.

To zamyka ważną pętlę: agent nie jest jednorazową odpowiedzią na czacie. To pełna sesja pracy, do której możesz wrócić i przeanalizować jej ślad.

Ćwiczenie praktyczne

Uruchom małe zadanie agentowe w kilku plikach i przejdź przez review w trzech krokach:

1. Otwórz każdy plik z pending edits z poziomu Chat View.
2. Odrzuć przynajmniej jedną zmianę, która jest technicznie poprawna, ale nie pasuje do Twojego stylu albo zakresu zadania.
3. Zobacz, jak ten stan wygląda w Source Control po stage albo po discard.

Po ćwiczeniu oceń:

• czy review edits faktycznie przyspiesza kontrolę jakości
• czy agent zmienił coś, czego nie powinien
• czy lepiej reviewować od razu po zadaniu, czy po chwili z dystansem

Kluczowe wnioski

• Agentowe zmiany są zapisywane na dysk od razu, ale pozostają pending edits do review.
• Review edits działa na poziomie pojedynczej zmiany, pliku i całej sesji.
• To nie jest awaryjny bezpiecznik, tylko podstawowa warstwa higieny pracy z AI.
• Source Control integruje się z review workflow; stage akceptuje zmiany, discard je odrzuca.
• Sensitive files warto chronić osobnymi regułami akceptacji, bo ich profil ryzyka jest inny niż zwykłego kodu.

Co dalej

Ostatni element układanki to checkpoints, czyli cofanie całych batchy zmian i wracanie do wcześniejszych stanów sesji bez ręcznego rozplątywania diffu.