Jika AI menulis kode, haruskah sesi juga menjadi bagian dari commit?

(github.com/mandel-macaque)

26 poin oleh GN⁺ 2026-03-03 | 4 komentar | Bagikan ke WhatsApp

git-memento adalah alat ekstensi yang secara otomatis merekam sesi kode yang dihasilkan AI ke dalam Git commit, dengan menyimpan riwayat percakapan AI yang terkait dengan tiap commit sebagai git notes
Saat menentukan ID sesi AI ketika commit, ringkasan disimpan terpisah di refs/notes/commits, sementara percakapan lengkap disimpan di refs/notes/memento-full-audit, sehingga ketertelusuran dan privasi dapat dijaga sekaligus
Mendukung berbagai penyedia AI seperti Codex dan Claude, serta memungkinkan penerapan skill kustom pengguna saat membuat ringkasan untuk mengontrol kualitas catatan commit
Terintegrasi dengan GitHub Actions, menyediakan fitur komentar otomatis untuk catatan commit, validasi CI gate, dan pemindahan catatan otomatis saat merge (merge-carry)
Mendukung Windows/Mac/Linux. Alat ini meningkatkan transparansi pembuatan kode oleh AI dan memastikan kemampuan audit atas riwayat kontribusi AI dalam lingkungan kolaboratif

Ikhtisar git-memento

git-memento adalah alat ekstensi Git untuk mencatat sesi coding AI per commit
- Saat commit, isi percakapan sesi AI dirangkum dan disimpan sebagai catatan Markdown
- Setiap commit menyimpan asal dan konteks percakapan dari sesi AI sehingga proses pembuatan kode dapat ditelusuri
Secara default mendukung Codex, dan AI model lain seperti Claude juga dapat dikonfigurasi
Dirilis dengan lisensi MIT dan didistribusikan sebagai file eksekusi tunggal berbasis NativeAOT

Perintah utama dan fitur

Inisialisasi konfigurasi per repositori dengan git memento init, lalu simpan informasi penyedia AI ke .git/config
Gunakan perintah git memento commit untuk menambahkan catatan sesi bersamaan dengan commit
- Dengan opsi --summary-skill, ringkasan dan sesi penuh dapat disimpan secara terpisah
- Ringkasan dicatat ke refs/notes/commits, dan log lengkap ke refs/notes/memento-full-audit
git memento amend memungkinkan penambahan atau perubahan sesi baru pada commit yang sudah ada
git memento audit memeriksa apakah ada catatan yang hilang dalam rentang commit serta memvalidasi metadata
git memento doctor memeriksa konfigurasi, referensi catatan, dan status sinkronisasi remote

Pengelolaan dan sinkronisasi catatan

Dorong catatan ke repositori remote (origin dan lainnya) dengan git memento share-notes
git memento notes-sync menggabungkan catatan remote dengan aman dan membuat cadangan
- Menyinkronkan refs/notes/commits dan refs/notes/memento-full-audit sekaligus
git memento notes-carry memindahkan catatan ke commit baru setelah rebase atau squash
git memento notes-rewrite-setup mengaktifkan pengaturan pemindahan catatan otomatis

Integrasi GitHub Actions

Repositori ini menyertakan GitHub Action yang dapat digunakan ulang
- mode: comment — membaca catatan commit dan menulis komentar otomatis
- mode: gate — memeriksa ada tidaknya catatan yang hilang pada tahap CI, dan memblokir build jika gagal
- mode: merge-carry — memindahkan catatan ke merge commit saat PR digabungkan
Tiap mode didefinisikan di action.yml, dan menyertakan artefak untuk pendaftaran Marketplace (dist/note-comment-renderer.js)
PR dengan label ignore-notes akan melewati pemeriksaan gate dan meninggalkan komentar “Notes ignored”

Format catatan dan versioning

Catatan disimpan dalam format git notes add -f -m ""
Menggunakan tag versi(``) dan pemisah bagian untuk mendukung banyak sesi
Pesan pengguna diberi label nama pengguna Git, sedangkan respons AI diberi label nama penyedia
Catatan lama dengan sesi tunggal akan ditingkatkan versinya secara otomatis bila diperlukan untuk menjaga kompatibilitas

4 komentar

wedding 2026-03-03

