Chatbot Değil, Sistem Tasarlamak

Günümüzde biz yazılımcılar arasında; özellikle yapay zekâya ilgi duyan, bu alanda geliştirme yapan sektör emektarları, yapay zekâ konusunda heyecanlı şirketlerimiz ve bu şirketlerdeki ürün sorumlularımız tarafından sıkça düşülen tuzaklar var.

Bunlardan ilki, genelde tercih edilen ilk yöntem: genel bir yapay zekâ modelini (OpenAI, Vertex AI vb.) API üzerinden kullanıp basit ya da detaylı prompt'larla bir chatbot geliştirmek, sonra da "bakın, biz de yapay zekâ kullanıyoruz, ürünümüze yapay zekâ entegre ettik" deyip bunu ürün pazarlamasında sonuna kadar kullanmak.

İkinci tuzak ise (tam olarak tuzak diye adlandırıp adlandırmamakta başta kararsız kaldım) bir RAG sistemi, yani bir doküman ya da doküman tabanıyla kısıtlanmış bir sistem inşa etmek. Bu da aslında tüm sorunumuzu çözmüyor; özellikle regülasyona tabi sağlık ve hukuk sistemlerinde. Buradaki kritik konu, LLM'lerin "halüsinasyon" denen şeyi yapması: olmayan bir cevap karşısında "bilmiyorum" demek yerine kaynaksız bir şekilde uydurması.

Regüle veya karar etkisi yüksek production sistemlerde, modelin kaynaksız verdiği her cevap potansiyel bir bug ve risk kaynağıdır.

Bölüm 1Gerçek dünya örnekleri#

Bu hatalardan size üç örnek vermek gerekirse:

1. Prompt injection: sistem prompt'u güvenlik değildir#

2023'te sosyal medyada viral olan bir olayda, bir yazılım mühendisi (Chris Bakke) bir otomotiv bayisinin chatbot'una "zararsız gibi görünen" ama aslında sistem davranışını manipüle eden bir prompt enjekte etti.

