Konflikty Git, TODO implementation, rename symboli

Czego się nauczysz

• Jakie trzy różne klasy smart actions kryją się za tym modułem
• Kiedy AI pomaga przy merge conflictach, TODO comments i rename symboli
• Gdzie kończy się wygoda, a zaczyna potrzeba inżynierskiego review

To nie jest jedna funkcja, tylko trzy różne workflow

Ten temat łatwo wrzucić do jednego worka pod etykietą “AI robi coś za mnie”. To zbyt płaskie uproszczenie.

W dokumentacji VS Code te akcje reprezentują trzy różne typy pracy:

• merge conflict resolution z wejściem w agentowy flow
• delegowanie implementacji TODO do coding agenta
• rename suggestions osadzone bezpośrednio w refaktorze symbolu

Wspólne jest tylko to, że startują z miejsca problemu, a nie z pustego chatu.

Merge conflict z AI to nie magiczne scalanie wszystkiego

VS Code opisuje AI merge conflict resolution jako funkcję eksperymentalną. I dobrze o tym pamiętać, bo to ustawia właściwe oczekiwania.

Po kliknięciu Resolve Merge Conflict with AI nie dostajesz po prostu automatycznego pliku “już naprawionego”. Otwiera się agentowy workflow, w którym model dostaje jako kontekst:

• merge base
• zmiany z jednej gałęzi
• zmiany z drugiej gałęzi

To ważne, bo konflikt merge rzadko jest tylko konfliktem tekstowym. Często jest konfliktem intencji.

AI może bardzo dobrze pomóc w sytuacjach typu:

• dwa podobne refaktory w tym samym pliku
• konflikt w boilerplate albo konfiguracji
• konflikt, gdzie trzeba złożyć dwie kompatybilne zmiany

Ale jeżeli konflikt dotyczy logiki biznesowej albo dwóch sprzecznych decyzji architektonicznych, AI nie rozwiązuje problemu za zespół. Ono może pomóc złożyć warianty, ale nie wybiera strategii produktu ani architektury.

Najlepsza praktyka jest prosta: traktuj wynik jako propozycję scalenia, nie jako automatycznie poprawny stan końcowy.

TODO implementation to delegacja zadania, nie zwykłe autocomplete

To jedna z ciekawszych smart actions, bo pokazuje, że VS Code coraz częściej przechodzi od “sugestii” do “delegacji”.

Jeżeli masz zainstalowane rozszerzenie GitHub Pull Requests, komentarz TODO może dostać code action Delegate to coding agent.

To nie działa jak zwykłe podpowiedzenie jednej linijki. Tutaj przekazujesz agentowi konkretny punkt zaczepienia do implementacji zadania.

Praktycznie oznacza to, że TODO przestaje być martwym komentarzem, a staje się wejściem do workflow typu:

• znajdź kontekst
• zrozum zależności
• zaproponuj albo wykonaj implementację

To bardzo mocne narzędzie, ale tylko pod jednym warunkiem: TODO musi być sensownie napisane.

Komentarz w stylu // TODO: improve this jest za słaby nawet dla człowieka, więc dla agenta też będzie słabym briefingiem.

Lepszy TODO wygląda bardziej jak mini-spec:

• co ma zostać dodane albo poprawione
• jakie są ograniczenia
• czego nie wolno zepsuć

Wtedy delegacja do agenta ma realną wartość.

Rename suggestions wspierają nazewnictwo, ale nie zwalniają z myślenia

Trzecia akcja z tej lekcji jest mniej spektakularna, ale bardzo praktyczna. Przy rename symbolu VS Code potrafi wygenerować AI-assisted sugestie nazwy na podstawie:

• kontekstu symbolu
• otaczającego kodu
• szerzej rozumianego codebase

To jest świetne w momentach, gdy czujesz, że obecna nazwa jest zła, ale nie masz jeszcze lepszej.

Przykłady:

• metoda robi już nie tylko get, ale też filtruje i mapuje wynik
• komponent urósł poza pierwotną odpowiedzialność
• zmienna lokalna jest technicznie poprawna, ale semantycznie mętna

AI potrafi tu zaproponować nazwę lepiej osadzoną w intencji. Ale dalej obowiązuje zasada: rename jest elementem designu, nie tylko kosmetyką.

Jeżeli nazwa sugerowana przez AI jest ładna, ale niezgodna z językiem domeny projektu, to nadal jest zła.

Wspólny wzorzec: startujesz dokładnie tam, gdzie pojawia się tarcie

To najważniejszy motyw tej lekcji.

W każdym z tych przypadków nie budujesz promptu od zera. Zaczynasz w punkcie, gdzie problem już istnieje:

• konflikt w edytorze
• TODO w kodzie
• rename na symbolu

To jest właśnie przewaga smart actions nad “ręcznym czatem do wszystkiego”. Produkt już zna lokalną intencję i dołącza właściwy kontekst startowy.

Gdzie najłatwiej popełnić błąd

Najczęstsze pomyłki są trzy:

• potraktowanie merge resolution jak pewnego automatu
• delegowanie słabo opisanego TODO i oczekiwanie idealnego wyniku
• akceptowanie rename suggestion tylko dlatego, że brzmi profesjonalnie

We wszystkich trzech przypadkach problemem nie jest samo AI. Problemem jest oddanie decyzji tam, gdzie nadal potrzebna jest odpowiedzialność człowieka.

Ćwiczenie praktyczne

Zrób jeden mały eksperyment z tej trójki:

1. Wybierz stary komentarz TODO i dopisz go tak, żeby był naprawdę konkretny.
2. Albo weź symbol, którego nazwa Cię drażni, i porównaj własny rename z sugestią AI.
3. Jeśli masz bezpieczne środowisko testowe, przećwicz konflikt merge i zobacz, jak AI składa warianty.

Po ćwiczeniu odpowiedz sobie:

• ile pracy usunęło AI
• jaki kontekst produkt dołączył za Ciebie
• w którym miejscu nadal potrzebna była decyzja inżynierska

To jest lepsza miara wartości niż samo “zadziałało”.

Kluczowe wnioski

• Merge conflicts, TODO delegation i rename suggestions to trzy różne workflow, nie jedna funkcja pod wspólnym szyldem AI.
• Merge conflict resolution pomaga składać warianty zmian, ale nie podejmuje decyzji architektonicznych za zespół.
• TODO implementation działa najlepiej wtedy, gdy komentarz jest precyzyjnym briefingiem, a nie pustym placeholderem.
• Rename suggestions potrafią poprawić nazewnictwo, ale nie znają domeny lepiej niż Ty i Twój zespół.
• Największa przewaga smart actions polega na starcie z właściwego miejsca w UI i z gotowym kontekstem problemu.

Co dalej

Teraz przechodzimy do smart actions, które pomagają nie tyle coś wygenerować, ile szybciej zrozumieć problem, naprawić go i zreviewować wynik.