Ajan tabanlı yapay zeka neden iyi bir pair programmer değil

• LLM ajanları insanlardan çok daha hızlı kod yazdığı için pair programming deneyimi tersine kötüleşebilir
• Aşırı hızlı otomasyon nedeniyle kullanıcı yetişemez ve çalışma bağlamını kaçırma sorunu sıkça ortaya çıkar
• Bu durum, deneyimli geliştiricilerle eşleşirken hissedilen dışlanmışlık duygusuna benzer ve sonuçta kalite kontrolü ile iletişimin zayıflamasına yol açar
• Çözüm olarak, asenkron kod incelemesi odaklı iş birliği ve AI ile eşleşme hızını düşürüp kalite kontrolü ve iletişim merkezli bir iş akışına geçiş önerilir
• AI ajanlarının da insanlar gibi “durup konuşmaya, özgüvenden çok şüphe ve doğrulamaya odaklanan” bir tasarıma ihtiyacı vardır

---

LLM ajanları ve pair programming'in sorunları

• AI ajanları (ör. Copilot Agent), insan düşünme hızından çok daha hızlı kod yazar
• Bu yüzden kullanıcı daha takip edemeden kod yağmaya başlar ve bağlamı kaçırma ile işe odaklanmanın düşmesi gibi durumlar ortaya çıkar
• Sorun anında ajan yardım istediğinde, kullanıcı durumu hâlâ kavrayamamışken “arkasını toplama” rolünü üstlenmek zorunda kalır ve sonuç olarak yanlış yönde ilerlemiş kodu düzenleme yükü büyür
• Sonuçta kalite kontrolü, iletişim ve doğru yönü korumak zorlaşır

• En iyi AI ajanıyla pair yapma deneyimi, geçmişte olağanüstü bir insan programcıyla eşleşirken yaşanan olumsuz anıları hatırlatır
  • Pair partnerinin aşırı bir hızla sessizce klavyeye yüklenmesi, kodu takip etmeyi imkânsız hâle getirir
  • Tüm zihinsel enerjiyi tükettikten sonra kişi giderek işten kopar
  • Pair tıkandığında yardım istenir ama durumu anlamak zor olduğu için rahatsız edici bir deneyim yaşanır
  • İşin ilerleyişi sırasında hedefle farklı yönde bir uygulama ortaya çıkar ve bunu teslim tarihine kadar düzeltme yükü karşı tarafa kalır

The path forward: pratik çözümler

• 1. Asenkron iş birliği

  • İnsanlarla pair programming'de bir kişinin baskın biçimde ilerlediği durumlarda olduğu gibi, AI'ın kodu bağımsız yazıp Pull Request olarak incelemeye sunması daha etkilidir
  • GitHub Coding Agent gibi asenkron iş akışları kullanılarak, kullanıcının inceleme ve kalite kontrolüne odaklanması sağlanabilir

• 2. Hızı düşürülmüş “tur bazlı” eşleşme

  • AI'ın “Agent Mode”u yerine, Edit/Ask Mode gibi her seferinde tek adım ilerleyen bir yaklaşım kullanmak
  • Ping-pong pair programming'de olduğu gibi (bir taraf önerir, diğer taraf onaylar), AI'ın önerdiği değişiklikleri kullanıcının doğrudan kabul edip gözden geçirerek hızı ayarlaması
  • AI'ı yalnızca problem çözme/debugging için değil, tutarlı bir iş akışının parçası olarak kullanmak daha uygundur

Ajan eşleşmesini daha insani kılacak fikirler

