Tutorial DeltaDB di Zed: Version Control Baru yang Mencatat Setiap Edit Antar Commit

Git telah mendominasi version control selama lebih dari satu dekade, tapi paradigma kerja software berubah drastis sejak masuknya AI agent. Percakapan dengan agent kini menjadi sumber kebenaran baru dari software yang kita bangun, sementara Git dirancang untuk snapshot diskrit yang tidak pernah memperhitungkan conversational context. Zed memperkenalkan DeltaDB, sebuah sistem version control baru yang merekam setiap operasi antar commit dan menjadikan percakapan agent sebagai artefak bersama. Artikel ini membahas konsep dasar, perbedaan dengan Git, dan cara kamu bisa mencobanya.

Masalah yang Diselesaikan DeltaDB

Tim Zed sendiri mengakui bahwa mereka tidak pernah benar-benar nyaman dengan pull request. Sebelum agent, kita bisa berpura-pura bahwa komentar pada snapshot adalah cara kolaborasi yang efektif. Tapi kenyataannya, diskusi paling penting terjadi saat kode sedang ditulis, bukan setelah di-commit dan di-push.

Dengan masuknya AI agent, masalah ini menjadi lebih krusial. Agent bekerja secara kontinu dan percakapan yang menghasilkan kode harus bisa di-cross-reference kapan saja. Git, yang terorganisir around discrete commits, tidak pernah didesain untuk mendukung pola kerja ini.

Langkah 1: Memahami Konsep Delta

Di Git, kamu membuat commit sebagai snapshot. Antara commit A dan commit B, ada banyak perubahan yang terjadi di working tree, tapi tidak ada catatan resmi tentangnya. DeltaDB memecah pekerjaan menjadi stream of fine-grained deltas. Setiap operasi dicatat dan diberi identitas stabil.

Karena setiap delta bisa dialamatkan secara individual, kamu bisa menunjuk ke kode pada titik mana pun dalam evolusinya, bahkan saat dia terus berubah. Ini memungkinkan version control pada worktree yang aktif berkembang, bersama dengan percakapan yang menggerakkannya.

Langkah 2: Menghubungkan Kode ke Percakapan

Salah satu fitur andalan DeltaDB adalah traceability. Setiap pesan dan edit yang dihasilkannya direkam berdampingan, sehingga tidak ada yang terlepas. Referensi diancangkan pada delta, bukan nomor baris, sehingga referensi tersebut survive meskipun kode bergeser di bawahnya.

Dari baris mana pun dalam percakapan masa lalu, kamu bisa melompat ke kode tersebut dalam kondisi sekarang atau saat agent menulisnya pertama kali. Sebaliknya, dari baris kode mana pun, kamu bisa menemukan percakapan yang menghasilkannya dan setiap percakapan yang menyentuhnya sejak itu.

Agent pun bisa memanfaatkan data ini. Mereka bisa mengambil konteks di balik kode yang sedang disentuh, atau mengonvensi agent sebelumnya yang mengerjakannya dan bertanya mengapa kode ditulis demikian.

Langkah 3: Branching di Titik Mana Pun

DeltaDB memvirtualisasikan worktree, sehingga membuat agent branch baru praktis tanpa biaya. Titik mana pun dalam sejarah bisa menjadi titik percabangan yang valid, termasuk di tengah proses (mid-run). Ini sangat berbeda dengan Git, di mana branching biasanya dilakukan pada commit yang bersih.

Bayangkan kamu sedang mengerjakan fitur dengan bantuan agent, lalu tiba-tiba muncul ide sampingan. Di DeltaDB, kamu bisa membuat branch dari delta terakhir tanpa harus commit dulu. Agent lama terus berjalan di branch asli, sementara agent baru mulai bekerja di branch baru. Kedua branch merujuk pada delta yang sama di titik percabangan, tapi berevolusi secara independen setelahnya.

Langkah 4: Berbagi Thread, Bukan Pull Request

Konsep kolaborasi di DeltaDB berpusat pada thread, bukan pull request. Seorang rekan tim bisa bergabung saat pekerjaan sedang berlangsung, berbicara dengan agent yang mengerjakannya, dan memberi anotasi sepanjang jalan. Tidak perlu menunggu commit dan push terlebih dahulu.

