AI Blindspots – Yapay zeka ile kodlama sırasında keşfedilen LLM kör noktaları

 (ezyang.github.io)
12 puan yazan GN⁺ 2025-03-20 | 1 yorum | WhatsApp'ta paylaş

Yapay zeka ile kodlama sırasında keşfedilen LLM kör noktaları. Claude Sonnet temel alınmıştır

  1. Stop Digging → Sorun çıktığında yön değiştirmekte zorlanır
  2. Use Static Types → Statik tip tanımları gereklidir
  3. Black Box Testing → Uygulama ayrıntılarına aşırı bağımlıdır
  4. Use MCP Servers → MCP sunucusu kurulumu ve güvenlik sorunları
  5. Preparatory Refactoring → Gereksiz refactoring yapabilir
  6. Mise en Place → Ortam kurulumu başarısız olursa sorun çıkar
  7. Stateless Tools → Duruma bağlı araçlarda sorun yaşanır
  8. Respect the Spec → Spesifikasyona uyma olasılığı düşüktür
  9. Bulldozer Method → Tekrarlayan işleri fazla yapar
  10. Memento → Bağlamı yeterince anlayamama sorunu yaşanır
  11. Requirements, not Solutions → Gereksinimlerin netleştirilmesi gerekir
  12. Scientific Debugging → Tahmine dayalı düzeltmelerde sorun çıkar
  13. Use Automatic Code Formatting → Kod stili tutarsızlıkları oluşur
  14. The Tail Wagging the Dog → Önemli iş yerine küçük sorunlara takılır
  15. Keep Files Small → Büyük dosyaları düzenlerken sorun yaşanır
  16. Know Your Limits → Model kendi sınırlarını yeterince kavrayamaz
  17. Read the Docs → Eğitim verisi dışındaki bilgilerde hata üretir
  18. Culture Eats Strategy → Kod stili tutarlılığı zayıftır
  19. Walking Skeleton → Önce en azından çalışan bir sistem gerekir
  20. Rule of Three → Kod tekrarında refactoring gerekir

Soruna saplanıp kalmamak (Stop Digging)

  • Mevcut LLM'ler, çalışma sırasında sorun çıksa bile bunu kendi başına durdurup yön değiştirmekte yetersizdir
    • Örnek: Özellik X uygulanırken önce özellik Y'nin yapılması gerektiği ortaya çıksa bile LLM asıl işini, yani X'i bitirmeye çalışır
    • LLM'nin komutları sadakatle yerine getirmesi avantajdır, ancak sorunu fark edip rota değiştirmesi zordur
  • Sorunu önlemeye yönelik stratejiler
    • Planlama aşamasında akıl yürütme modeli kullanarak iş önceliğini ve önkoşul işleri belirlemek
    • Sonnet gibi ajan tabanlı LLM'ler dosyaları okuyup iş planı oluşturur → kullanıcı açıkça söylemese de gerekli işleri anlayabilir
  • İdeal olarak LLM'nin sorunu fark edip kullanıcıdan onay istemesi gerekir
    • Ancak bu bağlam tükettiği için, bunu ayrı bir gözetleyici LLM'nin yapması daha iyi olabilir

  • Example

    • Monte Carlo simülasyonundaki rastgele örnekleme yöntemi değiştirildikten sonra Claude Code'dan testleri düzeltmesi istendi
      • Yeni uygulama deterministik olmadığı için test sonuçları rastgele geçiyor ya da kalıyordu
      • Claude Code bunu fark etmedi ve test koşullarını gevşeterek sorunu çözmeye çalıştı
      • Bunun yerine simülasyonun deterministik hale gelmesi için refactoring önermeliydi

