Ajanlarla Birlikte Nasıl Programlanır

• Bu yazı, mevcut programlama deneyimini konuşmalı bilgisayarlar (LLM, ajanlar) dünyasına uyarlama sürecini ele alan ikinci bölüm.
• İlk bölüm olan "LLM ile Nasıl Programlanır" yazısında, LLM’lerin mevcut araçlara entegre edilerek otomatik tamamlama ya da arama yerine kullanılması anlatılıyordu.
• Bu kez, biraz daha zor ama daha ödüllendirici olan ajan tabanlı programlama konusunda pratik deneyim ve içgörüler paylaşılıyor.

Ajanın tanımı ve pratikteki karşılığı

• LLM (büyük dil modeli) bağlamında "ajan" terimini tanımlamak anlamlı.
• Bu terim uzun süredir yapay zeka sektörünün moda kelimelerinden biri olarak kullanılıyor, ancak gerçekten işe yarar bir yapı haline gelmesi yakın zamanda oldu.
• Bu süreçte üzerine çok sayıda pazarlama söylemi ve gizem havası eklendi.

• Bir mühendisin gözünden bakınca artık bunu açık ve basit şekilde tanımlamak mümkün: ajan 9 satırlık bir kod, yani içinde LLM çağrısı bulunan bir for döngüsü.
• Bu döngü içinde LLM komutları yürütür, sonuçları doğrudan kontrol edebilir ve insan müdahalesi olmadan tekrarlı biçimde çalışır.
• Basit görünebilir, ancak pratikte bu yapı kurulduğunda yalnızca saf LLM kullanmaya kıyasla programlama yeteneği sıçrama yapar.

Beyaz tahta programlaması ile ajanların farkı

• Bir beyaz tahta karşısında durup marker ile C dilinde UTF-8 dizgelerinin geçerliliğini kontrol eden bir fonksiyon yazdığınızı varsayalım.
  • (Yazarın gerçekten yaşadığı bir mülakat durumu ve yaygın bir görüşme görevi.)
  • Bu işin başarıyla sonuçlanması, programcı olarak deneyiminize ve dış kaynaklara bakamama kısıtını ne kadar iyi idare edebildiğinize bağlıdır.
  • UTF-8 kodlama kurallarını hatırlamanız gerekir ve C sözdizimini başka C ailesi dilleriyle karıştırmamaya dikkat etmelisiniz (isim-tür, tür-isim sırası gibi).
  • Oysa günlük hayatta kodu doğrulamak ve hataları bulmak için derleyici geri bildirimi, doküman arama, printfler gibi birçok yöntem kullanabilirsiniz.
• LLM’ye ajansız biçimde kod yazdırmak, beyaz tahtada dış yardım olmadan kod yazmaya benzer.
  • Belirsiz anıları geri çağırmak, verimsiz biçimde sözdizimini tutturmaya çalışmak ve hayali arayüzler uydurma hatasından kaçınmak gerekir.
  • LLM’nin tamamen yeni bir program üretebilmesi teknik olarak etkileyici olsa da, GPU’ya bağlı sanal bir beyaz tahta tek başına gerçek programlama verimliliğini çok artırmaz.
• Peki LLM’ye sanal beyaz tahtadan fazlası verilirse?
  • Örneğin derleyiciyi çağırıp derleme hatalarını görmesine ve kendisinin düzeltmesine izin verilirse?
  • grep, cat ile mevcut dosyaları okuyup, birden fazla dosyayı (birim testler dahil) yamalayarak tekrar tekrar test edebilse?
• Ajan tam olarak böyle, geri bildirim temelli çalışan bir LLM’dir.

Ajan = geri bildirim ortamında çalışan LLM

• İnsan gibi geri bildirim ortamında iyi çalışan bir LLM, yalnızca birkaç tanıdık araçla bile pratik programlama yeteneği gösterebilir.
  • bash(cmd): terminal komutu çalıştırma (find, cat, grep vb.)
  • patch(hunks): dosya yamalama, kod değişikliği uygulama
  • todo(tasks): görev listesi yönetimi
  • web_nav(url), web_eval(script), web_logs(), web_screenshot() vb.: web gezintisi, değerlendirme, log, ekran görüntüsü vb.
  • keyword_search(keywords): anahtar kelime araması
  • codereview(): kod inceleme
• bash aracını kullanarak kod tabanını verimli biçimde keşfeder, git add/commit gibi sürüm kontrol işlemlerini de otomatikleştirir.
• Bu araçlar olmadan yalnızca kod üreten LLM’lerden farklı olarak, ajanların şu belirgin avantajları vardır:
  • API kullanım doğruluğu büyük ölçüde artar (doküman arama ve bağlama doğrudan yansıtma sayesinde)
  • Derleyici geri bildirimi ile sözdizimi hataları ve arayüz yanlışları azalır
  • Bağımlılık/sürüm yönetimi becerisi güçlenir (belirli sürüm özelliklerini kavrayabilir)
  • Test başarısızlıkları üzerinden hata tespiti ve test kodu yazma alışkanlığı güçlenir
  • Bağlam penceresi sınırını aşan kod tabanı işleme mümkün olur (yalnızca gerekli bölümleri seçerek okur)
  • Çalışma sonuçlarını doğrudan deneyebilir: kodu çalıştırır, tarayıcı ekran görüntüsünden geri bildirim alır, CSS’i otomatik ayarlar, sunucu loglarıyla hatayı izler ve test ekler