Pull request, thread review, dan inline comment ada untuk reattach diskusi ke kode setelah fakta, karena diskusi dan kode tinggal di tempat terpisah. DeltaDB memasukkan keduanya ke tempat yang sama, sehingga seremoni tersebut menghilang. Git dan CI tetap ada untuk tugas mereka yang sesungguhnya: menjalankan check dan menghubungkanmu ke dunia luar, bukan memaksakan kolaborasi terjadi di sana.

Langkah 5: Cara Bergabung ke Beta DeltaDB

DeltaDB masih dalam tahap beta dan akan tersedia dalam beberapa minggu mendatang. Zed membuka waitlist untuk early user yang ingin mencoba teknologi ini pertama kali. Kamu bisa mendaftar melalui Zed DeltaDB.

Sementara menunggu akses beta, ada beberapa persiapan yang bisa kamu lakukan:

1. Pelajari Zed editor terlebih dahulu melalui Zed Download. DeltaDB akan terintegrasi penuh dengan editor ini.

2. Pikirkan workflow timmu saat ini: di mana letak friction antara percakapan dan kode? DeltaDB paling bermanfaat untuk tim yang sering berkolaborasi real-time dengan agent.

3. Evaluasi apakah project-mu memerlukan audit trail yang sangat detail. DeltaDB memberikan visibility ke setiap operasi, yang bisa jadi overkill untuk project pribadi sederhana tapi sangat berharga untuk codebase enterprise.

Langkah 6: Integrasi Agent dan Human Developer

DeltaDB dirancang untuk menjadi lapisan kolaborasi antara human developer dan AI agent, bukan sistem yang menggantikan salah satu pihak. Agent bekerja di worktree virtual melalui terminal, sementara kamu bisa mount worktree tersebut ke disk kapan saja untuk menggunakan tool favoritmu seperti Vim, VS Code, atau CLI utilities.

Karena setiap referensi diancangkan pada delta, agent bisa melihat konteks penuh di balik kode yang sedang mereka sentuh. Mereka bisa menanyakan agent sebelumnya yang mengerjakan bagian tersebut: mengapa fungsi ini ditulis secara rekursif, apa pertimbangan performa yang dipilih, atau apakah ada edge case yang sengaja diabaikan. Ini mengubah agent dari sekadar code generator menjadi collaborator yang memahami sejarah project.

Untuk human developer, DeltaDB menghilangkan kebutuhan untuk menunggu agent selesai sebelum memberikan masukan. Kamu bisa bergabung ke thread aktif, membaca percakapan agent dengan agent lain, dan memberikan steer langsung tanpa harus membuat branch baru atau pull request. Workflow ini lebih mirip pair programming real-time, di mana kamu dan agent duduk di depan worktree yang sama.

Langkah 7: Migrasi dari Git ke DeltaDB

DeltaDB tidak mengharuskan kamu meninggalkan Git sepenuhnya. Zed memposisikan DeltaDB sebagai lapisan tambahan untuk fase pengembangan aktif, sementara Git tetap menangani distribusi dan CI/CD. Pola migrasi yang direkomendasikan adalah:

1. Gunakan DeltaDB selama fase pengembangan aktif dan kolaborasi dengan agent. Percakapan, branching, dan edit semua terjadi di dalam DeltaDB.

2. Ketika pekerjaan mencapai titik stabil, export snapshot ke Git commit. DeltaDB akan menghasilkan diff yang bersih yang merepresentasikan perubahan akhir.

3. Jalankan CI/CD pipeline seperti biasa melalui Git. DeltaDB tidak menggantikan CI, melainkan memindahkan fase kolaborasi ke tempat yang lebih alami.

Pola hybrid ini memungkinkan tim untuk mengadopsi DeltaDB secara bertahap tanpa mengubah infrastruktur deployment yang sudah ada. Bagi startup Indonesia yang menggunakan GitHub Actions atau GitLab CI, ini berarti tidak ada perubahan radikal pada pipeline DevOps.

Perbandingan DeltaDB vs Git

Kesimpulan

DeltaDB bukan pengganti Git secara menyeluruh, melainkan lapisan abstraksi baru untuk fase pengembangan yang paling kreatif dan kolaboratif: antar commit. Git tetap berperan untuk CI/CD dan distribusi ke publik, sementara DeltaDB mengurus evolusi kode dan percakapan yang menggerakkannya.

Bagi developer Indonesia yang sudah menggunakan Zed, DeltaDB akan menjadi alasan kuat untuk tetap berada di ekosistem tersebut. Bagi yang belum, ini mungkin saat yang tepat untuk mencoba editor yang dirancang dari nol untuk era agentic coding. Pantau perkembangannya di Zed Blog.