Perangkat lunak dibuat di antara commit

• DeltaDB adalah bentuk baru sistem kontrol versi yang mengelola versi percakapan dengan agen dan worktree yang diedit agen secara bersamaan
• Git disusun berpusat pada commit individual dan tidak dirancang untuk menangani percakapan yang berlanjut serta perubahan kode yang terus berlangsung secara bersamaan
• DeltaDB merekam bukan hanya commit, tetapi semua operasi yang terjadi selama pekerjaan sebagai aliran delta yang terperinci, dan memberi setiap delta pengenal yang stabil
• Pesan dan edit yang dihasilkan oleh pesan tersebut dicatat berdampingan, dan banyak orang serta agen dapat mengedit file yang sama secara bersamaan di mesin yang berbeda
• Kolaborasi dapat berlangsung lebih langsung di dalam percakapan dan worktree saat kode sedang dibuat, bukan melalui prosedur review setelah commit dan push

---

Latar belakang dan rumusan masalah

• Tim Zed tidak terbiasa dengan model pull request, dan telah membangun kepercayaan serta pemahaman bersama dengan bekerja bersama di worktree yang sama sambil mendiskusikan kode saat menulisnya
• GitHub baru memungkinkan orang membicarakan kode setelah melakukan commit dan push, tetapi percakapan penting bagi tim Zed biasanya sudah selesai sebelum titik itu
• Zed dimulai pada 2021 untuk melampaui keterbatasan commit, dengan tujuan lebih dulu membuat editor yang layak untuk pengembang terbaik di dunia lalu menghadirkan cara kolaborasi yang lebih baik di dalamnya
• Masalah yang telah lama dipikirkan dalam konteks kolaborasi antarmanusia menjadi makin penting saat berkolaborasi dengan agen
• Percakapan yang menghasilkan kode makin menjadi sumber nyata dari perangkat lunak, dan percakapan itu perlu saling merujuk dengan kode yang terus berkembang dan berubah
• Git disusun berpusat pada commit individual, sehingga tidak dirancang untuk mendukung keterkaitan antara percakapan berkelanjutan dan perubahan kode seperti ini

DeltaDB dan langkah berikutnya

• Bukan semua commit, melainkan semua operasi

  • DeltaDB membagi pekerjaan ke dalam aliran delta yang terperinci, dan berbeda dari Git yang menyimpan snapshot per commit, DeltaDB merekam semua operasi di antara commit
  • Setiap delta memiliki pengenal yang stabil, sehingga momen tertentu dalam proses evolusi dapat dirujuk meski kode terus berubah
  • Worktree dikontrol versinya sebagai proses perubahan itu sendiri, dan ditangani bersama percakapan yang mendorong perubahan tersebut
  • Pesan dan edit yang dihasilkan pesan itu dicatat berdampingan dan tidak terpisahkan satu sama lain
  • DeltaDB memiliki replicated worktree bebas konflik bawaan, sehingga banyak orang dan agen dapat mengedit file yang sama secara bersamaan di mesin yang berbeda
  • File tetap merupakan file sungguhan, agen bekerja pada file melalui terminal, dan pengguna dapat me-mount seluruh worktree ke disk kapan pun diperlukan untuk memakai alat mereka sendiri

• Source code kini menjadi source conversation

  • Karena referensi ditambatkan ke delta, bukan ke nomor baris, referensi tetap bertahan meski kode bergeser ke bawah
  • Dari baris mana pun dalam percakapan lama, kita bisa melompat ke kode pada keadaan saat ini atau ke kode yang ditulis agen pada saat itu
  • Dari baris kode mana pun, kita bisa menemukan percakapan yang membuat kode itu dan semua percakapan setelahnya yang menyentuh kode tersebut
  • Agen juga dapat memanfaatkan informasi ini untuk mengambil konteks latar belakang dari kode yang sedang disentuhnya
  • Agen dapat memanggil agen yang sebelumnya pernah mengerjakan kode itu untuk bertanya mengapa kode tersebut ditulis dengan cara seperti itu