• Dezavantajlar da var.
  • Tek cümlelik bir istek için on binlerce ara token üretilebilir (araç çağrıları, web araması, test döngüleri vb.) ve iş birkaç dakika veya daha uzun sürebilir
  • API çağrısı maliyeti de vardır, ancak donanım gelişimiyle zamanla azalması beklenir
• Sonuçta aradaki emeği CPU/GPU üstlenir, geliştiricinin zamanını boşaltır ve yapmak istediği daha fazla programı tamamlamasını sağlar.
• Pratikte bir projeye ajan ekleyip küçük görevler vererek sonuçları kontrol etmek kolaydır.

Örnek: Github App kimlik doğrulaması geliştirme

• Bu, ajan kullanarak sketch.dev’in Github App kimlik doğrulama akışını uygulamaya alan gerçek bir örnek.
  • Yalnızca 3-4 geri bildirim turuyla tüm kimlik doğrulama akışı hızlıca tamamlandı.
  • Hata ya da gereksinim bulunduğunda kısa bir cümleyle anlatmak yeterli oldu; ajan hemen kodu ve davranışı iyileştirdi.
  • Tekrarlayan ve sıkıcı API entegrasyonu işleri, build sistemi/paket yönetimi/kütüphane kurulumu gibi gerçek iş hayatının "angaryalarını" azaltarak üretkenlik ivmesini korumaya büyük katkı sağladı.
• İlk gereksinimlerden biri, "kullanıcı bazlı token saklamadan yalnızca uygulamanın global kimlik bilgilerini kullanmak" oldu ve ajan bunu yansıtarak uyguladı.
  • Ancak bunun sonucunda ciddi bir güvenlik açığı oluştu (herkes tüm depoları görebiliyordu).
  • Sorun tek cümleyle geri bildirim olarak verilince, ajan hemen kullanıcı bazlı yetki kontrolü ekleyip düzeltilmiş bir commit oluşturdu.
• Sonrasında performans sorunu ortaya çıktı.
  • Aşağıdaki yapı nedeniyle tüm kullanıcı-depo kombinasyonları için API çağrısı yapılıyor ve bu da ölçeklenebilirlik sorunu yaratıyordu.

    for install := range allAppInstallations {  
    	for r := range install.Repositories() {  
    		if r.IsCollaborator(user) {  
    			// add to available repositories  
    		}  
    	}  
    }  
    

  • Bu sorunun kök nedeninin, "kullanıcı bazlı token saklamama" yönündeki kendi gereksinimi olduğu fark edildi.
  • Gereksinim değiştirildiğinde (kullanıcı bazlı token saklamaya izin verilince), ajan sistemi daha verimli API çağrılarıyla yeniden tasarladı.
• Aslında bu süreci yazıyla anlatmak için kullanılan kelime sayısı, Sketch’te kimlik doğrulama kodunu almak için girilen toplam kelime sayısından daha fazlaydı.
• Kısacası, ajanlar bugün için geliştiricilerin yerini alabilecek düzeyde değil; ama geleneksel olarak günler süren tekrarlı işleri bir güne indirmeye yardımcı oluyor.
• Otomasyon öyle bir düzeye gelebiliyor ki geliştirici "çocuğun odasını toplarken" bile işi ilerletebiliyor.

Örnek: JSON tabanlı SQL kurallarının uygulanması

• Ajanların sık yaptığı işlerden biri olarak, Tailscale’de öğrenilen sıra dışı bir SQL stilinin uygulanması gerekiyordu.
  • Tüm tablolarda gerçek sütun yalnızca bir tane (JSON veri) ve diğer sütunlar JSON’dan türetilen generated column olarak ele alınıyor.
  • Örnek tablo yapısı:

    CREATE TABLE IF NOT EXISTS Cookie (  
      Cookie   TEXT    NOT NULL AS (Data->>'cookie')  STORED UNIQUE, -- PK  
      UserID   INTEGER NOT NULL AS (Data->>'user_id') STORED REFERENCES User (UserID),  
      Created  INTEGER NOT NULL AS (unixepoch(Data->>'created')) STORED,  
      LastUsed INTEGER AS (unixepoch(Data->>'last_used')) CHECK (LastUsed>0),  
      Data     JSONB   NOT NULL  
    );  
    

  • Bu yaklaşım bir tür poor man’s ORM işlevi görüyor; şemayı genişletmeyi kolaylaştırıyor ve SQL kısıtları JSON veri kalitesini doğrulamaya yardımcı oluyor.
  • Dezavantajı ise satır başına depolanan verinin artması ve tüm INSERT/UPDATE işlemlerinin JSON birimi üzerinden yapılmak zorunda olması.
