Google, Haziran'da yapay zeka ile son iki yılın toplamından daha fazla Chrome hatasını düzeltti

 (blog.google)
1 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Chrome, Gemini tabanlı ajanlar ile güvenlik açığının bulunmasından sınıflandırma, düzeltme, dağıtım ve güncellemenin uygulanmasına kadar süreci otomatikleştiriyor; Chrome 149 ve 150'de önceki 23 milestone'un toplamından daha fazla olan 1.072 güvenlik hatası düzeltildi
  • Açık tespit sistemi; birden çok model, Chrome'un CVE ve Git geçmişi bilgi tabanı, SECURITY.md ve ayrı bir eleştiri ajanını birleştiriyor; internet ve yerel sistem erişiminin sıkı biçimde sınırlandığı bir ortamda çalışıyor
  • Otomatik sınıflandırma; spam ve tekrarların ayıklanması, yeniden üretim ve stack trace toplanması, önem derecesi gibi meta verilerin eklenmesi ve sorumlu atamasını yaparak ayda yüzlerce saatlik geliştirici işini azalttığı tahmin ediliyor
  • Düzeltme yayımlandıktan sonra istismara kadar geçen patch gap süresini azaltmak için haftada iki güvenlik sürümü test ediliyor; yeniden başlatmadan alt süreçleri değiştiren dinamik yama ve macOS otomatik yeniden başlatma geliştiriliyor
  • Yalnızca tek tek hataları düzeltmekle kalmayıp MiraclePtr, std::span ve Rust ile bellek güvenliğini artırıyor; gönderim anında AI kontrolü ve 2.300'den fazla harici bağımlılığın otomatik güncellenmesiyle açıkların sisteme girmesi önleniyor

Yapay zekanın değiştirdiği güvenlik hatası yaşam döngüsü

  • LLM'ler, yalnızca insanların güvenlik uzmanlığıyla ele alınabilecek ölçeğin ötesine geçerek otomatik açık tespitini genişletti; Chrome da yüzlerce güvenlik hatasını daha hızlı bulup düzeltmek için yapay zekadan yararlanıyor
  • Sıradan işlev hataları arayüzün donması gibi sorunlara yol açarken, güvenlik hataları saldırganların kişisel verileri okumasına veya kullanıcının haberi olmadan bilgisayarı kontrol etmesine yarayan exploit'lerde kullanılabiliyor
  • Güvenlik hataları keşif, sınıflandırma, düzeltme, düzeltmeyi içeren Chrome dağıtımı, tarayıcının yeniden başlatılması ve uygulama sırasıyla ele alınıyor; amaç tüm adımları mümkün olduğunca kısaltmak

Açık tespitinin genişletilmesi

  • Chrome güvenlik ekibi, yıllar içinde LLM tabanlı tespit tekniklerini geliştirdi
  • 2026'nın başında kurulan Gemini ajan harness'i, daha geniş Chrome kod tabanında tespit verimini artırıp yanlış pozitifleri azalttı
    • Bulunan sandbox escape hatası, ele geçirilmiş bir renderer'ın tarayıcıyı kandırarak yerel dosyaları okutmasına yol açabiliyordu ve kodda 13 yıldan uzun süre kalmıştı
  • Tespit harness'ine şu yetenekler eklendi
    • Açık ağırlıklı modeller ile kapalı modellerin güçlü yönlerinden yararlanan model birlikte çalışabilirliği
    • Mevcut tüm CVE'leri ve Chrome'un tüm Git geçmişini içeren bilgi tabanı
    • Güven sınırları ile tehdit modelini net biçimde aktaran SECURITY.md yazım kılavuzu
    • Ayrı bir bağlamda SECURITY.md'yi okuyan eleştiri ajanı
    • Modellerin deterministik olmamasını ve zamanla iyileşmesini hesaba katmak için kod tabanının yinelenen taraması
  • Yapay zeka, genel internete erişemeyen kilitli cihazlarda yalnızca kaydedilmiş kaynak kodu analiz ediyor
    • Tüm ağ istekleri yakalanıyor ve uygulama ile hedef tabanlı izin listeleri uygulanıyor
    • Modeller sınırsız modda çalıştırılmıyor; alt ajanların sistem değişiklikleri yapması ve belirtilen kaynak dizini dışındaki dosyalara erişmesi kısıtlanıyor
  • Yapay zeka tespiti mevcut güvenlik testlerinin yerini almıyor
    • Fuzzing, birbirinden uzak kod bölgeleri arasındaki uzun menzilli etkileşimlerde veya alakasız görünen çoklu işlemlerin birleşiminden doğan hatalarda özellikle etkili
  • Harici araştırmacılar, Chrome Vulnerability Reward Program üzerinden zor ve etkisi yüksek açıkları bulmaya devam etmeleri için ödüllendiriliyor
    • 2026 başında her tür bildirimin sayısı arttı; Mart ayında 2025'in tamamından daha fazla hata bildirimi alındı
    • Buna yanıt olarak VRP değiştirildi; iç tespit sonuçlarına ek değer sunan ve otomatik işleme hattının kolayca kabul edebileceği bildirimlere odaklanılıyor

