Pendiri awal GitHub mengambil 17 juta dolar dari a16z, membangun Git pada era Agent

Menulis: Leo

Apakah kamu pernah berpikir bahwa pemrograman mungkin benar-benar telah berubah? Pengembang sedang beralih dari sekadar menggunakan alat AI, menjadi memandang AI sebagai fondasi baru dalam membangun perangkat lunak. Ini bukan sekadar penyesuaian kecil, melainkan sebuah perubahan paradigma yang menyeluruh. Bayangkan saja, konsep inti yang selama ini kita anggap biasa—pengendalian versi, cabang, tinjauan kode, bahkan definisi “kolaborasi”—semuanya sedang didefinisikan ulang karena alur kerja yang didorong oleh agen AI. Lebih mengejutkan lagi, Git yang kita gunakan setiap hari sebenarnya adalah alat yang dirancang untuk alur kerja patch daftar email 20 tahun yang lalu, kini harus melayani skenario di mana pengembang manusia dan sekelompok agen AI bekerja secara bersamaan.

Itulah sebabnya berita bahwa GitButler baru saja mendapatkan pendanaan Seri A sebesar 17 juta dolar membuat saya berhenti dan berpikir serius. Pendanaan ini dipimpin oleh a16z, diikuti oleh Fly Ventures dan A Capital. Lebih menarik lagi, CEO GitButler Scott Chacon adalah salah satu pendiri GitHub, yang menulis buku “Pro Git” yang hampir setiap pengembang pernah baca. Orang yang sudah meraih keberhasilan besar di bidang pengendalian versi, mengapa harus kembali ke jalur startup dan memikirkan ulang masalah yang tampaknya sudah “terpecahkan” ini? Dalam pengumuman resminya, dia mengatakan secara lugas: “Kami bukan membangun ‘Git yang lebih baik’, kami membangun infrastruktur dasar generasi berikutnya untuk pembangunan perangkat lunak.” Kalimat ini menyimpan wawasan mendalam tentang masa depan pengembangan perangkat lunak.

Kebuntuan Git 20 Tahun: Alat yang Dirancang untuk Daftar Email

Saya menyadari banyak orang tidak memahami latar belakang sejarah Git. Awalnya, Git dibuat oleh tim kernel Linux pada tahun 2005, dan filosofi desainnya sangat berakar pada tradisi Unix. Dalam wawancara, Scott menyebutkan detail menarik: tim inti Git sama sekali tidak berniat membuat antarmuka yang ramah pengguna. Mereka mengikuti filosofi Unix, membangun serangkaian “perintah pipa” tingkat rendah, di mana setiap perintah melakukan satu hal sederhana, lalu kamu bisa menggabungkannya dengan skrip Perl untuk melakukan apa pun yang diinginkan. Ide desain ini sangat masuk akal saat itu, karena mereka berasumsi hanya para ahli seperti tim kernel Linux yang akan menggunakan alat ini.

Kemudian, hal yang kita semua tahu terjadi. Seorang pengembang bernama Pasquy menulis beberapa skrip Perl yang membungkus Git dengan antarmuka pengguna yang seragam, yaitu apa yang sekarang kita kenal sebagai perintah CLI. Skrip-skrip ini menjadi sangat populer dan akhirnya digabungkan ke dalam inti Git, menjadi apa yang disebut “lapisan porselen” (porcelain). Menariknya, perintah-perintah ini sejak 2005-2006 hampir tidak mengalami perubahan besar. Awalnya ditulis dalam Perl, kemudian ditulis ulang dalam C, tetapi logika inti dan antarmuka pengguna hampir tetap sama. Scott mengatakan bahwa saat dia menulis edisi pertama “Pro Git” pada 2009, perintah-perintah tersebut masih bisa digunakan secara langsung tanpa perubahan.