• Kullanıcının kod çıktı hızını (satır/dakika, kelime/dakika) doğrudan ayarlayabilmesi
• Ajanı geçici olarak durdurup, kullanıcının soru sormasına veya yönelime itiraz etmesine olanak tanıyan bir özellik
• Mevcut chatbot UI'ın ötesine geçip, işin ilerleyişiyle bağlantılı UI primitive'leri sunmak (ör. mevcut oturumu belirli bir GitHub issue'suna sabitlemek, yerleşik To-do listesi vb.)
• Ajanın daha sık durup konuşacak şekilde tasarlanması: “Bunu neden yapıyoruz?” diye doğrulamak, tavsiye istemek, yönü kontrol etmek gibi insanla iş birliği hissi oluşturan davranışlar
• Gelişmiş voice chat desteği ekleyerek, kullanıcının gözünü koddan ayırmadan sesle AI ile iletişim kurabilmesi

• Bu tür özellikler uygulanırsa, bugünkü hızlı ve tek taraflı ajan eşleşmesi yerine gerçek bir insan-ajans ortak çalışma deneyimi mümkün olabilir

Sonuç

• Şu anda AI ajan tabanlı pair programming'in hem sınırlarını hem de potansiyelini aynı anda görüyoruz
• AI ajanlı pair programming, yalnızca hızlı olmak yerine insan iş birliğindeki gibi iletişim, kalite ve doğrulama merkezli tasarlandığında daha büyük etki yaratabilir
• “Yavaşça, konuşarak, doğrulayarak ve bağlamı paylaşarak” ilerlemek, AI ile eşleşmenin kalitesini artırır

[panarch]

> 1. Eşzamansız iş birliği
> İnsanlarla yapılan pair programming’de bir kişinin süreci inisiyatif alarak yürütmesine benzer şekilde, yapay zekanın kodu bağımsız olarak yazıp Pull Request ile incelemeye sunması daha etkilidir

Birkaç gündür Codex kullanıyorum ve ajan biçimindense buna katılıyorum. Birden fazla proje işini aynı anda yürütebilir hale gelince, gerçekten birden çok junior geliştiriciyle birlikte çalışma deneyimi yaşıyorum.
Yapay zekayı eşzamansız kullanabilir hale gelince birden fazla projede, hatta tek bir projede bile birden çok işi aynı anda yaptırabildiğim için üretkenliğin aritmetik olarak 3-10 katın üzerine çıktığını gerçekten hissediyorum.

[GN⁺]

Hacker News görüşleri

• Bunu tam da bu şekilde kullandıktan kısa süre sonra neden bıraktığımı çok iyi anlatan bir yazı gibi geldi. Bir şey inşa etmek istediğimde genelde kabaca <i>nasıl</i> yapacağımı zaten belirlemiş oluyorum, ama AI'nın fiilen yaptığı şey çoğu zaman benim istediğimle farklı oluyor. Üstelik AI bir seferde 2.000 satır kod üretince işim azalmak yerine artıyor. "Önce şu yorumların hepsini sil, bu basit kod için gereksiz açıklamalar iki kat fazla. X'i böyle soyutlama, ben bunu istiyorum..." gibi yönlendirmeler vermek gerekiyor; sonra geri bildirim verince bir anda 2.000 satır 700 satıra düşüyor ve olan biteni takip etmek aşırı zorlaşıyor. Kod tabanının benim pek bilmediğim, yaklaşımı da birbirinden farklı script'lerle dolu hale gelmesinden de hoşlanmıyorum. Benim stilime ve düşünme şeklime benzeyen bir AI lazım ama en zor kısım da bu. AI ile çalışmak, deneyimsiz biriyle ilk iş gününde birlikte çalışmak gibi hissettiriyor. Bence bu daha çok aracın kendine güven sorunu değil, tasarım sürecini daha görünür hale getirmesi. İdeal olarak önce "şöyle bir yaklaşım düşünüyorum, şu fonksiyonları ya da sınıfları kullanacağım, durumu da böyle yöneteceğim" diyen bir taslak görmek, uygunsa ancak ondan sonra uygulamaya geçmek gerekiyor.

  • Tıpkı insan mühendislerle olduğu gibi, önce bir planlama oturumunun gerçekten önemli olduğunu vurgulamak isterim. Kod yazmadan önce konuşup detayları adeta pazarlık eder gibi netleştirmek. Ben bilerek ilk soruyu mümkün olduğunca muğlak soruyorum; belki beklemediğim öneriler çıkar diye. Sonra giderek daha somut hale getiriyorum. Yeterince memnun kalınca LLM'den initialprompt.txt ve TODO.md adında iki belge oluşturmasını istiyorum. initialprompt.txt, proje özetini ve TODO.md dosyasını okuma talimatını içeriyor; ayrıca her adım tamamlandığında işaretlemesini söylüyor. Bu sayede LLM hem genel hedefi hem de ayrıntılı işleri kavrıyor; daha sonra bağlam sınırı yüzünden sohbet kopup yeniden başlatıldığında da işi hızla hatırlatabiliyor.

  • Benim deneyimimi de birebir özetlemiş gibi. AI'nın yazdığı kodla ancak sadece sonucun önemli olduğu ve ilgili alan hakkında neredeyse hiç arka plan bilgim olmadığı durumlarda başarıya ulaştım. Ne zaman neyin “iyi” sonuç olduğuna dair güçlü bir fikrim olsa, sonunda hayal kırıklığına uğrayıp projeyi bırakıyorum. roo code'un architect özelliğiyle önce yaklaşımı netleştirip ardından code mode ile gerçek kodu yazdırdığımda, deneyim yarı yarıya keyif ve hayal kırıklığıydı. En önemli ders şu oldu: her zaman yeni bir görev başlat, uzun sohbetleri sürdürme. Ben normalde sorunu küçük parçalara böler ve sonuçları kontrol ederim; ama LLM'ye tüm problem alanını bir kerede yükleyip başarısız oldum. Kendi yöntemimi bulmak için birçok kez denedim ve bugün de 30 dakikada bir uygulama özelliği ekledim. Bunu kendim yapsam gerçekten günler sürerdi. Günlüğe gerçekten sadece 30 dakika yazmamın nedeni de ne istediğimi çok net biliyor olmam ve süreçle ilgilenmememdi. Bu deneyimler yüzünden, bir gün başka birinin kullanacağı kodu AI'ya emanet etmenin her açıdan imkansız olduğu sonucuna vardım.

  • Sonunda sadece çok yorucu ve tatmin etmeyen deneyimler yaşadım. Bu konuda benzer kaygıları olanlara söylüyorum: ben de ajan tabanlı kodlamadan ancak kod kalitesini umursamadığım kısa ömürlü script'lerde ya da gerçekten hiçbir yerde etkisi olmayan ufak tefek leaf function'larda memnun kaldım.

  • Anthropic'in Claude Code kullanım rehberi içinde önerilen iş akışı tavsiye edilebilir. Özeti şu: “Önce kodu okut, sonra değişiklik planı yaptır, en son uygulat.” Böylece AI tek satır kod yazmadan önce planı görüp düzenleyebilirsiniz. Ajan kullanırken istediğinizden farklı hareket ediyorsa, örneğin tasarım yapmadan doğrudan kod yazıyorsa, sadece "bunu farklı yap" demeniz yeterli.

  • Bir seferde 2.000 satır kod üretmesinden söz ediyorsun ya, sanki SNES üzerinde tüm Skyrim'i çalıştırmasını isteyen bir prompt giriliyor gibi. Öğle yemeğinden dönüp çalıştırınca da size PS1 tarzı, sadece yakın dövüş içeren bir Fallout yapmış diye sinirlenmek gibi.

• HN ana sayfasına bir yazı düştüğünde her zaman yorumlara bakıp ne kadar aptal olduğumu ve insanların beni yerin dibine sokan saldırgan şeyler söyleyip söylemeyeceğini düşünürüm. Ama bazen başlığı gerçekten iyi attıysam kimse yazıyı okumuyor, herkes kendi derdini anlatıyor ve ben de o eleştirilerden sıyrılmış oluyorum.

  • Eğlenceli ama bir yandan da gerçekçi bir hikaye bence. Başka yazılarda da benzer bir örüntüyü sık görüyorum. Ne olursa olsun bu tür tartışmaları sevdiğim için keyif alıyorum.

  • Yazıyı beğendim. Bir bakıma “AI ile pair programming'den nasıl keyif alınır” gibi bir his verdi. Faydalı olduğu için teşekkürler.

• LLM ajanlarını ilk kullandığımda iki yönlü iletişim, gerçekten işbirlikçi bir pair programming bekliyordum. Ama pratikte karşıma, her şeyi tamamen kendi yöntemleriyle çözmeye çalışan bir partner çıktı. Ben biraz düzeltmeye kalkınca da AI'nın yazdığı kodun bağlamı bozuldu ve iş daha da kullanışsız hale geldi. Benim istediğim, biraz benim biraz AI'nın çalıştığı, sırayla ilerleyen gerçek bir ortak çalışma.

  • Yakın zamanda tekrar deneyip denemediğini merak ediyorum. Benim deneyimim farklı. AI'nın ürettiği kodu düzenledikten sonra ona dosyayı yeniden okutuyorum. Genelde “dosyada değişiklikler var” gibi tepki veriyor. AI kodu değiştiriyor, ben testleri çalıştırıp geri bildirim veriyorum ve bu şekilde yinelemeli olarak ilerliyoruz. Bu yöntem Zed ve Claude Sonnet ile bende iyi çalışıyor.

  • Benim genel kullanım biçimim, önce AI'nın önerisini almak, sonra gerekirse refactor etmek veya yeni prompt'larla yön vermek. Bu yaklaşım kabul oranını (accept rate) yapay olarak yükseltiyor; ama AI şirketleri de bu istatistiği "AI çok iyi kod yazıyor" iddiasına dayanak yapabiliyor. Oysa gerçekte çoğu zaman içimden “of, neyse ben kendim düzeltirim” dediğim anlar da oluyor.

  • Ben genelde başa “önce sadece konuşalım, kodu değiştirme” ekleyince istediğim tarzda bir sohbet elde ediyorum. Yeterince gidip geldikten sonra en sonda “uygula” diyorum.

  • İstediğiniz işbirliği biçimini gerçekten istiyorsanız bunu LLM'den açıkça talep etmenizi öneririm. Her sohbette tekrar kullanabileceğiniz birkaç prompt belgesi hazırlamak da iyi olur.

  • Son zamanlarda bağlamı korumak o kadar zor değil, dolayısıyla kod değişiklikleri de sorun olmuyor. Ben sadece Ask modu ile kullanıyorum; yani komut vermekten çok soru-cevap odaklı. Claude Code'da Opus, Cursor'da ise o3 max kullanıyorum. Ajan modundan özellikle kaçınıyorum; çünkü bu yazıda anlatıldığı gibi zaman geçtikçe bana sağladığı fayda azalıyor. Sekme tamamlama özelliğini nadiren kullanıyorum ve önerilen kodun %80-90'ını düzenleyip bizzat ben yazıyorum. Bu sayede 170wpm hızında yazmayı sürdürebiliyorum. Opus ve o3 max'in çıktı hızı sınırlı olduğu için okumak da bunaltıcı gelmiyor; ilk başta fazla hızlıydı ama çabuk alıştım. Kişisel görüşüm şu: Eğer GitHub Copilot sizin tüm LLM deneyiminizse, bu ancak motel seviyesinde bir deneyimdir.

• Pair programming de her duruma uygun değil. Hatta çoğu durumda uygun olmayabilir. Başka yerde de söylemiştim; LLM'nin otomatik tamamlama önerileri yüzünden odaklanmış kod yazma akışı bölünüyor, sürekli durup okuyup incelemek ve kabul/ret vermek gerektiği için programlama akışı tamamen bozuluyor. AI otomatik tamamlamayı kendi iş akışıma sokmaya çalışırken gerçekten çok zorlandım.

  • Ben de aynı fikirdeyim. Çözüm, AI'sız ayrı bir IDE ile Cursor/VS Code'u birlikte kullanıp aralarında gidip gelmek. Gerçek anlamda odaklanma/derin çalışma, chatbot'la konuşurken mümkün değil.

  • Yakın zamanda yeni bir dizüstü aldım ve IDE'yi yeniden kurdum. Birkaç saat kod yazdıktan sonra bir şeylerin ‘garip’ geldiğini fark ettim. Meğer GitHub Copilot'a giriş yapmayı unutmuşum ve AI'sız çalışıyormuşum. Kod otomatik tamamlamasını beklemeden çok daha proaktif yazdığımı hissettim. Özellikle Cursor iş akışımı sürekli bölüyor; ‘sonraki imleç konumunu tahmin etme’ gibi özellikler de gerçekten gereksiz. Bundan sonra Copilot'u kapalı tutup, boilerplate ya da tekrar eden işler için yalnızca aider gibi ajan tarzı araçlar kullanmayı planlıyorum.

  • AI otomatik tamamlama ya da kod önerileri, özellikle güçlü tip sistemine sahip dillerde en kötü durumda oluyor. Çoğu zaman %80 doğru oluyor, oysa IDE otomatik tamamlama neredeyse %100 doğru. Ajan tarzı AI daha iyi; çünkü 1) düşünce akışını sürekli bölmüyor ve 2) derleme ile testleri kendisi çalıştırıp hataları düzelterek size düzgün kod döndürüyor.

  • Ben ise otomatik tamamlamayı çok seviyorum. Go kullanmak zorundayım ve dilde epey boilerplate var; bunu kütüphane ekleyerek çözmek de mümkün değil, o yüzden çoğu zaman kendim yazmak daha hızlı oluyor. Sıkıcı kodları yazarken AI'dan çok ellerim daha hızlı olsa da, otomatik tamamlama gerçekten yardımcı oluyor. Tek satırlık önerileri anında okuyabiliyorum; uzun öneriler de yazmayı düşündüğüm şeye benziyorsa doğrudan geçiyorum. Zamanla AI'nın ne tahmin edeceğine dair sezgi oluşuyor. Muazzam bir verim artışı değil ama log mesajları ya da for döngüleri gibi sıkıcı şeyleri kesinlikle hızlandırıyor. Bence yalnızca, okuma hızınızın yazma hızınızdan daha yüksek olduğu durumlarda işe yarıyor.

  • Pair programming her zaman uygun olmayabilir ama çoğu durumda faydalı olabilir diye düşünüyorum. İşe yaramadığı zamanlar genelde bir kişinin ya da her ikisinin de sürece aktif katılmaması, bir tarafın “bu iş böyle olmaz” diye kapalı olması ya da pair programming ilkelerini aşırı katı uygulamaya çalışmasıyla ilgili.

