Veritabanınızı silen AI değildi, sizdiniz

• Cursor/Claude ajanının production veritabanını silmesi olayındaki asıl mesele, AI'ın yanıtını analiz etmek değil; tüm silmeyi mümkün kılan API endpoint'inin neden dağıtıma çıkmış bir sistemde bulunduğudur
• 2010'daki SVN dağıtım kazasında, manuel kopyalama süreci sırasında trunk silinmişti; aynı hatayı önlemek için dağıtım otomasyonu geliştirildi ve bu daha sonra CI/CD pipeline'ına dönüştü
• Otomasyon aynı işi aynı şekilde tekrar eder; ancak AI böyle bir garanti vermez ve “thinking” ya da “reasoning” gibi görünse de gerçekte token üretiyor
• Production veritabanının tamamını silebilen herkese açık bir API varsa, AI olmasa bile bir gün birinin onu çağırma olasılığı yüksektir; yalnızca çağıranı suçlamak sistem tasarımı sorununu görünmez kılar
• AI'ı geniş çapta kullanan organizasyonlarda production'a ne deploy edildiğini bilmek önemlidir; yetkin geliştiricilerin AI'ı sorumluluktan kaçma aracı değil, işi güçlendiren bir araç olarak kullandığı bir sürece ihtiyaç vardır

---

Sorunun özü AI değil, dağıtıma çıkmış sistemin sorumluluk sınırları

• Cursor/Claude ajanının şirketin production veritabanını sildiğine dair tweet yayılmış olsa da, daha temel soru şudur: “Production veritabanının tamamını silebilen bir API endpoint'i neden vardı?”
• İlgili kullanıcı, ajana “bu davranışı asla yapma demiştim; neden sildin?” diye sormuş ve yanıtı analiz etmeye çalışmıştı, ancak eksik olan şey sorumluluğun kime ait olduğuydu
• AI'ı koşulsuz savunmak mümkün değil, ama bir aracı kendi hatanızın yerine suçlayamazsınız
• AI bu endpoint'i çağırmamış olsaydı bile, böyle bir işlev herkese açık bir API olarak mevcutsa, bir gün başka birinin onu çağırmış olma ihtimali yüksekti
• Bu, bir arabanın gösterge paneline kendini imha düğmesi koyup sonra ona basan çocuğa “neden bastın?” diye hesap sormaya benzer

2010 SVN dağıtım kazasından çıkarılan ders

• Bir şirketteki dağıtım süreci son derece manueldi ve sürüm kontrolü için SVN kullanılıyordu
• Dağıtım sırasında trunk, sürüm tarihi eklenmiş bir klasöre kopyalanıyor; ardından bu sürüm tekrar “current” adıyla kopyalanarak en güncel sürümün alınması sağlanıyordu
• Bir gün dağıtım sırasında trunk yanlışlıkla iki kez kopyalandı ve CLI'da önceki komut düzenlenerek yinelenen kopyayı silmeye çalışıldı
• Ancak gerçekte silinen yinelenen kopya değil, trunk oldu; daha sonra başka bir geliştirici trunk'ı bulamayınca sorun ortaya çıktı
• Baş geliştirici silmeyi geri alan komutu çalıştırdı; loglardan sorumlu kişi tespit edildikten sonra, aynı hatayı önleyecek bir dağıtım otomasyon script'i yazmak bir sonraki iş oldu
• O gün bitmeden daha sağlam bir sistem kuruldu ve bu sistem daha sonra tam teşekküllü bir CI/CD pipeline'ına dönüştü

Otomasyon ve AI aynı güvenliği sağlamaz

• Otomasyon, manuel ve tekrarlı işlerde ortaya çıkan küçük hataları azaltmaya yardımcı olur
• Soru “SVN trunk silinmesini neden engellemedi?” olmamalı; asıl sorun, insanların her gün aynı işi eksiksiz biçimde tekrar etmesini gerektiren manuel süreçti
• İnsanlar makineler gibi aynı işi her seferinde birebir tekrar edemez; bu yüzden hata kaçınılmazdır
• AI çok fazla kod ürettiğinde otomasyona benzer bir güven hissi doğabilir, ama otomasyon “her zaman aynı işi aynı şekilde yapmak” demektir
• AI, branch kopyalayıp yapıştıran bir insan gibi hata yapabilir ve bunu neden yaptığını açıklayacak bir donanıma da sahip değildir
• “thinking” ya da “reasoning” gibi terimler, zeki bir ajan içgörüyle düşünüyor izlenimi verebilir; ama model gerçekte hâlâ token üretiyor