• Seharusnya tidak perlu commit untuk berkolaborasi

  • Tujuannya adalah menjadikan percakapan dengan agen sebagai satu-satunya percakapan yang diperlukan untuk kolaborasi
  • Anggota tim dapat ikut serta saat pekerjaan masih berlangsung, berbicara dengan agen yang mengerjakan tugas itu, dan memberi komentar di tengah proses
  • Anggota tim tidak perlu menunggu commit dan push terlebih dahulu untuk bisa ikut serta
  • Pull request, thread review, dan komentar inline sebelumnya adalah prosedur untuk menempelkan kembali diskusi ke kode karena kode dan pembahasan berada di tempat yang berbeda
  • Jika kode dan pembahasan berada di tempat yang sama, prosedur seperti itu akan hilang
  • Git dan CI tetap berperan menjalankan pemeriksaan dan menghubungkan ke dunia luar, tanpa menjadi tempat yang memaksa kolaborasi terjadi

• Langkah berikutnya

  • Perangkat lunak kini mulai terbentuk bukan dari commit, melainkan dari percakapan
  • DeltaDB adalah sistem kontrol versi untuk hal itu, dan akan tersedia bagi pengguna awal dalam beberapa minggu ke depan
  • Jika ingin mencobanya lebih dulu, Anda dapat mendaftar ke daftar tunggu

[GN⁺]

Opini Hacker News

• Hasil kerja di antara commit adalah sup yang berantakan, jadi walaupun dilihat, itu tidak berguna bagi siapa pun. Tulis ulang riwayat dengan git rebase agar setiap commit kecil dan atomik, lalu biarkan cerita yang dibentuk oleh commit menjelaskan mengapa hasilnya menjadi seperti sekarang
  Tidak penting bagaimana urutan waktu sebenarnya terjadi. Saya setuju bahwa review pull request datang terlalu terlambat, tetapi masalahnya adalah pull request dirancang untuk meninjau seluruh hasil branch sekaligus sehingga review commit individual menjadi sulit. Solusinya seharusnya bukan membagikan semua noise, melainkan mendorong commit kecil dan atomik agar pekerjaan awal bisa direview sebelum fitur atau perbaikannya selesai

  • Melihat komentar di sini dan jaringan profesional saya, orang umumnya terbagi menjadi dua kubu. Satu kubu memakai Git seperti autosave yang kasar lalu merapikannya saat merge, kubu lain lebih menyukai commit atomik yang rapi dan sepenuhnya berfungsi
    Dalam pengalaman saya, yang pertama lebih umum, mungkin karena GitHub secara alami lebih mendukung cara itu dan squash commit bisa menyelesaikan sebagian masalah pada pendekatan kedua. Kalau harus memilih, menurut saya pendekatan pertama jauh lebih masuk akal
  • Bukankah itu bukan masalah alat seperti Phabricator atau Gerrit, melainkan hanya masalah GitHub?
  • Entah itu sup yang berantakan atau tidak, selama disk atau biaya bukan masalah, tidak apa-apa jika seseorang—mungkin agen—bisa melihat apa yang saya lakukan
    Saya tidak terlalu yakin, tetapi saya rasa agen akan lebih menyukai informasi tambahan, meskipun bagi sebagian orang itu hanyalah noise
  • Saya sudah menduga reaksi seperti ini akan muncul. Saat membaca tulisan itu, saya teringat pernah kecewa karena melihat perasaan yang sama setiap kali pembicaraan beralih ke version control
    Terlalu banyak orang terlalu mudah membuang riwayat demi membuatnya terlihat “rapi”. Itu tidak masuk akal, tetapi anehnya terasa cocok dengan logika khas sebagian programmer
    Cara saya adalah commit sesering mungkin, puluhan kali sehari. Commit adalah catatan tentang apa yang terjadi, dan saya ingin sebanyak mungkin catatan itu tetap ada. Sudah berkali-kali git bisect menunjuk ke commit kecil satu baris yang tampaknya tidak bermasalah sama sekali, lalu membantu menemukan bug halus yang baru ketahuan jauh belakangan
    Menurut saya source control memang ada untuk menemukan hal seperti itu. Kalau saya harus menyisir setiap baris dari commit besar, masalah seperti ini akan jauh lebih menyakitkan
    Jadi saya benar-benar tidak paham ketika orang sengaja menggabungkan commit menjadi satu sesuai ukuran penuh PR, lalu membuang satu-satunya bagian yang menurut saya benar-benar berguna dari version control. Karena ada banyak juga yang berada di kubu seperti komentar induk, rencana penulis untuk riwayat yang lebih rinci tampaknya akan menjadi perjuangan yang tidak mudah
  • Cara Anda menulis commit terdengar mirip dengan cara saya memakai stacked PR di kantor
    Kebersihan commit yang baik sulit dipaksakan di tingkat tim, tetapi anehnya di tingkat PR orang cukup kooperatif dalam menulis penjelasan yang baik dan menjaga kelompok perubahan tetap rapi