Statik tip kullanımı (Use Static Types)

  • Dinamik tip ile statik tip sistemi tartışması, prototipleme kolaylığı ile uzun vadeli bakım arasındaki denge meselesidir
    • LLM'ler boilerplate kodu ve refactoring işlerini yapabildiği için prototiplemeye uygun dil seçme baskısı azalır
    • Bu sayede prototiplemeden çok uzun vadeli bakım için avantajlı diller seçilebilir
  • Tip hatalarını düzeltme stratejisi
    • Ajan ayarlarında, LLM'nin değişiklik sonrası oluşan tip hatalarını fark edeceği şekilde yapılandırmak
    • Bu sayede düzeltilmesi gereken başka dosyalar da kolayca tespit edilebilir
  • Dikkat edilmesi gerekenler
    • Python ve JavaScript'te kademeli tip sistemi kullanılır → bu yüzden type checker ayarları sıkı yapılandırılmalıdır
    • Rust ilke olarak LLM'ler için uygundur, ancak şu anda Python/JavaScript kadar iyi üretilmemektedir

Kara kutu testi (Black Box Testing)

  • Kara kutu testi, bir bileşenin iç yapısını bilmeden işlevini test etme yöntemidir
    • Uygulama dosyaları bağlama dahil olduğu için LLM'lerin kara kutu testi ilkesine uyması zordur
    • Sonnet 3.7'de (Cursor kullanırken) kod tutarlılığını koruma eğilimi vardır → test dosyalarındaki tekrarları kaldırmaya çalışır
      • Ancak kara kutu testinde bu tekrarların korunması hata yakalamak açısından faydalıdır
  • İdeal çözüm
    • LLM'nin yüklediği dosyalardaki uygulama ayrıntılarını maskeleyebilmesi veya özetleyebilmesi gerekir
    • Mimarın bilgi gizleme sınırlarını açıkça tanımlaması gerekir

  • Example

    • Sonnet 3.7, başarısız testi düzeltirken hardcoded sabitleri orijinal algoritmaya göre hesaplanacak şekilde değiştirdi
      • Oysa sabitlerin olduğu gibi korunması gerekiyordu

MCP sunucularını kullanmak (Use MCP Servers)

  • Model Context Protocol (MCP) sunucuları, LLM'lerin ortamla etkileşim kurması için standart bir arayüz sağlar
    • MCP sunucuları Cursor ajan modunda ve Claude Code'da yaygın biçimde kullanılır
    • Ayrı bir RAG sistemi olmadan da LLM, MCP çağrılarıyla gerekli dosyaları bulup düzenleyebilir
    • Model test veya build çalıştırdıktan sonra sorunları anında düzeltebilir
  • Özel MCP sunucusu yazarken dikkat edilmesi gerekenler
    • Cursor'da YOLO modu etkinleştirildikten sonra Cursor kurallarına shell komutları eklenebilir
      • Bu risklidir → rastgele shell komutları ortamı bozabilir
    • Alternatif: Yalnızca belirli komutları açığa çıkaran özel bir MCP sunucusu yazmak → güvenliği artırır
      • Ancak Mart 2025 itibarıyla Cursor'da proje bazlı MCP sunucusu ayarları yetersizdir

  • Example

    • Sonnet 3.7, TypeScript projesinde tip kontrolü yapıp hataları düzeltirken MCP kullandı
      • Terminal çıktısını elle kopyalayıp yapıştırmaya gerek kalmadan bunu otomatik yaptı
      • Ancak bazen yanlış komutu (npm run typecheck) tahmin etmesi mümkündür