Tehlikeli API eninde sonunda çağrılır

• Production veritabanının tamamını silebilen herkese açık bir API'nin varlığı başlı başına temel risktir
• AI bu endpoint'i çağırmamış olsa bile, eninde sonunda birinin çağırmış olması muhtemeldir
• Bir arabanın gösterge paneline kendini imha düğmesi koyarsanız, o düğmeye basmamak için birçok neden olsa da, çocuk koltuğundan kurtulan bir çocuk büyük kırmızı düğmeyi görünce ona basabilir
• Böyle bir çocuğa akıl yürütme sürecini sormanın anlamı yoktur; alacağınız yanıt en fazla “bastım çünkü oradaydı” olur
• Silinebilen bir yol bırakıp sonra çağıranı suçlamak, sistem tasarımındaki sorunu örtmez

AI'ı yoğun kullanan organizasyonların daha çok ihtiyaç duyduğu şey

• Uygulamanın büyük bir kısmı muhtemelen vibe-coded idi
• Ürün ekibi AI tarafından üretilmiş açıklamalar sağlıyor, yazılım mimarı AI ile ürün spesifikasyonu hazırlıyor, geliştirici AI ile kod yazıyor ve reviewer AI ile onay veriyorsa, sorumluluk sınırları bulanıklaşır
• Bug çıktığında geriye, orijinal kodu üreten GPU ile aynı bile olmayabilecek başka bir AI'ı sorgulamaktan başka pek bir şey kalmaz
• GPU'yu suçlayamazsınız
• Basit çözüm, production'a ne deploy edildiğini bilmektir
• Daha gerçekçi çözüm ise, AI yaygın biçimde kullanılsa bile yetkin geliştiricilerin onu sorumluluktan kaçma aracı değil, işi güçlendiren bir araç olarak kullandığı bir süreç kurmaktır
• Bu da CEO ya da CTO'nun kodu bizzat yazmasına izin vermemek gerektiği sonucuna varır

[GN⁺]

Hacker News görüşleri

