Stručně: Článek tvrdí, že model commitů a pull requestů v Gitu je pro vývoj s podporou AI příliš pomalý a chudý na kontext, protože agenti generují souvislý proud rozhodnutí a úprav, nikoli oddělené snapshoty. Navrhuje DeltaDB – jemně granulární delta stream, který propojuje konverzace s vyvíjejícím se kódem, pomocí CRDT umožňuje souběžné úpravy lidmi i agenty a Git ponechává pro distribuci, CI a čistou veřejnou historii.
- Tradiční pull requesty oddělují kód od uvažování v reálném čase, které ho vytvořilo, čímž zpožďují zpětnou vazbu a zakrývají záměr.
- DeltaDB zaznamenává každou operaci ve worktree se stabilní identitou, takže uživatelé mohou prohlížet kód i konverzaci v libovolném bodě jejich vývoje.
- Replikované worktrees založené na CRDT mají lidem i agentům umožnit souběžné úpravy bez zámků a běžných merge konfliktů.
- Git zůstává užitečný jako vnější protokol záznamu a pro finální ověření, zatímco DeltaDB slouží jako vrstva pro spolupráci.
- Delta streamy zlepšují kontext, ale přinášejí kompromisy v úložišti, výkonu a eventuální konzistenci, které vyžadují robustní infrastrukturu a stabilní připojené worktrees.
Tradiční commity zhušťují práci do snapshotů. AI agenti produkují proud rozhodnutí, úprav, oprav a kontextu, který vyžaduje jiný model spolupráce.
Tradiční správa verzí je navržena kolem „snapshotu“ – jednoho okamžiku, kdy se vývojář rozhodne, že jeho práce je hodna sdílení. V DataTip jsme s ceremonií pull requestů žili desítky let, ale jak do každodenních pracovních postupů začleňujeme AI agenty, stává se tato hranice strukturální zátěží. Tření při výměně komentářů nad statickými snapshoty už není jen nepříjemnost; je to překážka souvislé konverzace, která dnes definuje moderní vývoj softwaru. V éře autonomních agentů je čekání na commit fatálním úzkým hrdlem. Potřebujeme systém, který zachytí práci v okamžiku, kdy vzniká, ne jen hotový výsledek. Za hranicí commitu musíme rozpoznat zásadní posun: konverzace, která generuje kód, se stává skutečným zdrojem našeho softwaru. Tento dialog probíhá nepřetržitě a musí být provázán s kódem, jak se mění. Git, organizovaný kolem jednotlivých commitů, nikdy nebyl navržen pro takovou míru granularity. Směřujeme k realitě, kde zdrojový kód je fakticky zdrojovou konverzací, a naše nástroje tento posun musí odrážet. Tento článek zkoumá, proč model snapshotů selhává a proč je k překlenutí propasti mezi lidským záměrem a strojovým provedením potřeba nová abstrakce – postavená na jemně granulárních deltách.
Selhání ceremonie pull requestů
Tradiční pull requesty a správa verzí založená na snapshotech (Git) vytvářejí tření tím, že oddělují konverzaci od kódu. V prostředích s vysokou důvěrou a vysokým tempem se rituál commitu, pushnutí a čekání na code review často odehrává dlouho poté, co padla nejdůležitější technická rozhodnutí. Zjistili jsme, že skutečná spolupráce probíhá ve worktree, ne ve vlákně PR. Když s diskusí o kódu čekáme na PR, provádíme v podstatě pitvu rozhodnutí, které bylo definitivně učiněno před hodinami nebo dny. Než se na snapshot podívá lidský reviewer nebo agent, kontext původního myšlenkového procesu už se posunul. Git vnucuje synchronní zpoždění asynchronnímu procesu, a proto je obtížné zvládat úzké hrdlo produktivity AI, které vzniká, když se nástroje pohybují rychleji než naše review cykly. Ceremonie PR byla zástupným ukazatelem důvěry ve světě před agenty, dnes ale funguje jen jako buffer, který za „co“ skrývá „proč“. V podstatě vyměňujeme sladění v reálném čase za čistou historii, kterou ve skutečnosti nikdo nečte.
Proč AI agenti rozbíjejí model snapshotů
Nástup AI agentů zesílil potřebu těsného propojení kódu a konverzace. Agent nepotřebuje jen vidět aktuální stav souboru; potřebuje rozumět záměru za změnami. Ve standardním workflow s Gitem je tento záměr pohřben v commit message nebo v samostatném okně chatu. Toto oddělení vede k chybějícímu společnému porozumění mezi lidským operátorem a autonomním agentem. Když agent ztratí nit konverzace, začne se odchylovat od architektonických standardů projektu. Pokud agent upravuje váš worktree, neměli byste muset čekat, až dokončí „kus“ práce, abyste mohli vidět nebo opravit jeho směr. Konverzace je skutečným zdrojem softwaru. Tento souvislý proud myšlenek musí být provázán s kódem, jak se mění v reálném čase, aby se zpráva a úprava od sebe nevzdalovaly. Bez toho nám zůstává mezera v předvídatelnosti, kdy nemůžeme plně věřit, že výstup agenta odpovídá slovním instrukcím zadaným o tři prompty dříve.
Představujeme DeltaDB: proud jemně granulárních delt
DeltaDB je nový systém pro správu verzí postavený na jemně granulárních deltách místo jednotlivých commitů. Místo pořizování snapshotu každých pár hodin DeltaDB zachytí každou jednotlivou operaci ve worktree a každé přidělí stabilní, adresovatelnou identitu. Nejde jen o „autosave“ pro Git; jde o zásadní přepracování způsobu, jakým se sleduje stav. Přechodem od snapshotů ke streamům dosahujeme rozlišení verzování, které odpovídá rychlosti myšlení. Protože každá delta je samostatně adresovatelná, můžete ukázat na kód v libovolném konkrétním okamžiku jeho vývoje. To je zásadní odklon od architektury Gitu. Umožňuje nám verzovat worktree tak, jak se vyvíjí, spolu s konverzací, která ho pohání. Můžete přeskočit z řádku v minulém chatu na přesný stav kódu v okamžiku, kdy byl ten řádek napsán, nebo naopak. Tato úroveň technické analýzy obsahu zajišťuje, že historie projektu je živým záznamem, ne hřbitovem squash-mergnutých commitů. V DeltaDB se zásobník „zpět“ a historie verzí stávají jedním a tímtéž.
Souběžné úpravy díky bezkonfliktně replikovaným worktrees
Jak mohou více agentů a lidí pracovat na stejném souboru bez obávaného merge konfliktu? Systém používá bezkonfliktně replikované worktrees (CRDT), které lidem i agentům umožňují upravovat stejné soubory současně. Jde o stejnou technologii, na které stojí kolaborativní editory jako Google Docs, ale aplikovanou na celý souborový systém projektu. Agenti mohou pracovat přes terminál nebo přes připojené worktrees, takže můžete používat vlastní lokální nástroje, zatímco agent pracuje na pozadí. Tato architektura odstraňuje potřebu „zamykat“ soubory nebo řešit složité merge konflikty po dlouho běžící úloze agenta. Více účastníků – lidských i syntetických – může dospět ke stejnému stavu souboru bez ceremonie merge. Worktree se tak mění ze soukromého sandboxu ve sdílený, živý artefakt. Když odpadne nutnost „commitovat, abyste mohli spolupracovat“, může se kolega připojit k probíhající session, promluvit si s agentem, který práci dělá, a anotovat kód, zatímco vzniká.
Kdy si ponechat Git: role CI a distribuce
Kdy byste delta stream používat neměli? Je důležité upřesnit, že DeltaDB není plošnou náhradou celého ekosystému. Git a CI zůstávají pro externí integraci a kontroly. Git je výjimečně dobrý jako „protokol záznamu“ pro okolní svět a pro spouštění finálních ověřovacích pipeline před vydáním. Nechcete, aby „neuspořádaný“ proud každého jednotlivého stisku klávesy tvořil veřejnou historii vašeho repozitáře. DeltaDB vnímáme jako vrstvu pro spolupráci, kde probíhá skutečná práce, zatímco Git zůstává distribuční vrstvou. DeltaDB používáte k tvorbě softwaru prostřednictvím konverzace a jemně granulárních iterací a Git pak k zabalení této práce pro okolní svět. Toto oddělení vám umožní udržet čistou historii v Gitu a zároveň během vývoje těžit ze syrového, neupraveného kontextu streamu DeltaDB. Představte si to jako rozdíl mezi živým nahráváním ve studiu a finální masterovanou skladbou.
Od zdrojového kódu ke zdrojové konverzaci
V této nové éře je každý odkaz ukotven k deltě místo k číslu řádku. To znamená, že odkazy přežijí, i když se kód kolem nich přesouvá nebo mění. Pokud agent napíše funkci a vy ji proberete, tato diskuse zůstane propojená s konkrétní logikou bez ohledu na to, kam bude později refaktorována. Tím se řeší odvěký problém „rozbitých odkazů“ v dokumentaci nebo komentářích PR, které ukazují na kód, jenž už na daném řádku neexistuje. Vzniká tak prohledávatelná historie záměru, na kterou se lze dotazovat. Agenti mohou z tohoto kontextu čerpat, aby pochopili, proč byl použit konkrétní vzor, nebo aby „svolali“ předchozí agenty, kteří na daném bloku kódu pracovali, a požádali je o vysvětlení. Fakticky tak řešíme krizi znalostního dluhu tím, že „proč“ nikdy neoddělíme od „co“. Když je kód závazkem, jak často říkáme, jediný způsob, jak tento závazek řídit, je mít dokonalý záznam konverzace, která jeho existenci zdůvodnila.
Technické kompromisy: snapshoty vs. delta streamy
Přínosy delta streamů pro spolupráci jsou zřejmé, je však třeba zvážit technické kompromisy. Systémy založené na snapshotech, jako je Git, jsou z hlediska úložiště velmi efektivní, protože mohou používat delta kompresi na velké bloky dat najednou. Systém založený na streamu, jako je DeltaDB, musí zvládat mnohem vyšší objem jednotlivých operací, což pro udržení výkonu vyžaduje robustní databázový backend. Pro aktivní worktree firmy s 10–200 lidmi je však tato režie zanedbatelná ve srovnání s nárůstem produktivity díky spolupráci s agenty v reálném čase. Přechod na CRDT navíc znamená, že „pravda“ o souboru je eventuálně konzistentní. Pro úpravy textu to funguje perfektně, ale vyžaduje to pečlivé zacházení, když agenti nad worktree spouštějí kompilátory nebo testovací sady. Proto DeltaDB umožňuje připojit worktree na disk, aby váš stávající toolchain – kompilátory, lintery a debuggery – viděl stabilní souborový systém, i když se podkladové delty synchronizují po síti.
Shrnutí a další kroky
Základy pro toto řešení jsme v Zed začali stavět v roce 2021 a konečně jsme připraveni zjistit, jak si poradí s reálnými úlohami. V nadcházejících týdnech začneme DeltaDB dávat do rukou prvním uživatelům. Pokud vás už unavuje ceremonie PR a jste připraveni na systém správy verzí, který skutečně rozumí tomu, jak agenti pracují, je čas posunout se za hranici commitu. Software dnes dostává tvar v konverzaci, ne ve snapshotu.
Další krok
Berte tento článek jako technický pohled; prodejní CTA zde není potřeba. Promluvte si s DataTip.