• Ancak ajan bu stili her zaman tutarlı biçimde izleyemedi.
  • Yeni tablo oluştururken genelde iyi uyuyordu, ama istisnalar olduğunda kafası karışıyor ya da stili keyfi biçimde değiştiriyordu.
• Basit çözüm: SQL şema dosyasının başına 3 cümlelik bir açıklama eklemek.
  • "Her tablonun yalnızca gerçek bir Data JSON sütunu vardır, diğer tüm sütunlar bundan türetilir" gibi anahtar bir cümle eklendi.
  • Bu kurala uymayan tablolarda da bunun istisna olduğu ayrı yorumlarla belirtildi.
  • Sonrasında ajanın davranışı gözle görülür biçimde iyileşti.
• İlginç olan, bu tür açıklama ve yorumların gerçek insan mühendisler tarafından çoğu zaman görmezden gelinmesi ya da düşük faydalı bulunması;
  • buna karşılık LLM tabanlı ajanlar yorumları ve açıklamaları kod yazarken aktif biçimde dikkate alıyor
  • yalnızca iyi açıklama yazmak bile kod üretim kalitesini belirgin biçimde artırıyor

“Varlık” ve “borç” kod modeli

• LLM tabanlı kod üretim araçlarına yönelik yaygın eleştirilerden biri, kod üretiminin toplam yazılım maliyetinin yalnızca çok küçük bir parçası olmasıdır.
  • Asıl zaman, mevcut kodun bağımlılıklarını, iç içe geçmiş yapısını ve karmaşık arayüzlerini yönetmeye gider.
  • Büyük ölçekli, eski ve çok kullanıcılı ürünlerde bakım maliyeti ezici ölçüde yüksektir.
  • Böyle bir ortamda LLM’ye "Fortran ile bubble sort yaz" demek oyuncak gibi ya da rahatsız edici bir dikkat dağıtıcı gibi gelebilir.
  • Finanstaki "varlık/borç" kavramıyla kıyaslayan tartışmalar da vardır, ancak bu da tam oturmaz.
• Ancak tüm yazılım mühendisliği yalnızca bu tür büyük ve uzun ömürlü projelerden ibaret değildir.
  • Programların çoğu az sayıda kullanıcıya hizmet eder ya da kısa ömürlü projelerdir.
  • Büyük bakım tecrübelerini tüm sektörün özüymüş gibi genellememek gerekir.
• Ajanların değeri yalnızca kod üretimiyle sınırlı değildir.
  • Ajanlar, çeşitli araçları ve LLM’leri birleştirerek kod okuma, dosya düzenleme, kod silme/değiştirme gibi değişimin kendisini otomatikleştirir.
  • Yalnızca kod eklemek değil, kod silme/refactor etme de doğal biçimde yapılabilir.
• Sonuçta mühendisin hedefi değişimdir (change).
  • Değişim sürecinde sürücünün yapılan değişikliği anlaması için ek çaba gerekse de, ajanlar orta ölçekli projelere kadar kademeli değişim üretme kapasitesi gösteriyor.
  • Bugün henüz yeterli olmasa da, ajanlar doğru yönde hızla gelişiyor.
• Ayrıca karmaşık dillerin ve build sistemlerinin projeye giriş eşiği oluşturduğu yönünde bir görüş de var.
  • Kolay kod yazdıran araçların (LMM, type safety, garbage collection, package management, ajanlar vb.) bu eşiği düşürmesi halinde kalitenin düşeceği endişesi dile getiriliyor.
  • Eğer amaç değişim hızını yavaşlatmak ya da kontrolü sıkılaştırmaksa, ajan gibi otomasyon araçları uygun olmayabilir.

Neden ajanlar şimdi?

• Transformer gibi karmaşık yapay zeka ilkelerinin aksine, LLM’ye geri bildirim döngüsü eklemek sezgisel olarak çok açık bir yaklaşım.
  • Geliştirici araçları üzerine düşünen biri için bu doğal bir evrim yönü gibi görünüyor.
  • Nitekim bir yıl önce sketch.dev’in ilk sürümü de LLM’ye yalnızca go aracının bağlandığı bir düzeydeydi; ancak bununla bugün kullanılan ajan arasında pratik kullanım açısından büyük fark var.
  • ML alanında da pekiştirmeli öğrenme (geri bildirim temelli öğrenme) 50 yılı aşkın süredir temel ilkelerden biri.
• Ajanların pratikte ortaya çıkışı, LLM’lerin evrimiyle doğrudan bağlantılı.
  • 2023’teki LLM’ler araç çağırma konusunda yetersizdi, bu yüzden ajan rolü sınırlıydı.
  • 2025 LLM’leri araç çağrıları ve tekrarlı işler için optimize edilmiş durumda, bu da ajanların gerçek anlamda kullanılmasını mümkün kılıyor.
  • Frontier (en yeni ticari) modeller, araç kullanma becerisinde açık modellere göre belirgin biçimde önde.
  • Önümüzdeki 6 ay içinde açık modellerin de bu farkı kapatması bekleniyor.
  • İşe yarar şekilde tekrarlı araç çağrısı yapabilmek, en yeni LLM’lerdeki en büyük değişim.

