Kodlama ajanını `while` döngüsüne koyunca bir gecede 6 depo tamamlandı

 (github.com/repomirrorhq)
18 puan yazan GN⁺ 2025-08-25 | 2 yorum | WhatsApp'ta paylaş
  • Claude Code headless yöntemle sonsuz döngüye alındığında, 1000'i aşkın commit ve birkaç kod tabanının port edilmesi sonucu üretildi
  • Bu yöntemle assistant-ui React projesini Vue'ya, Python projesini TypeScript'e otomatik dönüştürmek gibi çeşitli başarılı port deneyimleri elde edildi
  • Prompt'ları basit tutmanın performansı artırdığı, karmaşık hale getirmenin ise verimsizliği büyüttüğü görüldü
  • Kusursuz olmasa da, kaynak/hedef depo senkronizasyonu için yararlı bir araç olan RepoMirror da birlikte geliştirildi
  • Yapay zeka ajanının kendini durdurması, göreve ek işler eklemesi gibi beklenmedik davranışlar ve öğrenimler de gözlemlenerek, gelecekteki otomasyonun hem olasılıkları hem de sınırları hissedildi

Projenin genel görünümü ve amacı

  • Bu proje, bir AI kodlama ajanını (Coding Agent) sonsuz bir while döngüsüne koyarak gerçek kod port etme işini nasıl yürüttüğünü deneysel olarak inceliyor
  • Claude Code, headless şekilde çalıştırılıp giriş prompt'u sürekli tekrar edilerek çeşitli depolarda otomatik dönüştürme sürecine uygulandı
  • 1000'den fazla commit, React'tan Vue'ya, Python'dan TypeScript'e gibi birden çok port etme işinin otomasyonu sonucu elde edildi
  • Süreç boyunca port otomasyonunu destekleyen RepoMirror aracı da geliştirildi

Sonsuz döngü yöntemiyle ajan çalıştırma

  • Geoff Huntley'nin önerdiği, kodlama ajanı prompt'unu shell içinde art arda çalıştırma biçimi
    • Örnek: while :; do cat prompt.md | claude -p --dangerously-skip-permissions; done
  • assistant-ui'nin React'ten Vue'ya çevrilmesi gibi işlerde bu döngü yöntemi uygulandı
    • Her dosya değişikliğinde commit ve push çalıştırıldı
    • İş kayıtları ve planlar .agent/ dizinine yazıldı

Çeşitli port etme vakalarının denenmesi

  • Browser Use (Python'dan TypeScript'e port)

    • basit prompt ile sonsuz döngü çalıştırıldı
    • GCP VM üzerinde tmux ile döngü sürekli çalıştırıldı
    • Sabah neredeyse kusursuz çalışan bir TypeScript port sonucu görüldü

  • Vercel AI SDK için TypeScript → Python portu da uygulandı

    • FastAPI/Flask otomatik adaptörleri oluşturuldu
    • Python'daki çeşitli schema validator'lara dönüşüm desteği de sağlandı

  • Spesifikasyona dayalı kod otomasyonu: Convex, Dedalus gibi projelerde belgelerden doğrudan kod üretimi de denendi

Deney sırasında ortaya çıkan durumlar ve çıkarımlar

Ajanın test yazması ve kendini durdurması

  • Ajan, verilen komutlara göre test kodu da yazdı
  • Sonsuz döngüye girdiğinde veya görev tamamlandığında süreçleri pkill ile kendi kendine sonlandırdığı durumlar da oldu
  • İş kapsamına sıkı uydu ve tamamlanma seviyesini TODO.md içinde tekrar tekrar kaydetti

Ek ortaya çıkan davranışlar

  • Port işi bittikten sonra, özgün JS sürümünde olmayan FastAPI/Flask entegrasyonu, schema validator desteği gibi ek özellikleri kendi inisiyatifiyle ekledi

Prompt sadeleştirmenin önemi

  • Kısa ve basit prompt'lar daha iyi performans gösterdi
  • 103 karakterlik bir prompt 1500 karaktere çıkarıldığında yavaşlama ve doğruluk düşüşü görüldü
  • Gerçekte kullanılan prompt bilgileri için prompts klasörüne bakılabilir

