Röviden: A cikk amellett érvel, hogy a Git commit- és pull request-modellje túl lassú és túl szegényes kontextusú az AI-támogatott fejlesztéshez, mert az ágensek diszkrét snapshotok helyett folyamatos döntéseket és módosításokat hoznak létre. Javaslata a DeltaDB: egy finom szemcsézettségű delta-folyam, amely a beszélgetéseket a változó kódhoz köti, CRDT-k segítségével támogatja az emberek és ágensek egyidejű szerkesztését, a Gitet pedig megtartja a terjesztésre, a CI-ra és a tiszta nyilvános előzményekre.
- A hagyományos pull requestek elválasztják a kódot az azt létrehozó valós idejű gondolkodástól, ami késlelteti a visszajelzést és elhomályosítja a szándékot.
- A DeltaDB stabil azonosítóval rögzít minden worktree-műveletet, így a felhasználók a fejlődés bármely pontján megvizsgálhatják a kódot és a beszélgetést.
- A CRDT-alapú replikált worktree-k célja, hogy az emberek és az ágensek zárolások és hagyományos merge-konfliktusok nélkül, egyszerre szerkeszthessenek.
- A Git továbbra is hasznos külső hiteles protokollként és a végső ellenőrzéshez, míg a DeltaDB az együttműködési réteg szerepét tölti be.
- A delta-folyamok javítják a kontextust, de tárolási, teljesítménybeli és eventual consistency-kompromisszumokkal járnak, amelyek robusztus infrastruktúrát és stabil, csatolt worktree-ket igényelnek.
A hagyományos commitok snapshotokba sűrítik a munkát. Az AI-ágensek viszont döntések, módosítások, javítások és kontextus folyamát hozzák létre, amelyhez más együttműködési modell kell.
A hagyományos verziókezelés a „snapshot” köré épül – egy diszkrét pillanatra, amikor a fejlesztő úgy dönt, hogy a munkája megérett a megosztásra. A DataTipnél évtizedek óta együtt élünk a pull request ceremóniájával, de ahogy az AI-ágenseket beépítjük a napi munkafolyamatainkba, ez a határ szerkezeti teherré válik. A statikus snapshotokon folytatott kommentváltás súrlódása már nem csupán bosszúság: akadálya annak a folyamatos párbeszédnek, amely ma a modern szoftverfejlesztést meghatározza. Az autonóm ágensek korában a commitra várni végzetes szűk keresztmetszet. Olyan rendszerre van szükségünk, amely a munkát menet közben rögzíti, nem csak a kész terméket.
A commiton túl egy alapvető váltást kell felismernünk: a kódot létrehozó beszélgetés válik a szoftver valódi forrásává. Ez a párbeszéd folyamatosan zajlik, és a változó kóddal kereszthivatkozásban kell állnia. A diszkrét commitok köré szervezett Gitet soha nem erre a szemcsézettségre tervezték. Egy olyan valóság felé haladunk, ahol a forráskód valójában forrásbeszélgetés, és az eszközeinknek tükrözniük kell ezt a váltást. Ez a cikk azt vizsgálja, miért bukik el a snapshotmodell, és miért van szükség egy új, finom szemcsézettségű deltákra épülő absztrakcióra, amely áthidalja a szakadékot az emberi szándék és a gépi végrehajtás között.
A pull request ceremónia kudarca
A hagyományos pull requestek és a snapshotalapú verziókezelés (Git) súrlódást okoznak, mert elválasztják a beszélgetést a kódtól. A nagy bizalmú, nagy sebességű környezetekben a commitolás, a push és a code review-ra való várakozás rituáléja gyakran jóval azután történik, hogy a legkritikusabb technikai döntések már megszülettek. Azt tapasztaltuk, hogy a valódi együttműködés a worktree-ben zajlik, nem a PR-szálban. Ha a kód megbeszélésével a PR-ig várunk, lényegében boncolást végzünk egy olyan döntésen, amely már órákkal vagy napokkal korábban véglegessé vált.
Mire egy emberi reviewer vagy egy ágens ránéz egy snapshotra, az eredeti gondolatmenet kontextusa már elsodródott. A Git szinkron késleltetést kényszerít egy aszinkron folyamatra, ami megnehezíti, hogy kezeljük az AI termelékenységi szűk keresztmetszetét, amely akkor jelentkezik, amikor az eszközök gyorsabbak a review-ciklusainknál. A PR ceremóniája az ágensek előtti világban a bizalom helyettesítője volt, ma viszont csupán pufferként működik, amely a „mi” mögött elrejti a „miért”-et. Lényegében a valós idejű összehangolást cseréljük el egy tiszta előzményre, amelyet valójában senki sem olvas.
Miért töri meg az AI-ágensek megjelenése a snapshotmodellt
Az AI-ágensek térnyerése felerősítette a kód és a beszélgetés szoros összekapcsolásának igényét. Egy ágensnek nem elég egy fájl aktuális állapotát látnia; értenie kell a változtatások mögötti szándékot is. Egy szabványos Git-munkafolyamatban ez a szándék egy commitüzenetben vagy egy külön chatablakban vész el. Ez az elkülönülés közös értelmezés hiányához vezet az emberi operátor és az autonóm ágens között. Amikor egy ágens elveszíti a beszélgetés fonalát, elkezd eltávolodni a projekt architekturális standardjaitól.
Ha egy ágens az Ön worktree-jét szerkeszti, ne kelljen megvárnia, amíg befejez egy munkadarabot, mielőtt látná vagy korrigálná az irányát. A beszélgetés a szoftver valódi forrása. Ezt a folyamatos gondolatfolyamot valós időben kell a változó kódhoz kötni, hogy se az üzenet, se a módosítás ne sodródjon el a másiktól. Enélkül egy kiszámíthatósági szakadék marad, amelyben nem bízhatunk teljesen abban, hogy az ágens kimenete megfelel a három prompttal korábban adott szóbeli utasításoknak.
Bemutatjuk a DeltaDB-t: finom szemcsézettségű delták folyama
A DeltaDB egy új verziókezelő rendszer, amely diszkrét commitok helyett finom szemcsézettségű deltákra épül. Ahelyett, hogy néhány óránként snapshotot készítene, a DeltaDB a worktree minden egyes műveletét rögzíti, és mindegyiknek stabil, címezhető azonosítót ad. Ez nem egyszerű „automatikus mentés” a Githez; az állapotkövetés alapvető újratervezése. A snapshotokról a folyamokra való átállással olyan verziókezelési felbontást érünk el, amely a gondolkodás sebességével lép lépést.
Mivel minden delta egyenként címezhető, a kód fejlődésének bármely konkrét pillanatára rámutathat. Ez alapvető eltérés a Git architektúrájától. Lehetővé teszi, hogy a worktree-t fejlődése közben verziózzuk, az azt irányító beszélgetéssel együtt. Egy korábbi chat egy sorából közvetlenül a kód pontos állapotára ugorhat, amikor az a sor elhangzott – és fordítva. A technikai tartalomelemzés ilyen szintje biztosítja, hogy a projekt előzményei élő nyilvántartást alkossanak, ne pedig squash-merge-ölt commitok temetőjét. A DeltaDB-ben a „visszavonás” verem és a verzióelőzmény ugyanaz lesz.
Egyidejű szerkesztés konfliktusmentesen replikált worktree-kkel
Hogyan dolgozhat több ágens és ember ugyanazon a fájlon a rettegett merge-konfliktus nélkül? A rendszer konfliktusmentesen replikált worktree-ket (CRDT-ket) használ, hogy az emberek és az ágensek egyszerre szerkeszthessék ugyanazokat a fájlokat. Ez ugyanaz a technológia, amely az olyan közös szerkesztőket működteti, mint a Google Docs, csak a projekt teljes fájlrendszerére alkalmazva. Az ágensek terminálon vagy csatolt worktree-ken keresztül dolgozhatnak, így Ön a saját helyi eszközeit használhatja, miközben az ágens a háttérben működik.
Ez az architektúra megszünteti a fájlok „zárolásának” szükségességét, és azt, hogy egy hosszan futó ágensfeladat után bonyolult merge-konfliktusokat kelljen kezelni. Több résztvevő – ember vagy szintetikus – merge ceremónia nélkül juthat el ugyanarra a fájlállapotra. A worktree privát homokozóból közös, élő artefaktummá válik. Ha megszűnik az igény, hogy „az együttműködéshez commitolni kelljen”, egy csapattárs csatlakozhat egy folyamatban lévő munkamenethez, beszélhet a munkát végző ágenssel, és annotálhatja a kódot, miközben az íródik.
Mikor maradjon a Git: a CI és a terjesztés szerepe
Mikor ne használjon delta-alapú folyamot? Fontos tisztázni, hogy a DeltaDB nem a teljes ökoszisztéma egy az egyben történő lecserélése. A Git és a CI megmarad a külső integrációhoz és az ellenőrzésekhez. A Git kivételesen jó abban, hogy a külvilág felé a „hiteles protokoll” legyen, és hogy a kiadás előtti végső ellenőrző pipeline-okat futtassa. Nem szeretné, ha minden egyes billentyűleütés „kusza” folyama lenne a nyilvános repository előzménye.
A DeltaDB-t együttműködési rétegnek tekintjük, ahol a tényleges munka zajlik, míg a Git marad a terjesztési réteg. A DeltaDB-vel beszélgetésen és finom szemcsézettségű iteráción keresztül építi a szoftvert, majd a Gittel csomagolja a munkát a külvilág számára. Ez az elkülönítés lehetővé teszi, hogy tiszta Git-előzményt tartson fenn, miközben a fejlesztési szakaszban kihasználja a DeltaDB-folyam nyers, szerkesztetlen kontextusát. Gondoljon rá úgy, mint egy élő stúdiófelvétel és a végleges, masterelt dal közötti különbségre.
A forráskódtól a forrásbeszélgetésig
Ebben az új korszakban minden hivatkozás egy deltához van horgonyozva, nem egy sorszámhoz. Ez azt jelenti, hogy a hivatkozások akkor is megmaradnak, ha a kód körülöttük elmozdul vagy megváltozik. Ha egy ágens megír egy függvényt, és Ön megbeszéli, az a megbeszélés ahhoz a konkrét logikához kötve marad, függetlenül attól, hogy később hová refaktorálják. Ez megoldja a dokumentációban vagy PR-kommentekben lévő „törött linkek” régi problémáját, amelyek olyan kódra mutatnak, amely már nem létezik azon a soron.
Így a szándék kereshető, lekérdezhető előzménye jön létre. Az ágensek erre a kontextusra támaszkodva megérthetik, miért használtak egy adott mintát, vagy „összehívhatják” azokat a korábbi ágenseket, amelyek egy kódblokkon dolgoztak, hogy pontosítást kérjenek tőlük. Ezzel lényegében megoldjuk a tudásadósság-válságot, mert biztosítjuk, hogy a „miért” soha ne váljon el a „mi”-től. Ha a kód teher – ahogy gyakran mondjuk –, akkor ezt a terhet csak úgy lehet kezelni, ha tökéletes nyilvántartásunk van a létezését indokoló beszélgetésről.
Technikai kompromisszumok: snapshotok kontra delta-folyamok
Bár a delta-folyamok előnyei az együttműködés szempontjából egyértelműek, technikai kompromisszumokkal is számolni kell. A snapshotalapú rendszerek, mint a Git, rendkívül hatékonyak a tárolásban, mert egyszerre nagy adatdarabokon alkalmazhatnak delta-tömörítést. Egy folyamalapú rendszernek, mint a DeltaDB, sokkal több egyedi műveletet kell kezelnie, ami a teljesítmény fenntartásához robusztus adatbázis-backendet igényel. Egy 10–200 fős vállalat aktív worktree-je esetében azonban ez a többletterhelés elhanyagolható a valós idejű ágensalapú együttműködés termelékenységi előnyeihez képest.
Emellett a CRDT-kre való átállás azt jelenti, hogy a fájl „igazsága” eventually consistent. Bár ez a szövegszerkesztésnél tökéletesen működik, gondos kezelést igényel, amikor az ágensek fordítókat vagy tesztcsomagokat futtatnak a worktree-n. Ezért teszi lehetővé a DeltaDB, hogy a worktree-t lemezre csatolja, így a meglévő eszközlánc – fordítók, linterek és debuggerek – stabil fájlrendszert lát, még akkor is, amikor a háttérben a delták szinkronizálása zajlik a hálózaton.
Összegzés és következő lépések
Ennek alapjait 2021-ben kezdtük építeni a Zednél, és végre készen állunk arra, hogy lássuk, hogyan birkózik meg a valós terheléssel. A következő hetekben elkezdjük a DeltaDB-t korai felhasználók kezébe adni. Ha elege van a PR ceremóniából, és olyan verziókezelő rendszerre vágyik, amely valóban érti, hogyan dolgoznak az ágensek, itt az ideje túllépni a commiton. A szoftver ma a beszélgetésben ölt formát, nem a snapshotban.
Következő lépés
Használja a cikket technikai nézőpontként; nincs szükség erős értékesítési CTA-ra. Beszéljen a DataTippel.