MCP, dağıtık sistemlerde 40 yılda edinilen önemli dersleri göz ardı ediyor
(julsimon.medium.com)- MCP (Model Context Protocol) AI araç entegrasyonunu standartlaştırmayı savunuyor, ancak 40 yıldır birikmiş dağıtık sistemler ve RPC en iyi uygulamalarını görmezden geldiği bir sorunu var
- Bu nedenle kurumsal ortamlarda operasyonel güvenilirlik, tip güvenliği, güvenlik, gözlemlenebilirlik, maliyet yönetimi gibi kritik işlevler eksik kalıyor
- MCP yalnızca temel yetenekleri harici kütüphanelere bağımlı kılmakla kalmıyor, ayrıca protokol parçalanması, entegrasyon karmaşıklığı ve denetim-b güvenlik yönetimi yükünü de getiriyor
- Dağıtık izleme, şema sürüm yönetimi, servis keşfi, performans optimizasyonu gibi temel operasyonel gereksinimler hala yetersiz
- MCP'nin erken benimsenmesi, AI patlamasından beslenerek kurumsal ortamlarda ciddi arıza, operasyonel risk, tekrar eden geliştirme, gereksiz maliyet oluşmasına yol açma riski taşıyor
MCP'nin Sadelikten Doğurduğu Tehlike
MCP (Model Context Protocol), AI araçları arasındaki entegrasyonu 'AI alanının USB-C'si olarak konumlandırıyor ve benimseme eşiğini düşüren sadeliği vurguluyor. Fakat bu sadelik, tam tersine dağıtık sistemlerde 40 yıldır biriken dersleri görmezden gelmesi nedeniyle gerçek operasyon ortamlarında kritik işlev eksiklikleri yaratıyor. MCP'yi şu an benimseyen şirketler, temelde gerekli RPC sistem işlevleri eksik bir temelde sistem inşa etmiş oluyor.
Gerçeklik ve Beklenti Arasındaki Tehlikeli Uçurum
MCP savunucuları bu protokolü production-ready altyapı olarak tanıtıyor; ancak gerçek tasarım felsefesi geliştirme kolaylığına kaymış ve operasyonel sağlamlıkta yetersiz kalmış durumda. Kısa vadede AI araçlarını bağlamak mümkün olsa da, milyonlarca istek ölçeğinde gerçek iş süreçlerinde kullanılınca ölümcül eksiklikler ortaya çıkıyor. AI'ya yönelik aşırı piyasa beklentisi nedeniyle mimari olgunluk beklenmeden benimseme hızlandırılıyor ve bu da nihayetinde operasyonel başarısızlığa neden olma olasılığını büyütüyor.
40 Yıllık Tarihten Tekrarlanan Hatalar
-
UNIX RPC (1982), farklı sistemler arasında 32-bit tamsayı gibi veri uyumluluğu için XDR (External Data Representation) ve IDL (Interface Definition Language) getirmiş, derleme zamanında tip tutarsızlığı hatalarını yakalamıştı
MCP bu deneyimi görmezden gelip şema içermeyen JSON ve zorunlu olmayan ipuçları sunuyor. Bu nedenle tip hataları çalışma zamanında ortaya çıkıyor; AI yanlış tarih ürettiğinde finans, sağlık, imalat gibi gerçek iş ortamlarında kritik veri dönüştürme hatalarına ve kalite sorunlarına yol açabiliyor -
CORBA (1991), birden fazla dil arasında aynı arayüzü garantilemek için OMG IDL kullanmıştı. MCP'de ise her dilin ayrı ayrı uygulanması, seri hale getirme yöntemi ve hata işlemede dil ile kütüphaneler arasında tutarsızlığa neden olarak entegrasyon kabusu yaratıyor
-
REST (2000), durumdan bağımsız mimari, fiil (verb) temelli anlam netleştirme, önbellek başlıkları ile geniş ölçekte ölçeklenebilirlik ve güvenilirlik kazandı
MCP'de stateful/stateless ayrımı belirsiz; önbellek, standart istek-anlam ayrımı ve idempotency desteği yok. Sunucu ölçeklendirme, yeniden deneme ve yük dengeleme son derece zorlaşır -
SOAP/WSDL güçlü makine tarafından okunabilir sözleşme, otomasyon potansiyeli, güvenlik genişletilebilirliği sunuyordu
MCP yalnızca temel JSON şeması sağlıyor; makine tarafından okunabilir sözleşme, otomatik üretim, tip güvenliği, güvenlik denetimi gibi işlevler yok. OAuth 2.1 de geç de olsa sadece HTTP iletimi için eklenmiş, stdio ise ortam değişkenlerine bağımlı olması nedeniyle güvenlik kontrolleri eksik -
gRPC (2016) gözlemlenebilirlik, dağıtık izleme, çift yönlü akış, deadline, yapılandırılmış hata kodları sunuyordu
MCP yalnızca event tabanlı tek yönlü akış destekliyor ve karmaşık etkileşimleri uygulamakta verimsiz kalıyor. İzleme bağlamı, deadline ve hata sınıflandırması gibi kritik unsurlar eksik
"Sadece bu kütüphaneyi kullanın" Riski
MCP, her kritik kusur iddiasında üçüncü taraf bir kütüphane eklemeyi (ör. mcp-oauth-wrapper, mcp-tracing-extension, mcp-schema-generator) yanıt olarak veriyor. Ancak bu, protokolün özüdeki başarısızlık noktası. Temel işlevler ne kadar dışarıda dağıtılırsa, parçalanma, tutarsızlık, bakım/güvenlik/entegrasyon sorumluluğunun bölünmesi sorunları derinleşir.
Kurumsal ortamlarda aylar içinde standartlaştırma, denetim ve entegrasyon yükü büyür; geliştirici eğitimi ve dış bağımlılık da anormal derecede artar.
Giderek Eklenen Geçici Yama Çözümleri
MCP'nin 2025–03–26 sürümü, üretim ortamında geç fark edilen kusurları sonradan eklenen geçici yamalarla kapatmaya benzeyen bir yama notu gibi. OAuth, oturum yönetimi, araç özelliği (annotation), ilerleme durumu bildirimi gibi maddeler, en başından itibaren zorunlu olması gereken özelliklerin sonradan eklenmesi kadar bir şey değil. Aracın özellik ayrımları da ilk aşamada yoktu; güvenlik kimlik doğrulaması da başlangıçta gereksiz görülmüştü. Bu, kurumsal gereksinimlerin özünü anlamadığını kanıtlar.
Hata Ayıklama Kabusu ve Operasyonel İzlenebilirlik
gRPC ortamında dağıtık izleme ve trace ID ile hızlı ve tutarlı hata ayıklaması ve izleme yapılabilir
MCP'de ise istekler arası ilişki ID'si yokluğu, günlük (log) biçimi tutarsızlığı ve özelleştirilmiş uygulama zorunluluğu nedeniyle hata ayıklama ve hata takibinde günlerce zaman geçebilir
Operasyon ve iş açısından da maliyet dağılımı ve kullanım yönetimi (başlıklar, token sayımı, kota vb.) yapılamıyor.
Bulut ortamında temel yetenekler MCP'de hiç sunulmadığı için AI kullanım maliyeti ve sorumluluk izi takibi neredeyse olanaksız hale geliyor
Hâlâ Bulunan Başlıca Operasyonel Sorunlar
- Servis keşfinin olmamasıyla kullanılabilirlik, çoklu bölge genişletme ve kesintisiz güncelleme yapılamıyor
- Araç bazında şema sürüm yönetiminin olmaması nedeniyle, bir aracın güncellenmesi tüm istemcilerin ani şekilde bozulmasına yol açabilir
- Performans sınırlamaları: JSON fazlalığı, bağlantı havuzu eksikliği, ikili protokol ve sıkıştırmada yetersizlik, süreç bazlı iletişim modeli vb. eski kalıpların tekrarı
Kurumsal Uygulamada Ciddi Tehlike
AI'nin artık gerçek gelir, güvenlik ve kalite sorumluluk alanlarına (finans, sağlık, imalat, müşteri destek vb.) girmesiyle MCP benimsemenin riski büyüyor
Uzun yıllar boyunca inşa edilmiş sağlam entegrasyon kalıpları yerine, güvenlik, denetim, tip güvenliği, operasyonel stabilite sonradan uygulanarak geçici olarak tamamlanmış oluyor
Prototip düzeyindeki "hızlı kurup bozma" stratejisi, kritik hizmetlerde yıkıcı sonuçlar doğurabiliyor
İyileştirme Yönü ve Uzun Vadeli Gereksinimler
- Kısa vadede: Protokol içinde gömülü tip güvenliği, dağıtık izleme (ilişki kimliği), yetkilendirme, standart denetim formatı, araç bazlı bağımsız şema sürüm yönetimi zorunlu
- Operasyonel olarak: Servis keşfi, bağlantı havuzu, ikili transfer, deadline, standardize hata ve yeniden deneme politikaları gerek
- Uzun vadede: Çift yönlü akış, gömülü kota ve maliyet yönetimi, SLA enforcement, iş akışı orkestrasyonu gibi kurumsal düzeydeki özellikler gerek
Sonuç
MCP'nin sadelik odaklı tasarımı, deneysel ve kısa çevrim süresi olan AI araç entegrasyonlarına uygun olabilir; ancak kurumsal operasyonel ortamlarda ölümcül operasyonel risk ve maliyet artışına yol açar
AI patlamasına kapılıp geç benimseme yapıldığı için, güvenlik, gözlemlenebilirlik, operasyonel stabilite gibi zorunlu işlevler sonradan eklenecek geçici yamalarla telafi edilmeye çalışılıyor
Sonuçta, bu protokolün önlemeyi hedeflediği parçalanma ve tekrar eden geliştirme MCP üzerinde yeniden ortaya çıkma riski var
AI sektörü, 40 yıllık dağıtık sistem gelişimini yok sayıp sorunları tekrar mı yaşayacağı yoksa tarihten ders çıkarıp mı ilerleyeceği noktasında duruyor
Bu şekilde ilerlerse başarısız benimseme, güvenlik açığı, operasyon kabusu tekrar eder ve maliyetin tamamı kurumsal müşteriler tarafından taşınır
1 yorum
Hacker News yorumu
Başta sadece başlığa bakınca tipik bir güvenlik şovu olacak diye düşündüm, ama okuyunca gerçekten içgörülü olduğunu fark ettim. Özellikle dikkatimi çeken şu noktaydı: MCP, bu dersleri görmezden gelip şema olmayan JSON'da zorunlu olmayan ipuçları kullanıyor, tip doğrulama ya çalışma zamanında yapılıyor ya da hiç yapılmıyor. Örneğin, bir AI aracı ISO-8601 zaman damgası beklerken Unix epoch değeri alırsa model doğru şekilde hata fırlatmak yerine rastgele bir tarih üretebilir. Bu durum finans hizmetlerinde işlemler için AI'nin sayıları yanlış yorumlayıp yanlış ondalık hassasiyetle işlem çalıştırmasına, sağlıkta hasta veri tipinin yanlış dönüştürülmesiyle yanlış ilaç dozunun önerilmesine yol açabilir. Üretimde sensör verisi JSON serileştirmede hassasiyet kaybına uğrayıp kalite kontrol sorunlarına dönüşebilir. LLM ile her gün çalışan biri olarak bu tür sorunlar gerçekten sıkça görüyorum. İleride MCP içeren bir sistemin bir yerinde büyük bir olay yaşanacağını hayal edebiliyorum; olay raporlarında MCP sunucusunun garip veri verdiği, bunun LLM tarafından alınarak alakasız bir halüsinasyon çıktısı üretildiği ve bunun ardışık şekilde daha büyük sorunlara dönüştüğü bir senaryo net görünüyor. İnsan hatası, istisna işleme yeteneği olmayan LLM doğası (halüsinasyon üretimi) ve startup'ların aceleyle yeni servisleri yayına alma kültürü birleşince yeni bir hata türü kaçınılmaz. Bu sorun patlak verince, Twitter kullanıcılarının AGI'nin nükleer fırlatma kodunu hacklediğine saatlerce bağırmasını seyretmek de ilginç olurdu
Açık söyleyeyim, 2023 öncesinde Star Trek'te gördüğümüz teknik bug ve arıza anlatıları o kadar kurguya benziyordu ki böyle bir şeyin gerçekten olacağını düşünmezdim. Ama LLM'lerden sonra bunun gerçekten gerçekleşeceğine dair güçlü bir sezim var. LLM entegrasyonunun artık mühendislikle ne kadar ilişkisi kaldığını anlamıyorum ve şirketin tüm altyapısını dışarıdan kontrol edilmesine bırakmanın çok rasyonel olup olmadığını sorguluyorum. Üstüne tekrarlanabilirlik eksikliği de eklendiğinde, “bir şekilde olur” denecek bir şeyin mühendislik olarak adlandırılamayacağı ortaya çıkıyor
Yazarın getirdiği eleştiriyi anlamakta zorlandım. MCP, JSON Schema destekliyor; sunucu yanıtlarının bu şemaya uyması gerekiyor. Eğer ISO-8601 zaman damgası isteyen bir şema varsa ve sunucu Unix epoch gönderiyorsa bu açık bir protokol ihlalidir. Yazıda MCP'nin JSON Schema desteklemesine rağmen type-safe istemci üretilmeyeceği iddia edilmiş; oysa zaten çok sayıda JSON Schema kod jeneratörü mevcut, bu gerçeklerle uyuşmuyor
PEBKAC zaten (kullanıcı kaynaklı hata) vardı; LLM bunu otomatikleştiriyor
Tıp alanında yanlış veri tipi dönüşümüyle ilaç dozunun hatalı önerilebileceği uyarısına gelince; ben tıbbi telemetriyle uğraşırken zaman damgasını doğru parse etmenin ne kadar kritik olduğunu çok iyi anladım. Birim testlerini ilk kez yazmamın nedeni muhtemelen bu nedenleydi. NTP yokken bile başlıkların zaman damgasını yeniden hesaplayıp düzeltmiştim. Bunların nedeni hata incelemeleri ve tıbbi sorumluluk tartışmalarıydı. Örneğin, bir hastaya kalp durması öncesinde verilen ilacın zamanı ile daha sonra verilen zaman arasındaki fark hayati olabilir. Son dönemlerdeki Royal Mail örneğinde olduğu gibi tek bir veri hatası bir hayatı mahvedebilir; tıbbi veride bir dakikalık fark dünyanın değişmesine yol açabilir
MCP'nin amacı iletim ve bağlam yönetimidir. Yani şema tanımlama ve doğrulama gibi makul arayüz uygulama sorumluluğu kullanıcıdadır. Bu, “HTTP json doğrulama desteklemiyor” eleştirisine benzer; doğal bir durumdur
MCP'nin “AI dünyasının USB-C'si” olmayı vaat ediyor ama ironik biçimde bu daha çok MCP başarısından değil USB-C'nin doğasıyla ilgili bir gösterme. USB-C çoğu şeyi bağlasa da, standart uyumu berbat olduğu için MCP'nin tutarsız JSON ayrıştırma veya protokol uyumsuzluğu gibi örnekleriyle çok benzer. Yüzeyde farklı USB-C kablolarının varlığı gibi, dışarıdan evrensel görünmesine rağmen arka planda çok karmaşık bir gerçek gizleniyor. Bence daha net ayrılmış API’ler/protokoller daha iyi
USB-C'nin felaket derecede ters örneği, Apple'ın en yeni M4 Mac mini'da USB-A portunu tamamen kaldırmasıyla başladı. Görünümü aynı iki port gerçekte bambaşka performans veriyor ve kullanıcı bunu ürün lansmanından sonra ancak fark ediyor. Eskiden Apple Silicon masaüstü/laptop'lardaki USB-C'lerin hepsinin 40Gbps Thunderbolt olacağını düşünebilirdin; şimdi bazılarının sadece USB3 10Gbps olduğunu gördük. Hangi portun ne olduğunu anlamak için spesifikasyon dokümanına bakıp küçük bir ikon okuyabilmek gerekiyor. Şayet Apple birkaç USB-A bırakmış olsaydı 10Gbps sınırı daha net belli olurdu; buna rağmen USB-C markası daha da sulandırıldı. Sonuçta çoğu USB-C cihaz bile hâlâ adaptörle USB-A'ya bağlanıyor; USB-C versiyonları pahalı ve daha az yaygın olmalarının yanı sıra kalite olarak da iyi değiller. Ama hype ve fandom pratiklikle kullanılabilirliğin üstüne geçtiği bir dünyada yaşıyoruz
O “USB-C = evrensel ama şeffaf olmayan şey” çizgisini görünce gerçekten çok güldüm. Hedefe ulaşıldı sayılır
SOAP için “çok uzundu ama MCP'nin bilmediği şeyi biliyor” gibi bir yorum var, ama gerçek şu ki SOAP da pek anlaşılmış değildi. Gerçek hayatta SOAP'a dair iyi bir şey söyleyebilecek değilim; kendisi kalıbın modeli olamayacak bir yapı. Ben bakımını yaptığım legacy SOAP sistemlerinde SOAP hakkında iyi bir şey söyleyemem. Rol model olabilecek bir şey görmüyorum
SOAP gerçekten tam bir facia oldu. Basit olması gereken şeyi nasıl bu kadar karmaşıklaştırdığını düşünmek zor. XML zaten karmaşıktı; bir de WSDL ve çoklu HTTP parça sınırları, belirsiz tanımlamalar, farklı diller arasında çalışabilirlik garantisi olmaması (ör. .NET sunucusu ile Java istemcisi deneyimleri) eklendi. Modası geçince herkes iyi tarafını hatırlıyor gibi görünür ama ben bir ay SOAP kullanmaktansa 50 yıl şema olmayan JSON API'lerle uğraşmayı seçerdim. Kişisel olarak protobuf ve capnp çok daha iyi diyorum
REST (aslında JSON-RPC) ve GraphQL'ın hala SOAP ile SOA'nın sağladığı özellikleri yakalamaya çalıştığını düşünüyorum. Yeni bir teknoloji geldiğinde iyi yanları bile beraberinde atmak zorunda kalmak çok üzücü
İsmi içinde “Simple” geçen herhangi bir protokol asla basit olmamıştır; yakında “SMCP” benzeri protokolleri de görürüz gibi
SOAP için hem eğlenceli hem de doğru bir açıklama linki paylaşıyorum https://harmful.cat-v.org/software/xml/soap/simple. Ben XML tabanlı teknolojileri sevmeye meyilliyim; özellikle XML Schema'nın tip kombinasyonu ve doğrulama kabiliyeti bugün bile eşsiz. Fakat SOAP böyle gereksiz bir canavara dönmüş gibi hissediyorum. Basit bir uzak çağrı spesifikasyonu istenirken, her şeyi tanımlayıp aslında hiçbir şeyi doğru şekilde ele almayan bir standart oldu. SOAP, çoklu iletim protokollerini destekliyor (SOAP over email dahil), çeşitli RPC türleri, UDDI ve daha pek çok “self-RPC” yaklaşımı iddia ediyor; ancak gerçekte kimlik doğrulama, cacheleme, HTTP durum kodları gibi temel implementasyonlar yine kullanıcıya kalıyordu
İlginçtir ki SOAP'u sonsuza kadar reddetmemin nedeni o dönemde dinlediğim SOAP teknik sunumuydu. Aynı dil içinde kabaca çalışsa da, diller arası kullanımda en kötü haline geliyor. Microsoft'un SOAP'u bu kadar sevmesinin sebebi de bunu düşünüyorum
CORBA, 1991'de “heterojen ortamlarda her dil için sadece bir protokol yazmak yetmez” içgörüsünü alarak doğmuştu ve OMG IDL, çoklu dille aynı bağlamayı üreterek arayüz tutarlılığı ve serileştirme sorunlarını önlemesi açısından doğruydu. Ancak gerçekten başarılı bir örnek olup olmadığı soru işareti taşıyor
Bugünkü JSON odaklı API dünyası CORBA ve SOAP'un başarısızlıklarına bir tepki olarak doğmuş görünüyor. CORBA dersini unuttuk derken değil, bilinçli olarak geri çevirmişiz gibi
CORBA'yı çok iyi kullandığımız bir yerde çalışmışlığım var. Başarıyı sanırım ekibimizde CORBA deneyimi yüksek kıdemli bir mühendis olduğundan aldık
1998'de CORBA kullanan bir AT&T işine başvurmuşum, o son CORBA deneyimim olmuştu (ondan sonraki dönemde JDK indirme hızını yavaşlatmanın dışında görmedim). O zaman görüşmeci, yazdığım eşzamanlılık kodunu beğenmediğini ve alternatifimde race condition olduğunu söylediğini ama bunu ikna edemediğini anlattı. Daha sonra Java Memory Model nedeniyle benim cevabımın doğru olduğu anlaşıldı
CORBA birçok şeyi iyi yaptı ama 80'lerin sonundaki klasik telekom ağları ve OOP dalgasının bir ürünüydü. Bu yüzden ağın şeffaf, güvenilir ve simetrik olduğu temel varsayımını yerleştirdi; gerçek hayatta ise timeout'lar, yeniden denemeler, ağ tıkanıklıkları ve sistem çöküşleri ile tam tersi. Özellikle CORBA C++ bağlayıcısı STL'nin gelmeden önce olduğu dönemde korkunçtu; diğer dillerdeki taraflar bazen daha iyi sonuç veriyordu
Teknik olarak ne kadar iyi olursa olsun, ticari olarak başarısız olmuş projelerde bile katkılarını hak ettiği gibi takdir edebilirim
MCP tartışmasında atlanan şey, “MCP'nin gerçekten öğrendiği temel dersin” aslında tüm gelişmiş özelliklerin karmaşıklık getirmesi, bu yüzden sahadaki çoğu durumda basit tercihe dönülmesi olduğudur. Bu yüzden JSON-over-HTTP'nin ana akım olması bunu açıklar. Büyük şirketlerde dahi gRPC gibi yüksek fonksiyonlu bir serileştirme protokolüne geçişin yıllar alması ve arada birçok başarısız deneme yaşanması mümkündür. MCP'nin gerçek rolü, basit JSON API sözleşmesini standartlaştırarak LLM için token ya da araç çağrı stili üretimini kolaylaştırmaktır
MCP mükemmel olmamakla birlikte, yıllarca süren RPC tarihinden tek öğrenilen şey karmaşıklığın entegrasyonu ve kullanımını en zor hale getirmesi dersini doğru almış durumda (XML'in yerini JSON'un almasıyla benzer). SOAP sistemler arası uyumluluk için aşırı karmaşık ve XML ile şema tarafı da çok uzun uzadı. CORBA'nın kütüphane ve çatıları karmaşık olduğundan o zamanın yeni dillerinde tiksinilen bir şeydi. gRPC hızlı ama okunabilirliği daha düşük ve eşleme gerektiriyor. Bugünün RPC omurgası REST ve JSON. Yukarıdaki standartlar ya geri planda kaldı ya da gRPC sadece ekstrem yüksek performans gerektiren alanlarda kaldı. REST ve JSON'un ana akım olması, bu basitliğin galibiyeti; MCP de bu çizgide tasarlanmış bir ürün
Çok iyi yorumlar var. MCP'yi yanlış anlıyoruz gibi duruyor. Asıl kritik olan, genel endüstride ajan nedir ve gelecekte nereye gidecek konusunda yanlış anlaşılma ve yön uyuşmazlığı. Birçok web platformu ajanların ağ dağıtık altyapıya gömülü olacağına inanıyor; tüm konteyner içi ajanları servis ağına MCP ile bağlı hale getirmeyi hedefliyor. Benim görüşüme göre, bu “web-native ajan ve SDK/framework'lerin sunucu uygulaması gibi dağıtılması gerekir” yaklaşımı yanlış; çünkü bunlar ajan değil ve evrimsel olarak henüz başlangıç bile değiller. Gerçek ajan harness'ler Frontier labs gibi az sayıda sağlayıcı tarafından yapılabiliyor ve giderek kişiselleşmeye gidecek (ör. masaüstümdeki Claude Desktop için tek bir MCP sunucusu). MCP sunucuları aslında bu tekil örnek ve harness senaryosu için tasarlandı
Umarım biri MCP'nin Swagger veya proto yerine neden gerekli olduğuna açık biçimde açıklayabilir
OpenAPI (Swagger) ve Proto (protobuf) her biri MCP'nin kapsamını tamamen karşılamıyor. Teorik olarak bu araçların üzerine MCP eklemek mümkündü, ancak MCP'nin yerel kullanım örneklerinde OpenAPI'nin iletim varsayımları uyuşmuyor; protobuf zaten iletişim protokolünü içermez, bu yüzden ekstra tasarım gerekir. JSON-RPC'yi tamamen ikame etseniz bile en sonunda MCP spesifikasyonunu neredeyse tamamen korumak zorunda kalırsınız, bu da işi daha karmaşık yapar
MCP yeni bir teknoloji
MCP akış yanıtını destekliyor. Polling veya oturum durumuyla yapılabilir ama bu verimsiz bir geçici çözümdür
OpenAI geçen ay API kullanımı nedeniyle 50.000 $'lık bir fatura kesildiğinde, bunu hangi MCP aracının tetiklediğini, hangi tek bir araç çağrısı ya da kullanıcı/senaryo olduğunu ayırt etmek mümkün olmayabiliyor. AI ekosisteminin çoğu, sorunları geri planda takip eden bir konumda. Ama web framework'leri, blockchain vb. gibi, teknoloji büyüdükçe başlangıçta hiçbir şey tam olarak bilinmez. Zaman içinde bu açık kapanır. AI'da da fikir ve farkındalık paylaşmaya devam etmek gerektiği konusunda hemfikirim. Bu gerçekten heyecanlı bir dönem
Daha iyi tasarım ile “yeterince iyi” tasarım arasında seçim yapınca her zaman “yeterince iyi” kazandığını düşünüyorum. Multics ile Unix, XML tabanlı SOAP ile JSON tabanlı REST, XHTML'in çöküşü, JavaScript'in kendisi… sayısız örnek verilebilir. Bu yüzden insan sürekli “daha iyi”yi yeniden inşa eder, sorunlar ortaya çıktığında ise geçici yamalarla idare eder duruma mahkûm olduğunu düşünüyorum
Bu, bilinen Worse is Better fenomeninin bir başka doğrulaması (https://en.m.wikipedia.org/wiki/Worse_is_better). Zaman geçse de defalarca doğrulandı. Ben de her zaman “daha iyi” çözümlere çekilirim ama gerçek bazen böyle değil
xforms 2.0 için bir dakikalık susma gerekecek. Yaşayabileceğimiz bir dünya: gerçekten çalışan web form validasyonu, microdata...