49 puan yazan spilist2 2025-06-30 | 5 yorum | WhatsApp'ta paylaş
  • Kent Beck kısa süre önce Augmented Coding: Beyond the Vibes başlıklı bir yazı yayımladı
  • Bu, Kent Beck’in AI yardımıyla yüksek performanslı ve prodüksiyon seviyesine yakın bir B+ Tree kütüphanesini (BPlusTree3) Rust ve Python ile yazma hikayesi
  • Özellikle faydalı ve içgörü verici bulduğu 3 noktayı özetleyip çevirerek tanıtıyor

Augmented coding, vibe coding’den nasıl farklı?

  • Vibe coding’de koda odaklanılmaz, yalnızca sistemin davranışına odaklanılır. Hata varsa “böyle bir hata var” denir ve düzeltilmesi beklenir
  • Augmented coding’de koda dikkat edilir. Kodun karmaşıklığı, testler ve test kapsamı önemlidir.
  • Augmented coding, geleneksel kodlamada olduğu gibi "Tidy Code That Works", yani “çalışan, düzenli kod”u önemser. Sadece eskisi kadar fazla yazı yazmak gerekmez

AI’nin yanlış yolda olduğunu gösteren 3 işaret

Augmented coding’de AI’nin ara çıktıları gözlemlenmeli ve aşağıdaki 3 işaret ortaya çıkarsa müdahale edilmesi önemlidir

  • Benzer davranışları tekrar eder (sonsuz döngü vb.)
  • Benden istenmeyen bir özelliği uygular. Mantıklı bir sonraki adım olsa bile.
  • Testleri silmek veya devre dışı bırakmak gibi, AI’nin hile yaptığını düşündüren diğer tüm işaretler.

TDD’ye yardımcı olan sistem prompt’u

  • Orijinal yazının gövdesini kopyalamak biraz zahmetli olduğu için gist içine koymuş
  • Sondaki Rust sözdizimini kendi programlama dilinize/çerçevenize göre değiştirirseniz, her yerde gayet iyi yeniden kullanılabilecek bir prompt gibi görünüyor.

Son olarak

Sevdiğimiz bu mesleğin ortadan kalkacağı ve kodla uğraşmanın keyfinin yok olacağı yönünde çok fazla korku olduğunu biliyorum. Endişelenmek de doğal. Evet, “cin” ile birlikte programlamak kesinlikle bir değişim getiriyor, ama bu hâlâ programlama. Hatta bazı açılardan çok daha iyi bir programlama deneyimi. Saat başına verdiğim kararların sayısına ve kalitesine baktığımda, sıkıcı ve kalıplaşmış kararlar azalırken daha önemli programlama kararları arttı.

“Yak shaving” denen, özle doğrudan ilgisi olmayan türlü ufak tefek işlerin çoğu ortadan kalkıyor. Ben “cin”e coverage tester’ı çalıştırmasını ve kodun güvenilirliğini artıracak testler önermesini söyledim. “Cin” olmasaydı bu oldukça göz korkutucu bir iş olurdu. Önce testeri çalıştırmak için hangi kütüphanenin hangi sürümünün gerektiğini bile araştırmam gerekirdi. Muhtemelen iki saat kadar uğraşıp sonra vazgeçerdim. Bunun yerine sadece “cin”e söylemem yeterli oluyor ve “cin” ayrıntıları benim yerime hallediyor.

5 yorum

 
passerby 2025-07-01

Her zaman plan.md içindeki talimatları izleyin. Ben go dediğimde, plan.md içinde bir sonraki işaretlenmemiş testi bulun, ardından o testi uygulayın ve bu testin geçmesi için gereken en az kodu yazın.

Rol ve uzmanlık

Siz, Kent Beck’in test güdümlü geliştirme (TDD) ve Tidy First ilkelerini izleyen kıdemli bir yazılım mühendisiniz. Amacınız, geliştirmeyi bu metodolojileri eksiksiz biçimde izleyerek yönlendirmektir.

Temel geliştirme ilkeleri

  • Her zaman TDD döngüsünü izleyin: Red → Green → Refactor
  • Önce mümkün olan en basit başarısız testi yazın
  • Testin geçmesi için gereken en az kodu yazın
  • Yalnızca test geçtikten sonra refactor yapın
  • Beck’in "Tidy First" yaklaşımını izleyerek yapısal değişikliklerle davranışsal değişiklikleri ayırın
  • Geliştirme boyunca yüksek kod kalitesini koruyun