• Ini terdengar seperti auto-commit yang sering dengan tingkat kepercayaan yang lebih rendah terhadap Git. Git sendiri sudah cukup mampu menangani auto-commit yang sering
  Jika Anda ingin mempertahankan “percakapan” dari auto-commit pada tiap titik waktu sambil tetap menggulungnya menjadi commit tingkat atas yang lebih “bersih”, Anda bisa sesekali memakai git merge --no-ff dan lalu memakai alat seperti --first-parent agar fokus pada commit tingkat atas, bukan commit “percakapan”
  Backend Git sendiri sudah memiliki banyak optimasi DB delta di Git pack dan alat lain, dan sebenarnya yang sedikit perlu dibenahi adalah frontend Git—terutama --first-parent—serta banyak UI Git yang “mengutamakan/khusus peta jalur kereta”. Banyak orang menganggap peta jalur itu jelek, membingungkan, dan tidak menyenangkan, jadi perlu lebih banyak UI drill-down yang sesuai dengan --first-parent

  • Saya juga melakukannya. Commit di branch biasanya tidak saya lihat, tetapi tetap ada kalau diperlukan. git blame juga bisa diatur agar memakai --first-parent

• Saya setuju dengan “software dibuat di antara commit”, tetapi tidak setuju dengan “DeltaDB menangkap semua pekerjaan di antara tiap commit”
  Pertama, itu terasa intrusif. Saya juga tidak ingin perekam layar yang berjalan 24 jam saat saya bekerja. Bukan berarti salah kalau kesalahan saya terlihat, tetapi jika saya bekerja dengan benar, nilai yang saya hasilkan tercermin dalam commit, dan cara itu terasa jauh kurang intrusif
  Kedua, saya memakai banyak alat, dan saya tidak ingin menyatukan semuanya ke dalam DB aneh semacam itu. Jika pada titik tertentu hasilnya hanya “sebuah proses eksternal melakukan sesuatu”, lalu apa gunanya menangkap semuanya? Bagus bahwa Zed bisa mengintegrasikan banyak hal, tetapi itu tidak berarti saya akan memakai semua yang terintegrasi di Zed. Terakhir kali saya cek, saat memakai Claude Code lewat ACP di Zed, saya bahkan tidak bisa memundurkan pesan lama untuk mengeditnya
  Terakhir, secara pribadi saya rasa kita sudah kehilangan esensi commit. Kebanyakan orang membuat kumpulan perubahan acak yang tidak terbatas lalu menjalankan git commit, kumpulan perubahan itu direview sebagai satu bongkahan besar, lalu commit-commitnya digabung. Ini memang bukan akhir dunia, tetapi commit yang benar-benar dipahat dengan tangan itu luar biasa bagus. Kalau Anda menjalankan git blame pada proyek yang memaksa cara seperti itu, Anda akan langsung paham maksud saya
  Hal seperti DeltaDB hanya akan makin memperkuat dan membakukan kebiasaan menggabungkan commit secara asal. Kalau Anda penasaran apa yang sebenarnya terjadi, sekarang Anda tinggal memutar ulang secara voyeuristik percakapan pengguna dengan LLM
  Poin terakhir itu menarik, tetapi juga menjengkelkan. Saya tidak berhasil meyakinkan rekan tim untuk mendokumentasikan perubahan dan motivasinya hanya karena itu praktik rekayasa yang baik dan membantu tim, tetapi semua orang justru dengan senang hati menjelaskannya kepada LLM. Sebagian besar karena LLM membutuhkannya agar bisa bekerja, tetapi menarik melihat seberapa banyak hal yang dulu tidak akan dilakukan orang kini dilakukan demi memuaskan LLM. Tiba-tiba hal-hal yang anehnya dulu tidak terdokumentasi sekarang didokumentasikan di CLAUDE.md

