Yapay zeka kod yazıyorsa, oturum da commit’in bir parçası olmalı mı?

(github.com/mandel-macaque)

26 puan yazan GN⁺ 2026-03-03 | 4 yorum | WhatsApp'ta paylaş

git-memento, yapay zeka tarafından üretilen kod oturumlarını Git commit’lerine otomatik olarak kaydeden bir eklenti; her commit’e karşılık gelen yapay zeka konuşma geçmişini git notes olarak saklıyor
Commit sırasında yapay zeka oturum kimliği belirtilirse, özet refs/notes/commits içinde, tam konuşma ise refs/notes/memento-full-audit içinde ayrı ayrı saklanarak izlenebilirlik ve gizlilik birlikte sağlanıyor
Codex ve Claude gibi çeşitli yapay zeka sağlayıcılarını destekliyor; özet üretiminde kullanıcı tanımlı skill’ler uygulanarak commit notlarının kalitesi kontrol edilebiliyor
GitHub Actions ile entegre çalışarak commit notlarına otomatik yorum ekleme, CI geçidi doğrulaması, birleştirme sırasında notların otomatik taşınması (merge-carry) işlevlerini sunuyor
Windows/macOS/Linux desteği var. Yapay zeka ile kod üretiminde şeffaflığı artıran ve ekip çalışmasında yapay zeka katkılarının denetlenebilirliğini (audit) mümkün kılan bir araç

git-memento genel bakış

git-memento, yapay zeka kodlama oturumlarını commit düzeyinde kaydeden bir Git eklentisi
- Commit sırasında yapay zeka oturumunun konuşma içeriğini düzenleyip Markdown notları olarak kaydediyor
- Her commit’te yapay zeka oturumunun kaynağı ve konuşma bağlamı bırakılarak kod üretim süreci izlenebilir hale geliyor
Varsayılan olarak Codex destekleniyor; Claude gibi diğer yapay zeka modelleri de yapılandırılabiliyor
MIT lisansı ile yayımlanıyor ve NativeAOT tabanlı tek bir çalıştırılabilir dosya olarak dağıtılıyor

Temel komutlar ve özellikler

git memento init ile depo bazlı yapılandırma başlatılıyor ve yapay zeka sağlayıcı bilgileri .git/config içine kaydediliyor
git memento commit komutuyla commit ile aynı anda oturum notu ekleniyor
- --summary-skill seçeneği kullanılırsa özet ve tam oturum ayrı ayrı saklanabiliyor
- Özet refs/notes/commits, tam günlük ise refs/notes/memento-full-audit içine yazılıyor
git memento amend, mevcut bir commit’e yeni bir oturum eklemeyi veya mevcut oturumu düzenlemeyi sağlıyor
git memento audit, belirli bir commit aralığında not eksiklerini ve meta veri geçerliliğini denetliyor
git memento doctor, yapılandırmayı, not referanslarını ve uzak senkronizasyon durumunu kontrol ediyor

Not yönetimi ve senkronizasyon

git memento share-notes ile notlar uzak depoya (origin vb.) push ediliyor
git memento notes-sync, uzak notları güvenli biçimde birleştiriyor ve yedek oluşturuyor
- Hem refs/notes/commits hem de refs/notes/memento-full-audit senkronize ediliyor
git memento notes-carry, rebase veya squash sonrası notları yeni commit’e taşıyor
git memento notes-rewrite-setup, otomatik not taşıma yapılandırmasını etkinleştiriyor

GitHub Actions entegrasyonu

Depoda yeniden kullanılabilir bir GitHub Action bulunuyor
- mode: comment — commit notlarını okuyup otomatik yorum yazıyor
- mode: gate — CI aşamasında not eksiklerini denetliyor, hata varsa build’i engelliyor
- mode: merge-carry — PR birleştirildiğinde notları merge commit’ine taşıyor
Her mod action.yml ile tanımlı ve Marketplace kaydı için artifact’ler (dist/note-comment-renderer.js) içeriliyor
ignore-notes etiketi eklenmiş PR’lerde geçit denetimi atlanıyor ve “Notes ignored” yorumu bırakılıyor

Not biçimi ve sürüm yönetimi

Notlar git notes add -f -m "" biçiminde saklanıyor
Çoklu oturum desteği için sürüm etiketi(``) ve bölüm ayraçları kullanılıyor
Kullanıcı mesajları Git kullanıcı adıyla, yapay zeka yanıtları ise sağlayıcı adıyla etiketleniyor
Mevcut tek oturumlu notlar gerektiğinde otomatik olarak yükseltilerek uyumluluk korunuyor