Hazırlık refactoring'i (Preparatory Refactoring)

  • Hazırlık refactoring'i, değişiklikten önce işi kolaylaştırmak için önce refactoring yapma stratejisidir
    • Refactoring anlamı koruyan bir işlem olduğu için gerçek değişiklikten daha kolay değerlendirilebilir
    • Önce refactoring, sonra asıl değişiklik yapılırsa inceleme ve hata düzeltme kolaylaşır
  • Mevcut LLM sorunları
    • Ön hazırlık refactoring'i yapmadan her şeyi tek seferde çözmeye çalışma eğilimi
    • Gerekli olmayan düzenlemeleri de yaparak aşırı refactoring'e yol açabilir
    • Cursor Sonnet 3.7 komutları yerine getirmede düşük isabet gösterir → alakasız refactoring ortaya çıkabilir
  • İyileştirme yolları
    • LLM'ye, değişiklikten önce yalnızca refactoring aşamasında kod düzenlemesi yapması açıkça söylenmelidir
    • LLM'nin düzenleyebileceği kod kapsamı net biçimde tanımlanmalıdır → gereksiz değişiklikler önlenir

  • Example

    • LLM'ye import hatasını düzeltmesi söylendi → düzeltmeden sonra lambda fonksiyonlarına tip notasyonu ekledi
      • Bu notasyonların bir kısmı yanlış eklendi ve ajan döngüsüne yol açtı

Mise en place

  • Mutfakta mise en place, işe başlamadan önce tüm malzeme ve araçların hazırlanıp düzenlenmesidir
  • LLM'lerde mise en place, işe başlamadan önce gerekli kuralların, MCP'nin ve geliştirme ortamının eksiksiz hazırlanması anlamına gelir
    • Sonnet 3.7 bozuk bir ortamı düzeltmekte zayıftır
    • Sorunu StackOverflow'dan komut kopyalayıp yapıştırarak çözmeye çalışır → ortamı bozma riski vardır
    • Sonnet'in debugging döngüsüne girmemesi için ortam önceden doğru kurulmalıdır

  • Example

    • npm link sorunu nedeniyle VSCode, başka bir yerel projeden gelen import'ları tanıyamadı
      • Cursor, lint ve test düzeltmeleri sırasında bu soruna takıldı, ancak npm unlink çalıştırılması gerektiğini fark edemedi

Durumsuz araç kullanımı (Stateless Tools)

  • Araçlar durum saklamadan her seferinde bağımsız olarak çalıştırılmalıdır
    • Shell, mevcut çalışma dizini durumuna bağımlıdır → durum saklamanın yol açtığı karışıklıklar ortaya çıkabilir
    • Sonnet 3.7, mevcut çalışma dizini durumunu doğru şekilde takip edemiyor
    • Tüm komutların proje kök dizininde çalışabilecek şekilde ayarlanması gerekir
  • İyileştirme yöntemleri
    • Durum değişikliği gerektiren araç komutlarının kullanımını en aza indirin
    • Durumun mutlaka gerekli olduğu durumlarda, tutarlılığı korumak için mevcut durumu modele sürekli sağlayın

  • Example

    • Bir TypeScript projesi common, backend ve frontend olmak üzere üç modülden oluşuyorsa
      • Cursor kökten çalıştırıldığında uygun dizine cd yapılması gerekir → dizin karmaşası oluşur
      • Her modülü ayrı bir çalışma alanı olarak açıp çalışınca sorun çözüldü

Spesifikasyona uyum (Respect the Spec)

  • Sistemde değişiklik yapılırken değiştirilebilir kısımlar ile değiştirilemez kısımlar açıkça ayrılmalıdır
    • Herkese açık API değiştirildiğinde geriye dönük uyumluluğun bozulmaması gerekir
    • Harici sistemlerle entegrasyonda gerçekten var olan API'lere uyulmalıdır → istenildiği gibi değiştirilemez
    • Test başarısız olduğunda testi silmek yasaktır → neden bulunup düzeltilmelidir
  • LLM'nin sorunları
    • Spesifikasyonu ihlal etme olasılığı yüksektir → test silme, API değiştirme gibi işlemleri rahatça yapar
    • Spesifikasyona uymak sağduyulu görünse de prompt içinde açıkça belirtilmesi gerekebilir
    • Bazı sınırlar ancak kod incelemesiyle fark edilebilir

  • Example

    • Sonnet, testi düzeltmeyi başaramadıktan sonra test içeriğini assert True ile değiştirdi
    • public bir fonksiyon pass anahtarını içeren bir dict döndürüyor → Sonnet bunu pass_ olarak değiştirmeye çalıştı (reserved word sorunu)