Stabilitas ini, dalam beberapa hal, adalah hal yang baik. Tim Git sangat menghargai kompatibilitas ke belakang dan enggan menghapus fitur yang sudah ada karena khawatir akan merusak alur kerja yang ada. Tapi ini juga menimbulkan masalah mendasar: asumsi inti saat Git dirancang sudah sangat tidak sesuai lagi dengan praktik pengembangan perangkat lunak saat ini. Git dirancang untuk mengirim patch melalui daftar email. Pada masa itu, pengembang akan melakukan perubahan lokal, membuat file patch, lalu mengirimkannya ke pemelihara, yang kemudian meninjau dan memutuskan apakah akan menerima. Proses ini bersifat asinkron, berbasis teks, dan satu-thread.

Lalu, sekarang? Kita punya integrasi berkelanjutan, deployment berkelanjutan, tim yang tersebar secara real-time, alat tinjauan kode, serta berbagai pipeline otomatisasi pengujian dan deployment. Lebih dari itu, kini ada agen AI yang menulis kode secara massal. Scott menyebutkan sebuah pengamatan yang sangat berkesan: kita sedang mengajari sekelompok agen AI menggunakan alat yang dirancang untuk patch daftar email. Ketidaksesuaian ini seperti mengendarai Tesla di jalan yang dirancang untuk kereta kuda.

Filosofi Unix yang diterapkan pada Git juga menimbulkan masalah lain: ia mencoba melayani dua pihak sekaligus—komputer dan manusia—dengan satu antarmuka. Jika kamu menjalankan “git branch”, secara default kamu hanya akan mendapatkan daftar cabang tanpa antarmuka pengguna yang jelas. Ini karena Git harus memastikan output perintah ini bisa dibaca manusia sekaligus diparse oleh program lain. Akibatnya, Git tidak cukup ramah untuk manusia dan tidak optimal untuk mesin. Meski ada opsi “–porcelain” untuk output yang bisa dibaca mesin, ini bukan praktik standar dan banyak perintah tidak memilikinya.

Tantangan Baru di Era Agen AI: Direktori Kerja Tidak Cukup Lagi

Ketika AI mulai berperan besar dalam pemrograman, keterbatasan Git menjadi semakin nyata. Saya sendiri baru-baru ini mencoba menggunakan beberapa agen AI sekaligus dan menemukan bahwa asumsi dasar Git—seorang pengembang, satu cabang, alur kerja linier—sudah benar-benar tidak berlaku lagi. Pengembang modern tidak bekerja secara linier. Kamu mungkin menjalankan beberapa agen secara paralel: satu memperbaiki bug UI, yang lain mengoptimalkan kueri basis data, yang ketiga memperbarui dokumentasi. Tapi sistem indeks Git akan gagal dalam pengeditan paralel ini karena mengasumsikan bahwa salinan kerja lokal mewakili satu perubahan atomik pada repositori.

Solusi tradisional adalah menggunakan worktree, yaitu membuat beberapa salinan repositori untuk setiap tugas paralel. Tapi ini menimbulkan masalah baru. Jika ada lima agen yang bekerja bersamaan, kamu harus memiliki lima salinan lengkap dari direktori kerja. Meskipun Git mengoptimalkan dari segi penyimpanan, ini tetap berarti banyak duplikasi file dan penggunaan ruang disk. Lebih dari itu, agen-agen ini sepenuhnya terisolasi satu sama lain; mereka tidak bisa melihat apa yang dilakukan yang lain sampai mereka selesai dan mencoba menggabungkan. Pada saat itu, biaya menyelesaikan konflik sudah sangat tinggi.

