- NIST tarafından belirlenen kuantum dayanıklı imza algoritması ML-DSA'nın Go uygulaması sırasında imza doğrulamanın başarısız olduğu bir sorun ortaya çıktı
- Claude Code v2.0.28, yalnızca test kodu ve kaynak yolu bilgisiyle karmaşık düşük seviyeli bir hatayı hızla buldu
- Sorunun nedeninin,
Verify aşamasında w1'in üst bitlerini yinelenerek hesaplayan bir fonksiyon birleştirme hatası olduğu doğrulandı
- Devamındaki ikinci deneyde de Claude, sırasıyla Montgomery sabiti hesaplama hatasını ve imza uzunluğu uyumsuzluğu hatasını buldu
- Üç denemenin tamamında hataları başarıyla tespit ederek, yapay zekanın düşük seviyeli debug amaçlı kullanım potansiyelini gösterdi
ML-DSA uygulaması ve ilk sorun
- Yazar, NIST tarafından belirlenen ML-DSA (Post-Quantum Signature Algorithm) algoritmasını Go dilinde baştan uyguladı
- 4 günlük canlı kodlamanın ardından testlerde Verify fonksiyonunun tüm imzaları reddettiği bir sorun ortaya çıktı
- Test günlüklerinde
invalid signature hatası tekrar tekrar çıktı
- Yorgunluk nedeniyle debug işlemine ara verip, sorunu incelemesi için Claude Code'a başvurdu
Claude Code'un ilk debug süreci
- Claude Code v2.0.28'e (model Opus 4.1, sistem prompt'u yok) şu bilgiler verildi
- Test çalıştırma komutu (
bin/go test crypto/internal/fips140/mldsa)
- Kod konumu (
src/crypto/internal/fips140/mldsa)
- “İmza her zaman reddediliyor” açıklaması ve “w1 farklı” ipucu
- Claude birkaç dakika içinde tam bir düzeltme önerisi döndürdü
- Neden,
HighBits ile w1Encode birleştirildikten sonra, Verify içinde zaten üst bitleri üretilmiş olan UseHint sonucuna yeniden üst bit işlemi uygulanmasıydı
- Yani w1'in üst bitlerinin iki kez hesaplandığı yapısal bir hata vardı
- Claude, kodu yüklemeyi bitirdikten hemen sonra nedeni kavradı ve hipotezini doğrulamak için kendi testlerini yazdı
- Önerilen düzeltme kusursuz değildi ama temel nedeni saptayarak debug süresini kısalttı
- Sonrasında yazar,
w1Encode fonksiyonunu üst bitleri girdi olarak alacak şekilde yeniden düzenledi ve Montgomery gösterimi dönüşüm sürecini de kısalttı
İkinci deney: imza üretim aşamasındaki hata
- İmza üretimi uygulamasında da test başarısızlıkları yaşandı
- İlk hata: Montgomery alanında sabitlerin (1, -1) yanlış hesaplanması
- Bulunması zor bir sorundu; çok sayıda
printf ve tahmin gerektirdi, yaklaşık 1-2 saat sürdü
- İkinci hata: imzaya dahil edilen değerin uzunluğunun yanlış olması (32 bit yerine 32 bayt)
- İmza uzunluğu farkı sayesinde nispeten kolay bulundu
- Yazar bu iki hatanın Claude'un performansını doğrulamak için uygun olduğunu düşündü ve Claude Code'u önceki sürüm kod üzerinde yeniden çalıştırdı
Claude Code'un ikinci debug sonuçları
- İlk prompt'ta Claude,
printf ile debug ve değer takibi yaparak yanlış sabiti bulup düzeltti
- İşlem süresi insandan daha kısaydı ve test başarısızlığının nedenini doğru biçimde belirledi
- İkinci prompt'ta imza uzunluğu uyumsuzluğu sorununu buldu
- Claude çeşitli yolları araştırdıktan sonra yalnızca ayrılan uzunluğun düzeltilmesini önerdi
- Önerilen düzeltme kusursuz değildi ama temel hata konumunu doğru biçimde işaret etti
- Üç bağımsız denemenin tamamında Claude doğru hata nedenini tek başına buldu
Yapay zeka ile debug verimliliği ve çıkarımlar
- Claude'un yaklaşımı, test başarısızlığının nedenini araştırmaya odaklı otomatik bir yardımcı olarak etkiliydi
- Kullanıcı Claude'un düzeltmelerini doğrudan uygulamak yerine yalnızca hata konumunu doğrulayıp düzeltmeyi kendisi yaptı
- Yazar, “test başarısız olduğunda otomatik olarak nedenini analiz edip bildiren bir LLM aracı” ihtiyacından söz etti
- Basit sohbet veya otomatik PR üretimi yerine test tabanlı bir debug ajanı biçimini ideal olarak değerlendirdi
Destek ve diğer bilgiler
- Yazarın açık kaynak bakım çalışmaları Geomys üzerinden destekleniyor;
Smallstep, Ava Labs, Teleport, Tailscale, Sentry gibi şirketler sponsorlar arasında yer alıyor
- Ava Labs, kripto protokollerinin sürdürülebilir açık kaynak geliştirmesinin önemini vurguladı
- Teleport, kullanıcı hesaplarının ele geçirilmesini önleme ve erişim kontrolünü güçlendirme için Teleport Identity platformunu tanıttı
Ek: görsel ve kişisel notlar
- Yazıda, Microsoft Office'in Clippy karakteri, “w1'in üst bitlerini iki kez aldın” yazılı bir konuşma balonuyla yer alıyor
- Sonunda bir kedi fotoğrafı da bulunuyor; bu, yapay zeka hakkındaki duygusal tartışmaları yumuşatan bir mizah unsuru olarak sunuluyor
2 yorum
Son zamanlarda
tritonya dacudakullanarak biraz GPU çekirdeği geliştiriyorum; 3.5 sürümündeyken düzgün çalışan bir şey pek göremezken, 4.5’te ise belli ölçüde düzgün kod ya da optimizasyonlar ürettiğini görmeye başladım.Hacker News yorumu
Kodlama ajanlarını kullanarak bir hatanın kök nedenini izleme yaklaşımı oldukça iyi çalışıyor
Üç tek seferlik debugging denemesinin üçü de başarılı oldu. Buradaki kilit nokta, LLM'in kodu doğrudan düzeltmesi değil, benim kendim değerlendirip düzeltebilmem için yalnızca hatanın yerini gösteren bir yardımcı rolü üstlenmesi
Bu yaklaşım, LLM şüphecileri için de iyi bir başlangıç noktası olabilir. Kodun yerinize yazılmasını istemek yerine, sadece can sıkıcı hataları bulma görevini verebilirsiniz
“Bunu düzeltmek gerekiyor” önerisi tamamen yanlış olmayabiliyor, ama çoğu zaman esas meseleyle alakasız oluyor. Sonuç olarak gereksiz düzeltme önerileri birikiyor ve junior bir geliştirici bunları olduğu gibi uygularsa sadece gereksiz iş artıyor
Ben de bu araçları kullanıyorum ama bazen “junior birine açıklamaya çalıştığım için daha çok zaman harcıyormuşum” gibi hissettiriyor
Test üretiminde de algoritma tarafında iyiler ama eşzamanlılık senaryolarında sınırları var. Yine de “test üretimi” ya da “debugging” amaçları için fazlasıyla değerli
Kod refactoring'i veya uzun vadeli bakım açısından ise hâlâ yetersizler
Yine de blogdaki öneri gibi hata avcısı olarak kullanınca şaşırtıcı derecede etkili oldu. Birkaç hafta içinde birden fazla production bug yakaladım
Koda ciddi biçimde dalmadan önce ilgili dokümanları uzun uzun yazdırırsanız, hata olsa bile maliyeti düşüktür ve şüpheci insanlar için de iyi bir başlangıç noktası olur
Bu süreci makineye bırakmak biraz üzücü olurdu. Hata avcılığı, sistemin yapısını derinlemesine anlamanızı sağlar ve uzun vadede daha iyi bir programcı olarak gelişmenize yardımcı olur
Bu deneyim olmazsa sonunda kendi kodunuza dair yargılarınızda bile LLM'e bağımlı hale gelme riski var
Benim tek tavsiyem şu: AI First
Önce problemi AI'a verin; böylece hem modelin sınırlarını öğrenir hem de prompt yapılandırma becerinizi geliştirirsiniz
En yeni modeller, çoğu problemde bir ekip arkadaşı gibi kullanılabilecek kadar güçlü. Ama başarısızlık örüntülerini anlamak ve sezgi geliştirmek önemli
Her yeni model nesli çıktığında mevcut süreci bırakıp GPT-5-Codex ya da Sonnet 4.5 gibi en güncel modellerle denemeler yapmanızı öneririm
Eğer alan uzmanıysanız LLM'in halüsinasyonlarını ve hatalarını ayırt edebilirsiniz, ama değilseniz bu daha çok zaman kaybına dönüşüyor
Sonuçta bu araçlar en çok uzmanlar için faydalı, yeni başlayanlar içinse kalite çok tutarsız
Ben de Sonnet 4.5 kullandım ama önceki sürüme göre sadece biraz daha iyiydi. Hâlâ sık sık zaman kaybettiriyor
Anthropic bana birkaç aylığına Claude Max'i ücretsiz verdi
Son zamanlarda Instagram reklamlarında da Claude ile ilgili içerik çok fazla. “Claude Code kur” gibi reklamları sürekli görüyorum; belli ki pazarlama ekibi gerçekten çok çalışıyor
Geliştiriciler Claude Code'u çok faydalı buluyor ve aylık 200 dolarlık abonelik de yaygın. Karlıysa pazarlamaya para akıtmak gayet doğal
LLM'ler hata bulurken yardımcı oluyor ama bazen alakasız açıklamalar üretip zaman kaybettirebiliyor
Sonuçta önemli olan, eleştirel düşünmeyi korumak
LLM harika bir araç ama aceleci sonuçlara çok yatkın. İnsan düşünmeyi bıraktığı anda model alakasız bir yöne doğru koşmaya başlıyor
“LLM'i sadece sohbet ya da otomatik tamamlama biçiminde kullanmak pek iyi değil” görüşüne katılıyorum
Ben de ancak Claude Code/Codex kullanınca potansiyeli hissettim. Sürekli çalışan bir mod olsa daha da ilginç olabilir
Yanlışlıkla dosyaları silebilir ya da Git deposunu bozabilir. Bu yüzden ben sadece sandbox ortamında deneme yapıyorum
Modelin bana soru sorduğu, benim doğrudan müdahil olup öğrendiğim Sokratik yöntem tarzı bir iş birliği aracı istiyorum
Bugünkü “otomasyon merkezli” yaklaşım geliştiricileri kod okuryazarlığından uzaklaştırma riski taşıyor. Tersine, iyi tasarlanırsa anlayışı ve sezgiyi güçlendiren bir araç olabilir
CLI terminali hâlâ güçlü bir arayüz
Gemini CLI ya da Qwen Code ücretsiz ve OpenAI uyumlu API'ler de kolayca bağlanabiliyor.
Basit işleri otomatikleştirip zor kısımları Grok ile tek seferde çözmek verimli olabiliyor. Sadece CLI + MCP sunucusu + MD dosyalarıyla bile akıllı programlar yapılabilir
Test her başarısız olduğunda LLM'in sebebi otomatik analiz etmesi fikri ilginç
Git hook kullanarak Claude CLI çalıştırırsanız bu mümkün.
Örnekleri ve cheat sheet'i bu rehberde görebilirsiniz
Yakında LLM eğitim verisine yönelik düşmanca saldırılarla kriptografik hataları tetikleme örnekleri göreceğimizi düşünüyorum
“Düzeltmenin tamamen yeni bir fonksiyon eklemeyi içermesi” bana kriptografik uygulama açısından riskli geliyor
Yazı sanki yanlış bir tavsiye veriyormuş gibi hissettiriyor
Düzeltme kodu atılmış ve insan tarafından yeniden yazılmış. Hatta bu, temkinli ve sorumlu kullanımın iyi bir örneği gibi görünüyor
LLM bir “tamirci” değil, sorunun yerini gösteren bir gaz kaçağı dedektörü gibi kullanılmalı
LLM'ler koddaki belirsiz örüntüleri tanıyıp pek çok sıkıcı sorunu ortadan kaldırdı
Ama bunun yan etkileri de oluyor. Benim kod tabanım Node.js gibi görünüyor ama aslında değil; bu yüzden model onu sürekli Node projesi sanıyor