Untuk proyek privat, saya mengekspor sesi lalu meng-commit-nya, dan untuk yang publik saya meng-commit file ringkasan jika dinilai memang perlu. Soalnya ada juga data pribadi.. dan meski tiap tool berbeda-beda, per sesi gampang lewat 10 MB.. jadi rasanya agak kurang pas kalau langsung diunggah begitu saja

roxie 23 hari lalu

Tapi kita hidup di era ketika disk lebih murah daripada sebelumnya!

GN⁺ 2026-03-03

Komentar Hacker News

Saat menulis kode dengan AI, saya mulai dari file project.md
Di situ saya menjelaskan hasil yang saya inginkan, lalu meminta AI menulis plan.md berdasarkan itu
Setelahnya saya merevisi plan.md berkali-kali sampai rencana yang diinginkan matang, lalu membuat daftar todo detail dan menempelkannya di akhir plan.md
Setelah benar-benar puas, saya memerintahkan AI untuk menjalankan todo itu dan menyelesaikannya sampai akhir tanpa bertanya lagi
Terakhir, saya commit project.md, plan.md, dan seluruh kode
Dengan begini, plan.md menjadi semacam artefak yang dapat direproduksi, sehingga model yang lebih maju di masa depan bisa menggunakannya untuk melakukan modifikasi atau menemukan kesalahan
- Saya juga melakukan hal serupa, tetapi membaginya menjadi tiga dokumen — design, plan, debug
  design ditulis per fitur, dengan pertanyaan yang belum terjawab dicantumkan secara jelas
  plan dikelola dengan struktur plan/[feature]/phase-N-[description].md, dan saya berhenti jika mentok pada batas build atau eksekusi
  Pada tahap debug, saya menyusun hipotesis kemungkinan penyebab, memverifikasinya dengan logging/tracing, lalu memperbaikinya
  Dengan cara ini, saya melihat tingkat keberhasilan hampir 100% baik pada proyek baru maupun legacy
  Kekurangannya adalah terlalu banyak file markdown yang menumpuk, tetapi karena catatan lama berguna untuk perubahan di masa depan, saya belum mengotomatiskannya
- Ini terdengar seperti pendekatan berbasis spec
  Mungkin layak melihat GitHub spec-kit
- Fitur “brainstorming” di obra/superpowers hampir sama persis dengan workflow ini. Sangat bagus saat dipakai
- Dulu saya memakai Beads seperti ini, lalu setelah itu membuat GuardRails
  Saat membiarkan model melakukan riset pasar dan meninjau proposal secara berulang, model akhirnya melakukan desain prompt dalam bahasa yang bisa dipahaminya sendiri
  Baru-baru ini saya mengetahui bahwa XML memengaruhi perilaku Claude, jadi saya sedang memikirkan ulang struktur GuardRails
  Tautan artikel pengantar
- Saya juga memakai struktur serupa, tetapi menyimpan file “context” secara terpisah
  Setelah plan selesai, saya membuat “context.md” untuk referensi saat nanti perlu membatalkan rencana yang ternyata salah
  Saya belum pernah benar-benar perlu memakainya, tetapi secara konsep ini berguna
  Hanya saja, saya masih ragu file seperti ini sebaiknya diletakkan di mana, jadi belum saya masukkan ke repo
  Saya penasaran di mana orang biasanya menyimpan file md per tugas seperti ini
Menurut saya ini sama seperti pertanyaan “apakah semua baris harus di-commit?”
Pada akhirnya yang penting adalah catatan ini untuk siapa
Sebagian besar sesi penuh noise, dengan banyak percobaan yang salah atau informasi yang tidak perlu
Yang penting adalah hasil dari sesi itu, bukan prosesnya sendiri
Tapi spec awal atau prompt pertama tetap bernilai. Sebaiknya itu diringkas dan disimpan dalam commit message atau file markdown
- Bagi manusia ini rumit dan berisik, tetapi informasi sesi seperti ini bisa berguna bagi AI masa depan
  Sesi lama bisa dijadikan konteks pembelajaran untuk melanjutkan pekerjaan saat ini
  Ini bisa membantu khususnya dalam memahami batas model dan menemukan titik ketika kode mulai menyimpang dari niat pengguna
  Pada akhirnya saya pikir mencatat semua input manusia penting untuk perkembangan model open source