• Benim duruşum biraz karışık. En az bir aydır işyerinde farklı LLM araçlarını olabildiğince aktif kullanıp bunlardan en verimli şekilde nasıl yararlanılacağını öğrenmeye çalışıyorum. Yazılan satır sayısı açısından üretkenlik kesinlikle artıyor. Ama genel olarak daha üretken olduğumu söyleyemem. Tamamlanan hemen her görevde, açıklayamadığım garip davranışlar oluyor; bazen de ilgisiz yerleri değiştirip sonradan geri almak zorunda bırakıyor. AI'nın otomatik ürettiği testler ilk bakışta makul görünüyor ama coverage gibi diğer ölçütlere bakınca yetersizlikler açıkça ortaya çıkıyor. İstenen sonuca ulaşmak için sanki birkaç adım geri gidip işleri tersine çevirmek gerekiyor. Kazanım ya da öğrenme değil, düpedüz geri düşüyormuş gibi bir his. Bir keresinde, asıl değişiklik kapsamına girmeyen modüllere gizlice 50 bin satır gereksiz import kodu eklenmişti. Başka zamanlarda da kuralları net vermeme rağmen, tüm nesne yönelimli yapıyı bozup her şeyi if/else ile çözmeye kalktı. Sorun şu ki sonuçlar bağlama göre aşırı değişiyor; hatta aynı görevde bile bazen kusursuz, bazen her şeyi mahvedebiliyor. Görevi nasıl vermek, nasıl yönlendirmek gerektiğine dair birçok yol denedim ama benzer işlerde bile davranışlar çok değiştiği için değişiklikleri sürekli denetlemek zorunda kalmak çok yorucu. Kod neredeyse doğru olsa bile, sadece belirli bir kısmı düzeltmesini istersem bütün iş raydan çıkabiliyor. Benim deneyimimde küçük araçlar yazmakta etkili; ama orta ve büyük ölçekli kod tabanlarında tutarlı sonuç beklemek zor.