Otomatik sınıflandırma ve çok ajanlı düzeltme

  • Geçmişte tek bir güvenlik bildirimini sınıflandırmak 5 dakikadan 30 dakikanın üzerine kadar sürüyor ve büyük ölçüde insan uzmanlığına dayanıyordu; bugün kural tabanlı sistemlerle AI birleştirilerek iş hacmi ve doğruluk artırılıyor
  • Otomatik sınıflandırma dört adımda ilerliyor
    1. Spam ve tekrarlar ayıklanıyor; kabul koşullarının karşılanıp karşılanmadığı ve Chrome güvenlik açığına dair net bir açıklama olup olmadığı kontrol ediliyor
    2. Kavram kanıtı ve yeniden üretilebilirlik doğrulanıyor, ilgili işletim sistemi ve tarayıcı sürümünde test ediliyor, ardından stack trace gibi bilgiler ekleniyor
    3. Hatanın ilk ne zaman sisteme girdiği ve önem derecesi ekleniyor
      • Otomatik uygulamayı kolaylaştırmak için önem derecesi yönergeleri daha net hale getirildi
      • Geliştiriciler yanlış önem derecesi puanını değiştirebilir ve SECURITY.md ile güvenlik sınırı bilgisini tamamlayabilir
    4. Sorun doğru bileşene ve sorumlu kişiye otomatik atanıyor
  • Kesin ölçmek zor olsa da otomatik sınıflandırmanın her ay yüzlerce saat geliştirici işini azalttığı tahmin ediliyor
  • Açıkların düzeltilmesinde çok ajanlı iş akışı kullanılıyor
    • Düzeltme ajanı, soruna özel bağlamı alıp birden fazla aday yama üretiyor
    • Eleştiri ajanı en uygun adayı değerlendiriyor ve geliştirici incelemesi için gerekli çıktıları hazırlıyor
    • İki ajan, kod incelemesine benzer yinelemeli çalışmalarla işlev davranışını, Chromium ve Google stilini, yerel kod teamüllerine uyumu kontrol ediyor
    • Test yazma ajanı, geliştirici incelemesinden önce Chrome'un desteklenen platform ve yapılandırmalarında testleri doğrulayarak en fazla birkaç haftalık zaman tasarrufu sağlıyor
  • Şu anda açıkların çoğunda LLM'ler aday düzeltmeler üretiyor
    • Chrome 149 ve 150'de 1.072 güvenlik hatası düzeltildi ve bu sayı önceki 23 milestone'un toplamını aştı
  • DeepMind ve Project Zero ile geliştirilen Big Sleep ve CodeMender, CI'a entegre edilerek tüm CL'leri her 24 saatte bir tarıyor
    • Yalnızca Mayıs ayında, kritik S1+ sorunları da dahil 20'den fazla açık production'a ulaşmadan engellendi