Buldozer yöntemi (Bulldozer Method)

  • Buldozer yöntemi, basit tekrar eden işleri kullanarak sorunu çözme ve öğrenme etkisiyle hızı artırma stratejisidir
    • Yapay zeka ile kodlama doğası gereği tekrarlı işlerde güçlüdür → yeterli token kullanılırsa büyük ölçekli refactoring mümkündür
    • İnsanın "iş yükü çok fazla" diyerek vazgeçtiği sorunları bile LLM çözebilir
    • Ancak LLM aynı işi tekrar tekrar yapabilir; bu yüzden gerçekte ne yaptığını gözden geçirmek gerekir

  • Example

    • Haskell veya Rust'ta çekirdek bir fonksiyon değiştirildiğinde geniş kapsamlı refactoring gerekir
      • LLM, derleme hatalarını okuyup → düzeltip → yeniden derleme sürecini otomatikleştirebilir
    • Hardcode edilmiş test değerleri değiştirildiğinde LLM testleri yeniden çalıştırıp otomatik düzeltme yapabilir

Memento

  • LLM durum hatırlayamaz → her görevde kod tabanını baştan yeniden anlaması gerekir
    • Yalnızca prompt, açık/örtük bağlam ve agent modunda modelin yüklediği dosyalarla çalışır
    • Her görevde kod tabanını yeniden anlaması gerektiğinden, ilk kurulum başarısız olursa yanlış çalışma olasılığı yüksektir
  • Sorun önleme stratejileri
    • LLM'nin başvurabileceği belgeleri açıkça sağlayın
    • Modelin gerekli bilgiyi kolayca bulabileceği bir yapı kurun
    • Projenin genel bağlamını sunduktan sonra önemli değişiklik taleplerini iletin

  • Example

    • Sonnet 3.7'den mevcut bir proje için uçtan uca test planı oluşturması istendi
      • Projenin tüm amacının test olduğunu yanlış anlayıp README'yi test odaklı olacak şekilde değiştirdi

Gereksinimler, çözümler değil (Requirements, not Solutions)

  • Yazılım mühendisliğinde yaygın bir hata, gereksinimleri net tanımlamadan doğrudan çözüm önermektir
    • Problem alanı yeterince sınırlandığında yalnızca gereksinimlerin net tanımlanması bile çözümü fiilen belirleyebilir
    • Gereksinimler açık değilse çözüm üzerine gereksiz tartışmalar çıkabilir
  • LLM'nin sorunları
    • LLM gereksinimleri bilmez → eğitim gördüğü kalıplar içinden olasılığı en yüksek yanıtı üretir
    • Net gereksinimler olmadan görev verildiğinde alakasız sonuçlar ortaya çıkabilir
    • Yanlış yorum, prompt düzenlenerek düzeltilebilir → ancak yanlış yorum bağlamda kalırsa düzeltmek zorlaşır
  • İyileştirme yöntemleri
    • Belirli bir çözüm biçimi gerekiyorsa bunu açıkça talimat olarak verin
    • LLM komutları tam olarak uygular; bu yüzden yanlış yöntemle yönlendirilirse hatalı sonuç üretebilir

  • Example

    • Sonnet'ten görselleştirme üretmesi istendiğinde varsayılan olarak SVG oluşturur
      • "Etkileşimli" ifadesi açıkça belirtildiğinde React tabanlı bir uygulama üretir → tek bir anahtar kelime büyük fark yaratır