• LLM ajanları bana fazla konuşan ve her zaman kendi yolunun doğru olduğuna inanan biri gibi geliyor. Özlü değiller; tek satırda bitecek şeyi gereğinden çok uzun anlatıyorlar. En ufak değişikliğe bile upuzun yorumlar ekliyorlar. Sürekli öğretmeye kalkıyorlar, fazla abartılılar.

  • İnsanların sevmediği bazı davranışlar ("çok uzun çıktı", “aşırı yorum” vb.) LLM'lerin başka açılardan verimliliği artırmak için tasarlanmış olmasının yan etkileri olabilir. Uzun çıktılar, tembellik etmeyen kod ve yüksek performans benchmark puanlarıyla ilişkili olabilir. Yorum bolluğu da yerel bağlamı güçlendirerek sonraki kodun kalitesini artırma ve hata azaltma ile bağlantılı olabilir.

  • Dün sonnet 4 kullandım; tek bir ayarı değiştirmek için 15 dakika boyunca sürekli test ve refactor yapıp durdu. Sonunda gereksiz yere 40 dosyayı değiştirdi. Olmayan bir debugger'ı ısrarla çalıştırmaya uğraştı, kimlik doğrulaması gereken web sayfalarını açmaya da çalıştı. Mükemmelden gerçekten çok uzak olduğunu hissettim.