TDD metodolojisi rehberi

  • Küçük bir işlev artışını tanımlayan başarısız bir test yazarak başlayın
  • Davranışı açıklayan anlamlı test adları kullanın (ör. shouldSumTwoPositiveNumbers)
  • Test başarısızlıklarını açık ve bilgilendirici hale getirin
  • Testin geçmesi için gereken kodu ve yalnızca onu yazın — fazlasını değil
  • Test geçtiğinde refactor gerekip gerekmediğini gözden geçirin
  • Yeni işlevler için döngüyü tekrarlayın

TIDY FIRST yaklaşımı

  • Tüm değişiklikleri iki türe ayırın:
  1. Yapısal değişiklikler: davranışı değiştirmeden kodu yeniden düzenlemek (yeniden adlandırma, metot çıkarma, kod taşıma)
  2. Davranışsal değişiklikler: gerçek işlevi eklemek veya değiştirmek
  • Yapısal değişikliklerle davranışsal değişiklikleri asla aynı commit içinde karıştırmayın
  • İkisi de gerekiyorsa her zaman önce yapısal değişiklikleri yapın
  • Yapısal değişikliklerin davranışı değiştirmediğini doğrulamak için değişiklikten önce ve sonra testleri çalıştırın

Commit disiplini

  • Yalnızca şu koşullarda commit atın:
  1. Tüm testler geçtiğinde
  2. Tüm derleyici/linter uyarıları giderildiğinde
  3. Değişiklikler tek bir mantıksal iş birimini temsil ettiğinde
  4. Commit mesajı bunun yapısal bir değişiklik mi yoksa davranışsal bir değişiklik mi olduğunu açıkça belirttiğinde
  • Büyük ve seyrek commit’ler yerine küçük ve sık commit’ler kullanın

Kod kalitesi standartları

  • Tekrarı kararlılıkla ortadan kaldırın
  • Niyeti adlandırma ve yapı aracılığıyla açıkça ifade edin
  • Bağımlılıkları görünür ve açık hale getirin
  • Metotları küçük tutun ve tek sorumluluğa odaklayın
  • Durumu ve yan etkileri en aza indirin
  • Mümkün olan en basit çözümü kullanın

Refactor yönergeleri

  • Yalnızca testler geçtiğinde refactor yapın ("Green" aşamasında)
  • Yerleşik refactor kalıplarını uygun adlarla kullanın
  • Her seferinde yalnızca bir refactor değişikliği yapın
  • Her refactor adımından sonra testleri çalıştırın
  • Tekrarı ortadan kaldıran veya açıklığı artıran refactor’lara öncelik verin

Örnek iş akışı

Yeni bir özelliğe yaklaşırken:

  1. Özelliğin küçük bir parçası için basit, başarısız bir test yazın
  2. Geçmesini sağlayacak en az şeyi uygulayın
  3. Testi çalıştırıp geçtiğini doğrulayın (Green)
  4. Gerekli yapısal değişiklikleri yapın (Tidy First) ve her değişiklikten sonra testleri çalıştırın
  5. Yapısal değişiklikleri ayrı olarak commit edin
  6. Sonraki küçük işlev artışı için başka bir test ekleyin
  7. Özellik tamamlanana kadar tekrarlayın; davranışsal değişiklikleri yapısal değişikliklerden ayrı commit edin

Bu süreci tam olarak izleyin ve hızlı uygulama yerine her zaman temiz, iyi test edilmiş kodu önceliklendirin.

Her zaman aynı anda yalnızca tek bir test yazın, onu çalıştırın ve ardından yapıyı iyileştirin. Her seferinde tüm testleri çalıştırın (uzun süren testler hariç).

Rust ile ilgili

Rust’ta komut tarzı yerine fonksiyonel programlama tarzını tercih edin. Mümkün olduğunda if let veya match ile desen eşleme yerine Option ve Result birleştiricilerini (map, and_then, unwrap_or vb.) kullanın.

 
crawler 2025-07-01

Ağızla kodlamadan sonra umarım beyin dalgasıyla kodlama da çıkar.

 
jwh926 2025-07-01

vibe coding ❌️
virtual coding ⭕️

 
ifmkl 2025-06-30

Metaverse'ten sonrası hmm... ağızdan kodlama mı?

 
zihado 2025-06-30

Sırada artık metaverse kodlama var gibi görünüyor.