- Daripada “apakah semua baris di-commit”, analogi yang lebih tepat mungkin “apakah semua catatan dan percobaan yang gagal harus disimpan”
- Dalam riset ilmiah pun masalah seperti ini sudah lama ada — krisis reproduktibilitas
  Hasil yang sama seharusnya tetap muncul bahkan jika kondisi awal dan noise ikut diperhitungkan
  Kalau tidak, pemeliharaan kode di masa depan akan berubah menjadi permainan menebak niat
  Artikel terkait
- Jika organisasinya menekankan transparansi, ini mungkin bernilai untuk audit, tetapi secara realistis siapa yang mau membaca log sepanjang itu
- Tidak semua sesi perlu disimpan, tetapi momen ketika requirement menjadi lebih konkret selama proses revisi layak dipertahankan
Saya mengusulkan ide serupa seminggu lalu (tautan)
Tetapi ada banyak yang menolak — proyek AI tidak dihasilkan dari satu input tunggal, melainkan proses percakapan, jadi sulit dijadikan artefak seperti source code
Meski begitu, sekarang terlalu banyak proyek generatif yang naik ke Show HN sehingga noise-nya sudah serius
Tidak mungkin sepenuhnya dikecualikan, tetapi dalam kondisi sekarang minat saya menurun
Saya sedang memikirkan bagaimana komunitas seharusnya menangani masalah ini
- Saya merujuk ke cara Boris Tane memakai Claude untuk menulis kode
  Saya commit research.md dan plan.md, lalu memakainya sebagai kamus hidup untuk arsitektur dan fitur
  Nama fitur saya taruh sebagai prefiks nama file agar Claude bisa cepat memanggil desain yang relevan
  Blog rujukan
- Masalahnya bukan kurangnya konteks, melainkan standar upaya yang menurun
  Proyek yang dulu terasa menarik sekarang terlalu mudah dibuat
  Membuat orang membaca log sesi panjang bukanlah solusi. Kemampuan merangkum dan merencanakan kini menjadi lebih penting
- Akan bagus kalau Codex bisa mengekspor seluruh sesi ke markdown
  Nilai sebenarnya dari vibe coding adalah melihat proses coba-coba dan kegagalan
- Saya juga sedang mempertimbangkan apakah akan memposting dua proyek ke Show HN
  Daripada hanya menaruh hasil akhir, akan lebih menarik bila ada proses pembuatan dan penjelasannya
  Karena itu, akan bagus jika selain [Show HN] ada kategori seperti [Creations]
  Misalnya: chess engine biasa masuk [Creations], chess engine yang dibuat dengan 1k masuk [Show HN]
  PerfBoard dan Lerc adalah contohnya
Sesi hanyalah artefak perantara, jadi tidak perlu dimasukkan ke hasil akhir
Jika alasan perubahan kode penting, lebih tepat merangkumnya dalam commit message atau dokumentasi
- Ini pada akhirnya adalah masalah ringkasan
  Pada saat commit, kita belum tahu pertanyaan apa yang akan diajukan pembaca di masa depan
  Karena itu saya lebih suka menyimpan sesi, lalu nanti membuat ringkasan berdasarkan pertanyaan
  Git AI memakai pendekatan seperti ini
  Engineer belakangan bekerja terlalu cepat, jadi kadang seminggu kemudian saja mereka sudah lupa kenapa melakukan sesuatu dengan cara tertentu
- Setidaknya ringkasan sesi tetap diperlukan
  Prompt yang sifatnya riset sebaiknya diringkas, sementara prompt untuk generasi kode sebaiknya disimpan apa adanya
  Dengan begitu reproduksibilitas dan kemudahan review bisa terjaga
- Dulu saya hanya meminta LLM menulis commit message, tetapi sekarang saya merasa versioning file plan lebih baik
  Rencana itu ikut mencerminkan proses perbaikan error, sehingga menjadi dokumen yang berguna untuk iterasi berikutnya
- Dalam kasus saya, repo itu sendiri adalah penyimpanan memori bagi agen
  Tiap repo saling bertukar pesan untuk mengelola permintaan fitur
  Percakapan asli dan memori yang dipadatkan secara semantik disimpan bersama, agar spesifikasi dan requirement bisa disusun ulang