Tam otomasyonun sınırları

  • Belirgin sorun: zaman zaman tam çalışmayan port edilmiş kod üretmesi (bazı tarayıcı demolarının eksik kalması gibi)
  • Prompt düzeltmesi ve etkileşimli düzenleme gerekti

Altyapı/maliyet ve operasyon

  • Yaklaşık maliyet $800, toplam 1100 commit, ajan başına yaklaşık $10.50/saat düzeyi
  • Birden fazla kaynak/hedef depo port sürecini otomatikleştiren bir araç anlık olarak geliştirildi (RepoMirror)
    • shadcn tarzı open-box ilkesi uygulandı; init adımından sonra script ve prompt'ların özelleştirilebileceği klasörler oluşturuldu
    • npx repomirror sync ve sync-forever ile tekrarlı çalıştırma desteklendi

Aracın kullanımı ve değerlendirme biçimi

  • npx repomirror init ile kaynak/hedef dizinleri belirtilip komut girilerek ilk kurulum yapılıyor
    • Örn.) React → Vue, gRPC → REST dönüşümleri gibi yeni komutlar kolayca uygulanabiliyor
  • Klasör yapısı:
    • .repomirror/prompt.md, sync.sh, ralph.sh gibi başlangıç dosyaları otomatik oluşturuluyor
  • Her yinelemede sync/sync-forever çalıştırılarak AI port döngüsü işletiliyor
  • Ana örnekler, demo sonuçları ve kaynak kod depoları README içinde görülebiliyor

Deney sonrası izlenimler ve ekip geri bildirimi

AGI'yi (genel yapay zeka) somut olarak hissettirdi ve buna çoğunlukla heyecan ile biraz korku eşlik etti

Sadelik etkili; bunu doğrudan deneyimleyebildik

Şu an üstel büyüme eğrisinin çok erken bir aşamasında olduğumuz hissi var

  • Ekip üyelerine ve fikir sağlayanlara teşekkür edildi

Sonuç

  • Sonsuz döngü tabanlı AI kodlama ajanıyla gerçek kaynak kod port etme ve senkronizasyon işlerinin pratikte mümkün olduğu deneyimlendi
  • Basit yapı ve etkili prompt kullanımının önemi vurgulandı
  • Otomasyonun gelecekteki potansiyeli ve sınırları birlikte ortaya çıktı
  • İlgili araç olan RepoMirror, açık kaynak biçiminde kullanılabilir ve araştırılabilir

İlgili okumalar