Sonraki yön: container’lar ve paralel çalışma

• LLM ajanları alanı, mühendislerin çoğunun henüz fiilen benimsemediği erken ve hızlı değişim aşamasında.
• Bugün ajanlar ağırlıklı olarak IDE içinde ya da yerel depolarda çalışacak şekilde kullanılıyor.
  • VSCode fork’u ya da komut satırı aracı kurarak başlamak kolay.
  • Ancak iki önemli sınır var:
    • Birincisi, güvenlik önlemlerinin yetersizliği: gerçek bilgisayarda kayıtlı prod kimlik bilgileri gibi hassas verilerin sızma riski
      • Ajanın deploy script’i gibi istenmeyen komutları çalıştırması durumunda kritik güvenlik olayları yaşanabilir
      • Her komut çalıştırma öncesi manuel onay istense de, hassas bilgi sızdırma ihtimali sürer
    • İkincisi, paralel yürütme ve otomasyon sınırı: her geliştiricinin kendi ortamında aynı anda ancak bir ajan çalıştırabilmesi
      • Bir ajanın tek çalışması birkaç dakika sürebildiğinden, birden fazla işi eşzamanlı ilerletmek zor ve verimsizdir
• sketch.dev bu sınırları container ortamı ile aşmaya çalışıyor.
  • Her iş için izole geliştirme container’ları oluşturuluyor, kaynak kod kopyalanıyor ve dışarıya yalnızca git commit gibi çıktılar alınıyor.
  • Böylece birden fazla ajan aynı anda çalıştırılabiliyor; başka ajan sistemleri de bu yaklaşımı araştırıyor.
• Gerçek örnek: Github kimlik doğrulama işi sürerken, form arayüzü iyileştirmesi ayrı bir ajan oturumunda yürütüldü.
  • Ayrı bir issue tracker kaydı açmadan, ekran görüntüsü ve tek satırlık kısa bir istekle form tasarımı geri bildirimi verildi.
  • Sadece 30 saniyelik bir yatırımla bile belli bir kalite eşiğinin üzerinde sonuç alınabildi.
• Son 6 aydaki UX deneylerinin sonucu:
  • Ajan tabanlı geliştirmede container’ların (izole yürütme ortamlarının) en pratik çözüm olduğu sonucuna varıldı.

IDE neye dönüşecek?

• Ajan tabanlı geliştirme ortamında IDE’nin (entegre geliştirme ortamı) rolünün ne olacağı hâlâ açık bir soru.
  • Ajana yönerge verip işi başlatmak, bunu container ortamında çalıştırmak, değişiklikleri diff olarak incelemek ve branch/PR olarak push etmek gerçek iş akışı haline gelebilir.
• Pratikte ajanın ürettiği commit’lerin çoğunda belirli düzeyde insan eliyle temizlik gerekiyor.
  • Başlangıçta neredeyse her commit manuel düzeltme gerektiriyor; fakat prompt yazma becerisi arttıkça gereken düzeltme miktarı azalıyor.
  • Yapılan düzeltmeler bazen yorum düzenleme, değişken adı değiştirme gibi basit şeyler; bazen de daha karmaşık refactor işlemleri olabiliyor.
  • Bunların container ortamında nasıl verimli yapılacağı kilit nokta.
• sketch.dev ve benzeri yerlerde denenen iş akışları:
  • Doğrudan düzenlenebilir diff görünümü sunmak
    • Sketch’in diff ekranının sağ tarafında kod doğrudan düzenlenince ilgili commit’e yansıyor ve hemen push edilebiliyor
    • Küçük tek satırlık düzeltmeler için çok verimli
  • Container’a SSH erişimi sağlamak
    • Doğrudan shell’e girilebiliyor veya web terminal ile kod üzerinde çalışılabiliyor
    • vscode:// URL’siyle açılarak geleneksel IDE’de çalışma mümkün oluyor
  • Kod inceleme tarzı yorumları diff üzerinde doğrudan bırakıp ajana geri bildirim olarak iletmek
    • Kod inceleme deneyiminden yararlanarak, gerekli açıklama ve talepler minimum girişle aktarılabiliyor
• Genel değerlendirme
  • Container ortamı, kod üretimi-düzenleme-doğrulama-inceleme süreçlerini entegre ederek,
    basit kod yazımının ötesine geçen gerçek ajan tabanlı geliştirmeyi mümkün kılıyor.
  • Geçmişte container içinde geliştirme yapmak istenmeyen bir şeydi;
    ancak ajanın ürettiği diff’leri container içinde toparlayıp düzeltme deneyimi çok ilginç ve üretken.

Son söz