Patch gap'in kısaltılması ve güncellemenin uygulanması

  • Düzeltme kodu herkese açık açık kaynak deposuna girdikten sonra kullanıcıya dağıtılana kadar saldırganların bunu tersine mühendislikle istismar edebildiği N-day saldırı aralığına patch gap deniyor
  • Ana dala giren düzeltmelerin, kullanıcıların çoğunun kullandığı Stable kanalına ulaşması genelde birkaç hafta sürüyor
    • Önem derecesine göre düzeltmeler doğrudan mevcut Stable sürüm dalına birleştiriliyor ve yeni çakışma ya da regresyonlar izlenmeye devam ediliyor
    • Büyük Chrome milestone'ları iki haftalık düzene geçtiğinden her hafta güvenlik güncellemesi sunuluyor
    • Yapay zeka tabanlı saldırı hızına karşılık verebilmek için haftada iki güvenlik sürümü de test ediliyor
  • Stable'a ulaşan tüm güvenlik hataları, içte mi dışta mı bulunduğuna bakılmaksızın herkese açık biçimde belgeleniyor
    • Manuel darboğazları kaldırmak ve keşiften duyuruya kadar geçen süreyi azaltmak için yamalardan sürüm notları ve CVE açıklamalarını otomatik üretme çalışmaları sürüyor
  • Chrome, 2008'den beri yeni binary'leri arka planda indirip hazırlayan ve bir sonraki yeniden başlatmada uygulayan otomatik güncelleme kullanıyor
    • Sınıflandırma, düzeltme, test ve dağıtım 1-2 gün sürse de kullanıcının yeniden başlatmasına kadar geçen bekleme de N-day istismar riskine ciddi katkı yapabiliyor
    • Yeniden başlatma işi böldüğü ve ayrıca zaman ayırmayı gerektirdiği için kullanıcılar bunu ertelemeye yatkın
  • Yeniden başlatma yükünü kullanıcıya bırakmamak için yeni özellikler geliştiriliyor
    • Dinamik yama, Chrome'un çok süreçli yapısından yararlanarak Renderer ve GPU gibi arka plan alt süreçlerini sırayla yeni binary ile değiştiriyor; amaç çoğu durumda tüm tarayıcıyı yeniden başlatma gereğini ortadan kaldırmak
    • Karmaşık durumlarda bile oturumu geri yükleyebilmek için daha fazla durumu yerelde saklama yöntemleri inceleniyor
    • Tam oturum geri yüklemesinin garanti edildiği noktada otomatik yeniden başlatma yapılıyor
    • Chrome 150, macOS'ta tüm pencereler kapalı olsa da uygulamanın arka planda kaldığı durumu algılıyor ve bekleyen güncelleme varsa otomatik yeniden başlatıyor
  • Uzun vadede hedef, sürekli dinamik yama ile az rahatsız eden zamanlardaki otomatik yeniden başlatmayı birleştiren her zaman güncel bir tarayıcı
  • Kurumsal BT yöneticileri için öneriler şöyle
    • RelaunchNotification politikasıyla bildirimden belirli bir süre sonra zorunlu yeniden başlatmaya kadar kademeli uygulama yapılmalı
    • Değişikliklerin doğrulanması gereken hassas ortamlarda Chrome Extended Stable Channel kullanılmalı
    • Chrome Enterprise Core veya Premium içindeki işletim sisteminden bağımsız gösterge paneliyle tüm tarayıcı sürümleri izlenmeli ve güncellemeler ayrıntılı yönetilmeli

