Oxide'nin LLM Kullanımı

 (rfd.shared.oxide.computer)
4 puan yazan GN⁺ 2025-12-08 | 1 yorum | WhatsApp'ta paylaş
  • Büyük dil modeli (LLM) iş yapış biçimini kökten değiştiriyor ve Oxide bu modelin şirket içinde nasıl kullanılacağını net bir şekilde tanımladı
    • Oxide, yerinde (on-premise) veri merkezleri için entegre donanım ve yazılım üreten talep odaklı bir hesaplama altyapısı girişimidir
  • LLM kullanımında temel ilke olarak sorumluluk, titizlik, empati, takım çalışması ve aciliyetin dengesini benimsiyor
  • Belge özeti ve anlama, kod incelemesi, hata ayıklama gibi alanlarda yararlı olsa da, yazma veya kod yazmada insanın yargısı ve sorumluluğu zorunlu
  • LLM'nin ürettiği çıktılar her zaman insan tarafından doğrulanıp sorumluluğu üstlenilen bir yapıda kalmalıdır
  • Oxide, LLM kullanımını teşvik etmesine rağmen, bunu ürün, müşteri ve meslektaşlar için sorumluluk anlayışına dayandırıyor

LLM Kullanımının Değer Kriterleri

  • Oxide, LLM kullanımını şirketin temel değerlerine göre değerlendirir
    • Sorumluluk (Responsibility) : LLM yalnızca bir araçtır ve sonuçlardan tamamen insan sorumludur
    • Titizlik (Rigor) : Dikkatli kullanıldığında düşünceyi iyi biçimde olgunlaştırabilir, ancak dikkatsiz kullanım düşüncenin kalitesini düşürür
    • Empati (Empathy) : Dilin alıcısı ve yazarı her ikisinin de insan olduğunu fark ederek, insan merkezli iletişimi sürdürmeli
    • Takım Çalışması (Teamwork) : LLM kullanımı, ekip içi güveni zedelememeli ve kullanıldığı bilgisinin paylaşılması sorumluluktan kaçış gibi görünmemelidir
    • Aciliyet (Urgency) : Hız artışı mümkün olsa dahi, diğer değerler feda edilmemelidir

LLM'nin Çeşitli Kullanım Şekilleri

LLM'ler Okuyucu Olarak

  • LLM, belge özeti ve soru-cevap görevlerinde çok başarılıdır ve büyük bir miktarda materyali hızlıca anlamaya yardımcı olur
  • Bununla birlikte veri gizliliğinin sağlanması gerekir; yüklenen belgelerin modele öğrenme amacıyla eklenmemesi için ayar yapılmalıdır
  • Belge anlama için yardımcı bir araç olarak faydalıdır ancak, doğrudan okunması gereken durumların yerine geçmemelidir

LLM'ler Editör Olarak

  • Tamamlanmış bir belgenin yapısının ve üslubunun iyileştirilmesi konusunda etkilidir ve son aşamalarda kullanıldığında faydalıdır
  • Ancak LLM'ler aşırı iyimser geri bildirim verme eğiliminde olduğundan eleştirel analizde eksik kalabilir
  • Taslak aşamasında kullanılırsa, yazarın kendine özgü sesini kaybetme riski vardır

LLM'ler Yazar Olarak

  • LLM'nin ürettiği içerikler çoğunlukla klasikleşmiş, otomatik üretimin izlerini barındıran olur
  • Otomatik üretilen içerik, düşüncenin samimiyetini ve okuyucunun güvenini zedeleyebilir
  • Okuyucu, yazanın içeriği anladığını varsayar; ancak LLM tarafından üretilen metin bu varsayımı bozar
  • Oxide, tüm ekip üyelerinin yazma kapasitesine sahip olduğunu varsayarak, LLM'yi yazının ana üreticisi olarak kullanmaz
  • Buna karşılık, fikirleri düzenleme veya yardımcı araç olarak sınırlı şekilde kullanılabilir

LLM'ler Kod Gözden Geçiren Olarak

  • LLM, belirli türdeki kod problemlerini tespit etmede faydalı olsa da, insan incelemesini tamamıyla ikame edemez
  • Önerileri mantıksız olabileceği veya bağlamı kaçırabileceği için yalnızca yardımcı bir araç olarak kullanılmalıdır

LLM'ler Hata Ayıklayıcı Olarak

  • LLM, hata ayıklama fikirleri doğuran bir “rubber duck” rolü üstlenebilir
  • Gerçekten sorun çözme yeteneği sınırlıdır ancak, yeni yaklaşımları tetikleyen bir kıvılcım olarak yararlıdır