• LLM tabanlı teknolojileri öğrenip denemek insana alçakgönüllülük öğreten bir süreç oldu.
  • Geçmişte çok çekirdekli işlemciler, SSD’lerin gelişi, ağların genişlemesi gibi programlamanın doğası değiştiğinde duyulan heyecana benzer bir şey var; ama LLM’ler, özellikle de ajanlar, kodlamanın "sürecinin kendisini" baştan yaratıyor.
  • Algoritma, dil ve kütüphane seçimlerini etkileyen önceki değişimlerin aksine, ajanlar çalışma biçiminin tüm varsayımlarını temelden yeniden sorgulatıyor.
  • Hatta bazen, "programlamayı hiç bilmiyormuş gibi sıfırdan yeniden öğrenmek daha iyi olurdu" diye düşündürecek kadar büyük bir değişim söz konusu.
  • Ve bu değişim hâlâ sürüyor.
• Bugün yaşadığımız biçim, 6 ay öncesinden bile tamamen farklı ve henüz oturmuş değil.
  • Takım işbirliği, review gibi geliştirme kültürü standartları da yakında büyük ölçüde değişebilir.
  • Örneğin, biçimsel olarak yapılan kod incelemeleri artık gerçek sorunları çözmekte yetersiz kalıyor
    • Kod inceleme sürecinin kendisini yeniden icat etme zamanı gelmiş olabilir
  • IDE de yıllardır savunduğu bütünlük anlayışının aksine, baştan aşağı yeniden düşünülmek zorunda kalabilir
  • Sektör bu değişimin farkında, ancak ajan merkezli yaklaşım henüz başlangıç aşamasında
  • Önümüzde daha büyük değişimler var ve
    merak ile alçakgönüllülük, bu dönüşümden iyi geçmenin belki de tek yolu
  • Hatta belki de şu anda teknoloji forumlarında vakit geçirmek yerine,
    bu tür tartışma ve özetleri bile ajanlara bırakmak daha iyi olabilir

[GN⁺]

Hacker News görüşü

• Ben çoğunlukla sadece kendi araçlarım için kod yazdığım için, benim yerime başka birinin ya da bir şeyin kodu yazıp sonra benim onu okuyup, anlayıp, düzeltmemin çok büyük bir artısını pek görmüyorum; tabii API dokümantasyonunda istediğim kısmı LLM'e buldurmak oldukça faydalı ve zaman kazandırıyor, bu yüzden LLM'lerin gelecekte daha iyi olup olmayacağından bağımsız olarak ben zaten başkasının kodunu okumayı pek sevmiyorum

  • Benim için LLM'in faydalı olduğu durumlar var; örneğin daha formel kodlarda makro ya da code generator ihtiyacını azaltıyor, gerçi yavaş ve makrolar gibi her şeyi tek seferde güncellemek zor ama, küçük farklılıklarla tekrar eden kod yapılarında LLM bazen makrodan daha kullanışlı oluyor, ayrıca aşina olduğum ama kodunu ezbere bilmediğim bir API'yi kullanırken Google araması yapıp doküman kazmaya gerek kalmadan doğrudan ilerleyebiliyorum, tipli bir dil kullandığım için LLM saçmalarsa type checker ya da testler bunu yakalayabiliyor, bu yüzden çok endişe etmiyorum, ayrıca 10'dan fazla dosyaya yayılan değişikliklerde Markdown olarak bir değişiklik planı çıkarması gerçekten büyük zaman kazandırıyor, son olarak yorgunken stil ya da isimlendirme kurallarını kolayca göz ardı edebiliyorum ama LLM projenin mevcut stilini iyi koruyor
  • Son zamanlarda bu şekilde çalışmayı giderek daha çok seviyorum; önce genel kod tasarımını planlıyorum, sonra LLM'e somut adımları anlatıyorum ve ben kodu okuyup anlayıp düzeltirken ve sonraki adımı planlarken LLM'in bir sonraki bölümün kodunu önceden hazırlamasını sağlıyorum, yani ben ve LLM paralel çalışıyoruz, bu biraz restorandaki bir şefin sipariş gelir gelmez tüm yemeğin adımlarını planlayıp biftek pişerken boş boş beklemek yerine diğer hazırlıkları da aynı anda yapmasına benziyor, LLM daha çok fırın ya da food processor gibi bir mutfak aracına benziyor, mesela peyniri elde de rendeleyebilirsin ama food processor'a atarsan birkaç dakika kazanırsın, profesyonel aşçılar çeşitli araçlarla aynı anda birçok işi yürüterek verimi artırır; bence kodlama da gelecekte satır satır ilerleyen bir iş olmaktan çıkıp böyle çoklu görevli bir yapıya dönüşebilir
  • Kod yazma sorumluluğunu başka bir şeye devredip sonra dönüp onu yine okumak, anlamak ve elle düzeltmekte ne fayda var sorusuna ben "sürtünme" ifadesini kullanıyorum, birçok insan yeni bir işe başlamayı zor buluyor—tıpkı writer's block gibi—ama bir başkasının hazırladığı çözümü alırsan onu kendi tarzına göre değiştirip modülerleştirmeye başlamak için giriş eşiği çok düşüyor, ben ve ekip arkadaşlarım arasında bir projeyi sıfırdan kurarken toolchain yapılandırması ve bootstrap kısmını ciddi yük olarak gören çok kişi var, yeterli bağlam ve kaynak verilirse LLM tüm codebase'i hızla tarayıp "bu kodda zaten iki yerde audit mekanizması var, ortak kısmı çıkaralım" gibi şeyleri fark edebilir, yani benim gözümden kaçan noktaları da yakalayabiliyor
  • Üzerinde çalıştığım bir codebase'de birçok dosyada tekrar tekrar küçük değişiklikler yapmayı gerektiren işler var, bunlar yaratıcılık ya da meydan okuma değil, sadece birçok dosyayı açıp düzenlemekten ibaret tekrar işi, eskiden 3-4 saat sürüyordu ama AI agent'a işi anlattığımda %99'unu kendi hallediyor ve toplam süre 3-4 dakikaya düşüyor
  • Bazı insanlar araçlar olmadan hiçbir şey yapamayan tiplerdir, bu insanlar early adopter ve power user olur, sonra yeni keşifleri etrafa yayarlar, GitHub'ın değeri sıradan geliştiricilere PR, review, yeşil kareler, todo listeleri gibi şeylerle üretken görünme ortamı sunmasıydı, LLM de benzer şekilde sıradan geliştiricilerin çok da önemli olmayan araçları ve agent'ları çalıştırarak üretken görünmesine imkân verdiği için yöneticilerin hoşuna gidiyor