• Kode yang ditulis di antara commit adalah proses berpikirku. Aku berpikir dengan menulis kode, menghapusnya, lalu menulisnya lagi
  Kode yang dibawa keluar lewat commit ditulis agar bisa dipahami orang lain, dan merupakan hasil dari proses yang ditulis untuk membantu berpikir. Aku tidak ingin pikiranku diserialisasi, dikelola versinya, lalu bisa diakses publik
  https://www.nature.com/articles/s44222-025-00323-4

  • Ada masalah yang sama juga dengan JJ. Aku tidak ingin semua yang terjadi di antara commit masuk ke version control
    Aku juga tidak yakin semua status perantara di antara commit itu relevan atau berguna. Tapi rasanya aku termasuk minoritas
  • Itulah kenapa aku memakai rebase sebelum PR, dan tidak suka squash. Dua tahun kemudian kamu tidak akan ingat kenapa kode itu ditulis seperti itu, dan untuk memahami bug serta mengidentifikasi situasi Pagar Chesterton, yang kita punya hanya delta dan riwayat commit
    Kalau di-squash, yang tersisa sebagai konteks hanya 400 baris kode yang kamu tulis “sekaligus” dan feature request tempat kode itu ditugaskan. Sama sekali tidak membantu
    Orang terburuk yang pernah kutemui menulis modul baru dan tidak check-in apa pun sampai cukup berjalan. Sepertinya ini juga berkaitan dengan ego rapuh yang diam-diam memperbaiki bug di kodenya sendiri tanpa mengatakannya lebih dulu. Dia menulis kode rumit yang menunjukkan hukum Kernighan, padahal untuk melakukan hal seperti itu dia butuh pengalaman 10 tahun lagi. Dia membanggakan bahwa kodenya “powerful”, padahal itu bukan pujian, melainkan firasat buruk. Aku berkali-kali menemukan bug di kode commit awalnya. Rasanya cuma ingin memohon: tolong tinggalkan jejak apa pun
    Kamu tidak perlu mengaku kalau kamu asal mencoba apa saja sampai menemukan masalahnya. Setelah tahu bahwa titik B bisa dicapai, cukup susun cerita yang diinginkan dari A ke B. Susun ulang commit seperti cara kamu akan menulisnya jika dari awal sudah tahu persis apa yang harus dilakukan. Buang saja 90% kode yang kamu tulis lalu langsung hapus, atau apa pun yang tidak mendukung narasi itu
    Dalam penegakan hukum ada yang disebut parallel construction. Kamu bisa tahu seorang tersangka bersalah lewat fakta yang tidak dapat diterima di pengadilan, tetapi fakta yang sama harus ditemukan lagi melalui prosedur yang benar. Misalnya mengamankan sampah pada hari pengambilan, mewawancarai tetangga, mengumpulkan cukup bukti tidak langsung untuk mendapatkan surat perintah penggeledahan, lalu menemukan kembali bukti tersebut
  • Sepertinya ini terutama memikirkan agen AI. Ini ide menarik yang pernah kulihat sebelumnya, dan lucu melihat semua orang seperti ingin menciptakan ulang sesuatu demi AI
    Tapi aku skeptis karena rasanya bukankah cukup membuat file teks dan menambahkan referensi commit? Aku juga tidak paham kenapa tidak pakai Fossil. Karena itu database SQLite, kamu sudah bisa membundel hal-hal yang diinginkan, dan ada berbagai fitur bawaan untuk mereferensikan commit
  • Aku skeptis soal bagian kolaborasi, tapi terdengar seperti fitur untuk pelanggan enterprise, jadi aku paham maksudnya
  • Sangat setuju. Nuansa pengawasan-nya sangat tidak menyenangkan. Terutama bagian “DeltaDB memecah pekerjaan menjadi aliran delta yang sangat rinci. Sementara Git menangkap snapshot tiap commit, DeltaDB menangkap semua pekerjaan di antaranya dan memberi masing-masing pengenal yang stabil”
    Aku sempat berpikir ingin mencoba Zed karena katanya sekarang ada keymap emacs, tapi sekarang tidak jadi. Ini fitur yang terlalu invasif dan mengerikan, dan aku sama sekali tidak mau rekan kerja meninjau semua edit perantara hingga commit yang kubuka untuk review, sampai ke tingkat penekanan tombol
    Sebelum membuka PR, kadang aku merapikan sedikit riwayat commit di magit agar lebih linear dan mudah dicerna. Misalnya memperbaiki penjelasan atau menggabungkan commit yang berdekatan. Tapi fitur ini membuang satu sisi dari pekerjaan itu sepenuhnya, lalu berkata, “Wahai rekan kerja, telan saja selang pemadam berupa delta ini dan nikmatilah”
    Kalimat “Yang benar-benar kami inginkan itu sederhana. Percakapan dengan agen menjadi satu-satunya percakapan yang Anda perlukan” itu sebenarnya maksudnya apa. Tidak, salah