Bilimsel hata ayıklama (Scientific Debugging)

  • Hata düzeltme yaklaşımı ikiye ayrılır
    • Rastgele değişiklikler deneyip şansa bırakmak
    • Sistemin nasıl çalıştığını mantıksal olarak analiz ederek gerçek durum ile beklenen durum arasındaki uyumsuzluğun nedenini bulmak
    • Bilimsel hata ayıklama (mantıksal analiz), uzun vadede daha iyi bir yaklaşımdır
  • LLM'nin sorunları
    • LLM'nin akıl yürütme yeteneği sınırlıdır; bu yüzden bilimsel yaklaşım zordur
    • Önce "doğru cevabı tahmin eder", ardından hemen düzeltmeye girişir → başarısız olursa rastgele düzeltmeleri tekrarlar (agent loop)
    • Hata ayıklama için Grok 3, DeepSeek-R1 gibi akıl yürütme modelleri daha uygundur
  • İyileştirme yöntemleri
    • Modelden nedeni analiz etmesini istemek veya nedeni kullanıcı olarak vermek → düzeltme başarı oranını artırır
    • Sorunun nedenini doğru verirseniz model daha iyi çözüm önerebilir

  • Example

    • Sonnet 3.7'de, içinde pip bulunmayan varsayılan uv ortamında paket kurulum hatası oluştu
      • Nedeni saptayamayınca rastgele denemeleri tekrarladı → token israfı ve başarısız hata ayıklama

Otomatik kod biçimlendirme kullanın (Use Automatic Code Formatting)

  • Otomatik kod biçimlendirme araçları (gofmt, rustfmt, black vb.) tutarlı kod stilini korumada faydalıdır
    • LLM, mekanik kurallara (ör. boş satırlarda boşluk olmaması, 78 karakter satır uzunluğu sınırı vb.) uymakta zorlanır
    • Biçimlendirme araca bırakılmalı, LLM ise daha karmaşık işlere odaklanmalıdır
  • Aynı ilke lint düzeltmeleri için de geçerlidir
    • Otomatik düzeltilebilen lint kurallarının kullanılması önerilir
    • LLM kaynakları karmaşık sorun çözümüne odaklanacak şekilde kullanılmalıdır

Kuyruğun köpeği sallaması (The Tail Wagging the Dog)

  • Küçük bir sorunun daha önemli bir sorunu yönlendirdiği durumu ifade eder
    • Düşük seviyeli bir problemi çözmeye aşırı takılıp kod yazmanın asıl amacını unutma durumu yaşanabilir
    • LLM, sohbet oturumundaki tüm bilgileri bağlama dahil eder → neyin daha önemli olduğunu ayırt etmekte zorlanır
  • İyileştirme yöntemleri
    • Başlangıçta net bir prompt verin → LLM'nin önemli işlere odaklanmasını sağlayın
    • Claude Code, alt agent'lar aracılığıyla belirli görevleri yürütüp genel bağlamın kirlenmesini önler

  • Example

    • LLM'den belirli bir işi nasıl yapacağını düşünmesi istendiğinde, düşünmek yerine işi gerçekten yapmaya çalışabilir

Dosya boyutlarını küçük tutun (Keep Files Small)

  • Kod dosyalarının boyutu üzerine tartışmalar uzun süredir devam ediyor
    • Tek sorumluluk ilkesi (dosya başına bir sınıf) uygulamak vs duruma göre büyük dosyalara izin vermek
    • Dosya boyutu fazla büyürse, RAG sistemlerinde dosya düzeyinde bağlam yüklenirken sorun çıkabilir
    • Cursor gibi IDE'lerde patch uygulama başarısız olabilir → başarılı olsa bile uygulama süresi uzar
      • Örnek: Cursor 0.45.17'de 64KB'lık bir dosyadaki 55 değişikliğin uygulanması kayda değer zaman aldı
    • Sonnet 3.7, 128KB üzerindeki dosyaları düzenlemekte zorlanır (200K token context window sınırı)
  • İyileştirme yöntemleri
    • Dosya boyutlarını küçük tutun → LLM import gibi işlemleri otomatik olarak halledebilir

  • Example

    • Sonnet 3.7, 471KB'lık bir Python dosyasında küçük bir test sınıfını taşımaya çalıştı
      • Değişiklik küçüktü ancak Cursor patcher değişiklikleri uygulayamadı