C++ savunmaları ve Rust'a geçiş

  • Chrome, mevcut C++ açıklarını çalışma zamanında etkisizleştirirken uzun vadede bellek güvenli dillere geçiş yapan ikili bir strateji izliyor
  • Chromium kodunun büyük kısmı C++ olduğu için araç zinciri ve çalışma zamanı hafifletmeleri ilk ve anlık savunma hattı
    • Güçlendirilmiş standart şablon kütüphanesi ve MiraclePtr ailesi teknolojilerle Use-After-Free (UAF) açıkları azaltıldı
  • C++ savunma yol haritası üç eksenden oluşuyor
    • MiraclePtr ve MiracleObject'in genişletilmesi
      • MiraclePtr; Skia, ANGLE, Dawn, C++ iterator'leri ve std:: container'lara genişletiliyor
      • MiracleObject, yerel çalışma zamanı performansını zamansal güvenlikle takas ederek GPU ana iş parçacığındaki UAF açıklarının yüzde 90'ına kadarını etkisizleştirmeyi hedefliyor
    • std::span dönüşümü
      • İşaretçi ve boyutu birlikte kullanan eski yapılar, derleyicinin denetleyebildiği std::span ile değiştirilerek sınır dışı erişimler (OOB) ortadan kaldırılıyor
      • Chrome'un kendi kodunun yüzde 97'si, sıkı unsafe-buffer uyarılarıyla sorunsuz derleniyor; gereksinimler Skia, ANGLE ve Dawn'a da yayılıyor
    • Yapı ve tahsis güçlendirmesi
      • Bellek tahsis hesaplarında checked math uygulanarak integer overflow yolları kapatılıyor
      • İşaretçi içeren türlerle işaretçi içermeyen türleri sıkı biçimde ayıran ek heap partitioning, UAF istismarını zorlaştırıyor
  • C++ çalışma zamanı hafifletmelerinin önümüzdeki birkaç yıl içinde marjinal faydasının azalacağı düşünülüyor
    • Çalışma zamanı kontrolleri, derleme anı garantilerine kıyasla daha maliyetli; ayrıca güçlü biçimde hafifletilmiş C++ binary'leri bile Rule of Two'ya uymak için performansı kısıtlayan sıkı sandbox'lara ihtiyaç duyuyor
  • Uzun vadede Rust'a geçiş sürdürülüyor
    • Rust flywheel: Chromium tabanlı API'ler ve araçları doğrudan Rust'a sunan merkezi bir SDK kuruluyor; böylece yeni bileşenlerde gündelik tercih haline gelmesi amaçlanıyor
    • Hata yoğun bölgelerin kaldırılması: Karmaşık veri ayrıştırıcıları, görüntü codec'leri ve yazı tipi yığını gibi geçmişte hata yoğunluğu yüksek kodlar stratejik olarak değiştiriliyor
    • Yüksek ayrıcalıklı modülerleştirme: Yeni modüller Rust ile yazılarak tarayıcı süreci gibi yüksek ayrıcalıklı alanlarda sandbox performans maliyeti olmadan karmaşık işlevler çalıştırılabiliyor
  • Tarayıcının en üst düzey arayüzünü HTML, CSS ve TypeScript ile kurarak mevcut C++ framework bağımlılığını daha da azaltma seçeneği de değerlendiriliyor

Kod gönderiminden önce açıkların engellenmesi

  • Tüm kod tabanını periyodik tarama yaklaşımı, Chrome'un hızlı geliştirme temposunu takip etmekte zorlandığı için AI denetimleri kod gönderim anına yakın yerleştiriliyor
  • CI ve commit queue (CQ) savunma modeli, değişiklikleri otomatik inceliyor
    • std::span dönüşüm düzeltmeleri öneriyor
    • dangling pointer'ları işaretliyor
    • sayısal işlem güvenliğini zorluyor
  • Tek başına güvenli görünen kod, başka bir yerdeki küçük mantık değişiklikleriyle birleştiğinde ciddi potansiyel güvenlik sorunlarına dönüşebiliyor
  • CQ içindeki sürekli LLM anlamsal analizi, geleneksel statik analizin kaçırdığı ince veya karmaşık etkileşimleri bulup kod ağaçta yerini almadan önce engelliyor