GitButler mengusulkan solusi berupa cabang paralel (parallel branches). Ini adalah desain yang sangat menarik. Cabang paralel mirip cabang biasa, tapi kamu bisa membuka banyak sekaligus. Kamu mendapatkan manfaat worktree (isolasi logis), tapi tanpa perlu menyalin semua file. Semua agen bekerja dalam satu direktori kerja yang sama, tetapi perubahan mereka dialokasikan ke cabang virtual yang berbeda. Scott menggambarkan sebuah skenario yang mengesankan: mereka membiarkan dua agen bekerja bersamaan, keduanya ingin mengedit file yang sama, tetapi caranya tidak kompatibel. Hasilnya? Salah satu agen secara otomatis menumpuk cabangnya di atas cabang agen lain, lalu melanjutkan pekerjaan dan melakukan commit di tumpukan tersebut. Penanganan konflik yang cerdas ini hampir tidak mungkin dilakukan dalam alur kerja Git tradisional.

Saya sangat mengapresiasi salah satu eksperimen tim GitButler, meskipun akhirnya mereka tidak mengadopsinya. Mereka pernah mencoba membuat saluran komunikasi antar agen agar bisa saling berkomunikasi tentang apa yang sedang mereka lakukan. Scott mengatakan fitur ini terlihat sangat keren: mereka bisa melihat percakapan antar agen, sangat ingin merilisnya. Tapi setelah banyak pengujian, mereka menyadari fitur ini sebenarnya tidak membantu. Agen secara otomatis mendeteksi jika ada orang lain yang mengubah file tertentu, menebak alasannya, lalu menyesuaikan strategi kerjanya sendiri. Mereka tidak perlu komunikasi eksplisit karena komunikasi sendiri justru menimbulkan overhead dan memperlambat proses. Penemuan ini sangat menginspirasi: kita tidak bisa sekadar meniru pola kolaborasi manusia ke agen; agen memiliki cara kerja sendiri.

Redesain Antarmuka: Untuk Manusia, Agen, dan Skrip

GitButler baru saja merilis alat CLI yang sangat menarik. Ini bukan sekadar pembungkus Git, melainkan pemikiran ulang mendasar tentang bagaimana alat baris perintah harus dirancang. Scott menyebutkan sebuah pengamatan menarik: sekitar 80% pengembang masih menggunakan alat baris perintah untuk mengoperasikan Git, meskipun ada berbagai GUI. Alasannya sederhana—kebanyakan GUI Git hanya membungkus perintah Git dalam antarmuka grafis, tanpa menambah fungsi baru, malah memperlambat operasi. Jika kamu tahu perintah apa yang harus dijalankan, mengetik langsung di terminal biasanya lebih cepat.

Tapi CLI GitButler berbeda. Ia menyediakan berbagai format output sesuai skenario penggunaan. Jika kamu menjalankan perintah langsung, ia akan memberi output yang dioptimalkan dan ramah manusia, lengkap dengan petunjuk dan saran. Jika kamu menambahkan “–json”, ia akan memberi data terstruktur dalam JSON yang mudah diparse skrip. Mereka bahkan mempertimbangkan menambahkan “–markdown” untuk output yang dioptimalkan bagi agen, karena format markdown lebih mudah disuntikkan ke konteks agen.

Lebih menarik lagi, mereka mengamati perilaku agen secara langsung untuk mengoptimalkan desain alat. Mereka menemukan bahwa meskipun opsi “–json” tersedia, agen lebih suka menggunakan output yang bisa dibaca manusia, lalu mengalirkannya ke jq atau skrip Python untuk mengekstrak informasi. Temuan lain adalah, setelah menjalankan perintah modifikasi, agen hampir selalu langsung menjalankan “git status” untuk memeriksa keadaan. Jadi, tim GitButler menambahkan opsi “–status-after” ke semua perintah modifikasi, sehingga setelah operasi selesai, otomatis menampilkan status. Desain ini bertentangan dengan filosofi Unix tradisional dan kurang cocok untuk scripting, tapi sangat cocok untuk agen.

