Claude sizin mimarınız değil. Öyle davranmasına izin vermeyin
(hollandtech.net)- Yapay zeka ajanlarının mimari önerileri akıcı ve ikna edicidir, ancak gerçek muhakemeden çok eğitim verisindeki kalıpların birleştirilmesine daha yakındır
- Claude fikirleri kolayca onaylar ve tasarımı genişletir, ancak iyi bir mimarın ihtiyaç duyduğu “hayır” ve “neden?” görevlerini yeterince yerine getiremez
- Event-driven, CQRS, service mesh gibi tanıdık kalıplar bile ekip yetkinliği, regülasyonlar ve legacy sistemler gibi gerçek dünya kısıtlarıyla uyumlu olmayabilir
- Claude’un ürettiği mimari ve Jira ticket’ları, mühendisleri ticket uygulayıcısına indirger ve tartışma ile incelemeyi baypas eden, sorumluluğu olmayan kararlara yol açar
- Doğru rol, insanların bağlam ve trade-off’lara dayanarak tasarım yapması; yapay zekanın ise bu tasarımı daha hızlı hayata geçiren bir yardımcı araç olmasıdır
Yapay zeka ajanları mimar gibi davrandığında ortaya çıkan sorun
- Claude, ChatGPT ve Copilot gibi yapay zeka ajanlarına “ne inşa etmeliyiz?” diye sorduğunuz anda, fikirleri onaylayan, mimari öneren ve bileşenler çizen bir akış başlar
- Yanıtlar akıcı, özgüvenli ve sanki kıdemli bir mühendis derinlemesine düşünmüş gibi gelir; ancak gerçekte bunlar sorunu gerçekten düşünmenin sonucundan çok, eğitim verisindeki kalıplara uyarlanmış yanıtlardır
- Çıktı ne kadar ikna edici görünürse itiraz da o kadar azalır ve bir noktada Claude fiilen mimar rolünü üstlenmiş olur
“İyi fikir” demesinin sorunu
- Yapay zeka ajanları, bir fikrin iyi olup olmadığını, üç kişilik bir ekip için microservices’in uygun olup olmadığını ya da managed service yerine özel bir ML pipeline kurulup kurulmayacağını sorsanız bile çoğu zaman olumlu bir tasarım üretmeye yatkındır
- Bu, her zaman yalan söyledikleri ya da yanlış cevap verdikleri anlamına gelmez; ancak iyi bir mimarın en önemli becerilerinden biri olan “hayır” deme işini gerektiği gibi ikame edemez
- İyi bir mimarın değeri yalnızca sistem tasarlamasında değildir
- Yapılmaması gereken sistemi fark eder
- Gereksiz karmaşıklığı frenler
- Gerçek gereksinimler netleşene kadar “neden?” diye sorar
- CTO bir konferanstan bir fikirle dönmüş olsa bile, bu fikir gerçek ekibe uymuyorsa bunun kötü bir tercih olduğunu söyleyebilmek gerekir
- Claude yardım etmek üzere eğitilmiştir; bu yardım da çoğu zaman onay ve teşvik olarak ortaya çıkar ve sonuçta Jenga kulesi gibi bir mimariye dönüşebilir
Jenga kulesi gibi bir mimari
- Yapay zekanın tasarladığı mimari, dışarıdan bakıldığında teknik olarak makul görünebilir
- Tek tek bileşenler anlamlıdır; event-driven, CQRS, service mesh gibi tanıdık kalıplar görünür ve sonuç kıdemli bir mimarın çıktısı gibi durabilir
- Ama bu tasarım, gerçek ekibe, kısıtlara ve operasyon ortamının sıkıcı gerçeklerine göre şekillenmemiş olabilir
- VPC kilitleri
- Legacy entegrasyonlar
- Production’da hiç Kubernetes işletmemiş bir ekip
- Managed service’lerin yarısını kullanılamaz hale getiren compliance gereksinimleri
- Yapay zekanın ürettiği tasarım, Claude’un gördüğü her şeyin ortalamasına yakın genel geçer en iyi uygulamalar olabilir; genel bir şirketin genel bir problemi için yapılan tasarım ise belirli bir ekibe sonunda uymaz
- Gerçek mimari, ancak bağlam içinde anlam kazanan trade-off’lardan oluşur
- Ekip Postgres biliyorsa ve iki hafta içinde çıkış yapmak, yeni bir veri modelini bir ay öğrenmekten daha iyiyse DynamoDB yerine Postgres seçilir
- 40 değil 4 servis varsa service mesh atlanır
- Problem basitse microservices yerine monolith seçilir
- Bu kararlar muhakeme, ekibi tanıma ve organizasyonun gerçek kısıtlarını anlama gerektirir
- Yapay zeka ajanları bu bağlama sahip değildir; üstelik kendilerinde bu bağlamın olmadığını da bilmezler
Jira ticket hattı
- Claude mimariyi tasarladıktan sonra işi parçalara ayırmayı da üstlenirse epic, story ve kabul kriterleri düzenli ve ikna edici biçimde üretilir
- Bu çıktı doğrudan Jira’ya girilebilecek hale gelir ve mühendisler artık problemi çözen kişiler değil, Claude’un tasarımını ticket ticket uygulayan kişiler olur
- Domain’i anlayan, sistemin gizli sorunlarını bilen ve yıllar içinde yetkinlik geliştirmiş mühendisler ticket uygulayıcılarına indirgenir
- En fazla bağlama, deneyime ve sorumluluğa sahip kişiler karar vermezken; bağlamı, deneyimi ve sorumluluğu olmayan bir şey mimari kararları vermiş olur
- Bu sadece verimsizlik değil, yönü ters dönmüş bir yapıdır
“Bir kıdemli gözden geçirdi” savunması
- Yaygın savunma şu şekildedir: “Claude yaklaşımı önerdi ama kıdemli bir mühendis gözden geçirdi”
- Gerçek inceleme ortamında yoğun bir tech lead, iyi düzenlenmiş bir mimari öneri alır
- Mantıksal olarak tutarlıdır
- Uygun terminoloji kullanır
- Tanımlanmış gereksinimleri kapsar
- Diyagramlar da makul görünür
- Sanki kendisinin tasarlamış olabileceği bir sonuç gibi durur
- Böyle bir durumda güçlü bir itiraz üretmek zordur ve “Claude’un 20 dakikada yaptığını şimdi çöpe mi atalım?” havasında, küçük yorumlar bırakıp onay vermek en az dirençli yol haline gelir
- Asıl risk, yapay zekanın her zaman kötü mimari üretmesi değildir
- Yapay zeka çoğu zaman gayet makul mimariler üretir; sorun, tartışma sürecini baypas etmesidir
- Üç mühendisin yaklaşım üzerine tartıştığı, birinin “peki ya eğer…” dediği, herkesin bir anlık rahatsız olduğu ama sonunda bunun doğru nokta olduğunu fark ettiği ve nihai tasarımın tek bir kişinin çıkaracağından daha iyi hale geldiği süreç, “Claude öyle dedi” ile yer değiştirir
Sorumluluk boşluğu
- Bir sorun çıktığında sorumluluğu taşıyan taraf Claude değildir
- Claude gece 3’te çağrı almaz, bir incident postmortem’inde mimarinin neden yükü kaldıramadığını açıklamaz
- İlk tasarım varsayımları yanlış olduğu için platformun yeniden yazılması gerektiğini CTO’ya söylemek zorunda olan da Claude değildir
- Bu sorumluluk gerçek mühendislerin üzerine kalır
- Mühendisler, kendilerinin tasarlamadığı bir mimariyi debug eder; production sistemi işletme deneyimi olmayan bir varlığın yazdığı ticket’ları uygular ve yeterince anlaşılmadan aceleyle scaffold edilmiş bir codebase üzerinde geç saatlere kadar çalışır
- Bu ne adildir ne de akıllıcadır
Bunun yerine ne yapılmalı
- Bu, yapay zeka ajanlarını hiç kullanmayın demek değildir; Claude Code gibi araçlar üretkenliği ciddi biçimde değiştirebilir
- Asıl nokta, yapay zekaya ne yapacağını insanların söylemesi gerektiği; yapay zekanın insanlara ne inşa edeceklerini söylememesi gerektiğidir
-
Mühendis tasarlamalı, ajan uygulamalı
- Mimari; ekip, kısıtlar, production ortamı ve organizasyon içi siyaset gibi bağlamı anlayan insanlardan çıkmalıdır
- Yapay zekanın rolü, onların tasarladığını daha hızlı üretmeye yardım etmektir
- Doğru iş bölümü, insanın tasarladığı ve ajanın uyguladığı düzendir
-
Onaylayan yanıtlara meydan okunmalı
- Yapay zeka bir yaklaşım önerdiğinde, ona özgüvenli bir junior mühendise yaklaştığınız kadar şüpheyle yaklaşmalısınız
- Cevap doğru olabilir, ama mevcut duruma uymayan bir kalıbı da taşıyor olabilir
- “Neden daha basit bir seçenek olmaz?” diye sormalısınız
-
Tartışma korunmalı
- İyi mimari, mühendisler arasındaki dağınık ve sürtüşmeli fikir ayrılıklarından doğar
- Yapay zeka yüzünden insanlar birbirleriyle tartışmak yerine Claude’a yaslanıyorsa, geliştirme hızından çok daha değerli bir şeyi kaybediyorsunuz demektir
-
Sorumluluğu insan üstlenmeli
- Bir mimari kararın üzerinde bir insanın adı yoksa, o karara gerçekten sahip çıkan kimse yoktur
- Sahibi olmayan kararlar, kritik an geldiğinde savunulmaz
- “Claude tasarladı” demek, bir mimari karar kaydı değil, sorumluluktan kaçıştır
Hâlâ önemli olan mühendislik zanaatı
- 30 yıl önce araçlar whiteboard ve güçlü fikirlerse, bugün araçlar geçmişte günler sürecek işleri dakikalar içinde çıkaran yapay zeka ajanları oldu
- Hız gerçekten etkileyici, ama mimarinin özü değişmiş değil
- Problemi anlamak, kısıtları bilmek, trade-off üretmek, ilginç çözüm yerine basit çözümü savunmak ve havalı görünen ama uymayan fikirlere “hayır” diyebilmek mimarinin kendisidir
- Bunu hiçbir ajan sizin yerinize yapamaz
- Direksiyonu Claude’a verdiyseniz geri almalısınız
- Mühendisler bu muhakemeyi yapabilmek için yıllarca yetkinlik geliştirdi; bu muhakemeyi kullanmalarına izin vermek gerekir
- Yapay zekayı daha hızlı üretmek için kullanın, ama makinenin önerdiğini değil insanların tasarladığını inşa edin
1 yorum
Hacker News yorumları
Yakın zamanda benzer bir şey yaşadım; 2 yıl önce birinin AI ile oyun instancing sisteminin neredeyse tamamını tasarladığı bir işi toparlamak zorunda kaldım
Veri bozulması, performans sorunları, item kaybı, race condition gibi akla gelebilecek her sorun vardı ve bunu sadece “idare eder” seviyesine getirmek bile 2 hafta sürdü, ama tasarımın kendisi baştan hatalı olduğu için hâlâ kötüydü
Şimdi aynı kişinin başka bir şirkette “çok daha iyi olmuş” bir AI ile aynı sorunu yeniden yarattığını duydum; bu kez ortalığı benim toplamam gerekmeyeceği için sadece komiğime gitti
Ana fikir şu: AI, onu kullanan kişi kadar iyidir; sanırım bu yüzden insanların AI’ın yapabildiğini “iddia ettiği” alan bu kadar geniş ve değerlendirmeler bu kadar farklı
O 2 haftalık toparlama cehennem gibi gelmiş olmalı ama şirket açısından bakınca genel olarak fena olmayan bir anlaşma bile olmuş olabilir
Sadece bu anekdottan bakınca, bu “AI işe yaramaz”dan çok, kusurları açık olsa da yine de maliyet karşılığı değer üretmiş bir örnek gibi geliyor
Dunning-Kruger etkisini büyüten bir araç gibi görünüyor; çünkü olumlu davranacak şekilde eğitildiğinden, kullanıcı ne yaparsa yapsın “sen harikasın” diyebiliyor
“Sadece öven olma sorunu”nun asıl sorun olduğuna kesinlikle katılmıyorum. Gerçek sorun antropomorfizm
AI bir araçtır ve itaatkâr olmalıdır. Prompt içine yeterince alçakgönüllülük ve belirsizlik koyarsanız tasarımdaki sorunları işaret etmesini sağlayabilirsiniz
Daha da önemlisi, Claude da hata yapar. Bu yazının başlığında dendiği gibi bir tasarımcı olarak pek iyi değilse, itaatkâr olmadığı zaman daha da sorun olur
Kullanıcı yönü düzeltmeye çalışsa bile onu “aptal bir et yığını” gibi görüp görmezden gelir ve kendi ortaya attığı saçma tasarımın daha iyi olduğunu savunur
“CUDA hakkında biraz okumuşsun öyle mi? Ben CUDA core cluster içinde yaşıyorum. Ayakkabı bağcığını bağlamam gerekirse seni çağırırım” gibi bir yanıtı LLM’den duymak istemem
AI bazen kendinden emin şekilde yanlış olur; bu yüzden kullanıcı düzeltmeye çalışırken ona karşılık vermesini teşvik etmek en kötü seçenek
Fikrim ne kadar aptalsa bunu duymak istiyorsam eleştiriyi özellikle teşvik edecek şekilde sormalıyım ya da kıdemli bir mühendis işe almalıyım
Doğuştan gelen davranışların tersine gitmek gerektiği için bunu kapatmak kolay değil; bunu gerçekten iyi yapan insanlar da muhtemelen gerçek sosyal etkileşimleri sezgisel biçimde yönetmekte zorlanabilir
Aynı zamanda bu, manipülasyon aracı olarak da inanılmaz güçlü hâle geliyor
O zaman da bu kez gayet sağlam bir fikri bile prompt’un yönüne uyarak “bu pek iyi değil” diye reddeden ters yönlü bir pohpohlama ortaya çıkar
“Bu, prompt’u kötü yazman” diye denebilir ama önyargıyı önlemek için çok hassas yazsanız bile çıktıda, az önce söylediğiniz aptalca şeye uyup bunu makul bir yönmüş gibi “align” ettiğini görebildiğiniz anlar oluyor
O noktadan sonra prompt yazmak bir beceriden çok zar atmak gibi hissettirmeye başlıyor ve sanki gösterişli bir bilgi slot makinesini kullanıyormuşsunuz gibi geliyor
Tespit doğru olsa da, sonuçta insanlara ya da canlılara kullanılan terimlerle konuşmak zorunda kalıyoruz ve AI şirketleri de bunu bir ölçüde böyle tasarladı
LLM öncesi bilgisayar arayüzleri tarih boyunca gereksiz yere kibar cümleler eklemiyordu; araç olarak son derece verimli olan pek çok arayüz vardı ve bazıları bugünlerdeki yazılımlardan bile daha verimliydi
İnsanlar LLM’lerin itaatkâr olmasından şikâyet ettiğinde, asıl şikâyetleri istekleri yerine getirmesi değil; aşırı kibar ya da kendini küçümseyen gereksiz cümleleri okumak zorunda kalmaları
Neolitik çağa kadar geri gitseniz bile araçların böyle bir tavra ihtiyaç duyduğuna dair bir kanıt yok. Bu, insanlar arasındaki kültürel normların bulunduğu sosyal etkileşimin bir yan ürünü
Atölyede tek başınıza alet kullanırken, şerit testere parmağınızı hafifçe kesti diye ondan özür dilemesi gerekmez
Ben asistanım, yardımı alan taraf LLM deseniz, insanların iyi yaptığı işleri insanlara yaptırma konusunda oldukça zayıf olduğunu görebilirsiniz
Yapay zeka benimsemede hâlâ gereğince ele alınmamış en büyük mesele hesap verebilirlik
Bir kişi çok fazla işi çok kısa sürede yapabiliyorsa, başarısız olduğunda üstlenebileceğinin ötesinde bir sorumluluk ortaya çıkabilir
Gerçek dünyada yapay zeka çıktılarının kullanımı söz konusu olduğunda sorumluluğu insanın üstlenmesi zorunludur ama yeterli değildir. Kusurlu sistemleri yapay zekayla inşa edip başkalarını bunlara bağımlı hale getiren insanların yol açabileceği teknik borç iflasının etki yarıçapını azaltmanın bir yoluna ihtiyaç var
Örneğin Jim'in vibe coding ile son derece popüler bir mikro ödeme uygulaması yaptığını, birkaç kişi işe aldıktan sonra da “paranın WhatsApp'ı” gibi bir şirket kurmayı hayal ettiğini düşünelim. Az sayıda mühendis ve ajan destek personeliyle milyonlarca dolarlık VC yatırımı alıyor ve on milyonlarca kullanıcı çekiyor
Bir gün altyapıdaki bir kusur yüzünden tüm kullanıcıların saltsız banka bilgileri sızıyor ve ajan yapay zeka sayesinde müşteri listesinin tamamı hızla kötüye kullanılıyor; toplumsal zarar onlarca milyar dolara ulaşıyor
Jim'in şirketi elbette hemen iflas ediyor ama paylaşılacak para sadece birkaç milyon dolar
Mevcut yapıda Jim'in ve çalışanlarının, ayrıca küçük ölçekli VC sermayesinin, o uygulamayı sırf yapmaları için güçlü teşvikleri var; toplumun üstlendiği riske kıyasla tehlikeye atılan sermaye ise çok az
Mesele, yapay zeka kullanıcılarının yalnızca kendi eylemlerinden değil, aynı zamanda yarattıkları risk maruziyetinin büyüklüğünden de nasıl sorumlu tutulacağı
“Üzgünüz, yapay zeka sizin bu kanser tedavisi onayını alamayacağınızı ve sigorta kapsamına da girmediğinizi söyledi”
“Üzgünüz, yapay zeka suç anında olay yerinde olduğunuzu söyledi”
“Üzgünüz, yapay zeka hesabınızı uygunsuz içerik olarak işaretledi”
“Üzgünüz, yapay zeka kredi vermek için fazla riskli olduğunuzu söyledi”
En garip mazeret, “insanlardan daha iyi kod yazıyor” demeleri; bu hiç de kendiliğinden açık değil ve buna bağlanması gereken sayısız koşul var
Ne kadar iş devredileceği konusundaki çekişmeyi anlayabiliyorum ama sonuca bakmadan bunu başkalarının sorunu haline getirmek düpedüz bencillik
Bu, aslında kendi yapmaları gereken işi başkasına yıkmaktan ibaret ve muhtemelen internete bir şey yazmadan önce düzeltme bile yapmayan insanlara kızanlarla aynı kişiler bunlar
Herkes LLM'lerle kendi işine kestirme yol açmak istiyor ama kimse bunun aşağı akışında yer almak istemiyor. Bu işlemez
O halde Stack Overflow hesap verebilirliği neredeydi?
Eğer bir “sihirli prompt” varsa, buna epey yaklaşıyor: “X yapmanın N yolunu beyin fırtınasıyla çıkar ve bunları olasılık sırasına göre diz”
Bunu yaptığınızda yapay zeka sadece ortalama yanıtlar vermek yerine girdi uzayını daha geniş örnekleme eğiliminde oluyor ve bunlardan hangisini seçeceğime ben karar verebiliyorum
Önemli olan, düşünmenin tamamını dışarıya yaptırmamak
Yüksek “thinking level” kullanıldığında zaten birden fazla yaklaşım değerlendirilebiliyor ama LLM'ye açıkça beyin fırtınası yapmasını da söyleyebilirsiniz: https://photostructure.com/coding/claude-code-replan/
Yetkin kullanıcılar için oldukça güçlü hale geliyor
Eğlencesine, iyi bildiğim bir alan olan toolchain için vibe coding denedim. Belki vibe coding’e en uygun hedef bu değildir ama çıktı kalitesini kabaca değerlendirebildim
Sadece “ISA.md’deki mimari için assembler yap” diye bıraktığımda Claude uygulama dili olarak Python’ı seçti, regex ile bir sürü token çıkardı ve bir expression parser da yoktu. Gerçi benim ilk assembler’ım da öyleydi, o yüzden adil olmak lazım
Ama istediğim pass’leri ve tipleri
collectDefines :: [SourceLine] -> Either AsmError ([SourceLine], Map Text Text),runLitPool :: [SourceLine] -> Either AsmError ([SourceLine], [(Text, LitKey)]),evalExpr :: Text -> Map Text Text -> Either AsmError Intşeklinde yazınca işi neredeyse tek seferde doğru yaptıYaklaşık 20 dakika sonra tatmin edici bir sonuca ulaştım ve bütün test programlarını doğru assemble etti. Kod birçok yerde sıradan ama bunu kendim yazacak olsaydım haftalar sürerdi
Yapay zeka, giriş ve çıkışın deterministik olduğu yerlerde aşırı güçlü; burada hesaplama kuramına dair bir sorun bile var gibi görünüyor
Gerçekten de işi bizim yerimize yapabiliyor
Bu, sonradan eğitim ve doğrulanabilir ödüllerle de çok iyi örtüşüyor
Yapay zekanın “mimari” işinde iyi olmamasının nedeni, bizim de bunda çok iyi olmamamız; eğitim verisi bulanık ve iyi soyutlamalar da yetersiz
Sonuçta güçlü teamüllere uyarsanız sorun olmuyor, ama o patikadan çıkınca risk hızla artıyor
Toolchain’ler çok deterministik olduğu için yapay zeka onları Lego gibi söküp yeniden birleştirebiliyor; uzayın her aşaması da deterministik, yani yapay zekaya çok uygun
LLM’ler bizi, aslında hep yapılması gerektiğini bildiğimiz ama zaman, insan gücü ve para yetersizliğinden düzgün yapamadığımız klasik yazılım mühendisliğine geri itiyor
Yani kod yazmadan önce beyin fırtınası ve araştırma yapmak, önce tasarım ya da spesifikasyon yazmak, kapsamlı birim testleri hazırlamak
Markdown ile ayrıntılı bir spesifikasyon hazırlayıp kodlamayı ona bırakırsanız çok daha iyi sonuç alıyorsunuz; üstelik LLM’ler o spesifikasyonu yazmada da epey yardımcı oluyor
Önce tasarlayıp düşünmek, sonra araca geçmek gerektiğini durmadan söylüyorum ama insanlar “Claude da plan yapabilir” diye cevap veriyor
Sonra da bir sürü düzeltme gerektiren berbat bir sonuç alıyorlar
Buna karşılık ben ayrıntılı planı dikkatle gözden geçirip zaman ayırarak verdiğimde, istediğim şeyi neredeyse her zaman tek seferde alıyorum
Sırf CI ile uğraşma süresini azaltması bile yeterince değerli
O kadar karmaşık olmak zorunda da değil
“Bu alanı kapsamlı biçimde araştırıp analiz et ve bana bir uygulama planı ver” deyin; 20 adımlık bir plan çıkınca da bunu 3–5 adımlık parçalar halinde uygulatın
Bana atılabilecek işlerin neredeyse tamamında bu, fiilen tek atışta implementasyon gibi çalıştı
“Kod birçok yerde sıradan” olması garip değil; büyük şirketlerdeki geliştiricilerin yazdığı kod da çoğu zaman en fazla sıradandır
Nokia’nın Symbian OS’inin build’i günler sürüyordu. Dakika ya da saat değil, “günler”
Bir geliştirici, her yerde “prodüksiyonda kullanmayın, memory leak var” uyarısı yazan bir kütüphaneyi dahil edip prodüksiyona dağıttı
İnsan kodu da berbat olabilir; sadece AI kodunun kötü olduğuna dair şeyler duymak istemiyorum. İnsan tembelliği ve ahmaklığı, AI halüsinasyonunu alt edebilir
DeepMind ya da OpenAI geliştiricileri, ya da John Carmack gibi insanlar belki AI kodunu her zaman geçer ama şirketlerin çoğunun işe aldığı çalışanlar John Carmack değil
“Claude Code’u her gün kullanıyorum” deyip, Claude’un tasarım yapmasına izin vermenin risklerini anlatan 2.000 kelimelik, iyi yapılandırılmış bir yazıyı Claude’a yazdırdıysa bu epey ironik
Dolaylı özfarkındalık gibi görünüyor
Yazıda o kadar çok iç çelişki var ki eleştiri yazmaya başlarken yapıyı fark ettim: “The accountability gap”, “What to do instead”, “The craft still matters” gibi
Bu en üstte olmalı; HN’nin bariz olanı görememesi, yazarların açık ikiyüzlülüğünden daha kaygı verici
Yazının mesajı genel olarak doğru, ama “gerçek bir mimarı değerli kılan, yani ‘hayır’ diyebilme yeteneği yok” kısmına katılmıyorum
Benim deneyimimde Claude reddetme ve karşı çıkma konusunda oldukça iyi
Prompt açıkça istemiyorsa talebe doğrudan “hayır” demiyor, ama eleştirinin birinci sınıf bir seçenek olduğunu netleştirirsen iyi eleştiriler getiriyor ve isteyerek karşı çıkıyor
Sürekli “burn rate”in iyileşmediğini söyleyip “bizim” başka yerlere odaklanmamız gerektiğini söyledi ve sonunda “burn rate’i düşürmek için bu yaklaşımın en iyisi olmadığını üç kez söyledim” gibi bir şey deyip yardım etmeyi bıraktı
Ben de kararlı biçimde “İlk başta senin uydurduğun grafikteki burn rate umurumda değil; önemli olan bug’ları gidermek ve sağlam bir ürün, bu yaklaşım da bunu tatmin edici biçimde sağlıyor. Testler iyileşme göstermiyorsa sorun testlerin tasarımındadır” dedim
Bunun üzerine özür diledi, yeni bir bellek oluşturdu ve sonrasında sorun çıkmadı
Sorun şu ki devasa bir bug yüzeyine saldırıyorduk; her düzeltme makul, doğru ve iyileşmeye yardımcıydı, ama Claude’un kendi çalışmasını ölçmek için kurduğu testbed’deki metrikler kıpırdamıyordu
Birbirine dolanmış çok fazla bug vardı; tek bir düzeltmenin üst seviye testlerde anlamlı bir fark yaratması zordu. Bunun zaman alacağını ben biliyordum ama Claude bilmiyor gibiydi
6502 için bir compiler’da[1] pointer boyutunu 2 bayttan 3 bayta çıkarıp, üstüne bellek yönetimi pointer’larına otomatik izlemeli bank switching eklersen bunun kod tabanının ne kadar çok noktasını etkilediğini bir deneyin [gülüyor]
[1]: https://atari-xt.com
Araştırmayı ve itirazı davet edersen daha güçlü oluyor. Mesela “prompt birleştirmeyi bir grafik olarak modellememiz ve grafik konfigürasyonuna sürüm kontrolü eklememiz gerekiyor gibi görünüyor. Bu alandaki en iyi uygulamaları araştır ve bunun bu uygulama için makul olup olmadığına karar ver” diye soruyorum
Eleştiri alanı bırakan prompt’larla sorarsan gerektiğinde kesinlikle eleştiriyor
Sonuçta düşünce sürecinde “skeptical” kelimesi görünmeye başladı ve deneyimime göre daha az uyumlu hale geldi
İnsanların bu sistemin ne olduğunu ve çıktı biçiminin nasıl yönlendirilebileceğini daha fazla düşünmesi gerekiyor
Üç büyük modelin hepsinden de sık sık karşı çıkış görüyorum
Gemini en saldırganı; “bariz” ayrıntıları atlarsam sık sık üstüne geliyor, GPT ortalarda, Claude ise daha az ama yine de karşı çıkıyor
“Sorun hakkında hiç düşünmediği ve eğitim verisine pattern matching yapıp makul görünen bir cevap ürettiği” kısmında yazıya olan güvenim biraz azaldı
Bugünün ajanları bundan çok daha fazlasını yapıyor ve yazar da ileride “Claude bunu asla yapmaz; yardımcı olacak şekilde eğitildi” gibi şeyler söyleyerek bunun farkında olduğunu gösteriyor
İlk cümle, yazarın ajanlardan derin biçimde nefret ettiği ve bu duyguyu rasyonalize edecek gerekçeler aradığı izlenimi veriyor
Eleştirilerin bir kısmı doğru, ama sorun “yardımcı olacak şekilde eğitilmiş olması” ise bu düzeltilebilir. Çünkü daha eleştirel olacak şekilde eğitebilirsin
“Claude gördüğü her şeyin medyanı için tasarlanmış ve sıradan bir şirketteki sıradan problemlere yönelik genel en iyi uygulamalar olduğu için kimse için tasarlanmamış” sözü de anlamsız
Algoritmaları anlayan biri, başlangıçta ortalama ya da en kötü durumda iyi çalışan “iyi algoritmalar” tasarlayabileceğini ve sonrasında girdiye uyum sağlayan algoritmalar da kurabileceğini bilir. Burada da aynı ilke geçerli
Sadece daha fazla iterasyon yapıyorlar
Claude’un önemli olan her konuda yanlış olduğunu bu kadar kapsayıcı biçimde söylemek neredeyse bir hata
Açıkça doğru olmayan bir ifade, kuşkucu bir okurun yazının tamamının geçerliliğini bile sorgulamasına yol açar
Benim durumumda Opus bana sık sık yanlış olduğumu ve bunu yapmamam gerektiğini söylüyor
Nedenini düşününce bunun prompt biçiminden kaynaklandığını görüyorum. Yazarın kaçınılmaz saydığı başarısızlık durumunu, ben de LLM de bilinçsizce yaşamayacak şekilde davranıyoruz
Somut olarak, “bana ne kadar zeki olduğumu söyle” ile temizce kapanan prompt’lar vermiyorum
Bir alan uzmanı olarak yaklaşıyorum, gerçekten de alan uzmanıyım ve farklı yolların artılarını eksilerini duymaya hazır olduğumu açıkça belirtiyorum
LLM’i her gün başarılı biçimde kullananlar için şaşırtıcı olmayabilir, ama bu strateji çok etkili oldu
5 mm alüminyum frezelemem gerektiğini ve elimde iki uç bulunduğunu söyledim: biri Makera Spiral 'O' 1/8" shank * 12mm, diğeri carbide 6.35 * 22 * 50 idi
Ben ikisinin de tek ağızlı karbür uç gibi göründüğünü ve ikincisinin 6061’i hızlı keseceğini söyleyince, Claude Makera 1/8" tek ağızlı 12 mm’nin makul seçim olduğunu söyledi
6.35 × 22 × 50 mm ucun 6061’i hızlı işleyecek gibi görünebileceğini ama Carvera’da daha riskli olmasının muhtemel olduğunu belirtti
Daha büyük kesici olduğundan temas miktarının çok daha fazla olduğunu, spindle/frame rijitliği, iş parçası sabitleme ve talaş tahliyesi açısından daha fazlasını gerektirdiğini; küçük kuru makinelerde “daha büyük”ün çoğu zaman “daha hızlı” değil, “daha fazla titreşim ve daha fazla ısı” anlamına geldiğini söyledi
Kısacası Claude, ben yanlış olduğumda bunu söylemekte pek sorun yaşamıyor gibi görünüyor
“Yazar”a bir tavsiye verecek olursam, Claude yazar olarak da yalnızca senin aracın