W skrócie: Artykuł dowodzi, że model commitów i pull requestów w Git jest zbyt wolny i ubogi w kontekst dla programowania wspieranego przez AI, ponieważ agenci generują ciągły strumień decyzji i zmian, a nie odrębne snapshoty. Proponuje DeltaDB – strumień drobnoziarnistych delt, który łączy rozmowy z ewoluującym kodem, umożliwia jednoczesną edycję przez ludzi i agentów dzięki CRDT oraz zachowuje Git do dystrybucji, CI i czystej publicznej historii.
- Tradycyjne pull requesty oddzielają kod od rozumowania prowadzonego w czasie rzeczywistym, które go wytworzyło, co opóźnia informację zwrotną i zaciemnia intencję.
- DeltaDB rejestruje każdą operację w worktree ze stabilną tożsamością, pozwalając prześledzić kod i rozmowę w dowolnym momencie ich ewolucji.
- Replikowane worktree oparte na CRDT mają pozwolić ludziom i agentom edytować jednocześnie, bez blokad i klasycznych konfliktów scalania.
- Git pozostaje przydatny jako zewnętrzny protokół referencyjny i do końcowej weryfikacji, a DeltaDB pełni rolę warstwy współpracy.
- Strumienie delt poprawiają kontekst, ale wprowadzają kompromisy w zakresie przechowywania danych, wydajności i spójności ostatecznej (eventual consistency), które wymagają solidnej infrastruktury i stabilnie zamontowanych worktree.
Tradycyjne commity kompresują pracę do snapshotów. Agenci AI wytwarzają strumień decyzji, zmian, poprawek i kontekstu, który wymaga innego modelu współpracy.
Tradycyjna kontrola wersji jest zbudowana wokół „snapshotu” – odrębnego momentu, w którym programista uznaje, że jego praca nadaje się do udostępnienia. W DataTip od dekad żyjemy z ceremonią pull requestu, ale w miarę jak włączamy agentów AI do codziennej pracy, ta granica staje się strukturalnym obciążeniem. Wymiana komentarzy na statycznych snapshotach to już nie tylko niedogodność – to bariera dla ciągłej rozmowy, która dziś definiuje nowoczesne tworzenie oprogramowania. W erze autonomicznych agentów czekanie na commit to zabójcze wąskie gardło. Potrzebujemy systemu, który rejestruje pracę w trakcie jej powstawania, a nie tylko gotowy produkt. Wychodząc poza commit, musimy dostrzec fundamentalną zmianę: rozmowa, która generuje kod, staje się prawdziwym źródłem naszego oprogramowania. Ten dialog toczy się nieprzerwanie i musi być powiązany z kodem w miarę jego zmian. Git, zorganizowany wokół odrębnych commitów, nigdy nie był projektowany z myślą o takiej szczegółowości. Zmierzamy ku rzeczywistości, w której kod źródłowy jest w praktyce rozmową źródłową, a nasze narzędzia muszą tę zmianę odzwierciedlać. Ten artykuł wyjaśnia, dlaczego model snapshotów zawodzi i dlaczego potrzebna jest nowa abstrakcja – oparta na drobnoziarnistych deltach – aby zniwelować lukę między ludzką intencją a wykonaniem przez maszynę.
Porażka ceremonii pull requestu
Tradycyjne pull requesty i kontrola wersji oparta na snapshotach (Git) tworzą tarcie, oddzielając rozmowę od kodu. W środowiskach o wysokim zaufaniu i dużym tempie rytuał commitowania, pushowania i czekania na code review często następuje długo po podjęciu najważniejszych decyzji technicznych. Przekonaliśmy się, że prawdziwa współpraca odbywa się w worktree, a nie w wątku PR. Kiedy czekamy na PR, by omówić kod, w gruncie rzeczy przeprowadzamy sekcję zwłok decyzji, która zapadła wiele godzin lub dni wcześniej. Zanim recenzent – człowiek lub agent – spojrzy na snapshot, kontekst pierwotnego toku myślenia zdąży się już rozmyć. Git narzuca synchroniczne opóźnienie na proces asynchroniczny, co utrudnia radzenie sobie z wąskim gardłem produktywności AI, które pojawia się, gdy narzędzia działają szybciej niż nasze cykle przeglądu. Ceremonia PR była substytutem zaufania w świecie sprzed agentów, ale dziś działa po prostu jak bufor, który ukrywa „dlaczego” za „co”. W praktyce wymieniamy dopasowanie w czasie rzeczywistym na czystą historię, której i tak nikt nie czyta.
Dlaczego agenci AI łamią model snapshotów
Rozwój agentów AI spotęgował potrzebę ścisłego powiązania kodu z rozmową. Agent nie musi jedynie widzieć bieżącego stanu pliku – musi rozumieć intencję stojącą za zmianami. W standardowym workflow Git ta intencja jest ukryta w komunikacie commita lub w osobnym oknie czatu. To rozdzielenie prowadzi do braku wspólnego zrozumienia między człowiekiem a autonomicznym agentem. Gdy agent gubi wątek rozmowy, zaczyna odbiegać od standardów architektonicznych projektu. Jeśli agent edytuje worktree, nie powinno być konieczne czekanie, aż skończy „porcję” pracy, by zobaczyć lub skorygować kierunek jego działań. Rozmowa jest prawdziwym źródłem oprogramowania. Ten ciągły strumień myśli musi być powiązany z kodem, gdy ten zmienia się w czasie rzeczywistym, tak aby ani komunikat, ani zmiana nie oddalały się od siebie. Bez tego zostaje nam luka przewidywalności, w której nie możemy w pełni ufać, że wynik pracy agenta odpowiada instrukcjom słownym sprzed trzech promptów.
Przedstawiamy DeltaDB: strumień drobnoziarnistych delt
DeltaDB to nowy system kontroli wersji oparty na drobnoziarnistych deltach zamiast odrębnych commitów. Zamiast robić snapshot co kilka godzin, DeltaDB rejestruje każdą pojedynczą operację w worktree i nadaje każdej z nich stabilną, adresowalną tożsamość. To nie jest po prostu „autozapis” dla Git; to fundamentalne przeprojektowanie sposobu śledzenia stanu. Przechodząc od snapshotów do strumieni, osiągamy rozdzielczość wersjonowania dorównującą szybkości myśli. Ponieważ każda delta jest indywidualnie adresowalna, można wskazać kod w dowolnym konkretnym momencie jego ewolucji. To fundamentalne odejście od architektury Git. Pozwala nam wersjonować worktree w miarę jego ewolucji, razem z rozmową, która go napędza. Można przeskoczyć od linijki w dawnym czacie do dokładnego stanu kodu z chwili, gdy ta linijka została napisana, lub odwrotnie. Taki poziom analizy treści technicznych sprawia, że historia projektu jest żywym zapisem, a nie cmentarzem commitów scalonych przez squash. W DeltaDB stos „cofnij” i historia wersji stają się tym samym.
Jednoczesna edycja dzięki bezkonfliktowo replikowanym worktree
Jak wielu agentów i ludzi może pracować nad tym samym plikiem bez znienawidzonego konfliktu scalania? System wykorzystuje bezkonfliktowo replikowane worktree (CRDT), aby ludzie i agenci mogli jednocześnie edytować te same pliki. To ta sama technologia, która napędza edytory do współpracy, takie jak Google Docs, ale zastosowana do całego systemu plików projektu. Agenci mogą pracować przez terminal lub przez zamontowane worktree, co pozwala korzystać z własnych lokalnych narzędzi, podczas gdy agent działa w tle. Ta architektura eliminuje potrzebę „blokowania” plików lub rozwiązywania złożonych konfliktów scalania po długotrwałym zadaniu agenta. Wielu uczestników – ludzi lub syntetycznych – może dojść do tego samego stanu pliku bez ceremonii scalania. Worktree przestaje być prywatną piaskownicą, a staje się wspólnym, żywym artefaktem. Gdy znika potrzeba „commitowania, by współpracować”, członek zespołu może dołączyć do trwającej sesji, porozmawiać z agentem wykonującym pracę i dodawać adnotacje do kodu w trakcie jego pisania.
Kiedy zostać przy Git: rola CI i dystrybucji
Kiedy nie należy używać strumienia opartego na deltach? Warto wyjaśnić, że DeltaDB nie zastępuje w całości całego ekosystemu. Git i CI pozostają do zewnętrznej integracji i kontroli. Git doskonale sprawdza się jako „protokół referencyjny” dla reszty świata i do uruchamiania końcowych pipeline’ów weryfikacyjnych przed wydaniem. Nikt nie chce, by „chaotyczny” strumień każdego pojedynczego naciśnięcia klawisza był publiczną historią repozytorium. Postrzegamy DeltaDB jako warstwę współpracy, w której odbywa się właściwa praca, podczas gdy Git pozostaje warstwą dystrybucji. DeltaDB służy do budowania oprogramowania poprzez rozmowę i drobnoziarnistą iterację, a Git – do spakowania tej pracy dla świata zewnętrznego. Ten podział pozwala utrzymać czystą historię w Git, a jednocześnie korzystać z surowego, nieedytowanego kontekstu strumienia DeltaDB na etapie rozwoju. To jak różnica między sesją nagraniową w studiu na żywo a ostatecznym, zmasterowanym utworem.
Od kodu źródłowego do rozmowy źródłowej
W tej nowej erze każde odwołanie jest zakotwiczone w delcie, a nie w numerze linii. Oznacza to, że odwołania przetrwają, nawet gdy kod wokół nich się przesuwa lub zmienia. Jeśli agent napisze funkcję i zostanie ona omówiona, ta dyskusja pozostaje powiązana z konkretną logiką, niezależnie od tego, gdzie zostanie później zrefaktoryzowana. Rozwiązuje to odwieczny problem „zepsutych linków” w dokumentacji lub komentarzach PR, które wskazują na kod, którego w danej linii już nie ma. Powstaje w ten sposób przeszukiwalna, odpytywalna historia intencji. Agenci mogą czerpać z tego kontekstu, by zrozumieć, dlaczego zastosowano dany wzorzec, albo „zwołać” wcześniejszych agentów, którzy pracowali nad fragmentem kodu, by poprosić o wyjaśnienia. W praktyce rozwiązujemy kryzys długu wiedzy, dbając o to, by „dlaczego” nigdy nie było oddzielone od „co”. Skoro kod jest obciążeniem, jak często mówimy, jedynym sposobem zarządzania tym obciążeniem jest pełny zapis rozmowy, która uzasadniła jego istnienie.
Kompromisy techniczne: snapshoty kontra strumienie delt
Choć korzyści strumieni delt dla współpracy są oczywiste, trzeba wziąć pod uwagę kompromisy techniczne. Systemy oparte na snapshotach, takie jak Git, są bardzo wydajne pod względem przechowywania danych, ponieważ mogą stosować kompresję delta na dużych porcjach danych naraz. System strumieniowy, taki jak DeltaDB, musi obsłużyć znacznie większą liczbę pojedynczych operacji, co wymaga solidnego backendu bazodanowego, by utrzymać wydajność. Jednak w przypadku aktywnego worktree firmy zatrudniającej 10–200 osób narzut jest znikomy w porównaniu z przyrostem produktywności dzięki współpracy z agentami w czasie rzeczywistym. Co więcej, przejście na CRDT oznacza, że „prawda” o pliku jest ostatecznie spójna (eventually consistent). Choć sprawdza się to doskonale przy edycji tekstu, wymaga ostrożności, gdy agenci uruchamiają kompilatory lub zestawy testów na worktree. Dlatego DeltaDB pozwala zamontować worktree na dysku, dzięki czemu istniejący zestaw narzędzi – kompilatory, lintery i debuggery – widzi stabilny system plików, nawet gdy bazowe delty są synchronizowane przez sieć.
Podsumowanie i kolejne kroki
Fundamenty pod to rozwiązanie zaczęliśmy budować w Zed w 2021 roku i wreszcie jesteśmy gotowi sprawdzić, jak radzi sobie z rzeczywistymi obciążeniami. W najbliższych tygodniach zaczniemy udostępniać DeltaDB pierwszym użytkownikom. Jeśli mają Państwo dość ceremonii PR i są gotowi na system kontroli wersji, który naprawdę rozumie, jak pracują agenci, czas wyjść poza commit. Oprogramowanie nabiera dziś kształtu w rozmowie, a nie w snapshocie.
Następny krok
Ten artykuł to techniczne stanowisko; nie wymaga nachalnego CTA sprzedażowego. Porozmawiajmy z DataTip.