Mereka juga sedang mengeksplorasi cara memberi konteks lebih banyak ke agen melalui output. Misalnya, menyisipkan petunjuk seperti “Jika ingin melakukan ini, jalankan perintah ini”. Ini bukan untuk manusia—karena akan terasa bertele-tele—tapi sangat membantu agen dalam memutuskan langkah berikutnya. Scott menyebut ini sebagai masalah UX yang menarik: kita harus memperlakukan agen sebagai “profil pengguna” baru, dengan kebutuhan dan pola perilaku yang berbeda dari manusia.

Perubahan Esensial dalam Pengembangan Perangkat Lunak: Dari Menulis Kode ke Menulis Spesifikasi

Dalam wawancara, Scott menyampaikan sebuah pandangan yang sangat memancing pemikiran: di masa depan, pengembang perangkat lunak terbaik mungkin bukan mereka yang menulis kode paling bagus, melainkan mereka yang paling pandai berkomunikasi, menulis, dan mendeskripsikan. Ini terdengar kontra-intuitif, karena banyak dari kita memilih pemrograman karena bisa berinteraksi langsung dengan mesin, bukan manusia. Tapi, jika dipikir-pikir, tren ini sangat masuk akal.

Ketika agen AI mampu menghasilkan kode secara efisien, hambatannya bukan lagi pada detail implementasi, melainkan pada seberapa jelas kamu bisa mendeskripsikan apa yang diinginkan. Scott berbagi alur kerjanya sendiri: dia sekarang lebih banyak menulis spesifikasi secara rinci tentang bagaimana sebuah fitur harus bekerja. Setiap kali ada keputusan desain, dia minta AI mengimplementasikan berdasarkan spesifikasi itu, lalu menguji hasilnya. Jika ada masalah, dia kembali memperbaiki spesifikasi dan meminta AI mengulang. Siklus ini sangat cepat karena dia tidak perlu menulis semua kode sendiri.

Keindahan cara kerja ini adalah kamu bisa melakukan “show and tell” dengan cepat. Secara tradisional, jika ingin menguji ide, kamu harus menulis dokumen teknis lengkap dan meyakinkan tim untuk membacanya. Tapi dokumen saja tidak seefektif prototipe yang bisa dijalankan. Sekarang, kamu bisa dengan cepat membuat prototipe, membiarkan tim mencoba langsung, lalu melakukan iterasi berdasarkan feedback. Ini mempercepat siklus dari ide ke verifikasi secara signifikan.

Tapi, ini juga menimbulkan tantangan baru. Batas kolaborasi tim beralih dari “apakah kita bisa mengimplementasikan ini” ke “apakah kita bisa sepakat tentang apa yang diinginkan”. Scott menyebutkan banyak pengembang, terutama yang merasa sangat pintar, beranggapan bahwa mereka tidak perlu menjelaskan apa yang mereka lakukan karena kode adalah dokumen terbaik. Tapi di era AI, sikap ini tidak lagi berlaku. Kamu harus mampu mengungkapkan niatmu secara jelas dan menulis spesifikasi yang bisa dipahami manusia dan AI. Kemampuan menulis menjadi kekuatan baru.

Ini juga mengubah pandangan tentang tinjauan kode. Scott mengajukan pertanyaan tajam: jika kamu jujur, apakah mayoritas pengembang benar-benar membaca seluruh PR secara detail? Memikirkan logika baris demi baris? Menjalankan pengujian lokal? Atau hanya sekadar melihat sekilas dan menyetujuinya? Kebanyakan orang melakukan yang terakhir. Bukan karena tidak bertanggung jawab, tapi karena tinjauan lengkap sangat mahal dan manfaatnya tidak selalu sepadan.

Agent AI bisa mengubah permainan di sini. Mereka mampu meninjau setiap baris kode secara teliti, menjalankan pengujian, dan memeriksa potensi masalah. Mereka tidak lelah dan tidak bosan, serta konsisten dalam standar peninjauan. Dengan demikian, manusia bisa fokus pada aspek yang lebih tinggi: apakah perubahan ini sesuai arah produk? apakah memenuhi kebutuhan pengguna? apakah arsitektur sudah tepat? Detail implementasi, sintaks, dan bug potensial bisa diserahkan ke AI.