LLM'ler Programcı Olarak

  • LLM, kod üretme kapasitesi açısından son derece yetkin ve deneysel/yardımcı kod yazımı için uygundur
  • Ürün koduna ne kadar yakınsa doğrulama ve sorumluluk o kadar kritik hale gelir
  • LLM'nin yazdığı kod, yazar tarafından doğrudan incelenmeli (self-review) ve ardından eş meslektaşla yapılan incelemeden önce doğrulanmalıdır
  • Kod inceleme sırasında kodu tamamen yeniden üreterek yanıt verme davranışı yasaktır, çünkü bu durumda tekrar tekrar gözden geçirme mümkün olmaz
  • Kod üretiminde de sorumluluk, titizlik, empati ve takım çalışması korunmalıdır

Operasyon ve Kılavuzlar

  • LLM kullanımına ilişkin teknik ayrıntılar ve iç yönergeler GitHub'daki iç belgelerde derlenmiştir
  • Oxide, LLM kullanımını özendirir ancak sorumlu kullanımı temel alır
    • Ürün kalitesi, müşteri güveni ve meslektaşlarla iş birliği konusunda sorumluluk bilincini en üst öncelikte tutar

İlgili okumalar

1 yorum

 
GN⁺ 2025-12-08
Hacker News görüşleri

  • Bryan’ın yazısı dengeli ve gerçekçi bir bakış açısı sunuyor
    Oxide junior mühendis işe almadığı için bunun RFD’de yer almadığını düşünüyorum
    Bryan, 30 yılı aşkın süredir zor yazılım ve donanımlarla çalışan, gerçekten zor bir programı (OS) tamamlamış bir mühendis
    LLM’lerle çalışma biçimi, 2025’teki junior mühendislerden çok farklı
    Günümüz juniorlarının LLM yardımı olmadan neredeyse hiç kod yazmamış olması muhtemel

    • Eskiden iş yerinde veri ingest modeli üzerinde aylarca çalıştığımız dönemler olmuştu
      O kadar sıkıcıydı ki işe gitmek bile zordu; şimdi ise bunu LLM ile birkaç dakikada bitirebilirmişim gibi geliyor
      O zaman harcadığım zaman şimdi düşününce neredeyse delilik gibi geliyor
    • İlk web tasarımı dersimde hocanın bir dönem boyunca HTML, CSS, JS’nin “temel ilkelerini” Notepad ile öğrettiğini hatırlıyorum
      Ancak ondan sonra Dreamweaver’ı tanıttı ve üretkenlik on kat arttı
    • LLM’deki “zanaatkârlık vs pratiklik” gerilimi ilginç
      Güvenlik araştırması gibi sonucun net olduğu alanlarda LLM çok başarılı ama ince yargı gerektiren sorunlarda zayıf
      Bu yüzden tekrarlı ve sistematik kısımları LLM’ye bırakıp, muhakeme gerektiren kısımları insanın üstlenmesi ideal görünüyor
    • 20 yıldan uzun süredir programlama yapıyorum ve LLM kullanmaya karşı görünmez bir direnç hissediyordum
      Ama artık bunun “yeni bir programlama biçimi” olduğunu kabul ettim; bunu fark edince kendimi hatta daha genç hissettim
    • Cümlede “LLM’in izlerini fark eden insanlar” ifadesinin hemen ardından em-dash (—) gelmesi komikti
      Bugünlerde em-dash kullanınca yazının AI tarafından yazıldığı sanılması biraz sinir bozucu

  • Oxide’ın RFD’sini okurken çoğunlukla başımı sallayarak onayladım ama “LLM baştan iyi kod yazar” kısmına katılmıyorum
    LLM, **“boş sayfa sendromu”**nu çözmekte iyi ama gerçekten deploy edilecek kodun onun çıktısından epey uzak olduğunu düşünüyorum
    Bu, bir tür “ilerleme yanılsaması” olabilir

    • Yazı yazmak kişisel bir ifade biçimi ama kod, problem çözme aracıdır
      LLM, veri setinde sık görülen “iyi çözümleri” öğrenerek problem çözmede güçlü hale geliyor
      Buna karşılık insan ifadesinin özü çeşitlilik olduğu için ortalama ifade ilgi çekiciliğini kaybediyor
      Sonuçta LLM, çözülmemiş problemleri çözme yeteneğini sınırlayabilir
      Kod kalitesinin düşük olmasının nedeninin context window sınırı olduğunu düşünüyorum
    • Klişe yazı kötü olabilir ama klişe kod aslında iyidir
    • “Başka model dene” itirazı artık LLM dünyasının **“No True Scotsman”**ı gibi geliyor
      Fonksiyon düzeyinde üretim fena değil ama tüm özelliği ona bırakırsan yapı ve arayüz darmadağın oluyor
      Yazı yazmaya benzetirsek, sadece paragrafın ilk ve son cümlesini verip arasını doldurtmak kadarının uygun olduğunu düşünüyorum
    • İyi bildiğimiz alanlardaki haberlerde hataları hemen fark ederiz ama bilmediğimiz alanlarda olduğu gibi inanırız
      Programcılar kod kalitesini değerlendirebilir ama yazı için aynı şey geçerli değil
    • LLM kalitesi modele göre değişiyor
      Eski ya da ucuz model kullanıp kötü izlenim edinen çok kişi var

  • “LLM, LLM’in yazdığı metni iyi ayırt eder” iddiası bana şüpheli geliyor
    Bunun veriyle kanıtlanıp kanıtlanmadığını merak ediyorum

    • Oxide’dan Bryan bunu bizzat açıklıyor
      Şirketin işe alım süreci yazı odaklı olduğu için son dönemde LLM ile yazılmış başvurular patlama yaşamış
      RFD 0003 ve kariyer sayfasında da dikkat edilmesi gerektiği yazıyor ama yine de olmaya devam ediyor
      podcast bölümü de ilgili vakaları ele alıyor
      LLM her AI metnini yakalayamasa da, şüpheli durumlarda tespit destek aracı olarak faydalı olduğu söyleniyor
    • LLM tarafından yazılan metni ayırt etmek için, metnin yarısını LLM’ye verip kalanını tahmin ettirerek n-token olasılığını karşılaştırma fikri öneriliyor
      Denemedim ama ilginç bir yaklaşım
    • LLM’in ne kadar devreye girdiğine göre (tam yazım, özetleme, redaksiyon vb.) tespit zorlaşıyor
      Bu yüzden mevcut teknolojiyle kusursuz tespit mümkün görünmüyor

  • LLM ile üretilen kodda sorumluluk mühendise aittir
    Kişinin kendisi incelemediği kod, review konusu olamaz
    Benim sürecim şöyle:

    1. ilgili kodu gir → 2) hedefi açıkla → 3) tasarımı gözden geçir → 4) kod üret → 5) test et ve düzelt → 6) tüm kodu baştan sona dikkatlice oku ve manuel düzeltmeler yap
      Son adım en zor olanı ve duygusal olarak atlamak istiyorsun
      Bu yaklaşım, mimari düzeyde düşünmeyi korurken tekrarlı işleri azaltıyor
      Ama LLM deterministik olmadığı için derleyici gibi öngörülebilir bir araç değil
    • Pratikte toplam sürenin çoğunu 6. adım alıyor
      Kod düzgün çalışmazsa daha fazla düzeltme gerekiyor
      Bu yüzden LLM gerçekten zaman kazandırıyor mu emin değilim
      1. adımdan önce test kodunu ürettirip önce fail edip sonra geçmesini sağlayan bir adım eklemek iyi olabilir
    • Manuel düzeltme yerine tüm değişiklikleri LLM’nin yönlendirmesine izin verirsen, oturum içinde bilgi tutarlılığı korunabilir
    • Ama bu durumda mühendisin özsaygısı ve sahiplik hissi zedeleniyor gibi geliyor
      Makinenin yaptığı kodu cilalamaya duygusal olarak bağlanmak zor

  • LLM’in ürettiği kodda telif ihlali ihtimalinden bahsedilmemesi tuhaf
    GitHub kodu birebir kopyalanıyor olabilir; bu da açık kaynak şirketleri için önemli bir konu

    • Eğer LLM çıktısı telif hakkına konu değilse, Copyleft lisanslı kodun hukuki statüsü de belirsizleşiyor
      Telif hakkı doğması için yeterli insan katkısı gerekiyor ama bunun eşiği net değil
    • Bunun mahkemede ele alındığı bir vaka olup olmadığını merak ediyorum
    • Güncel LLM’lerin hâlâ bu sorunu üretip üretmediğini ya da bunu insanlardan daha sık yapıp yapmadığını da merak ediyorum

  • Belge iyi yapılandırılmış ama “LLM’yi okuma yardımcısı olarak kullanmak sorun değil” kısmı bana çelişkili geliyor
    Kusursuzsa zaten orijinalinden farkı olmaz, kusursuz değilse de yanlış okuma riski var
    Gerçekten de LLM’nin belgeyi düzgün okumayıp sadece içindekiler tablosuna bakarak çıkarım yaptığı durumları sık görüyorum
    İçerik ile okur arasına bir çeviri katmanı girme riski var

    • Bence RFD, “okuma”dan çok “yazma”ya dair toplumsal beklentiler üzerineydi
    • Üç teknik kitabı karşılaştırmasını isteyip yanlış sonuç aldıysan bu aracı kötü kullanma örneğidir
      Tüm metni doğrudan context window içine koymak gerekir
      Yine de üç kitabın tamamı LLM sınırlarını aşacak kadar büyük olabilir

  • “LLM’in ürettiği yazı düşüncenin sahiciliğini bile aşındırır” sözüne katılıyorum
    İnsanın doğrudan yazdığı metin değerlidir ama LLM’in yazdığı metin değeri seyreltilmiş bir kopya gibi hissettiriyor
    Hatta prompt’u okumayı tercih ederim sözü akılda kalıcıydı

    • İnsan sanatı bireyin iç dünyasını ifade eder ama LLM, kolektif ortalamanın çıktısıdır
      İlginç ve özgün düşünceler ortalamadan sapılan noktalarda ortaya çıkar
      Çeviri gibi durumlarda ana dili olmayan birinin kendi düşüncesini daha iyi ifade etmek için LLM kullanmasını anlayabiliyorum ama
      alıcı taraf, o ifadenin gerçekten o kişiye ait olup olmadığından şüphe eder
    • Naur’un “Programming as Theory Building” metnini hatırlatıyor
      Yorumlar, koda sığmayan kuramsal bağlamı ifade etme çabasıdır
      LLM böyle bir “teori”ye sahip olamayacağı için gerçekten değerli yorumlar üretemez
    • LLM’e özgü **“AI yazı üslubu”**ndan hoşlanmıyorum ama birçok kişi bunu fark etmiyor
      Mesela /r/SaaS gönderilerinin çoğu LLM yazmış gibi geliyordu ama
      duygusal hikâye anlatımıyla okuyucu tepkisini iyi yönlendiriyordu
      Ben de belge ya da benchmark yazımında LLM kullanıyorum
      Ana dili İngilizce olmayanların teknik belge yazmasında da yardımcı oluyor ama kalite farkı büyük
      Sonuç olarak bilgi aktarmaya yönelik yazılarda LLM giderek daha kullanışlı hale geliyor
    • “Prompt’u okumak isterim” hissi haber başlıklarına bakarken de geliyor
      Ne yazıldığından çok neden yazıldığı ilgimi çekiyor
    • LLM ortalama cümleleri iyi tahmin ediyor ama yaratıcı cümleleri neredeyse hiç tutturamıyor
      Bu yüzden düşüncelerim çok özgün olmasa bile istatistiksel olarak nadir olması bana teselli veriyor

  • LLM ile yazılmış metinlerin okunmaya değer olmadığını düşünüyorum
    Oxide’ın kod dışı çıktılarda LLM kullanmama konusunda net bir ilke koyması güzel
    Kod review’da da aynı şekilde, üretilen kodu önce yazan kişi incelemeli
    Bu kültürün gerçekten korunup korunamayacağını göreceğiz ama yön akıllıca

  • LLM’in çalınmış verilerle eğitildiği algısı çok güçlü
    Bunun kamu algısı açısından hesaba katılması gerektiğini düşünüyorum
    Bu ister etik sorun olsun ister marka riski, şu anda kesinlikle önemli bir unsur

    • Bu belgeyi halka dönük değil, iç teknik belge olarak görüyorum
      Amaç etik pozisyon almak değil, teknik yönergeler sunmak
    • Yazıda sözü edilen “güvenin çöküşü” aslında bu meseleyi başka bir dille anlatıyor gibi
      LLM’in yazdığı metin sahiciliğini kaybediyor ve okur, düşüncenin bile otomatikleştirildiğini hissediyor
      Sonuçta bu, karşılıklı güvene zarar verebilir

  • “Yazmanın, okumaktan daha büyük bir zihinsel emek olduğu” sözü ilginç
    Ama kod için bunun tersinin geçerli olduğunu düşünüyorum

    • Berbat yazı işe yaramaz ama berbat kod, en azından çalışıyorsa Jira ticket’ını kapatabilir
      Bu yüzden kötü kod çok daha fazla
      Buna karşılık iyi yazılmış kod, tıpkı iyi yazı gibi öğrenme değeri taşır ve içgörü gerektirir
    • Kernighan yasası alıntılanıyor
      “Debugging, code yazmaktan iki kat daha zordur.
      O hâlde yazarken olabildiğince akıllı davranırsanız, debug etmek sizin için imkânsız hale gelir.”
      laws-of-software.com bağlantısı