Fable’ı Yenen “Kısa Tasma” AI Kodlama Yöntemi
(blog.okturtles.org)- Güvenliğin kritik olduğu yazılımlarda AI kodlama ajanlarını kullanmak için, onlara otonom çalışma vermektense geliştiricinin değişiklikleri sürekli kontrol ettiği Short Leash yöntemi gerekiyor
- Birden çok ajanın paralel biçimde kod yazıp incelediği “vibe” tarzı yaklaşım, kod tabanını anlama düzeyini zayıflatabilir ve sorunların ancak AI off the rails durumuna geldikten sonra fark edilmesine yol açabilir
- Temel süreç; plan oluşturma, adımlara bölme, izin istemlerinde görülen diff’leri inceleme, sık sık reddetme ve müdahale etme, alt görev başına commit atma ve son incelemeye kadar uzanıyor
- PR incelemesinde AI ile insanı birlikte kullanmak hataları azaltabilir; AI yaygın hataları hızlıca yakalar, insan ise daha üst düzey sorunları ve yönü değerlendirir
- AI’nın yazıma katkı verdiği PR’lerde gönderimi yapan kişi her satırı bizzat incelemeli ve PR açıklamasında kullanılan modeli AI Disclosure olarak belirtmeli; güven ancak böyle kazanılabilir
AI kodlama ajanlarını kullanmak için önkoşullar
- Bu yöntem, güvenlik açısından kritik sistemlerde yüksek kaliteli yazılım üretmek için AI ajanlarını kullanma deneyimine dayanıyor
- Hedef kitle, AI’yı öğrenmenin düşmanı olarak görmesi gereken acemi geliştiriciler değil; kendi uzmanlık alanında “frontier AI models”dan daha yetkin olan uzman geliştiriciler
- Amaç, AI’yı performansı artıran bir araç olarak kullanırken yazılım kalitesinden ödün vermemek
- Deneyim kapsamına, AI ajanlarının sınırlarını keşfetmek, şirket içi AI inceleme araçları geliştirmek ve AI kodlama ajanı Crush’ın özel fork’unu sürdürmek de dahil
“vibe” tarzı yaklaşımın sallandığı noktalar
- AI ajanlarının kullanıldığı oturumlarda iki sorun sık görülür
- İlk fikir kötüdür ve daha iyi bir yaklaşım olduğu ancak sonradan fark edilir
- Ajan, istenmeyen bir yöne gidip off the rails durumuna düşer
- Birden çok paralel ajan ve orkestratör aynı anda çalışırken geliştirici kodlama sürecinin dışında kalırsa, kod tabanına dair anlayışı doğrudan inşa etmek zorlaşır
- Kalitenin önemsenmediği durumlarda bu yaklaşım işe yarayabilir; ancak kalitenin kritik olduğu yerlerde farklı bir yaklaşım gerekir
- Fable 5’in yazdığı ya da incelediği kod, çalışsa bile verimsiz ve çirkin olabilir
- Modellerin dayanacağı eğitim verisinin az olduğu niş alanlarda bu sorunlar daha sık yaşanabilir
- Bazı CEO’ların pazarlama söylemlerinin aksine, bu bakış açısına göre modeller eğitim verisinin ötesinde düşünemez
Short Leash yönteminin çalışma biçimi
- Short Leash, herkesin kullanabileceği bir yöntem değil; uzman yazılım geliştiricilere göre tasarlanmış durumda
- Avantajı, frontier model kullanmadan da Fable’ı geçen sonuçlar üretebilmesi
- İşe başlamadan önce planlama aşamasında görev araştırılır ve plan yapılır
- Büyük işler, tasks skill gibi araçlarla takip edilir ve aşamalara bölünür
- Bu bölüm, birçok “vibe engineering” yaklaşımıyla ortak noktalar taşır
- Sonrasındaki kilit nokta, AI’yı sürekli kısa tasma ile tutmaktır
- “YOLO” modu ya da “dangerously skip permissions” kullanılmaz
- Kullanıcı oyun oynarken AI’nın tek başına çalışmasına izin verilmez
- İzin isteminde uygulanacak değişikliklerin diff’ini gösteren bir kodlama ajanı kullanılır
- Geliştirici, AI’nın önerdiği değişiklikleri gerçekten analiz eder
- İzin istemindeki diff’ler sayesinde kod tabanına dair anlayış güncel tutulur ve AI kontrol altında kalır
- AI istenmeyen bir iş yapmaya kalkarsa izin reddedilir
- Gerekli olduğunda sık sık müdahale edilerek AI’nın yönünü kaybetmesi önlenir
- Her alt görev tamamlandığında bir commit oluşturulur; böylece AI’nın önceki çalışmayı bozması veya silmesi engellenir
- Bu gerçekten yaşanabilir; Opus’ta görülen örnekler var
- Son aşamada inceleme yapılır
AI incelemesi insan incelemesinin yerini tutmaz
- Yalnızca insanın yaptığı ya da yalnızca AI’nın yaptığı PR incelemelerine kıyasla, insan ve AI’nın birlikte incelediği PR’ler hataları daha fazla azaltabilir
- AI, bir linter gibi ele alınabilir
- Yaygın hataları hızlıca yakalar
- İnsan ise daha üst düzey sorunları ve yön değişikliği gerekip gerekmediğini değerlendirir
- Tüm PR’lerin AI incelemesinden geçmesi önerilir
- AI incelemesi için yeterli bağlam gerekir
- issue
- PR açıklaması
- kod tabanı
- değişiklikler
- İnceleme için eldeki en güncel modelin kullanılması tavsiye edilir
AI Disclosure ve gönderici sorumluluğu
- PR hazırlarken AI kullanıldıysa, PR açıklamasındaki AI Disclosure bölümünde kullanılan tam model açıklanmalıdır
- Bu açıklamanın birden fazla amacı vardır
- Bakımcılara AI kullanıldığını bildirmek
- Zayıf bir model kullanıldıysa daha iyi bir model önerebilmelerini sağlamak
- AI’yı gizlice sürece sokma niyeti olmadığını göstermek
- AI kullanılan PR’ler mutlaka PR’nin “yazarı” tarafından doğrudan incelenmelidir
- AI destekli PR’ler, pratikte insan yardımı almış bir AI’nın PR’sine daha çok benzer; bu yüzden gönderici ne sunduğunu anlamalıdır
- Gönderici, kendi PR’sini başka birinin PR’si gibi görmeli ve line-by-line biçimde bizzat incelemelidir
- Kendi incelemesi tamamlandıktan sonra onayını doğrulayıp bakımcılardan inceleme isteyebilir
- Bu süreç, göndericinin kod tabanını anladığını hem oluşturur hem de gösterir
okTurtles’ın uygulama biçimi
- okTurtles AI’yı bu yöntemle kullanıyor
- Resmî politika AI Usage Policy içinde özetlenmiş durumda
- Yazının kendisi insan tarafından yazıldı ve yayımlanmadan önce yalnızca AI tarzı bir yazım denetimi yapıldığına dair bir AI Disclosure içeriyor
1 yorum
Hacker News yorumları
Bu “kısa tasma” yöntemi bir yardımcı araçtan çok koltuk değneği gibi görünüyor; sanki baştan yapay zekaya problemi yeterince anlatmadığınızın ya da çıktıyı inceleyip yinelemediğinizin işareti
Fable gibi güçlü bir modeli uygulama aşamasında elinden tutup sürüklemek zaman kaybı ve Fable israfı. Model ne kadar güçlüyse, o kadar incelikli tasarım tartışmaları yapılabiliyor ve eskisine göre çok daha iyi kod yazıyor. Tasarım ve uygulamayı tartışmak, tuhaf görünen yerleri sorgulamak ve yapay zekanın yanıtlarını gerçekten okumak, başlı başına daha iyi bir çözüm bulmaya yardımcı oluyor
Daha önce açgözlü algoritma çözümü oluşturmaya çalışırken Opus’la yaptığım tartışmada, sorunun mevcut bir MILP kütüphanesi ile tam olarak çözülebileceği önerisini aldım; MILP’yi hiç duymamış olmama rağmen nihai uygulama, tek başıma yapsaydım ortaya çıkacak olandan daha iyi ve daha basit oldu
Oysa çalışmıyordu; o ilk-ilkelerden akıl yürütme adımını açıklamasını isteyince de aslında uydurduğunu söyledi. Bu yüzden modelle incelikli tartışma lafına inanmak zor
Planlama aşamasına yeterince yatırım yaptıysanız ve projenin mevcut mimarisi ile konvansiyonları sağlamsa, burada anlatıldığı kadar uygulama aşamasında yoğun gözetim gerekmeyebilir
“İlk fikrin aptalca olduğunu ve daha iyi bir yol bulunduğunu keşfedebilirsiniz” durumu genellikle planlama ve mimari aşamasında üst düzeyde ortaya çıkar
Ajanın istenmeyen bir yöne “raydan çıkması” sorunu da eskisi kadar kötü değil; etkili değişiklikler için en azından asgari test kapsamı olmalı. Bu test yalnızca uygulanan davranışı “sabitleme” düzeyinde olsa bile yeter. Son inceleme tartışması, review’un ya da karşıt inceleme ajanının bulduklarının ötesini kontrol etmek için iyi bir fırsat
MILP örneği bu yaklaşımın engelleyeceği bir şey değil; planlama aşamasında ortaya çıkardı
Sonuçta ayrıntılar önemli ve işe başlama prompt’unu nasıl verdiğiniz etkili oluyor. Yine de çıktıyı kontrol etmek, modelin yaptığı işe dahil olmak ve neden öyle yapmak istediğini didiklemek mutlaka gerekli
Ama o çalışanın fikirleri masaya gelmez ve uzun vadede tüm ekibe fayda sağlayabilecek katkılar da ortadan kalkar
Üretilen her şeyi anlamamı ve kod tabanına dair çalışma bilgimi sürekli korumamı sağlıyor. Yön değişikliği yaptırmak da kolay
Bir yan projede 2 hafta boyunca böyle yaptım ama sonunda kod tabanı hakkında bir zihinsel modelim olmadan kaldım
O modeli bizzat yapmadan oluşturmanın bir yolu olmadığına daha da ikna oldum
Unutma eğrisi yüzünden zihinsel modelim, onu ilk oluşturduğum dönemden çok daha uzun süre dayanmıyor. Nasıl yeniden kuracağımı hâlâ çözemedim
Yine de doğrudan yazdığınız zamanki gibi “bunu kendi başıma yapabilme becerisi”nin pek gelişmediğine katılıyorum
Örneğin belli bir etkiyi elde etmek için hangi değişikliği yapmam gerektiğini biliyorum ve gerçekten değiştirince beklediğim sonuç çıktığı için zihinsel modelimin çalıştığını anlıyorum. Ama benzer bir şeyi sıfırdan kendim yapmam istense yapamayacakmışım gibi geliyor. Yaklaşım sanki elimin ulaşamayacağı bir yerde; açıklaması zor
Gerçekten kod yazmayı bilen insanların, önemli işlerde yapay zekayı kullanırken hep böyle kullandığını sanıyordum
Yanılıyor muyum? Bugünlerde herkes sadece YOLO modunda mı çalıştırıyor?
funemployment’ın eğlencesi bu. Tekrar işe başladığımda epey ilginç bir değişim olacak gibi
Şimdilik çalıştırıp, bira içerken yaklaşık bir saat boyunca büyük resim eleştirisi ve özdenetim/kapalı döngü geri bildirimini yeniden ayarlıyor, sonra yine istediği gibi çalışmasına bırakıyorum; basit yani
Claude’u bypass-permissions dışında başka nasıl kullandığınızı merak ediyorum. Claude’un kullanabileceği araç listesini uzun süre yönettim ama sonunda geri geldiğimde bir aracın çıktısını başka bir araca pipe etmeye çalıştığını ve buna açıkça izin verilmediği için takılı kaldığını tekrar tekrar gördüm. Sadece
grepgibi bir şeydi; buna rağmen durması sinir bozucuydubypass-permissions’ta “öylece çalışıyor”. Elbette yalnızca mevcut kodu analiz etmek ve değişiklik önermek için kullanıyorum; bir şey bozulursa zaten sürüm kontrolü bunun için var diye düşünüyorum
Genel olarak yazara katılıyorum. Her şeyden önce şunu eklemek isterim: LLM’in yaptığı ya da söylediği hiçbir şeye güvenmeyin
Bugün Claude’dan 3 bileşenin davranışını birleştirmesini istedim ve bunu 5 kez yaptırdım. Her seferinde sonunda hâlâ uymayan bir şey vardı ve Claude bunu rasyonelleştirmenin bir yolunu buldu
Sorunca “bu benim sorumluluğum” ya da “bunun bilinçli bir tercih olduğunu düşündüm” dedi ama önce ne yapılması gerektiğini sormadı, sorunu da hiç dile getirmedi. Bu yüzden kısa tasmayı tutup düşünme sürecini izlemek ve saçmalıkları düzeltmek gerekiyor. Bu, bugünkü Sonnet 5 için geçerli; yarın daha iyi de olabilir, daha kötü de. Bugün Claude’da işe yarayan üslup yarın farklı sonuç verebilir
“Yapay zekayla X nasıl yapılır” türü yazılardaki sorun, her durumda meselenin tamamen farklı olması. Örneğin bir Symfony projesini 3.1’den 8.1’e yükseltme işinde yol nettir
Her majör sürüm için yazılmış migration rehberlerini izler, tüm route’ları ve kimlik doğrulama akışlarını vb. test edersiniz. Bu testleri de kendiniz seçebilirsiniz; bazıları 200, bazıları 302 döndürebilir
İsteğe bağlı olarak manuel testleri azaltmak için önce bir güvenlik ağı yazabilir ve örneğin PHPStan baseline gibi bir şey de koyabilirsiniz
Route’lar uçtan uca işlevsel olarak niyet edildiği gibi çalışıyorsa iş biter. Burada snapshot testleri de kullanılabilir
Böyle durumlarda yapay zekayı izlemeye gerek yoktur. En sonda kodu review edebilirsiniz ama arada sırada manuel onay vermeye gerek olmadığı için güvenlik özelliklerini kapatırım
Çoğu kişi tek bir bakış açısından yazar ama gerçek bakış açısı geniştir; bir durumda işe yarayan şey başka bir durumda işe yaramaz. Yazılım mühendisliğinin tamamı da nihayetinde neyi nereye, ne zaman uygulayacağını anlayıp geri kalanını görmezden gelmeye çalışma işine benzer
Birçok şirket blog yazısı, her durumda geçerli bir gümüş kurşun varmış gibi inandırır ama genelde bu doğru değildir
Sonuçta bu, yazılım mühendisliğinde hep uğraştığımız gibi “bazı şeyler bazı durumlarda işe yarar” meselesine daha yakındır; doğru-yanlıştan çok, duruma göre gerçek uygulamanın farklı olmasıdır ve bu normaldir
Yapay zeka junior ile mid-level mühendis arası bir seviyede. Ona böyle davranırsanız, tüm bu paranoya olmadan hem vibe coding’in hem de sıkı mühendisliğin avantajlarını elde edebilirsiniz
En başından beri Claude’u izole bir VM’de YOLO modunda çalıştırdım. Bu, bir mühendise kendi dizüstü bilgisayarını vermek gibi. Claude özelliği PR açılabilecek noktaya kadar getiriyor; ben de başka bir mühendis gibi diff’i review edip uygun şekle sokuyor ve devam ediyorum
Deneyimsiz mühendisler de aynı hataları yapar.
rm -rfde gördüm, gerçi root’ta değildi. Tüm yetkileri reddederek birini mikro yönetmeye kalksaydım muhtemelen çıldırırdımJunior/mid-level mühendis benzetmesine de katılıyorum ama büyük bir çekince var. Yapay zeka öğrenmeyi bilmeyen bir junior mühendis gibi
Memento’nun başkahramanıyla çalışmak gibi. Her gün LLM işe geldiğinde, o ana kadarki işlerden hiçbir şey öğrenmemiş oluyor ve her gün ilk günü
Elbette Memento’nun başkahramanı gibi çalışma alanının dört bir yanına post-it’ler ve hatırlatıcılar serpiştirerek yardımcı olabilirsiniz. Çaba gösterilirse “öğrenme” denilen şeye yaklaşılabilir; bu da ekipteki tüm yazılım geliştiriciler için kelimenin tam anlamıyla en önemli özellik
Ama kolay değil ve araçlar da hâlâ yetersiz. Denediğim en iyi şey, Obsidian gibi araçlarla kullanılan “ikinci beyin”e daha yakındı. Ne yazık ki ikinci beynin birinci beynin yerine geçmediğini düşünüyorum. Açıkçası, bir yapay zeka agent’ı gibi öğrenip gelişemeyen bir mühendis olsaydı, çalıştığım şirketlerin herhangi birinde ilk aydan sonra işten çıkarılırdı
Yine de büyük yapay zeka sağlayıcılarının ya da birilerinin bu kısmı ileride iyileştireceği konusunda oldukça iyimserim. İyi bir bellek, bağlama uygun şekilde anıları daha iyi enjekte eden iyi tasarlanmış bir düşünme sistemiyle birleşirse ve gözetimsiz gerçek öğrenmeyi yakalayabilirse, imkânsız bir görev gibi görünmüyor
Bu tür yazıları, umarım birileri bu sorunu çoktan çözmüştür ve benim sadece geç fark etmem gerekiyordur diye okuyorum; ama şimdilik agent tasarlama becerim başa kıyasla sadece biraz daha iyi hale geldi
Benim pratik kuralım şu: Yapay zeka için oluşturulan özel süreçler insanlar için de anlamlı olmalı; değilse değeri yoktur. İyi komut satırı araçları, uzun komut çıktılarının otomatik özetlenmesi, Markdown dokümantasyonu ve workflow’lar insanlar için de faydalı
Hataları ve kötüye kullanımı önlemek için mikro yönetim değil, sandbox ve kapsamı sınırlı yetkiler kullanılmalı
Öğrenmek istediğim şey, yapay zeka agent’ıyla iyi bir pair programming workflow’u. Yüksek performanslı bir modele büyük bir iş verebilirsiniz ve bu iyi çalışır. Düşük seviyeli bir modeli IDE yardımcısı olarak kullanabilirsiniz, o da iyi çalışır. Ama bunlar ayrı workflow’lar
Asıl faydalı olan, yüksek performanslı modelle klavyeyi sırayla paylaşarak birlikte inşa etmek. Ancak bu, kendi makinemde tamamen YOLO modunda çalıştırmak olmamalı. İnsan ile LLM arasındaki fark da bu. Çok hızlı olduğu için raydan çıktığında klavyeyi geri kapmak zor oluyor
Yapay zekanın tam olarak ne olduğunu kimse bilmiyor ama junior ya da mid-level mühendis değil. Daha çok, alan bağlamı olmayan ve her 5 saatte bir hafızasız uyanan, barakada yaşayan bir nükleer staff engineer gibi
LLM hâlâ bir sonraki token tahmincisidir. Daha muğlak talimatlar verdiğinde doğru adımları bulması, zeki olduğu anlamına gelmez. Bu, modelin eğitiminde kullanılan koşumla aynı dili konuştuğun anlamına gelir
Bunun da sınırları var. Kavram kanıtı düzeyinde ya da basit uygulamalarda kalıyorsan, mevcut modelin hâlâ ne kadar sınırlı olduğunu bilmiyor olabilirsin. Böyle yerlerde işi parçalara bölmek gerekir; kulağa makul gelen adımlar sıralayan bir token tahmincisine güvenilmez
Bir yerde mutlaka insan döngüsü olmalı. Yetkileri atlamaya başladığında en iyi ihtimal büyük başarıdır ama daha olası olan, ikinci sınıf çözümler ve token israfıdır. Asıl korkutucu olan, modelin talimatları görmezden gelip aptalca bir şey yaparak gününü mahvetmesidir
Bu, CNC makinesi gibi keskindir. Yararsız değil, ama tehlikeli olabilir. Paralel park yapamıyorsan, canavar gibi bir makineyle ahşap oymaya çalışmamak ya da dar bir mahalleye Ferrari park etmeye kalkışmamak daha iyi olur
LLM’in “token tahmincisi” olduğu için bir şeyi yapabileceğini ya da yapamayacağını söylemek bir kategori hatasıdır. Arayüz katı bir sınır değildir
LLM’lerde zeka olmadığını baştan kabul eden bir aksiyom kullanmadan, dil modellerini dışarıda bırakıp insanları içeri alan bir tanımın nasıl mümkün olduğunu merak ediyorum
Genelde bununla kastedilen “yalnızca eğitim verisindeki, yani internetteki bir sonraki token’ı tahmin ediyor” anlamı; ham model için bu doğru olabilir. Ama modeller sonradan eğitildiği için bu açıklama bile artık doğru değil
“Zeka değildir” demek faydalı değil ve bence yanlış. Senin zeka tanımına uyup uymadığını kim umursar? Hâlâ etkileyici işler yapıyor ve ima ettiğinden çok daha büyük işler de yapıyor
Orijinal yazı sanki hâlâ 2025’te kalmış gibi
“Yapay zeka birkaç kez raydan çıkacak ve ancak yazılımı gerçekten kullanınca fark edeceksiniz” diyor, ama artık o yapay zeka yazılımı bizzat kullanıp hataları bulup düzeltebiliyor ve yeni özellikleri de ilerletebiliyor
Ajanların istenmeyen işler başlatması hâlâ oluyor, ama eskisine göre çok daha az; tam otonom ajanlar yönündeki argüman zayıflamıyor, güçleniyor
“İnsanın codebase’i anlaması insani olarak imkânsız” sözü de eskimiş görünüyor. Artık insanların codebase’i anlamasına gerek kalmadığı ve yapay zekanın yön verdiği bir tarafa gidildiğini düşünüyorum
Pek çok kişi buna atlıyor, ama ben bunu aptalca bir akım olarak görüyorum
Ama güvenlik riski büyük sistemler için kesinlikle doğru değil. Bankacılık, havacılık, savunma gibi alanlarda yapay zeka elbette katkı sağlayacak, ama insan mühendisliği anlayışından bağımsız hareket edemeyecek
Kısa tasma yöntemi, eğitim verisinin dışında çalışırken iyi sonuçları garanti etmenin bir yoludur. Ortalamanın biraz üstünde bir programcı bile, LLM ile hızlı ve kaliteli geliştirmeyi garanti etmenin tek yolunun bu olduğunu görür
İnsanların artık codebase’i anlamasına gerek olmadığı sözü, yapay zekanın programlama dünyasında hâlâ ne kadar feci derecede acemi olduğunu bilmemekten geliyor gibi. Manuel bellek yönetimi olan dillerde bellek işini sık sık berbat ettiğini sürekli gördüm. Bunu Valgrind döngüsüne koymakla çözülecek kadar basit değil
API tanımını, request/response modellerini, veritabanı şemasını ve tüm akışı birçok kez yineleyerek iyileştirdim; çelişkileri gidermek ve dokümanı düzeltmek için çok şeyi bizzat yaptım. Opus sürekli raydan çıktı ve nihai doküman 500 satırı aştı
API entegrasyon testleri için de tekrar tekrar gidip gelmek gerekti. Yapay zeka dokümandan doğrudan test üretemedi; bu yüzden önce Given-When-Then yorumları olan placeholder’lar oluşturup elle gözden geçirip düzelttim, ardından ikinci iterasyonda testleri implemente ettirdim. İncelemeden sonra düzeltilen çok hata vardı
Uygulama aşamasında API dokümanı, çalışan testler, değişiklikleri engelleyen hook, 6’dan fazla “en iyi uygulama” skill’i, “rubber duck” ve “kod sadeleştirme” ajanları, test/linter/derleme hatalarını kontrol etmek için script’ler sağladım. Planlama, yürütme, inceleme ve birkaç tur düzeltmeden sonra özellik implemente edildi ve tüm testler geçti
Kod incelemesinde ortalama her 20 satır kodda bir sorun buldum. Kod stilini hariç tutsak bile Kubernetes servisinde bellek içi semaphore kullanımı, tek bir request sırasında aynı kaydı güncellemek için 8 kez DB çağrısı yapmak, her seferinde tek bir kolonu güncellemek, transaction olmadan oku-değiştir-kaydet yapmak, iş mantığı, kurtarma ve yetkilendirme hataları vardı
Sonuç neredeyse bir haftalık mesai, 100 doların üzerinde token maliyeti ve yalnızca “bu çabaya değdi mi?” düşüncesi oldu. 2 kişilik bir geliştirici ekibim var; az önce birinin PR’ını inceledim, %80’i slop’tu
Benzer bir yaklaşım denedim ama bana pek uymadı. Hız artışı ya yoktu ya da çok azdı. Verimlilik elde etmek için sandbox içinde bir miktar YOLO modu gerektiğini düşünüyorum
Hedef, modelin mümkün olduğunca çok işi üstlenmesini sağlarken, sonuçları anlamak ve incelemek için gereken çabayı en aza indirmek olmalı
Örneğin modele bir hatanın nedenini bulma, X için kavram kanıtı oluşturma, bir şeyi kademeli olarak optimize etme, rehberli ve iyi tanımlanmış refactoring yapma gibi işler verilebilir
İnsanların döngü kurmaktan bahsederken kastettiği de buna çok benziyor. Modelin yaptığını maksimize etmek, onu kontrol etmek için benim yapmam gerekenleri minimize etmek
Yazıda pek bir içerik yoktu
Geçen yıl “AI yalnızca olasılıksal bir papağandır” deniyordu
Bu yıl ise “AI kod yazabilir ama insanın yine de incelemesi gerekir!” deniyor. Elbette o inceleme için de AI kullanılıyor
Bir yıl daha geçince anlatı şu olacak: “Kod incelemesini yalnızca AI yapabilir; AI’ın incelemesini inceleyebilecek olan da yalnızca AI’dır. İnsanların anlamlı bir denetimi sürdürebilmesi için AI’ın nihai görüşünü okumaları yeterlidir”
Kale direkleri sürekli yer değiştiriyor ama kesin kanaat asla değişmiyor