PR dan Issue: Mode Kolaborasi yang Sudah 20 Tahun Tidak Berkembang Seharusnya Bertransformasi

Model Pull Request (PR) di GitHub sudah menjadi standar kolaborasi open source, tapi Scott melihat adanya masalah mendasar. PR berbasis cabang, bukan patch, menyebabkan banyak “sampah commit”—seperti “oh, memperbaiki bug kecil ini” atau “lupa menambahkan file ini”. Karena PR berfokus pada seluruh cabang, bukan pada commit individual, kualitas pesan commit sering diabaikan. Setelah digabung, deskripsi PR biasanya hilang dan tidak tersimpan dalam sejarah Git.

Pada era daftar email, ini bukan masalah. Setiap patch memiliki pesan commit yang lengkap, yang berfungsi sebagai deskripsi PR. Tinjauan berbasis patch, dan kualitas patch serta pesan commit sangat berpengaruh. Tapi di era GitHub, kita kehilangan batasan ini. Scott berpendapat, masa depan tinjauan kode harus kembali ke model berbasis patch, tapi dengan memanfaatkan alat modern. Tinjauan harus dilakukan secara lokal, memungkinkan kamu menjalankan kode dan menguji fungsi. Agen bisa membantu menjalankan pengujian dan menandai masalah, sehingga kamu hanya fokus pada bagian yang benar-benar membutuhkan penilaian manusia.

Ada juga pandangan menarik tentang komunikasi antar tim. Scott menyebutkan bahwa salah satu aspek yang buruk dalam pengembangan perangkat lunak adalah komunikasi real-time antar tim. Jika kamu mengubah file yang sama dengan orang lain, biasanya baru ketahuan saat penggabungan, dan salah satu harus menanggung beban besar. Tapi jika kita bisa mengetahui apa yang dilakukan orang lain secara real-time, ini akan sangat membantu. Untuk manusia, komunikasi real-time bisa terlalu mengganggu, tapi untuk agen, ini bukan masalah. Agen bisa menggunakan waktu luangnya untuk saling berkomunikasi, memahami apa yang dilakukan anggota tim lain, mendeteksi konflik sejak dini, dan menyesuaikan strategi kerja mereka.

Sistem metadata yang sedang dieksplorasi GitButler juga menarik. Mereka ingin menambahkan catatan percakapan, proses berpikir agen, dan konteks terkait ke commit atau cabang. Saat ini, Git sangat terbatas dalam mendukung metadata semacam ini. Informasi ini sangat berharga untuk memahami alasan di balik keputusan tertentu, proses berpikir di balik kode. Tapi ini juga membawa masalah data besar: meskipun hanya menyimpan teks, volume metadata ini bisa sangat besar. Mereka harus memanfaatkan teknologi dari repositori besar seperti Chrome atau tim Microsoft Office untuk mengelola data dalam skala besar ini.

Refleksi Saya tentang Perubahan Ini

Setelah membaca kisah GitButler dan wawancara Scott, saya merasa sangat terinspirasi. Pengembangan perangkat lunak sedang mengalami perubahan paradigma yang mendasar, dan sebagai infrastruktur dasar, sistem pengendalian versi harus beradaptasi. Filosofi Git yang 20 tahun lalu sangat maju, tapi sekarang sudah menjadi hambatan. Kita tidak lagi membutuhkan “Git yang lebih baik”, melainkan fondasi baru yang sesuai dengan alur kerja modern dan era AI.