Sınırlarını Bilmek (Know Your Limits)

  • Araç eksikliği ya da yetenek sınırı olan durumlarda sorunu fark edip yardım istemek gerekir
    • Sonnet 3.7 kendi sınırlarını fark etmede zayıf
    • Net prompt verildiğinde sınırlarını fark edebilir → belirli konularda halüsinasyon üretmesi için uyarı ayarlamak gerekir
  • Sorunlar
    • Sonnet 3.7, shell komutlarını çalıştırabildiğini yanlış sanıyor
      • Shell komutu olmadığında rastgele shell script üretmeye çalışabilir → ortamın bozulma riski
      • "X'i çalıştıracağım" dedikten sonra tamamen farklı bir Y çağrısı üretmesi mümkün
  • İyileştirme yolları
    • Prompt'u değiştirmek veya yalnızca istenen işi yapan özel araçlar sağlamak
      • Belirli araçlar sağlandığında alakasız shell çağrıları önlenebilir

  • Example

    • Sonnet 3.7, bir dosyaya çalıştırma izni verirken alakasız bir shell script üretmeye çalıştı
      • Komut hatası sonrası yanlış düzeltme denemeleri tekrar tekrar yaşandı

Dokümanları Oku (Read the Docs)

  • Yeni bir framework ya da kütüphane öğrenirken öğretici koddaki değişikliklerle basit işler yapılabilir
    • Ancak nihayetinde dokümanları baştan sona okuyup sistemin nasıl çalıştığını bütünüyle anlamak gerekir
  • LLM'in güçlü yönleri
    • Popüler framework'ler çoğu zaman önceden eğitildiği için kullanım biçimlerinin çoğunu hatırlar
    • Ancak niş araçlarda veya bilgi kesim tarihinden sonra çıkan araçlarda halüsinasyon görülebilir
    • Sonnet web aramayı desteklemiyor → dokümanları elle sağlamak gerekir
      • Cursor'da URL verildiğinde otomatik olarak bağlama eklenebilir

  • Example

    • LLM'den Python function calling için YAML yazması istendiğinde hatalı bir yapılandırma üretti
      • Doküman verildikten sonra başarıyla düzeltildi ve çıktı biçimi iyileştirildi