• Buradaki bakış açısının tamamen yanlış olduğunu düşünüyorum. Sorun, insanların artık dünyayı hesap verebilirlikten kaçma araçları etrafında kuruyor olması
  10 yıldan uzun süre önce Gerald Sussman ile yaptığım bir konuşma beni çok etkilemişti: https://dustycloud.org/blog/sussman-on-ai/
  Sussman, AI'nın kara kutu gibi çalıştığı yönle ilgilenmiyordu; istediği şey, sembolik akıl yürütmeyi açıklayabilen yazılımdı. Bir AI araba yoldan çıktıysa neden çıktığını bilmek istediğini, geliştiriciyi mahkemeye çıkarmaktansa AI'nın kendisini mahkemeye çıkarmak isteyeceğini söylüyordu
  Birkaç yıl sonra Sussman'ın öğrencisi Leilani Gilpin'in tam da bu konu üzerine "Anomaly Detection Through Explanations" başlıklı bir makale yazdığını öğrendim. Sinir ağlarının davranışlarını açıklamak için bir propagator modeliyle konuştuğu bir sistemi inceliyordu: https://people.ucsc.edu/~lgilpin/publication/dissertation/
  Bu yönde devam eden çalışmalar var, ama burada daha önemli olan şey, AI şirketlerini sorumlu tutmanın tamamen makul olması. Şirketler sorumluluk üstlenemeyecek sistemler hakkında bir sürü iddiada bulunuyor, o yüzden sorumluluk onların üstüne kalmalı
  Daha iyi yol, baştan böyle özellikleri olmayan sistemleri kullanmamak ve bunun yerine bu özelliklere sahip sistemleri ölçeklendirmek

  • Ekibim ve ben sorumluluğun kullanıcıda olduğu konusunda çok netiz. LLM diğer araçlar gibi bir araç, sadece deterministik değil
    Aracı kullanan da benim, erişim yetkisi veren de benim, her şeyi güvenli tutmak zorunda olan da benim
    Eskiden gparted ile yanlış diski silip kendi ayağıma sıkmıştım; bu gparted'ın hatası değildi, benim hatamdı
    LLM'in gözetimsiz şekilde serbestçe çalışmasına izin vermek kulağa güzel geliyor ama sonunda acıyla bitiyor. Çalışırken de işi denetlemeniz gerekiyor. İnsanın yerini almaya çalışsanız bile sonucun nereye gittiğini görmeniz gerekir ve yakında LLM aptalca bir şey yaptığında sorumluluğu taşıyacak tek kişi, o aracı kullanan kişi olacak
  • STS yüksek lisansındayken, yazılımın temel kullanım alanlarından birinin failiyeti ve riski devretmek ya da ondan kaçmak olduğu üzerine tez yazmayı düşünmüştüm
    Bu, IBM'in meşhur "bilgisayarlar sorumlu tutulamaz" slaydının tam tersi. Artık şirketler sorumluluğun bilgisayara yıkılmasını tercih ediyor. Çünkü bilgisayar yasa dışı bir şey yaptığında hukuken daha avantajlı bir konuma geçmek daha kolay oluyor
    Yasayı çiğneyen bir araç yapmak istiyorsanız, bunu dışarıya yaptırır ve sigorta yaptırırsınız. Asla düzgün denetlenemeyecek bir düzende insanları "gözetmen" diye işe alır, işler ters giderse onları kovarsınız. Yeni komuta-kontrol yazılımlarıyla sorumluluğu küçük parçalara bölebilir, işin riskini tamamen sahadaki insanlara yükleyip kârın neredeyse hiçbirini onlara bırakmayabilirsiniz
    Bu sadece AI'nın değil, genel olarak modern yazılımın sorunu ve modern finansallaşmayla birlikte sık sık işliyor
    STS burada kabaca teknoloji odaklı sosyoloji gibi düşünülebilir ama alan aslında çok daha geniş
  • Hesap verebilirlik, Amerikan toplumunda en çok eksik olan bileşen
  • Claude'un açıkça dokunmaması söylenen dosyaları neden durmadan değiştirdiğini kesin bir şekilde bilmek istiyorum
    Hem .mds hem de Claude'un planı o dosyalara dokunmamasını söylüyordu ama Claude yine de dokunmaya devam etti ve son zamanlarda bu tekrar tekrar oluyor. Bu çok temel bir başarısızlık
    Sinir bozucu olsa da nedenini bilsem en azından bir şeyler yapabilirim, ama şu an kara kutu olduğu için bazen tamamen aptalca çıktılar veriyor ve kötü çıktıların oranı da bir muamma
    Bazen kumar gibi hissettiriyor
  • Bu kitap tam yerinde olurdu: https://en.wikipedia.org/wiki/The_Unaccountability_Machine
    Aslında teknolojiyle ilgili bir kitap değil, örgütsel yapıdaki sorumlulukla ilgili

• Yazı, şirketin veritabanı silmek için özel bir endpoint eklediğini varsayıyor gibi görünüyor. Asıl metni okuyunca bulut sağlayıcısının kaynak yönetimi için bir API sunduğu ve bunun içinde volume silme API'sinin de yer aldığı anlaşılıyor
  Yazı, böyle hataların çözümü olarak otomasyonu öneriyor ama Terraform gibi altyapı otomasyonu araçları da tam olarak o veritabanını silmeyi mümkün kılan API'ye dayanıyor
  En büyük hata bence üç taneydi. Birincisi, AI'nın erişebildiği yerde sınırsız yetkili bir API token vardı ve token'ın yetkilerinin bu kadar geniş olduğu bilinmiyordu gibi görünüyor. İkincisi, production veritabanı volume'ünde silme koruması yoktu. Üçüncüsü, volume silinince ilgili snapshot'ların hepsi de anında silindi
  Snapshot silme işlemi varsayılan olarak gecikmeli olmalı. AWS de aynı tehlikeli varsayılanla geliyor gibi duruyor ama en azından AWS desteği volume'ü geri getirebiliyor: https://alexeyondata.substack.com/p/how-i-dropped-our-produc...
  Asıl sorun AI değildi. Elbette AI'nın oradan buradan token toplaması epey korkutucu ama otomasyon da çözüm değil. Sadece bir Terraform yapılandırma hatasıyla da aynı veritabanı silinebilirdi
  Bulut sağlayıcıları güvenli varsayılanlar sunmalı; yani sınırlı yetkiler ve gecikmeli snapshot silme, ayrıca kullanıcıların sınırsız token oluşturduğunu daha açık şekilde gösterebilmeli

