Checkpoints: cofanie i punkty kontrolne w sesji agenta

Czego się nauczysz

• Jak odróżnić edit previous request, review pojedynczych zmian i restore checkpoint
• Kiedy checkpoints są najlepszym sposobem cofnięcia większej sesji agentowej
• Dlaczego checkpoints uzupełniają Git, ale go nie zastępują

Przy większych zmianach najgorsze uczucie brzmi: nie wiem, jak się z tego wycofać

Checkpoints istnieją właśnie po to, żeby to uczucie zniknęło.

Gdy pracujesz z agentem nad wieloplikową zmianą, nie zawsze chcesz cofać pojedyncze linie ręcznie. Czasem potrzebujesz wrócić do znanego dobrego stanu całej rozmowy i całego zestawu plików.

VS Code daje do tego dwa mechanizmy wyższego poziomu:

• edycję wcześniejszego requestu
• restore checkpoint

I to trzeba dobrze rozróżnić.

Trzy poziomy cofania, trzy różne zastosowania

Najprostszy poziom to review edits z poprzedniej lekcji. Tam cofasz pojedyncze zmiany albo całe pliki.

Wyżej masz Edit a previous request. Ten mechanizm służy do sytuacji, w której chcesz przeredagować wcześniejszy prompt. VS Code cofnie zmiany wykonane przez ten request i wszystkie kolejne, a potem wyśle nową wersję prośby.

To dobre wtedy, gdy problem brzmi nie “wynik jest zły”, tylko raczej “źle sformułowałem zadanie”.

Najwyższy poziom to Restore Checkpoint. Tu nie zmieniasz promptu. Po prostu cofasz workspace do stanu z wcześniejszego punktu rozmowy.

To dobre wtedy, gdy chcesz wrócić do wcześniejszego, znanego stanu bez przepisywania historii poleceń.

Jak działają checkpoints

Gdy checkpoints są włączone przez chat.checkpoints.enabled, VS Code tworzy snapshot plików dotkniętych przez każdy request, zanim zacznie go przetwarzać.

To oznacza bardzo ważną rzecz praktyczną: każda większa iteracja rozmowy może mieć własny punkt przywracania.

Dzięki temu nie musisz myśleć o checkpointach jak o czymś, co zakładasz ręcznie w wyjątkowych momentach. To raczej siatka bezpieczeństwa budowana podczas pracy.

Restore checkpoint cofa cały batch zmian po danym punkcie

Po wybraniu Restore Checkpoint VS Code przywraca workspace do stanu z czasu tego requestu i usuwa z historii późniejsze skutki tej ścieżki rozmowy.

To kluczowa różnica względem review edits. Nie cofasz jednej poprawki. Cofasz cały pakiet tego, co wydarzyło się po danym momencie.

To ma sens, gdy:

• agent wszedł w złą ścieżkę i zmienił za dużo
• kilka kolejnych promptów budowało się na złym założeniu
• chcesz wrócić do wcześniejszej wersji rozwiązania i ruszyć inną drogą

Redo i fork conversation dają bezpieczną eksperymentalność

Dokumentacja opisuje dwa bardzo praktyczne mechanizmy po restore:

• Redo pozwala odtworzyć cofnięte zmiany, jeśli restore był pomyłką
• Fork Conversation pozwala odgałęzić sesję z wybranego checkpointu i sprawdzić alternatywne podejście

To jest mocne, bo pokazuje, że checkpoints nie są tylko przyciskiem awaryjnym. Są też narzędziem eksploracji.

Możesz potraktować checkpoint jak rozwidlenie decyzji:

• jedna ścieżka zostaje przy obecnym podejściu
• druga testuje alternatywną implementację

To szczególnie cenne przy refaktorach i eksperymentach architektonicznych, gdzie nie chcesz ciągle ręcznie cofać plików.

File changes summary pomaga wybrać właściwy punkt cofnięcia

Włączenie chat.checkpoints.showFileChanges pokazuje listę zmodyfikowanych plików i bilans linii dodanych oraz usuniętych przy końcu danego requestu.

To brzmi jak detal UI, ale w praktyce bardzo pomaga.

Bez tego checkpointy są tylko serią punktów w historii rozmowy. Z tym widokiem zaczynasz rozumieć realny koszt każdego requestu i łatwiej wybierasz, do którego momentu warto wrócić.

Checkpoints nie zastępują Gita

Dokumentacja mówi to wprost i warto powtórzyć to jeszcze mocniej: checkpoints nie są systemem version control.

Ich zadaniem jest szybka iteracja wewnątrz aktywnej sesji chatu. Git nadal odpowiada za:

• trwałą historię zmian
• współpracę zespołową
• branchowanie i merge
• audyt tego, co zostało zaakceptowane na stałe

Najpraktyczniej myśleć o tym tak:

• review edits i checkpoints pomagają Ci w pracy przed commitem
• Git przejmuje odpowiedzialność po commicie

Kiedy używać którego mechanizmu

Najprostszy filtr decyzyjny wygląda tak:

• chcesz odrzucić jedną lub kilka konkretnych zmian: użyj review edits
• źle sformułowałeś wcześniejszy prompt: edytuj wcześniejszy request
• chcesz cofnąć cały batch zmian do bezpiecznego punktu: restore checkpoint
• chcesz sprawdzić alternatywną drogę bez psucia obecnej: fork conversation

Jeśli będziesz mylił te poziomy, szybko pojawi się chaos. Jeśli je rozdzielisz, praca z agentem staje się dużo spokojniejsza.

Mały scenariusz praktyczny

Wyobraź sobie taki przebieg:

1. Agent robi refaktor w trzech plikach.
2. Potem dopisujesz prompt o optymalizacji i agent dotyka kolejnych czterech miejsc.
3. Po chwili widzisz, że cała druga iteracja szła w złą stronę.

W takiej sytuacji review pojedynczych editów byłoby żmudne. Znacznie lepszy jest restore checkpoint do momentu sprzed drugiego promptu. Jeśli później uznasz, że jednak chcesz porównać obie wersje, możesz użyć Redo albo fork conversation.

To jest właśnie realna przewaga checkpointów: cofanie całych decyzji, nie tylko pojedynczych linii.

Kluczowe wnioski

• Review edits, edycja wcześniejszego requestu i restore checkpoint rozwiązują trzy różne problemy cofania zmian.
• Checkpoints działają najlepiej jako szybka siatka bezpieczeństwa dla wieloplikowych iteracji agentowych.
• Restore checkpoint cofa cały batch zmian po danym punkcie rozmowy, a nie tylko pojedynczy diff.
• Redo i fork conversation zamieniają checkpointy z mechanizmu awaryjnego w narzędzie eksperymentowania.
• Git pozostaje systemem trwałej historii; checkpoints służą do iteracji przed commitem.

Co dalej

Masz już pełny workflow pracy agentowej w VS Code: wieloplikowa implementacja, plan, review edits i cofanie przez checkpoints. To moment, w którym Copilot przestaje być tylko asystentem do kodu, a staje się środowiskiem sterowania zmianą.