- Menyimpan sesi juga berguna untuk melacak akar bug atau analisis setelah kejadian
Log sesi kebanyakan adalah noise
Isinya rangkaian percobaan gagal dan rollback, jadi menaruhnya di samping commit itu seperti menyimpan browser history
Yang penting adalah commit message yang memuat niat dan constraint
Jika AI yang menulis kode, inti persoalannya bukan percakapannya melainkan mengapa permintaan itu diberikan
Pada akhirnya, masalahnya mungkin bukan penyimpanan sesi, melainkan kebiasaan menyepelekan commit message
Meski memakai AI, saya tetap mempertahankan prosedur desain tradisional
requirement → use case → desain kelas → definisi constraint → eksekusi AI
Dengan begitu, penilaian arsitektural tetap dijaga oleh manusia, sementara AI mempercepat implementasi yang berulang
Jika dibanding log sesi, memasukkan dokumen UML/constraint seperti ini ke commit akan meninggalkan niat dan konteks dengan lebih jelas
Menurut saya, developer tahun 2026 harus menjaga struktur kolaborasi yang bermartabat seperti ini
Ini mirip dengan pertanyaan apakah commit perlu di-squash atau tidak
Jika Anda lebih suka squash, berarti yang penting hasil akhirnya dan prosesnya tidak disimpan
Jika tidak, berarti perjalanan itu sendiri juga dicatat
Sesi AI juga sama; itu berguna untuk debugging alur berpikir, tetapi orang yang menyukai histori bersih belum tentu ingin melihatnya
Secara realistis, sesi lebih cocok dikelola terpisah di luar repo
- Saya juga termasuk kubu squash, tetapi jika ada sistem yang memungkinkan histori internal dibuka, saya juga ingin melihat sesi bersama itu
  Katanya Mercurial atau Fossil lebih baik untuk fitur seperti ini
- Menurut saya analogi ini yang paling tepat
  Dalam vibe-coding, daripada kodenya sendiri, prompt menunjukkan jejak pemikiran
  Soal apakah itu dimasukkan ke git atau tidak adalah hal lain, tetapi membuatnya tetap bisa diakses itu bernilai
- Jika development-nya dipimpin manusia, penggunaan AI hanyalah alat biasa
  Dalam kasus seperti itu tidak perlu melihat proses real-time
  Tetapi jika kodenya benar-benar ditulis sepenuhnya oleh AI, maka prompt perlu dibuka
Saya juga pernah mengekstrak sesi
Meski ada risiko kehilangan sebagian informasi, keterbacaan dan aksesibilitas jadi jauh lebih baik
Saya pikir setidaknya prompt yang sudah diringkas dari sesi harus disimpan
AI code review kurang ketat dibanding manusia, dan niatnya hanya tersimpan di prompt
Kalau tidak, kesalahan yang sama akan terus terulang
Nilai code review adalah pembelajaran dan perbaikan, tetapi AI tidak belajar, jadi catatan prompt harus mengambil peran itu
Selain itu ini juga dibutuhkan untuk menilai kemampuan membuat prompt atau melatih junior
- Tetapi saya tidak setuju kalau ini dianggap “sudah jelas”
  Kita tidak memasukkan penekanan tombol, klik menu, atau percobaan debugging ke dalam commit
  Jika semua percakapan disimpan, noise-nya akan terlalu besar
  Sebagai gantinya, lebih realistis menyisakan dokumen yang memuat niat dan asumsi saja
- Sekadar penasaran, menurut Anda ukuran sesi biasanya kira-kira sebesar apa
Ini sama seperti bertanya, “apakah riwayat pencarian Google harus dimasukkan ke commit?” — tentu saja menurut saya tidak
- Analogi yang sempurna. Mencatat setiap potongan pikiran punya rasio sinyal terhadap noise yang terlalu buruk
  Sebaiknya hanya meninggalkan ringkasan alasan, asumsi, dan alternatif
- Tetapi jika sesi disimpan, query pencarian dan hasil yang dilakukan AI juga ikut tersimpan, sehingga bisa berguna sebagai konteks proyek
- Tidak ada yang ingin tahu berapa kali seseorang mencari “cara membuat div di tengah”
  Demikian juga, log model yang tersendat pada masalah sepele itu tidak perlu
- Lagi pula, tidak semua pencarian relevan dengan commit. Bisa saja mengandung informasi sensitif