4 yorum

wedding 2026-03-03

Özel projelerde oturumu dışa aktarıp commit’liyorum; herkese açık projelerde ise yalnızca özet dosyasının gerçekten gerekli olduğuna karar verirsem commit’liyorum.
Sonuçta kişisel bilgiler de var... araca göre değişiyor ama oturum başına 10 MB’ı rahatça aşıyor... öylece yüklemek pek doğru gelmiyor.

roxie 2026-03-28

Ama artık disklerin her zamankinden daha ucuz olduğu bir çağda yaşıyoruz!

GN⁺ 2026-03-03

Hacker News görüşleri

Ben AI ile kod yazarken project.md dosyasıyla başlıyorum
Orada istediğim sonucu açıklıyorum ve AI'dan buna dayanarak plan.md yazmasını istiyorum
Sonrasında plan.md'yi defalarca düzenliyorum; istediğim plan tamamlanınca ayrıntılı bir todo listesi oluşturup plan.md'nin sonuna ekliyorum
Tamamen memnun kalınca AI'ya todo'ları uygulamasını, artık soru sormadan sonuna kadar ilerlemesini söylüyorum
Son olarak project.md, plan.md ve tüm kodu commit ediyorum
Böylece plan.md bir tür yeniden üretilebilir artefakt haline geliyor; daha sonra daha gelişmiş bir model bunun üzerinden değişiklik yapabilir veya hata bulabilir
- Ben de benzer yapıyorum ama üç belgeye ayırıyorum — design, plan, debug
  design'ı özellik bazında yazıyor ve çözümlenmemiş soruları açıkça belirtiyorum
  plan'ı plan/[feature]/phase-N-[description].md yapısıyla yönetiyor, derleme ya da çalıştırma sınırına çarpınca duruyorum
  debug aşamasında olası neden hipotezleri kurup, bunları logging/tracing ile doğruladıktan sonra düzeltiyorum
  Bu yöntemle hem yeni projelerde hem de legacy projelerde neredeyse %100 başarı elde ettim
  Dezavantajı çok fazla markdown dosyası birikmesi ama geçmiş kayıtlar gelecekteki değişiklikler için faydalı olduğu için henüz otomatikleştirmedim
- Bu, spec tabanlı bir yaklaşım gibi geliyor
  GitHub spec-kit'e bakmaya değer
- obra/superpowers'ın “brainstorming” özelliği neredeyse aynı iş akışı. Deneyince gerçekten harika
- Eskiden Beads'i bu şekilde kullanıyordum, sonrasında GuardRails yaptım
  Modele pazar araştırması ve öneri incelemesi yaptırıp yineledikçe, modelin kendi anlayabileceği dilde prompt tasarımı yapmış oluyorsunuz
  Son zamanlarda XML'in Claude'un davranışını etkilediğini öğrendim; bu yüzden GuardRails'in yapısını yeniden düşünüyorum
  Tanıtım yazısı bağlantısı
- Ben de benzer bir yapı kullanıyorum ama ayrı bir “context” dosyam var
  Plan tamamlanınca sonradan yanlış bir planı geri alırken başvurmak için “context.md” oluşturuyorum
  Henüz gerçekten kullanmam gerekmedi ama kavramsal olarak faydalı
  Yalnız bu dosyaları nereye koyacağım belirsiz olduğu için henüz repoya dahil etmiyorum
  Acaba siz bu tür iş bazlı md dosyalarını nereye kaydediyorsunuz, merak ediyorum
Bence bu, “her satırı commit etmeli miyiz?” sorunu gibi
Sonuçta asıl mesele kaydı kimin için tuttuğunuz
Çoğu oturum çok fazla gürültü içeriyor; hatalı denemeler ve gereksiz bilgilerle dolu
Önemli olan oturumun çıktısı, sürecin kendisi değil
Yine de ilk spec veya ilk prompt değerli olabilir. Bunu özetleyip commit mesajına ya da bir markdown dosyasına bırakmak iyi olur
- İnsanlar için karmaşık ve gürültülü olsa da bu tür oturum bilgileri gelecekteki AI için faydalı olabilir
  Geçmiş oturumları öğrenme bağlamı olarak kullanıp mevcut işi devam ettirmesini sağlayabilirsiniz
  Özellikle modelin sınırlarını anlamaya ve kodun kullanıcının niyetinden saptığı noktaları bulmaya yardımcı olabilir
  Sonuçta tüm insan girdisini kaydetmenin açık kaynak modellerin gelişimi için önemli olduğunu düşünüyorum
