TL;DR: Článok argumentuje, že model commitov a pull requestov v Gite je príliš pomalý a chudobný na kontext pre vývoj s podporou umelej inteligencie, pretože agenti generujú nepretržité rozhodnutia a úpravy, nie diskrétne snímky. Navrhuje DeltaDB, jemnozrnný delta stream, ktorý prepája konverzácie s vyvíjajúcim sa kódom, podporuje súčasné úpravy ľuďmi a agentmi pomocou CRDT a zachováva Git pre distribúciu, CI a čistú verejnú históriu.
- Tradičné pull requesty oddeľujú kód od úvah v reálnom čase, ktoré ho vytvorili, čím oneskorujú spätnú väzbu a zakrývajú zámer.
- DeltaDB zaznamenáva každú operáciu v pracovnom adresári so stabilným identifikátorom, čo umožňuje používateľom prezerať kód a konverzáciu v ktoromkoľvek bode jeho vývoja.
- Replikované pracovné adresáre založené na CRDT majú umožniť ľuďom a agentom súčasne upravovať bez zámkov alebo konvenčných konfliktov pri zlučovaní.
- Git zostáva užitočný ako externý protokol záznamu a na konečné overenie, zatiaľ čo DeltaDB slúži ako vrstva spolupráce.
- Delta streamy zlepšujú kontext, ale prinášajú kompromisy v oblasti úložiska, výkonu a výslednej konzistencie, ktoré vyžadujú robustnú infraštruktúru a stabilné pripojené pracovné adresáre.
Tradičné commity komprimujú prácu do snímok. Agenti umelej inteligencie produkujú prúd rozhodnutí, úprav, opráv a kontextu, ktorý si vyžaduje iný model spolupráce.
Tradičná správa verzií je navrhnutá okolo „snímky“ – diskrétneho okamihu v čase, keď sa vývojár rozhodne, že jeho práca stojí za zdieľanie. V DataTip sme desaťročia žili s ceremóniou pull requestu, ale keďže integrujeme agentov umelej inteligencie do našich každodenných pracovných postupov, táto hranica sa stáva štrukturálnym záväzkom. Trenie výmeny komentárov na statických snímkach už nie je len nepríjemnosťou; je to prekážka nepretržitej konverzácie, ktorá dnes definuje moderný vývoj softvéru. V ére autonómnych agentov je čakanie na commit fatálnym úzkym hrdlom. Potrebujeme systém, ktorý zachytáva prácu tak, ako prebieha, nielen hotový produkt.
Za commitom musíme uznať zásadný posun: konverzácia, ktorá generuje kód, sa stáva skutočným zdrojom nášho softvéru. Tento dialóg prebieha nepretržite a musí byť krížovo odkazovaný na kód, ako sa mení. Git, organizovaný okolo diskrétnych commitov, nebol nikdy navrhnutý na podporu tejto úrovne granularity. Smerujeme k realite, kde je zdrojový kód v podstate zdrojovou konverzáciou a naše nástroje musia odrážať tento posun. Tento článok skúma, prečo model snímok zlyháva a ako je potrebná nová abstrakcia – postavená na jemnozrnných deltách – na preklenutie priepasti medzi ľudským zámerom a strojovým vykonávaním.
Zlyhanie rituálu pull requestov
Tradičné pull requesty a verzovanie založené na snímkach (Git) vytvárajú trenie tým, že oddeľujú konverzáciu od kódu. V prostrediach s vysokou dôverou a vysokou rýchlosťou sa rituál commitovania, pushovania a čakania na code review často odohráva dávno po tom, čo boli prijaté najkritickejšie technické rozhodnutia. Zistili sme, že skutočná spolupráca prebieha v worktree, nie vo vlákne PR. Keď čakáme na PR, aby sme diskutovali o kóde, v podstate vykonávame pitvu rozhodnutia, ktoré bolo finalizované pred hodinami alebo dňami.
V čase, keď sa ľudský recenzent alebo agent pozrie na snímku, kontext pôvodného myšlienkového procesu sa už posunul. Git vynucuje synchrónne oneskorenie v asynchrónnom procese, čo sťažuje riadenie úzkeho miesta produktivity AI, ktoré vzniká, keď nástroje fungujú rýchlejšie ako naše cykly review. Rituál PR bol náhradou za dôveru vo svete pred agentmi, ale dnes jednoducho pôsobí ako nárazník, ktorý skrýva „prečo“ za „čo“. V podstate vymieňame spoluprácu v reálnom čase za čistú históriu, ktorú nikto nečíta.
Prečo AI agenti narúšajú model snímok
Nástup AI agentov ešte viac zvýraznil potrebu tesného prepojenia kódu a konverzácie. Agent nepotrebuje vidieť len aktuálny stav súboru; potrebuje pochopiť zámer zmien. V štandardnom Git workflow je tento zámer pochovaný v správe commitu alebo v samostatnom okne chatu. Toto oddelenie vedie k nedostatku spoločného porozumenia medzi ľudským operátorom a autonómnym agentom. Keď agent stratí niť konverzácie, začína sa odchyľovať od architektonických štandardov projektu.
Ak agent upravuje váš worktree, nemali by ste musieť čakať, kým dokončí „kus“ práce, aby ste videli alebo opravili jeho smer. Konverzácia je skutočným zdrojom softvéru. Tento nepretržitý prúd myšlienok musí byť krížovo referencovaný s kódom, ktorý sa mení v reálnom čase, čím sa zabezpečí, že ani správa, ani úprava sa neodchýlia od seba. Bez toho zostávame s medzerou predvídateľnosti, kde nemôžeme plne dôverovať, že výstup agenta je v súlade s verbálnymi inštrukciami zadanými pred tromi promptami.
Predstavujeme DeltaDB: Prúd jemných delta zmien
DeltaDB je nový systém správy verzií postavený na jemných delta zmenách namiesto diskrétnych commitov. Namiesto vytvárania snímky každých pár hodín DeltaDB zachytáva každú jednu operáciu v pracovnom strome a každej priraďuje stabilnú, adresovateľnú identitu. Nejde len o „automatické ukladanie“ pre Git; ide o zásadné prekonanie toho, ako sa sleduje stav. Prechodom zo snímok na prúdy dosahujeme rozlíšenie verzovania, ktoré zodpovedá rýchlosti myslenia.
Keďže každá delta je individuálne adresovateľná, môžete ukázať na kód v akomkoľvek konkrétnom okamihu jeho vývoja. Toto je zásadný odklon od architektúry Gitu. Umožňuje nám to verzovať pracovný strom tak, ako sa vyvíja, spolu s konverzáciou, ktorá ho poháňa. Môžete preskočiť z riadku v minulej konverzácii na presný stav kódu, keď bol tento riadok napísaný, alebo naopak. Táto úroveň technickej analýzy obsahu zaisťuje, že história projektu je živým záznamom, nie cintorínom squash-zlúčených commitov. V DeltaDB sa „undo“ zásobník a história verzií stávajú tým istým.
Súčasné úpravy pomocou replikovaných pracovných stromov bez konfliktov
Ako môže viacero agentov a ľudí pracovať na tom istom súbore bez obávaného konfliktu pri zlučovaní? Systém používa replikované pracovné stromy bez konfliktov (CRDT), aby umožnil ľuďom a agentom upravovať rovnaké súbory súčasne. Ide o rovnakú technológiu, ktorá poháňa kolaboratívne editory ako Google Docs, ale aplikovanú na celý súborový systém projektu. Agenti môžu pracovať cez terminál alebo cez pripojené pracovné stromy, čo vám umožňuje používať vlastné lokálne nástroje, zatiaľ čo agent pracuje na pozadí.
Táto architektúra eliminuje potrebu „uzamykania“ súborov alebo riešenia zložitých konfliktov pri zlučovaní po dlhotrvajúcej úlohe agenta. Viacerí účastníci – ľudskí alebo syntetickí – sa môžu zhodnúť na rovnakom stave súboru bez obradovania zlučovania. Transformuje pracovný strom z privátneho pieskoviska na zdieľaný, živý artefakt. Keď odstránite potrebu „commitovať, aby ste spolupracovali“, kolega sa môže pripojiť k prebiehajúcej relácii, porozprávať sa s agentom, ktorý pracuje, a anotovať kód počas jeho písania.
Kedy ponechať Git: Úloha CI a distribúcie
Kedy by ste nemali používať delta-based stream? Je dôležité objasniť, že DeltaDB nie je úplná náhrada celého ekosystému. Git a CI zostávajú pre externú integráciu a kontroly. Git je výnimočne dobrý v tom, že je „protokolom záznamu“ pre zvyšok sveta a na spúšťanie finálnych overovacích pipeline pred vydaním. Nechcete, aby „chaotický“ prúd každého jedného stlačenia klávesy bol vašou verejnou históriou repozitára.
DeltaDB vnímame ako kolaboračnú vrstvu, kde prebieha skutočná práca, zatiaľ čo Git zostáva distribučnou vrstvou. DeltaDB používate na budovanie softvéru prostredníctvom konverzácie a jemnozrnnej iterácie, potom Git používate na zabalenie tejto práce pre vonkajší svet. Toto oddelenie vám umožňuje udržiavať čistú históriu Gitu a zároveň ťažiť z hrubého, neupraveného kontextu DeltaDB streamu počas vývojovej fázy. Predstavte si to ako rozdiel medzi živým nahrávaním v štúdiu a finálnym masterovaným trackom.
Od zdrojového kódu k zdrojovej konverzácii
V tejto novej ére je každá referencia ukotvená k delte namiesto čísla riadku. To znamená, že referencie prežijú aj keď sa kód pohybuje alebo mení okolo nich. Ak agent napíše funkciu a vy o nej diskutujete, táto diskusia zostane prepojená s touto konkrétnou logikou, bez ohľadu na to, kam je neskôr refaktorovaná. To rieši odveký problém „nefunkčných odkazov“ v dokumentácii alebo komentároch k PR, ktoré ukazujú na kód, ktorý už na tom riadku neexistuje.
Vytvára sa tak prehľadateľná a dotazovateľná história zámerov. Agenti môžu čerpať z tohto kontextu, aby pochopili, prečo bol použitý konkrétny vzor, alebo aby „zvolali“ predchádzajúcich agentov, ktorí pracovali na bloku kódu, a požiadali o objasnenie. Efektívne riešime krízu znalostného dlhu tým, že zabezpečujeme, aby „prečo“ nebolo nikdy oddelené od „čo.“ Keď je kód záväzkom, ako často hovoríme, jediný spôsob, ako tento záväzok riadiť, je mať dokonalý záznam konverzácie, ktorá ospravedlňovala jeho existenciu.
Technické kompromisy: Snímky verzus delta toky
Hoci sú výhody delta tokov pre spoluprácu zrejmé, existujú technické kompromisy, ktoré treba zvážiť. Systémy založené na snímkach, ako je Git, sú vysoko efektívne z hľadiska úložiska, pretože dokážu naraz použiť delta kompresiu na veľké bloky údajov. Systém založený na tokoch, ako je DeltaDB, musí spracovať oveľa väčší objem jednotlivých operácií, čo si vyžaduje robustné databázové backendové riešenie na udržanie výkonu. Avšak pre aktívny pracovný adresár spoločnosti s 10 až 200 ľuďmi je táto réžia zanedbateľná v porovnaní s prínosmi v produktivite, ktoré prináša spolupráca agentov v reálnom čase.
Navyše, prechod na CRDT znamená, že „pravda“ o súbore je nakoniec konzistentná. Zatiaľ čo to funguje perfektne pre úpravu textu, vyžaduje to starostlivé zaobchádzanie, keď agenti spúšťajú kompilátory alebo testovacie sady voči pracovnému adresáru. Preto DeltaDB umožňuje pripojiť pracovný adresár na disk, čím sa zabezpečí, že váš existujúci nástrojový reťazec – kompilátory, lintery a debuggery – uvidí stabilný súborový systém, aj keď sa základné delty synchronizujú cez sieť.
Zhrnutie a ďalšie kroky
Základy sme začali budovať v Zed v roku 2021 a konečne sme pripravení zistiť, ako to zvláda reálne pracovné zaťaženie. V najbližších týždňoch začneme dávať DeltaDB do rúk prvým používateľom. Ak ste unavení z PR ceremónie a ste pripravení na systém správy verzií, ktorý skutočne rozumie tomu, ako agenti pracujú, je čas posunúť sa za commit. Softvér sa teraz formuje v konverzácii, nie v snímke.
Ďalší krok
Použite článok ako technický názor; nie je potrebné žiadne predajné CTA. Porozprávajte sa s DataTip.