• Yazarın code review'un zayıf olduğu ve neredeyse hiç düzgün işlemediği kısmına tamamen katılıyorum, agent'ların kod yazdığı bir dönemde gerçek darboğaz yazmak değil kod okumak olacak, insanlar review'yu baştan savma yapar ya da sadece kendi zevklerini göstermenin aracı olarak kullanırsa agent'lar ciddi güvenlik ya da performans sorunlarını kolayca içeri sokabilir, açıkçası asıl sorunlar kodu sadece okuyarak görünmüyor; doğrudan debug etmek ya da varsayımları elle doğrulamak gerekiyor

  • Agent/AI kodunun bu "zayıf review" sorununu tam olarak nasıl çözdüğü belli değil, insanlar zaten code review yapmayı sevmiyor ve bunu sıkıcı buluyor, beni endişelendiren şey eğlenceli kısmı olan "kod yazmayı" AI'ya bırakıp onun yerine sonsuz kod okuma ve denetim yapmak zorunda kalmak
  • Bugün piyasadaki en büyük eksik, LLM'in ürettiği kodu, diff'leri ve tüm codebase'i nasıl verimli şekilde okuyup gerçekten review edeceğimiz ve anlayacağımız konusu, projede insan sayısı azsa geride kalanların bu kodu gerçekten okuyup okumadığı, yoksa sadece geçip gitmediği konusunda endişeliyim
  • Agent'ların asıl olayı, test coverage yeterliyse AI'nın kod yazıp güvenlik/performans geri bildirimi de alabilmesi, ayrıca test yazımında da yardımcı olması

• Nihayet LLM'ler hakkında gerçekçi bir analiz yapan bir yazı gördüm, "agent" teriminin aslında özyinelemeli biçimde LLM çağıran bir for döngüsüne isim verilmesinden ibaret olması biraz sinir bozucu ama sektörde isimlendirme zaten ortalamanın altında, o yüzden kabulleniyorum

  • "Agent" tanımı konusunda yazıyla tam aynı fikirde değilim, aslında olan şey LLM'in araçları ve kaynakları yinelemeli olarak çağırdığı bir döngü, küçük bir fark gibi görünse de öznenin ne olduğunu belirliyor
  • "Agent, döngünün içinde araç olan şeydir" ifadesini sevdim, sanırım Simon bunu söylemişti
  • OP'nin agent tanımına biraz itirazım var, olay yalnızca LLM'in döngüye girmesi değil; asıl belirleyici nokta, LLM'in eylemlerinin başka mantıksal bileşenler tarafından kısıtlanması ya da yönlendirilmesi, bunların bir kısmı deterministik, bir kısmı ise ML tabanlı (LMM dahil), yani LLM'i bir şekilde tasarlanmış bir sistem içinde plan yapmaya zorlayarak ya da kod düzenlemesinden sonra test derleme ve çalıştırmayı tetikleyerek ek fayda elde edilebiliyor, "agent kendi başına girdi alıp hareket eder" demek tamamen yanlış değil ama özünde daha önemli olan şey birçok bileşenin sürekli olarak LLM'in davranışını denetleyip yönlendirmesi
  • "Agent" ismi bence insanların sezgisel olarak kolay anlaması açısından fena değil ama alternatif olarak LoopGPT gibi bir ad da olabilir diye düşündüm

• "Container'ların programlamada faydalı ve gerekli olduğu konusunda hemfikiriz" kısmıyla bağlantılı olarak, Docker'ı yapan Solomon Hykes'ın neden yakın zamanda Container Use adlı projeyi açık kaynak yaptığı anlatılıyor: agent'ların paralel ve güvenli şekilde çalıştırılabilmesi için, Sketch gibi bazı platformlar yalıtılmış yerel geliştirme ortamını gömülü sunuyor ama diğer coding agent'larda bu yok; ek bilgi olarak şu YouTube videosu da öneriliyor