- “Her satırı commit etmek”ten çok, “tüm notları ve başarısız denemeleri saklayacak mıyız?” benzetmesi daha uygun gibi
- Bilimsel araştırmalarda da bu sorun zaten yaşanıyor — yeniden üretilebilirlik krizi
  İlk koşullar ve gürültü dahil olsa bile aynı sonucun çıkması gerekir
  Aksi halde gelecekte kod bakımı bir niyet tahmin oyununa dönüşür
  İlgili makale
- Şeffaflığın önemli olduğu bir kurumdaysanız denetim açısından değerli olabilir ama gerçekçi olalım, o uzun logları kim okuyacak
- Tüm oturumları saklamak gerekmeyebilir ama ayrıntılı düzenlemeler sırasında gereksinimlerin netleştiği anlar değerlidir
Bir hafta önce benzer bir fikir önermiştim (bağlantı)
Ama çok itiraz geldi — AI projeleri tek bir girdiden üretilmiyor, konuşmalı bir süreçten geçiyor ve bu yüzden kaynak kod gibi artefaktlaştırılması zor deniyordu
Yine de Show HN'de paylaşılan üretim projeleri o kadar çoğaldı ki gürültü ciddi bir sorun haline geldi
Tamamen dışlamak mümkün değil ama şu anki haliyle ilgim azalıyor
Topluluğun bu meseleyi nasıl ele alması gerektiğini düşünüyorum
- Ben Boris Tane'in Claude ile kod yazma yöntemini örnek alıyorum
  research.md ve plan.md'yi commit ediyor, bunları mimari ve özellikler için yaşayan sözlük olarak kullanıyorum
  Claude'un ilgili tasarımı hızla çağırabilmesi için özellik adını dosya adına önek olarak ekliyorum
  İlgili blog
- Sorun bağlam eksikliği değil, emek çıtasının düşmüş olması
  Eskiden ilginç olan projeler artık fazla kolay üretilebiliyor
  İnsanlara uzun oturum logları okutmak çözüm değil. Özetleme becerisi ve planlama yeteneği daha önemli hale geliyor
- Codex tüm oturumu markdown olarak dışa aktarabilse güzel olurdu
  vibe coding'in gerçek değeri deneme ve başarısızlık sürecini görebilmekte
- Ben de iki projeyi Show HN'de paylaşsam mı diye düşünüyorum
  Sadece sonucu koymaktansa üretim süreci ve açıklama olduğunda daha ilgi çekici oluyor
  Bu yüzden [Show HN]'den ayrı olarak [Creations] gibi bir kategori olsa iyi olurdu
  Örneğin: sıradan bir satranç motoru [Creations], 1k ile yapılmış bir satranç motoru ise [Show HN]
  PerfBoard ve Lerc buna örnek
Oturumlar sadece ara çıktıdır; nihai sonuca dahil edilmeleri gerekmez
Kod değişikliğinin nedeni önemliyse bunu commit mesajı veya dokümantasyonla anlatmak daha doğru
- Bu sonuçta bir özetleme problemi
  Commit anında gelecekteki okuyucunun hangi soruları soracağını bilemezsiniz
  Bu yüzden ben oturumu saklayıp daha sonra sorular üzerinden özet üretme yaklaşımını tercih ediyorum
  Git AI bu yaklaşımı kullanıyor
  Bugünün mühendisleri çok hızlı çalıştığı için bazen bir hafta sonra neden öyle yaptıklarını bile hatırlamıyorlar
- En azından oturumun özetlenmiş bir sürümü gerekli
  Araştırma tipi prompt'lar özetlenmeli, kod üretim tipi prompt'lar ise olduğu gibi saklanmalı
  Böylece yeniden üretilebilirlik ve incelenebilirlik sağlanır
- Eskiden ben de LLM'ye sadece commit mesajı yazdırıyordum ama artık plan dosyalarının sürüm kontrolünün daha iyi olduğunu düşünüyorum
  Plan, hata düzeltme sürecini de yansıtıyor ve sonraki iterasyonlarda işe yarayan bir belgeye dönüşüyor
