O czym jest ten film
- Problem: gitowy diff pokazuje, co się zmieniło w kodzie, ale gdy zmiany wygenerował agent, odpowiedź na pytanie dlaczego przepada — zostaje sprasowana w kontekście rozmowy.
- Skala zjawiska: agent w jednej rozmowie potrafi wygenerować absurdalną ilość kodu. Zostaje lawina zmian, których sami ledwo rozumiemy — a tym trudniej wytłumaczyć je komuś innemu.
- Odpowiedź Zeda: Delta — wieloosobowe środowisko do kodowania z agentami, kompatybilne z Gitem, z własnym systemem wersjonowania (Delta DB).
- Nowa jednostka pracy: wątek, nie projekt. Coraz więcej przedsięwzięć zaczyna się od rozmowy, a kod jest jej produktem ubocznym; repozytorium podepina się później.
- Komentarze w miejscu: rozmowa toczy się „w linii”, a pytania zadaje się adnotacjami przy konkretnych fragmentach odpowiedzi, plików i diffów; kilka uwag można spakować w jedno wysłanie.
- Delta DB: drobne zmiany zapisywane na bieżąco pomiędzy commitami. Commit pozostaje punktem kontrolnym, a Delta zachowuje całą „podróż” między punktami.
- Multiplayer: udostępniony wątek to żywe miejsce pracy — druga osoba (w przeglądarce lub aplikacji) śledzi i współtworzy w czasie rzeczywistym, z trybem podglądu „follow”.
- Ekonomia: za kredyty płaci ten, kto klika „wyślij”, więc recenzent może komentować bez ponoszenia kosztów.
- Recenzja i „land”: podwątek z przewodnikiem po całej pracy, zbiorowe zatwierdzanie, a osobny krok „lądowania” zmian na gałęzi głównej — pull request w nowej odsłonie.
- Werdykt autora: Delta nie czyni modelu mądrzejszym — porządkuje kontekst. Do zadań jednorazowych wystarczy tradycyjne narzędzie (materiał sponsorowany przez Zed).
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zacznij od wątku, nie od projektu
Na czym polega: Delta odwraca typową kolejność. Zamiast najpierw zakładać repozytorium, a dopiero potem rozmawiać z agentem, punktem startu jest wątek — rozmowa, w której rodzi się pomysł. Kod i projekt są jej następstwem, nie warunkiem wstępnym.
Jak stosować: przy nowym pomyśle otwórz wątek i eksploruj swobodnie; folder z repozytorium podepnij dopiero wtedy, gdy dyskusja dojrzeje (w Deldzie: „dodaj do projektu”). Jeden wątek może zasilać kilka projektów naraz.
Na co uważać: przy zadaniach dobrze zdefiniowanych i jednorazowych ta dodatkowa warstwa tylko przeszkadza — klasyczne narzędzie do kodowania wystarczy.
2.Zapisuj „dlaczego”, nie tylko „co”
Na czym polega: standardowy diff pokaże zmiany w kodzie, ale nie powody decyzji — zwłaszcza gdy kod napisał agent, uzasadnienia giną w sprasowanym kontekście rozmowy. Delta (a w filmie także autorska umiejętność „bridge”) pozwala prowadzić wersjonowany dokument, który spina decyzje z konkretnymi miejscami w rozmowie.
Jak stosować: prowadź obok rozmowy plik typu bridge.md: decyzje, uzasadnienia, linki do punktów w wątku; aktualizuj go przy każdym commicie. Wtedy jeden dokument odpowiada na pytania „co zbudowałem”, „jak” i „dlaczego właśnie tak”.
Na co uważać: taki dokument ma wartość tylko przy bieżącej aktualizacji — odtwarzanie historii po fakcie odda jedynie fragment prawdy.
3.Komentuj dokładnie tam, gdzie rodzi się pytanie
Na czym polega: zamiast dopisywać wątpliwości końcem czatu, zaznaczasz konkretny fragment odpowiedzi agenta, pliku albo diffu i komentujesz bezpośrednio przy nim. Komentarz dziedziczy dokładnie ten kontekst, który wywołał pytanie, i zostaje zapisany w historii rozmowy.
Jak stosować: gdy coś jest niejasne, zaznacz fragment i zapytaj; możesz wrócić do miejsca sprzed dwudziestu minut i tam dopisać uwagę. Funkcja „portal” przeskakuje między komentarzem a miejscem, do którego się odnosi.
Na co uważać: pojedyncze, rozproszone uwagi łatwo się mnożą — grupuj je w paczki (punkt 4), żeby agent odpowiadał na całość, a nie na pojedyncze wtrącenia.
4.Pakuj wiele uwag w jedno wysłanie
Na czym polega: w Delcie sam Enter niczego nie wysyła — piszesz do woli, a dopiero Cmd/Ctrl+Enter przekazuje całość modelowi. Kilka komentarzy z różnych miejsc wątku zbiera się w jedną paczkę i wychodzi razem.
Jak stosować: przed wysłaniem przejdź po wątku, zbierz wszystkie pytania i dopiski, sprawdź paczkę i wyślij raz — agent odpowie na każdy punkt, a odpowiedź zostanie zalogowana.
Na co uważać: to wymaga przestawienia odruchów z innych czatów; z przyzwyczajenia łatwo czekać na reakcję po każdym Enterze.
5.Podpinaj repozytorium, gdy pomysł dojrzeje — i zamawiaj zmiany komentarzami w plikach
Na czym polega: wątek można w każdej chwili połączyć z projektem — wystarczy katalog zainicjowany jako repozytorium Gita. Od tego momentu pliki stają się częścią kontekstu wątku: komentuje się je bezpośrednio (np. README), nie edytując, a agent nanosi poprawki i tworzy dokumenty.
Jak stosować: utwórz folder, zrób git init, w wątku wybierz „add to project”. Komentarz w pliku to wygodne zamawianie zmian: mówisz agentowi, co poprawić, zamiast poprawiać samemu.
Na co uważać: jeden wątek może zasilać wiele projektów — pilnuj, które pliki i decyzje trafiają gdzie, żeby nie posypać porządku w repozytoriach.
6.Commit to punkt kontrolny — między nimi liczy się podróż
Na czym polega: Delta DB to replikowany system kontroli wersji, który zapisuje drobne zmiany rozmowy i projektu razem, na warstwie pod Gitem. Commit pozostaje punktem kontrolnym i łącznikiem z resztą ekosystemu, a Delta zachowuje wszystko, co wydarzyło się pomiędzy.
Jak stosować: korzystaj z linków do konkretnych miejsc rozmowy: wklejony do dokumentu adres potrafi przenieść współpracownika dokładnie tam, gdzie zapadła decyzja.
Na co uważać: Delta nie zastępuje Gita w kontaktach ze światem zewnętrznym — CI, hostingi czy ludzie pracujący na czystym Gicie nic o niej nie wiedzą. Traktuj ją jako warstwę pośrednią, nie nowy standard zespołowy.
7.Udostępniaj żywy wątek zamiast wysyłać podsumowania
Na czym polega: przekazanie pracy tradycyjnie oznacza podsumowanie — sprasowany dokument wręczany następcy. W Deldzie udostępnia się sam wątek: odbiorca widzi całą historię, dołącza jako aktywny uczestnik (przeglądarka lub aplikacja, pełna synchronizacja na żywo), a tryb „follow” pokazuje dodatkowo ekran współpracownika.
Jak stosować: zamiast pisać komuś streszczenie, wyślij link do wątku i pozwól komentować diffy oraz dokładać pytania — decyzje zapadają wspólnie, przy tym samym kontekście agenta.
Na co uważać: opcja „każdy, kto ma link” daje dostęp do wszystkiego, łącznie z repozytorium — w filmie pada przed nią słuszne ostrzeżenie.
8.Za kredyty płaci ten, kto klika „wyślij”
Na czym polega: model uruchamia osoba, która zatwierdza paczkę komentarzy. Recenzent może więc komentować bez ponoszenia kosztów — rachunek trafia do konta, z którego wyszło zapytanie.
Jak stosować: wykorzystaj to do taniej recenzji: przekaż kod czy dokumenty komuś do komentowania, a model odpytuj z własnego konta, uwzględniając już jego uwagi.
Na co uważać: każde „wyślij” na głównym koncie kosztuje — ustal w zespole, kto i kiedy uruchamia model, żeby uniknąć niespodzianek w rachunku.
9.Zamień pull request na recenzję i lądowanie
Na czym polega: funkcja „review” tworzy podwątek z przewodnikiem po całej dotychczasowej pracy: podsumowanie, mapa decyzji, dowody ich pochodzenia. Każdy uczestnik może recenzję zatwierdzić, a przycisk „land” wypycha zmiany na główną gałąź. To pull request (klasyczny mechanizm przeglądu zmian przed scaleniem) — tylko osadzony w pełnym kontekście i działający na żywo.
Jak stosować: po zamknięciu etapu wygeneruj recenzję, wyślij link recenzentowi, zbierz aprobaty i wykonaj lądowanie. Sprawdzanie i uzgadnianie dzieje się w czasie rzeczywistym, a nie przy wielkim diffie na sam koniec.
Na co uważać: zatwierdzenie recenzji samo nie scala commitów — publikacja zmian wymaga osobnego kroku „land”.
10.Zanim sięgniesz po Deltę, sprawdź, czy jej potrzebujesz
Na czym polega: Delta nie czyni modelu mądrzejszym — porządkuje i wersjonuje kontekst oraz otwiera go na współpracę. Wartość zależy jednak od tego, co sami do wątków wkładasz.
Jak stosować: jeśli śledzisz pochodzenie pomysłów i decyzji oraz dzielisz się nimi jako żywym dokumentem — potraktuj darmowy okres próbny na eksperymenty. Autor przekonuje, że całość „kliknęła” dopiero przy własnym komentowaniu i budowaniu dokumentów kontekstu.
Na co uważać: to wczesna beta i materiał sponsorowany przez Zed — część mechanizmów może się jeszcze zmienić, a ocena ma charakter pierwszego spojrzenia, nie pełnego testu.
Redakcyjne tłumaczenie
Dlaczego obecna praca z agentami się nie broni
Sposób, w jaki dziś pracujemy z agentami AI, trudno uznać za sensowny — zwłaszcza jeśli chodzi o zarządzanie kontekstem i kontrolę wersji. Gitowy diff pokazuje, co zmieniło się w kodzie czy plikach tekstowych. Ale gdy zmiany wygenerował agent, odpowiedź na pytanie „dlaczego” przepada — zostaje sprasowana w kontekście rozmowy.
Git powstał w 2005 roku po to, by programiści mogli wspólnie pracować nad projektami: przesyłali sobie migawki mailem i na ich podstawie bezpiecznie sprawdzali oraz scalali zmiany w kodzie. Od tamtej epoki dzieli nas długa droga, a najbardziej zmieniło się jedno — kodują teraz obok nas agenty. W pojedynczej rozmowie agent wygeneruje absurdalną wręcz ilość kodu, znacznie więcej, niż człowiek napisałby w tym samym czasie. Zostaje nam lawina zmian, w których sami ledwo się orientujemy — a co dopiero pomagać zrozumieć je komuś innemu.
Zed uważa, że z nowym projektem Delta uporał się z problemem kontekstu w agentowym kodowaniu. Czy słusznie?
Cześć, jestem Callum, w sieci znany jako Wanderloots, i witam w odcinku o Deldze — o drodze od kontekstu do ciągłej inżynierii. Zobaczymy, czym Delta jest, czym różni się od tego, co znamy, jak działa i kto powinien jej spróbować. Dziękuję Zedowi za sponsoring tego materiału i możliwość pokazania nowego sposobu pracy z kontekstem i agentami — ten problem chodzę wokół od lat, więc nie mogę się doczekać, aż pokażę, jak to działa. Wersję do bezpłatnego wypróbowania znajdziecie pod linkiem w opisie. Zaczynajmy.
(Informacja dodatkowa: Zed to popularny, otwartoźródłowy edytor kodu; Delta to jego nowość — wieloosobowe środowisko do kodowania z agentami, w fazie testów.)
Nie mądrzejszy model, tylko porządny kontekst
Klucz do zrozumienia Delty: to nie jest projekt o tym, żeby model był mądrzejszy. Chodzi o to, żeby kontekst i wszystko, co otacza pracę z agentem, stały się łatwiejsze do nawigowania i porządnie wersjonowane w czasie. Kontekstu mamy dziś więcej niż kiedykolwiek, ale więcej nie znaczy lepiej. Potrzebujemy narzędzi, które doprowadzą nas do właściwego materiału dokładnie wtedy, gdy go potrzebujemy — i pozwolą podzielić się nim z innymi. W ten sposób praca, i z samym sobą, i z agentami, staje się ciągła. Deltę można więc potraktować jako warstwę kontekstu i współpracy, kompatybilną z Gitem.
Najważniejsza zmiana myślenia: wątek (thread) staje się pojęciem nadrzędnym wobec projektu. Coraz więcej przedsięwzięć zaczyna się od rozmowy, a kod z niej wypływa — jest produktem ubocznym konwersacji prowadzonych z agentami. Delta chce, żeby praca z taką nieprzerwaną rozmową i z kodem, który z niej wynika, szła gładko i była śledzalna; żeby stanowiła żywy kontekst. Dlatego Delta zaczyna od wątku, nie od projektu — to nowa, podstawowa jednostka agentowego kodowania. Wątek to nie zwykły czat: to miejsce, w którym praca się dzieje i w którym jej historia pozostaje pod ręką.
Pierwsze uruchomienie
Zanim zejdziemy głębiej w teorię, lepiej zobaczyć Deltę w akcji — wtedy łatwiej będzie zrozumieć, o co mi chodzi przy poszczególnych funkcjach. Pod linkiem w opisie znajdziecie stronę z bezpłatnym okresem próbnym. Sam Zed to klasyczne IDE, a Delta jest środowiskiem wieloosobowym — o współpracy wielu osób jeszcze porozmawiamy. Klikamy pobieranie, akceptujemy warunki bety, instalujemy. I tak mniej więcej wygląda Delta.
Po wejściu wita nas wątek „Witaj w Delcie”. Wyjaśnia, że mamy do czynienia ze środowiskiem wieloosobowym do kodowania z agentami i przeglądania tego, co budują. To znakomity wstęp: pokazuje, że Delta działa trochę inaczej, i przeprowadza przez podstawowe komendy. Gorąco polecam przejść ten samouczek od początku do końca.
Wątek bez okienka czatu
Stwórzmy pierwszy wątek. Klikam „utwórz wątek”, otwiera się nowy. Piszę „cześć”. Enter — i nic się nie dzieje. Można tu napisać, ile się chce, a do modelu trafi to dopiero po Cmd+Enter. Ale mnie najbardziej intryguje co innego: nie ma tu pola czatu. Nie ma znajomego okienka na dole ekranu — rozmowa toczy się po prostu w linii, w miarę pisania. Dlaczego to ważne, zobaczymy przy komentowaniu.
Druga różnica: utworzyliśmy wątek, a nikt nie kazał nam od razu podpinać projektu. Działamy bowiem w trybie „najpierw wątek”: zaczynamy od pomysłu, a dopiero później dochodzi projekt. To ciekawa odwrócona kolejność — zamiast zmuszać się do zdefiniowania, czym projekt ma być, wchodzimy w tryb eksploracji, a projekt, który wyrośnie z wątku, podepniemy wtedy, kiedy będzie potrzebny. Wrócę do tego za chwilę.
Umiejętności — wielokrotnego użytku pakiety instrukcji
Przetestujmy to. Piszę: „Mam pomysł na nową umiejętność. Chcę, żebyś pomógł mi wybrać najlepszy kierunek. Najpierw zwięźle wyjaśnij, czym jest umiejętność i jak Delta z nich korzysta”. I widzimy, że żeby odpowiedzieć, Delta załadowała umiejętność — „Delta help”, czyli pakiet z całą wbudowaną dokumentacją. Umiejętność (ang. skill) to wielokrotnego użytku pakiet specjalistycznych instrukcji; można w nim zawrzeć skrypty i zasoby, które uczą Deltę, jak radzić sobie z określonym typem zadania.
Komentarz przy fragmencie, a nie końcem czatu
Mógłbym teraz po prostu ciągnąć rozmowę tam i z powrotem, ale mogę też komentować — anotować — konkretne fragmenty odpowiedzi. Zaznaczam kawałek tekstu i od razu w nim piszę: „Jak wyglądałoby drzewo plików prostej umiejętności i czym różniłoby się drzewo dla czegoś bardziej złożonego?”. Na dole od razu pojawia się komentarz przypięty do odpowiedzi agenta. I tu znów Delta idzie pod prąd: zamiast rozmawiać „wzdłuż dołu ekranu”, mogę zaznaczyć dokładnie ten fragment, który wywołał moje pytanie, i zapytać właśnie przy nim — albo rozwinąć konkretny wątek albo kierunek.
Mogę też cofnąć się wyżej, skomentować tam, a ten komentarz sam spłynie na dół, do paczki uwag, którą za chwilę wyślę. Komentarzy mogę dodać, ile chcę, i dopiero Cmd/Ctrl+Enter przekazuje wszystko modelowi. Na marginesie działa przycisk „portal”: klikam i przeskakuję prosto do oryginalnego komentarza wyżej; stamtąd mogę wrócić z powrotem na dół.
To banalny przykład, ale wyobraźcie sobie, że nowy pomysł dotyczy czegoś, nad czym pracowaliście dwadzieścia minut temu. Wracacie, komentujecie, dorzucacie uwagę do paczki, klikacie wyślij — i agent odpowiada na każdy komentarz w wątku. Odpowiedź zostaje zalogowana, ja ją przeglądam i wracam na dół. Właśnie zaczyna się to zarządzanie kontekstem, o którym mówiłem: poruszam się między promptami i komentarzami w sposób, jakiego nie widziałem w innych narzędziach. Wątek bez trudu staje się dokumentem, po którym nawiguję w czasie.
Delta DB — ciągłość zamiast migawek
Te elementy zmieniają się w czasie i tworzą delty, które trafiają do bazy Delta DB. Jej cel: ciągły kontekst zamiast migawek. Delta DB to replikowany system kontroli wersji, na którym działa cała Delta; zapisuje on drobne zmiany w projekcie i w rozmowie razem. Git pozostaje warstwą punktów kontrolnych i łącznikiem z szerszym ekosystemem. Zamiast zmagać się z wielkimi migawkami, przestrzeń między commitami Gita zostaje pokrojona na delty — małe zmiany rozłożone w czasie — działające na warstwie pod Gitem, więc w pełni z nim kompatybilne. Każdy commit traktujcie jak punkt kontrolny (checkpoint); Delta stara się zachować podróż między punktami.
Most kontekstowy — mój pomysł na umiejętność
Mój pomysł: zbudować „most kontekstowy”, który będzie śledził moje prompty z tej rozmowy, komentarze do nich i zmiany w Gicie, a przy tym tworzył plik bridge.md — dokument zapisujący na bieżąco wprowadzane zmiany. Dzięki temu, wysyłając kolejne commity, mam jeden wersjonowany dokument, który pokazuje nie tylko to, co zbudowałem i jak, ale odsyła do konkretnych miejsc w wątku Delty i wyjaśnia, dlaczego zbudowałem to właśnie tak.
To, co dostałem, to szkielet pierwszej wersji tej umiejętności — generatora migawek kontekstu — z poleceniami /bridge, bridge update i bridge status. Chcę jednak trochę więcej i tu znowu z pomocą przychodzi komentowanie. Nie chcę tylko „zaakceptowanych decyzji i uzasadnień” zbieranych automatycznie — chcę móc dopisywać je sam. Komentuję więc: „Czy możemy dodać polecenie add-to-bridge, które pozwoli mi zaznaczyć fragment i przesłać go do tego rosnącego dokumentu w biegu?”. Komentarz spływa na dół. Dorzucam kontekst: „Przygotuj proszę mikro-PRD, czyli zwięzły dokument wymagań produktowych”. Agent odpowiada na uwagę o add-to-bridge i tworzy skrócony zapis pomysłu.
Szczerze mówiąc, brzmi to całkiem nieźle — mamy komplet operacji, a wątek urósł do rangi czegoś, wokół czego warto tworzyć dokumenty. I to jest właśnie moment, w którym przechodzimy z fazy szukania pomysłów — samej rozmowy — do prawdziwego projektu. Stwórzmy go i podepnijmy do tego wątku, zanim zaczniemy się nim dzielić.
Wątek spotyka repozytorium
Utworzyłem nowy folder i zainicjowałem go jako repozytorium Gita (jeśli nie wiesz, jak to zrobić, odsyłam do mojego filmu o Gicie). Teraz klikam „dodaj do projektu”, wybieram umiejętności i otwieram projekt Gitowy. Wątek od razu przeskoczył wyżej, do sekcji projektów. Można dorzucić kolejne — nie musi to być jeden; jeden wątek może zasilać kilka różnych projektów. To po prostu inna, odwrócona kolejność: najpierw rozmowa, potem reszta.
Z boku, na górze, widnieje pusty plik README. Mogę komentować go bokiem — i to jest fajne, bo nie wprowadzam zmian bezpośrednio w pliku. Komentuję agentowi, jaką zmianę chcę mieć zrobioną: „Proszę zaktualizować ten README — jest nieaktualny” oraz „Proszę utworzyć dokument dla tego konceptu: mikro-PRD wersja pierwsza”. Cmd+Enter, wysyłam. I już: agent utworzył nowy plik README w panelu obok, a do tego folder docs. Mogę otworzyć właśnie powstały dokument wymagań i — jeśli zechcę — skomentować dowolny jego element; komentarze pojawiają się z boku. Kontekst tego, nad czym pracuje agent, i sama rozmowa są ze sobą spięte. Tym razem portal prowadzi mnie bokiem, do plików, a nie w górę, do wcześniejszego komentarza. Mam nadzieję, że zaczynacie widzieć, jak kontekst zrasta się z wątkiem: gdy dochodzi projekt, pliki również stają się częścią materiału, w którym porusza się rozmowa.
Praca solo: ścieżka własnych myśli
To działa i w pojedynkę, i zespołowo. Samemu wątek Delty staje się ścieżką dla waszych pomysłów: gdy prowadzicie kilka projektów naraz, łatwo wrócić do wcześniejszego toku myślenia i podjąć go dokładnie tam, gdzie się skończyło. I nie tylko wy macie dostęp do tej rozrastającej się ścieżki — także agenci, z którymi pracujecie, oraz inni ludzie, albo jedno i drugie. Warstwa współpracy sprawia, że Delta świetnie sprawdza się w trybie wieloosobowym — zarówno z agentami, jak i z ludźmi: możecie udostępnić wątek komukolwiek, a ta osoba dołączy dokładnie we właściwym miejscu, jako aktywny współpracownik wątku i projektu. Trochę jak dorzucenie współedycji znanej z Google Docs do narzędzi do agentowego kodowania.
W większości narzędzi, gdy dzielicie się wątkiem czy czatem, można zajrzeć wstecz, ale nie w przód. Zwykły diff pokazuje, co się zmieniło. Delta potrafi pokazać, dlaczego się zmieniło — co nie zadziałało i jak doszliśmy do obecnego stanu. Dopisuje historię pochodzenia decyzji do warstwy kontekstu w pracy z agentami i z ludźmi. Nie pracujecie równolegle, niepewni, co porabia druga strona, tylko nad tym samym projektem, w tym samym czasie, z tym samym kontekstem agenta. Przekazanie pracy przestaje być podsumowaniem — statycznym, sprasowanym dokumentem wręczanym komuś innemu — bo przekazać można samo miejsce, w którym praca się dzieje.
Dwa konta, jeden wątek: recenzja na żywo
Mamy solidny plan budowy, ale chcę posłuchać kogoś z zespołu. Niech twórca Callum podzieli się wątkiem z recenzentem Callumem. U góry klikam „udostępnij”. Do wyboru: dostęp tylko dla zaproszonych albo dla każdego, kto ma link. Po kliknięciu tego drugiego pojawia się ostrzeżenie: to daje dostęp do wszystkiego, łącznie z repozytorium. Z tą opcją trzeba ostrożnie. Zaprosiłem swój drugi adres e-mail i akceptuję zaproszenie do wątku. Żeby pokazać różnicę, otworzę go właśnie w przeglądarce.
I proszę: udostępniłem wątek drugiemu kontu i przyszło wszystko — pełna historia rozmowy. Mogę wrócić aż do samego początku, ale też przejść aż do końca. Gdy zaczynam pisać, tekst natychmiast pojawia się w moim programie na desktopie. Po lewej aplikacja, po prawej wersja webowa. Mogę rozwinąć listę plików, bo repozytorium jest podpięte, i wracać do zmian. Na przykład: właśnie doszliśmy do mostu kontekstowego w wersji drugiej — a jak wyglądała pierwsza? Zaznaczam ten fragment; od razu podświetla się po drugiej stronie. Piszę: „Czym różniła się wersja pierwsza? Proszę o zwięzłe wyjaśnienie” — i w czasie rzeczywistym widać, jak pytanie pojawia się z boku.
I tu ciekawostka ekonomiczna: recenzent nie musi nic wysyłać. Za kredyty płaci ten, kto kliknie „wyślij”. Można więc oddać dokumenty albo kod komuś do sprawdzenia i po prostu uwzględnić jego uwagi. Konto pierwsze zostawiło komentarz z pytaniem, konto drugie śledzi wszystko na żywo — pełna synchronizacja. Chodzi o to, że udostępniona osoba nie tylko zagląda do przeszłości, żeby zobaczyć, jak doszliśmy do tego punktu: wchodzi do rozmowy i staje się częścią wątku w miarę, jak powstaje kolejny kod. Mogę wrócić na swoje konto, skomentować „tak, brzmi dobrze”, poprosić agenta o przepisanie dokumentu do następnej wersji — a drugie konto patrzy na te zmiany w czasie rzeczywistym. Recenzent przechodzi po nich i komentuje: „to ma sens, podoba mi się” — przy tym może komentować dokładnie diff; te uwagi pojawiają się u mnie i wchodzą do rozmowy oraz historii decyzji. Decyzje zapadają wspólnie, a ja jednym kliknięciem przeskakuję do miejsca, w którym druga strona zgłasza swoją uwagę.
Tryb śledzenia
Zajmę się teraz chwilę właściwym budowaniem, a że to potrwa, pokażę jeszcze jedną funkcję: follow. Klikam drugie konto i nagle mój ekran pokazuje to, co widzi tamta osoba. Przy dwóch oknach obok siebie lekko to zakręcone, ale widzę na przykład, że tamto konto właśnie zaczęło komentować — i mogę krok po kroku śledzić, co robi. To pomocny mostek: przeskakujesz do obecnego toku myślenia kolegi dokładnie wtedy, gdy on podąża twoim wcześniejszym tokiem. Naprawdę zgrabny system wspólnej pracy: planowanie, budowanie, wykonanie i recenzja razem, cały czas na tym samym agencie i w tym samym kontekście.
Most w akcji: podsumowanie, mapa decyzji, dowody
Umiejętność właśnie się zbudowała. Widać, że most kontekstowy powstał kompletnie, od początku do końca, razem z commitami opisującymi, jak działa — a to, że mogę obserwować ten proces na żywo, samo w sobie jest fajne. A tak wygląda efekt: krótkie podsumowanie całości, mapa rezultatów mówiąca, skąd wzięły się poszczególne decyzje, i dowody ich pochodzenia. Teraz, gdy wpiszę /bridge, pojawi się umiejętność; klikam ją, kopiuję na przykład link do udostępnienia i uruchamiam — umiejętność przepisze dokument do następnej wersji, z pierwszego punktu kontrolnego do drugiego. A ponieważ wkleiłem link, do dokumentu trafi nowe źródło: adres prowadzący dokładnie do tego miejsca w rozmowie. Dokument wskoczył na drugi punkt kontrolny, z dopisanym adresem. Chcąc się podzielić tą konkretną decyzją, kopiuję link, a odbiorca otwiera go w przeglądarce i ląduje dokładnie tam, gdzie zrobiłem migawkę — tak jak ja przed chwilą. Przy tej umiejętności jest jeszcze sporo do dopracowania i będę ją rozwijał, ale na koniec pokażę jeszcze jeden sposób wspólnej pracy: recenzowanie i lądowanie.
Recenzja i lądowanie — pull request w nowej odsłonie
Funkcja recenzji automatycznie tworzy podrozmowę — podwątek całego czatu — i przygotowuje przewodnik na podstawie wszystkiego, co się tu wydarzyło. Można go udostępnić: kopiuję link i przekazuję komuś do sprawdzenia. Recenzja się zakończyła; oto przewodnik zbudowany z całego kontekstu tego wątku — podsumowanie wszystkiego, co stało się wzdłuż commitów Gita. Klikam „prześlij recenzję” i „zatwierdź”; widać, że moje konto właśnie zaaprobowało. A ponieważ podzieliłem się wątkiem, druga osoba też może kliknąć zatwierdzenie — i proszę: oba konta oddały głos. Zamiast zmagać się z pull requestem, tworzycie recenzję, a recenzent dostaje pełny przegląd tego, co się stało, wraz z wyjaśnieniami całego kodu.
(Informacja dodatkowa: pull request to standardowy w Gicie mechanizm proponowania zmian — z dyskusją i przeglądem przed scaleniem z główną gałęzią.)
Gdy recenzja zostanie zatwierdzona, sama z siebie nie publikuje ani nie scala commitów. Klikam przycisk „land”, który otwiera mój sposób załatwiania tego, jak zacommitować całość i wypchnąć na main. Delta pyta, jak to zrobić; tworzy nową umiejętność lądowania, a ja klikam „tak, proszę”. Wszystko wylądowało.
Efektywnie zrobiliśmy właśnie recenzję i lądowanie — możecie o tym myśleć jak o innej formie pull requesta, z tą różnicą, widzianą na własne oczy, że wszystko można sprawdzać, uzgadniać i obrabiać na żywo, w trakcie samego recenzowania i lądowania. Zamiast wpatrywać się w gigantyczny diff i zgadywać, co się stało, uczestniczysz w procesie na każdym etapie: przy szukaniu pomysłów, planowaniu, realizacji, wdrożeniu, recenzji i lądowaniu.
Moja ocena
Jak dla mnie — naprawdę ciekawe narzędzie. Podoba mi się, jak Delta i Zed inaczej myślą o kontekście agentowym i o tym, żeby uczynić ten proces wieloosobowym. Ale klucz jest taki: Delta po prostu daje nam więcej kontekstu. To wciąż nasza sprawa, żeby kontekst wchodzący do tych wątków miał wartość — dla nas samych albo dla ludzi, z którymi pracujemy. Jeśli od agentów zamawiacie jednorazowe zadania, być może nie potrzebujecie tej rozszerzonej warstwy i tradycyjne narzędzie do kodowania wystarczy. Ale jeśli zależy wam na śledzeniu, skąd wzięły się wasze pomysły i decyzje — i na dzieleniu się tą historią jako żywym dokumentem — Delta może wam przypaść do gustu.
Cel to ciągła inżynieria: utrzymanie flow zamiast spisywania wszystkiego w podsumowania i wręczania ich kolejnym osobom. Polecam po prostu poeksperymentować — wersja próbna jest darmowa, a link w opisie wspiera kanał. U mnie wszystko poukładało się dopiero, gdy zacząłem eksperymentować, komentować i składać elementy, które Delta odblokowuje, w lepszy dokument kontekstu — dla siebie i dla ludzi, z którymi pracuję. Jeśli materiał był pomocny, dajcie lajka, hype’a i subskrypcję — bardzo to doceniam. Dzięki za obejrzenie i do zobaczenia w następnym odcinku.