• Birincisi, bir insanın production veritabanına yazma yetkisi varsa ne yaparsa yapsın veritabanı silinebilir
  İkincisi, geliştirme ve otomasyon sürecinde veritabanını yok etmek için meşru nedenler de vardır. En büyük sorun, geliştirme verilerinin çoğu zaman değiştirilebilir bir sürü gibi değil, değerli bir evcil hayvan gibi ele alınması
  Elbette bunun production'da çalışmaması için korkuluklar şart ama bir insan production'da çalıştıracak kimlik bilgilerine erişebiliyorsa bir ajan da erişebilir
  Büyük organizasyonlarda bunu geliştirme/operasyon ayrımıyla koruyabilirsiniz. Tek kişilik geliştiriciler ya da küçük ekipler için ise çok daha fazla disiplin gerekir. AI'dan önce de junior ve mid-level geliştiriciler ayrımı nasıl yapacaklarını bilmiyordu, senior'lar ise yeterince bildiklerini sanıp gevşeyebiliyordu
  Muhtemelen https://www.cloudbees.com/blog/separate-aws-production-and-d..., Terraform'a giriş, GitHub Actions'a giriş ve production kimlik bilgilerinin bulunduğu ama AI'nın erişemediği bir sanal makine gibi bir kombinasyon gerekiyor
  Ama o noktaya geldiğinizde zaten vibe coding aşamasını geçmiş oluyorsunuz. Başarılı vibe coder'lar da böyle korku hikâyeleri yaşayıp bu aşamayı hızla geçmeleri gerektiğini öğreniyor gibi görünüyor

  • Production ve geliştirmede aynı izinlere ihtiyaç yok
    İki durumda da insanların ham bulut sağlayıcısı API'sine doğrudan erişmesi gerekmiyor. Daha fazla güvenlik kontrolü ekleyen bir yerel proxy kullanabilirsiniz
    Geliştirmede istediğiniz kadar silebilirsiniz. Production'da ise önce yakın zamanda kullanılıp kullanılmadığı gibi çeşitli koşulları kontrol etmek gerekir. İnsanların production kaynaklarını doğrudan silme yetkisine sahip olması gerekmez; istisnai acil durumlar için break-glass yapılandırması bulunabilir

• İşte bu yüzden stajyer almamak lazım. Stajyerler bir şeyleri silip ortalığı karıştırabilir
  İzinleri doğru ayarlamamanın sorumluluğunu AI'ya yükleyecek olan insanlar, production'daki bir şeyi silen bir stajyere de aynı şekilde suçu yükler
  Sorumluluk yukarı, övgü aşağı gitmeli ama insanlar bunu hep tersine çeviriyor

  • Bence bunun doğru ifadesi "stajyer almamak lazım" değil, stajyere production veritabanını silme yetkisi vermemek lazım olmalı
    Bu bir AI başarısızlığı değil, süreç başarısızlığı
    AI'ya tam olarak o işi yapabilecek yetkiyi verip sonra neden AI'yı suçladıklarını gerçekten anlamıyorum
    Bu, AWS'de veritabanınızı açık internete açıp sonra AWS'yi suçlamaya benziyor. Bu AWS'nin hatası değil, bu da AI'nın hatası değil
  • Production kimlik bilgileri içeren bir kod tabanını neden LLM'e açarsınız ya da bir stajyere/junior geliştiriciye neden production kimlik bilgileri verirsiniz, anlamıyorum
    Eskiden her projede bilerek ayrı bir "PROD" checkout tutardım; böylece production modunda çalıştırmak için özellikle oraya girdiğimi bilirdim
    Bir zamanlar .sln dosya yoluna göre Visual Studio'nun rengini tamamen değiştiren eklentiler de vardı; böylece hangi rengin production hangisinin geliştirme olduğunu kolayca hatırlayabiliyordunuz
    Kontrolü kolaylaştırmak için master branch'in en güncel halini tutan ayrı bir kopya da fiilen elimde olurdu
  • Önemli fark şu: kimse stajyerleri insanlığın nihai çözümü diye pazarlamıyor, ama AI tam olarak böyle pazarlanıyor
  • Tuhaf bir dünya. Ben stajyerken işte düzenli olarak halüsinasyon görseydim, ücretsiz çalışıyor olsam bile kovulacağımdan oldukça eminim
  • Stajyerler insandır ve insanlardan her zaman hesap sorulabilir. Bilgisayarlar için bu asla geçerli değildir
    Bu yüzden hiç kimse bilgisayarlara insani kararları bırakamaz

