Şu anda birçok şirketin AI kaynaklı bir toplu çılgınlığa kapıldığına inanıyorum
(twitter.com/mitchellh)- Mitchell Hashimoto: "Şu anda birçok şirket ciddi bir AI kaynaklı toplu çılgınlığa kapılmış durumda ve onlarla akılcı bir konuşma yapmak imkansız"
- Bulut altyapısı otomasyonu dönemindeki MTBF vs MTTR tartışması artık yazılım geliştirme sektörünün tamamına yayılmış durumda ve AI ajanlarına körü körüne güven yeni bir toplu çılgınlık biçimi yaratıyor
- "Ajanlar hataları hızlıca düzeltecek, o halde hatalı yazılımı yayına almak sorun değil" şeklindeki MTTR her derde deva yaklaşımı yaygınlaşıyor; bu ise altyapı döneminde zaten başarısız olduğu görülen bir düşünce biçimi
- Sistemler yerel metriklerde sağlıklı görünüp genel olarak anlaşılmaz bir hale dönüşebilir; hata raporlarının azalması ve test kapsamının artması gerçek güvenliği garanti etmez
- Bu sorun doğrudan dile getirildiğinde, "test kapsamı %100" ya da "hata raporları azalıyor" gibi anlık itirazlarla konuşma tıkanıyor ve kimse büyük resmi göremiyor
- Değişim o kadar hızlı ki kimse temel mimarideki çürümeyi fark etmeden otomatikleştirilmiş bir "dayanıklı felaket makinesi" inşa ediyor
Temel iddia: AI toplu çılgınlığı (AI Psychosis)
- Şu anda birçok şirket ciddi bir AI toplu çılgınlığı içinde ve onlarla akılcı bir konuşma yürütmek başlı başına imkansız
- Somut isimler verememesinin nedeni, bu kişilerin arasında kişisel olarak derin saygı duyduğu arkadaşlarının da bulunması
- Bu durumun nasıl ilerleyeceğine dair derin endişe dile getiriyor
Altyapı döneminden ders: MTBF vs MTTR
- Buluta geçiş ve bulut otomasyonu döneminde yaşanan MTBF (ortalama arızalar arası süre) vs MTTR (ortalama kurtarma süresi) tartışması yeniden gündeme geliyor
- O dönemde bu tartışma altyapı alanıyla sınırlıydı; şimdi ise yazılım geliştirme sektörünün tamamına (hatta daha geniş ölçekte dünyaya) yayılmış durumda
- AI'ye aşırı inananlar neredeyse mutlak bir "MTTR yeterlidir" düşüncesiyle hareket ediyor
- "Ajanlar hataları insanların yapamayacağı hız ve ölçekte düzeltecek, o halde hatalı yazılımı yayına almak sorun değil" mantığı
- Altyapı döneminde öğrenilen ders: MTTR harikadır ama dayanıklı sistemlerin kendisinden tamamen vazgeçilemez
Konuşmanın tıkanması ve itiraz kalıpları
- Bu konu şahsen tanıdığı kişilere açıldığında anında geçiştirme ile karşılaşıyor
- "Hayır, test kapsamı kusursuz" ya da "hata raporları azalıyor" gibi tepkiler
- Bu itirazlar büyük resmi göstermiyor
- Kaygılarını doğrudan ve kişisel olarak ilettiğini ama dinlenmediğini, bu yüzden daha geniş ölçekte paylaşmanın önemli olduğunu düşündüğünü söylüyor
Otomatikleştirilmiş felaket makinesi
- Altyapıda daha önce öğrenilmiş bir ders: Otomasyonla "son derece dayanıklı bir felaket makinesi" kurulabilir
- Sistemlerin yerel metriklerde sağlıklı görünürken genel olarak anlaşılmaz hale gelmesi mümkündür
- Hata raporları azalırken gizli riskler patlayabilir
- Test kapsamı artarken anlamsal kavrayış azalabilir
- Değişim o kadar hızlı gerçekleşir ki kimse temel mimarideki çürümeyi fark etmez
Öne çıkan yanıtlardaki noktalar
- @adamhjk: "Saf vibe coding'in ilk yok ettiği şey mimarinin kendisi"; ayrıca çürümeyi fark etmek için en başta bir mimarinin var olması gerekir
- Mitchell Hashimoto'nun ek açıklaması: Altyapıda çevrimiçi sistemler güncellenerek makul bir süre içinde tüm kullanıcılara MTTR uygulanabilir; ancak kütüphaneler, masaüstü yazılımları ve mobil uygulamalar gibi başkalarının entegre ettiği ya da doğrudan çalıştırdığı yazılımlarda bu yaklaşım işlemez
- @tinygrad: AI'nin söylediğinin tamamen yanlış bilgi olup olmadığını anlamanın artık 10 saniye değil 20 dakika aldığı bir döneme girdik; organizasyonların gerçeklikle temasını koruması gerekiyor
- @beyang: Mevcut ajan UX'i, "LGTM(Looks Good To Me)" seçeneğini en az dirençli yol haline getiriyor ve ajanların ürettiği ikna edici görünen kodun hızı, kod incelemesindeki doğrulama sorununu anlık bir tehdide dönüştürüyor
- @beh_zod: Yayına almanın ödül fonksiyonu kısadır; insanların biriktirdiği borcu fark etmesi için gereken süre ise çoğu dikkat aralığının ötesindedir
- @shipwithjay: Mühendislik liderliğinin karşı-olgusal sorulara (bunu durdurmak için hangi şeylerin doğru olması gerekir?) yanıt veremeyip sessiz kalması bir belirtidir
- @chadfowler: Bu konu hakkında bir kitap yazıyor; temel nokta titizliği (rigor) mimariye ve değerlendirme sistemlerine yeniden yerleştirmek ve bugünün, bugüne kadar zaman ve maliyet eksikliği yüzünden uygulanamayan en iyi pratikleri hayata geçirmek için bir fırsat olması
Mitchell Hashimoto'nun insanların sorularına ve yorumlarına verdiği yanıtlar
- S: "Bunun yerine ne yapmalıyız?"
- C: "Düşünün (AI kullanın ama düşünün)"
- S: "AI fazla abartıldı" düşüncesinin aslında daha da psikoz benzeri bir semptom olabileceğini düşünüyorum
- C: Tüm dünyevi trendler abartılır ama bu, onları toptan yok saymak için bir gerekçe değildir
- S: "Elimde olanı korumakla riskin içine atlamak arasında seçim yapmam gerekse, ikincisini seçerim"
- C: Bu ikili bir anahtar değil
1 yorum
Hacker News görüşleri
AI mimari danışmanlığının, güvenlik ihlali müdahalesi ya da veri kurtarma uzmanlığı gibi yüksek değerli danışmanlığın büyük bir türü haline geleceği düşünülüyor
Tamamen AI tarafından yazılmış sistemler insanların anlayamayacağı kadar karmaşık hale gelebilir; hata düzeltme oranı düşerken hata başına token tüketimi artar ve sonunda AI değişiklikleri düzelttiğinden daha fazla hata üretip her şeyi istikrarsızlaştırabilir
Böyle bir keşmekeşi clean room yaklaşımıyla toparlayıp temel tasarım ilkelerini çıkardıktan sonra, muhtemelen yine AI kullanarak baştan yeniden kurmayı içeren özel bir sürece ihtiyaç duyulacaktır
Geleceğin yazılım mühendisliği baştan buna yol açmamayı hedefleyen ilkeler etrafında şekillenecektir; ama mevcut yazılım mühendisliğinin de sağlam tasarım ilkelerine ulaşması beklenenden uzun sürdüğü için, bunu öğrenmemiz muhtemelen 20 yıl alacaktır
Hastane tarafı IT departmanı sunucu erişimini bile verdi ama Claude’u bağlayamadığı için nasıl deploy edeceğini bilmeden epey bocalayıp bana ulaştı; ayrıca uygulamada ilginç veri/durum problemleri de var gibi görünüyor
Sanki Amazon’dan sonsuz bedava ürün eve getirtiyormuşsunuz gibi; teoride bolluk içinde bir hayat ama pratikte refahtan çok başka bir şeyin altında kalıyorsunuz
Bunun nasıl sonuçlandığını herkes biliyor
Binlerce satırlık Github Actions içinde Kubernetes’in yarısı yeniden yazılmış gibiydi ve anlamak imkânsızdı
AI pazarlamasından hoşlanmıyorum ama deneyimli insanların daha hızlı hareket etmesini sağlayan bir araç olarak faydalı olduğunu düşünüyorum
Yalnız uzman olmayanlar için AI, yapılmak istenen her şeyde karmaşık çözümler üretmeye meyilli görünüyor
Burada anlatılanın, AI kullanımının kendisinden çok şirketlerin ve insanların karar verme ve düşünme işini AI’a dış kaynak olarak vermesi olduğu anlaşılıyor
AI ile kod yazmak AI psikozu ya da kötü bir şey değil; ama sadece prompt girip AI’ın söylediğine inanmak bana daha çok AI psikozu gibi geliyor
Twitter’daki finansçılarla VC’lerin, biraz kendi başlarına düşünmeleri yeterli olacak konularda düşünme ve muhakeme yerine ChatGPT ekran görüntüleri kullandığını sık görüyorum
Bu araçlar fikir, düşünce ve tavsiye konusunda berbat; sadece pattern matching ile pattern gibi görünen şeyler üretiyorlar, bu yüzden bir fikir sorduğunuzda genelde en jenerik saçmalıkları kusuyorlar
Buna karşılık kod yazımı gibi pattern matching’in gerçekten işe yaradığı görevlerde epey faydalılar; ama düşünme ve karar verme işini onlara bırakmamak gerekiyor
Genel olarak tavan daha yüksek, taban daha düşük hale geldi ve yukarıdaki tarif çok isabetli
Bununla ilgili yazdıklarım: https://mitchellh.com/writing/my-ai-adoption-journey, https://mitchellh.com/writing/building-block-economy, https://mitchellh.com/writing/simdutf-no-libcxx
Son yazı, AI sayesinde yaptığım karmaşık bir değişiklikti ve buna nasıl makul biçimde yaklaştığımı da gösteriyor
Neredeyse her zaman mantıklı görünen metin üretiyor ama o metnin içinde, ilgili kullanım senaryosuna uymayabilecek yanlış örtük varsayımlar ve kararlar bulunabiliyor
Gerçekten doğru çözümü üretebilmek için problemin tanımı düzgün yapılmalı; bu da çözümü üretmekten daha zor olabilir
Ya da rastgele danışmanlara bırakmalarından
“AI bunun iyi bir fikir olduğunu söyledi” demek, gerçekten “sektör trendini takip ettik” demekten daha mı kötü?
Biri tek başına böyle davrandığında, arkadaşları ve ailesi garip davranışlarını ya da sözlerini işaret ederek bir miktar frenleyebiliyor
Ama işveren bunu liderlik düzeyinde yapmaya başladığında ne kadar kötüleşebileceğini hayal etmek zor
Sizden de buna katılmanız bekleniyor ya da işten çıkarılmaktan korkuyorsunuz; düşüncenizi dengeleyecek kişiler yalnızca karşı çıkan iş arkadaşları oluyor ama onların da ayrılma ya da kovulma ihtimali yüksek
İşinizi korumak için uyum sağlamanız gerekiyor
Çünkü kararları ajan veriyor, işler ajanın hızında ilerliyor ve çoğu zaman hiçbir şey söylemeden kararları alıp size sadece “işte plan” şeklinde son çıktıyı sunuyor
Bunu gerçekten gözden geçirmek için problemi derinlemesine anlamanız gerekiyor; bu da yeniden insan hızına dönmek demek, dolayısıyla sonunda üstünkörü bakıp onaylıyorsunuz
Asıl mesele, hangi kararları dışarı vereceğinizi bilinçli ve dikkatli biçimde seçmek
Bunun için yavaşlamak gerekiyor; abartılan 10 kat vibe coding kazancı azalıyor ama daha fazla müdahil oluyor ve daha az bilişsel borç biriktiriyorsunuz
Dizinin nasıl dolaşılacağı, bir çağrının çıktısının diğer çağrının girdisine nasıl uydurulacağı gibi sıkıcı kararlar ajana bırakılabilir
Gerçek kararları ise önceden verip spesifikasyona koymak gerekir: sınırlar, API’ler, temel veri yapıları, sistemler ve sorumluluklar, hata işleme, güvenlik ve gizlilik için sıkı kısıtlar tanımlanmalıdır
Belirsizlik varsa ajanı durması için yönlendirmelisiniz; iyi bir mühendis de yan etki olmadan 2-3 kat hız artışı elde edebilir
Belki de bu durum yazılım mühendisliğini gerçekten bir mühendislik disiplinine dönüştürür
Şu anda prompt yazanlar bütün şirket altyapısını kuruyor
Kişisel olarak tanıdığım biri şirket veritabanını daha yeni bir Postgres sürümüne migrate etti ve sonunda başardı ama süreci anlatırken dişlerimi sıktım
Hissi şuydu: “Sunucuya benzin döküp sigara içtim ama merak etme, bodrumda bir yangın söndürücü buldum. Göstergesi boş diyor ama sallayınca içinde hâlâ sıvı sesi geliyor.”
O kişi şirketten ayrılırsa, o DB altyapısını ayakta tutacak daha da özgüvenli bir prompt yazıcısına ihtiyaç duyulacak
Bu yazı, “hataları canlıya almanın sorun olmadığını, çünkü ajanların insanın yapamayacağı hız ve ölçekte bunları düzeltebileceğini” söyleyenlerle tartışılamayacağını vurguluyor
Ama en üstteki yanıt tam da “ama ajanlar çok hızlı” diye buna örnek oluyor
Belki de codebase ve özelliklerin iki katına çıkmasından gelen kazancın, hataların iki katına çıkmasından gelen zarardan büyük olduğu varsayılıyor
En azından bu çeyreğin yatırımcı bülteninde güzel görünür
Belki sadece gitgide daha fazla çöpü canlıya alıyorlar; geri bildirim döngüsü müşteri mi oluyor?
Aldığım cevap şuydu: “Bu game theory. Birileri yapacak ve sen de yapmak zorunda kalacaksın. O kadar kötü olamaz.”
Mantık yararlıdır ama riskleri görmezden gelmek başka bir şeydir
Aşırı hızla ilerleyip her şeyi parçalayınca sonunda iyi bir sonuç çıkacağını varsaymak tehlikeli
Bu AI akımının gidişatını iyi bulmuyorum
Psikoz yaşayan tarafın ille de “bizim taraf” olduğunu düşünmüyorum
Çok büyük bir şirkette çalışıyorum ve bizim şirket modernleşme ile teknoloji benimseme konusunda her zaman buzul gibi yavaştı
Ama tuhaf biçimde, bu artık bir rekabet avantajı olabilir
Hayat sanatı taklit ediyor
Eskiden hâlâ faks kullanılmasıyla dalga geçerdim ama böyle bir çılgınlığın olmadığı bir kültürde çalışmanın bu kadar iyi hissettireceğini düşünmezdim
HN okuyunca kendimi token maksimalistleriyle AI psikozu yaşayanların Alice's Wonderland’ine girmiş gibi hissediyorum
Burada gerçekten kimsenin bu şekilde çalışmaya zorlandığını bilmiyorum
Eğer bu hissi seviyorsanız, yeni CLI aracı Burn, Baby, Burn (those tokens) hoşunuza gidebilir: https://github.com/dtnewman/burn-baby-burn/tree/main
Show HN burada: https://news.ycombinator.com/item?id=48151287
Rich Hickey’nin Simple Made Easy konuşmasını ve Clojure’u geliştirirken benimsediği yaklaşımı hatırlatıyor
LLM’ler tüm programı üretmeden önce de karmaşık framework’ler geliştiricilerin ilk sürümü çok hızlı oluşturmasını sağlıyordu ama bunun bedeli, programın anlaşılmasının ve dolayısıyla debug edilip değiştirilmesinin zorlaşmasıydı
Bazıları, AI ne kadar iç içe geçmiş ve karmaşık programlar yazarsa yazsın, AI’ın bunları her zaman debug edecek, bakımını yapacak ve değiştirecek kadar akıllı olacağına bahis oynuyor
Ben bundan o kadar emin değilim
AI psikozu, AI kullanımına karşı olmak anlamına gelmiyor
AI kodlama araçlarını her gün kullanıyorum ama AI araçlarının gelecek diye bir kavramı yok
“Bu production’da patlarsa ben düzeltemem ve sabah 3’te beni ararlar” diye düşünen mühendisin bencil kaygısına güvenerek kararlı sistemler kurduk
CPAN’de mükemmel kütüphaneyi bulup işi kendimiz yapmamak istemekten gelen sıradan tembellik de vardı; hatta bazen bir kütüphaneyi aramak, onu kendin yazmaktan daha uzun sürüyordu
AI araçlarıyla binlerce satır kod yazıp production’a koydum ve bu bana büyük ölçüde doğal geldi; çünkü 2017’den beri insanlara kodu baştan sona elle yazmak yerine yazdırmalarını söylüyor, testlerde kötü kodu yakalayacak tuzaklar kuruyorum
Ama AI’ın yapmadığı bir şey var: daha az kod yazmak: https://xcancel.com/t3rmin4t0r/status/2019277780517781522/
İnsanlar düzeleceğine olan inancını kaybettiğinde bug report sayısı da düşer
Çünkü bug bildirmek çoğu zaman ciddi bir zaman yatırımı gerektirir
Bir gruba ya da şirkete duyulan güven çöktüğünde bu oldukça sık olur
Bu yüzden yanlış raporlama ihtimali daha yüksek ve bazı içerikler de hatalı olabilir
Yani birden fazla yönden saldırı altındasınız
Daha adversarial taktiklere henüz gelmedik bile
Ahlakınız yoksa, rakibinize ajanlarla sahte bug report yağdırmaktan daha iyi ne olabilir?
Sorun çözüldü
Mitchell’in gözlemlediği şeylerin önemli bir kısmı, belki tamamı, AI olmadan da rahatlıkla yaşanabilir
Kendimi gerçekten tuhaf bir yerde hissediyorum
AI’ın kod yazma deneyimi ve pratiğine getirdiği değişimden o kadar nefret ediyorum ki bilgisayar kullanmak dışında her şeyi yapmak istiyorum; ama aynı zamanda bu araçların çok güçlü olduğunu ve giderek daha iyi hale geldiğini de düşünüyorum
Mitchell’in ana fikri geçerli. Bu araçlar çürük temelleri sisteme sokabilir ve bunu ancak tüm yapı çöktükten sonra fark edebilirsiniz
O noktada sorumluluk taşıyan tarafta olup da codebase’i eskisi gibi derinlemesine anlamıyor olmak istemem
Ama insanlar da uzun zamandır koda ince ama ölümcül bug’lar yerleştiriyor
Bu yüzden bunun önemli bir bölümü hâlâ açık bir ampirik soru gibi geliyor
Daha önce görmediğimiz şekillerde korkunç biçimde çöken çok sayıda sistem mi göreceğiz? Belki bazılarını
Aynı zamanda spesifikasyon ve doğrulamaya daha çok yönelmemiz gerektiğini de öğrenmeyecek miyiz? Bilmiyorum
Her durumda, bu şekilde sistem inşa etmek, arada çarpışmalar olsa da kaçınılmaz görünüyor
AI karşıtı tarafta da kendine özgü gerici bir psikoz var gibi geliyor
AI ile uğraşmak istemiyorum ama bu araçları kullanma deneyimimi de inkâr edemem
Keşke bu tür gerçekçi ama olumsuz AI tartışmaları için daha fazla alan olsa
Mitchell’in iyi bir geliştirici olmasının nedenlerinden biri de bu