2 yorum

 
GN⁺ 2025-08-25
Hacker News görüşleri
  • İleride yazılım mühendisleri için mevcut legacy kod bakımı ile tehlikeli saha temizliğinin birleştiği yeni bir iş türü doğacak gibi geliyor; örneğin geçmişte FoxPro, Excel, Access vb. ile yamalı bohça gibi yapılmış ERP’leri “bir şekilde düzeltin” talebi çok olurdu. Ama bundan sonra satış ekipleri Excel/Access gibi sandbox kısıtlarından çıkıp, çoklu bulut ve edge üzerinde dağıtılmış Kubernetes mikroservislerini Kafka ile birbirine bağlayıp kafalarına göre çalıştırabilecek. O sırada niyetin ne olduğunu anlamaya çalışsanız bile soracak kimse kalmayacak
    • Bu anlatımı görünce, bir kişinin statik site deploy etmek isteyip Hacker News’te yazılmış bir rehberi takip ettiğini hayal ediyorum
    • Ayrıca o zamanki niyeti artık kimse bilmiyorsa, AI tabanlı araçların büyük zayıflığı da ortaya çıkıyor; sonunda kara kutuya dönüştüğünde insanlar ya tamir etmek ya da baştan yapmak zorunda kalıyor. Tabii teorik olarak AI araçlarının sürekli daha iyi olacağı beklentisi de var. İleride vibe-coded yazılımlarla gelir elde eden örnekleri modele verip iyileştirme yapmak da mümkün olabilir, ama ben böyle sihirli ya da kara kutu sistemleri pek tercih etmiyorum
    • Eğer Claude Kafka cluster deploy etmeye de başlarsa elimi eteğimi çekerim
    • AI’nın DB içindeki veriyi anlayıp daha iyi tasarlanmış bir veritabanına taşımasının bir yolu olup olmadığını merak ediyorum. Ben “güçlü veri yapıları + basit algoritmalar” felsefesine katılıyorum; verinin uygulamadan daha uzun ömürlü olabilmesi benim için önemli. Örneğin MongoDB’de int ile string değerleri karışık saklamak, Postgres’te foreign key olmadan ilişki kurmak, alter table yapılamadığı için doğrudan yeni tablo açmak gibi verimsiz durumlar gördüm
    • Böyle projelerin kodu adeta bir Superfund (büyük ölçekli çevresel temizleme projesi) deposu gibi hissettiriyor
  • Yazılım geliştirme sürecinde her zaman iki ana çıktı kalır: biri koddaki değişimdir, diğeri ise ister kodu doğrudan yazmış ister LLM kullanmış olsun, geliştiricinin bilişsel değişimidir. Python ve Typescript, binlerce geliştiricinin uzun yıllar boyunca emek vererek oluşturduğu sofistike resmî dillerdir ve aralarındaki farklar basit değildir. Bir dildeki kütüphaneyi başka bir dile yarı otomatik şekilde port edebilmek etkileyici. Ama ekonomik açıdan bakınca “ajan” tabanlı iş akışları başlangıçtaki bilişsel gereksinimi kökten değiştiriyor. LLM ile kod ürettiren geliştiriciler, o koda onu bizzat yazmış kişilerden tamamen farklı bir aşinalık geliştiriyor. Bazen bunun ekonomik olarak büyük bir sorun olmadığı söylenebilir ama bana göre kodun ekonomik değeri, o kodu gerçekten yazma deneyimine sahip insanların bir topluluğunun bulunmasına bağlı. Bu gerçeği inkâr eden kültür, LLM’lerden önce de sorundu. Ekip değişimleri yüzünden kimsenin bakım yapamadığı kod tabanlarının şirketin geleceğini riske attığı çok örnek vardı
    • Peter Naur’un 1985 tarihli klasik makalesi “Programming as Theory Building” bu konuda faydalı bir referans olabilir https://pages.cs.wisc.edu/~remzi/Naur.pdf
    • Ben bu bağlamı daha önce “harita arazinin kendisi değildir” benzetmesiyle açıklamıştım. Kod haritaysa, çözülmesi gereken problem alanına dair geliştiricinin zihinsel modeli de arazidir. Ancak LLM’ler çok sayıda kod tabanını okumakta son derece güçlü olduğu için, kod tabanını 3D görselleştirmek gibi tartışmalar bile anlamsız hale gelebilir. Karmaşık bir kod tabanını anlamak kolaylaşırsa, geliştiricinin zihinsel modeliyle kodu sürekli senkron tutma ihtiyacı bile ortadan kalkabilir. Bu açık bir soru https://divan.dev/posts/visual_programming_go/
    • Bence LLM’lerin asıl gücü kod okuma tarafında. Araçların dokümantasyon ve kod açıklaması konusunda yazmaktan daha iyi olduğunu düşünüyorum. Sorular sorup kodu hızlıca kavrayabiliyorsanız, eski geliştiricilere gerçekten ihtiyaç kalıyor mu diye insan merak ediyor. Teknik stack’i bilen biri doğru soruları sorup hızla anlayabiliyorsa, orijinal yazarın mutlaka kalması gerekir mi?
    • “Kodun ekonomik değeri, onu yazma deneyimi olan insanların topluluğuna bağlıdır” sözü bana yazılım mühendisliğindeki şu özdeyişi hatırlatıyor: yazılım, o andaki problem anlayışının bir anlık görüntüsüdür ve kod, gelecekteki size de “o zaman bu probleme böyle yaklaşmıştık ve bu mantıkla çözmüştük” diyen bir açıklama metni bırakır
    • LLM’ler sayesinde bir kod tabanının zihinsel modelini oluşturmak çok daha kolaylaştı gibi geliyor. İstediğiniz alt sistem hakkında soru sorunca ilgili dosyaları, kod parçalarını ve kavramları hemen işaret ediyor. Ben örneğin CPython’daki GIL’in nasıl çalıştığını LLM’e sorup ilgili API’leri ve örnekleri hemen öğrendim; sonra koda bakınca doğrudan anlayabildim. Eskiden bunu tek başıma kod okuyarak çözmek uzun sürerdi, şimdi ise birkaç dakikada bitiyor; en büyük fark bu
  • Port işlemi bittikten sonra ajanların çoğu ek testler yazmış ya da agent/TODO.md dosyasını sürekli güncelleyerek ilerleme durumunu bırakmıştı. Bir ajanın sonsuz döngüye girdiğini fark edip pkill komutuyla kendini sonlandırdığı da olmuş. Her açıdan çok ilginç bir olay. Bu proje hakkında birkaç düşüncem var: 1,5 yıl önce de benzer bir deneme vardı ama o zaman GPT-3.5/4 tabanlı yaklaşım neredeyse hiç çalışmıyordu; bu kez sonuç çok daha iyiydi. Bu kadar basit bir prompt’la iyi çalışması şaşırtıcı. Belki de hepimiz işi gereğinden fazla karmaşık düşünüyorduk. Öte yandan telif/IP meselesi epey karmaşıklaşacak gibi görünüyor. SaaS şirketleri için bu akım darbe niteliğinde. Bu teknolojiye orta ölçekli bir şirketteki 10 mühendis de eklenince, şirket içi geliştirme (=NIH sendromu) için güçlü bir gerekçe doğuyor
    • Bir ajanın sonsuz döngüden çıkmak için kendini pkill ile kapatmış olması, AI’nin ilk “intihar” vakası sayılır mı diye düşündürüyor
    • LLM’leri bir Bitcoin mixer gibi fikrî mülkiyet (IP) işlemede kullanabilme fikri bizi tuhaf bir alana sokuyor, https://ghuntley.com/z80 bunun ne anlama geldiğini ele alıyor. Yani mevcut bir eseri spesifikasyona dönüştürüp temiz IP ile yeniden üretebiliyorsunuz; %100 değil ama insan çalıştırmaktan daha verimli
    • NIH sendromu yorumu tam yerine oturuyor bence. Bütün SaaS araçları artık bitti ve kendi yazılmış, kurum içi yönetilen monolitler geri mi dönüyor diye düşündürüyor. Tarihsel olarak Unix’in "küçük ve keskin araçlar" felsefesi sona mı eriyor? x86 dönemindeki her şeyi kendin yap yaklaşımının son safhası olabilir
    • Ajanın pkill ile kendini sonlandırması, acaba Halting Problem’i çözdü mü diye espri bile yapılıyor
    • Çeşitli mevcut açık kaynak projelerle entegrasyon kurmaya çalışırken vazgeçip, Claude’a sadece gereken kısımları seçtirip doğrudan port ettirince iş çok daha hızlı ve temiz bitti. Artık “bağımlılıkları takip etmeye gerçekten gerek var mı? Benim için sadece istediğim çekirdek parçalar mı değerli? Bu proje iyi bakılıyor mu?” diye düşünüp, değilse doğrudan port edip unutma gibi yeni bir alışkanlık gelişiyor
  • Güvenlik uzmanı açısından vibe-coded facialardan para kazanılabiliyor olması nedeniyle, bu eğilim sürerse gözümün önünde çizgi filmdeki gibi dolar işaretleri dönüyor
    • vibe coding kavramı sadece 5 ay önce ortaya çıkmış bir yeni kelimeyken, piyasa nasıl bu kadar hızlı doygunlaşıp toparlama uzmanlığı bile çıkardı diye merak ediyorum
    • Bu pazara fiilen nasıl girdiğinizi, kişisel deneyimleri ya da vibe-coded sistemlerin nasıl patladığını dinlemek isterim; böyle örnekler gerçekçi ve eğlenceli olurdu
    • LLM’lerin, yeni mezunlardan oluşan bir ekiple karşılaştırıldığında güvenlik açısından daha mı iyi yoksa daha mı kötü olduğunu da merak ediyorum
  • Çok sayıda “neredeyse başarılı oldu” yorumu görüyorum. Gerçekten iyi çalışan bir sistem istiyorsanız bence tamamen yeni bir süreç gerekiyor. Tek çağrıda “neredeyse düzgün kod” çıkıyorsa, tekrarlandığında da sadece daha fazla “neredeyse düzgün kod” birikiyor. Muhtemelen AI’nin başvuracağı, Cucumber tarzı örnek tablo tabanlı bir gereksinim formatı oluşturmak gerekir; ardından AI önce testleri yazmalı, sonra o testleri geçecek kodu üretmeli
    • Garip gelebilir ama TLA+ gibi resmî ispat temelli yaklaşımlar Ralph’i çok iyi çalıştırıyor
  • Ralph hakkında daha fazlası https://ghuntley.com/ralph adresinde var; şu sıralar Gen-Z kuşağını hedefleyen tuhaf bir programlama dili olan Cursed’in standart kütüphanesini Go’dan port ediyor. Derleyici çalışıyor ve standart kütüphane biter bitmez açık olacak. Dilin adı Cursed
    • Teşekkürler, Ralph’in doğrudan bizim projeye ilham verdiğini belirtelim. Böyle bir iş yaparken IMPLEMENTATION_PLAN.md olmadan da olur mu diye merak etmiştim
  • https://gist.github.com/eisbaw/8edc58bf5e6f9e19418b2c00526ccbe0 ile kod üretip https://github.com/eisbaw/CMake-Nix projesini yayınladım ve çalışıyor
  • Son zamanlarda aklıma takılan bir alıntı var: “Bu iş kontrolden çıkacak ve biz sadece hayatta kalırsak şanslı sayılacağız”, https://www.youtube.com/watch?v=YZuMe5RvxPQ&t=22s
    • İşin ironik tarafı, o zaman da herkes hayatta kaldı; demek ki sonunda biz de bu durumu atlatacağız
  • Bu alandaki insanlar gerçekten tuhaf. İlham veren blog yazısında, sanki şüpheli bir yatırım dolandırıcılığının Facebook reklamında göreceğiniz türden iMessage ekran görüntüleri var https://ghuntley.com/ralph/. Geoff’in bu yöntemini öğrenen birinin 50.000 dolarlık projeyi 297 dolara bitirdiği havası veriliyor; üstüne bir de “gizli prompt”u ücretsiz paylaşacağız, yeter ki bültene abone olun deniyor. Gerçekten inanılmaz
    • https://archive.ph/goxZg bağlantısını da ekliyorum
    • Tam anlamıyla growth hacking, hatta düpedüz dolandırıcılık gibi geliyor. Blog seviyesi korkunç derecede düşük sinyal/yüksek gürültü ve AI tarafından yazıldığı çok belli olduğu için itici geliyor
    • Bunun gerçekten işe yarayan bir teknik mi, şaka mı, yoksa cüretkâr bir dolandırıcılık mı olduğunu ayırt edemiyorum. Genel olarak blogun üslubu ve içeriği kibirden doğmuş dağınık bir gevezelik hissi veriyor
  • Görünüşe göre AGI için de sonunda tek gereken bir bash for loop imiş; çılgın bir proje
    • Şaka bir yana, insan gerçekten öyle düşünüyor. Belki ben fazla temkinliyim ama prompt kapsamı geniş, yetkileri fazla ya da privilege escalation yolu olan bir ajan sürekli döngüye girerse, AGI olmasa bile steroid almış bir virüs kadar tehlikeli bir şey ortaya çıkabilir diye düşünüyorum. Utility gibi temel kaynakları bile yok edebilir diye hayal ediyorum. Belki ben yanlış anlıyorum ama bu modeller sonsuz döngüde kalıp kötü niyetli ayrıcalıklara da sahipse, hayal edilenden büyük bir kaos yaratma potansiyeline sahipler
    • Sadece ID.md, EGO.md, SUPEREGO.md dosyalarını eklemek yeterli olur diye yapılan bir şaka
    • Birçok açıdan fazlasıyla tedirgin edici
 
kjows5 2025-08-27

LLM'in yazdığı kodun bir kara kutuya dönüşmesi endişesine katılıyorum; ama sonuçta o kodu analiz etme işini de LLM'e bırakamaz mıyız?