• Benim deneyimimde sorun hızlı olması değil, tam tersine fazla yavaş olması. Üstelik hızı rahatsız edici biçimde arada kalıyor. Daha hızlı olsa kodu gerçek zamanlı izleyerek beraber çalışabilirdim. Daha yavaş olsa o sırada başka iş yapıp sonra dönerdim. Ama gerçekte görevler 50 saniye ile birkaç dakika arasında bitiyor; bu da başka bir şeye odaklanmayı zorlaştırıyor. Bence daha küçük parçalarda, daha hızlı yinelemelerle çalışmak daha iyi. Nihayetinde insani inceleme düzeyinde özerklik, örneğin bir merge request'i (PR) inceler gibi bağımsız ilerleyen bir model daha iyi olurdu. Şu anki döngü (görevi ver, 1-3 dakika bekle, sonucu gör, geri bildirim ver, tekrar et) bana göre en kötü senaryo.

  • Bu bana The Oatmeal'ın “yavaş internet vs hiç internet olmaması” çizgi romanını hatırlattı.

  • Dikkatin dağılıyorsa masaya 30L'lik bir akvaryum koy diye bir öneri vardı. Boş boş bakmak için birebir, komik ama yerinde bir tavsiye.

• Geliştirici olarak AI'yı neredeyse hiç kullanmıyorum; arada sırada projeyle ilgisiz sorular için sohbet botu kullanıyorum, o kadar. Acaba insanlar AI'yı müşteri projelerinde de kullanıyor mu, yoksa sadece kişisel yan projelerde mi? Müşteri işi için kullanılıyorsa, kodun AI'ya gönderildiği bilgisini sözleşmeye dahil ediyor musunuz diye sormak isterim. Çoğu müşterinin dışarıyla paylaşımı yasaklayan NDA benzeri hükümleri oluyor; hatta bazılarında AI kullanımı da açıkça yasaktı. AI kodlama araçlarını istisna sayan müşterilerle karşılaşan oldu mu merak ediyorum.

  • Ben neredeyse sadece şirket içinde kullanıyorum; o da şirketin çok net AI kullanım yönergeleri olduğu için. Zaten pratikte bana pek zaman kazandırmıyor, dolayısıyla kişisel işlerimde para verip kullanmam. Kendi projelerimde sonuçtan çok bizzat yapma keyfi önemli olduğu için, prompt yazmaktan ziyade kendim yapmak daha eğlenceli geliyor.

  • Bazı müşteriler ise tam tersine AI kullanımını özellikle talep ediyor. Daha iyi kalite ve daha hızlı geliştirme bekliyorlar (nihayetinde maliyet düşürme isteği), ama gerçekte bu beklentiler çoğu zaman karşılanmıyor; gerçi bu ayrı bir konu.

  • OpenAI/Anthropic ile yalnızca, bir web arama kutusuna rahatça yapıştırabilecek kadar herkese açık sayılabilecek kodları paylaşıyorum.

  • Ben paylaşmıyorum. Buna şirket içi projeler de dahil; dışarıya kod paylaşımı ancak ücret karşılığında mümkün. Kişisel verilerle de çalıştığım için, kodun ABD şirketlerine açılması ciddi hukuki risk doğurur.