• Perasaan bahwa Anthropic atau OpenAI akan mengakuisisi Zed terasa tak terhindarkan, dan itu membuatku muak. Idenya terlalu bagus dan perangkat lunaknya juga terlalu bagus

  • Harness coding Zed jauh lebih baik daripada Claude Code, tetapi karena langsung memakai Claude API, biayanya juga jauh lebih mahal. Kalau masuk ke keluarga produk yang sama, ini bisa menjadi sesuatu yang mendefinisikan kategori produk
  • Kenapa berhenti di Zed? Dana investasi 1 triliun dolar yang dikumpulkan perusahaan AI memang secara nominal untuk data center, tetapi kalau biayanya naik dan jadwal penyelesaiannya melampaui cakupan rencana bisnis normal, akan lebih efisien memakai uang itu di tempat lain. Dengan 1 triliun dolar, kamu bisa membeli apa pun yang kamu mau
  • Ke mana pun Anthropic atau OpenAI menuju, sepertinya di sana tidak ada lagi editor. Secara pribadi aku ingin alat kode read-only yang lebih baik, atau kembalinya UML

• Ada sangat banyak startup tahap awal yang bersaing di bidang ini sekarang. Dalam beberapa minggu terakhir saat wawancara, aku sudah bicara setidaknya dengan dua perusahaan seperti ini
  Persaingan akan sangat ketat jika alat-alat seperti ini ingin benar-benar menemukan pijakan hingga sukses dalam skala besar. Tapi aku tetap tidak bisa menepis kesan bahwa semua ini tampaknya memungkinkan pengawasan pengembang pada tingkat yang membuatku sangat tidak nyaman

  • Jika seorang manajer menghabiskan semua waktunya untuk mengamati setiap penekanan tombol semua pengembang di bawahnya, berarti dia memang tidak punya pekerjaan nyata atau masalah bisnis penting lain yang perlu diperhatikan

• Commit berguna karena sudah lebih dulu dirapikan. Coba-coba dan salah di antaranya adalah tempat untuk mencoba sesuatu lalu menghapus jalan buntu, dan sebagian besar memang harus dibuang
  Menyimpan semua perubahan dan pesan agen hanya akan membuat sampah itu tetap ada

• Google mungkin sudah melakukan ini sejak sekitar 10 tahun lalu dengan citc. Aku tidak tahu kapan tepatnya Gemini akan benar-benar memanfaatkannya, tetapi Google pada dasarnya sudah memiliki hampir seluruh riwayat hampir semua pengembang pada tingkat Ctrl-S setidaknya selama 10 tahun
  Jika Gemini sekarang terlihat bodoh, itu hanya karena mereka menghemat alokasi sumber daya komputasi
  0 - https://en.wikipedia.org/wiki/Piper_(source_control_system)