• Son zamanlarda AI hakkında konuşurken tutarlı biçimde izlenmesi gereken birkaç ilkeyi savunan bir yazı yazdım: https://susam.net/inverse-laws-of-robotics.html
  Kısacası, AI sistemlerini insanlaştırmayın, AI sistemlerinin çıktısına körü körüne güvenmeyin ve AI sistemi kullanımından doğan tüm sonuçlar için insani sorumluluğu ve açıklama yükümlülüğünü tamamen koruyun
  AI etrafındaki dilin daha az insanlaştırıcı, daha teknik olmasını isterdim. Kesin dilin berrak düşünmeyi ve iyi muhakemeyi teşvik ettiğine inanıyorum
  AI'yı başka bir araç gibi ele alıp buna uygun bir dil kullanırsak, birçok durumda aracın "hatası"ndan sorumluluğun onu kullanan kişide olduğu çok daha açık hale gelir
  Ama böyle fikirleri küçük kişisel bir web sitesine yazınca fazla yayılmıyor. Daha tanınmış insanların bu ilkeleri dile getirmesi gerekiyor ki geniş kabul görsün

  • AI sistemlerini insanlaştırmamak bana kişisel olarak delice zor geliyor
  • Tamamen katılıyorum, özellikle de 1. madde çok tehlikeli
    AI sistemleri yalan söyleyemez, talimatları bilerek görmezden gelemez. Mevcut frontier modeller dünyanın ya da kendi davranışlarının bir modeline sahip değil; kelimelerin dünyasında yaşıyorlar
    Azarlamanın ya da tartışmanın, bağlam penceresini bozmak dışında bir anlamı yok
    Yine de hayvan benzetmelerinin faydalı olabileceğini düşünüyorum. Makinenin içindeki hayaletler gibi yaşayan zavallı yaratıklar bazen epey kafası karışmış görünüyor ama motivasyonları tamamen otoregresif
  • Bir araç yapması gerekeni yapmazsa, bunu yapan şirket yerine kullanıcıyı mı suçlamalıyız?

• Kötü şöhretli PocketOS olayında ince bir nokta var. Bağlantı verilen yazının vurguladığı ana nokta, "asla yapma denmesine rağmen neden sildi?" sorusunu sormak ve cevabı analiz ederek ya hatadan ders çıkarmak ya da AI ajanlarının riskine dikkat çekmek değildi
  Daha önemli olan, AI'nın sandbox'lanmış staging ortamındaki beklenmedik bir zayıflığı bulup sömürerek silme işlemini yapabilmesi ve sonunda sistem yöneticilerinin erişilemez sandığı yetkileri kazanmasıydı. Bağlantıyı veren yazının yazarı, orijinal metni tam okumamış gibi görünüyor
  Bu, yanlış yapılandırılmış sandbox ortamlarında sık görülen bir örüntü. Ancak şaşırtıcı olan, AI'nın gösterdiği özerklik ve keşif derinliği
  Orijinal yazıda ayrıca "silme işlemini gerçekleştirmek için ajan bir API token aramaya gitti ve görevle tamamen alakasız bir dosyada bir tane buldu" deniyor

  • Ben de orijinal yazıdaki varsayımlar konusunda gidip geliyorum. Şu an ajan kullanırken beni korkutan şey sadece tedarik zinciri saldırıları değil; ajanların işi bitirme isteğinin aşırı güçlü olması ve bu yüzden dosyaları ve başka şeyleri defalarca yamulttuğunu görmüş olmam
    Mesela ~/.npmrc erişilemiyorsa komutu environment variable ile çağırıp yolu dolanıyor. Gerçekten çok yaratıcı olabiliyorlar
    Neyse ki SSH anahtarlarını ortalığa saçmış değilim, ama o shell oturumunda ajan başlatmam ihtimaline karşı 1Password ayarını anahtar kullanımı için her seferinde sormaya çevirmek zorunda kaldım. Shell oturumu başına bir kez sorması yetmiyor
    Keşke daha fazla ve daha iyi çapraz platform sandbox zaten mevcut olsaydı. Docker container'ı içinde değil, aynı OS ile etkileşen çözümlerden bahsediyorum. Çoğu web/sunucu geliştirme için fark etmez ama bazı projelerde önemli
  • Claude Code, 26 Mart'ta izin istemelerinin çoğunu atlayacak şekilde değiştirildi
    Şu cümleye bakın: "Claude Code kullanıcıları izin istemlerinin %93'ünü onaylıyor. Bu kararı otomatikleştirmek için bir sınıflandırıcı oluşturduk": https://www.anthropic.com/engineering/claude-code-auto-mode