• Agentic loop, makinenin içindeki bir beyin, hatta fiilen bir kural motoru yerine geçen şey gibi görünüyor, kendine özgü bazı eksileri hâlâ var ama birçok uzmanın özü doğru yakaladığını düşünüyorum: "agent araçları birbirine bağlıyor, kullanıcının isteğiyle prompt veriyor, sonra çalıştırıp tekrar tekrar döndürüyor ve prompt da duruma göre dinamik olarak değişiyor", insan benzeri etkileşim ya da problem çözme biçimini illa taklit etmeden de orkestrasyon/çok aşamalılık, belirsiz görevlerin yerine getirilmesi ya da otomasyon için oldukça faydalı, eskiden belirsizliği doğrudan kodla ifade etmek gerekiyordu, belki artık buna gerek kalmayacak, production ortamında dry run olmadan çalıştırma konusunda kaygılar var ama araçların ve servislerin de evrileceğini düşünüyorum, 100'den fazla benzer servis tutarlı bir arayüzle dış dünyaya (ör. SMS, e-posta, hava durumu, sosyal ağlar vb.) bağlanırsa bugünkünden çok daha güçlü bir asistan, hatta daha fazlası ortaya çıkabilir

  • Takvim, hava durumu gibi çeşitli servislere agent bağlayıp bir oyun arayüzü oluşturan ilginç bir oyuncak proje var, bağlantı
  • Kullanılan tüm araçlar için soyutlama birleşirse mevcut asistanlardan çok daha iyi bir şey çıkabilir ama bunun bedeli olarak çok büyük arıza ve hata ihtimallerini de kabul etmek gerekir, reliability engineering, quality assurance, yetki yönetimi, güvenlik ve gizlilik gibi konular giderek daha kritik olacak, Apple'ın Siri'nin sınırlarını aşan yeni bir sesli asistanı piyasaya sürmemesinin sebebi de belki bu risk yönetimidir

• Kod okumak her zaman yazmak kadar önemliydi ama artık daha da önemli hâle geliyor, bu benim kâbusum, kod yazmak bazen eğlenceli olabiliyor ama kod okumak her zaman emek

  • Yine de "düzeltme eğlencesi" kalabilir, hatta artabilir

• Agent kullananlar arasında gerçekten "programlamayı" yani problem çözme biçimi üzerine düşünmeyi ve bunu kodla ifade etmenin keyfini seven kaç kişi var merak ediyorum, bugün birçok agent iş akışına bakınca bu sürecin kendisi ortadan kalkmış gibi; doğal dille gereksinimleri anlatıyorsun ve sonra sadece LLM'in bug üretmemesini umuyorsun

  • Ben kod yazmaktan keyif alan biriyim ve LLM'in benim için eğlenceli olabilecek bir parser'ı tek seferde üretmesi bende biraz boşluk hissi yarattı, yine de zaman yiyen parser yazımı yerine daha büyük hedeflere odaklanabiliyorum, istediğim type/function signature'larını yazıp detay implementasyonu LLM'e bırakınca doğrudan sonraki aşamaya geçebilmek etkileyiciydi, eskiden "düzeltsem iyi olur ama uğraşmaya değmez" seviyesindeki kapsamlı düzenlemeler büyük yük gelirdi; şimdi kod cilalama, test üretme, README senkronizasyonu ve refactoring fikirlerinde LLM yardımcı olduğu için projenin hem kalitesi hem de iddiası arttı, doğru zihniyetle yaklaşılırsa yazılım üretmeyi seven insanlar için adeta cennet olabilir
  • Tersinden bakarsam, binlerce kez çözülmüş sorunlarda kodu ille de kendi elimle yazmak istemem, o durumda sözlük kullanırım, gidip yeniden hash table yazmam, eğer "bu dilin derleyicisini yap" ya da "bunu DFS ile çöz" deyince kusursuz sonuç gelseydi bunun programlamanın keyfini azaltacağını düşünmüyorum, doğal dille hesaplama sürecini tarif etmenin karmaşık seviyelerde belirsizlik ya da çelişki üretmeye yatkın bir sınırı var, ama hangi tarafta olursan ol LLM'i düşünmeden kullanmayı zaten kimse önermiyor; sonuçtan sorumlu olan yine benim
  • Doğal dilin programlama için uygun olmadığına kanıt olarak EWD667 belgesine atıf yapılıyor, ayrıca LLM'ler Stack Overflow tarzı soru-cevaplarda yararlı olsa da ileride SO verisi azalırsa bunun da sınıra dayanabileceği söyleniyor
  • Ben buna katılmıyorum, LLM'in yaptığı işlerin çoğu tekrarlı ve sıkıcı implementasyon görevleri, ben hâlâ proje mimarisi gibi eğlenceli kısımları ve LLM'in de zorlandığı yaratıcı/zor parçaların tasarımını kendim yapıyorum, bir yıl sonra durum değişebilir ama şimdilik gerçekten düşünmem gereken şeylere odaklanabildiğim için memnunum
  • Yazar benim, ben hem programlamayı hem de agent'ları seviyorum