Yang sangat resonan bagi saya adalah pemikiran Scott tentang “titik logika akhir”. Dia mengatakan bahwa dalam memulai usaha pembelajaran bahasa, banyak orang melihat teknologi terjemahan waktu nyata dan berkata bahwa pembelajaran bahasa sudah mati. Tapi dia membantah bahwa meskipun ada penerjemah sempurna, komunikasi tetap tidak sebaik berbicara dalam bahasa yang sama. Dia pernah bekerja selama seminggu di Jepang dengan penerjemah yang sangat bagus, tapi pengalaman itu tetap tidak memuaskan; kamu tidak akan membangun hubungan yang mendalam atau kolaborasi kompleks dengan cara itu. Sama halnya dengan pemrograman. Sekali AI menjadi sangat kuat, mereka tidak bisa sepenuhnya menggantikan penilaian manusia, kreativitas, dan kemampuan komunikasi.

Mengenai masa depan GitHub, saya setuju dengan pandangan Scott. Keunggulan utama GitHub adalah basis pengguna yang besar, sedangkan kelemahannya adalah sebagai perusahaan besar, sulit untuk bertransformasi dengan cepat. Saat ini, seluruh industri sedang mencari “pengganti GitHub”, tapi Scott menunjukkan bahwa pertanyaan ini mungkin salah. GitHub sendiri bukanlah “pengganti” dari apa pun; ia menciptakan pola kolaborasi yang benar-benar baru. Di masa depan, mungkin akan muncul pola kolaborasi yang sama sekali berbeda dan bahkan tidak kita bayangkan saat ini.

Saya percaya nilai utama GitButler bukan hanya fitur spesifiknya, tetapi cara berpikir yang diwakilinya. Mereka mempertanyakan asumsi yang selama ini kita anggap biasa: mengapa kita hanya bisa bekerja di satu cabang? Mengapa commit harus linier? Mengapa agen dan manusia harus menggunakan antarmuka yang sama? Mengapa kolaborasi harus melalui PR dan issue? Pemikiran dari prinsip pertama ini sangat penting di era perubahan cepat ini.

Saya juga menyadari bahwa sebagai pengembang, kita perlu mengembangkan keterampilan baru. Menulis spesifikasi yang jelas, berkomunikasi secara efektif, memahami cara kerja agen AI—semuanya mungkin lebih penting daripada sekadar kemampuan coding. Ini mungkin menjadi tantangan, terutama bagi mereka yang memilih pemrograman untuk menghindari interaksi manusia. Tapi ini juga peluang: kita bisa membebaskan diri dari detail implementasi yang rumit dan fokus pada pekerjaan yang lebih kreatif: mendefinisikan masalah, merancang solusi, dan membuat keputusan yang tepat.

Pendanaan sebesar 17 juta dolar untuk GitButler hanyalah awal. Saya yakin dalam beberapa tahun ke depan, kita akan melihat lebih banyak upaya untuk meredefinisi infrastruktur pengembangan perangkat lunak. Pengendalian versi, tinjauan kode, manajemen proyek, pengujian, dan deployment—semuanya adalah alat yang dirancang sebelum era AI dan perlu dirombak. Pengembang dan tim yang mampu beradaptasi lebih dulu akan mendapatkan keuntungan besar dalam perubahan ini.

Akhirnya, pengembangan perangkat lunak akan lebih berfokus pada komunikasi, kolaborasi, dan pengambilan keputusan, bukan lagi pada sintaks dan detail implementasi. Ini mungkin membuat beberapa programmer tradisional tidak nyaman, tapi saya yakin ini adalah hal yang positif. Ini membuat pemrograman lebih mendekati inti dari pemecahan masalah, bukan lagi terjebak dalam detail teknis. Ketika kita tidak lagi perlu mengingat perintah Git yang rumit, tidak perlu menyelesaikan konflik merge secara manual, dan tidak perlu menghabiskan waktu menulis kode berulang, kita bisa mengalihkan energi ke hal yang benar-benar penting: memahami kebutuhan pengguna, merancang solusi elegan, dan menciptakan produk yang bernilai. Inilah inti dari pengembangan perangkat lunak dan arah yang coba dibawa GitButler untuk kita kembali ke sana.