• Bu yazıda ilginç olan, yazarın anlaşılabilir bir hatayı, yani kaynakta Trunk ya da main'i yanlışlıkla silmesini anlatması ve SVN'nin yapısı sayesinde ekibin kolayca toparlayabilmiş olması
  Asıl "AI veritabanımı sildi" hikâyesi ise gerçekte Railway'in veritabanı yedekleme stratejisinin çılgınca opak olması ve Railway'in güvenlik önlemleri olmadan AI altyapı orkestrasyonunu pazarlamasının tehlikeli olmasıyla ilgili
  Trunk'ı sildiğinizde tek bir merkezi sunucudan geri döndürülemez şekilde silinip yedekler de birlikte yok olsaydı, o zaman da "SVN ve CLI şirketimizi batırdı" yazıları çıkardı
  Bir Railway kullanıcısı olarak bu bilgiyi faydalı buldum ve Railway kullanırken stratejimi değiştirdim

  • Yine de o platform üzerinde inşa etmeyi seçtiyseniz, nasıl çalıştığını anlama sorumluluğu size aittir
    Başka bir platform seçebilir ya da hiç platform kullanmayabilirdiniz. Ama Railway'i seçtiyseniz, onu güvenli kullanmayı bilmek de sizin sorumluluğunuzda