- Benim durumumda repo, ajanın bellek deposu gibi
  Her repo birbirine mesaj göndererek özellik isteklerini yönetiyor
  Orijinal konuşmayı ve anlamca sıkıştırılmış belleği birlikte saklayarak spesifikasyonları ve gereksinimleri yeniden düzenliyorum
- Oturumları saklamak hata nedenini izleme veya sonradan analiz için de faydalı olabilir
Oturum logları çoğunlukla gürültü
Yanlış denemeler ve geri almalarla dolu; bunları commit'in yanına koymak tarayıcı geçmişini saklamaya benziyor
Önemli olan, niyeti ve kısıtları taşıyan commit mesajı
Kodu AI yazdıysa asıl mesele konuşma değil, neden öyle istendiği
Sonuçta sorun belki de oturum kaydetmek değil, commit mesajlarını ihmal etme alışkanlığıdır
AI kullansam bile geleneksel tasarım sürecini koruyorum
Gereksinimler → use case'ler → sınıf tasarımı → kısıtların tanımı → AI yürütmesi
Böylece insanın mimari muhakemesi korunurken AI tekrarlı uygulamayı hızlandırıyor
Oturum logları yerine bu tür UML/kısıt belgelerini commit'e eklerseniz niyet ve bağlamı daha net bırakabilirsiniz
Bence 2026'nın geliştiricisi böyle zarif bir işbirliği yapısını sürdürmeli
Bu, commit'leri squash edip etmemek meselesine benziyor
squash'ı tercih ediyorsanız sadece sonuç önemlidir ve süreci bırakmazsınız
Aksi durumda yolculuğun kendisini de kaydedersiniz
AI oturumları da benzer; düşünme sürecini debug etmek için faydalı olabilir ama temiz bir geçmiş sevenler bunu özellikle görmek istemez
Oturumları repo dışında ayrı yönetmek daha gerçekçi
- Ben de squash tarafındayım ama iç geçmişi açıp görebildiğiniz bir sistem olsa oturumları da görmek isterdim
  Mercurial veya Fossil'in bunu daha iyi yaptığı söyleniyor
- Bence en uygun benzetme bu
  vibe-coding'de kodun kendisinden çok prompt'lar düşüncenin izini gösteriyor
  Git'e koyup koymamak ayrı mesele ama erişilebilir bırakmanın değeri var
- İnsan yönlendirmeli geliştirmede AI sadece bir araçtır
  Bu durumda gerçek zamanlı süreci görmeye gerek yok
  Ama kod tamamen AI tarafından yazıldıysa prompt'ların açıklanması gerekir
Ben de oturumları dışa aktarmayı denedim
Bir miktar bilgi kaybı riski olsa da okunabilirlik ve erişilebilirlik çok daha iyi oluyor
En azından oturumun özetlenmiş prompt'larını saklamak gerektiğini düşünüyorum
AI kod incelemesi insan kadar sıkı değil ve niyet yalnızca prompt'ta yer alıyor
Aksi halde aynı hataları tekrar edersiniz
Kod incelemesinin değeri öğrenme ve gelişimdedir; AI öğrenmediği için bu rolü prompt kaydı üstlenmeli
Ayrıca prompt becerisi değerlendirmesi veya junior eğitimi için de gerekli
- Ama bunun “apaçık” olduğu fikrine katılmıyorum
  Tuş vuruşlarını, menü tıklamalarını ya da debug denemelerini de commit'e koymuyoruz
  Tüm konuşmaları saklamak fazla gürültü üretir
  Bunun yerine niyet ve varsayımları içeren belgeler bırakmak daha gerçekçi
- Bu arada, oturum boyutunun ne kadar olduğunu düşündüğünüzü de merak ediyorum
Bu, “Google arama geçmişini commit'e dahil etmeli miyiz?” sorusuyla aynı — kesinlikle hayır derim
- Mükemmel bir benzetme. Düşüncenin her parçasını kaydetmekte sinyal/gürültü oranı çok kötü
  Bunun yerine sadece gerekçeleri, varsayımları ve alternatiflerin özetini bırakmak daha iyi
- Ama oturumları saklarsanız AI'nın yaptığı arama sorguları ve sonuçları da birlikte korunur; bu da proje bağlamı için yararlı olabilir
- Kimse bir div'i ortalamak için kaç kez arama yapıldığını bilmek istemez
  Aynı şekilde modelin önemsiz sorunlarda debelendiği loglar da gereksiz
- Üstelik her arama da commit'le ilgili olmaz. Hassas bilgiler de içerebilir