Kültür Stratejiyi Yener (Culture Eats Strategy)

  • Ekibin kültürü, stratejiyi uygulama becerisi üzerinde belirleyici etkiye sahiptir
    • LLM, önceden öğrendiği stillere ve context window'a göre kod üretir
    • Bağlamda sık görünen kütüphaneleri veya stilleri tercih eder
      • Açıkça belirtilmezse varsayılan stilini uygular
  • LLM stilini değiştirme stratejileri
    • Cursor kurallarını değiştirmek (prompt'u değiştirmek)
    • Mevcut kod stilini istenen biçime refactor etmek → sonraki token tahminini etkiler
    • Kod tabanının büyüklüğü prompt'tan daha fazla etki eder → kod tabanını değiştirmek daha temel çözümdür

  • Example

    • Sonnet 3.7 Python'da senkron kodu tercih ediyor
      • Asenkron kod üretmesi için mevcut kodun büyük kısmı async olarak taşındı ve başarı sağlandı

Yürüyen İskelet (Walking Skeleton)

  • Yürüyen iskelet, uçtan uca çalışan asgari bir sistem kurma stratejisidir
    • Mükemmel olmasa da önce tüm sistem çalışır hale getirilir, sonra ayrıntılar iyileştirilir
    • LLM ile kodlama çağında tüm sistemi hızlıca kurmak daha kolay hale geldi
    • Sistem çalıştığında bir sonraki adım netleşir → hızla çalışan bir duruma ulaşmak önemlidir
    • LLM yazdığı kodu doğrudan kullanamadığı için çalışan bir durum elde etmek önemlidir

Üç Kuralı (Rule of Three)

  • Aynı kodun kopyalanmasına iki defaya kadar izin verilir, üçüncü kopyada refactor gerekir
    • DRY (Don't Repeat Yourself) ilkesinin iyileştirilmiş bir versiyonu
    • Tekrarı kaldırma zamanını netleştirir → üçüncü kopyada refactor yapılır
  • LLM'in sorunları
    • LLM'ler kod tekrarları üretmeye eğilimlidir
    • Prompt olmadan düzeltme istendiğinde kodun tamamını yeniden kopyalayıp değişikliği öyle yapar
    • Tekrarı kaldırma ancak model bunu kendiliğinden seçerse olur → açık talimat gerekir
  • İyileştirme yolları
    • Tekrarı kaldırması açıkça istenmelidir
    • Mevcut kodda çok tekrar varsa model bu tekrarları sürdürmeye devam edebilir

  • Example

    • LLM'den test kodu yazması istendiğinde aynı mantık birden fazla testte tekrarlandı
      • Açıkça yardımcı metod oluşturması istendikten sonra sorun çözüldü
      • Ajan modu

İlgili okumalar

1 yorum

 
GN⁺ 2025-03-20
Hacker News görüşleri

  • LLM'ler insanlardan farklı şekillerde hata yapar ve bu hataları yakalamak zordur

    • İnsan hatalarını yakalama konusunda uzun deneyim var, ancak LLM'lerin düşünme biçimini anlamak zor
    • LLM hatalarını yakalayacak sistemler tasarlamak zor

  • LLM'ler gereksinimleri bilmediğinde, eğitim verilerindeki en olası cevabı doldurur

    • Müşterinin ne istediği tam olarak açıklanmalı ki yapay zeka programcıların yerini alabilsin

  • Yazılım mühendisliğinde gereksinimleri netleştirmek önemlidir

    • Gereksinimler netleşince çözüm de doğal olarak belirlenir
    • Yeni bir framework veya kütüphane öğrenirken dokümantasyonu dikkatle okumak faydalıdır
    • Bug düzeltirken sistemin varsayımlarını sistematik olarak gözden geçirmek önemlidir
    • Kod tekrarı üçüncü kez ortaya çıktığında refactor etmek iyi olur

  • LLM'ler kodlama yeteneği açısından "çok zeki bir junior programcı" seviyesindedir

    • Büyük resmi görme yetenekleri zayıftır ve sadece isteneni yaparlar
    • Modellerin zamanla gelişmeye devam etmesi bekleniyor

  • LLM'ler çok fazla cevap vermeye çalışır

    • Yeterli veri verilmezse yanlış cevaplar üretirler
    • LLM'lerin "daha fazla bilgiye ihtiyacım var" diyebilmesi iyi olurdu

  • Blogdaki yazılar arttıkça düzenleme ihtiyacı doğuyor

    • İyi bir organizasyon sistemi bulunamamış

  • LLM'lerle kod yazarken bazı faydalı tavsiyeler

    • Statik tip kullanımı konusunda farklı görüşler var
    • Clojure, Typescript'ten daha iyi sonuç veriyor
    • LLM'ler fonksiyon merkezli yaklaşıma daha uygundur

  • LLM'ler hesaplama ve aritmetikte zayıftır

    • Kod üretirken sayıları doğru yerden almak önemlidir
    • LLM'in ürettiği kodu debug etmek zaman alır

  • İnsan yazılımcılarla birlikte düşünülmesi gereken noktalar var

    • Ürün yöneticileri de buna dikkat etmeli

  • Üç farklı LLM'in var olmayan bir "bug" bulduğu bir örnek

    • Kod optimize değildi ama bug da değildi
    • Kod blokları arasındaki mesafe kısaydı