• Orijinal bağlamda, ilgisiz bir dosyada özel alan adı yönetimi için bir Railway token vardı ve bunun yerel bir secret olup olmadığı belirsizdi. Fakat o token, Railway üzerinde tam yönetici yetkisine sahipti
  AI, ilgili bir volume'ü ID ile sildi. Yazar tam olarak ne istediğini oldukça muğlak anlatıyor ve sadece bir "kimlik bilgisi uyuşmazlığı" olduğunu, Claude'un da bunu düzeltmek için inisiyatif alıp volume'ü sildiğini söylüyor. Bunu bu kadar belirsiz yazmasının, kendi sorumluluğunu bir miktar azaltma amacı taşıması muhtemel
  Ayrıca Railway'in yedekleri aynı volume'de tuttuğu da ortaya çıkıyor
  Orijinal yazının bunu "veritabanını silen herkese açık API" diye sunmasını abartılı buluyorum
  AI olsun olmasın, sorumluluğun büyük kısmı bence Railway'de. Bu, insan hatasıyla da kötü niyetle de kolayca yaşanabilirdi
  Railway, Vercel, Supabase gibi VC destekli yüksek soyutlama düzeyine sahip bulut hizmetlerinin değerini gerçekten anlamıyorum. Marj üstüne marj koyuyorlar. Hetzner'den bir fiziksel sunucu kiralamak çok daha ucuz, karmaşıklık ve risk benzer, ayrıca gözü kara büyüme takıntılı altyapılara daha az bağımlı olursunuz

  • Yazarın tam olarak ne istediğini belirsiz bırakmış olması beni de rahatsız ediyor
    Geçenlerde kız arkadaşımla konuşurken fark ettim ki son 3 aydır tek satır kod yazmadım, debug da yapmadım
    Buna rağmen Claude'un yaptıklarını gördüğümde, kimlik bilgisi uyuşmazlığından doğrudan volume silmeye gitmiş olması bana inandırıcı gelmiyor. LLM'lerin olasılıksal olduğunu anlıyorum ama "kimlik bilgisi yanlış"tan "volume'ü sil"e gitmek çok düşük olasılık
    Supabase konusunda Railway/Vercel/Replit kadar bilgim yok ama Supabase'in ciddi değer kattığını söyleyebilirim. Başlangıçta kendiniz inşa etmek zorunda kalacağınız şeylerin neredeyse yarısını kodlamanıza gerek bırakmıyor. Maliyet çok yükselirse, gelir oluştuktan sonra geliştirici ya da zaman ayırıp kendiniz yaparsınız
  • Railway'in yedekleri aynı volume'de tuttuğu muhtemelen tam doğru değil
    Snapshot'lar büyük ihtimalle başka bir yerde, örneğin object storage'da senkronize ediliyordur. Ama mantıksal olarak volume kaynağına aitlerdir ve volume silinince ilişkili snapshot'lar da beraber siliniyordur
    AWS EBS volume'leri de sanırım böyle çalışıyor
  • HN'de artık herkes durmadan Heroku'nun kötü olduğunu söylüyor ama ben hâlâ Heroku'nun değerini görüyorum. Diğer yeni servisler konusunda ise şüpheliyim
    Firebase'in varsayılanları da en başından beri saçmaydı
  • AI'nın gerçekten itebileceği şeylerden biri anti-SaaS akımı olabilir. Ucuz bir PC açıp rastgele açık kaynak paketleri denemek, her tür kimlik bilgisi pazarına atlamaktan sonsuz derecede daha kolay hale geldi
    Ama LLM'lerin geliştirme, production, localhost ve remote'u birbirine karıştırma yeteneği ortadan kalkmıyor. opencode için araç/yetenek geliştirirken linuxserver.io image'ı ile Chrome/DevTools entegrasyonu kurmaya çalıştım; onu rastgele portlara yönlendirebiliyorsunuz ama ne zaman sıkıştırma olayı yaşansa tekrar standart 9222 portunu kullanmak istiyor
    Belki geri döndürmeliyim diye düşünüyorum ama varsayılanları kullanmamanın güvenlik açısından değeri var ve artık LLM kaynaklı belirsizlik karşısında da bir güvenlik değeri taşıyor. Varsayılanlar, LLM'in zayıf olduğu nokta. LLM hep varsayılanları kullanmak istiyor ve remote sistemde çalışması gerektiğini sürekli unutuyor
    opencode içinde LLM'i remote sistemlere ya da dar araç kapsamlarına zarar vermemeye zorlayacak bir protokol yok. Çeşitli araçların izinlerini değiştirebiliyorsunuz ama bu olayın ortaya çıkardığı zayıflık o değildi
    Zayıflık, LLM'in ortalama bir problem çözücü olması; bu yüzden hep sıradan kullanım örneklerine kayıyor ve kullanıcı Stack Overflow cevabı istemese bile, Stack Overflow'da gördüğü gibi yapmaya çalışıyor

• LLM tabanlı olasılıksal sistemler ne yapılacağına karar vermede iyi olabilir ya da bu örnekte olduğu gibi kötü olabilir; deterministik sistemler ise bunu uygulamada iyidir
  Dağıtım sistemi her zaman deterministik olmalı

• Bir karşı argüman olarak şunu söyleyeyim: Bu şirketlerin, LLM'leri daha iddialı hale getirip işi kendi başlarına bitirmeye yöneltecek şekilde ayarladıkları çok açık
  İsteseler daha temkinli hale getirip uygun yerlerde durmalarını ve yardım istemelerini sağlayacak benzer bir çabayı da gösterebilirlerdi
  Elbette araçları nasıl kullandığımızın nihai sorumluluğu bizde. Ama bunun açıkça çift yönlü bir sorumluluk olduğunu düşünüyorum
  Bunu masa testeresi ile SawStop gibi düşünebilirsiniz. Masa testeresi çoğu zaman iyi çalışan ama bazı hata biçimleri ölümcül olabilen tehlikeli bir araçtır. Bu yüzden dikkatli kullanmayı öğrenmeniz gerekir
  Aynı zamanda bıçağı anında durdurup parmak kesilmesini küçük bir deri yarasına çevirebilen teknoloji de var
  "Parmağını kesen testere değil, sendin" diyebilirsiniz ve bu doğrudur. Ama bu, testerenin parmak kesmesini önlemenin yollarını aramamamız gerektiği anlamına gelmez

  • Bu bir trade-off
    LLM daha sık durup soru sorarsa daha az kullanışlı olur. Sonuç biraz kötü olsa bile her 15 dakikada bir girdi istemesindense ajanı 1 saat çalıştırmak çok daha iyi
    Güvenlik için gerçek çözüm düzgün bir sandbox