Açık kaynak ekosistemi ve harici bağımlılıklar

  • Web güvenliği, yalnızca Chrome'a değil, açık kaynak projelerine ve bakımcıların müdahale kapasitesine de bağlı
    • Google, bakımcıların açık bildirimlerine hızlı yanıt verecek araç ve desteğe sahip olması için Alpha-Omega projesine diğer katılımcılarla birlikte 12,5 milyon dolar bağışladı
    • Akrites projesinin kurucu üyeleri arasında yer aldı; amaç merkezi bir açık bildirim kanalı ve güvenlik olay müdahale ekibi sunarak upstream bakımcıların yükünü azaltmak
  • Chromium ile V8, BoringSSL, Skia, ANGLE ve Dawn gibi ilgili projelerde 2.300'den fazla harici bağımlılık bulunuyor
    • Bunların yaklaşık 1.700'ü Android cihazlar, edge computing platformları ve büyük ölçekli bulut şirketi yığınları gibi çeşitli ürünler aracılığıyla kullanıcılara dağıtılıyor
  • Otomatik açık tarama hattı; Google içi beslemeler ile ABD hükümetinin NVD verisini ve açık kaynak odaklı OSV verisini topluyor
  • Sonradan yapılan izleme tek başına risk boşluğu bırakabildiği için, tüm Chrome harici bağımlılıklarını upstream'in en güncel sürümüne proaktif biçimde yükselten otomatik güncelleme hattına geçiş başladı
  • Otomasyon sürecinde, GOSSIP gibi projelerin güvenlik sinyalleri kullanılarak harici açık kaynak ekosistemindeki diğer riskler de hesaba katılıyor

Sürekli korunan tarayıcı

  • LLM'lerle bulunan ve düzeltilen hata sayısının artması bir başarısızlık değil; düzeltilen her hata, saldırganların kullanabileceği bir basamağı daha ortadan kaldırıyor
  • Yalnızca bulmak ve düzeltmek yeterli değil; saldırganlar istismar etmeden önce düzeltmenin dağıtılması ve kullanıcı ortamına uygulanması gerekiyor
  • Daha hızlı sürümler, dinamik yama, az rahatsız eden zamanda otomatik yeniden başlatma ve yapısal savunmaları birleştirerek kullanıcıyı rahatsız etmeden sürekli korunan bir Chrome hedefleniyor

İlgili okumalar