Bot, verilen talimatlarla "müşteriye ne söylerse yasal olarak bağlayıcıdır" gibi saçma bir çerçeveye çekildiğinde, modelin bu yönergeleri takip etmeye eğilimli olduğu görüldü. Sonuç olarak bot, gerçek olmayan bir satış teklifini kabul eder gibi davranabildi. (Satın alma chatbot'ları çok sık olmasa da rezervasyon gibi pek çok alanda kullanılıyor.)

Prompt injection nedir? Bkz. Palo Alto Networks: What is a prompt injection attack?

Yani LLM ile konuşan kişi, modeli prompt ile hackleyerek istediği gibi davranmasını sağladı. Bu durum sadece bir internet fenomeni olarak da kalmadı; güvenlik tarafında standartlaştırıldı: OWASP Top 10 for LLM Applications (LLM01: Prompt Injection). OWASP, prompt injection'ı LLM güvenlik açıklarının en üst sırasına koyarak bu problemin "tasarım düzeyinde" olduğunu resmî olarak tanımladı.

2. Halüsinasyon: hukukta "yanlış ama ikna edici gerçek"#

2023'te ABD'de yaşanan Mata v. Avianca davası, LLM kullanımının hukuk sisteminde nasıl kırıldığını gösterdi. Bir avukat, ChatGPT kullanarak daha önce var olmayan dava kararlarını içeren hukuki referanslar üretip mahkemeye sundu. Sonuç:

• Uydurma kararlar
• Gerçekte var olmayan içtihatlar
• Tamamen ikna edici ama yanlış bir referans zinciri

Mahkeme bu durumu açıkça yaptırımla sonuçlandırdı. Bu olay artık klasik bir referans noktası: model "doğru gibi görünen ama yanlış" bilgi üretmişti ve bu çıktı doğrudan hukuk sistemine girmişti. (Günümüzün en büyük sorunlarından biri yanlış AI kullanımı: yapay zekânın her dediğini doğru kabul etmek.)

Kaynak: Mata v. Avianca, Inc., U.S. District Court (S.D.N.Y., 2023 yaptırım kararı)

3. "Halüsinasyon yok" dese bile yapay zekâya körü körüne inanmamak gerekir#

2024'te Stanford RegLab'in yaptığı bir çalışma, hukuk alanında çalışan yapay zekâ ürünlerinde halüsinasyon tespit etti. Burada kritik bir nokta var: incelenen şirketler "halüsinasyonu hallettik, bizde halüsinasyon yok" diyordu.

Çalışma, Lexis+ AI (LexisNexis) ve Westlaw AI-Assisted Research (Thomson Reuters) sistemlerini inceledi. Sonuç netti: hukuki sorgularda anlamlı seviyede halüsinasyon üretimi gözlemlendi. Oranlar sistemden sisteme değişmekle birlikte çift haneli seviyelerdeydi (yaklaşık %17–33 aralığı raporlandı).

Bu vakaların ortak hastalığı şu: model konuşurken iki şeyi ayırt etmiyor; neyi biliyor, neyi uyduruyor. Ayırt etmesi için zorlanması lazım. Ve bu zorlama prompt'ta değil, sistem mimarisinde olmalı.

Kaynak: Stanford RegLab — Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools (2024)

Bölüm 2Sistem tasarımına başlarken#

Sistem tasarımına başlamadan önce, tasarlayacağımız sistem için doğru kelimeleri seçmek çok önemli; çünkü kelimeler mimariyi belirler.

"Chatbot" dediğimiz şey son birkaç yılda o kadar geniş bir anlama kaydı ki neredeyse içi boşaldı. Herkes "AI asistan" diyor ama çoğu zaman aynı şeyden bahsetmiyoruz. Pratikte üç farklı yaklaşım var ve bunları ayırmadan yapılan her tartışma havada kalıyor.

Birincisi, otonom chatbot. En basit hâliyle: kullanıcı yazıyor, model cevaplıyor, arada kimse yok. Sistem kendi başına karar veriyor ve sonucu doğrudan kullanıcıya iletiyor. Kulağa verimli geliyor ama riskin tamamını da üstleniyorsunuz. Bunun gerçek hayatta nasıl patladığını gördük: Air Canada örneğinde olduğu gibi, ya da The Markup'ın ortaya çıkardığı MyCity bot vakasında olduğu gibi. Sistem yanlış hukuki bilgi veriyor ve bu bilgi doğrudan kullanıcı davranışını etkiliyor. Sonuç: tazminat kararları, kapatma baskısı, itibar kaybı ve hukuki risk.

İkinci model daha "kurumsal" görünüyor: kapalı devre otomasyon (agent sistemler). Kullanıcı bir şey talep ediyor; sistem arka planda işlemleri yapıyor, form dolduruyor, API çağırıyor, randevu açıyor ve size sadece sonucu gösteriyor. Sürecin kendisi görünmez. İlk bakışta daha kontrollü gibi ama aslında şeffaflık yok. Hız artıyor, maliyet düşüyor… ama bir süre sonra kalite geriliyor ve insanlar tekrar devreye alınmak zorunda kalıyor. Yani problem çözülmüyor, sadece erteleniyor.

Üçüncü model ise bence asıl konuşulması gereken: agent-assist. Burada yapay zekâ karar vermez, destek olur. Operatöre öneri sunar, kaynak getirir, taslak hazırlar. Ama son söz her zaman insandadır. Kritik fark bu. Mesela Nuance'ın DAX Copilot ürününde doktor konuşurken notları yapay zekâ çıkarıyor, ama doktor okumadan ve imzalamadan hiçbir şey resmîleşmiyor. Sistem hız kazandırıyor ama sorumluluğu devralmıyor. Mimari olarak bilinçli bir sınır çiziliyor. (kaynak)

Zaten bu yazının temel iddiası da burada başlıyor: Regüle sektörlerde, kullanıcıyı bağlayan bilgi veren veya işlem başlatan otonom chatbot'lar ciddi bir mühendislik ve yönetişim riski taşır.

Doğru yaklaşım ise net: agent-assist + insan onayı + denetlenebilir kayıt. Yani sistem sadece cevap üretmez, nasıl cevap verdiğini de izlenebilir kılar.

Bu bakış açısı sadece teorik değil; veriler de aynı şeyi söylüyor. Gartner'ın 2025 öngörülerine bakınca ilginç bir tablo çıkıyor. Bir yandan agentic AI sistemlerinin çok yaygınlaşacağı söyleniyor; öte yandan bu projelerin büyük bir kısmının maliyet, belirsiz değer ve zayıf risk yönetimi yüzünden iptal edileceği öngörülüyor. Bu aslında bir çelişki değil. Yaygın olan şey ile güvenli olan şey her zaman aynı değil.

Buradaki kritik nokta şu: sizin probleminiz "AI kullanmalı mıyım?" değil, "Hangi risk seviyesinde, hangi sözleşmeyle kullanmalıyım?" sorusu.

Benim görüşüm net: Türkiye'de regüle bir alanda otonom chatbot kuran şirketlerin önemli bir kısmı önümüzdeki yıllarda en az bir KVKK süreci ya da tüketici davası görecek. Bu kesin bir iddia değil; ancak mevcut örneklerin Türkiye'deki tüketici hukuku ve KVKK bağlamına taşınması hâlinde makul bir risk senaryosu. Mata v. Avianca, Air Canada, MyCity… Hepsi aynı şeyi söylüyor: başta doğru sözleşmeyi kurmazsanız, sistem bir noktada duvara çarpıyor.

Mesele model değil. Mesele kontrol.

Bölüm 3Refusal ve citation sözleşmeleri#

Bu hikâyeyi biraz daha mühendis gözüyle okuyunca iş dönüp dolaşıp iki temel "sözleşme"ye geliyor.

1. Refusal contract#

"Bilmiyorum" cevabı sistemin başarısızlığı değil, doğru çalıştığının göstergesidir.

Çünkü şunu net kabul etmek gerekiyor: modelin kaynağa dayanmadan ürettiği her cevap, production'da bir bug'dır. Bu bazen küçük bir içerik hatası gibi görünür ama regüle alanlarda doğrudan hukuki riske dönüşür.

Bunun en net örneklerinden biri yine Mata v. Avianca. Avukat, modelden bir davanın gerçek olup olmadığını doğrulamasını istiyor. Model kendinden emin bir şekilde "evet" diyor, hatta güvenilir hukuk veritabanlarını referans göstererek bunu destekliyor. Sorun şu: ortada böyle bir dava yok. Tamamen uydurma. Sonuç: mahkemeden para cezası ve ciddi bir itibar kaybı.

Buradaki problem "model hata yaptı" değil. Daha temel bir şey: model bilmediğini söyleyemiyor. Emin olmadığı durumda bile cevap üretmeye zorlanıyor.

Bu yüzden çözüm, modelin içine "daha iyi prompt" yazmak değil; sistem seviyesinde bir karar vermek: modelin elinde doğrulanabilir bir kaynak yoksa, cevap üretmek yerine açıkça "bilmiyorum" demeli. Daha kritik olan kısım ise şu: bu cevap sistem için bir failure değil, başarılı bir outcome olarak tanımlanmalı.

Yani metriklerin de buna göre kurulması gerekiyor. "Coverage %90" güzel bir sayı olabilir; ama o %90'ın içinde doğrulanmamış cevaplar varsa, sistem aslında sessizce risk üretiyordur. İyi bir agent-assist mimarisinde hedef şudur:

• ya doğru ve kaynaklı cevap ver,
• ya da hiç verme.

Aradaki gri alanı sistemden bilinçli olarak kaldırırsınız. Çünkü gerçek hayatta sorun çıkaran şey tam olarak o gri alan.

Yazının bu kısmından sonra biraz .NET ve Azure tarafında teknik örneklere de yer vereceğim. Geliştiriciler için .NET'te hazırladığım altyapıdan bir kesit (seri bittiğinde repoyu public yapacağım; şimdilik küçük parçalar):

public sealed record AssistantAnswer(
    string Answer,
    IReadOnlyList<Citation> Citations,
    ConfidenceLevel Confidence,
    RiskClass RiskClass,
    bool EscalationRequired,
    string? RefusalReason)
{
    public static AssistantAnswer Refused(
        string reason,
        RiskClass risk,
        ConfidenceLevel confidence = ConfidenceLevel.Low) =>
        new(
            Answer: "Bu soruyu yanıtlamak için yeterli kaynak bulunamadı.",
            Citations: Array.Empty<Citation>(),
            Confidence: confidence,
            RiskClass: risk,
            EscalationRequired: true,
            RefusalReason: reason);
}

Kullanıcı açısından da bu bir failure değil. Sistem elindeki bilgiyle konuşamayacağını fark ediyor ve bunu dürüstçe söylüyor. Doğru davranış bu.

API tarafında da semantik değişiyor. Bu bir exception değil; dolayısıyla HTTP 500 değil, 200 dönersiniz. Frontend de bunu "bir şey bozuldu" gibi göstermez. Onun yerine daha doğal bir akış kurarsınız: "Bu konuda güvenilir bir kaynak bulamadım, sizi ilgili ekibe yönlendiriyorum." Yani UX de sistem sözleşmesine uyumlu hâle geliyor.

Peki bunun karşılığında ne kazanıyoruz, ne kaybediyoruz?

Kazanç tarafı oldukça net. Öncelikle kontrol edilebilirlik geliyor: sistemin ne zaman konuşup ne zaman sustuğu artık deterministik bir karar. İkincisi ölçülebilirlik: log'larda RefusalReason tuttuğunuz anda şu soruya veriyle cevap verebiliyorsunuz: "Bilgi tabanımızda, veri setlerimizde ne eksik?" Bu, zamanla sistemin en değerli çıktılarından biri oluyor. Çünkü artık halüsinasyon kovalamıyorsunuz, doğrudan bilgi açığını kapatıyorsunuz.

Kayıp tarafı ise daha çok teknik detay. "Modele söyleyelim, kaynaksız konuşmasın" yaklaşımı burada çalışmaz; çünkü model doğası gereği boşluk doldurmaya meyilli. Gerçek çözüm orchestration katmanında: retrieval sonuç vermiyorsa modeli hiç çağırmamak. Bu küçük bir değişiklik gibi görünür ama mimariyi büyütür. Threshold kontrolü, retrieval skorlama ve fallback akışları biraz daha dikkatli tasarlanmak zorunda.

Latency tarafında da küçük bir bedel var. Doğru tasarlanmış sistemlerde, özellikle gereksiz büyük model çağrılarını kesiyorsanız token maliyetinde anlamlı bir düşüş görülebilir; latency etkisi ise retrieval, reranking ve validation stratejisine göre değişir. Karşılığında boşuna yapılan büyük model çağrılarını kesmiş olursunuz. Özellikle 32K context gibi pahalı çağrılarda bu ciddi fark yaratır. Pratikte gördüğümüz etki:

• token maliyetinde %15–30 düşüş (günümüzün, bireysel tarafta bile, en büyük karın ağrısı),
• kalite metriklerinde gözle görülür iyileşme.

Yani sistem daha yavaş değil, daha akıllı çalışıyor.

2. Citation contract: kaynaksız cümle yoktur#

Refusal yolunda citation'lar boş dönebilir; bu normaldir. Sistem "bu konuda konuşamam" diyorsa zaten kaynak göstermesi beklenmez. Ama citation'lar doluysa iş değişir.

Her citation gerçek bir chunk'a, gerçek bir doküman ID'sine ve doğrulanabilir bir snippet'e bağlı olmak zorundadır. Aksi hâlde bu citation değil, süslenmiş bir halüsinasyondur.

Sektörde en çok sorun yaratan yerlerden biri burası. RAG kurulduğu için herkes sistemin "kaynağa göre" çalıştığını varsayıyor. Oysa pratikte çoğu model cevabı önce kendi iç bilgisinden üretiyor, sonra retrieval'dan gelen parçaların içinden cevaba benzeyen bir yer bulup citation yapıştırıyor. Yani kaynak için atıf var gibi görünüyor ama o atıf cevabı gerçekten desteklemiyor.

Bu çok tehlikeli bir yanılsama. Çünkü ekranda kaynak görünce insan güveniyor; operatör de, kullanıcı da, hukuk ekibi de. Ama aslında sistem sadece cevabını sonradan makyajlamış oluyor.

Bu yüzden citation'ı modelin dil becerisine bırakmamak gerekiyor. Citation, modelin "ben bunu şu kaynaktan aldım" demesiyle değil, sistemin bunu doğrulamasıyla geçerli sayılmalı. Mimaride bu yüzden kritik bir düğüm var:

{
  "refused": false,
  "citations": ["CHUNK_42", "CHUNK_43"],
  "confidence": "High",
  "escalationRequired": false
}

{
  "refused": true,
  "refusalReason": "no_source",
  "citations": [],
  "escalationRequired": true
}

{
  "refused": true,
  "refusalReason": "no_source",
  "citations": [],
  "escalationRequired": true
}

{
  "refused": true,
  "refusalReason": "invalid_citation",
  "citations": [],
  "escalationRequired": true
}

Bu akışta kritik nokta şu: model sistemin merkezi değil, sadece bir adımıdır. Karar modelde başlamaz ve modelde bitmez. Risk sınıflandırma, retrieval, yetki filtresi, citation validation ve audit event, model çağrısının etrafında ayrı ayrı enforce edilir. Bu yüzden refusal bir hata değil, sistemin bilinçli olarak seçtiği güvenli bir outcome'dur.

Citation validator (akıştaki 7. adım)#

Bu katmanın görevi basit: modelin döndürdüğü her atfı, retrieval katmanının gerçekten döndürdüğü chunk listesiyle tekrar karşılaştırmak. Model [CHUNK_42] diyorsa sistem sorar:

• Böyle bir chunk gerçekten var mı?
• Bu chunk, bu kullanıcı sorgusu için retrieval'dan geldi mi?
• Cevaptaki iddia bu snippet tarafından gerçekten destekleniyor mu?

Cevap hayırsa iki seçenek vardır: cevap yeniden formatlanır ya da refusal yoluna düşer.

Bu pahalı bir işlem değil; yeni bir büyük model çağrısı kadar maliyetli değil. Daha çok bir doğrulama döngüsü. Ama etkisi büyük, çünkü citation hatalarının büyük kısmı burada yakalanır.

Tabii bunun da bedeli var. Öncelikle prompt daha disiplinli yazılmak zorunda. Modele chunk'ları düz metin gibi değil, [CHUNK_42] [CHUNK_43] [CHUNK_44] gibi yapılandırılmış şekilde vermeniz gerekir. Sonra da modelden her önemli iddianın yanına ilgili chunk ID'sini koymasını istersiniz. Bu, özellikle küçük modellerde her zaman kusursuz çalışmaz: bazı modeller chunk ID'lerini karıştırır, bazıları citation eklemeyi unutur, bazıları da kaynakla desteklenmeyen yorumu kaynaklıymış gibi gösterir.

Burada önemli bir yanlış varsayımı da kırmak gerekiyor: daha güçlü model, her zaman daha az halüsinasyon demek değildir. Reasoning modelleri bazı görevlerde daha iyi düşünür ama grounded summarization gibi işlerde daha fazla yorum katabilir. Daha çok akıl yürütmek, bazen daha çok extrapolation demektir. Yani model "metinde yazanı" aktarmak yerine "metinden ne çıkarılabilir" sorusuna kayabilir. Regüle sistemlerde bu fark ölümcül olabilir.

Bu yüzden citation contract, model seçiminden bağımsız bir güvenlik katmanı olarak düşünülmeli. Pahalı model kullanmak tek başına güvenlik sağlamaz. Hatta pahalı model ve zayıf citation kontrolü, ucuz model ve sıkı citation kontrolünden daha kötü davranabilir.

Özet basit:

• Kaynak yoksa cevap yok.
• Kaynak varsa, kaynak gerçekten cevabı desteklemek zorunda.
• Bunu da model değil, sistem doğrulamalı.

Son bölümTahminlerim ve gelecek#

Bu kısım kanıt değil, görüş. Ama kafadan atılmış görüşler de değil; mevcut örneklerin ve teknik gidişatın üzerine kurulmuş öngörüler.

Birinci öngörü: Önümüzdeki 1–2 yılda Türkiye'de en az bir büyük finans ya da sigorta şirketi, otonom chatbot'unun verdiği hatalı bilgi yüzünden bir tüketici hakları davası kaybedecek.

Bunu söylerken dayanağım şu: Air Canada'da yaşanan şey Türkiye'de de gayet mümkün, sadece hukuki çerçeve farklı olacak. Kanada'da başka bir regülasyon üzerinden tartışılan konu, Türkiye'de büyük ihtimalle 6502 sayılı Tüketicinin Korunması Hakkında Kanun ve KVKK eksenine oturacak. Özellikle KVKK'nın yapay zekâ tarafında çıkaracağı rehberler, bu davalarda teknik mimariyi değerlendirmek için fiilî standart hâline gelebilir. Yani mahkeme şuna bakacak: "Bu sistem otonom mu çalışıyordu, insan onayı var mıydı, log tutuluyor muydu, kaynak gösteriliyor muydu?" Cevaplar zayıfsa, şirketlerin işi zor.

İkinci öngörü: Bu kısım biraz benim gibi Microsoft ekosistemini yakından takip edenler için. 2027 itibarıyla Microsoft Agent Framework, Türkiye'deki kurumsal .NET projelerinde Semantic Kernel'ın önüne geçecek. SK hâlâ güçlü ve desteklenmeye devam edecek; ama yeni proje başlatan ekiplerin tercihi büyük ihtimalle daha standart, daha hafif ve .NET ekosistemine daha doğal oturan yapı olacak. Burada mesele "SK kötü" değil; mesele Microsoft'un uzun vadeli standardının nereye kaydığı. Stephen Toub'un dahil olduğu bir interface tasarımı, .NET dünyasında genelde tesadüfi bir şey değildir. Orada oluşan abstraction, zamanla ekosistemin varsayılanı hâline gelir.

Üçüncü öngörü: Yine Microsoft ekosistemi ve .NET özelinde: citation enforcement, prompt injection savunması ve PII redaction 2027'de standart middleware olacak. Bugün her ekip kendi citation validator'ını, kendi prompt injection filtresini, kendi PII temizleme katmanını yazıyor. Bu sürdürülebilir değil; her şirketin aynı güvenlik problemini sıfırdan çözmesi verimsiz ve riskli. Büyük ihtimalle NuGet tarafında Microsoft.Extensions.AI.Guardrails benzeri bir paket göreceğiz. Bu Microsoft'tan da gelebilir, topluluktan da; ama bir şekilde standartlaşacak ve diğer ekosistemlerde de yaygınlaşacak. Çünkü bu artık bir "AI özelliği" meselesi değil, uygulama güvenliği meselesi. OWASP LLM Top 10'da prompt injection ve vector/embedding zafiyetlerinin ayrı başlıklar olarak yer alması da bunu gösteriyor. Ekosistem burada ortak primitive'ler bekliyor.

Kapanış#

4–5 yıl önce kurumsal ve regülasyona tabi bir şirkette yapay zekâ sistemi kurmak "geleceğin işi" gibi görünüyordu. Bugün ise gecikmiş bir konu. Altyapı hazır, araçlar hazır, örüntüler yazılmış. Microsoft özelinde .NET 10 LTS ile birlikte Microsoft.Extensions.AI ve Microsoft Agent Framework production'da. Azure tarafında Foundry, AI Search, APIM AI Gateway gibi bileşenler zaten yerini almış durumda (diğer ekosistemler de, Vertex AI olsun bağımsız sistemler olsun, hızla ilerliyor). En önemlisi, bu işin nasıl yapılacağı artık bir deney değil; konuşulmuş, tartışılmış, tekrar tekrar aynı yere gelmiş bir disiplin.

Yazının başında bir cümle kurmuştuk: kurumsal yapay zekâda chatbot yapmıyoruz, sözleşmeli agent-assist sistemleri yapıyoruz. Şimdi bunu biraz daha keskinleştirebiliriz:

Bu sözleşmeler nerede enforce edilebiliyorsa, orada yazılmalı.

Ama kesinlikle şuralarda değil: sistem prompt'unda, README'de, pazarlama sayfasında. Çünkü sözleşme dediğiniz şey, çalışmadığında sistemi durdurabilmeli. Aksi hâlde sözleşme değil, niyet beyanıdır.

Air Canada örneğinde konuşulan paralar aslında önemsiz. Asıl önemli olan, mahkemenin kurduğu mantık. Hâkim Rivers'ın söylediği şeyin özeti şu: "Bilginin statik bir sayfadan mı yoksa bir chatbot'tan mı geldiğinin bir önemi yoktur."

Bunu .NET diline çevirdiğinizde geriye tek bir kural kalıyor:

Modelin verdiği her cevabın arkasında ya doğrulanabilir bir kaynak vardır ya da açık bir refusal vardır. Üçüncü bir seçenek yoktur.

Bütün mimariyi aslında bu cümlenin etrafına kuruyorsunuz. Refusal contract ve citation contract dediğimiz şeyler de bunun implementasyonu.

Önümüzdeki birkaç yılın farkı burada açılacak. Bu disiplini baştan kuran ekipler, sistemlerini büyütürken yeniden yazmak zorunda kalmayacak. Kurmayanlar ise aynı dersi daha pahalı bir yerde, daha zor bir ortamda öğrenecek. Muhtemelen bir production incident'ında. Ya da bir mahkeme salonunda.

Bu makaleyi tek başına bırakmayıp bir yazı dizisi olarak yayımlıyorum. Sonraki bölümler, burada anlatılan hikâyenin Azure ve .NET ekosisteminde doğru bir şekilde implementasyonu olacak.