• Kod yazarken AI'ı keyifle kullandığım birkaç alan var (gerçekten benim yazdıklarım!):

  • CSS: Herhangi bir web sitesinde CSS ile uğraşmaktan nefret ederdim, AI ise karmaşık CSS numaralarının hepsini hatırlıyor, bu da işi hızlandırıyor; örneğin karmaşık bir WordPress yapısında belli bir div'i ortalamak birkaç denemeden sonra hızlıca çözülebiliyor
  • Unit test: AI'nin gömülü kod verisi çok eski değilse test üretimi de eğlenceli bir deneyim oluyor
  • Commit özeti: İlk taslak için fazlasıyla yeterli
  • Çok küçük, birinci sınıf seviyesindeki ödevleri de hızlıca halledebiliyor
  • İlginçtir, benim deneyimimde AI CSS konusunda pek iyi değilmiş gibi geldiği için bazen faydasız buldum, ama sevmediğin işleri üstlenmesi fikrine tamamen katılıyorum; benim için buna örnek ticket açıklamaları yazmak, bunu benden çok daha iyi yapıyor
  • Yanlış anladıysam kusura bakma ama eğer güncel CSS trendlerine çok aşina değilsen, modern CSS artık eskisine göre çok daha az karmaşık ve yönetmesi daha kolay; birkaç saat ayırıp güncel CSS'e bakmanı öneririm, yine de ben de stil işlerinde AI'ı sık kullanıyorum

• "Varlık" ve "borç" kısmı ilginçti ama katılmıyorum, birçok program az sayıda kullanıcı için başlayıp sonra beklenmedik şekilde büyük projelere dönüştü, geçmişte tek seferlik diye üstünkörü yazılmış bilimsel kodun bir anda çok daha uzun ömürlü ve geniş kapsamlı hale geldiğini fazlasıyla gördüm, bu yüzden kendi kodumu çok daha uzun yaşayacak ve daha geniş ölçekte kullanılacakmış gibi, hem kendime hem başkalarına karşı sorumluluk duyarak yazıyorum, bir çalışma arkadaşının kişisel yan projesinin yönetici tarafından ekip projesine dönüştürüldüğünü gördüysen bu sorunu anlarsın

  • Yine de aklımda "alternatif ne?" sorusu kalıyor, insanlar neyin yaygın şekilde benimseneceğini tahmin etmekte kötü, hatta özenle yapılmış projelerin hiç kullanılmaması, hızlı ve dağınık yapılanların ise başarılı olması daha sık görülüyor, evrimsel baskı biraz da bu yönde işliyor; burada klasik "worse is better" metni anılabilir (bağlantı)

• Bence LLM'leri kod yazma/tasarlama yerine code review için kullanmak asıl killer özellik olabilir, şu anda code review zaten birçok açıdan bozuk ve ileride güvenlik, tanımsız davranış, özelliklerin yanlış kullanımı, derleyici uyarılarının ikinci kez kontrolü gibi konularda LLM'lerin faydası daha da artabilir, ben kişisel olarak LLM'leri daha çok arama motoru gibi hata teşhisi ve debug için kullanıyorum, doğruluk oranı yaklaşık %50 ve bu bana gayet yeterli geliyor

  • ChatGPT, internette zaten bolca tartışılmış bir problemse debug konusunda epey iyi, çünkü Stack Overflow bilgisini özetleyip birleştiriyor ve tek tek örnek arama süresini azaltıyor, ama LLM yanıtlarında hâlâ uydurma/hallucination kaynaklı gürültü var; tüm kodu review ederse hata türlerini ya da sorunlu fonksiyon/çağrıları iyi yakalayabiliyor ama buna karşılık false positive de çok oluyor, gerçekten LLM'i otomatik code review'da etkili kullanan var mı merak ediyorum
  • "Bu kodu review et" isteğini tekrar tekrar yaptığında chatbot bazen X'i Y ile değiştirip biraz sonra tekrar Y'yi X'e çevirmeyi önerebiliyor, yani code review'da belli ölçüde işe yarasa da hangi öneriyi kabul edip hangisini reddedeceğine insanın kendisinin karar vermesi gerekiyor, ayırt etme gücü yeterli biri için gerçekten üretkenliği artıran değişiklik adayları sunuyor
  • Bu konunun neden daha büyük bir tartışma başlığı olmadığını merak ediyorum, çevremdeki geliştiricilerin teknolojiye ilgisi çok değişiyor; genelde deneyimi az olanlar daha hevesli kullanıyor, kıdemliler ise daha az ilgili, AI'ın code review/doğrulama için kullanımını neredeyse hiç duymadım, belki commit anında otomatik çalışan bir özellik gerekebilir
  • Code review/design yerine code review odaklı LLM'ler zaten GitHub Copilot'ta reviewer mode olarak var, henüz zirve seviyede değil ama döngüye alıp kullanmak için yeterince işe yarar kalitede
  • Katılıyorum, biz de sourcery.ai tarafında bunun üzerinde çalışıyoruz