1 yorum

 
GN⁺ 3 시간 전
Hacker News yorumları

  • Son zamanlarda iş yoğunluğu sırasında performans optimizasyonu için yapay zekayı epey kullandım ama üst düzey yön belirlemede neredeyse hiç işe yaramadı. SQL sorgularında şüpheli kısımları işaret etse de önce-sonra performans farkı neredeyse yoktu, gereksiz öneriler yüzünden zaman kaybettirdi ve başkalarının işlenmemiş yapay zeka çıktısını anlamlı katkıymış gibi ortaya atmasına da katlanmak zorunda kaldım
    Yine de bizzat bulduğum değişiklikleri uygulamak veya join'leri CTE'ye taşımak çok daha kolaylaştı

    • İşe yaramayan uzun öneriler gerçekten çok yorucu. Bir iş arkadaşım Slack, Jira, kod incelemesi ve e-posta dahil tüm asenkron iletişimde Claude kullanıyor; basit bir soruya bile kapsamı sürekli büyüyen dev bir metin duvarıyla cevap veriyor
      Yapay zeka aracına tekrar tekrar “kısa ol”, “sadece soruya cevap ver”, “istenmeyen bilgi verme” desem de gerekenden fazla çıktı üretiyor; sanki daha fazla token tüketmeye dönük ince bir çaba gibi görünüyor
    • Yapay zekaya kendi hipotezlerini doğrulayacak tüm araçları sağlarsanız ve tüm yaşam döngüsünü tekrar tekrar çalıştırmasına izin verirseniz şaşırtıcı derecede iyi çalışıyor
    • Sorguyla birlikte EXPLAIN ANALYZE çıktısı verilirse yapay zekanın optimizasyon yapmakta büyük zorluk çekmediğini gördüm; bu yüzden sorgu optimizasyonunda işe yaramadığı yorumu şaşırtıcı
    • Hangi modelin kullanıldığını da belirtmek gerekir. En ileri modeller arasında bile fark çok büyük; pratikte Opus 5.0, benchmark farkının düşündürdüğünden çok daha farklı bir seviyede ve Cursor Grok 4.5 ile Sonnet ya da Composer'la kıyaslamak bile zor
    • Sadece kodu gösterip performans optimizasyonu bulmasını istemek hatalıydı. Performans profili, sorgu planı, telemetri verisi verilmeli ve değişiklik öncesi-sonrası ölçülmeli
      Kod metninden tek başına önbellek boyutu, veritabanı hacmi veya ağ gecikmesi anlaşılamaz; daha iyi sonuç için bu bağlamı vermek gerekir

  • Geçen mayısta Berlin'deki Pwn2Own etkinliğinde Firefox için hiç ödül verilmemiş olması kilit veri noktası. 2007'den beri her etkinlikte ödül verilmişti; doğrulanmış tek bir açık bile çıkmaması, kolay açıkların artık neredeyse tükendiğini ve bu modelin belli ölçüde faydalı olduğuna işaret ediyor gibi görünüyor

  • Çok sayıda hatanın düzeltilebildiğine inanıyorum ama asıl sürecin nasıl işlediğini merak ediyorum. Google blog yazısı yayımlayıp yöneticilerin üst kademeye yapay zeka benimseme başarısı gösterebilmesi için birkaç sprint boyunca hata düzeltmeyi teşvik etmiş olabilir; bu da ekiplerin normalden çok daha fazla çalışmasına yol açmış olabilir

    • Google onlarca yıldır her şeyi otomatikleştiriyor; fuzzer'lar ve Project Zero da bunun parçası. Bunun üstüne LLM eklemek, ardından harness ve geliştirici araçlarını iyileştirip tespit-sınıflandırma-düzeltme-doğrulamayı uçtan uca bağlamak doğal bir sonraki adım
      LLM performansı çalıştığı yineleme yapısına, o yapı da doğrulayıcıların kalitesine bağlı; dolayısıyla yönetsel gösteriş olmadan da bu durum rahatça açıklanabilir
    • Statik analiz ya da fuzzing gibi yeni analiz araçları devreye alındığında, yeni bulunan hatalar önce patlama yapar; bunlar temizlendikten sonra bulunma sıklığı yeniden düşmüş olabilir
    • 2026'nın başında tüm hata kategorilerinde raporlar artıp martta 2025'in tamamını geçtiyse, yapay zeka toplam hata sayısını da ciddi biçimde artırmış olabilir. Örneğin 2025'te 50 hata bulunup 45'i düzeltilmişken, 2026'da 500 bulunup 450'si düzeltilmiş olabilir
    • Yapay zeka kodu hızla yorumlayıp hata birikimini daha çabuk eritiyor olabilir; ayrıca kod ve güvenlik incelemelerini hızlandırarak daha fazla sorun bulunmasını sağlayabilir. Benzer bir durumun Linux çekirdeğinde, ayrıca Windows ve Apple tarafında da görüldüğü anlaşılıyor
    • Chrome mühendislik organizasyonunda son 10 yılda, Google üst yönetimi iş değeri görmedikçe hataların düzeltilmediği atalet dolu bir kültür olmuş olabilir. Şimdi ise daha fazla yapay zeka satmak için hataları düzeltip bunun kredisini yapay zekaya yazma yönünde ticari bir motivasyon doğduğundan şüpheleniyorum

  • Yapay zekayı başıboş çalıştırmak yerine bir hızlandırma aracı olarak kullanmak gerekir ama eleştirmenler bunu karıştırıyor gibi görünüyor. Bu, yatırım getirisi kötü diye Excel'e kızmaya benzeyen bir saman adam argümanı; bu yüzden daha fazla tartışmak yerine onu gerçekten verimli kullanmaya çalışanlarla sessizce kullanım yöntemleri paylaşmak istiyorum

    • Aslında yapay zekanın nasıl kullanılması gerektiği pek net değil. Bir taraf tüm bağlamı verip dilediği gibi çalıştırmak gerektiğini söylüyor, diğer taraf ise dikkatle yönlendirilip her sonucun gözden geçirilmesi gerektiğini; üstelik iki yaklaşımın da destekçileri var
      Başıboş bırakılırsa birkaç yinelemeden sonra sonuçlar kötüleşiyor; dikkatli yönlendirilirse değer üretiyor ama bu çaba, özellikle tekrarlı işlerde, çoğu zaman kodu doğrudan yazmaya yakın bir emek gerektiriyor
    • Gerçekte yapay zeka geliştiriciyi hızlandıran bir araç ama yönetim ve en öndeki araştırma laboratuvarları yakında artık kod okumaya bile gerek kalmayacakmış ve programcılar yok olacakmış gibi pazarlıyor
    • Yapay zeka artık uluslararası güvenlik ve siyaset meselesi hâline geldiğine göre bu alanda bolca propaganda olabilir; mevcut tartışma da biçim olarak 10 yıl önceki siyasi tartışmaları andırıyor
    • Bitcoin'in benim sorunumu nasıl çözdüğünü anlattığımda herkesin bunun imkânsız olduğunu söylemesi aklıma geliyor. Bu, yapay zekanın Bitcoin'le aynı şey olduğu anlamına gelmiyor
    • Hata düzeltme, kod iyileştirme, refactoring yapay zekaya en uygun işler. Eski yazılımları nihayet toparlayabileceğimizi umuyordum ama kendilerinden sürekli daha hızlı yeni özellik geliştirmeleri istenenler, çalıştıkları ortama göre buna ya seviniyor ya da alaycı yaklaşıyor

  • Otomatik düzeltmelerden kaçının geri alındığı, kaç yeni hata üretildiği ve tespit ajanının yanlış pozitif oranının ne olduğu bilinmiyor. Gönderide yalnızca başarılı görünen sayılar var; ters gidebilecek kısımlara ise hiç değinilmiyor

    • Gerçekte, yapay zeka sayesinde çok sayıda hatanın bulunup düzeltildiği diye tanıtılıyor olabilir; ancak asıl temel performans göstergesi yapay zekayla olabildiğince çok hata düzeltmek haline geldiyse, yapay zekanın eski ve kolay birikmiş işleri bulup insanların bunları düzeltmiş olması da oldukça muhtemel
    • M146 sonrasında bulunan hata sayısındaki keskin artışın daha iyi testlerden mi kaynaklandığı, yoksa baştan itibaren daha fazla yeni hatanın mı eklendiği açıklanmıyor
    • Amazon'da yapay zeka başarı hikayelerini paylaşacak çok yer var, ama başarısızlıkları veya hayal kırıklıklarını paylaşacak yer yok. Yöneticilerin tek taraflı anlatılar duyup yapay zeka hakkında yanlış kararlar vermesi de bu yüzden şaşırtıcı değil
    • O hatalardan kaçını yapay zekanın yeni oluşturduğunu da merak ediyorum
    • Tarayıcı güvenliğinde az sayıda yeni hata oluşması o kadar da büyük bir sorun olmayabilir. 2012'deki Pinkie Pie saldırısında da 6 hatanın zincirlenmesi gerekiyordu; sonrasında ise 10'dan fazla hatayı zincirleyen saldırılar da ortaya çıktı, dolayısıyla bunlardan yalnızca birini düzeltmek bile tüm saldırıyı etkisiz hale getirir
      10 hatayı düzeltip 2 yeni hata oluşturuyor olsanız bile, bunlar tek başına istismar edilebilen ciddi hatalar olmadığı sürece net kazanç büyüktür. Tarayıcı saldırıları giderek daha uzun güvenlik açığı zincirleri gerektirdiğinden, yapay zekayla potansiyel hataları bulmanın faydasını görmezden gelmek zordur
      https://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1....

  • İleride Google'ın, Chromium için açık kitlesel hata avcılığına artık gerek olmadığına karar verip açık geliştirmeyi sonlandırmasından endişe ediyorum. Böyle olursa mevcut Chromium türevleri, fiilen son açık sürümün birer fork'u haline gelir ve Gemini destekli Chrome kadar bakım kaynağına sahip olmayacakları için her fork'un sürdürülebilirlik zorluğu farklı olabilir

    • Google zaten Chrome ile Chromium'un yönünü güçlü biçimde kontrol ediyor; bu yüzden açık web önemliyse Firefox kullanmak gerekir

  • Yapay zeka eleştirileri çoğu zaman kodu körü körüne üretmenin kötü olduğuna dair dar bir kategoriye odaklanıyor; buna katılmak kolay. Ama düşmanca testler, geliştirici varsayımlarını doğrulama, refaktör önerileri, küçük geliştirme araçları, yönlendirmeli kodlama ve büyük kod tabanlarında bağımlılıkları ile davranışı izleme bunun diğer tarafında duruyor ve buralarda büyük fayda sağlanabiliyor
    Körü körüne kod üretimine yönelik eleştiriler, bu kullanım alanlarının tamamıyla fazla kolay biçimde birbirine karıştırılıyor

    • Yapay zeka belirli bir şekilde kullanılması gereken bir araçtır. İstenen yönü sizin vermeniz gerekir; her sorunu sihirli biçimde çözmesini beklememek gerekir
    • Yapay zekanın, tek bir kişinin tümüne sahip olamayacağı bazı yetenekleri vardır; ama kullanıcıdan daha akıllı değildir ve kullanıcı onu düzeltmezse sık sık yanlış kararlar verir

  • Asıl mesele, bu hatalardan kaçının en başta LLM'in yazdığı koddan kaynaklandığıdır. 100 kat fazla hata üretip 100 kat fazla hata düzeltmek övünülecek bir şey değildir

    • Chrome 20 yılı aşkın bir projedir ve LLM'ler çok daha yeni ortaya çıktı; ayrıca LLM tabanlı kod üreticileri çıktı diye kod inceleme ve testler de gevşetilmedi. 13 yıllık bir sorundan da söz edildiğine göre, etkilenen alanlarda yakın dönemde çok fazla geliştirme yapılmamış olması muhtemeldir
      Bu bir açık kaynak projesi olduğundan, bunların gerçekten LLM kaynaklı hatalar olup olmadığını doğrudan kontrol etmek de mümkündür
    • Kodlamayı giderek daha fazla yapay zekaya bırakırsak, insanların potansiyel hataları tespit etme yeteneği de zayıflayabilir. Yapay zekanın yazdığı özellikleri commit'ten önce tekrar yapay zekayla denetlemeye başlarsak, altyapıyı çalıştıran kodun bile insanların anlayamadığı bir dünyaya yaklaşırız
    • Git istatistiklerine bakınca gönderilen kod satırı sayısının dramatik biçimde değişmediği görülüyor. Herkes düşük kaliteli yapay zeka kodunu olduğu gibi birleştirmiyor; yerleşik büyük organizasyonlar da genelde sorumsuz vibe coding çıktıları birleştirmiyor
    • Yapay zekanın daha az hatayla kod üretebildiğini varsayarsak, yeni hataların 100 kat arttığını söylemek, yeni özellik geliştirme hızının 100 kattan fazla arttığı anlamına gelir. Model 13 yıllık kritik bir hatayı bulabiliyorsa, aynı yetenekle böyle hatalar içermeyen yeni kod da yazabilmesi gerekir
    • Projenin geçmişini ve ölçeğini yok sayıp, hiçbir dayanağı olmadan hata sayısının 100 kat arttığına dair bir rakam uydurup sonra da bunu temel sorun ilan etmek mantıklı değildir. Yapay zeka konusunda, gerçekliği zorlayarak kurmaya çalışan bir tutumla olağandışı sık karşılaşılıyor

  • Chrome her nerede ne yaparsa yapsın kullanıcıyı izlemeye çalışan davranış izleme hatalarını da düzeltti mi, onu merak ediyorum