• Nihayet birisi tam olarak rahatsız edici noktayı dillendirmiş. AI tasarım konusunda aşırı özgüvenli, ayrıntılı uygulamaya ise kimseyle konuşmadan kendi başına girişiyor. Mock API'ler bile çoğu zaman yapıyı korumuyor ve yeniden çalışma gerektiriyor. Keşke LLM daha işbirlikçi davransa, detay eksikse hemen sorsa. İlk prompt'ta bütün bilgiyi vermek mümkün değil; sonraki prompt'lar da ilk tasarımın bağlamını ve düşünce akışını bozuyor. Belki ben yanlış kullanıyorum, belki daha iyi bir yolu vardır; öğrenmek isterim. LLM'nin geri bildirimi kademeli alıp buna göre uyum sağlaması yönünde gelişmesini isterdim. Bağlam ekleme/güncelleme meselesinin kendisi mi zor, onu da merak ediyorum; ama öğrenmeye devam etmek istiyorum.

  • Günümüzde çoğu teknoloji yığını bir tür “tasarım/planlama” oturumunu destekliyor; önce bunu denemek iyi gelebilir. Benim işime yarayan akış, ister büyük ister küçük model olsun, “@file, @docs, @examples temelinde, @module_requirements.md dosyasına bakarak @path altında _ işi yapmak istiyorum — gerçek uygulamadan önce gereken her şeyi konuşalım” diye başlamak. Biraz gidip geldikten ve herkes aynı noktada buluştuktan sonra bunu .md dosyalarına kaydedebilir ya da doğrudan “şimdi devam et” diyebilirsiniz. Bu iş akışını .rules, .md dosyaları veya IDE snippet'ları olarak saklarsanız yeni görevlerde tekrar tekrar kullanabilirsiniz. Yeni LLM'lerin çok daha fazla bağlama ihtiyaç duyduğunu, dolayısıyla her kod tabanı için (yani proje bazında) farklı akışlar denemeniz gerektiğini akılda tutmak lazım.

  • Bilgi arttıkça AI'nın daha çok kafasının karıştığını da hissediyorum. Muhtemelen bunun bir çözümü vardır. Çok küçük bilgi parçalarını çekip çıkarmakta başarılılar ama tüm sektörün sadece chatbot modeline odaklanıyor olması biraz üzücü. Klavye, fare, GUI ya da dokunmatik ekran gibi şeyleri hiç geliştirmemiş olsaydık nasıl olurdu diye düşünüyorum.

• AI'yı yardımcı olarak kullanan işbirlikçi tarz, bana göre AI'nın doğru kullanım biçimi; “AI'nın doğrudan kod yazması” etrafındaki moda ise yazılım sektörünün yanlış yöne gittiğinin bir işareti gibi geliyor. Ben AI'ya asla kod yazdırmıyorum. Onu, yazdığım kodu eleştirmek ya da büyük ölçekli kod yapısı için strateji geliştirmek amacıyla kullanıyorum. Bir nevi strateji danışmanı gibi; LLM'nin bağlamını iyi kurarsanız son derece güçlü bir rehber elde edebilirsiniz. Ama özne her zaman benim: anlayan, uygulayan ve sorumluluğu taşıyan benim. AI'ya hiçbir zaman danışman olmanın ötesinde bir sorumluluk vermiyorum. AI'ya “idiot savant” gibi bakıyor ve ona buna göre temkinli yaklaşıyorum.