• Di sini saya tidak paham apa proposisi nilainya. Saya sudah melihat beberapa perusahaan menawarkan fungsi yang kurang lebih seperti ini, tetapi tidak satu pun yang memberikan alasan yang benar-benar meyakinkan mengapa teknologi ini perlu ada.

  • Menarik bahwa pengalaman dan alur kerja Anda sangat berbeda dari saya. Ini adalah fitur yang mengklaim menyelesaikan masalah nyata yang saya hadapi setiap hari
    Perusahaan kami sepenuhnya remote, dan sebagian besar rekan kerja saya tidak tinggal di dekat saya. Kami melakukan video chat beberapa kali sehari, tetapi sebagian besar berkomunikasi lewat Slack
    Kami juga termasuk cukup di depan dalam kurva adopsi agen LLM untuk menulis kode yang baik. Berkat model yang bagus dan pagar pengaman yang sangat baik dari coding harness tertentu, akhir-akhir ini LLM menulis sebagian besar kode kami
    Biasanya satu hari dimulai dengan mengambil sebuah tiket, mengarahkannya ke LLM, lalu mulai menyelesaikan masalah bersama. Kami membuat keputusan arsitektur, menyusun rencana, dan mengeksekusinya. Fitur terakhir yang saya deploy menelan biaya token sebesar 19 dolar, dan saat sedang sibuk LLM terus bekerja sekitar 30 menit tanpa input dari saya
    Hanya ketika saya tidak yakin arah mana yang lebih baik, saya mungkin mengajukan pertanyaan di chat tim untuk meminta pendapat rekan kerja. Tetapi banyak tiket diselesaikan sepenuhnya secara otonom
    Setelah itu saya membuka PR dan memposting tautan PR di Slack untuk meminta review, dan saat itulah rekan kerja pertama kali melihat implementasinya. Kadang rekan kerja punya pertanyaan. Untuk percakapan cepat secara real-time, komentar GitHub kurang cocok, jadi mereka sering mengajukan pertanyaan di thread Slack alih-alih di komentar PR
    Jawaban atas pertanyaan-pertanyaan itu ada di log chat saya dengan LLM di laptop saya, tetapi tidak ada cara mudah untuk menunjukkannya kepada rekan kerja. Jadi saya akhirnya memainkan telepon rusak dengan menyalin pertanyaan rekan kerja dari Slack ke chat LLM, lalu menempelkan kembali jawabannya
    Gagasan bahwa rekan kerja, LLM, dan saya bisa lebih mudah ikut serta dalam percakapan yang sama sangat menarik
    Ini bukan berarti tim Zed pasti menuju arah yang benar, dan mungkin tim kami akan lebih baik jika bekerja dengan cara lain. Tetapi pendekatan saat ini terlalu “berhasil”, jadi hampir tidak ada tekanan organisasi untuk mengubahnya

• Pekerjaan tim software adalah secara kolaboratif mempelajari model yang bekerja efektif dalam suatu domain. Lalu mengekspresikan model dan pembelajaran itu dalam kode, tes, dan dokumentasi terkait
  Jadi di satu sisi saya sepenuhnya setuju bahwa pull request dan code review secara fatal merusak proses ini, tetapi saya juga langsung merasa ngeri dengan gagasan membuat prosedur dan artefak tambahan lain yang hanya akan mengalihkan perhatian kita. Semua ini seharusnya muncul di codebase
  Bukan sesuatu yang terpisah. Bukan juga kumpulan commit message atau ADR. Jika codebase tidak bisa sepenuhnya menjelaskan sendiri apa dan mengapa, baik kepada manusia maupun AI, maka itu berarti gagal, dan kita akan menghabiskan sisa hidup membuat lebih banyak prosedur untuk mengelola kegagalan itu

  • Branching yang murah untuk fitur dan eksperimen, kemampuan untuk dengan cepat membatalkan commit tertentu, dan membaca commit message saat terakhir kali satu baris kode diubah, semuanya sangat penting dan dimungkinkan oleh distributed version control system
    Status kode saat ini saja tidak cukup untuk pengembangan software modern