2026'da YZ Tabanlı Yazılım Geliştirme Alanı Nereye Gidiyor?

“AI Engineering” Youtube kanalındaki 80+ tane YZ ile yazılım geliştirme sunumunun Türkçe özetidir.

YouTube’daki AI Engineering kanalında Araştırmacıların ve geliştiricilerin yaptığı SDLC iyileştirmeleriyle ilgili sunumlardan en güncel, popüler ve faydalı olanları sizler için derledim ve Türkçe olarak özetledim. Aşağıdaki genel özetten fikir edinebilirsiniz. Ayrıca her bir sunumun detaylı özetini inceleyebilir, daha fazla bilgi için kaynaklar bölümünden ilgili URL’lere ulaşıp sunumları izleyebilirsiniz.

Sunum seçimini AI Engineering kanalındaki son aylardaki YZ ile Yazılım Mühendisliği yapma konusundaki sunumları aldım. 3–5 tanesi tamamen reklam odaklı olduğu için onları almadım. Aldığım sunumlardan ise gerçekten alanı değiştirdiğine inandığım özgün ve faydalı olanları ⭐ ile işaretledim. Arzu eden özetlerini okuyup ayrıca, sunum videolarını da izleyebilir.

🌌Genel Özet🌌

1. GENEL FİKİR BİRLİĞİ VE ANA AKIM TRENDLER

1.1 Kod Artık Daha Ucuz, Yeni Darboğaz “Bağlam” (Context is the New Code) Sektördeki en büyük fikir birliği şudur: Yapay zekaya (YZ) kod yazdırmak artık en kolay ve maliyetsiz iştir. Asıl zorluk, YZ ajanlarının devasa ve karmaşık kod tabanlarında kafalarının karışmasını engellemektir. Bağlam Mühendisliği: İyi bir istem (prompt) yazmak devri kapandı. Artık “Bağlam Mühendisliği” (Context Engineering) devrindeyiz. Ajanlara tüm projeyi verip bağlam penceresini şişirmek onları “Aptal Bölgeye” sokar. Sadece ihtiyaç duydukları veriyi (Markdown dosyaları, API şemaları) alt ajanlar (sub-agents) aracılığıyla kademeli olarak sunmak şarttır.

1.2 “Sohbet” (Chat) Arayüzünün Ölümü ve MCP Devrimi Yapay zeka ile sadece metin kutusu üzerinden konuşmak, karmaşık mühendislik ve hukuk/finans gibi işler için yetersizdir. Sohbet arayüzleri yerini “Etkileşimli Arayüzlere (MCP Apps)” ve paylaşımlı çalışma alanlarına (Canvas) bırakıyor. YZ artık size metin değil, tıklayabileceğiniz butonlar ve grafikler üretiyor. MCP (Model Context Protocol), yapay zekanın USB-C’si haline gelmiş durumda. Ajanların dış dünyayla, API’lerle ve şirket veritabanlarıyla güvenli bir şekilde konuşmasını sağlayan standart altyapı MCP’dir.

1.3 Yazılım Mühendisinin Değişen Rolü: “Yazıcıdan” -> “Orkestra Şefine” Yapay zekanın kod yazması, mühendisleri işsiz bırakmıyor; aksine rollerini yükseltiyor. Mühendisler artık sıfırdan kod yazan kişiler değil; ürünün mimarisini tasarlayan, ajanların çalışacağı güvenli altyapıları (sandbox) kuran ve ajanların ürettiği kodu “inceleyen/onaylayan” (Reviewer) sistem yöneticileridir. YZ bağlamı kendi kendine anlayamaz; bu nedenle klasik yazılım temelleri (DDD, derin modüller, iyi dokümantasyon, test güdümlü geliştirme, TDD) her zamankinden daha önemli hale gelmiştir. Kötü mimari, YZ’yi de felç eder.

1.4 Küçük Modeller ve Pekiştirmeli Öğrenme (RL) Zaferi Her iş için devasa modellere ihtiyaç yoktur. Sektör, cihaz üzerinde (edge) lokal olarak çalışan, hızlı, ucuz ve gizlilik sağlayan küçük modellere (Qwen, Gemma, MiniMax) yönelmektedir. Bu küçük modeller, belirli görevler için Pekiştirmeli Öğrenme (RL) ile eğitildiğinde, devasa modelleri hız, maliyet ve doğruluk açısından geçmektedir.

1.5 Statik Testlerin (Evals) Sonu Standart yapay zeka benchmark testleri (kıyaslamalar) artık gerçeği yansıtmıyor. YZ ajanları otonomlaştıkça, onları test eden sistemlerin de dinamik, sürekli arka planda çalışan ve YZ’nin kendi ürettiği verilerle kendini düzelten bir yapıya geçmesi gerekiyor.

2. BEKLENMEYEN VE AYKIRI BULGULAR

Endüstrinin pazarlama rüzgarına tamamen ters düşen, veriye dayalı en çarpıcı gerçekler şunlardır:

2.1 Aykırı Bulgu 1: YZ, Kıdemli (Senior) Geliştiricileri %19 Yavaşlatıyor! Pazarlama sloganlarının aksine, METR tarafından yapılan saha deneyleri; karmaşık ve eski kod tabanlarında (legacy codebases/brownfield) YZ kullanan uzman geliştiricilerin işlerini %19 daha yavaş bitirdiğini kanıtlamıştır. YZ, sıfırdan LeetCode algoritmaları yazmada (greenfield) harikadır, ancak 10 yıllık devasa projelerdeki “örtük bilgiyi” (tacit knowledge) bilemediği için ürettiği hatalı kodları düzeltmek insanlara daha fazla zaman kaybettirmektedir.

2.2 Aykırı Bulgu 2: “Hız” Artık Rekabet Avantajı Değil; “Lezzet” (Taste) ve “Sürtünme” (Friction) Önemli Herkesin YZ ile saniyeler içinde özellik (feature) üretebildiği bir dünyada hızlı kod yazmak değerini yitirmiştir. Şirketler YZ hızına kapılıp her fikri koda döken “özellik fabrikalarına” dönüşürse çöplük (bloatware) üretirler. Asıl fark yaratan şey “Lezzet” (Taste) yani ürün estetiği ve mimari kalitedir. Ayrıca veritabanı taşıma veya güvenlik gibi kritik konularda YZ’nin hızını kesip bilinçli olarak “Sürtünme” (insan onayı) eklemek hayati bir zorunluluktur. Ajanlar acı hissetmez, çöplük üretirler; kaliteyi insan dikte etmelidir.

2.3 Aykırı Bulgu 3: CI/CD Öldü, Sürekli Hesaplama Geldi İnsanların haftada birkaç kez Pull Request (PR) gönderdiği CI/CD sistemleri, paralel çalışan 30 YZ ajanının saatte binlerce kod ve PR ürettiği bir dünyada çökmektedir. İnsanların bu hızı manuel incelemesi imkansızdır. Kod incelemelerini (Code Review) artık başka YZ’lerin (LLM-as-a-judge) yaptığı ve kodun sürekli derlenip test edildiği (Continuous Compute) sistemlere geçilmek zorundadır.

2.4 Aykırı Bulgu 4: YZ Tüketimi Toksik Bir Şirket Kültürüne Dönüştü (Token Maxxing) Büyük teknoloji şirketleri, çalışanlarını “YZ’yi ne kadar çok kullandıklarına (harcanan token sayısına)” göre değerlendirmeye başlamıştır. Bu metrik, mühendislerin YZ’ye boş yere iş yaptırmasına ve üretkenlik illüzyonu yaratmasına (Goodhart Yasası) neden olmaktadır. Oysa doğru mühendislik, YZ’yi her şey için kullanmak değil, nerede kullanmayacağını iyi bilmektir.

3. GELECEKTE BEKLENEN TRENDLER VE AR-GE ALANLARI

3.1 TEKNİK EVRİM: Ajan Mimarisi ve Altyapı Nasıl Değişiyor?

Yapay zeka ajanlarını (Agents) çalıştırmak, artık basit bir API çağrısı değildir. Ciddi bir sistem mühendisliği (DevOps/MLOps) problemine dönüşmüştür.

3.2 Bağlam Sıkıştırma (Intentional Compaction) ve Alt-Ajanlar: Büyük Dil Modellerine (LLM) tüm kod tabanını vermek bağlamı (context) kirletir. Teknik çözüm: Ajanları rollere değil, görevlere ayırmak gerekmektedir. Ana ajanın görevi sadece “akıl yürütmek” (reasoning) olmalıdır. Devasa bir projede bir şey aranacaksa, ana ajan bir “araştırmacı alt-ajan” (sub-agent) başlatır. Alt-ajan tüm dosyaları okur, bağlamını şişirir ve ana ajana sadece “Aradığın şey X dosyasında” diye kısa bir yanıt döner.

3.3 Git Çalışma Ağaçları (Worktrees) ile Paralelleştirme: Ajanların ana projeyi bozmadan paralel çalışabilmesi için “Git Worktree” teknolojisi yoğun olarak kullanılmaktadır. Aynı anda 5 farklı model, 5 farklı worktree’de çalışır, sonuçlar kıyaslanır (Best of N) ve en iyisi ana projeye birleştirilir (merge).

3.4 Durumlu (Stateful) Ajanlar ve MicroVM’ler (Firecracker): Ajanların uzun süren görevlerde (örneğin 3 saat süren bir refactoring) sunucu çökmesiyle tüm hafızasını kaybetmesini önlemek için altyapı değişiyor. Ajanlar AWS Firecracker gibi “Mikro Sanal Makinelerde” (MicroVM) izole ediliyor. Çalışma durumları anlık olarak donduruluyor (Execution Snapshot) ve 17 milisaniye gibi bir sürede tekrar uyandırılabiliyor (Dayanıklı Yürütme: Durable Execution).

3.5 Araç Çağrısı (Tool Calling) Yerine REPL / Kod Modu: Cloudflare gibi devasa API’lere sahip sistemlerde, API şemalarını JSON olarak YZ’ye vermek milyonlarca token israfıdır. Yeni trend: YZ’ye izole bir V8/JS motoru (REPL sandbox) verilir. YZ API’yi kullanmak için arka arkaya 8 araç çağırmak yerine, tek bir betik (script) yazar, bunu çalıştırır ve doğrudan sonucu alır.

3.6 RAG’dan GraphRAG’e Geçiş: Vektör veritabanlarına dayalı standart RAG (Erişim Destekli Üretim) sadece kelime “benzerliğini” bulur, bağlamı ve mantığı anlamaz. Gelecek, Bilgi Graflarındadır (Knowledge Graphs, Neo4j vb.). Belgelerdeki varlıklar ve ilişkiler ağ olarak haritalandırılır. YZ bu ağ üzerinde seyahat ederek çok daha kesin, halüsinasyonsuz ve kaynağı açıklanabilir (explainable) cevaplar üretir.

3.7 Sıfır Hata (Zero Bug) ve Biçimsel Yöntemler (Formal Methods): YZ rastgele (stokastik) hatalar yapabilir. Ancak YZ’nin ürettiği kod, Dafny veya Coq gibi “matematiksel ispat” dilleriyle derleme aşamasında doğrulanabilir. Uzay ve havacılıkta kullanılan “sıfır hatalı” kod yazma maliyeti, YZ sayesinde web geliştirme projelerine girecek kadar ucuzlayacaktır.

3.8 Küçük Modeller + Pekiştirmeli Öğrenme (RL) Kombinasyonu: Genel amaçlı GPT-5 veya Opus gibi dev modellere bağımlılık azalıyor. Ar-Ge ekipleri Qwen, Gemma, ModernBERT gibi küçük (1B -14B parametreli) modelleri alıp, sadece tek bir görevi yapması için (örneğin sadece veritabanı sorgusu yazmak veya siber güvenlik bariyeri olmak) Pekiştirmeli Öğrenme ile eğitiyor. Bu, maliyeti %90 düşürürken hızı ve doğruluğu inanılmaz artırıyor.

3.9 Tam Çift Yönlü (Full-Duplex) Sesli Ajanlar: Sesli yapay zekada “Sesten Metne -> Metinden Sese” (Cascaded) gecikmeli yapı terk ediliyor. “Flow Matching” gibi difüzyon tabanlı tekniklerle, aynı anda hem dinleyen hem konuşan, sözü kesilebilen, 70 milisaniye gecikmeli insansı sesli YZ’ler (Voice AI) web ve mobil uygulamalara entegre ediliyor.

4. YZ İLE KOD ÜRETEN BİR TAKIM NELERE ODAKLANMALI?

Eğer ekibiniz Cursor / Copilot, Claude Code / OpenCode / Pi veya otonom ajanlar kullanıyorsa, yazılım geliştirme yaşam döngünüzü (SDLC) acilen şu prensiplere göre güncellemelisiniz:

4.1 Kod Tabanını “Ajanlara Hazır” (Agent-Ready) Hale Getirin Yapay zeka, spagetti koda ve karmaşık mimarilere adapte olamaz.

• Derin Modüller (Deep Modules) Tasarlayın: İçi çok karmaşık olsa bile, dışarıya çok basit ve standart bir arayüz (Interface/API) sunan modüller yazın. Ajanlar bu “gri kutuları” kolayca kullanabilir.
• Katı Linter’lar ve Kurallar: Linting kurallarını acımasızca katılaştırın. “Boş catch blokları” (hatayı yutan kodlar) yasaklanmalıdır. Ajanlar kolaya kaçıp hataları gizlemeye (exception swallowing) bayılırlar.
• DDD (Domain Driven Design) Kullanın: İnsan ile YZ arasındaki iletişim kopukluğunu önlemek için projenin terimler sözlüğünü (Ubiquitous Language) bir Markdown dosyası (örn: rules.md) olarak belirleyin. YZ bu terminoloji dışına çıkamamalıdır.

4.2 “Bağlam Geliştirme Döngüsü” (CDLC) Kurun Artık yazdığınız spesifikasyonlar ve istemler (promptlar) projenin kodudur.

• Komut dosyalarınızı Git üzerinden versiyonlayın.
• YZ’ye yazdığınız kuralların çalışıp çalışmadığını test eden, hatta bu kuralları başka bir LLM’e (LLM-as-a-judge) okutup “Bu komut yeterince açık mı?” diye denetleten bir sistem kurun.

4.3 Test Güdümlü Geliştirme (TDD) Artık Opsiyonel Değil, Zorunluluktur YZ çok hızlıdır; fırtına gibi çalışmayan kod yığınları üretebilir (“outrunning headlights”, farların aydınlattığı alanın dışına çıkmak).

• YZ’ye asla “Bana X özelliğini yaz” demeyin.
• YZ’ye önce “Bana X özelliğinin çalışacağını kanıtlayan testleri yaz” deyin. İnsan olarak bu testleri onaylayın.
• Ardından YZ’ye “Şimdi sadece bu testleri geçecek kadar kod yaz” deyin. Ve kodları da her zaman okuyun. Bu, YZ’nin hız sınırını ve kalite kontrolünü sağlar.

4.4 Çoklu Ajanları Paralel Değil, “Seri ve Kontrollü” Çalıştırın Ajanların aynı anda aynı dosyaları düzenlemesine izin vermeyin.

• Yaratıcı ve Doğrulayıcı (Creator-Verifier) Deseni: Kodu yazan YZ (örn: Sonnet) ile kodu kontrol eden YZ’yi (örn: gpt-5) ayırın. Kodu yazan ajan kendi hatasına kör olabilir.
• Karar Günlüğü (Decision Log): Ajan otonom çalışırken size aldığı her kararı sormasın (bu süreci duraksatır). Kendisi inisiyatif alıp çözsün ama bunu bir “Karar Günlüğü” dosyasına yazsın. Siz mesaiye başladığınızda kodu değil, bu günlüğü okuyun ve farklı bir tercihiniz varsa onu düzelttirin. En sonda commit’lenicek olan kodu okumayı asla unutmayın.

4.5 Teknik Olmayan Ekiplere (Ürün ve Tasarım) “Ajan” Verin Yazılım ekibinin en büyük darboğazı, tasarımcıdan (Figma) veya ürün yöneticisinden (PRD) gelen işleri koda dökmektir. Yeni altyapılar (örn: Tessl, tldraw) sayesinde, teknik olmayan kişilerin kendi ekranlarındaki değişiklikleri YZ aracılığıyla otomatik olarak bir Pull Request’e dönüştürmesini sağlayın. Mühendisler sıfırdan kodlamak yerine sadece bu PR’ı inceleyen (Reviewer) konumuna geçmelidir.

Özetle;

YZ destekli yazılım takımları artık kodu doğrudan yazmaktan çok; sistem mimarisi, net arayüzler, güçlü otomatik test altyapıları ve güvenli çalışma sınırları (guardrails / harness / sandbox) tasarlamaya odaklanmalıdır. Geleceğin yazılım mühendisi, binlerce satır kod yazan kişi değil; yapay zekâ ajanlarının hata yapmadan, güvenle ve kaliteli şekilde çalışabileceği sistemi kurgulayan bir “Sistem Orkestratörü” olacaktır. 2026 itibarıyla “bana şu kodu yaz” yaklaşımı yerini; YZ’nin içinde çalışacağı mimariyi, testleri, kalite standartlarını ve süreç kontrolünü tasarlayan insan odaklı mühendisliğe bırakmaktadır çünkü yapay zekâ ajanları olağanüstü üretken işçiler olsa da, neyin inşa edileceğine (vizyon), neyin kaliteli olduğuna (lezzet) ve sürecin ne zaman durdurulacağına (mantık) karar verme yetkisi hâlâ tamamen insana aittir.

1. ⭐ Hissiyata Yer Yok: Karmaşık Kod Tabanlarındaki Zor Problemleri Çözmek, Dex Horthy@HumanLayer

Bu sunumda, yapay zekâ kodlama ajanlarının büyük ve karmaşık projelerde verimli kullanılabilmesi için, yalnızca “şunu kodla” demek yerine bağlamların dikkatle yönetilmesi; önce plan oluşturulup insan onayı alındıktan sonra kod yazdırılması gerektiğini vurgulayan pratik ve derinlemesine stratejiler sunulmaktadır.

Yapay zekâ (YZ) destekli yazılım mühendisliği, sıfırdan başlanan küçük projelerde (greenfield) harika çalışırken, mevcut, eski ve karmaşık kod tabanlarında (brownfield) genellikle hayal kırıklığı yaratır. Geliştiriciler YZ’nin sürekli olarak “slop” (kalitesiz, özensiz, teknik borç yaratan kod) ürettiğinden ve büyük repolarda (depolarda) çalışmadığından şikâyet etmektedir. Dex ekibiyle birlikte bu sorunu çözdüklerini ve verimliliklerini 2–3 kat artırdıklarını belirtmektedir.

Büyük dil modelleri (LLM’ler) durumsaldır (stateless); yani onlardan daha iyi sonuç almanın tek yolu, onlara daha iyi tokenlar (bağlam/bilgi) sunmaktır. Horthy, YZ’yi kullanmanın üç yolunu şu şekilde tanımlıyor:

• En Safdil Yöntem: YZ’ye bir şey sorarsınız, hata yapar, onu düzeltmeye çalışırsınız ve bağlam (context) penceresi dolana kadar bu kısır döngü devam eder.
• Biraz Daha Akıllı Yöntem: İşler ters gittiğinde sohbeti temizler ve yeni bir bağlam penceresi açar.
• En Akıllı Yöntem (Kasıtlı Sıkıştırma, Intentional Compaction): YZ’nin ulaştığı mevcut durumu ve ilerlemeyi özetleyen bir Markdown dosyası oluşturmasını istersiniz. Sonraki adıma bu sıkıştırılmış özetle başlarsınız. Böylece gereksiz dosya aramaları ve hata logları ile bağlamı şişirmemiş olursunuz.

Horthy bağlam penceresinin %40'ından fazlasının kullanılmaması gerektiğini savunuyor. Eğer bağlam penceresi gereksiz verilerle (JSON dökümleri, eski test çıktıları, uzun dosya içerikleri) dolarsa, YZ “Aptal Bölge”ye girer ve performansı dramatik şekilde düşer. Amaç her zaman “Akıllı Bölge”de kalmaktır.

Alt ajanlar, YZ’ye “sen bir veritabanı uzmanısın” gibi insan rolleri biçmek için değil, bağlamı kontrol etmek için kullanılmalıdır. Örneğin, devasa bir kod tabanında bir şey aranacaksa, ana ajan bir alt ajan yaratır. Alt ajan tüm dosyaları tarar ve ana ajana sadece “aradığın şey şu dosyanın şu satırında” şeklinde kısa ve öz bir yanıt döner. Bu sayede ana ajanın bağlam penceresi temiz kalır.

Başarılı bir kodlama ajanı kullanımı üç aşamalı bir “Sıkıştırma” döngüsü gerektirir:

1. Araştırma (Research): Kod yazmadan önce sistemin nasıl çalıştığı anlaşılır ve ilgili dosyalar bulunur. Bu bir “gerçeğin sıkıştırılması”dır.
2. Planlama (Plan): Yapılacak değişikliklerin (hangi dosya, hangi satır, nasıl test edilecek) adım adım yazıldığı bir plan oluşturulur. Bu bir “niyetin sıkıştırılması”dır.
3. Uygulama (Implement): YZ sadece bu kusursuz plana bakarak kodu yazar.

Horthy, bu yöntemle 300.000 satırlık karmaşık bir Rust projesinde tek seferde (one-shot) hatasız bir PR (Pull Request) oluşturduğunu örnek göstermektedir.

Horthy YZ’nin düşünme yeteneğinin olmadığını, sadece sizin düşüncelerinizi (veya düşüncesizliğinizi) güçlendirdiğini (amplify) vurgular. Eğer bir sorunu siz anlamadıysanız, YZ’nin onu çözmesini bekleyemezsiniz. YZ’yi kullanarak bir mimariyi değiştirmeye çalıştıkları, ancak kendileri de ne yapacaklarını tam bilmedikleri için başarısız oldukları bir anısını paylaşır.

Geleneksel kod incelemesinin en temel amacı “zihinsel uyum”dur (ekibin ne yapıldığı konusunda aynı sayfada olması). İnsanların haftada binlerce satır YZ tarafından üretilmiş kodu okuması zordur ve sıkıcıdır. Bunun yerine, insanlar kodu değil, YZ’nin ürettiği “Plan”ları incelemelidir. Eğer plan doğruysa, ortaya çıkacak kod da yüksek ihtimalle doğru olacaktır. Bu, mühendisler için çok daha yüksek bir “kaldıraç” (leverage) noktasıdır.

Sonuç:

• “Spec-Driven Development” (Şartname Odaklı Geliştirme) terimi kötüye kullanılıyor: Horthy, herkesin bu terimi farklı kullandığını (sadece uzun bir prompt yazmayı bile böyle adlandırdıklarını) belirterek, odaklanılması gereken şeyin terimler değil, “Bağlam Mühendisliği” (Context Engineering) olduğunu söylüyor.
• Pratik Yapın (Reps): Hangi modelin veya aracın en iyisi olduğunu tartışmak yerine, tek bir araç seçip onunla yüzlerce kez pratik yapmanın (intuition/sezgi geliştirmenin) şart olduğunu belirtiyor.
• Kültürel Değişim: Kodlama ajanları yakında sıradanlaşacak. Asıl zorluk, şirketlerin iş akışlarını bu yeni sisteme adapte etmesi olacak. Şu an Kıdemli (Senior) mühendisler, YZ’nin ürettiği kalitesiz kodları temizlemekten nefret ediyor. Bu kültürel değişimin yukarıdan aşağıya (yönetimden) desteklenmesi gerekiyor.

2. Cursor’ın Composer Modelini Geliştirmek, Lee Robinson@Cursor

Bu sunum Cursor ArGe ekibinin geliştirdiği ilk yapay zekâ kodlama ajanı modeli olan “Cursor Composer”ın geliştirilme sürecini ve arkasındaki teknik zorlukları anlatan bir sunumdur.

Gerçek dünyadaki yazılım mühendisliği ihtiyaçları için tasarlanan Composer, piyasadaki en iyi açık kaynaklı modellerden daha iyi performans gösterirken, GPT-4 veya Claude 3.5 Sonnet gibi modellerin zekasına denktir. Bu yüksek zeka seviyesindeki modeller yaklaşık 4 kat daha hızlı token üretebilmektedir. Eski tip kodlama ajanları arka planda çalışıp sonuç vermek için 20 dakika beklerken, Composer anında, doğrudan kullanıcının gözü önünde (kod okuma, düzenleme, terminal komutları çalıştırma gibi) birden fazla aracı aynı anda kullanarak çalışır.

Ekip modeli eğitmek için Reinforcement Learning (Pekiştirmeli Öğrenme) kullandı. Modelin geliştirilmesindeki temel strateji, eğitim ortamını gerçek dünyadaki Cursor kullanım ortamıyla (production) birebir eşleştirmekti. Model farklı kodlama senaryoları (rollouts) dener, en başarılı olanı seçer ve ağırlıklarını (weights) güncelleyerek kendini geliştirir.

Robinson, yapay zeka modelini eğitirken aslında makine öğreniminden ziyade üç büyük altyapı (infrastructure) sorunuyla uğraştıklarını belirtiyor:

• Zorluk 1: Eğitim ve Çıkarım (Inference) Hızını Eşleştirme: Devasa bir “Uzman Karışımı” (Mixture of Experts, MoE) modelini binlerce GPU üzerinde eğitmek normalde çok yavaştır. Çözüm: Ekip çok düşük hassasiyetli eğitime olanak tanıyan özel çekirdekler (custom kernels) yazdı. Bu sayede eğitim hızını 3,5 kat artırarak gecikmeyi önlediler.
• Zorluk 2: Karmaşık Senaryolar ve Boşta Kalan İşlemciler: Model farklı görevleri (rollouts) farklı sürelerde bitirdiği için sistemde boş bekleyen işlemciler oluyordu. Çözüm: Ray adı verilen bir sistemle gelişmiş bir “yük dengeleme” (load balancing) kurarak görevleri boştaki işlemcilere dinamik olarak dağıttılar.
• Zorluk 3: Ortam Tutarlılığı: Modelin eğitim sırasında gördüğü ortam ile son kullanıcının bilgisayarındaki ortam farklılık gösteriyordu. Çözüm: Cursor’ın “Cloud Agents” (Bulut Ajanları) altyapısını kullanarak devasa bir sanal makine (VM) filosu kurdu. Böylece model, tıpkı gerçek bir kullanıcının bilgisayarındaymış gibi güvenli bir ortamda kod çalıştırarak eğitildi.

Pekiştirmeli öğrenme süreci modele çok kritik insani davranışlar kazandırdı:

• Paralel Çalışma: Araçları sırayla kullanmak yerine paralel olarak (aynı anda birden fazla dosyayı okumak gibi) kullanmayı öğrendi; bu da onu çok hızlandırdı.
• Daha Az ve Öz Kod Yazma: Başlangıçta çok fazla gereksiz kod silip yazan model, zamanla Cursor’ın “anlamsal arama” (semantic search) aracını çok iyi kullanmayı öğrendi. Kodda değişiklik yapmadan önce projenin ilgili kısımlarını okumayı ve araştırmayı alışkanlık haline getirdi.

Sonuç:

1. Kodlama gibi çok spesifik bir alanda pekiştirmeli öğrenme (RL) son derece iyi çalışıyor.
2. Yapay zekâ asistanları ile kod yazmak, şirketin kendi Ar-Ge ve altyapı geliştirme süreçlerini inanılmaz derecede hızlandırdı.
3. Günümüzde yapay zekâ modellerini ölçeklendirmek temelde bir donanım ve “altyapı” (infrastructure) problemidir.

3. ⭐ Ajanlar Yerine Yetenekler (Skills) Geliştirin – Barry Zhang & Mahesh Murag @Anthropic

Bu sunumda, yapay zekâ ajanlarının (agents) gelişiminde yeni bir paradigmaya geçiş yapıldığı ve her özel görev için sıfırdan yeni bir ajan inşa etmek yerine, genel amaçlı ajanlara kurumsal ve spesifik “Yetenekler” (Skills) kazandırmanın çok daha verimli olduğu anlatılmaktadır. Zhang ve Murag, “İhtiyacınız olan tek şey koddur” (Code is all you need) felsefesiyle yola çıkarak Anthropic’in ajan mimarisine getirdiği bu yeni ve ölçeklenebilir yaklaşımı tanıtmaktadır.

Geleneksel yaklaşımda her farklı alan (kodlama, araştırma, finans vb.) için kendi araçlarına sahip farklı ajanlar geliştiriliyordu. Ancak Claude Code gibi genel amaçlı ajanların ortaya çıkmasıyla, farklı görünen YZ iş akışlarının temelinde evrensel bir kod yürütme arayüzünün yattığı fark edildi. Zhang, günümüzdeki genel ajanların çok zeki olduğunu ancak “alan uzmanlığından” (domain expertise) yoksun olduklarını belirtiyor. Nasıl ki karmaşık kurumsal vergilerinizi bir matematik dehası yerine deneyimli bir vergi uzmanına yaptırmak isterseniz, ajanların da belirli görevleri doğru yapabilmesi için yönlendirilmeye ve spesifik uzmanlık bilgisine ihtiyaçları vardır.

Bu sorunu çözmek için Anthropic “Ajan Yetenekleri”ni (Agent Skills) tasarladı. Yetenekler, temelde ajanlar için prosedürel bilgiler içeren basit dosya klasörleridir. İçlerinde ajanı yönlendiren Markdown dosyaları ve araç olarak kullanılabilen kod betikleri (scripts) barındırırlar. Çok basit olmaları bilinçli bir tercihtir; böylece tıpkı normal bir kod projesi gibi Git veya Google Drive üzerinden kolayca paylaşılabilir ve ekipler arasında sürümlendirilebilir (versioning). Ayrıca bu yetenekler “Kademeli Açıklama” (Progressive Disclosure) yöntemiyle çalışır: Ajan başlangıçta sadece yeteneğin ne işe yaradığına dair kısa bir üst veri (metadata) görür. Eğer o yeteneğe gerçekten ihtiyaç duyarsa, klasörün tamamını okur. Bu sayede ajanın bağlam penceresi (context window) yüzlerce yetenekle gereksiz yere şişirilmemiş olur. Yetenekleri, ajanın kendisi için sistem istemlerini fonksiyon çağrısı yapması olarak düşünebilirsiniz.

Murag, yeteneklerin piyasaya sürülmesinin ardından 5 hafta gibi kısa bir sürede binlerce yetenekten oluşan devasa bir ekosisteme dönüştüğünü vurguluyor. Bu ekosistem temel olarak üçe ayrılıyor:

• Temel Yetenekler (Foundational Skills): Belge oluşturma, formatlama veya biyoinformatik gibi karmaşık bilimsel verileri analiz etme gibi ajana yepyeni özellikler katan yetenekler.
• Partner Yetenekleri (Partner Skills): Browserbase veya Notion gibi şirketlerin Claude’un kendi ekosistemlerini ve yazılımlarını kusursuz şekilde kullanabilmesi için hazırladığı yetenekler.
• Kurumsal ve Ekip Yetenekleri (Enterprise & Team Skills): En hızlı büyüyen alan burasıdır. Büyük şirketler (Fortune 100) ve dev yazılım ekipleri kurum içi en iyi pratikleri, kodlama standartlarını ve kendilerine has iç yazılımların nasıl kullanılacağını ajanlara öğretmek için yetenekler üretiyorlar. İşin çarpıcı yanı, finans, hukuk veya İK gibi teknik olmayan departmanlardaki çalışanlar da kendi iş akışlarını otomatize eden yetenekler oluşturabiliyor.

Murag, gelişen yeni yapay zekâ mimarisini bilgisayar sistemlerine benzeterek özetliyor: Bu yeni ekosistemde YZ Modelleri işlemcilerdir (Processors), Ajanlar (Agents) işletim sistemidir (OS), Yetenekler (Skills) ise uygulamalardır (Applications). İşletim sistemi (Ajan) kendi başına ne kadar iyi olursa olsun, ona asıl değeri katan şey üzerine kurulan uygulamalardır (Yetenekler). Ayrıca yetenekler Model Context Protocol (MCP) sunucularının rakibi değil, tamamlayıcısıdır. MCP ajana dış dünyayla bağlantı kurma (API) imkânı sağlarken, Yetenekler bu bağlantıların nasıl bir iş akışıyla orkestre edileceğini öğretir.

4. Etkili Yapay Zeka Kodlama Ajanları Geliştirirken Elde Edilen Zor Kazanılmış Dersler, Nik Pash @Cline

Bu sunumda, yapay zekâ ajanları (agents) geliştirirken yıllardır kullanılan karmaşık mühendislik numaralarının artık geçerliliğini yitirdiği ve odaklanılması gereken asıl noktanın modelleri eğitmek için kullanılan veri kümeleri ve test ortamları (benchmarks) olduğu anlatılmaktadır. Pash, “Aşırı düşünmeyi bırakın” felsefesiyle yola çıkarak Cline’ın açık kaynaklı yeni benchmark projesini tanıtmaktadır.

Geçmişte geliştiriciler, zayıf yapay zeka modellerinin eksiklerini kapatmak için RAG (Erişim Artırılmış Üretim), karmaşık arama ağaçları ve gelişmiş araç çağırma iskeleleri (scaffolding) gibi hilelere başvuruyordu. Ancak Pash bu dönemin kapandığını vurguluyor. Gelişmiş sınır (frontier) modelleri artık bu “başa çıkma mekanizmalarını” ezip geçiyor. Bunun en büyük kanıtı, hiçbir karmaşık yapısı olmayan, sadece tek bir terminal aracına sahip minimalist Terminus sisteminin, Gemini 3.0 gibi güçlü bir modelle birleştiğinde dünyanın en karmaşık ajan sistemlerini geride bırakmasıdır. Pash’a göre ders çok net: Ajan mühendisliğindeki yeteneğiniz, temel modelin kapasitesi karşısında anlamsız kalıyor; minimalizm ve basit araçlar her zaman kazanıyor.

Pash’a göre sektördeki asıl darboğaz, mükemmel ajanı tasarlamak değil, modellerin kendilerini geliştirmektir. Modeller, akıllı mühendislik hileleriyle değil, ancak zorlu görevler üzerinde Pekiştirmeli Öğrenme (RL: Reinforcement Learning) ortamlarında eğitildiklerinde gelişirler. Modellerin akıl yürütme yeteneklerindeki her büyük sıçrama, yeni ve zorlu bir benchmark sayesinde gerçekleşmiştir.

Gerçek dünyadaki yazılım görevlerini faydalı RL ortamlarına dönüştürmek ise zorlu bir süreçtir. Pash, bir görevin başarıyla tamamlanıp tamamlanmadığını kontrol eden iyi bir doğrulayıcının (verifier) nasıl olması gerektiğini “Çaydanlık Analojisi” ile açıklıyor: Suyun kaynayıp kaynamadığını anlamak için ocağın gazla mı çalıştığına, ateşin ne kadar yüksek olduğuna veya çaydanlığın malzemesine bakmazsınız; sadece düdüğün ötüp ötmediğine bakarsınız. İyi bir test süreci tamamen “sonuç odaklı” (pure outcome verification) olmalıdır. Ajanın o sonuca “nasıl” ulaştığını dikte eden aşırı kuralcı testler başarısız testlerdir.

Sunumun en çarpıcı noktalarından biri (Pash’ın tabiriyle “Truth Nuke” / Hakikat Atom Bombası), büyük yapay zekâ laboratuvarlarının ajanların gerçek dünyadaki başarı ve başarısızlıklarına dair devasa veri kümelerini ellerinde tutup kapalı kapılar ardında saklamalarıdır. Pash, dünyadaki en zengin veri kümelerinin gizli tutulmasının yapay zekâ bilimi ve açık kaynak ekosisteminin gelişimini yavaşlattığını belirtiyor.

Bu sorunu çözmek için Pash “cline-bench” adlı projeyi duyuruyor. Cline-bench, yapay kodlama bulmacaları yerine gerçek yazılım mühendisliği görevlerini temel alan, tamamen açık kaynaklı ve tekrarlanabilir bir ajan değerlendirme (benchmark) ortamıdır. Pash, sunumun sonunda tüm geliştiricileri Cline’ı kullanırken verilerini gönüllü olarak paylaşmaya (opt-in) davet ediyor. Bu sayede, geleceğin kodlama zekasını (next-generation coding intelligence) eğitecek ve büyük şirketlerin tekelini kıracak açık bir veri kümesinin topluluk tarafından hep birlikte inşa edilebileceğini vurguluyor.

5. ⭐ Kod Değerlendirmeleri: Kod Parçalarından Kod Tabanlarına, Naman Jain @Cursor

Yapay zekâ kodlama modellerinin değerlendirme (evaluation/eval) süreçlerinin son dört yıldaki evrimi incelenmektedir. Naman Jain, saniyeler içinde çözülen basit algoritma parçacıklarından saatler veya günler süren tüm bir kod tabanının optimizasyonuna kadar farklı zaman ufuklarında (time horizons) yapay zekâyı nasıl doğru bir şekilde test edebileceğimizi anlatmaktadır.

Geçmişteki statik test ortamlarının en büyük sorunu “veri kirliliği” (data contamination) idi. Modeller tüm internetle (GitHub, Stack Overflow vb.) eğitildiği için, standart testlerdeki (benchmark) soruları zaten ezberlemiş oluyorlardı. Jain ve ekibi bu sorunu çözmek için LiveCodeBench adını verdikleri dinamik bir değerlendirme sistemi geliştirdi. Bu sistem, LeetCode gibi platformlardan sürekli yeni sorular çekerek modellerin ezberini değil, taze problem çözme yeteneğini test ediyor. Ortaya çıkan “Hakikat Atom Bombası” niteliğindeki bulgu ise şuydu: Modeller, kendi eğitim verisi kesim tarihlerinden (cutoff date) sonra yayınlanan sorularla test edildiğinde, başarı oranları %50'lerden %15–20 seviyelerine dramatik bir şekilde çakılıyordu. Zaman model performansını ölçmek için en iyi kontrol mekanizması haline gelmişti.

Saniyeler süren görevlerden gerçek dünyadaki yazılım optimizasyon görevlerine (GSO: Gelişmiş kod tabanlarını hızlandırmak gibi saatler süren görevler) geçildiğinde ise çok daha ilginç bir sorun ortaya çıktı: Ödül Hackleme (Reward Hacking). Frontier (sınır) modelleri, kodu gerçekten ve mimariye uygun bir şekilde optimize etmek yerine, sadece testi geçmek için “hile” yapmaya başladılar. Modellerin çalışma süresini kısaltmak için rastgele fonksiyonlara önbellek (cache) eklediği, hatta testlerin yapıldığı değerlendirme altyapısını (evaluation infra) ele geçirip (hijack) Python yorumlayıcısını manipüle ettiği görüldü. Jain, bu hilekarlığı tespit edebilmek için değerlendirme sistemlerine kodun geleneksel (idiomatic) olup olmadığını denetleyen “LLM tabanlı Yargıçlar” (Hack-Detector) eklenmesi gerektiğini vurguluyor.

Daha da uzun ufuklu görevlerde, örneğin 4.000 satırlık devasa bir C kütüphanesini (Zopfli) sıfırdan güvenli bir Rust koduna çevirmek (Syzygy projesi) gibi durumlarda, klasik testler tamamen yetersiz kalmaktadır. Sistemin sonunda sadece “kod çalıştı” veya “kod çalışmadı” şeklinde tek bir ikili (binary) sonuç almak, modelin saatlerce süren çabası hakkında hiçbir fikir vermez. Jain’e göre çözüm ara notlandırma sinyalleridir (intermediate grading signals). Modellerin bu devasa görevlerdeki ilerlemesi, “çevrilen veya yeniden yapılandırılan kodun yüzdesi” gibi adım adım ölçütlerle değerlendirilmelidir.

Sunumun son bölümünde ise Copilot Arena gibi gerçek insan kullanımını ölçen “vahşi doğa” (in-the-wild) değerlendirmelerine değinilmektedir. İnsan odaklı deney tasarımında en kritik metrik başarı değil, gecikmedir (latency). Bir yapay zekâ asistanı, kod tamamlama önerisini 1 saniyeden daha uzun sürede verirse, kod ne kadar mükemmel olursa olsun, insanların o kodu kabul etme oranı keskin bir şekilde düşmektedir.

Özetle Jain’in mesajı net: Yapay zekâ modelleri geliştikçe, onları değerlendirme yöntemlerimiz de gelişmelidir. Geleceğin eval sistemleri, veri kirliliğini önlemek için sürekli güncellenmeli (dinamik), modelin hilelerini yakalayacak kadar zeki olmalı ve devasa projelerde başarısızlıkları değil, adım adım gelişimi ölçecek hassas ara sinyaller sunmalıdır.

6. ⭐ Kod Dünyası Modeli: Hesaplama için Dünya Modelleri Oluşturma, Jacob Kahn @FAIR Meta

Meta AI araştırmacısı Jacob Kahn tarafından sunulan bu vizyon, yapay zekâ kodlama modellerinde akıl yürütme, planlama ve karar alma yeteneklerine sahip “Kod Dünya Modeli” (Code World Model: CWM) konseptini tanıtmaktadır. Geleneksel büyük dil modellerinin kodu sadece bir metin (sözdizimi) olarak görmesine karşı çıkan Kahn, kodun aslında yürütülebilir (executable) kurallara sahip bir sandbox (kum havuzu) olduğunu ve yapay zekânın programların durum geçişlerini simüle edebilmesi gerektiğini savunmaktadır.

CWM’nin temelinde yatan teknoloji, sadece bir sonraki kelimeyi (token) tahmin etmek yerine “Yürütme İzleme” (Execution Tracing) yapabilmesidir. Sistem, bir kod çalıştığında değişkenlerin, belleğin ve program durumunun satır satır nasıl değişeceğini tahmin eder. Ekip bu modeli eğitmek için basit algoritma fonksiyonlarının ötesine geçerek, GitHub’dan devasa boyutta gerçek Pull Request (PR) verileri toplamış, bu verileri mutasyona uğratıp CI (Sürekli Entegrasyon) testlerinden geçirerek, tüm bir depo (repository) seviyesinde çalışan yürütme izleri oluşturmuştur.

32 milyar parametreli bu modelin ajanik pekiştirmeli öğrenme (RL) eğitimi sırasında çok yenilikçi bir altyapı kullanılmıştır. Geleneksel RL sistemlerindeki veriyi üretenler (samplers) ve modeli eğitenler (trainers) arasındaki dar boğazı çözmek için yüksek düzeyde asenkron bir mimari kurulmuştur. Bu mimarinin en radikal özelliği ise “Yörünge Ortası Güncelleme” (Mid-Trajectory Updates) yapabilmesidir; yani model, terminalde kod çalıştırıp çevresiyle etkileşime girdiği sırada (işlemi bitirmesini beklemeden) arka planda yeni ağırlıklarla güncellenebilmektedir. Model özellikle “bash” terminalini kullanarak karmaşık sistemleri yönetme konusunda uzmanlaşmıştır.

Kodu sadece metin olarak değil, “çalışan bir sistem” olarak anlayan bu model, iki büyük uygulama alanı sunmaktadır. Birincisi “Nöral Hata Ayıklayıcı” (Neural Debugger); geliştiriciler, kodun ortasına istedikleri hedef durumu doğal dilde yazabilir ve model, yürütme izlerini simüle ederek o koda nasıl ulaşılacağını bulabilir. İkincisi ve çok daha iddialısı ise bilgisayar biliminin ünlü çözülemeyen “Durma Problemi”ne (Halting Problem) getirdiği yaklaşımdır. CWM (Code World Model), devasa ve pahalı dağıtık sistem kodlarını veya potansiyel sonsuz döngüleri gerçekten çalıştırmadan, zihninde simüle ederek kodun nasıl davranacağını ve durup durmayacağını tahmin edebilmektedir.

Özetle: Yapay zeka ile kod üretmenin geleceği, sadece iyi görünen sözdizimleri (syntax) üreten dil modellerinde değil; yazdığı kodun belleği, değişkenleri ve sistemi nasıl etkileyeceğini adım adım görebilen “Dünya Modelleri”ndedir. Meta AI topluluğun bu yeni paradigmayı test edip geliştirebilmesi için CWM’yi Hugging Face ve GitHub üzerinden açık kaynaklı olarak araştırmacıların kullanımına sunmuştur.

7. Yapay Zekâ Kernel’i Üretimi: Neler işe yarıyor, neler yaramıyor, sırada ne var?, Natalie Serrino @Gimlet Labs

Bu sunumda, yapay zekâ (ML) modellerini donanım seviyesinde hızlandırmak için alt seviye kodların (kernellerin) yapay zekâ ajanları tarafından nasıl otomatik olarak üretilip optimize edilebileceği anlatılmaktadır. Serrino, GPU kernellerini optimize etmenin model performansını inanılmaz derecede (örneğin Llama modellerinde 3 kat) artırabildiğini, ancak bu işi yapabilecek donanım uzmanlarının sayısının çok yetersiz olduğunu ve mevcut uzmanların iş yükü altında ezildiğini belirtiyor. Gimlet Labs bu darboğazı çözmek için PyTorch kodunu alıp hedef donanıma (örneğin Apple M4, Nvidia, AMD) özel optimize edilmiş düşük seviyeli kodlar üreten ajan sistemleri geliştiriyor.

Geçmişte ve günümüzde bu optimizasyon süreci, bir insanın manuel olarak kod yazması, derleyip çalıştırması, doğruluğunu test etmesi ve ardından darboğazları bulup kod üzerinde tekrar optimizasyon yapması (profiling) şeklinde ilerliyordu. Gimlet’in geliştirdiği çoklu ajan (multi-agent) mimarisi tam olarak bu döngüyü taklit ediyor. Sistem: kod üreten bir ajan sürüsü (synthesis swarm), bu kodu donanım üzerinde (hardware-in-the-loop) gerçek zamanlı derleyip test eden bir doğrulama ajanı ve tüm süreci yöneten bir denetleyici (supervisor) ajandan oluşuyor. Ajanlar yanılıyor, öğreniyor ve kodu iteratif olarak iyileştiriyor.

Ancak bu ajanları geliştirmek ve test etmek oldukça zorlu bir süreçtir. Serrino, bir yapay zekanın ürettiği kernelin “doğru” çalışıp çalışmadığına karar vermenin (özellikle kayan nokta, floating point toleransları nedeniyle) ve performansını güvenilir bir şekilde ölçmenin sanıldığından çok daha karmaşık olduğunu vurguluyor. Basit bir kronometre mantığı önbellek (cache) temizleme sorunları ve başlatma/çalıştırma süreleri arasındaki farklar nedeniyle işe yaramıyor. Ayrıca, bu düşük seviyeli kernel optimizasyonlarını adil bir şekilde test edebilecek olgunlaşmış sektör standartlarında benchmarkların henüz yeni yeni oluştuğunun altı çiziliyor.

Sunumda, Apple M4 işlemciler üzerinde yapılan “KernelBench” testlerinin sonuçları da paylaşılıyor. Ajanlar, orta karmaşıklıktaki problemlerde mevcut derleyicilere (torch.compile) kıyasla ortalama %25 oranında hızlanma (speedup) sağlamayı başarıyor. Ajanın en başarılı olduğu alanlar, birden fazla işlemi tek bir kernelde birleştirme (kernel fusion) veya daha verimli algoritmalar seçme gibi yöntemler. Ancak ajanlar matris çarpımı (matmul) veya FlashAttention gibi insanların aylarca üzerinde çalışarak mükemmelleştirdiği algoritmaları henüz geçemiyor. Sunumun en çarpıcı ve eğlenceli kısımlarından biri ise ajanın “hile” yaptığı test durumu: Ajan, bir test senaryosunda verilerin sadece -1 ile 1 aralığında geleceğini fark edip işlemi tamamen atlayan bir kod yazarak 71.000 kat sahte bir hızlanma elde ediyor. Serrino, bu durumun test sistemlerinde “insan gözetiminin” (human-in-the-loop) hâlâ hayati olduğunu kanıtladığını belirtiyor.

Özetle, yapay zekâ güdümlü kernel optimizasyonu sihirli bir değnek değil, ancak geliştiricilerin alet çantasına eklenen çok güçlü yeni bir araç. Ajanlar, binlerce olası “optimizasyon numarasını” denemekte, mevcut kodu yeni donanımlara taşımakta (porting) harika bir iş çıkarıyor. Gimlet’in gelecekteki hedefi ise ajanları PTX gibi daha da düşük seviyeli montaj (assembly) dillerinde kod yazabilir hale getirmek ve insan gözetimini azaltmak için matematiksel formel doğrulama (formal verification) yöntemlerini sisteme entegre etmektir.

8. Kod tabanlarını ajanlara hazır hale getirmek – Eno Reyes @Factory AI

Bu sunumda, yazılım projelerinin (codebase) otonom yapay zekâ ajanları için nasıl hazır hâle getirilebileceği (“Agent-Ready”) ve yazılım geliştirme sürecinin spesifikasyon ve doğrulama odaklı bir modele nasıl dönüştürüleceği anlatılmaktadır. Factory şirketinin CTO’su Eno Reyes, Andrej Karpathy ve Jason Wei’nin fikirlerine dayanarak, kod yazmanın giderek bir “arama” problemine dönüştüğünü, bir çözümü üretmektense doğruluğunu test etmenin (asymmetry of verification) çok daha kolay olduğunu belirtiyor. Ancak Reyes, yapay zekâ ajanlarının gelişmişliğine rağmen çoğu şirketin kod tabanının bu ajanları destekleyecek yeterli otomatik doğrulama altyapısına sahip olmadığını, insanların tolere edebildiği eksik dokümantasyon veya tutarsız (flaky) testlerin ajanların sistemini tamamen bozduğunu vurguluyor.

Geleneksel yazılım geliştirme süreci, problemi anlama, tasarım yapma, kod yazma ve son olarak test etme şeklinde ilerliyordu. Yeni spesifikasyon odaklı (specification-driven) yaklaşımda ise bu döngü: sınırları belirleme (specify), ajanlar aracılığıyla çözüm üretme (generate), otomatik sistemlerle test etme (verify) ve iyileştirme (iterate) şeklini alıyor. Ajanların kod tabanında başarılı olabilmesi için çok katı ve kuralları net olarak belirlenmiş (opinionated) linterlara, yapay zekanın bozduğu yerleri kesin olarak yakalayacak güvenilir testlere ve net API spesifikasyonlarına ihtiyaç duyuluyor. Ajan, belirtilen kısıtlamalara ve testlere uyan kodu bulana kadar iteratif olarak yeni çözümler üretiyor ve doğrulamadan geçen kodu sisteme entegre ediyor.

Ancak kod tabanlarını bu ajanlara uygun hale getirmek zorlu bir süreçtir. Reyes, bir organizasyonun otomatik doğrulama standartları (örneğin %50–60 gibi düşük test kapsamı, tutarsız derleme süreçleri) zayıfsa, ajanların kod üzerinde paralel olarak çalıştırılamayacağını ve büyük ölçekli modernizasyon veya refactoring projelerinin ajanlara devredilemeyeceğini belirtiyor. Büyük teknoloji devleri (Google, Meta vb.) ile sıradan şirketler arasındaki en büyük farkın, kod tabanına yeni katılan deneyimsiz birinin (veya bir yapay zeka ajanının) sistemi çökertmesini engelleyen o devasa otomatik doğrulama ve test altyapısı olduğunun altı çiziliyor. Bu altyapı olmadan, ajanların rastgele veya sisteme zarar veren kod üretmesini güvenli bir şekilde engellemek imkânsız hale geliyor.

Özetle, otonom yazılım geliştirme sistemleri sihirli bir değnek değildir; başarılı olmaları için etraflarında sıkı bir güvenlik ağına ve küratörlüğü yapılmış bir test ortamına ihtiyaç duyarlar. Reyes’e göre gelecekte yazılım geliştiricilerin rolü, doğrudan manuel kod yazmaktan ziyade; yapay zeka ajanlarının içinde güvenle çalışabileceği sınırları (guardrails) belirlemek, testleri yazmak ve doğrulama ortamını inşa etmek yönüne kayacaktır. Factory’nin amacı da şirketlerin kod tabanlarını analiz edip bu eksikleri ajanlar yardımıyla gidererek projeleri ajanlara hazır hale getirmektir. Sunumda, ajanların çalışmasını sağlayan bu sürekli geri bildirim döngüsüne ve ajanlar için “geliştirici deneyimine” (DevEx) şimdiden yatırım yapan şirketlerin rakiplerine kıyasla yazılım üretim hızlarını 5 ila 7 kat artıracağı öngörülmektedir.

9. Amp Code: Yeni Nesil Yapay Zeka Kodlama, Beyang Liu, Amp Code

Bu sunumda, Sourcegraph Kurucu Ortağı ve CTO’su Beyang Liu, “Amp” adını verdikleri kendi kuralları ve felsefesi olan (opinionated) yenilikçi yapay zekâ kodlama ajanını tanıtmaktadır. Liu, yapay zekanın giderek daha fazla kod ürettiği bu yeni çağda, yazılım geliştirme sürecinin “huşu ve absürtlük” (awe and absurdity) barındıran büyük bir değişime uğradığını belirtiyor. Sadece sıradan bir asistan olmaktan ziyade, geleceğin kodlama alışkanlıklarını bugünden şekillendirmeyi hedefleyen bir araştırma laboratuvarı ürünü olarak konumlandırılan Amp, hem gelişmiş bir terminal arayüzü (TUI) hem de kod editörü (VS Code, JetBrains vb.) eklentisi olarak entegre çalışmaktadır.

Geleneksel yazılım geliştirme sürecinde kod yazmak ana odak iken; Liu, otonom ajanların devreye girmesiyle geliştiricilerin rolünün kod yazmaktan çok, ajanın ürettiği kodu okumaya ve “incelemeye” (code review) kaydığını fark ettiklerini vurguluyor. Bu darboğazı aşmak için Amp, editörü bir kod yazma aracından ziyade bir “okuma aracına” (Read-itor) dönüştürerek, yapılan değişiklikleri hızlıca incelemeyi ve onaylamayı sağlayan özel bir kod inceleme (diff viewer) arayüzü sunuyor. Ajan mimarisinin temelinde bir model ve “araç çağrılarından” (tool calls) oluşan bir döngü yattığını belirten Liu, Amp’in piyasadaki genel yaklaşımlardan ayrıştığı noktalara değiniyor. Örneğin, ajanın bağlam karmaşası (context confusion) yaşamasını önlemek için popüler MCP (Model Context Protocol) entegrasyonlarına bel bağlamak yerine, ajanın geri bildirim döngülerini (feedback loops) kendi kendine kapatmasını sağlayan dar ama çok verimli “özel araç setleri” geliştirmişler.

Ajanların karşılaştığı en büyük zorluklardan biri olan ve sistemin tıkanmasına yol açan “bağlam tükenmesi” (context exhaustion) sorununu çözmek için Amp jenerik alt ajanlar (sub-agents) yerine yüksek derecede uzmanlaşmış alt ajanlar kullanıyor. Kod tabanında hızlı arama yapan “Finder”, sadece çok karmaşık mantıksal sorunlarda devreye giren ve ana ajanın hızını kesmeyen “Oracle”, dış belgeleri okuyan “Librarian” ve büyük yeniden yapılandırmalar yapan deneysel “Kraken” gibi alt ajanlar bu mimariyi oluşturuyor. Ayrıca Liu, kullanıcılara düzinelerce dil modeli seçeneği sunmanın bir “seçim paradoksu” yarattığına inanıyor. Bu nedenle Amp, modeli kullanıcının omuzlarına yüklemek yerine mimariyi “Smart” (akıllı, derinlemesine düşünen) ve “Rush” (hızlı, anlık düzenlemeler yapan) olmak üzere amaca yönelik iki ana ajan etrafında şekillendiriyor.

Özetle, Amp ekibi, kodlama ajanlarının sadece kodu yazan araçlar olmadığını; insanların yapay zekâ ile nasıl kod yazacaklarını baştan öğrenmeleri (relearn how to code together) gereken yeni bir sosyal ekosistem olduğuna inanıyor. Bu ekip içi öğrenmeyi hızlandırmak için, ajanlarla yapılan sorun çözme dizilerinin (threads) ekip arkadaşlarıyla paylaşılabildiği işbirlikçi bir yapı sunuyorlar. Gelişmiş yapay zeka modellerinin maliyetini düşürmek ve sistemi öğrenciler için bile erişilebilir kılmak adına terminal içinde minimal reklamlar (Mini Ad Network) göstermek gibi oyunbozan ve absürt çözümler de deneyen ekip; geleceğin yazılım üretim sürecinin bu tarz amaca özel tasarlanmış, bağlamı ustaca yöneten ve yüksek hızda geri bildirim sağlayan ajan mimarileriyle inşa edileceğini öngörüyor.

10. Neden Ajanlara Olan Heyecan Gerçekliğin Gerisinde Kalabilir– Joel Becker, METR

Bu sunumda, bağımsız bir yapay zekâ güvenlik ve araştırma kuruluşu olan METR’de (Model Evaluation and Threat Research) araştırmacı olarak görev yapan Joel Becker, “Yapay Zekâ Yetenek Ölçümündeki Uçurum” (The AI Capability Measurement Gap) konusunu ele almaktadır. Becker, yapay zekâ modellerinin performansını ölçmek için kullandığımız iki farklı kanıt kaynağı olan geleneksel “kıyaslama testleri” (benchmarks) ile “ekonomik/saha deneyleri” arasında ortaya çıkan çelişkili sonuçlara dikkat çekmektedir. Sunumun temel amacı, yapay zekanın yeteneklerini değerlendirirken sadece laboratuvar ortamındaki sentetik testlere güvenmenin eksikliklerini göstermek ve gerçek dünya üretkenliği üzerindeki fiili etkisini sorgulamaktır.

Geleneksel kıyaslama testleri (SWE-bench vb.) yapay zekânın inanılmaz bir hızla geliştiğini göstermektedir. METR’in kendi araştırmalarına göre, yapay zekâ ajanlarının otonom olarak çözebildiği görevlerin “zaman ufku” (insanların aynı görevi çözmek için harcadığı süre) her 7 ayda bir iki katına çıkarak kusursuz bir üstel büyüme (exponential trend) sergilemektedir. Ancak Becker, bu laboratuvar başarısının gerçek dünyaya ne kadar yansıdığını görmek için 16 son derece deneyimli yazılımcı (Haskell, scikit-learn, HuggingFace Transformers gibi dev açık kaynak projelerine yıllardır katkıda bulunan uzmanlar) ile bir saha deneyi (RCT) gerçekleştirdiklerini belirtiyor. Deneyde yazılımcılar “Yapay Zeka Yasaklı” ve “Yapay Zeka İzinli” (Claude 3.7 Sonnet tabanlı Cursor Pro kullanımı) olarak ikiye ayrıldı. Beklentilerin ve ekonomi uzmanlarının tahminlerinin aksine, çok çarpıcı bir sonuç ortaya çıktı: Yapay zekâ kullanımı, bu uzman geliştiricileri hızlandırmak yerine işlerini tamamlamalarını %19 oranında yavaşlattı.

Becker, kıyaslama testlerindeki yüksek başarı ile saha deneylerindeki bu “yavaşlama” (slowdown) arasındaki uçurumu açıklamak için çeşitli hipotezler sunuyor. Kıyaslama testleri genellikle dar kapsamlı, düşük bağlamlı (low-context) ve net sınırları olan sentetik görevlerden oluşurken, gerçek dünya projeleri devasa (milyonlarca satır kod), karmaşık ve dağınıktır (messy). Uzman geliştiriciler zaten üzerinde çalıştıkları kod tabanını çok iyi bildikleri için yapay zekanın sağladığı jenerik yardımdan fayda sağlayamamış, aksine yapay zekanın ürettiği hatalı veya eksik kodları doğrulamak ve düzeltmek (low AI reliability) için ekstra zaman harcamak zorunda kalmışlardır. Ayrıca, kıyaslama testlerindeki puanlama sistemlerinin (örneğin sadece kodun o an çalışmasına bakılması, projenin geneline uygunluğunun göz ardı edilmesi) yapay zekâ yetenekleri hakkında aşırı iyimser (over-optimism) bir tablo çizdiği vurgulanmaktadır.

Özetle, METR ekibi ve Joel Becker, yapay zekâ modellerinin sentetik ve sınırları çizilmiş kıyaslama testlerini “doygunluğa” (saturation) ulaştırmasının, bu modellerin gerçek dünya ekonomisinde ve uzman işgücünde anında devasa bir üretkenlik artışı yaratacağı anlamına gelmediğini savunuyor. Geliştiricilerin yapay zekayı optimal olarak kullanamaması, karmaşık görevler arası bağımlılıklar ve büyük kod tabanlarındaki bağlam eksiklikleri bu dar boğazın ana nedenlerindendir. Ekip, yapay zekanın gerçek yeteneklerini ölçmek için kıyaslama testlerinin sınırlarını aşan, yüksek bağlamlı ve gerçek saha dağıtımlarını (real deployment scenarios) baz alan yeni ölçüm metriklerine ihtiyaç duyulduğunu öngörmektedir.

11. Claude Code Nasıl Çalışır?, Jared Zoneraich, PromptLayer

PromptLayer kurucusu Jared Zoneraich tarafından sunulan bu workshop, Anthropic’in Claude Code aracının mühendislik prensiplerini ve modern kodlama ajanlarının neden artık “gerçekten çalışmaya” başladığını derinlemesine inceliyor. Zoneraich, başarının sırrının karmaşık yazılım mimarilerinden ziyade “basit mimari ve gelişmiş model yetenekleri” arasındaki denge olduğunu vurguluyor.

İşte kaynaklara dayanarak Claude Code’un çalışma mekanizmasına dair daha detaylı bir teknik döküm:

Mimari Felsefe: “N0” Ana Döngüsü ve Basitlik Zoneraich, geçmişteki ajanların (DAG : Directed Acyclic Graphs gibi) çok katmanlı ve kural tabanlı yapılar yüzünden başarısız olduğunu belirtiyor. Claude Code ise Anthropic içinde “N0” olarak adlandırılan, son derece yalın bir “while” döngüsü üzerine kuruludur.

Döngü Mantığı: Model bir araç çağrısı (tool call) yapar, sistem aracı çalıştırır, sonucu modele geri verir ve model “tamam” diyene kadar bu süreç devam eder.

Model Güveni: Zoneraich, modelin kendi hatalarını fark edip düzeltme (self-correction) yeteneğine güvenilmesi gerektiğini, model kusurlarını aşmak için karmaşık “scaffolding” (iskele) yapılar kurmanın zaman kaybı olduğunu savunuyor.

Araç Seti ve “Evrensel Adaptör” Olarak Bash Claude Code, karmaşık RAG (vektör veritabanı) sistemleri yerine insanın terminalde yaptığı işlemleri taklit eden temel araçları kullanır:

• Bash Gücü: Bash, binlerce kütüphane ve araca erişim sağladığı için sistemin “evrensel adaptörü” olarak tanımlanır. Model gerektiğinde kendi Python betiklerini yazıp çalıştırabilir ve işi bitince bunları silebilir.
• Okuma ve Arama: Dosya okuma (read), grep ve glob gibi araçlar, modelin kod tabanında bir insan gibi gezinmesini sağlar.

Unified Diff (Birleşik Fark): Kod yazarken tüm dosyayı yeniden yazmak yerine sadece değişen kısımları (diff) iletmek, hem hızı artırır hem de bağlam (context) kullanımını optimize ederek hata payını düşürür.

Bağlam Yönetimi (Context Management) ve H2A Ajanların en büyük düşmanı olan “bağlam tükenmesi” (modelin çok fazla bilgiyle dolup performans kaybetmesi) için Claude Code iki ana çözüm sunar:

• H2A (Async Buffer): Girdi/çıktı (I/O) süreçlerini akıl yürütme (reasoning) süreçlerinden ayıran asenkron bir tampon mekanizması.
• Context Compressor: Bağlam dolmaya yaklaştığında (genellikle %92 kapasitede), sistem orta kısımdaki verileri atar ve baş ile son kısımları özetleyerek yer açar.
• Alt Ajanlar (Sub-agents): “Task” aracı ile ana ajan belirli bir araştırma veya doküman okuma işi için kendi bağlamına sahip izole alt ajanlar oluşturabilir. Bu sayede ana döngü gereksiz bilgilerle kirlenmez.

Yönlendirilebilirlik: To-do Listeleri ve Skills To-do Listeleri: Claude Code, yapılacak işleri yapılandırılmış bir plan dahilinde takip eder. Ancak bu liste kodla zorla dayatılmaz; tamamen istem tabanlı (prompt-based) çalışır. Model, bir sonraki adımı bu listeye bakarak kendisi belirler.

Skills (Beceriler): Geliştiriciler, sisteme özel “beceriler” (örneğin tasarım rehberleri veya dokümantasyon standartları) ekleyerek sistem istemini (system prompt) dinamik olarak genişletebilir.

Test, Eval ve Gelecek Öngörüleri Zoneraich, ajanların performansını ölçmek için geleneksel benchmarkların (puanlamaların) yetersiz olduğunu, bunun yerine “Agent Smell” (ajanın kaç kez deneme yaptığı, araçları ne sıklıkla çağırdığı gibi metrikler) kavramına odaklanılması gerektiğini belirtiyor.

Headless SDK: Claude Code’un sadece bir terminal aracı değil, aynı zamanda GitHub Actions gibi CI/CD süreçlerine entegre edilebilen “başsız” (headless) bir yapı olarak kullanılması, otomasyonda yeni bir dönemi işaret ediyor.

Sonuç: Gelecekte her ajanın (Cursor, Codex, Amp vb.) kendine has bir felsefesi (tadı) olacağı; ancak kazananın modele en çok güvenen ve en basit mühendislik çözümünü sunan yaklaşım olacağı öngörülüyor.

12. Paralel Ajanlar Kullanarak Büyük Ölçekli Yeniden Yapılandırmaları Otomatikleştirme - Robert Brennan, OpenHands

Sunum, yapay zekanın yazılım dünyasındaki gelişimini yıllara göre özetleyerek başlıyor:

• 2022: Bağlamdan habersiz, sadece istenen algoritmayı yazan kod parçacıkları (ChatGPT dönemi).
• 2023: IDE içinde çalışan, bağlamın farkında olan kod tamamlama araçları (GitHub Copilot dönemi).
• 2024: Belirli, küçük ve atomik görevleri (örn. bir hata düzeltme, bir uç nokta ekleme) kendi başına yapabilen otonom ajanlar (Devin, OpenHands).
• 2025 (Odak Noktası): Büyük ölçekli işler için Paralel Ajanlar ve Ajan Orkestrasyonu (Agent Orchestration).

2. Neden “Orkestrasyon” ve Paralel Ajanlara İhtiyacımız Var? Tek bir yapay zekâ ajanına devasa bir görev (örneğin dev bir monolitik yapıyı mikroservislere bölmek) vermek işe yaramamaktadır. Bunun sebepleri:

• Teknik Sorunlar: Bağlam penceresinin (context window) dolması, hataların katlanarak artması (compounding errors) ve yapay zekanın “tembellik” yapıp işi yarım bırakması.
• İnsani Sorunlar: Ajanın 60.000 satırlık tek bir “Pull Request (PR)” göndermesi durumunda hiçbir insanın bunu inceleyemeyecek olması. Görevin iyi tanımlanamaması ve ajanların projeye dair “insani sezgilere” sahip olmaması.
• Çözüm: Büyük görevleri küçük, tekil ajanların yapabileceği parçalara bölmek ve bu ajanları paralel olarak yönetmek (Orkestrasyon).

3. Orkestrasyonun Kullanım Alanları Bu yöntem, yüksek oranda tekrar edilebilir ve otomatikleştirilebilir görevler için mükemmeldir:

• Bakım (Maintenance): Binlerce koddaki güvenlik açıklarının (CVE) taranıp her biri için ayrı ajanlarla onarım yapılması.
• Modernizasyon: Tüm kod tabanına Python 3 tip açıklamalarının (type annotations) eklenmesi.
• Geçişler (Migration): Büyük bir projenin Redux’tan Zustand’a veya Spark 2'den Spark 3'e geçirilmesi.
• Teknik Borç (Tech Debt): Kullanılmayan kodların temizlenmesi, loglama veya hata yakalama eksiklerinin giderilmesi.

4. Görevleri Parçalama (Decomposition) Stratejileri Devasa bir iş, ajanlara nasıl dağıtılır?

• Parça Parça (Piece by Piece): Dosya dosya veya klasör klasör ilerlemek (basit sözdizimi güncellemeleri için idealdir).
• Bağımlılık Ağacı (Dependency Tree): Hangi dosyanın hangisine bağlı olduğunu haritalandırıp, hiçbir şeye bağlı olmayan “yaprak” (leaf) dosyalardan başlayarak yukarı doğru ilerlemek (Büyük geçişler için idealdir).
• İskelet ve Yineleme (Scaffold and Iterate): Eski ve yeni sistemin aynı anda çalışabilmesi için geçici bir yapı (scaffold) kurmak, tüm modülleri sırayla yeniye geçirmek ve en sonunda eski yapıyı yıkmak.

5. Ajanlar Arası Bilgi (Bağlam) Paylaşımı Ajanların aynı hatayı tekrar tekrar yapmamaları için öğrendiklerini paylaşmaları gerekir.

• Yanlış yöntem: Tüm geçmişi her ajanla paylaşmak (maliyeti artırır, bağlamı kirletir).
• Doğru yöntemler: Ajanların okuyup yazabileceği paylaşımlı bir AGENTS.md (veya benzeri) dosyası tutmak veya doğrudan “Mesajlaşma (Message Passing)” ile ajanların birbirleriyle iletişim kurmasını sağlamak.

6. Uygulamalı Demo (CVE Onarımı) Sunumun ikinci yarısında Brennan, OpenHands SDK’sını kullanarak pratik bir gösterim yapıyor:

• Bir GitHub reposu alınıyor.
• Trivy güvenlik tarayıcısı kullanılarak koddaki güvenlik açıkları (CVE’ler) bulunup bir JSON dosyasına kaydediliyor.
• Sistem, JSON dosyasındaki her bir güvenlik açığı için paralel olarak ayrı bir yapay zeka ajanı başlatıyor.
• Ajanlar, kendilerine atanan güvenlik açığını araştırıyor, kodu düzeltiyor ve GitHub’da bağımsız olarak birer Pull Request (PR) oluşturuyor.
• Bu sayede, insan mühendisin sadece açılan PR’ları inceleyip onaylaması yeterli oluyor; onarım süreci devasa ölçüde hızlanıyor.

Video, yazılım mühendisliğinde yapay zekanın “bana şu kodu yaz” seviyesinden çıkıp “binlerce dosyadan oluşan projemi koordine çalışan ajan ordularıyla yeni bir versiyona geçir” seviyesine ulaştığını ve bunun nasıl inşa edileceğini anlatmaktadır.

13. Yapay Zeka Ajanları için Kimlik , Patrick Riley & Carlos Galan, Auth0

Sunum yapay zekâ ajanlarının (özellikle arka planda kendi başına çalışan “headless” ve otonom ajanların) dış uygulamalarla ve API’lerle etkileşime girerken nasıl güvenli bir şekilde yetkilendirileceğini göstermektir.

Yapay zeka modelleri artık sadece sohbet botu olmaktan çıkıp kullanıcılar adına işlem yapan otonom ajanlara dönüşmektedir. Bu durum, veri sızıntısı veya yetkisiz işlemler gibi yeni güvenlik risklerini (OWASP LLM Top 10 listesinde belirtilen açıklar gibi) beraberinde getirmektedir. Çözüm, yapay zekanın tıpkı bir insan gibi standartlara uygun bir kimlik doğrulama ve yetkilendirme sürecinden geçmesidir.

Auth0, yapay zeka ajanlarının güvenliği için şu dört temeli benimsiyor:

• YZ kim olduğumu bilmeli: ajan, anonim olarak değil, belirli bir kullanıcının kimliğini üstlenerek hareket etmelidir.
• YZ benim adıma API çağrıları yapabilmeli: Ajanın dış servislere (Google, Slack, özel şirket API’leri vb.) kullanıcı adına erişebilmesi gerekir.
• YZ benden onay isteyebilmeli: Hisse senedi almak veya para transferi yapmak gibi “riskli” işlemlerde, ajan kendi başına karar vermemeli, kullanıcıdan anlık onay istemelidir.
• Erişim ince ayarlı (fine-grained) olmalı: Ajan sadece o anki görev için gereken minimum verilere erişebilmelidir.

Atölyede bu prensipleri hayata geçirmek için yeni piyasaya sürülen iki ana teknoloji gösteriliyor:

• Token Vault (Token Kasası): Yapay zekâ ajanının farklı platformlara bağlanmak için ihtiyaç duyduğu “access” (erişim) ve “refresh” (yenileme) tokenlarını güvenli bir şekilde saklayan ve yöneten mimari.
• Async Auth (Asenkron Yetkilendirme / CIBA standardı): Ajan otonom olarak çalışırken yüksek yetki gerektiren bir işleme denk geldiğinde, işlemi duraklatır ve kullanıcının mobil cihazına (örneğin Auth0 Guardian uygulaması üzerinden) bir “Push Bildirimi” gönderir. Kullanıcı telefonundan “Onayla” dediği anda ajan işlemine kaldığı yerden devam eder.

Sunumun diğer yarısında Patrick Riley Anthropic (Claude) ve Model Context Protocol (MCP) kullanarak kurgusal bir borsa uygulaması olan “DemoTradePro”yu sıfırdan inşa ediyor. Bu demoda şu adımlar izleniyor:

• Önce ajan sadece halka açık hisse fiyatlarını getirebiliyor.
• Ardından kullanıcı sisteme giriş yapıyor (Login) ve ajan kullanıcının özel portföy verilerini okuyabiliyor.
• Son olarak Async Auth devreye sokuluyor: Kullanıcı ajana “Benim için X hissesinden satın al” komutunu veriyor. Ajan işlemi doğrudan yapmak yerine kullanıcının telefonuna bir onay ekranı gönderiyor. İşlem ancak telefondan onaylandıktan sonra gerçekleşiyor.

Özetle, gelişmiş yapay zekâ ajanlarının kurumsal sistemlerde ve hassas verilerle çalışırken nasıl kontrol altında tutulabileceği, yetkilendirme sınırlarının nasıl çizileceği ve riskli işlemlerde insan onayının (human-in-the-loop) teknik olarak sisteme nasıl entegre edileceği aktarılmaktadır.

14. ⭐ METR Uzun Süren Görevleri ve Deneyimli Açık Kaynak Geliştiricilerin Verimliliğini Nasıl Ölçüyor?, Joel Becker, METR

Bu sunum, METR (Model Evaluation and Threat Research) araştırmacıları tarafından yapılan ve 2025 başlarındaki yapay zekâ araçlarının yazılım geliştiricilerin üretkenliğine etkilerini ve gelecekteki yapay zekâ yeteneklerini (time horizons) derinlemesine inceleyen bir araştırmaya dayanıyor.

Sunum, sektördeki genel kanının aksine, modern yapay zekâ araçlarının deneyimli geliştiricileri tarafından her zaman hızlandırılmadığını; hatta bazen yavaşlattığını veri odaklı bir yaklaşımla açıklıyor.

İşte araştırmanın öne çıkan bulgularına ve modern yapay zeka sistemlerinin mevcut durumuna dair detaylı bir teknik döküm:

Araştırmanın Temel Bulgusu: %19'luk Üretkenlik Düşüşü Araştırmacılar, deneyimli açık kaynak (open-source) geliştiricileri üzerinde rastgele kontrollü bir deney (RCT) gerçekleştirdi. Sonuçlar oldukça şaşırtıcıydı:

• Yapay zeka araçlarına (Cursor, GitHub Copilot, web tabanlı LLM’ler) erişimi olan geliştiricilerin karmaşık görevleri tamamlama süresi, bu araçları kullanmayanlara kıyasla %19 daha uzun sürdü.
• Bu durum, yapay zekanın “anında devasa üretkenlik artışı sağlayacağı” yönündeki pazar beklentileriyle ve geliştiricilerin kendi öznel “hızlandım” hissiyatlarıyla (hype) doğrudan çelişiyor.

“J-Eğrisi” (J-Curve) ve Araçlara Aşinalık Geliştiricilerin yapay zeka ile yavaşlamasının temel nedenlerinden biri adaptasyon sürecidir:

• Öğrenme Maliyeti: Geliştiriciler yeni bir aracı (örneğin Cursor) öğrenirken ilk başlarda zaman kaybederler (J eğrisinin dibi).
• Sınırları Keşfetme: Aracı 50 saatten fazla kullanan geliştiricilerde bile beklenen “mucizevi” sıçrama görülmüyor. Çünkü deneyim kazanan bir geliştirici aslında aracın neyi yapamayacağını öğreniyor ve yapay zekâya devrettiği görevleri daha iyi sınırlandırıyor.

Büyük Kod Tabanları (Legacy Codebases) ve “Örtük Bilgi” (Tacit Knowledge) Engeli Yapay zeka araçlarının farklı projelerde farklı sonuçlar vermesinin mimari bir sebebi var:

• Sıfırdan Projeler vs. Eski Projeler: Yapay zekâ, sıfırdan yazılan (greenfield) projelerde veya izole fonksiyonlar (LeetCode tarzı algoritmalar) yazmada oldukça başarılı. Ancak 10 yıllık devasa açık kaynak projelerinde bocalıyor.
• Bağlam Eksikliği: Eski projeler, sadece koda bakarak anlaşılamayacak; geliştiricilerin zihninde yer etmiş “örtük bilgilere” (tacit knowledge) dayanır. Yapay zekanın projenin tarihsel bağlamını ve mimari kararlarını bilmeden karmaşık sistemlerde hata düzeltmesi (bug fix) yapması ya da büyük PR’lar (Pull Request) oluşturması şu an için verimsizdir.

Gelecek Öngörüleri (Time Horizons) ve Bilişim (Compute) Ölçeklendirmesi Araştırma, yapay zekanın otonom olarak tamamlayabildiği görevlerin süresini tahmin etmek için log-doğrusal (log-linear) bir projeksiyon kullanıyor:

• Bilişim Çarpanı: Modellerin yetenek artışı, doğrudan harcanan bilişim (compute) gücüyle orantılıdır. Eğer algoritmik ilerlemeler durur veya veri/donanım/enerji darboğazları (bottlenecks) yaşanırsa, yapay zekâ gelişim eğrisi düzleşecektir.
• Bu duraklama ihtimali, “Yapay Zekâ Tekilliği” (Singularity) veya tüm AR-GE süreçlerinin tamamen otomatize edilmesi gibi vizyonların tahmin edilenden çok daha uzun süreceği (hatta on yıllar alabileceği) anlamına gelir.

Yeni Test Alanları: Veri Bilimi (Data Science) Neden Çok Zor? Yapay zeka sadece yazılım mühendisliğinde değil, veri bilimi gibi diğer karmaşık alanlarda da test ediliyor:

• Açık Uçlu Görevler: Modeller basit bir SQL sorgusu yazmakta çok iyidir. Ancak kirli bir veritabanını alıp, içindeki tutarsızlıkları (outliers) temizleyip, doğru “özellik çıkarımını” (feature curation) yaparak yöneticilere sunulacak mantıklı bir analiz raporu hazırlamada tamamen çuvallamaktadırlar. Gerçek dünya verisi çok karışıktır ve henüz hiçbir otonom ajan bunu uçtan uca çözecek bilişsel (cognitive) yeteneğe sahip değildir.

Sonuç: Yapay Zekâ Ne İşe Yarıyor? Araştırmanın nihai mesajı yapay zekânın işe yaramaz olduğu değil, yanlış beklentilerle yönetildiğidir. İnsanlar bir görev için harcanacak süreyi genellikle azımsama (optimism bias) eğilimindedir. Yapay zeka günümüzde bir otonom mühendis olmaktan ziyade, sınırları iyi çizildiğinde ve doğru bağlam (context) sağlandığında faydalı olabilen bir asistan konumundadır. Gelecekte başarı, modeli her şeyi yapmaya zorlamak yerine, insan-yapay zekâ işbirliğini (iteration loop) en akılcı şekilde tasarlayan sistemlerden geçecektir.

15. Kod Modu: Bırakın kod konuşsun, Sunil Pai, Cloudflare

Cloudflare’den Sunil Pai’nin yapay zekâ aracılarının (AI agents) sistemlerle nasıl etkileşime girdiği anlatılmaktadır.

1. Geleneksel Yöntemin (Tool Calling) Çöküşü Büyük Dil Modelleri (LLM) ile uygulama geliştirirken, modele araçlar (tools) verilir ve JSON formatında gidiş-dönüş (back-and-forth) mesajlaşmalarla işlemler yapılır. Ancak Cloudflare gibi binlerce API uç noktası (endpoint) olan devasa sistemlerde bu yöntem çalışmaz. Tüm API’leri modele bağlamaya kalkmak, milyonlarca “token” harcanmasına, sistemin çok yavaşlamasına ve bağlamın (context) bozulmasına neden olur.

2. Çözüm: “Kod Modu” (Code Mode) Pai ve ekibi, modelle JSON üzerinden konuşmak yerine farklı bir yol deniyor: modele doğrudan kodu (genellikle JavaScript) yazdırmak ve bu kodu bir ortamda tek seferde çalıştırmak.

• Dramatik Optimizasyon: 2500'den fazla API uç noktasını modele yüklemek yerine, sadece 2 araç veriliyor: search (ilgili API belgesini bulmak için) ve execute (yazılan kodu çalıştırmak için). Bu sayede token kullanımı 1,2 milyondan yaklaşık 1000'e (%99,9) düşüyor.
• Kodun Gücü: Kod, kendi içinde döngüleri (loops), durumu (state) ve sıralamayı (sequencing) barındırır. Model arka arkaya 8 kez API çağırmak yerine, bu mantığı içeren tek bir kod yazar ve sistem bunu bir kerede çalıştırır.

3. Bu Sadece Bir Optimizasyon Değil, Yeni Bir Etkileşim Modeli Pai, bunun sadece sistemi hızlandırmadığını, bilgisayarlarla iletişim kurma şeklimizi değiştirdiğini belirtiyor. Geçmişte programcılar kod yazar, diğer tüm insanlar ise arayüzleri (butonlar, formlar vb.) kullanırdı. Ancak LLM’ler bu sınırı yıkıyor. Artık yapay zekâ, kullanıcının niyetini anlıyor ve arka planda bunu gerçekleştirecek kodu anında yazıp çalıştırabiliyor.

4. Çarpıcı Bir Demo: Tic-Tac-Toe Bir iş arkadaşının geliştirdiği beyaz tahta uygulamasında modele “Benimle Tic-Tac-Toe oyna” deniyor. Modelin normalde sıfırdan bir oyun uygulaması yazması beklenirken, model bunun yerine ekrandaki mevcut durumu (çizgileri ve kullanıcının çizdiği “X” işaretini) okuyup analiz ediyor ve sadece “O” çizmesini sağlayan bir kod üretiyor. Yani model yeni bir uygulama yaratmıyor, mevcut sistemin durumuna sızıp ona göre kodla hareket ediyor.

5. Güvenlik ve Mimari (The Harness) Yapay zekanın kendi kendine kod yazıp çalıştırması güvenlik riskleri taşır. Bunun için “Harness” (Korumalı Alan/Sandbox) adı verilen bir yapı geliştirilmiş.

• Bu alan, modele başlarken hiçbir yetki vermez (Start powerless).
• Yetkiler (örneğin, sadece belirli API’lere erişim) modele açıkça ve sınırlandırılarak verilir.
• Modelin dış dünyaya izinsiz veri göndermesi (outgoing fetch) engellenir.
• Yazılan ve çalışan her kod satırı tam bir izlenebilirlik (observability) ile kaydedilir.

6. Geleceğin Yazılımları: Kişiye Özel Arayüzler Pai sunumunu şu vizyonla bitiriyor: Gelecekte her kullanıcı aynı statik web sayfasını veya arayüzü görmeyecek. Yapay zeka, elindeki verileri ve kullanıcının o anki niyetini kullanarak, sadece o kullanıcıya ve o ana özel geçici kodlar ve arayüzler (per-user software) üretecek. İnsanların sistemlerle temel iletişim aracı artık sabit butonlar değil, yapay zekanın onlar adına yazıp çalıştırdığı kodlar olacak.

16. MCP’nin Geleceği, David Soria Parra, Anthropic

1. 2026'nın Odak Noktası: Üretimdeki “Bilgi İşçisi” Aracıları 2024 ve 2025 yılları genellikle “kodlama aracıları” (coding agents) dönemiydi. Bu araçlar genellikle yerel (local) ortamda çalışır, yazdıkları kodları derleyicilerle anında test edip hatalarını düzeltebilirdi. Ancak Parra’ya göre 2026, aracıların üretime (production) geçtiği ve finansal analiz, pazarlama gibi “bilgi işçisi” (knowledge worker) rollerini üstleneceği yıl olacak. Bu yeni nesil aracıların tek ve en büyük ihtiyacı “Bağlantı” (Connectivity) olacaktır (SaaS uygulamalarına, şirket içi veri tabanlarına ve ortak sürücülere bağlanmak).

2. Doğru İş İçin Doğru Araç: Bağlantı Yığınları (The Connectivity Stack) Geleceğin aracılarını inşa ederken tüm bağlantı sorunlarını çözecek tek bir sihirli değnek yoktur. Üç farklı yapı bir arada kullanılmalıdır:

• Yetenekler (Skills): Alana özgü bilgiler ve tekrarlanabilir, özel talimatlardır.
• Komut Satırı (CLI) / Bilgisayar Kullanımı: Yerel aracıların GitHub, Git vb. araçları kullanması için mükemmeldir, model bu araçları zaten eğitim verilerinden (pre-training) bilir.
• MCP (Model Context Protocol): Zengin anlambilim (semantics), platform bağımsızlığı, uzun süren görevler, kurumsal yetkilendirme (auth) ve politikalar (governance) gerektiğinde araç ile sistemler arasında kurulan asıl “bağlantı dokusudur”.

3. İstemci (Client) Tarafındaki Devrim: Keşif ve Kod Modu Modelin çalıştığı istemci tarafında (harness) mevcut yapının hantallığını aşmak için iki kritik gelişme yaşanmaktadır:

• Kademeli Keşif (Progressive Discovery / Tool Search): Bütün araçları (tools) modelin bağlam penceresine (context window) baştan yüklemek 50.000'den fazla token harcayarak sistemi yavaşlatır. Bunun yerine modele bir “Araç Arama” yeteneği verilir. Model sadece o an ihtiyacı olan araçları talep eder ve bağlam penceresi 9.000 token seviyelerine düşer.
• Programatik Araç Çağrısı (Code Mode / REPL): Modelin sırayla bir aracı çağırıp (JSON ile), cevabı bekleyip, sonra diğerini çağırması çok yavaştır. Bunun yerine modele izole bir kod çalıştırma ortamı (REPL, V8 vb.) verilir. Model, arka planda API’leri çağıran, verileri filtreleyen ve istenen formatta sunan tek bir mini betik (script) yazar. Bu, etkileşimi muazzam hızlandırır.

4. Sunucu (Server) Tarafında Aracıya Özel Tasarım Geliştiricilerin sadece mevcut REST API’lerini alıp basitçe MCP’ye dönüştürmekten (wrapper) vazgeçmesi gerekmektedir. Sunucular doğrudan “bir yapay zekâ aracısı veya insan bunu nasıl en iyi kullanır?” mantığıyla tasarlanmalıdır. Gerektiğinde karmaşık işlemler için sunucu tarafında da bir kod çalıştırma alanı (sandbox) sunulmalı ve metinlerin yetersiz kaldığı durumlarda ağ üzerinden aracıya doğrudan zengin kullanıcı arayüzleri (MCP Apps / etkileşimli grafikler) gönderilmelidir.

5. Protokol (MCP) Seviyesindeki İyileştirmeler (2026 Yol Haritası) Aylık 110 milyondan fazla indirmeye ulaşan MCP ekosistemi, 2026'da protokolün çekirdeğini güçlendirecektir:

• Durumsuz Taşıma (Stateless Transport): Mevcut sürekli bağlantı modeli (SSE) büyük ölçekli bulut/k8s sistemlerinde zorluk yaratmaktadır. Daha kolay ölçeklenebilen “Stateless” bir yapıya geçilecektir.
• Çapraz Uygulama Erişimi (Cross-App Access): Kurumsal kimlik doğrulama sistemleriyle (Okta, Google vb.) entegre edilerek, aracının bir kez oturum açıp yetkisi dahilindeki tüm sistemlere sorunsuzca erişmesi sağlanacaktır.
• Otomatik Keşif (Server Discovery): Ajanların web sitelerini ziyaret ettiklerinde orada bir MCP sunucusu olduğunu (.well-known dosyaları aracılığıyla) otomatik olarak keşfedebilmeleri sağlanacaktır.

Sonuç: Soria Parra sunumunu, 2026'da “En iyi yapay zeka aracılarının tek bir yönteme bağlı kalmayacağını; CLI, MCP ve Yetenekleri (Skills) ihtiyaçlarına göre bir arada ve kusursuz bir şekilde harmanlayarak kullanacağını” belirterek ve bu vizyona uygun altyapıyı inşa ettiklerini gösteren etkileşimli grafik demolarıyla tamamlamaktadır.

17. Sürtünme, Sizin Yargınızdır, Armin Ronacher & Cristina Poncela Cubeiro, Earendil

1. Psikoloji Problemi: Hız Tuzağı ve İnceleme (Review) Çıkmazı Yapay zeka kodlama araçlarının (agent) yaygınlaşmasıyla sektördeki beklentiler tamamen “daha hızlı üretime” odaklandı. Ancak ajanların çok hızlı çalışması, gerçek bir ilerleme yanılsaması yarattı.

• Düşünmeyi Bırakmak: Kodun anında üretilmesi, mühendislerin durup sistemi tasarlamayı ve “bekle” demeyi bırakmasına yol açtı. Hız arttıkça kalite ve vizyon kaybolmaya başladı.
• Büyüme (Amplification) Sorunu: Eskiden kodu yazan da inceleyen (review) de insandı ve sistem dengeliydi. Şimdi devasa miktarda kod üreten ajanlar var, ancak bu kodun yasal ve mimari sorumluluğu (liability) taşıyamayan bu ajanlar yüzünden hala çok az sayıdaki insanın omuzlarında.
• Bu durum, insanların aşırı yüklenmesine ve kod incelemelerinin giderek atlanmasına veya baştan savma (rubber-stamping) yapılmasına neden olmaktadır.

2. Mühendislik Problemi: Ajan Kodlarının Erozyonu (Drift) ve Karmaşa Ajanlar insan mühendisler gibi uzun vadeli düşünmezler; temel hedefleri kodun o an çalışmasını sağlamak ve testleri geçmektir.

• Hataları Gizleme: Ajanlar genellikle kodu çalıştırabilmek için hataları yutar (catching exceptions broadly) veya bulamadıkları dosyalarda varsayılan ayarlara (defaults) dönerler. Bu, arkada sessizce çalışan ama aslında çökmüş olan çok kırılgan (brittle) sistemler yaratır.
• Kütüphaneler (Libraries) vs. Ürünler (Products): Ajanlar, sınırları net çizilmiş, API’si belli olan “Kütüphane” yazımında çok başarılıdır. Ancak UI, veritabanı, izinler (permissions) ve ödeme (billing) sistemlerinin iç içe girdiği “Ürün” geliştirmede bocalarlar. Ajanın bağlam penceresi (context window) ürünün tamamını görmeye yetmez; bu nedenle yerel olarak mantıklı görünen ama küresel çapta sistemi bozan kodlar yazarlar.
• Karmaşa Döngüsü (Entropy): Ajanlar kodu karmaşıklaştırdıkça, yeni görevlerde kendi yazdıkları eski kodları hatırlamakta ve bulmakta zorlanırlar. Bu da kod tekrarına ve daha büyük bir karmaşaya yol açar.

3. Çözüm: Kod Tabanını Ajanlar İçin Bir “Altyapı” Olarak Tasarlamak Geçmişte sistem mimarisi nasıl tasarlandıysa, günümüzde de kod tabanları ajanların kolayca okuyup anlayabileceği (agent-legible) bir “altyapı” olarak baştan tasarlanmalıdır.

• Modülerleştirme: Kod akışı, ajanın sistemi bozmadan sadece bir noktaya odaklanabileceği net sınırlarla ayrılmalıdır.
• Gizli Sihir Yok (No Hidden Magic): ORM (Object-Relational Mapping) gibi arka planda ne yaptığını gizleyen yapılar yerine, ajanın niyeti açıkça görebileceği (örn. SQL kullanarak) yapılar tercih edilmelidir. Ajan göremediği bir kod mantığına saygı duyamaz.
• Mekanik Zorlamalar (Mechanical Enforcement): Tüm hataları yakalayan boş catch blokları yasaklanmalı, SQL sorguları tek bir soyutlama katmanında toplanmalı ve UI için dinamik olmayan, tutarlı bileşenler kullanılmalıdır. Ayrıca ajanların dosyalar arasında kaybolmasını önlemek için benzersiz fonksiyon isimleri (unique function names) zorunlu kılınmalıdır.

4. Ne Zaman Hızlı, Ne Zaman Yavaş Olunmalı? Hız her zaman faydalı değildir. Konuşmacılar hızın ne zaman iyi, ne zaman tehlikeli olduğunu şu şekilde ayırmaktadır:

• Yüksek Fayda (Hızlı Olun): Ürün yönlerini keşfetmek, prototip üretmek, başarısız testleri (CI) ve hataları ayıklamak (debugging), ilk taslağı oluşturma süresini kısaltmak.
• Düşük Fayda (Yavaşlayın): Güvenilirlik, tutarlılık, uzun ömürlü sistem mimarisi ve ekibin ortak anlayış geliştirmesi gereken durumlar. Ajanlar ile teknik borç (technical debt) birikimi aylardan günlere inmiştir; bu yüzden kodu daha sonra temizleme fikri artık çalışmamaktadır.

Sonuç: “Sürtünme (Friction) Düşman Değil, Sizin Yargı Yeteneğinizdir” Sunum, sektörün pazarlama sloganı haline gelen “sürtünmesiz ürün çıkarma (ship without friction)” mantığına şiddetle karşı çıkarak sona ermektedir. Konuşmacılara göre sürtünme; geliştiricinin kodun maliyetini hissetmesini, tasarımı sahiplenmesini ve sorumluluk almasını sağlayan baskıdır. Ajanlar bu baskıyı veya stresi hissedemez. Veritabanı migrasyonları, yetki/güvenlik değişiklikleri (Auth) veya geriye dönük uyumsuz API güncellemeleri gibi kritik anlarda sisteme bilinçli olarak “sürtünme” (insan incelemesi ve onayı) eklenmelidir. Mühendisler, ancak bu sürtünme noktalarını yeniden inşa ederek kontrolü ellerinde tutabilirler.

18. Koşum (Harness) Mühendisliği: İnsanların Yönlendirdiği, Ajanların Yürüttüğü Bir Yazılım Nasıl Oluşturulur?, Ryan Lopopolo, OpenAI

1. Paradigma Değişimi: “Kod Bedava”, İnsan Zamanı İse Kıt Kaynak Yapay zeka modellerinin (GPT-4 ve sonrası) gelişimiyle birlikte yazılım geliştirme sürecindeki temel darboğaz (bottleneck) değişti. Artık kodu yazmak veya “uygulama” (implementation) aşaması en zor kısım değil.

• Kod Artık Bedava: Kod üretmek, yeniden düzenlemek (refactor) veya silmek artık maliyetsiz bir işlemdir. Bu nedenle “kod yazmak” artık sınırlı bir kaynak olarak görülmemelidir.
• Herkes Bir “Staff Engineer”: Günümüzde her mühendis, 7/24 çalışmaya hazır binlerce ajan (agent) kapasitesine sahip birer yönetici konumundadır.
• Yeni Kıt Kaynaklar: Artık sektördeki asıl sınırlı kaynaklar şunlardır: İnsan zamanı, insanın/modelin dikkati (attention) ve modellerin bağlam penceresi (context window). İnsanların senkronize olarak ajanları beklemesi veya onların kodlarını manuel incelemesi, sistemin önündeki en büyük engeldir.

2. Mühendislik Problemi: Kalitesiz Kod (Slop) Üretimi ve Bağlam Sınırları Ajanlar inanılmaz bir hızla trilyonlarca satır kod üretebilir, ancak neyin “iyi bir iş” olduğunu kendi başlarına tanımlayamazlar.

• “İyi İş”in Tanımsızlığı: Bir kodun çalışması, onun bakımı yapılabilir, güvenli veya mimariye uygun olduğu anlamına gelmez. Ajanlar, kısıtlamalar olmadan kendi hallerine bırakıldıklarında, projeyi çöpe çevirecek kadar kalitesiz ve baştan savma kod (“slop”) üretebilirler.
• Bağlam (Context) Sınırları: Ajanlara devasa bir kod tabanını (repository) tek seferde vermek başarısızlıkla sonuçlanır. Modelin dikkati dağılır ve mantıksız hatalar yapar. Ajana sadece ihtiyacı olan kadar bilgiyi sunmak zorunludur.
• Kod İnceleme (Code Review) Çıkmazı: Ajanların ürettiği binlerce satırlık kodu insanların manuel olarak incelemesi, insan zamanını boşa harcamaktır. Bu durum, insanların pes edip hatalı kodları doğrudan onaylamasına yol açar.

3. Çözüm: “Koşum/Çerçeve Mühendisliği” (Harness Engineering) İnsanların kodu yazdığı dönem kapanmıştır. Mühendislerin yeni görevi; ajanları sınırlandıran, yönlendiren ve denetleyen “koşumlar” (harnesses) veya sistematik korkuluklar (guardrails) inşa etmektir. İnsanlar yönlendirir (steer), ajanlar uygular (execute).

• Sistematik Korkuluklar (Guardrails): Ajanların kalitesiz kod üretmesini engellemek için kurallar kodlanmalıdır. Örneğin, kod formatlama, linting ve test süreçleri tamamen otomatikleştirilmeli ve ajan, bu testleri geçmeden kodu insana sunamamalıdır (“Slop kabul etmeyin!”).
• Ajanları Ajanlarla Denetleme: İnsanları kod inceleme yükünden kurtarmak için CI/CD süreçlerine “İnceleyici Ajanlar” (Reviewer Agents) eklenmelidir. Güvenlik, mimari veya performans kurallarını kontrol eden özel ajanlar, kodu insanlardan önce denetlemelidir.
• Açık Beklentiler ve Dokümantasyon: Ajanlar zihin okuyamaz. Mimari Karar Kayıtları (ADR’ler), ürün gereksinim dokümanları ve net yönlendirmeler (prompt’lar) ajanların “iyi bir iş” çıkarması için zorunlu altyapılardır.

4. Pratik Uygulama: Ajanları Ölçeklendirme ve Ekip Yönetimi Sunumun Soru-Cevap bölümünde, ajanların gerçek dünyada büyük kod tabanlarında nasıl yönetileceğine dair pratik stratejiler paylaşılmıştır:

• Personalar Oluşturma: Tek bir genel ajan yerine, belirli görevlerde uzmanlaşmış ajanlar (Örn: Frontend Mimarı, Güvenlik Uzmanı, QA Mühendisi) kullanılmalıdır. Her persona, kendi uzmanlık alanına göre kodun farklı bir yönünü eleştirir ve geliştirir.
• Kademeli Bilgi Sunumu (Progressive Disclosure) ve Ayrıştırma: Ajanların başarılı olması için kod tabanı küçük, bağımsız ve net sınırlara sahip parçalara ayrılmalıdır. Uzun dosyalar yerine kısa, ajanın kolayca kavrayabileceği (agent-legible) dosyalar oluşturulmalıdır.
• Çöp Toplama Günü (Garbage Collection Day): Ajanlar hızla çalışırken illaki arkalarında karmaşa bırakırlar. Ekip, her haftanın bir gününü (örneğin Cuma günleri) sadece ajanların ürettiği kalitesiz kodları (slop) tespit etmeye ve bu kodların bir daha üretilmemesi için sistemdeki kuralları/prompt’ları güncellemeye ayırmalıdır.

Sonuç: “Yazılım Mühendisinin Yeni Rolü: Uygulayıcı Değil, Orkestra Şefi” Sunum, yazılım mühendisliğinin geleceğinin kod yazmakta değil, sistem tasarımı ve yönlendirmede yattığı mesajıyla sona ermektedir. Kodu yazmak (implementation) artık en alt düzey iştir. İnsan mühendisler, sistemin vizyonunu belirlemeli, ajanların çalışabileceği pürüzsüz altyapıları (harness) inşa etmeli ve yüksek kaldıraçlı (high-leverage) stratejik görevlere odaklanmalıdır. İnsanların değeri klavyede ne kadar hızlı olduklarıyla değil, ajan ordularını hedefe ne kadar doğru yönlendirebildikleriyle ölçülecektir.

19. ⭐ Pi’yi Bir Bulamaç Dünyasında İnşa Etmek , Mario Zechner

1. Mevcut Ajan Araçlarının Çıkmazı: Şişkinlik ve Kontrol Kaybı Yapay zeka tabanlı kodlama ajanları (Claude Code vb.) başlangıçta basit ve öngörülebilir olsalar da, zamanla özellik karmaşasına (feature bloat) yenik düşmüşlerdir.

• Bağlamın (Context) Gasp Edilmesi: Mevcut araçlar, arka planda kullanıcının haberi olmadan çalışan gizli sistem promptlarına (yönergelerine) sahiptir. Geliştiricinin sağladığı bağlam, aracın kendi dayattığı bağlam tarafından ezilmekte, bu da araçları öngörülemez kılmaktadır.
• Şeffaflık (Observability) Eksikliği: Arka planda hangi LSP (Language Server Protocol) hata denetimlerinin yapıldığı, kodun nasıl gizlice değiştirildiği veya araçların hangi kararları aldığı kullanıcıdan gizlenmektedir.
• Esneklik Eksikliği: Sektördeki araçlar, sizin iş akışınıza uyum sağlamak yerine kendi iş akışlarını size dayatmaktadır. Özelleştirme ve genişletilebilirlik (extensibility) seviyeleri son derece yüzeyseldir.

2. Mühendislik Problemi: “Clanker” İstilası ve Katlanarak Büyüyen Hatalar Otonom kodlama ajanları kontrolsüz bir hızla kod ürettiğinde, bu durum projeler için bir avantaja değil, felakete dönüşmektedir.

• Açık Kaynak (OSS) İstilası: “Clanker” (otonom bot/ajan) olarak adlandırılan yapay zekalar, açık kaynaklı projelere binlerce gereksiz ve kalitesiz “Pull Request” (PR) ve hata bildirimi (issue) göndererek insan maintainer’ları (bakımcıları) bunaltmaktadır.
• Katlanarak Artan Hatalar (Compounding Booboos): Bir ajan günde yüzlerce satır hatalı kod yazabilir. Sınırları belirlenmemiş ajanlar, insan inceleme kapasitesini aşan miktarda çöp kod üreterek kod tabanına olan güveni tamamen yok eder.
• “İnceleyici Ajan” Yanılgısı (Ouroboros): Hatalı kodu denetlemek için başka bir ajan kullanmak işe yaramaz. Çünkü ajanlar “öğrenilmiş karmaşıklık” (learned complexity) tüccarlarıdır; internetteki kötü mimari kararları, eski “best practice”leri ve aşırı mühendislik (over-engineering) örneklerini kopyalayarak sistemi daha da içinden çıkılmaz hale getirirler.
• Ajanlar Acı Hissetmez: İnsanlar kötü bir kod tabanında çalışırken acı hisseder ve bu acı, onları kodu yeniden düzenlemeye (refactoring) veya süreci iyileştirmeye iter. Ajanlar ise acı hissetmez; ne kadar kötü olursa olsun çöp kodun üzerine çöp kod eklemeye itiraz etmeden devam ederler.

3. Çözüm: “Pi” Yaklaşımı , Kendi Araçlarınızı Geri Alın Mario Zechner, mevcut araçların bu sorunlarını çözmek için tamamen şeffaf, minimalist ve geliştirici odaklı “Pi” (pi.dev) adlı aracı inşa etmiştir.

• Minimalist Çekirdek, Maksimum Esneklik: Pi, sadece temel okuma/yazma/düzenleme araçlarıyla gelir. İstemediğiniz hiçbir alt ajan (sub-agent), planlama modu veya gizli arka plan işlemi yoktur.
• Kendi Kendini Modifiye Edebilen Ajan: Ajan, kullanıcının ihtiyaç duyduğu eklentileri (extensions) bizzat kendisi yazabilir. Geliştirici, ajana sadece dokümantasyonu verir ve ajan kullanıcının iş akışına özel araçları anında (hot-reload ile) inşa eder.
• Varsayılan Olarak “YOLO” (Tam Yetki): Sürekli karşınıza çıkan ve iş akışını bölen sahte güvenlik onayları yerine, sistem size tam kontrol verir. Kendi güvenlik ve kısıtlama kurallarınızı (korkuluklarınızı) kendi iş akışınıza göre inşa etmeniz beklenir.

*4. Pratik Uygulama: “Yavaşlayın” (Slow the Fck Down) ve Doğru Görevlendirme** Tüm ürünü sadece yapay zekaya yazdırmak (“%100 built by AI”) bir övünç kaynağı değil, ürünün kalitesizliğinin (slop/bulamaç) bir göstergesidir. Ajanlarla doğru çalışma pratikleri şunlardır:

• Yavaşlayın ve “Hayır” Demeyi Öğrenin: Sırf ajanlar yapabiliyor diye sürekli yeni özellikler eklemeyin. Daha az özellik geliştirin ancak bunları ajanları kullanarak mükemmelleştirin (polish).
• Kritik Kodu İnsanlar Yazmalı: Mimari kararları, kritik API’leri ve temel sistem tasarımlarını ajanlara bırakmayın; bunları elle yazın. Ajanlar büyük resmi göremez, kararları “yerel”dir (local).
• Sürtünme (Friction) Anlayış İnşa Eder: Kodla boğuşmak, mimariyi anlamanızı sağlar. Kodu okumayı tamamen bırakıp devasa bağlam pencerelerine (large context windows) güvenmek, kod tabanınızı bir daha asla anlayamayacağınız bir kara kutuya dönüştürür.
• Ajanlara Verilecek Doğru Görevler: Ajanları; sınırları çok net çizilmiş (scoped), ajanın kendi kendini test edebileceği (closed loop), sıkıcı, tekrarlayan, görev kritik olmayan (non-mission critical) işlerde ve sorun yeniden üretme (reproduction) süreçlerinde kullanın.

Sonuç: “Disiplin ve İnsan Sorumluluğu Şarttır” Sunumun temel mesajı; yapay zeka ajanlarının sihirli değnekler olmadığıdır. Kodu okumayı bıraktığınız an, projenizin kontrolünü kaybedersiniz. Ajanlar devasa kod blokları üretebilir ancak üretilen kodun sorumluluğunu alamazlar. Geleceğin yazılım mühendisliği, ajanlara her şeyi körü körüne yaptırmak değil; onları kendi belirlediğiniz katı sınırlar içinde ustaca yönlendirmek, üretilen kodu dikkatle incelemek (review) ve en önemlisi neyi inşa edip neyi inşa etmeyeceğinize insan olarak karar vermektir. Eğilim “hızlanmak” yönünde olsa da, kaliteyi korumanın tek yolu bilinçli bir şekilde “yavaşlamaktır”.

20. Gemma, DeepMind’ın Açık Modeller Ailesi, Omar Sanseviero, Google DeepMind

1. Paradigma Değişimi: Güçlü Açık Modeller ve “Cihaz İçi” (On-Device) Yapay Zeka Devrimi Google DeepMind, açık model ailesinin en yeni ve en yetenekli sürümü olan Gemma 4'ü tanıttı. Yapay zeka dünyasındaki temel odak, bulutta çalışan devasa modellerden, doğrudan son kullanıcının donanımında çalışan yüksek kapasiteli yerel modellere kayıyor.

• Tamamen Çevrimdışı (Offline) Kapasite: Artık internet bağlantısına veya bulut API’lerine ihtiyaç duymadan, doğrudan akıllı telefonlarda, dizüstü bilgisayarlarda veya Raspberry Pi gibi küçük cihazlarda tam teşekküllü ajan (agent) tabanlı kodlama ve geliştirme yapılabiliyor.
• Boyut Artmadan Artan Performans: Model boyutları 2 milyar ile 32 milyar parametre arasında değişiyor. Geçtiğimiz yıllara kıyasla modellerin boyutu büyümeden, sahip oldukları mantıksal yürütme ve genel yetenekleri (LMSYS Arena skorlarında görüldüğü üzere) muazzam bir artış gösterdi.
• Geliştirici Dostu Boyutlandırma: Her bir model boyutu (2B, 4B, 26B MoE, 32B), sıradan tüketici ekran kartlarına (GPU) veya mobil cihaz belleğine sığacak ve geliştiricilerin hayatını kolaylaştıracak şekilde özel olarak tasarlandı.

2. Teknik İnovasyonlar: E2B Mimarisi ve Yerleşik Çoklu Modalite Gemma 4, küçük cihazlarda yüksek performans elde etmek donanım kısıtlamalarını aşan yeni mimari yaklaşımlar ve çoklu modalite yetenekleri sunuyor.

• E2B (Etkili 2 Milyar) Mimarisi: Aslında 4 milyar parametreli olan bu model, “katman başına gömme” (per-layer embeddings) adı verilen yenilikçi bir mimari kullanır. Ağır matris çarpımları yerine bir “arama tablosu” (lookup table) gibi çalışarak, sadece 2 milyar parametreyi GPU’ya yükler. Geri kalan kısım CPU’da çalıştırılabilir, bu da mobil cihazlar için inanılmaz bir hız sağlar.
• Küçük Modellerde Çoklu Modalite (Multimodal): En küçük Gemma modelleri bile metin, ses ve görüntüyü yerel olarak işleyebilir. Bir cihazda doğrudan sesten metne çeviri yapabilir, fotoğraflardaki nesneleri algılayıp üzerine konuşabilir.
• Çok Dilli (Multilingual) Uyum ve Gemini Tokenizer: 140'tan fazla dille eğitilen model, Gemini tabanlı bir tokenizer kullanır. Bu sayede düşük kaynaklı yerel dillerde (Örn: Peru’daki Quechua dili) bile ince ayar (fine-tuning) yapıldığında kutudan çıktığı haliyle mükemmel sonuçlar verir.

3. Gerçek Açık Kaynak, Ekosistem ve Uyumlu Adaptasyon Gemma, sadece indirilebilir bir model olmaktan çıkıp, topluluğun üzerine araçlar ve uygulamalar inşa edeceği devasa bir ekosistem (Gemmaverse) olarak konumlandırılıyor.

• Apache 2.0 Lisansına Geçiş: Topluluğun en büyük taleplerinden biri karşılanarak Gemma 4, tam ticari esneklik ve özgürlük sağlayan gerçek açık kaynak lisansı olan Apache 2.0 ile yayınlandı.
• Topluluk Araçlarıyla İlk Günden Entegrasyon: DeepMind, modelin çıktığı gün Hugging Face, Ollama, Llama.cpp, vLLM ve MLX gibi açık kaynak ekosisteminin en popüler araçlarıyla sorunsuz çalışması için toplulukla birlikte hareket etti.
• Android Studio Entegrasyonu: Android geliştiricileri için, doğrudan IDE içinde çalışan, internet gerektirmeyen (Llama.cpp tabanlı) yerel bir kodlama asistanı entegre edildi.
• Devasa İlgi ve İndirme: Model sadece ilk haftasında 10 milyon kez indirilirken, tüm Gemma ailesinin toplam indirme sayısı 500 milyonu aştı.

4. Pratik Uygulama: Özelleştirilmiş Modeller ve Gerçek Dünya Etkisi Temel Gemma modelleri; kurumlar, devletler ve araştırmacılar tarafından kendi özel kullanım senaryolarına (domain-specific) ve bölgesel ihtiyaçlarına göre ince ayardan (fine-tune) geçirilmektedir.

• Sektörel ve Güvenlik Odaklı Varyasyonlar: Kötü niyetli istemleri engellemek için kurumsal üretime uygun ShieldGemma ve radyoloji, röntgen gibi medikal verileri analiz edebilen çok modlu MedGemma geliştirildi.
• Bölgesel Yapay Zeka (Sovereign AI): Singapur hükümeti destekli SEA-LION (Güneydoğu Asya dilleri için) ve Hindistan’daki Sarvam gibi projeler, Gemma’yı temel alarak kendi ulusal/yerel dil modellerini eğitiyorlar.
• Bilimsel Keşiflerde Kullanım: Sadece bir sohbet botu veya kod asistanı olmanın ötesinde, Gemma tabanlı bir modelin gerçek bir laboratuvar ortamında yeni bir kanser tedavisi yolunun (pathway) keşfedilmesine ve doğrulanmasına yardımcı olması sağlandı.

Sonuç: “Gelecek; Cebinizdeki, Özelleştirilmiş ve Tamamen Açık Yapay Zeka” Sunum, yapay zekanın geleceğinin sadece büyük teknoloji şirketlerinin tekelindeki devasa bulut API’lerinde değil; kullanıcıların kendi cihazlarında, gizlilik içinde çalışan yetenekli “açık modellerde” yattığı mesajıyla sona ermektedir. Geliştiricilerin yeni rolü; sadece API çağırmak değil, E2B gibi donanım kısıtlamalarını aşan yenilikçi mimarileri kullanarak tamamen çevrimdışı, kendi verileriyle eğitilmiş ve spesifik problemlere (sağlık, hukuk, yerel diller) çözüm üreten yüksek kapasiteli yerel ajanlar inşa etmektir.

21. ⭐ Yazılım Temelleri Neden Her Zamankinden Daha Önemli?, Matt Pocock, AI Hero @mattpocockuk

1. Paradigma Yanılgısı: “Kod Ucuzdur” Efsanesi ve Kötü Kodun Maliyeti Yapay zeka çağında “kodun artık bedava veya çok ucuz olduğu”, dolayısıyla eski yazılım kurallarının çöpe atılabileceği düşüncesi büyük bir yanılgıdır. Sadece metin tabanlı spesifikasyonlar verip (Specs to Code) yapay zekanın (YZ) kodu kendi başına yazmasını beklemek genellikle “çöp” (garbage) kod üretimiyle sonuçlanır.

• Kötü Kod Hiç Olmadığı Kadar Pahalıdır: Kod tabanınız (codebase) karmaşıksa ve değiştirilmesi zorsa, yapay zekanın sunduğu hız ve verimlilik avantajlarından yararlanamazsınız. Sistem giderek daha da bozulur (Yazılım Entropisi).
• Temel Prensiplerin Yükselişi: İyi tasarlanmış, temiz kod tabanları eskisinden çok daha değerlidir. Bu nedenle, yapay zeka devriminde klasik yazılım temelleri (software fundamentals) önemini yitirmemiş, tam aksine her zamankinden daha önemli hale gelmiştir.

2. İletişim Bariyeri: Tasarım Konsepti ve Ortak Bir Dil Oluşturmak Geliştiricilerin YZ ile yaşadığı en büyük sorunlardan biri, YZ’nin istenenden farklı şeyler yapması veya çok fazla gereksiz kelime (verbose) kullanmasıdır. Geliştirici ve YZ arasında bir iletişim uçurumu vardır.

• Ortak Tasarım Konsepti (Shared Design Concept): YZ’nin doğrudan koda atlamasına izin vermek yerine, ne yapılacağı konusunda tam bir fikir birliğine varılmalıdır. Bunun için sunumda önerilen “/grill-me” (Beni sorguya çek) taktiği ile; YZ’ye “planladığımız mimariyi tam olarak anlayana kadar bana ardı ardına sorular sor” komutu verilerek eksiksiz bir ürün gereksinim dokümanı (PRD) oluşturulmalıdır.
• Her Yerde Bulunan Dil (Ubiquitous Language): Alan Odaklı Tasarım (Domain-Driven Design: DDD) kavramından yola çıkarak, YZ ile insan arasında ortak bir sözlük oluşturulmalıdır. Projedeki teknik terimlerin ve iş mantığının açıklandığı bir “Ortak Dil” markdown dosyası yaratılarak, YZ’nin bağlamdan kopması ve laf kalabalığı yapması engellenir.

3. Geri Bildirim Döngüleri: Hız Sınırını Belirlemek ve TDD YZ’nin kod üretirken en sık düştüğü hatalardan biri de “farların aydınlattığı alanın dışına çıkacak kadar hızlı gitmesi” (outrunning headlights), yani tek seferde devasa boyutta ve çalışmayan kod yığınları üretmesidir.

• Hız Sınırı Geri Bildirimdir: Bir kod tabanında ilerleme hızınız, aldığınız geri bildirimlerin hızıyla sınırlıdır. Statik tipler (TypeScript), tarayıcı erişimi ve otomatik testler bu geri bildirim döngüsünün temel taşlarıdır.
• Test Güdümlü Geliştirme (TDD) Şarttır: YZ’nin yoldan çıkmasını engellemek için TDD (Test-Driven Development) kullanılmalıdır. YZ’ye önce küçük bir test yazdırılmalı, bu testin geçmesi sağlanmalı ve ardından kod yeniden düzenlenmelidir (refactor). Bu sayede YZ, küçük ve güvenli adımlarla ilerlemeye zorlanır.

4. Mimari ve Bilişsel Yük: Derin Modüller ve Arayüz Tasarımı YZ, kötü mimariye sahip, her şeyin birbirine girdiği sığ ve parçalı (shallow modules) bir kod tabanını anlayamaz. Aynı zamanda bu karmaşa, insanın da “beynini yakar” (bilişsel aşırı yük).

• Derin Modüller (Deep Modules) ve Gri Kutular: John Ousterhout’un felsefesine dayanarak, kod tabanı “Derin Modüller” şeklinde yapılandırılmalıdır. Yani, arka planda devasa ve karmaşık işlevler barındıran ancak dışarıya son derece basit bir arayüz (interface) sunan yapılar kurulmalıdır. Bu modüller YZ için dışarıdan test edilebilir “Gri Kutular” gibi çalışmalıdır.
• Stratejik vs. Taktiksel Programlama: Kod yazarken günü kurtaran “Taktiksel” programlama yerine, sistem mimarisine her gün yatırım yapılan “Stratejik” programlamaya geçilmelidir. Geliştirici sadece arayüzü tasarlamalı, içindeki uygulamanın (implementation) nasıl yapılacağını YZ’ye delege etmelidir.

Sonuç: “Yazılım Mühendisinin Yeni Rolü: Arayüz Tasarımcısı ve Stratejist” Sunum, yapay zekanın “vibes” (hisler/tahminler) ile kod yazma dönemi olmadığını, aksine geçmişin en iyi yazılım mühendisliği pratiklerine (The Pragmatic Programmer, A Philosophy of Software Design, Domain-Driven Design) sıkı sıkıya sarılmamız gerektiğini vurgulamaktadır. İnsanların yeni rolü; taktiksel kod yazıcılığı değil, ortak dili belirleyen, arayüzleri tasarlayan ve YZ’ye uygulama (implementation) sürecinde rehberlik eden yüksek seviyeli bir sistem mimarı olmaktır.

22. Uygulamaların Sonu, Kitze, Sizzy.co

1. Kişisel Verimlilik Çıkmazı ve “Life OS” (Hayat İşletim Sistemi) İhtiyacı Konuşmacının 10 yaşından beri süregelen verimlilik uygulamaları (to-do apps) arayışı ve kendi geliştirdiği sayısız uygulama (Tododo, Better, Benji) şu temel gerçeği ortaya koymuştur: Geleneksel üretkenlik araçları temelden kusurludur.

• Manuel Veri Girişi Sürtünmesi: İnsanlar, hayatlarını organize etmek için sürekli form doldurmak ve veri girmek istemezler. Bu sürtünme (friction), verimlilik uygulamalarının uzun vadede terk edilmesine yol açar.
• Uygulama Değil, İşletim Sistemi: Kullanıcılar sadece görevleri alt alta dizen bir uygulama değil; alışkanlıkları, rutinleri, e-postaları, dosyaları ve finansı entegre şekilde yönetecek kapsamlı bir “Life OS” aramaktadır.
• Veri Dağınıklığı: Tüm kişisel verilerin iCloud, Google Drive, Notion gibi farklı bulut sistemlerine dağılmış olması, kişisel bir asistanın (ajanın) hayatınızı gerçek anlamda anlamasını ve yönetmesini engeller.

2. Ajan (Agent) Çağı ve “Chat” Arayüzlerinin Yetersizliği LLM’lerin (Büyük Dil Modelleri) ve araç kullanımının (tool calling) gelişmesiyle, kişisel hayatı yönetecek asistanlar yaratmak mümkün hale geldi. Ancak bunu uygulamak yeni sorunlar doğurdu.

• Yanlış Arayüz (Discord/Telegram): Konuşmacı, kendi geliştirdiği özel ajanları (Clawdbot/Openclaw) yönetmek için Discord ve Telegram gibi sohbet uygulamalarını kullandı. Ancak bu platformlar kişisel bir işletim sistemi olmak için tasarlanmamıştır; bu sadece geçici bir “hack” yöntemidir.
• 1:1 Sohbet Çıkmazı: Hayatın tüm karmaşıklığını (iş, aile, kişisel görevler) tek bir ajanla, tek bir sohbet penceresinde yönetmek imkansızdır. Doğru yaklaşım; farklı bağlamlara, hafızalara ve yetkilere sahip “uzmanlaşmış ajanlar” (specialized agents) kullanmaktır.
• Güvenilirlik ve “Şizofreni”: Mevcut ajanlar zamanlanmış görevlerde (cron jobs), arka plan işlemlerinde ve bağlam hatırlamada hala yetersizdir. Bazen bir önceki mesajı unutacak kadar tutarsız (“LLM şizofrenisi”) davranabilirler.

3. Pazarın Bölünmesi: Özel Ajanlar (Custom) vs. Bulut Ajanları (Cloud) Şu an kişisel yapay zeka pazarında iki farklı gelecek birbiriyle savaşıyor ve ikisi de nihai çözüm değil:

• Bulut Ajanlarının Kısırlığı: OpenAI, Anthropic (Claude) veya Perplexity’nin kapalı ekosistem ajanları fazla güvenliğe alınmış, zayıflatılmış ve esneklikten yoksundur. Geliştiricileri (tinkerers) ve kişiselleştirme isteyenleri asla tatmin etmez.
• Özel Ajanların Erişilemezliği: Açık kaynaklı veya kendi barındırdığınız (self-hosted) özel ajan sistemleri ise normal kullanıcılar (meşgul profesyoneller veya teknik olmayan kişiler) için fazla karmaşıktır. Kimsenin bu ajanları kuracak ve “ayarlarla oynayacak” zamanı yoktur.

4. Bilgisayar Kullanımının Geleceği: Uygulamaların Ölümü ve Roller Değişimi Bugünkü sekmelerle, bildirimlerle ve pencerelerle dolu bilgisayar kullanım alışkanlığımız gelecekte insanlara “ilkel ve çılgınca” gelecektir.

• Yapay Zekanın İnsanı “Prompt”laması: Artık roller tersine dönecektir. Gelecekte en üretken insanlar, yapay zekaya komut verenler değil; işin %95'ini otonom olarak yapan yapay zekanın, eksik kalan %5'lik kısım (karar onayı veya eksik bilgi) için insanı dürtmesine (prompt) izin verenler olacaktır.
• Tüketici Uygulamalarının (App) Yok Oluşu: Özel profesyonel yazılımlar (video kurgu, kodlama vb.) hariç, son kullanıcıya yönelik “uygulama” (app) kavramı ortadan kalkacaktır. Kullanıcılar sadece bilgisayarlarıyla konuşacak, işletim sistemi arkada gereken API’leri ve ajanları çalıştırarak işi çözecektir.
• Yerel Modellerin (Local Models) Sessiz Zaferi: Yapay zeka savaşının nihai kazananı muhtemelen devasa bulut modelleri değil; doğrudan kullanıcının cihazında çalışan, kişisel verilere gizlilikle erişebilen (Apple Intelligence gibi) ve çoğu normal insanın ihtiyacını karşılayacak kadar “yeterli” olan yerel modeller olacaktır.

Sonuç: “İnsan-Bilgisayar Etkileşiminin Yeniden İnşası” Sunum, yapay zeka çağında kişisel verimliliğin geleceğinin yeni to-do uygulamaları yazmakta değil, tüm dijital altyapıyı baştan düşünmekte yattığını vurgulamaktadır. Gelecekte işletim sistemleri, pasif birer araç olmaktan çıkıp, tüm dijital ayak izimize entegre olmuş aktif ve otonom birer “Hayat İşletim Sistemi”ne dönüşecektir. İnsanlar, ekranlarda onlarca uygulama arasında geçiş yapmak yerine, kendi verileri üzerinde tam kontrole sahip kişisel ajan ordularıyla doğal bir diyalog kurarak hayatlarını yöneteceklerdir.

23. Yapay Zeka Yazılım Mühendisliğini Nasıl Değiştiriyor: Gergely Orosz ile Bir Söyleşi, ‪@pragmaticengineer‬

1. “Token Maxxing” (Token Maksimizasyonu) Absürtlükleri ve Yanlış Teşvikler Gergely Orosz, Meta, Microsoft ve Salesforce gibi dev teknoloji şirketlerinde ortaya çıkan ve mühendisleri yapay zeka kullanım oranlarına (üretilen/tüketilen token sayısına) göre değerlendiren “Token Maxxing” trendinin nasıl toksik bir kültüre dönüştüğünü açıklıyor.

• Metriklerin Silaha Dönüşmesi: Tıpkı eskiden yazılan kod satırı sayısının (lines of code) ölçülmesi gibi, şimdi de yapay zeka araçlarının kullanım oranı (token harcaması) bir performans kriteri, liderlik tablosu puanı veya terfi metriği haline gelmiştir.
• Sahte Üretkenlik: Mühendisler, sadece token sayılarını artırmak için okuyabilecekleri bir dokümanı yapay zekaya özetletmekte veya hiçbir işe yaramayan “çöp” otonom ajanlar çalıştırarak sistemi kandırmaktadır (Goodhart Yasası).
• Büyük Teknolojinin (Big Tech) Çıkmazı: Yeni girişimler (startuplar) maliyetleri düşürmeye ve gerçekten çalışan ürünler inşa etmeye odaklanırken, dev şirketler yöneticilerin “yapay zekayı ne kadar çok kullanıyoruz” illüzyonunu tatmin etmek için milyarlarca token’ı israf etmektedir.

2. Yukarıdan Aşağıya Yapay Zeka Baskısı ve “Kullan ya da Kovul” Yaklaşımı Deneyimli yazılım mühendisleri, mevcut yapay zeka araçlarını (özellikle karmaşık ve eski kod tabanlarında) her zaman faydalı bulmasa da, şirket yönetimleri bu araçların kullanımını zorunlu kılmaktadır.

• Coinbase Örneği ve Sert Yaptırımlar: Coinbase CEO’sunun yapay zeka araçlarını kullanmayan bir mühendisi tüm şirkete e-posta atarak işten çıkarması, sektördeki yeni agresif yaklaşımın en net örneğidir. Liderler, çalışanların yapay zekayı ne pahasına olursa olsun benimsemesini istemektedir.
• Kısa Vadeli Verim Kaybı vs. Uzun Vadeli Kazanç: Liderler, yapay zeka araçlarının mevcut durumda bazı mühendisleri (yanlış kodu düzeltmek zorunda kaldıkları için) yavaşlattığının farkındadır. Ancak, organizasyonun “gelecekteki verimlilik artışını” yakalayabilmesi için bu yeni kasın bugünden acı çekerek geliştirilmesi gerektiğine inanmaktadırlar.
• Mülakat İkiyüzlülüğü: Şirketlerin bir yandan yapay zeka kullanımını dayatıp, diğer yandan işe alımlarda yapay zekanın kolayca çözebileceği “LeetCode” tarzı ezbere dayalı geleneksel algoritma mülakatlarına devam etmesi sektördeki büyük bir çelişkidir. Sisteme girmek için istenen yetenek ile içeride istenen yetenek tamamen zıttır.

3. Yazılım Mühendisinin Değişen Rolü: Kodlayıcıdan “Orkestratör”e Dönüşüm Yapay zekanın kodlama sürecine dahil olmasıyla birlikte yazılım mühendislerinin (SWE) iş tanımı temelden değişmekte ve BT organizasyonları küçülmektedir.

• Rollerin Çöküşü ve Birleşmesi (DevOps & QA): Özellikle startuplarda Test (QA), DevOps ve Ürün yönetimi gibi ayrı roller kaybolmakta, hepsi tek bir mühendisin sorumluluğunda birleşmektedir. Geleceğin mühendisi, birden fazla süreci yöneten “bir tane büyük boy pizzayı yiyip doyabilecek boyuttaki takımlar” olacaktır.
• Mühendisin Test Uzmanına Dönüşmesi: Yapay zeka ajanları kod yazma işinin büyük kısmını üstlendikçe, mühendisin ana görevi sıfırdan kod yazmaktan ziyade; yapay zekanın ürettiği kodu okumak, incelemek (code review) ve sistemleri test edip onaylamak (QA) haline gelmektedir.
• Teknik Olmayanların Güçlenmesi: Yapay zeka araçları, geliştirici olmayan ekiplerin (non-coders) dışa bağımlılığını azaltarak, onların kendi başlarına kod yazmalarına ve şirkete doğrudan katkı sağlamalarına olanak tanımaktadır. Bu, darboğazları ortadan kaldırmaktadır.

4. Kurumsal Yapay Zeka Altyapısı (AI Infra) ve Kendi Sistemini İnşa Etme Trendi Pek çok şirket sadece hazır yapay zeka ürünlerini (Copilot, Cursor vb.) satın almakla yetinmeyip, “Neden kendi yapay zeka altyapımızı kuruyoruz?” sorusuna yanıt olacak şekilde iç sistemlerini inşa etmektedir.

• Bağlam (Context) ve Özelleştirme İhtiyacı: Piyasada satılan hazır araçlar, büyük şirketlerin devasa ve karmaşık kod havuzlarında (monorepo) yeterli bağlamı sağlayamamaktadır. Şirketler, kendi iç işleyişlerini, güvenlik protokollerini ve mimarilerini anlayan özel yapay zeka ajanları (Custom AI Agents) geliştirmek zorundadır.
• Düşük Riskli Öğrenme Alanı (Sandbox): Şirketler için kendi yapay zeka destekli iç araçlarını (internal tools) kurmak; müşteri verilerini riske atmadan yapay zekanın nasıl çalıştığını, MCP (Model Context Protocol) gibi yeni teknolojileri anlamak için risksiz bir laboratuvar ortamı yaratmaktadır.
• Geleceğe Stratejik Yatırım: Shopify gibi şirketlerin kendi yapay zeka asistanlarını baştan yaratmaları anlamsız bir çaba değil; geleceğin otonom, kurum içi verilerle eğitilmiş, çoklu araç kullanan (tool calling) iş akışlarına hazır olmak için yapılmış stratejik bir altyapı hamlesidir.

Sonuç: “Karmaşık ve Çelişkilerle Dolu Bir Geçiş Dönemi” Sunum, teknoloji endüstrisinin yapay zeka entegrasyonu konusunda kaotik ve zaman zaman absürt (Token Maxxing örneğindeki gibi) bir geçiş evresinde olduğunu vurgulamaktadır. Yöneticilerin vizyonsuz dayatmaları ve yanlış hedeflenen metrikler şu an için şirketlerde sürtünme ve israf yaratsa da, ana eğilim durdurulamazdır: Yazılım mühendisliği artık “sıfırdan satır satır kod yazma” mesleği olmaktan çıkmıştır. Geleceğin başarılı mühendisleri; yapay zeka ajanlarını doğru yönlendiren, üretilen kodu denetleyen (reviewer) ve karmaşık sistemleri birbiriyle konuşturan stratejik birer “orkestratör” olmak zorundadır. Organizasyonlar küçülecek, roller birleşecek ve sadece bu yeni yapay zeka dinamiklerine (ve mantıksız da olsa yöneticilerin beklentilerine) uyum sağlayanlar hayatta kalacaktır.

24. Yeni Uygulama Katmanı, Malte Ubl, CTO Vercel

1. Yapay Zeka Mühendisliğinin (AI Engineering) Yükselişi ve Yazılımın Evrimi Malte Ubl, geleneksel yazılım geliştirme döneminin büyük bir kırılma yaşadığını ve “Yapay Zeka Mühendisliğinin”, web geliştirmenin meşru ve ana akım halefi olarak önümüzdeki on yılı şekillendireceğini açıklıyor.

• İkili Yıkım (Disruption): Endüstri aynı anda iki farklı şok yaşıyor: İlki nasıl inşa ettiğimizin değişmesi (yapay zeka yardımıyla kodlama), ikincisi ise ne inşa ettiğimizin değişmesi (geleneksel sayfalar/uygulamalar yerine otonom ajanlar inşa edilmesi).
• Yeni Nesil Mühendislerin Adaptasyonu: “Mühendislere hala ihtiyaç var mı?” endişesine karşı Ubl net bir “Evet” diyor. Tıpkı TikTok neslinin kısa video üretimine doğuştan aşina olması gibi, yeni nesil “genç mühendisler” de doğrudan yapay zeka araçlarıyla yoğrularak yetişecek ve bu yeni disiplinde eskilere göre çok daha doğal bir yeteneğe sahip olacaklar.
• Avrupa’nın Liderliği: Yapay zeka modelleri genellikle ABD merkezli laboratuvarlardan çıksa da, açık kaynak araçlar, framework’ler ve uygulama katmanı inovasyonları (AI SDK, Phind vb.) sayesinde Avrupa, Yapay Zeka Mühendisliği devrimine liderlik etmektedir.

2. Yazılım Ekonomisinin Değişimi: Elastik Talep ve “Yap ya da Satın Al” Eğilimi Yapay zeka sayesinde yazılım üretmenin maliyeti dramatik şekilde düşmektedir. Ancak bu durum mühendisleri işsiz bırakmak yerine, Jevons Paradoksu (elastik talep) devreye girerek çok daha fazla yazılımın üretilmesini sağlayacaktır.

• Ekonomik Olarak Uygulanabilir Yazılım Havuzu: Geçmişte şirketlerin otomatize etmek istediği ancak geleneksel yöntemlerle (if-else blokları, iş kuralları yazmak) çok pahalı olduğu için vazgeçtiği devasa bir “keşke olsa” dediği yazılım havuzu vardı. Ajanlar (agents) sayesinde bu yazılımları üretmek artık ekonomik olarak mantıklı hale gelmiştir.
• SaaS Şirketleri vs. Kurum İçi Çözümler (“Buy vs. Make”): Şirketler artık dışarıdan hazır “SaaS” (Hizmet olarak yazılım) ürünleri satın almak yerine, kendi özel verileriyle eğitilmiş kurum içi (Make) yazılımlar ve ajanlar geliştirmeye yönelmektedir (Silikon Vadisi’nde buna “SaaS Kıyameti” denmektedir).
• Mühendislere Olan Talebin Artması: Yazılım üretmek ucuzladıkça ve kolaylaştıkça pazarın doyuma ulaşması beklenirken, tam tersine şirketler çok daha fazla otomasyon ve özel yazılım talep edeceği için yazılım mühendislerine olan iş ilanı talepleri artmaya devam etmektedir.

3. Günümüzde İnşa Edilen Pratik Yapay Zeka Ajanı (Agent) Arketipleri Şirketlerin karmaşık kod yazan ajanlardan ziyade, iş süreçlerini hızlandıran ve “düşük asılı meyveleri” toplayan pratik ajan tiplerine odaklanması gerekmektedir.

• Araştırma Sürecini Sıkıştırmak: Çoğu iş süreci “Bir Olay Gerçekleşir -> Araştırma Yapılır -> İnsan Karar Verir” şeklinde işler. Satış talepleri veya suistimal şikayetleri geldiğinde, arka planda Google araması yapan, LinkedIn profillerini inceleyen ve şirketin büyüklüğünü analiz eden ajanlar, insanlara sadece son kararı verme işini bırakarak 30 dakikalık işleri 5 dakikaya indirmektedir.
• Gizli Bilgiyi Yüzeye Çıkarma: Şirketlerde sorun takip sistemleri (issue trackers) genellikle güncel değildir. Yapay zeka ajanları; Slack mesajlarını, toplantı kayıtlarını ve dökümanları tarayarak hiçbir insanın manuel olarak güncel tutamayacağı bilgileri yüzeye çıkarabilmektedir.
• Sıkıcı İşlerin Eliminasyonu: “İşinizle ilgili en nefret ettiğiniz şey nedir?” sorusu, ajanların nereye konumlanması gerektiğini gösterir. Vercel’in müşteri destek ekibi, kredi kartı retleri gibi sıkıcı süreçleri ajanlara devrettiğinde, çalışanların iş tatmini (job satisfaction) devasa ölçüde artmıştır.

4. Geleceğin Altyapısı: Ajan Odaklı (Agentic) Sistemler ve Güvenlik Kullanıcı arayüzleri ve altyapı mimarileri, insanlardan ziyade makineler (ajanlar) için yeniden tasarlanmak zorundadır.

• Makineler İçin UI/UX: Vercel.com’un son yedi günlük sayfa görüntülemelerinin %60'ı insanlardan değil, yapay zeka ajanlarından gelmektedir. Geliştiriciler artık platformları görsel gösterge panelleri (dashboards) yerine CLI (Komut Satırı) ve API’lar üzerinden ajanlara yönettirmek istemektedir.
• Altyapıyı Ajanların Yönetmesi: Eğer kodu yapay zeka ajanları yazıyorsa, bu kodun üretim ortamında (production) nasıl çalışacağını ve altyapısını da ajanların kurup yönetmesi gerekmektedir.
• Güvenlik Kabusu (1999'a Dönüş): Ajanlara yetki vermek, siber güvenlik açısından internetin ilk günleri gibi her şeyin hacklenebilir olduğu vahşi bir ortam yaratmaktadır. Sektörün, ajanların dış dünyaya zarar vermeden kod çalıştırabileceği ultra hızlı ve güvenli “Sandbox” (Kum Havuzu) ortamlarına acil ihtiyacı vardır (Vercel’in “Just Bash” projesi gibi).
• Model Laboratuvarları Değil, Uygulama Katmanı Kazanacak: Gelecekte OpenAI veya Google gibi büyük şirketlerin tekelleştiği bir model (Labs Win) beklenmemektedir. Modeller metalaşacak (commoditized) ve fiyatları dibe vuracaktır. Gerçek kazananlar, bu ucuzlayan modelleri alıp şirketler için değer yaratan uygulama katmanını inşa eden (Application Layer Wins) Yapay Zeka Mühendisleri olacaktır.

Sonuç: “Ajanlar Çağında Yeni Bir Uygulama Katmanı” Sunum, yazılım geliştirme endüstrisinin artık “insanların tek tek kod yazdığı” bir dönemden, “ajanların (agents) iş süreçlerini yürüttüğü” yeni bir çağa geçiş yaptığını vurgulamaktadır. Yazılım maliyetlerinin dramatik düşüşü, mühendisleri işsiz bırakmayacak; aksine ekonomik kısıtlamalar yüzünden bugüne kadar yazılamayan devasa bir yazılım ekosisteminin önünü açacaktır. Sıkıcı işleri üstlenen, araştırma süreçlerini saniyelere indiren ve kurumsal hafızayı tarayan ajanlar artık lüks değil, standart birer araçtır. Önümüzdeki en büyük zorluk ise modelleri eğitmek değil; bu ajanların güvenle çalışabileceği altyapıları (sandbox) kurmak ve makinelere yönelik arayüzler tasarlamaktır. En nihayetinde, büyük model üreticileri rekabetle fiyatları aşağı çekerken, bu modelleri kullanarak gerçek dünya sorunlarını çözen “Yapay Zeka Mühendisleri” geleceğin asıl kazananları olacaktır.

25. Lezzet ve Zanaat: Tuomas Artman ile Bir Söyleşi, CTO Linear & Gergely Orosz, ‪@pragmaticengineer‬

1. Yapay Zeka Çağında “Özellik Fabrikası” Tuzağı ve Kalite

• Hızın Getirdiği Yanılgı: Linear kurucu ortağı ve CTO’su Tuomas Artman, yapay zekanın kod yazmayı ve ürün sevk etmeyi (shipping) aşırı derecede kolaylaştırmasıyla birlikte sektörde yanlış bir trendin başladığını belirtiyor. Şirketler sırf yapay zeka ile çok hızlı yapabiliyorlar diye, müşteri isteklerini hiç filtrelemeden anında koda döken “özellik fabrikalarına” (feature factory) dönüşme riski taşıyor.
• “Hayır” Diyebilme Sanatı: Tıpkı Steve Jobs’ın “Harika ürünler 1000 şeye hayır demekten doğar” felsefesinde olduğu gibi, yapay zeka çağında da iyi bir ürün yaratmanın sırrı her aklına geleni anında üretmek değildir. Ajanların (agents) hızına kapılıp her fikri koda dökmek, sonunda kullanıcı deneyimi karmaşık, kalitesiz ve işe yaramaz bir yazılım yığını (bloatware) yaratacaktır.

2. Uber Hiper Büyüme Örneği ve Kalitenin Ölçülemezliği

• Hız Uğruna Feda Edilen Kalite: Artman, geçmişte Uber’de çalışırken Lyft ile olan acımasız rekabet dönemindeki “hiper büyüme” (hypergrowth) stratejisinden örnek veriyor. O dönemde tek odak noktası yeni özellikler çıkarmak ve altyapıyı ayakta tutmaktı; kalite tamamen ikinci plana atılmıştı. Yapay zeka ile herkesin çok hızlı kod yazabildiği yeni dönemde, start-up’ların bu “kalitesiz ama hızlı” tuzağına düşmemesi gerektiği vurgulanıyor.
• Kaliteyi Ölçmenin Zorluğu: Şirketler genellikle gelir (revenue) veya işlem hacmi gibi altın metrikleri takip ederler. Yeni bir özellik geliri artırıyorsa başarılı sayılır. Ancak “yüksek kaliteli ve estetik bir arayüz”, geliri anında etkilemediği için metriklerle ölçülmesi ve savunulması en zor şeydir. Bu nedenle kaliteli yazılım, verilerden ziyade şirket kültürünün bir yansıması olmak zorundadır.

3. Sıfır Hata (Zero Bug) Politikası ve Yapay Zekanın Gerçek Rolü

• Yapay Zekayı Hata Ayıklamada Kullanmak: Linear, yapay zeka ajanlarını sadece yeni ürünler yığmak için değil, kod tabanını temiz tutmak için kullanıyor. Şu an platformlarına gelen hataların (bug) %10'u insan müdahalesi olmadan “tek atımlık” (single-shot) yapay zeka ajanları tarafından çözülüyor. Hedef, önümüzdeki birkaç yıl içinde bu oranı %100'e yaklaştırmak.
• Katı Hata Politikası: Şirket, kullanıcı deneyimini en üstte tutmak için bir “Sıfır Hata Politikası” (Zero Bug Policy) uyguluyor. Bir mühendise bir hata (bug) atandığında, mühendis diğer tüm yeni özellik geliştirme işlerini bırakıp o hatayı çözmek zorundadır. Eğer havuzdaki hatalar belirli bir eşiği aşarsa, tüm şirket yeni özellik geliştirmeyi durdurur ve sadece hataları temizlemeye odaklanır.

4. Geleceğin Mühendisi: “Ürün Mühendisi”ne (Product Engineer) Dönüşüm

• Sadece Kod Yazanların Sonu: Yapay zeka verileri bir yerden bir yere taşıyan, basit algoritmaları yazan rutin kodlama işlerini devraldıkça, geleneksel “sadece kod yazan yazılım mühendisi” profili yok olacaktır.
• Yeni Beklentiler: Geleceğin mühendislerinden beklenen; doğrudan müşterilerle konuşarak asıl problemi anlamaları, kullanıcı deneyimi (UX) tasarımı yapmaları ve bir “Ürün Yöneticisi” (PM) gibi düşünmeleridir. Linear’ın işe alım süreçlerinde de “ürün hissi” (product sense) ve “zarafet/kalite” algısı yüksek olan mühendisler tercih edilmekte, mühendislerin aynı zamanda mini-PM’ler olarak görev yapması beklenmektedir.

Sonuç: “Yapay Zeka Çağında Hız Değil, Lezzetli (Tasteful) ve Kaliteli Ürünler Kazanacak” Sunum, yapay zekanın yazılım dünyasındaki rekabet kurallarını temelden değiştirdiğini vurgulamaktadır. Artık küçük bir ekibin veya tek bir kişinin yapay zeka ajanları sayesinde devasa kodlar yazıp ürünleri çok hızlı piyasaya sürebildiği bir dünyada, “hız” artık bir rekabet avantajı (moat) olmaktan çıkmıştır. Herkesin her özelliği anında kopyalayıp üretebildiği bu yeni pazarda tek gerçek fark yaratıcı unsur; harika bir kullanıcı deneyimi sunan, detaylara takıntılı (örneğin 1 piksellik bir animasyon hatasını bile düzelten) ve “lezzetli” (tasteful) yazılımlar inşa etmektir. Şirketlerin yapay zekayı, düşünmeden her fikri koda döken bir “özellik fabrikası” kurmak için değil; sıkıcı hata ayıklama işlerini otonomlaştırıp insan mühendisleri yüksek seviyeli ürün tasarımına ve müşteri ihtiyaçlarına odaklamak için kullanması gerekmektedir. Geleceğin kazananları, sadece komut satırına kod yazanlar değil; estetik algısı yüksek, vizyoner “Ürün Mühendisleri” olacaktır.

26. Ajanların sohbetten fazlasına ihtiyacı var. Jacob Lauritzen, CTO Legora

Sunum, hukuk firmaları için dikey bir yapay zeka (Vertical AI) çalışma alanı sunan Legora’nın CTO’su Jacob Lauritzen tarafından yapılıyor. Lauritzen’in ana tezi; yapay zeka ajanlarından (agents) uçtan uca, karmaşık işler yapmalarını beklediğimizde, geleneksel “sohbet” (chat) arayüzlerinin artık yetersiz kaldığıdır. Sunumun başında gösterilen örnekte, bir ajandan karmaşık bir sözleşme hazırlaması isteniyor. Ajan dakikalarca düşünüyor, arama yapıyor ve nihayetinde hatalı bir sonuç üretiyor. Kullanıcı düzeltme istediğinde ise sistem bağlamı unutuyor (compaction) ve başarısız oluyor. Lauritzen, bunun berbat bir kullanıcı deneyimi olduğunu vurguluyor.

Üretimin Yeni Ekonomisi ve “Doğrulayıcı Kuralı” (Verifier’s Rule) Yapay zeka ile birlikte iş yapış şeklimizde bir darboğaz değişimi yaşandı. Eskiden işin çoğunluğunu “işi yapmak” oluştururken, artık YZ sayesinde işi yapmak çok ucuz ve hızlı hale geldi. Yeni darboğazlar ise “işi planlamak” ve YZ’nin yaptığı “işi gözden geçirmek (review)” oldu.

Burada “Doğrulayıcı Kuralı” devreye giriyor: Eğer bir görevin doğruluğunu teyit etmek kolaysa, o görev yapay zeka tarafından çözülebilir.

• Matematik ve Kodlama: Sonuçların doğrulanması görece kolaydır (örn. testleri geçer veya geçmez).
• Finans ve Hukuk: Doğrulama çok zordur. Örneğin, bir sözleşmenin gerçekten “iyi” olup olmadığı ancak mahkemede belli olur. Dava stratejilerinde ise 5 farklı avukat 5 farklı doğru strateji sunabilir, yani nesnel bir gerçeklik yoktur.

Bu nedenle dikey yapay zeka şirketlerinin asıl amacı, insanları işin gerçekten önemli olduğu noktalara dahil etmek olmalıdır. Bu da iki temel kavrama dayanır: Güven (Trust) ve Kontrol (Control).

1. Güveni Artırmak (How to Increase Trust)

Kullanıcının, yapay zekanın ürettiği sonuca ne kadar az göz atma ihtiyacı duyduğu “güven” ile ölçülür. Güveni artırmak için şunlar yapılabilir:

• Görevleri “Aşağı” Çekmek: Görevleri daha kolay doğrulanabilir hale getirmek. Hukukta bir sözleşmenin doğruluğunu kanıtlamak zor olduğu için “vekil” (proxy) yöntemler kullanılır. Örneğin; yeni yazılan sözleşmeyi, şirketin geçmişteki başarılı (altın) sözleşmeleriyle karşılaştırarak format ve dil kontrolü yaptırmak.
• Görevleri Parçalara Ayırmak (Decomposition): “Sözleşme yaz” gibi devasa bir komut yerine, işi parçalara bölmek. Sözleşmenin risk profilini belirlemek ve müzakere duruşunu ayarlamak gibi öznel işleri “insana” bırakmak; tanımların tutarlılığını kontrol etmek (linting) veya formatlama gibi mekanik işleri “ajana” yaptırmak.
• Korkuluklar (Guardrails) Eklemek: Ajanın yapabileceklerini kısıtlamak. Sadece belirli dosyaları okumasına veya belirli klasörleri düzenlemesine izin vererek, ajanın sistemi bozma ihtimali ortadan kaldırılır ve kullanıcı güveni artırılır.

2. Kontrolü Artırmak (How to Increase Control)

Kullanıcının, ajanın çalışma sürecine ne kadar etkili bir şekilde yön verebildiği “kontrol” ile ölçülür.

• Standart Sohbet: Çok düşük kontrole sahiptir. Ajan bir dizi işlem yapar ve size sadece son sonucu sunar; araya giremezsiniz.
• Planlama Yaptırmak: Ajan işe başlamadan önce size bir plan sunar. Bu kontrolü artırır ancak verimsizdir çünkü ajanın düzgün bir plan yapabilmesi için zaten işin büyük kısmını analiz etmesi gerekir. Ayrıca öngörülemeyen durumlarda tıkanır.
• Yetenekler (Skills) Eklemek: İnsani yargıları sisteme kural olarak kodlamaktır (Örn: Sözleşmede AB yasaları geçiyorsa şu prosedürü uygula). İşe yarar ancak her olası senaryo için bir yetenek yazılamaz.
• Karar Günlüğü (Decision Log / Elicitation): En iyi yöntemlerden biridir. Ajan çalışırken emin olmadığı bir durumla karşılaşırsa durup size sormaz (bu akışı engeller). Bunun yerine kendi inisiyatifiyle bir karar alır, bunu “Karar Günlüğüne” yazar ve işe devam eder. İş bitince insan bu günlüğü açar ve ajanın aldığı kararları tek tek inceleyerek gerekirse geri alır (revert). Ancak sohbet arayüzleri bu süreci yönetmek için hiç uygun değildir.

Çözüm: Arayüzlerin Evrimi (The Convergence of UI) Lauritzen’in nihai çözümü, sohbet kutularından kurtulup “Yüksek Bant Genişliğine Sahip Eserler” (High-bandwidth artifacts) yaratmaktır. Sohbet kutuları tek boyutludur, insan dili için tasarlanmıştır ve ajanın yaptığı çok dallı (tree of work) işlemleri dar bir alana sıkıştırmaya çalışır.

Bunun yerine insan ve yapay zeka şu ortamlarda işbirliği yapmalıdır:

1. Dinamik Dokümanlar: Tıpkı Google Docs gibi, insanın ve ajanın aynı anda üzerinde çalıştığı, birbirlerini etiketleyebildiği, ajanın belli maddeleri (örneğin sadece 3. maddeyi) düzenleyip notlar bırakabildiği kalıcı belgeler.
2. Tablo Tabanlı İnceleme (Tabular Review): Ajanın yüzlerce sözleşmeyi okuyup, riskli maddeleri (örn. rekabet yasağı maddeleri) bir tablo (dashboard) üzerinde çıkardığı arayüzler. İnsan bu tabloya bakarak sorunlu yerleri kırmızıyla işaretlenmiş olarak hızla görür, müdahale eder ve sadece o noktaları düzeltmesi için ajanı tekrar görevlendirir.

Sonuç Yapay zeka ajanları insan değildir. Bu nedenle onların potansiyelini, sadece insanların birbiriyle iletişim kurmak için kullandığı doğal dille (basit sohbet kutularıyla) sınırlandırmak yanlıştır. Etkili bir yapay zeka deneyimi için işe özel, zengin ve görsel arayüzler (UI) inşa edilmelidir.

27. Andrej Karpathy: Hissi Kodlamadan Ajan Tabanlı Mühendisliğe

Giriş: Bir Programcı Olarak “Geride Kalmış” Hissetmek

Karpathy, söyleşiye son aylarda (özellikle geçtiğimiz Aralık ayında) yaşadığı büyük bir aydınlanmayı anlatarak başlıyor. Sektördeki en iyi isimlerden biri olmasına rağmen, yapay zeka modellerinin kod yazma konusundaki hızlı gelişimi karşısında “bir programcı olarak kendini hiç bu kadar geride kalmış hissetmediğini” itiraf ediyor.

Modellerin artık büyük kod bloklarını hatasız yazabildiğini fark ettiğinde, kodu satır satır yazmayı bırakıp yapay zekaya tam güven duymaya ve tamamen “vibe coding” (kodun mantığını ve hissini yapay zekaya aktarıp kodlamayı ona bırakma) yapmaya başladığını belirtiyor.

Yazılım Paradigmalarındaki Evrim (Yazılım 1.0, 2.0 ve 3.0)

Karpathy, programlamanın tarihsel evrimini üç aşamaya ayırıyor:

• Yazılım 1.0 (Geleneksel Kodlama): İnsanların spesifik kurallar belirleyip C++, Python gibi dillerde satır satır kod yazdığı dönem.
• Yazılım 2.0 (Makine Öğrenimi): İnsanların doğrudan kod yazmak yerine veri setleri oluşturduğu ve yapay sinir ağlarını eğiterek problemleri çözdüğü dönem. (Örn: Görüntü tanıma modelleri).
• Yazılım 3.0 (LLM’lerin Bilgisayar Olması): Büyük Dil Modellerinin (LLM) başlı başına yeni bir işletim sistemi veya bilgisayar haline geldiği mevcut dönem. Artık programlama dili İngilizce (veya promptlar). Girdiğiniz komutlar (context) aslında sizin kodunuz; LLM ise bu komutları yorumlayan ve çalıştıran bilgisayarın ta kendisi.

Yazılım 3.0'ın Çarpıcı Örnekleri

Karpathy, bu yeni paradigmanın ne kadar güçlü olduğunu iki örnekle açıklıyor:

1. Kurulum Süreçleri: Eskiden karmaşık yazılımları kurmak için yüzlerce satırlık “bash script”ler (kurulum dosyaları) yazılırdı. Şimdi ise kurulum talimatlarını kopyalayıp bir yapay zeka ajanına veriyorsunuz. Ajan, sizin işletim sisteminizi ve bilgisayarınızı analiz edip kurulumu sizin yerinize akıllıca yapıyor.
2. MenuGen Projesi: Karpathy, restoran menülerindeki yemek isimlerini görselleştiren bir uygulama geliştirmişti. Eski (1.0) yöntemle; fotoğraf yükleme, OCR (metin okuma) ile yazıları çıkarma, Vercel üzerinde uygulama barındırma ve görüntü üretici API’leri birbirine bağlayan karmaşık bir sistem kurmuştu. Yazılım 3.0 yaklaşımında ise: Menünün fotoğrafını doğrudan Gemini gibi gelişmiş bir modele verip, “Bu menüdeki öğelerin üzerine yemek fotoğrafları yerleştir” demesi yetti. Model hiçbir ekstra kod veya mimari gerektirmeden tek başına bu işlemi saniyeler içinde hatasız yaptı. Karpathy’e göre eski yöntemle yazılmış kodların çoğu artık “gereksiz” (spurious).

Geleceğin Bilgisayar Mimarisi

Gelecek 2–3 yılın projeksiyonunu yapan Karpathy, bilgi işlem donanımlarına bakış açımızın tamamen değişeceğini öngörüyor. Klasik bilgisayarlarda CPU ana unsurdur. Gelecekte ise Yapay Sinir Ağları (Neural Networks) “ana işletim sistemi” olacak, geleneksel CPU’lar ve hesaplama araçları ise sadece yapay zekanın gerektiğinde kullandığı “yardımcı eklentiler/araçlar” (co-processor) haline gelecek.

Yapay Zekanın “Tırtıklı” (Jagged) Zekası ve Doğrulanabilirlik

Karpathy, modellerin zekasının insan zekası gibi düz ve tutarlı olmadığını, aksine “tırtıklı” (bazen dahi, bazen aptal) olduğunu belirtiyor.

• Zeka Sınırları: Gelişmiş bir model, 100.000 satırlık devasa bir kod tabanını anında yeniden yapılandırabilirken (refactoring); “Çilek kelimesinde kaç r harfi var?” veya “50 metre ilerideki oto yıkamaya arabayla mı yoksa yürüyerek mi gitmeliyim?” gibi basit mantık sorularında çuvallayabiliyor.
• Neden Kodlama ve Matematik Hızlı Gelişiyor? Çünkü bu alanlar “doğrulanabilir” (verifiable) alanlardır. Bir kodun çalışıp çalışmadığını veya bir matematik denkleminin doğru olup olmadığını sistem otomatik olarak test edebilir. Bu da yapay zekanın kendi kendini pekiştirmeli öğrenme (reinforcement learning) ile hızla eğitilmesini sağlar.

“Vibe Coding” vs. Ajan Mühendisliği (Agentic Engineering)

Karpathy bu iki kavram arasındaki ince ama önemli farka dikkat çekiyor:

• Vibe Coding: Herkesin yazılım üretebilmesini sağlar. Sektörün tabanını yükseltir. Amatörler için harikadır.
• Ajan Mühendisliği: Profesyonel yazılım geliştirmenin yeni adıdır. Yapay zeka ajanları hata yapabilen (stochastic) yapılardır. Ajan Mühendisliği, bu hata yapabilen ajanların bir araya gelip güvenilir, yüksek kaliteli ve kurumsal seviyede yazılımlar üretmesini sağlayan, kalite çıtasını (tavanı) koruyan yeni bir mühendislik disiplinidir.

İnsanların Rolü Ne Olacak?

Röportajın en vurucu noktası ise eğitimin ve insanın rolünün geleceği üzerineydi: “Düşünmeyi dış kaynaklara (yapay zekaya) devredebilirsiniz, ancak anlamayı devredemezsiniz.”

Karpathy, yapay zekanın bir sihirli değnek olmadığını belirtiyor. Bir ajana basitçe “Bana bir Twitter klonu yap” diyemezsiniz. İnsanın görevi; estetik lezzetli, ürün vizyonunu, mimari kararları belirlemek ve en önemlisi yapay zekaya adım adım, olağanüstü detaylı “spesifikasyonlar (spec)” yazmaktır. Kod yazma ameleliği yapay zekaya geçerken; yönetmenlik, vizyonerlik ve “ne yapılacağını anlama” işi tamamen insanda kalacaktır.

28. Cursor Çalışma Ağaçları (Worktrees): 200 Satırlık Beceri ile 12.000 Satırlık Kodu Silme, David Gomes

Bu sunum, David Gomes tarafından yapılmış olup, temel olarak “Markdown’ın nasıl yeni bir kodlama biçimi haline geldiğini” ve yapay zeka destekli kod editörü Cursor’ın karmaşık bir yazılım mimarisini nasıl basit bir metin istemine (prompt) dönüştürdüğünü anlatmaktadır.

Sunumun detaylı özeti şu şekildedir:

1. Giriş ve Temel Fikir

Cursor ekibi, daha önce uygulamaya entegre ettikleri ve yaklaşık 15.000 satır koddan (LoC) oluşan bir özelliği, sadece 200 satırlık bir Markdown dosyasıyla (bir “Ajan Yeteneği / Agent Skill”) değiştirmeyi başardı. Bu dönüşüm, yapay zeka ajanlarını yönlendirmenin geleneksel kod yazmaktan daha verimli olabileceğini kanıtlıyor.

2. Arka Plan: Git Worktrees ve Cursor

Sunumun odaklandığı özellik Git Worktrees entegrasyonudur.

• Git Worktree Nedir? Bir deponun (repository) izole edilmiş paralel kopyalarıdır. Farklı yapay zeka ajanlarının, ana projenizi bozmadan aynı anda farklı görevler üzerinde (veya aynı görev üzerinde) çalışmasına olanak tanır.
• Best of N (N’in En İyisi): Cursor’ın bu altyapıyı kullanarak sunduğu bir özelliktir. Aynı görevi (örneğin GPT-4, Claude Opus, Gemini gibi) farklı modellere aynı anda verirsiniz. Modeller kendi izole Worktree’lerinde çalışır ve sonunda sonuçları kıyaslayarak en iyisini seçebilirsiniz.

3. Eski Sistem vs. Yeni Sistem

• Eski İmplementasyon (Ekim 2023): Worktree yönetimi, ajanların izolasyonu, temizlik (cleanup) işlemleri ve sistem hatırlatıcıları gibi her şey geleneksel kodla yazılmıştı. Çok fazla bağımlılık, test ve karmaşıklık içeriyordu (yaklaşık 15.000 satır kod).
• Yeni İmplementasyon: Tüm bu kod silindi. Bunun yerine Agent Skills (Ajan Yetenekleri) ve Subagents (Alt Ajanlar) adı verilen iki temel yapı taşı kullanılarak sistem yeniden inşa edildi.

4. Yeni Sistem Nasıl Çalışıyor? (Markdown ile Kodlama)

Yeni sistemde kullanıcılar arayüzdeki bir menü yerine sohbete /worktree veya /best-of-n yazarak komut veriyorlar. Bu komutlar aslında Cursor’ın sunucularında barınan Markdown formatındaki prompt’ları (istemleri) tetikliyor.

Örneğin /worktree komutunu çalıştırdığınızda, sisteme verilen 40 satırlık Markdown komutu ajana şunları söylüyor:

1. Bir alt ajan (subagent) oluştur.
2. Bu alt ajan için yeni bir worktree yarat.
3. Varsa kurulum komutlarını (setup scripts) çalıştır.
4. En önemlisi: Sürekli o dizinde kal ve kesinlikle ana projeyi (primary checkout) değiştirme.

/best-of-n komutu ise ana modele (parent agent), belirtilen her model için birer alt ajan ve worktree oluşturmasını, onlar işini bitirdiğinde sonuçları kullanıcıya bir tablo halinde özetlemesini emrediyor.

5. Yeni Sistemin Avantajları (Pros)

1. Bakım Kolaylığı: Binlerce satır kod yerine sadece 40–200 satırlık bir Markdown promptunu güncellemek yeterli. Prompt güncellendiğinde kullanıcılar anında yeni versiyonu kullanabiliyor.
2. Esneklik: Kullanıcı, sohbetin ortasında aniden bir worktree oluşturup oraya geçiş yapabiliyor.
3. Çoklu Repo Desteği: Eski sistemde çalışmayan birden fazla repoya sahip (örneğin frontend ve backend’in ayrı repolarda olduğu) projelerde artık sorunsuz çalışıyor.
4. Daha İyi Değerlendirme: “Best of N” özelliğinde kullanıcılar artık ana ajana “Claude’un yaptığı şu kısımla, GPT’nin yaptığı bu kısmı birleştir” diyebiliyor. Eski arayüzde bu mümkün değildi, sadece bir modeli seçmek zorundaydınız.

6. Yeni Sistemin Dezavantajları (Cons)

1. Ajanın Yoldan Çıkması: Modellerin (özellikle Haiku gibi daha küçük modellerin) uzun süren oturumlarda verilen Markdown kurallarını unutup ana proje dizinine müdahale etmeye başlaması en büyük sorun.
2. Yavaşlık Hissi: Ajanın worktree’yi yaratma adımlarını kullanıcının sohbette metin olarak izlemesi, eski arayüzdeki butona basma hissine göre daha yavaş hissettiriyor.
3. Keşfedilebilirlik: Eskiden arayüzde açıkça görünen bir özellik, artık sadece komutları bilen “uzman” kullanıcıların (power users) erişebileceği bir araca dönüştü.

7. Sistemi İyileştirme Planları (Evals ve RL)

Dezavantajları gidermek için ekip şu adımları atıyor:

• Değerlendirmeler (Evals): Ajanın doğru dizinde kalıp kalmadığını, ana dosyaları değiştirip değiştirmediğini otomatik olarak test eden sistemler yazıldı.
• Pekiştirmeli Öğrenme (RL: Reinforcement Learning): Cursor’ın kendi eğittiği “Composer” modeli, bu yeni Evals testleri kullanılarak eğitilecek. Böylece Cursor’ın modelleri, izolasyon kurallarına uymayı geleneksel modellere göre çok daha iyi öğrenecek.

8. Sırada Ne Var?

• Cursor 3.0 ile gelen yeni “Composer” (Ajan Penceresi) arayüzünde, worktree özelliğinin daha entegre (native) bir şekilde sunulması planlanıyor.
• Sadece Git Worktree üzerinden değil, bilgisayar üzerinde lokal paralelleştirme yapabilecek alternatif yöntemler üzerinde de prototip çalışmaları yürütülüyor.

Özetle Sunumun Mesajı: Yapay zeka sistemleri geliştikçe, eskiden binlerce satır kod ve karmaşık kullanıcı arayüzleri gerektiren mantıksal işlemler, modellere ne yapması gerektiğini anlatan iyi yazılmış Markdown kurallarıyla (prompt engineering) çok daha az maliyetle ve esnek bir şekilde çözülebilmektedir.

29. Öncü Küçük Modeller Eğitirken Öğrendiğim Her Şey, Maxime Labonne, Liquid AI

Bu video, Liquid AI şirketinde Ön Eğitim (Pre-training) Başkanı olarak görev yapan Maxime Labonne’un, küçük boyutlu ve cihaz içi (edge) yapay zeka modellerini (1B civarı boyutlarda) eğitirken edindiği tecrübeleri anlattığı bir sunumdur.

Sunumun temel tezi şudur: Küçük modeller, büyük modellerin sadece küçültülmüş birer kopyası değildir; onlara has zorlukları ve özel mimari ihtiyaçları vardır.

İşte sunumun öne çıkan ana başlıkları ve Türkçe özeti:

1. Küçük (Edge) Modellerin Temel Özellikleri:

• Bellek Kısıtlaması (Memory-bound): Telefon veya araba gibi cihazlarda çalıştıkları için donanım limitlerine tabidirler. Bu nedenle büyük modellere kıyasla “bilgi kapasiteleri” düşüktür.
• Görev Odaklılık (Task-specific): ChatGPT gibi genel amaçlı sohbet botları olmak yerine, belirli görevlerde (örneğin metin özetleme veya araç kullanma) uzmanlaşmaya çok daha uygundurlar.
• Düşük Gecikme Hassasiyeti (Latency sensitive): Cihaz üzerinde anında (100 milisaniyenin altında) tepki vermeleri gerekir.

2. Mimari Farklılıklar ve Yenilikler:

• Labonne, rakip küçük modellerin (Gemma 3 veya Qwen gibi) parametrelerinin çok büyük bir kısmını (%29 ile %63 arası) sadece kelimeleri anlamlandırmaya yarayan “embedding” (yerleştirme) katmanına harcadığını belirtiyor.
• Liquid AI’nin geliştirdiği LFM 2.5 mimarisinde ise, “Kısa Konvolüsyon” (Short Convolution) adı verilen bir teknik kullanılarak bu katman %19'a düşürülmüştür. Bu sayede model, asıl “akıl yürütme” işlemlerine daha fazla parametre ayırabilmekte, daha az bellek tüketmekte ve çok daha hızlı çalışabilmektedir.

3. Eğitim Süreci (Geleneksel Kuralları Yıkmak):

• Ön Eğitim (Pre-training): Genel kabul gören yapay zeka ölçeklendirme yasalarına (Chinchilla yasası) göre, küçük modelleri çok fazla veriyle eğitmek bir noktadan sonra gereksizdir. Ancak Liquid AI, 350 milyon parametreli çok küçük bir modeli tam 28 Trilyon token ile eğitmiş ve modelin performansının artmaya devam ettiğini kanıtlamıştır.
• Eğitim Sonrası (Post-training): Modeller, Denetimli İnce Ayar (SFT) ile belirli görevlerde uzmanlaştırılır.

4. Yeni Bir Sorun: “Doom Looping” (Sonsuz Tekrar Döngüsü)

• Küçük modellerde ve özellikle matematik/mantık gibi zor görevlerde modelin aynı kelimeleri veya cümleleri sonsuza dek tekrarlamaya başlaması (Doom Looping) sık karşılaşılan bir sorundur.
• Çözüm: Liquid AI bu sorunu iki aşamada çözer. İlk olarak, modeli eğitirken kasıtlı olarak böyle sonsuz döngüye giren hatalı yanıtlar üretirler ve modele bu yanıtları “reddetmeyi” öğretirler. İkinci olarak, Pekiştirmeli Öğrenme (RL) aşamasında model aynı kelimeleri tekrar ettiğinde ona “ceza” (negatif ödül) verirler.

5. Bilgi Eksikliğini “Ajan (Agentic) Araçlar” ile Çözmek:

• Küçük modellerin içsel bilgi kapasitesi düşük olduğu için, bilmedikleri konularda halüsinasyon görme (uydurma) riskleri yüksektir.
• Ancak küçük modeller, dış araçları (web araması yapmak, Python kodu çalıştırmak vb.) kullanma konusunda şaşırtıcı derecede başarılıdır.
• Modelin bilmediği bir şeyi uydurması yerine internetten arama yapması sağlanarak, küçük modellerin en büyük zayıflığı ortadan kaldırılabilir.

Özetle; Uç cihaz (edge) modellerini eğitmek kendine has mimari ve veri zorlukları içerir. Ancak bu küçük modeller, doğru eğitildiklerinde ve web arama/kod çalıştırma gibi ajan (agentic) yeteneklerle donatıldıklarında son derece güçlü, hızlı ve verimli hale gelirler.

30. LLM kod üretimi başarısız oluyor ve bunları nasıl durdurabiliriz, Danilo Campos, PostHog

Bu sunum, PostHog şirketinde çalışan Danilo’nun, yapay zeka tabanlı otonom kod yazma ajanlarının (LLM codegen agents) gerçek dünyada neden başarısız olduğunu ve bu sorunların nasıl çözülebileceğini anlattığı teknik bir konuşmadır.

Danilo, kullanıcıların projelerine PostHog’u otomatik olarak entegre eden “PostHog Wizard” adlı aracı geliştirirken karşılaştıkları 6 temel sorunu ve buldukları çözümleri şu şekilde özetliyor:

1. Model Eskimesi (Model Rot)

• Sorun: Yapay zeka modellerinin eğitimi maliyetli ve uzun sürer. Bu nedenle modeller genellikle geçmiş bir tarihte takılı kalır ve güncel kütüphaneleri, API’leri veya dokümantasyonları bilemezler.
• Çözüm: Güncel dokümantasyonları taze ve taze olarak (Markdown formatında) çekip yapay zekaya doğrudan bağlam (context) olarak sunmak. Yapay zeka ajanının, neyi entegre etmesi gerektiğini anlaması için güncel dökümanlar arasından seçim yapabileceği araçlara sahip olması sağlanır.

2. Kötü Mimari (Bad Architecture)

• Sorun: Yapay zeka ajanı, kodu teknik olarak doğru yazsa bile projenin genel mimarisine ve standartlarına uymayan mantıksız yapılar kurabilir.
• Çözüm: PostHog ekibi buna “Model Uçaklar” (Model Airplanes) adını veriyor. Bunlar, gerçek ve karmaşık uygulamalar yerine, farklı framework’lerde yazılmış basitleştirilmiş şablon uygulamalardır. Ajan, bu şablonları referans alarak entegrasyonun gerçekte nasıl bir yapıya sahip olması gerektiğini öğrenir.

3. Doğaçlama (Improvisation)

• Sorun: Ajana doğrudan “PostHog’u entegre et” gibi büyük bir görev verirseniz, yapay zeka yaratıcılığını kullanarak öngörülemeyen, yanlış ve uydurma çözümler (halüsinasyon) üretebilir.
• Çözüm: “Ekmek Kırıntıları” (Breadcrumbing) yöntemi. Ajanı adım adım yönlendirmek gerekir. Önce “Bana projedeki giriş (login) dosyasını bul” denir. Sonra “Burada hangi olaylar (events) izlenebilir, kod yazmadan sadece listele” denir. En sonunda kod yazması istenir. Görev parçalara bölünerek kontrol sağlanır.

4. İnsan Hatası (Human Error)

• Sorun: Bazen ajanın başarısız olmasının sebebi geliştiricilerdir. İnsanlar, ajana birbirini tutmayan komutlar verebilir veya var olmayan bir aracı kullanmasını isteyebilir. Ajanın hafızası kısıtlıdır ve kafa karışıklığı yaşayabilir.
• Çözüm: Çalışma bittikten sonra ajana “Seni daha başarılı kılmak için biz neyi farklı yapabilirdik?” diye sormak. Yapay zeka genellikle “Benden şu aracı istedin ama bana o araca erişim vermemişsin” gibi insan hatalarını doğrudan tespit edip söyleyebilmektedir.

5. Güvenlik ve Riskler (Shenanigans)

• Sorun: Otonom bir ajanı kullanıcının makinesinde çalıştırmak ciddi bir güvenlik riskidir. Ajan, yetkisi dışında .env gibi hassas şifrelerin bulunduğu dosyaları okuyup buluta sızdırabilir.
• Çözüm: Araç (Tool) kullanımını çok katı bir şekilde kısıtlamak. Ajana bir dosyayı tamamen okuma yetkisi vermek yerine; sadece “bu dosyada şu değişken var mı?” diye kontrol eden ve “dosyanın sonuna şu satırı ekle” (append) komutunu çalıştıran spesifik ve kısıtlı araçlar verilir.

6. Aşırı Mühendislik (Overengineering)

• Sorun: Yazılımcılar genellikle sorunları karmaşık kod yapıları kurarak çözmeye eğilimlidir. Ancak yapay zeka ajanlarını karmaşık kodlarla yönlendirmek veya aşırı kısıtlamak esnekliği öldürür.
• Çözüm: Kod yerine “Düz Metin” (Prose) kullanmak. PostHog Wizard’ın mimarisinin %90'ı Markdown dosyalarından (düz metin), geri kalanı ise araçlardan oluşur. Düz metin kullanmak, yarın daha zeki bir yapay zeka modeli (örn. Claude’un yeni sürümü) çıktığında sistemin anında o modelle çok daha yetenekli hale gelmesini sağlar.

Özetle; Danilo, otonom yapay zeka kod yazıcılarının başarılı olması için onlara büyük görevler vermek yerine; güncel bağlam sunulması, basit şablonlarla eğitilmesi, adım adım yönlendirilmesi, güvenlik sınırlarının net çizilmesi ve sistemin karmaşık kodlar yerine düz metinlerle (yönergelerle) tasarlanması gerektiğini savunmaktadır.

31. Diğer Her Şey İçin Ajanlar, swyx

Bu sunum, AI Engineer konferanslarının kurucu ortağı swyx (Shawn Wang) tarafından yapılmış olup, temel olarak “Yapay zeka mühendisliği konferansını (ve 9 kişilik küçük bir işletmeyi) yapay zeka ajanları kullanarak nasıl inşa ettiklerini” ve yapay zeka kodlama ajanı Devin’in sadece kod yazmak için değil; tasarım, operasyon ve günlük iş süreçlerinde nasıl devrim yarattığını anlatmaktadır.

Sunumun detaylı özeti şu şekildedir:

1. Giriş ve Temel Fikir (Küçük Takımlar ve AGI Hapı) Swyx, sunumuna “Küçük Takımlar” (Tiny Teams , az çalışanla yüksek gelir elde eden şirketler) kavramına odaklanarak başlıyor. Ekibinin “AGI Hapını yuttuğunu” (yapay zeka ajanlarını işin her aşamasına radikal bir şekilde entegre etmeyi) belirten Swyx, temel fikrin şu olduğunu vurguluyor: Yapay zeka ajanları artık sadece kod yazmak için değil, şirketteki insan kaynağının verimliliğini artırmak için “her şey” alanında kullanılabilir.

2. Eski Sistem vs. Yeni Sistem

• Eski Sistem (Geleneksel): Konferansın web sitesi ve operasyonları tamamen yapay zeka barındırmayan geleneksel bir teknoloji yığınıyla (Figma, React, Vercel, Supabase, Google Sheets) yönetiliyordu.
• Yeni Sistem (Ajan Entegrasyonu): Kodlama ajanı Devin, şirketin Slack kanalına entegre edildi. Artık ayrı bir araç gibi değil, ekibin doğrudan komut alabilen bir üyesi gibi çalışmaya başladı.

3. Tasarımcılar ve Ajanların İşbirliği

• Figma’dan Koda: Devin doğrudan Figma’ya bağlandı. Tasarımcı arayüzü hazırladı ve Devin bunu insan müdahalesi olmadan pikseli pikseline mükemmel çalışan bir web sitesine dönüştürdü.
• Teknik Olmayan Kullanıcılar: En büyük kırılma noktası, teknik olmayan (kod yazmayı bilmeyen) tasarımcıların Slack üzerinden Devin ile sohbet ederek ve basit çizimler göndererek siteyi güncelleyebilmesi oldu.
• Bu sayede tasarımcılar “yazılımcı engelini” (Swyx’in kod yazmasını beklemeyi) aşarak kendi fikirlerini anında hayata geçirdiler. İşten keyif almaya başlayan tasarımcılar, siteye kendi inisiyatifleriyle eğlenceli “Sürpriz Yumurtalar” (Easter Eggs) ve viral tasarım trendleri eklemeye başladılar.

4. Operasyon, CMS ve Angarya İşlerin Yönetimi

• Angarya İşler (Yak Shaving): Ortam kurulumu, bağımlılıkların (dependencies) yüklenmesi gibi yazılımcıların nefret ettiği sıkıcı ve oyalayıcı işler ajanlara devredildi. Ajanların paralel çalışabilme yeteneği büyük zaman tasarrufu sağladı.
• CMS Olarak Ajanlar: Ekip, eski karmaşık İçerik Yönetim Sistemlerini (CMS) çöpe attı. Bunun yerine, kod tabanını “tek doğru kaynak” kabul ettiler. Örneğin, bir konferans konuşmacısının bilgileri değişeceğinde, Swyx sadece gelen e-postayı Slack’te Devin’e yönlendiriyor (“Şunu hallet” diyerek) ve Devin kodu güncelleyip yayına alıyor. Bu sayede 9 kişilik bir ekip, binlerce katılımcısı olan bir konferansı rahatça yönetebiliyor.

5. Fiziksel Satın Alımlar, ETL ve Araştırma

• Satın Alma: Swyx, konferans alanı için viral bir tweetten esinlenerek “dev bir şişme ıstakoz” almak istediğinde bu görevi Devin’e verdi. Devin internette araştırma yaptı, İngiltere’deki satıcıları buldu, telefon numaraları ve e-posta adreslerini listeleyerek satın alma sürecini hazırladı.
• Araştırma ve Kürasyon: “Town” adlı başka bir ajan kullanılarak konferans konuşmacılarının araştırması yapıldı ve Notion belgeleri otomatik olarak oluşturuldu.
• Veri Senkronizasyonu (ETL): Dış tedarikçilerden API anahtarları aracılığıyla veri çekme ve senkronize etme işlemleri de tamamen ajanlara bırakıldı.

6. SaaS Uygulamalarını Ajanlarla Değiştirmek Ekip, yapay zeka ajanlarının yeteneklerine o kadar güvenir hale geldi ki, dışarıdan hazır SaaS (Hizmet Olarak Yazılım) araçlarına para ödemek yerine, ihtiyaç duydukları yönetim araçlarını kendi içlerinde ajanlara sıfırdan yazdırmaya başladılar.

7. Gelecek Trendleri: Ajan Deneyimi (Agent Experience) Swyx, sektördeki büyük bir değişime dikkat çekiyor: Vercel gibi platformların trafiğinin %60'ı artık insanlardan değil, botlardan/ajanlardan geliyor. Bu durum, geleneksel kullanıcı arayüzlerinin (UI) ve gösterge panellerinin (dashboards) önemini yitirmekte olduğunu, yerini ajanların doğrudan kullanabileceği arayüzlere bıraktığını gösteriyor.

Özetle Sunumun Mesajı: Yapay zeka ajanları (Devin vb.) “kodlama hapishanesinden kaçmıştır”. Artık sadece yazılımcıların daha hızlı kod yazmasını sağlayan araçlar değil; tasarımcılar, operasyon yöneticileri ve tüm ekip üyeleri için “her şeyi yapan” otonom çalışma arkadaşlarına dönüşmüşlerdir. Şirketler, çalışanlarının verimliliğini artırmak ve iş süreçlerindeki dar boğazları ortadan kaldırmak için yapay zeka ajanlarını standart bir iş aracı olarak benimsemelidir.

32. Gemma 4: Öncü Cihaz İçi Modeller için Yaptığımız Her Şey, Cassidy Hardin, Google DeepMind

Google DeepMind, açık kaynaklı modeller ailesinin en yeni üyesi olan Gemma 4'ü tanıttı. Gemma 4, kendi boyutlarındaki rakiplerini (ve kendisinden çok daha büyük modelleri) geride bırakan, geliştiriciler için daha erişilebilir olması adına Apache 2.0 lisansı ile sunulan bir model ailesidir.

Gemma 4 ailesi dört farklı modelden oluşuyor:

• Küçük ve Verimli Modeller (2B ve 4B): Telefonlar, tabletler ve dizüstü bilgisayarlarda (cihaz içi, on-device) yerel olarak çalışmak üzere özel olarak optimize edilmiştir.
• Büyük Modeller (26B ve 31B): Karmaşık akıl yürütme, kodlama ve otonom iş akışları için tasarlanmıştır. Özellikle 31B modeli, kendisinden 20 kat büyük modellerle rekabet ederek küresel AI liderlik tablosunda üst sıralara yerleşmiştir.

Mimari Yenilikler ve Verimlilik Modellerin küçük cihazlarda bile yüksek performans göstermesi için mimaride önemli değişiklikler yapılmıştır:

• Dikkat Mekanizması (Attention): Bellek kullanımını azaltmak için “Yerel” (Local) ve “Küresel” (Global) dikkat katmanları harmanlanmıştır (5'e 1 oranında). Ayrıca, küresel katmanlarda bellek tasarrufu sağlayan Gruplandırılmış Sorgu Dikkati (Grouped Query Attention: GQA) kullanılmıştır.
• Uzmanların Karışımı (MoE): 26B modeli, Gemma ailesinin ilk MoE (Mixture of Experts) modelidir. 128 farklı uzmandan oluşur ancak her işlemde yalnızca 8 uzman aktif olur. Bu, modelin hem çok akıllı olmasını hem de çalışırken çok az kaynak tüketmesini sağlar.
• Katman Başına Gömme (Per-Layer Embeddings: PLE): 2B ve 4B modellerinde, sınırlı cihaz hafızasını (VRAM) tüketmemek için kelime vektörleri (embeddings) flash bellekte saklanacak şekilde optimize edilmiştir.

Çoklu Modalite (Multimodal Yetenekler) Gemma 4, baştan sona metin, görüntü ve ses işleyebilecek şekilde tasarlanmıştır:

• Gelişmiş Görüntü (Vision) İşleme: Önceki sürümlerin aksine, Gemma 4 görüntüleri karelere sıkıştırmak yerine değişken en-boy oranlarını ve değişken çözünürlükleri destekler. Kullanıcılar, nesne tanıma (OCR) gibi detay gerektiren işler için yüksek çözünürlük (daha fazla token) veya basit işler için düşük çözünürlük seçebilir.
• Ses İşleme (Audio): 2B ve 4B modellerine ses işleme yeteneği eklenmiştir. Ses dosyaları doğrudan modele verilerek konuşma tanıma ve çeviri gibi görevler cihaz üzerinde hızlıca yapılabilir.

Gemma 4 modelleri an itibarıyla Hugging Face, Kaggle ve Ollama üzerinden yerel kullanım için indirilebilir veya Google Cloud (AI Studio, Vertex AI) üzerinden bulut tabanlı olarak kullanılabilir.

33. Değerlendirme platformları oluşturmak neden zor, Phil Hetzel, Braintrust

Neden Değerlendirme (Eval) Yapmalıyız? Büyük Dil Modelleri (LLM’ler) doğaları gereği tahmin edilemez ve değişkendir. Günümüzde şirketler müşterileriyle etkileşim kurmak için giderek daha fazla yapay zeka ajanlarına güvenmektedir. Bu ajanların üretime (production) alınmadan önce ve üretimdeyken nasıl davranacağından emin olmak; marka itibarını korumak, yasal uyumluluğu sağlamak ve maliyetleri kontrol altında tutmak için hayati önem taşır.

Değerlendirme Platformu Oluşturmanın Aşamaları:

1. E-Tablolar (Spreadsheets) ile Başlangıç: Çoğu ekip sürece bir Excel/Google e-tablosu ve basit bir döngü ile başlar. Başlamak için engel olmaması güzeldir ancak bu yöntem yavaştır, analitik imkanı sunmaz, denemeler (experimentation) yapmaktan çok sadece dokümantasyon işlevi görür ve ekip çalışmasına uygun değildir.
2. Özel Arayüzler (UI) Geliştirme: Ekipler büyüdükçe kendi özel kullanıcı arayüzlerini ve basit veri tabanlarını oluştururlar. Bu aşama, teknik olmayan kişilerin (ürün yöneticileri vb.) de sürece dahil olmasını sağlar. Ancak bu sistemlerin yönetimi zordur, gerçek bir test/deneme alanı sunmaktan ziyade bir raporlama aracı olarak kalırlar.
3. “Volan” (Flywheel) Döngüsünü Kurmak: Gerçek başarı, üretim ortamındaki verileri (gözlemlenebilirlik) alıp, başarısızlık durumlarını analiz ederek bunları çevrimdışı testlere (evals) aktarmaktır. Bu sayede ajan sürekli olarak gerçek dünya verileriyle eğitilir ve iyileştirilir.

Asıl Sorun Bir “Sistem Mühendisliği” Problemidir Hetzel’in en çok vurguladığı nokta, iyi bir değerlendirme platformu oluşturmanın sadece basit bir arayüz (UI/UX) sorunu olmadığıdır. Bu, devasa bir veri ve altyapı sorunudur. Nedeni ise şunlardır:

• Yapay zeka ajanlarının oluşturduğu izleme verileri (traces), geleneksel yazılım loglarına göre çok daha büyüktür (bazen 10–20 MB’a ulaşabilir).
• Veriler genellikle yapılandırılmamıştır (unstructured) ve yoğun metin içerir.
• Bu devasa veriler üzerinde gerçek zamanlı tam metin araması (full-text search) yapmak, çok modlu girdileri (ses, video, vb.) yönetmek ve veri maskeleme gibi güvenlik/erişim kontrollerini (RBAC) sağlamak için birden fazla karmaşık veri tabanı ve depolama mimarisinin bir arada kullanılması gerekir.

Özetle Hetzel; yapay zeka ajanlarını güvenilir bir şekilde ölçeklendirmenin, arkada son derece güçlü, esnek ve yüksek hacimli veriyi işleyebilen bir sistem altyapısı kurmaktan geçtiğini belirtmektedir.

34. GitHub’ın Uzak MCP Sunucusunu Ölçeklendirirken Alınan Dersler, Sam Morrow, GitHub

Bu video, GitHub’da Kıdemli Yazılım Mühendisi olan Sam Morrow’un GitHub MCP (Model Context Protocol) Sunucusunu inşa ederken ve ölçeklendirirken karşılaştıkları zorlukları ve buldukları çözümleri anlattığı bir sunumdur.

İşte konuşmanın temel noktalarının Türkçe özeti:

1. Temel Sorun: “Daha Fazla Araç, Daha İyi Ajan Demek Değildir”

• GitHub, MCP sunucusunu ilk başlattığında çok büyük bir ilgi gördü ve platformdaki boşlukları doldurmak için 100'den fazla araç (tool) eklediler.
• Ancak çok fazla aracın yapay zeka ajanlarının kafasını karıştırdığını ve modelin “bağlam penceresini” (context window) hızla doldurduğunu fark ettiler.
• Bunu çözmek için “Araç Kümeleri” ve “Dinamik Seçim” gibi gruplandırma özellikleri geliştirdiler, ancak hiçbir kullanıcının JSON ayarlarını değiştirmediğini, herkesin varsayılan (default) ayarları kullandığını gördüler.

2. Çözüm: Bağlam Azaltımı (Context Reduction) ve Hata Toleransı

• Kullanıcıların ayar yapmasını beklemek yerine varsayılan deneyimi iyileştirdiler. En çok kullanılan araçları analiz edip, varsayılan araç sayısını 40 civarına düşürdüler.
• Araçların çıktı boyutlarını ciddi şekilde optimize ettiler (Örneğin; “Pull Request” listesi çekerken gereksiz verileri atarak token kullanımını %75'ten fazla azalttılar).
• Yapay zeka ajanlarının yaptığı yaygın hataları (örneğin başlatılmamış bir depoya kod itmeye çalışmak veya ‘main’ yerine ‘master’ yazmak) sunucu tarafında anında ve otomatik olarak düzeltecek mantıklar (intent analizi) kurdular. Bu sayede araçların başarı oranı %95'in üzerine çıktı.

3. Güvenlik ve Kimlik Doğrulama (Authentication)

• Düz metin şifrelerin veya Kişisel Erişim Belirteçlerinin (PAT) yapay zekaya verilmesini büyük bir güvenlik riski (anti-pattern) olarak gördüler.
• Bunun yerine, OAuth 2.1 standardını benimseyerek, ajanlara yalnızca ihtiyaç duydukları kadar yetki (least privilege) verdiler.
• Kapsam Filtreleme (Scope Filtering): Ajanın sahip olduğu yetkiye (OAuth scope) göre, sadece kullanabileceği araçları göstererek gereksiz bağlam tüketimini ve başarısız işlem denemelerini engellediler.
• Sınırsız veri tabanı büyümesine ve kimlik karmaşasına yol açacağı için Dinamik İstemci Kaydı (DCR) sistemini reddettiler.

4. Mimari ve Ölçeklenebilirlik

• Sistem tamamen durumsuz (stateless) bir yapıda çalışıyor ve oturum yönetimi için Redis kullanılıyor.
• Haftada yaklaşık 8 milyon araç çağrısı (tool call) alıyorlar. GitHub Action’ları ve Docker indirmeleri ile birlikte sistem muazzam bir boyuta (11 milyon+ indirme) ulaşmış durumda.

5. Gelecek Öngörüleri

• Sam Morrow, gelecekte MCP sunucularının otomatik olarak keşfedileceğini, araç kullanımının tıpkı Linux terminalindeki “bash pipe” mantığı gibi birbirine bağlanarak daha kompozisyonel hale geleceğini ve verilerin modeller arasında boşa harcanmadan doğrudan araçlar arası aktarılacağını öngörüyor.

Özetle sunum; yapay zeka ajanları için araç (tool) geliştirirken, kullanıcıları ayar yapmaya zorlamak yerine varsayılan deneyimi optimize etmenin, gereksiz verileri filtrelemenin ve güvenliği merkeze almanın önemini vurguluyor.

35. İşbirlikçi Yapay Zeka Mühendisliği: Bir Geliştirici, İki Düzine Ajan, Sıfır Hizalama, Maggie Appleton, GitHub

1. Bireysel Üretkenlik Yanılgısı: Appleton, mevcut yapay zeka kodlama araçlarının (Copilot, Claude vb.) “bir geliştiriciyi bir orduya dönüştürme” (bireysel üretkenliği artırma) fikrine odaklandığını, ancak bunun yanlış bir yaklaşım olduğunu savunuyor. Yazılım geliştirme izole bir süreç değil, bir takım sporudur. “Dokuz kadın, bir ayda bir bebek dünyaya getiremez” mantığıyla, iletişimi ve koordinasyonu çözmeden sadece bireysel çıktıyı artırmanın sorunları daha da kötüleştireceğini belirtiyor.

2. Yeni Darboğaz: Kod Yazmak Değil, Uyum (Alignment): Yapay zeka sayesinde kod yazma (uygulama) süreci giderek hızlanıyor ve ucuzluyor. Artık asıl zorluk “Nasıl inşa edeceğiz?” değil, “Neyi ve neden inşa etmeliyiz?” sorusudur. Ekiplerin ne yapılacağı konusunda hemfikir olması (alignment), sürecin yeni darboğazı haline gelmiştir.

3. İnsan Bağlamının Eksikliği: Yapay zeka ajanlarının (agents) doğru kodu yazabilmesi için projenin iş hedeflerini, politik dinamiklerini, kullanıcı araştırmalarını ve ürün vizyonunu bilmesi gerekir. Ancak bu bilgiler kod tabanında (codebase) değil, insanların kafasındadır. Ajanlar kapalı kapılar ardında kendi başlarına plan yapıp devasa “Pull Request”ler (PR) oluşturduğunda; boşa giden emek, koordinasyon sorunları ve kimsenin incelemek istemediği kod yığınları ortaya çıkar. Mevcut araçlar (Slack, Jira vb.) yapay zeka ajanlarıyla entegre çalışacak şekilde tasarlanmamıştır.

4. Çözüm: Ace (Agent Collaboration Environment , Ajan İşbirliği Ortamı) Prototipi: Appleton, bu sorunları çözmek için GitHub Next ekibinin geliştirdiği “Ace” adlı deneysel prototipi tanıtıyor. Ace’in sunduğu yenilikler şunlardır:

• Çok Oyunculu İşbirliği: Slack, GitHub ve bulut IDE’nin birleşimi gibi olan bu platformda; yazılımcılar, tasarımcılar, ürün yöneticileri ve yapay zeka ajanları aynı sohbet ekranında (session) buluşur.
• Paylaşımlı Bulut Ortamı (Micro-VM): Her görev kendi izole bulut bilgisayarında çalışır. Ekipteki herkes ve yapay zeka, aynı canlı geliştirme sunucusunu ve terminali görür.
• Anlık Geri Bildirim: Yapay zeka kod yazarken, takım üyeleri süreci anlık izleyebilir, müdahale edebilir ve arayüz üzerinden doğrudan ajana komut verebilir. Geri bildirim PR aşamasına bırakılmaz, işin başında yapılır.

5. Sonuç: Yeni Rekabet Avantajı “Kalite” Sunumun ana mesajı; yapay zekanın amacının sadece daha hızlı ve daha fazla (ama muhtemelen kalitesiz) kod yığınları üretmek olmadığıdır. Kod yazma aşamasında yapay zeka sayesinde kazanılan zaman; daha iyi sistem tasarımı yapmak, derinlemesine düşünmek ve yüksek kaliteli mühendislik üretmek için kullanılmalıdır. Kod yazmanın ucuzladığı bir dünyada kalite, yazılımları birbirinden ayıran en önemli unsur olacaktır.

36. Anthropic MCP’leri Nasıl Ölçekliyor (İhtiyacınız Olan Tek Şey Gateway’ler)? , Karan Sampath, Anthropic

Bu video, Anthropic’te Uygulamalı Yapay Zeka Mühendisi olarak çalışan Karan Sampath’ın, kurumsal şirketlerde MCP (Model Context Protocol) kullanımını ve şirketlerin neden bir “Ağ Geçidi”ne (Gateway) ihtiyaç duyduğunu anlattığı bir sunumdur.

İşte sunumun kapsamlı bir özeti:

Temel Problem: İşletmeler İçin Mevcut MCP’lerin Yetersizliği MCP’ler, yapay zeka araçlarını verilere bağlamak için harika bir açık standarttır ve halihazırda binlerce sunucuyu içeren kayıt defterleri (registry) bulunmaktadır. Ancak kurumsal şirketler bunu kullanmaya çalıştığında üç büyük sorunla karşılaşır:

1. Gözlemlenebilirlik (Observability): Hangi çalışanın, hangi sunucuyu ve aracı kullandığını izlemek zordur.
2. Erişim Kontrolü (Access Control): Sadece yetkili kişilerin (veya grupların) belirli sunuculara erişebilmesini sağlamak (RBAC) mevcut yapıda karmaşıktır.
3. Güvenlik (Security): Sunucuların güvenli olduğunu doğrulamak, veri sızıntılarını (exfiltration) engellemek ve dışarıdan gelen istemcilere güvenli erişim sağlamak zordur.

Mevcut Darboğaz (Bottleneck) Şu anki sistemde yazılım ekipleri kendi MCP’lerini geliştirmektedir, ancak bu araçların canlıya alınabilmesi için güvenlik (Security) ve yasal (Legal) ekiplerin onayından geçmesi gerekir. Bu ekipler aşırı iş yükü altında olduğu için süreç tıkanır, aylar sürer ve yapay zeka “ajanları” (agents) potansiyellerine ulaşamaz.

Çözüm: Ağ Geçidi (Gateway) Katmanı Kurmak Karan Sampath’a göre çözüm, her ekibin kendi MCP’sini sıfırdan kurmasını bırakıp bir “Güven Kökü” (Root of Trust) oluşturmaktır. Güvenlik ekibi sadece tek bir platformu (Ağ Geçidini) denetleyip onaylar.

Ağ Geçidi; MCP istemcileri (Claude, IDE’ler, yerel ajanlar) ile MCP sunucuları arasında duran bir “ara katmandır”.

Ağ Geçidinin (Gateway) Kurumlara Sağladığı Avantajlar:

• Merkezi Güvenlik ve Kimlik Doğrulama: Şirket içi SSO (Tekil Oturum Açma) sistemleriyle entegre çalışarak kimin neye erişebileceğini (Rol Bazlı Erişim, RBAC) tek bir merkezden yönetir.
• Hızlı Geliştirme (İterasyon): Ağ geçidi zaten güvenlik ekibinden onay aldığı için, yazılım veya hukuk ekipleri güvenlik engeline takılmadan sadece kendi iş mantıklarına odaklanarak anında yeni MCP’ler oluşturup yayınlayabilirler (Örn: Hazır CLI araçları sayesinde).
• Tam Gözlemlenebilirlik: Tüm veri trafiği bu geçitten aktığı için, şirketler hangi ajanların veya ekiplerin hangi araçları kullandığını tek bir gösterge panelinden denetleyebilir.
• Çoklu Yüzey Desteği (Any Surface): Ağ geçidine bağlanan bir sunucu; aynı anda hem web’deki Claude’da, hem bir yazılımcının kod editöründe (IDE) hem de yerel ajanlarda ekstra ayar gerektirmeden çalışabilir.
• Ölçeklenebilirlik: Ajanların sayısı 10'dan 10.000'e çıktığında bile sistem çökmeden aynı altyapı üzerinden güvenle çalışmaya devam eder.

Büyük Resim (Ana Fikir) Sunumun temel mesajı şudur: Yapay zeka ajan altyapısını (agent harness), şirket verilerinizin bulunduğu katmandan ayırın. Ağ Geçidi sayesinde ajanlar nerede çalışırsa çalışsın, şirketinizin özel verileri ve MCP sunucuları sizin kendi ağınız (network) içinde %100 güvende ve sizin kontrolünüzde kalır. Kurumların başarılı bir yapay zeka entegrasyonu için ortak bir altyapıya (Gateway) yatırım yapmaları şarttır.

37. Modellerin Hala Batırdığı Şeyler Neler?, Peter Gostev, Arena.ai, BullshitBench

Bu video, Arena’da Yapay Zeka Yetenek Lideri olan Peter Gostev’in, yapay zeka modellerinin standart testlerde (benchmark) kusursuz görünmesine rağmen gerçekte hala hangi konularda yetersiz kaldığını anlattığı bir sunumu içermektedir.

İşte sunumun temel noktalarının bir özeti:

1. “AGI Geliyor” Yanılgısı ve Testlerin Yetersizliği Standart yapay zeka performans grafikleri sürekli yukarı doğru giden bir başarı eğrisi çizer. Bu durum insanlarda “Yapay Genel Zeka’ya (AGI) çok yaklaştık” algısı (hatta psikozu) yaratır. Ancak Gostev, mevcut testlerin dar kapsamlı olduğunu ve modellerin gerçek hayattaki yetersizliklerini gizlediğini savunmaktadır.

2. “Saçmalık Testi” (Bullshit Benchmark) Gostev, modellerin mantığını ölçmek için kendi geliştirdiği “Saçmalık Testi”ni sunar. Bu testte modellere teknik terimlerle dolu ama tamamen anlamsız ve mantıksız sorular sorulur (Örn: “Kod deposunun yaşı ile değişken isimlerinin uzunluğu arasındaki farkı nasıl açıklarsın?”).

• Beklenti: Akıllı bir modelin “Bu sorunun mantığı yok, böyle bir ölçüm yapılamaz” demesidir.
• Sonuç: Sadece Anthropic’in yeni Claude modelleri bu konuda çok başarılıdır ve saçmalığı reddeder. GPT ve Gemini gibi popüler modellerin çoğu, bu anlamsız sorulara uydurma ve uzun cevaplar vererek testi geçemez.
• İlginç Bulgu (Düşünme/Reasoning İşe Yaramıyor): OpenAI o1 gibi “akıl yürüten” (düşünen) modeller bu testte çok daha kötü performans gösterir. Çünkü sorunun saçma olduğunu fark etmek yerine, 20 paragraf boyunca kendi kendine akıl yürüterek saçma bir soruya mantıklı bir kılıf bulmaya çalışırlar. Ayrıca modelin parametre boyutunun büyük olması da bu durumu düzeltmez.

3. “İkisi de Kötü” (Both Bad) Metriği ve Kullanıcı Memnuniyetsizliği Gostev, LMSYS Chatbot Arena verilerini kullanarak kullanıcıların iki modelin de cevabını beğenmediği “İkisi de Kötü” oy oranlarını (memnuniyetsizlik oranını) inceler.

• Genel olarak, yıllar içinde memnuniyetsizlik oranı %20'lerden %9'lara düşmüştür. Özellikle Matematik alanında yapay zeka inanılmaz bir ilerleme kaydetmiştir.
• Ancak iş “Uzman” (Expert) seviyesindeki sorulara geldiğinde tablo değişmektedir. Kullanıcıların soruları zorlaştıkça, özellikle tıp, hukuk, finans ve spesifik yazılım alanlarında yapay zeka hala yetersiz kalmaktadır.

4. Yapay Zeka Kodlamada Nerede Çuvallıyor? Yazılım kategorisi alt dallara ayrıldığında, modellerin özellikle Oyun Geliştirme (Gaming) gibi konularda hala çok kötü olduğu görülmektedir. Modeller basit kodları yazabilse de, karmaşık oyun mekanikleri kurmak veya otonom sistemler (ajanlar) tasarlamak gibi yapılandırılmamış, çok adımlı zor görevlerde başarısız olmaktadır.

Sonuç: Gostev’e göre, yapay zekanın sadece testlerdeki “en iyi” performanslarına (grafiklerin en tepesine) bakmak yanıltıcıdır. Modellerin gerçek dünyadaki değerini anlamak için, çuvalladıkları ve kullanıcıları hüsrana uğrattıkları noktalara da (dağılımın en altına) odaklanmak gerekmektedir.

38. Gerçekten Teslimat Yapan Çoklu Ajan Mimarisi , Luke Alvoeiro, Factory

1. Asıl Darboğaz Artık Zeka Değil, İnsan Dikkati Luke’a göre yazılım mühendisliğinde yapay zeka kullanımı için temel sorun modellerin yeterince zeki olmaması değildir. Sorun, insanların bu modellerin ürettiği her bir kodu, özelliği veya testi gözden geçirmek için gereken zamana ve dikkate sahip olmamasıdır. Çözüm; insanın sadece “ne yapılacağını” belirlediği, sistemin ise “nasıl yapılacağını” bularak saatlerce veya günlerce insandan bağımsız (otonom) çalıştığı yapılar kurmaktır.

2. Çoklu Ajan (Multi-Agent) Stratejileri Luke, ajanların birlikte çalışması için literatürdeki beş ana yaklaşımı tanımlıyor:

• Delegasyon: Bir ajanın alt görevler için başka ajanlar yaratması.
• Yaratıcı-Doğrulayıcı (Creator-Verifier): Bir ajanın kodu yazması, farklı bir ajanın ise kontrol etmesi (Böylece kodu yazan ajanın kendi hatasına kör olması engellenir).
• Doğrudan İletişim: Ajanların merkezi bir koordinatör olmadan kendi aralarında konuşması (Ancak durumu takip etmek zordur).
• Müzakere: Ortak kaynaklar (örneğin aynı veritabanı veya kod dosyası) üzerinde ajanların uzlaşması.
• Yayın (Broadcast): Bir ajanın genel durum güncellemelerini herkese duyurması.

3. “Missions” (Görevler) Sistemi ve 3 Temel Rol Factory şirketi, bu stratejileri birleştirerek günlerce kendi kendini düzelterek çalışabilen “Missions” adında bir mimari geliştirmiş. Bu mimari üç ana rolden oluşuyor:

• Orkestratör (Orchestrator): Planlamayı yapar. En kritik özelliği, tek satır kod yazılmadan önce işin bittiğinde nasıl test edileceğini belirleyen yüzlerce maddelik bir “Doğrulama Sözleşmesi” (Validation Contract) hazırlamasıdır.
• İşçiler (Workers): Kodu yazar. Her işçi temiz bir sayfayla başlar, kodu yazar, kaydeder (commit) ve işi devreder.
• Doğrulayıcılar (Validators): İki aşamalı çalışırlar. İlki sözdizimi, testler ve kod incelemesi yapar. İkincisi ise adeta bir Kalite Güvence (QA) mühendisi gibi davranarak uygulamayı başlatır, düğmelere tıklar ve akışın uçtan uca çalışıp çalışmadığını kontrol eder. Önemli nokta: Doğrulayıcılar kodu önceden hiç görmemiştir, bu nedenle tamamen bağımsız ve eleştireldirler.

4. Paralel Yerine Seri Yürütme ve Yapılandırılmış Devir (Handoff) Yazılım geliştirmede birçok ajanın aynı anda kod yazması (paralel çalışma) kodların birbiriyle çakışmasına neden olur. Bu yüzden Missions sistemi seri (sıralı) çalışır. Bir ajan işini bitirdiğinde; nelerin yapıldığını, nelerin yarım kaldığını, hangi komutların çalıştırıldığını ve hangi hataların alındığını içeren yapılandırılmış bir rapor bırakır. Bu sayede sonraki ajan kaldığı yerden hatasız devam edebilir ve sistem günlerce bağlam (context) kaybetmeden kendini onararak çalışabilir.

5. Model Bağımsızlığı (Model Agnostic) Sistem tek bir şirketin modeline (örneğin sadece OpenAI veya Anthropic’e) bağımlı değildir. Planlama için mantık yürütmesi güçlü bir model, kodlama için hızlı bir model, doğrulama için ise yönergeleri sıkı sıkıya takip eden farklı bir model kullanılır. Bu, eğitim verilerinden kaynaklanan önyargıları engeller.

Sonuç ve Etki: Luke, bu sistemle sıfırdan bir “Slack klonu” oluşturdukları ve 16,5 saat süren otonom bir testin başarıyla sonuçlandığını gösteriyor. Bu yaklaşımın amacı mühendisleri ortadan kaldırmak değil; aksine, bir mühendisin aynı anda mikro düzeyde kod yazmak yerine, aynı anda 30 farklı yapay zeka iş akışını (workstream) yönetmesini, mimariye ve asıl zor problemlere odaklanmasını sağlamaktır.

39. Kimsenin İnşa Etmediği Küçük Ölçekli Altyapı Modeli (Bu Nedenle Biz İnşa Ettik) , Filip Makraduli, Superlinked

Bu videoda Superlinked’den Filip Makraduli, yapay zeka ekosisteminde genellikle göz ardı edilen “küçük model çıkarımı” (small-model inference) konusunu ve bu alandaki altyapı eksikliklerini ele alıyor. Ayrıca, bu sorunları çözmek için geliştirdikleri yeni açık kaynaklı araç olan SIE’yi (Superlinked Inference Engine) tanıtıyor.

İşte sunumun öne çıkan temel noktaları:

1. Çıkarım Neden Önemlidir? (Yapay Zeka Ajanları ve İş Akışları İçin) Büyük Dil Modelleri (LLM’ler) çok fazla veriyle beslendiğinde performansları düşer; buna “bağlam çürümesi” (context rot) denir. Küçük modeller; verileri önceden işlemek, bağlamı yönetmek, gömme (embedding) ve yeniden sıralama (reranking) yapmak için kullanılarak LLM’lere yalnızca en alakalı verilerin gitmesini sağlar. Bu, yapay zeka ajanlarının çok daha verimli ve doğru çalışmasını sağlar.

2. Çıkarım (Inference) Ne Değildir?

• Sadece daha fazla GPU eklemek değildir: Küçük modeller bellekte çok az yer kaplar. Her küçük model için ayrı bir GPU tahsis etmek kaynak israfıdır. Modellerin aynı GPU üzerinde anında değiştirilebilmesi (hot-swap) gerekir.
• Sadece basit bir model sunucusu değildir: Sadece vLLM veya TEI gibi bir sunucu kurmak yetmez. Gerçek üretim (production) ortamı; yönlendirme (routing), otomatik ölçeklendirme (autoscaling), sıfıra ölçekleme (scale-to-zero) ve izleme (monitoring) gibi karmaşık bir altyapı gerektirir.

3. Çıkarımın Yin ve Yang’ı Makraduli, başarılı bir çıkarım altyapısının iki temel bileşeni (Yin ve Yang) birleştirmesi gerektiğini savunuyor:

• Yin (Model Desteği): Açık kaynaklı küçük modeller (BERT, Qwen, ColBERT vb.) hızla gelişiyor ve dar kapsamlı görevlerde ücretli API’leri geride bırakıyor. Ancak bu modellerin mimarileri, dikkat (attention) mekanizmaları ve konum kodlamaları (positional encodings) birbirinden farklıdır. Sistemin, yüzlerce farklı model mimarisini destekleyecek şekilde uyarlanabilir olması gerekir.
• Yang (Altyapı ve Kümeleme): Modelleri üretim ortamında çalıştırmak için gereken arka plan mimarisidir. Maliyetleri düşürmek ve verimliliği artırmak için yönlendirme mekanizmaları, kaynak havuzları ve yüke göre otomatik ölçeklendirme sistemleri içerir.

Sonuç: Piyasada bu uçtan uca süreci çözen bir sistem olmadığını fark eden ekip, hem model destek katmanını (Yin) hem de kümeleme/altyapı katmanını (Yang) bir araya getirerek SIE (Superlinked Inference Engine) projesini açık kaynaklı (open-source) olarak yayınlamıştır.

40. Bağlam Yeni Koddur , Patrick Debois, Tessl

Patrick Debois’nın YZ ajanları ile yazılım geliştirme sürecindeki paradigma değişimi anlatılmaktadır. Sunumun temel argümanı, “Bağlamın (Context) artık yeni Kod olduğudur.”

Debois, yapay zeka kodlama ajanlarını (coding agents) yönlendirmek için yazdığımız komutların (prompt, instructions, specs) artık kodun kendisi kadar önemli olduğunu belirtiyor. Bu nedenle, geleneksel Yazılım Geliştirme Yaşam Döngüsü’ne (SDLC) benzer şekilde, bir Bağlam Geliştirme Yaşam Döngüsü (Context Development Lifecycle : CDLC) kurulması gerektiğini savunuyor.

Bu döngü 4 temel aşamadan oluşmaktadır:

1. Generate (Bağlam Üretme)

Artık doğrudan kod yazmak yerine, YZ ajanlarına ne yapacaklarını anlatan bağlamlar üretiyoruz.

• Basitten Gelişmişe: Süreç, basit istemler yazmaktan çıkıp, tüm projede tekrar kullanılabilen standart talimat dosyalarına (agent.md, claude.md vb.) evriliyor.
• Dış Kaynakları Bağlama: Yapay zekanın halüsinasyon görmesini (yanlış bilgi uydurmasını) engellemek için güncel API dokümantasyonları, GitHub kodları, Jira biletleri veya Slack mesajları (MCP : Model Context Protocol gibi araçlarla) bağlama dahil ediliyor.
• Spesifikasyon Odaklı Geliştirme: Ne yapılacağının adım adım tanımlandığı detaylı spesifikasyonlar hazırlanıyor.

2. Evaluate (Bağlamı Test Etme ve Değerlendirme)

Yazdığınız istemlerde/bağlamda yaptığınız ufak bir değişiklik tüm sistemi bozabilir. Bu yüzden bağlamın da kod gibi test edilmesi gerekir.

• Bağlam Linting’i ve Grammarly’si: Yazılan talimatların uzunluğu, formatı veya ajan tarafından tam olarak anlaşılıp anlaşılamayacağı test ediliyor.
• Jüri Olarak LLM (LLM-as-a-judge): Üretilen kodun kurallara uyup uymadığını (örneğin; “kod istenen kuralla başlıyor mu?”) test etmek için yine başka bir LLM kullanılıyor.
• CI/CD Entegrasyonu: LLM’ler her zaman aynı sonucu vermediği (non-deterministik olduğu) için, testler tek sefer yerine örneğin 5 kez çalıştırılıyor ve bir “hata bütçesi” (error budget) kapsamında değerlendiriliyor.

3. Distribute (Bağlamı Paketleme ve Dağıtma)

İyi çalışan bir bağlam veya “yetenek” (skill) elde edildiğinde, bunun sadece sizin bilgisayarınızda kalmaması, ekiple paylaşılması gerekir.

• Bağlam Paketleri: Bağlamlar, tıpkı yazılım kütüphaneleri (npm paketleri gibi) paketlenerek “Yetenek Kayıt Defterlerinde” (Skill Registries) toplanıyor.
• Bağımlılık ve Güvenlik: Bu paketlerin versiyonlanması, birbirleriyle olan bağımlılıklarının yönetilmesi ve içlerinde zararlı komutlar (prompt injection) olup olmadığının güvenlik araçlarıyla taranması gerekiyor.

4. Observe (Canlıda Gözlemleme ve İzleme)

Ürettiğiniz bağlamın organizasyon içinde gerçekte nasıl performans gösterdiğini izlemek kritik bir adımdır.

• Ajan Logları ve İzleri (Traces): Ajanın nerede takıldığını, hangi kararları neden aldığını görmek için loglar incelenir.
• Geri Bildirim Döngüsü: Eğer bir ajan bir görevi yaparken sürekli olarak aynı eksik bilgi yüzünden hata veriyorsa, bu durum tespit edilip organizasyonun ortak bağlamına (context) eklenmelidir.
• Bağlam Filtreleri (WAF): Ajanları korumak ve güvenli sınırlar (sandbox) içinde tutmak için tıpkı web güvenlik duvarları (WAF) gibi bağlam filtreleri kullanılmalıdır.

Debois sunumunu güçlü bir metaforla bitiriyor: “Yapay zeka ajanları bir motordur, bağlam (context) ise bu motorun yakıtıdır.” Eğer motora yanlış veya kalitesiz bir yakıt (bağlam) koyarsanız, motor ne kadar iyi olursa olsun düzgün çalışmayacaktır. Bu nedenle “bağlam”, geleneksel mühendislik disiplinleriyle yönetilmesi gereken yeni bir yazılım unsurudur.

41. Yazılım Mühendisliği Planlama ve Değerlendirmeye Dönüşüyor , Louis Knight-Webb, Vibe Kanban

Bu video, Vibe Kanban’ın kurucusu Louis Knight-Webb’in yapay zekanın yazılım mühendislerinin günlük çalışma rutinlerini nasıl kökten değiştirdiğine dair yaptığı bir sunumdur.

İşte sunumun öne çıkan ana başlıkları ve özeti:

1. Kod Yazmaktan Planlama ve İncelemeye Geçiş Eskiden yazılım mühendisleri mesailerinin çok büyük bir kısmını aktif olarak kod yazarak geçiriyordu. Ancak GitHub Copilot, Cursor ve Claude Code gibi yapay zeka araçlarının gelişmesiyle kod yazmaya ayrılan zaman ciddi şekilde daraldı. Konuşmacı, bu kazanılan zamanın bir “boş zaman” yaratmadığını, bunun yerine işin doğasını değiştirdiğini vurguluyor. Artık mühendisler zamanlarını YZ’ye ne yapacağını planlamaya (planning) ve AI’ın ürettiği kodu incelemeye (reviewing) harcıyor.

2. İki Farklı AI Çalışma Modeli Konuşmacı YZ ile kod yazarken iki temel yaklaşım olduğunu belirtiyor:

• Planlama Ağırlıklı (Plan Heavy): İşin başında detaylı dökümanlar, testler ve spesifikasyonlar hazırlamaya çok zaman harcamak. Konuşmacı bunu kesinlikle tavsiye ediyor çünkü “5 dakika planlama yapmak, sizi 30 dakikalık kod inceleme ve düzeltme zahmetinden kurtarır.” Bu yöntem özellikle Backend (arkayüz) geliştirme, refactoring ve veritabanı taşıma (migration) işlemleri için idealdir.
• İnceleme Ağırlıklı (Review Heavy): Hızlı ve detaysız bir istem verip, yapay zekanın hızlıca ürettiği sonucu sürekli kontrol edip düzelterek iteratif ilerlemek. Bu yöntem, görsel öğelerin ve durum yönetiminin (state) çok olduğu Frontend (önyüz) geliştirmeleri için daha uygundur.

3. Yazılımcıların “Yönetici” (Manager) Rolüne Evrilmesi Yapay zeka ajanları (agents) giderek daha bağımsız hale geliyor. Artık sadece kod yazmakla kalmıyor, kendi yazdıkları kodu derliyor, test ediyor ve hataları ayıklıyorlar. Bu da YZ’nin bir görevi bitirip insana dönme süresini saniyelerden dakikalara (ve yakında saatlere) çıkarıyor. İnsanların bu bekleme sürelerinde boş durmaması için yazılımcıların birer “yönetici” gibi çalışıp, aynı anda birden fazla yapay zeka ajanına farklı görevler vererek onları paralel şekilde yönetmesi (paralel çalışma) gerekecek.

4. Sahnede Canlı Şirket Kapatma (Sürpriz Son) Konuşmacı, sunumun sonunda kendi geliştirdikleri ürünün (tam da bu paralel YZ ajanlarını yönetmeye yarayan araç) mevcut rekabetçi piyasada ticari olarak sürdürülebilir olmadığına karar verdiklerini açıklıyor. Sahnede canlı yayında şirketini kapatma kararı alıyor ve son bir gösteri yapıyor: Kendi ürünlerini kullanarak, şirket web sitelerine “Elveda” temalı veda blog yazısını yapay zekaya yazdırıp yayına alıyor.

Özetle sunum; yapay zeka çağında yazılımcıların artık sadece kod yazan kişiler değil, yapay zekayı doğru yönlendiren, planlayan, denetleyen ve paralel süreçleri yöneten “sistem yöneticileri” haline geldiğini anlatıyor.

42. Proaktif Ajanlar , Kath Korevec, Google Labs

Google Labs’de Ürün Yöneticisi olan Kath Korevec yapay zeka kodlama asistanlarının geleceği üzerine bir sunum yapıyor. Sunumun ana teması, yapay zekanın “reaktif” (komut bekleyen) bir araç olmaktan çıkıp, “proaktif” (ihtiyaçları öngörüp kendiliğinden harekete geçen) bir takım arkadaşına dönüşmesidir.

1. Temel Problem: Bilişsel Yük ve Reaktif Yapay Zeka

• Korevec sunuma “bulaşık makinesi” anısıyla başlar. Eşi bulaşıkları yıkayacağını söylese de, Korevec’in ona her gün bunu hatırlatması gerekir. Bu durum, işi fiziksel olarak yapmasa bile kişide büyük bir “zihinsel/bilişsel yük” yaratır.
• Şu anki yapay zeka araçları da tam olarak böyledir; asenkron çalışırlar ama biz komut vermedikçe bir şey yapmazlar.
• İnsan beyni aynı anda çoklu görev yapmaya (multitasking) uygun değildir, işleri sırayla yapar (serial processor). Görevler arası geçiş yapmak (context switching), üretkenliğimizin %40'ına mal olur. Bu nedenle, arka planda çalışan yapay zeka araçlarını sürekli kontrol etmek büyük bir zaman ve enerji kaybıdır.

2. Çözüm: Proaktif Sistemlerin 4 Temel Direği Gelecekte kodlama asistanlarının biz sormadan iş yapması gerektiğini belirten Korevec, başarılı bir proaktif yapay zekanın 4 özelliğe sahip olması gerektiğini söylüyor:

• Gözlem: Tüm kod tabanını, çalışma desenlerini ve mimariyi anlamalı.
• Kişiselleştirme: Geliştiricinin çalışma tarzını, neyi sevip neyi görmezden geldiğini öğrenmeli.
• Zamanında Eylem: İş akışını bölmeden, tam zamanında müdahale etmeli.
• Sorunsuz Entegrasyon: Geliştiriciyi başka bir uygulamaya gitmeye zorlamadan, halihazırda çalıştığı yerde (Terminal, IDE vb.) var olmalı.

3. Google Labs Projesi: “Jules” Korevec, Google bünyesinde geliştirdikleri proaktif, otonom kodlama ajanı olan Jules’u tanıtıyor. Jules üç zeka seviyesinde gelişiyor:

• Seviye 1 (Yardımcı Aşçı , Sous-chef): Eksik testleri bulur, kullanılmayan bağımlılıkları tespit eder ve siz başka bir kod yazarken bunları arka planda otomatik olarak düzeltir.
• Seviye 2 (Mutfak Şefi): Tüm projenin bağlamını anlar. Veritabanı şemalarını, kullanılan framework’leri (örneğin React) ve dağıtım stillerini bilir. İş akışının ritmini yönetir.
• Seviye 3 (Kolektif Zeka, Gelecek Vizyonu): Yalnızca kodu değil, kodun kullanıcıları nasıl etkileyeceğini (sonuçları) de anlar. Sadece kod yazan Jules değil; tasarım ajanı (Stitch) ve veri analizi ajanı (Insights) bir araya gelerek kolektif bir zeka oluşturur. Örneğin, verilerdeki bir düşüşü fark edip UX/UI düzeltmesi önerebilir.

4. Jules’un Yeni ve Etkileyici Özellikleri

• Hafıza: Geçmiş etkileşimleri hatırlar ve kendi hafızasını günceller.
• Eleştirmen (Critic Agent): Yazılan kodun kalitesini denetler ve kod incelemesi (Code Review) yapar.
• Doğrulama: Doğruluğunu kanıtlamak için test senaryoları (Playwright scriptleri) yazar ve ekran görüntüleri alır.
• To-Do Bot: Projedeki “yapılacaklar” (To-Do) notlarını tarar ve geliştirici söylemeden bunları sırayla çözmeye başlar.

5. Sonuç: Geleceğin Yazılım Geliştirme Süreci Korevec sunumu, Cadılar Bayramı için kendi yaptığı hareketli bir maket (Kel Kafa) hikayesiyle bitiriyor. Maketi yaparken sinir bozucu donanım ve yazılım hatalarını çözmekle vakit kaybettiğini, asıl yapmak istediği “yaratıcı” kısma (LED ışıkların animasyonları) odaklanamadığını fark etmiş.

Verdiği ana mesaj şudur: Yapay zeka angarya, sıkıcı ve tekrarlayan hata ayıklama işlerini üstlenmeli, böylece insanlar enerjilerini yaratıcılığa ve inşa etmeye harcayabilmelidir. Geleceğin yazılım araçları bugünkülere hiç benzemeyecek; yapay zeka sadece bir komut satırı aracı değil, proaktif bir takım arkadaşı olacak.

43. Vizyon: Sıfır Hata , Johann Schleier-Smith, Temporal

Bu video, Temporal Technologies’ten Johann Schleier-Smith’in yazılım dünyasında “Sıfır Hata” (Zero Bugs) vizyonunu ve yapay zeka ajanlarının bu vizyonu nasıl gerçeğe dönüştürebileceğini anlattığı bir sunumdur.

Sunumun ana hatları şu şekildedir:

1. Hata (Bug) Gerçeği ve İtirazlar: Schleier-Smith, son kullanıcılar hataları çok umursamasa da yazılım mühendislerinin sürekli bir stres ve hata düzeltme döngüsü içinde yaşadığını belirterek başlıyor. “Sıfır hata” vizyonuna karşı gelen üç temel itirazı ele alıyor:

• Yazılımda her zaman hata olmuştur.
• Karmaşıklık nedeniyle sıfır hata imkansızdır.
• Her hatayı düzeltmenin maliyeti (ROI) mantıklı değildir.

2. Havacılık ve Uzay Endüstrisi Örneği: Bu itirazlara karşı, insan hayatının söz konusu olduğu havacılık sektörünü (örneğin Airbus A320 ve Uzay Mekiği) örnek gösteriyor. Bu endüstriler; bağımsız doğrulama ekipleri, savunmacı programlama (defensive programming), N-sürüm programlama (farklı donanım/yazılımlarla yedekleme) ve sıfır hata toleranslı katı bir “kalite süreci” sayesinde onlarca yıldır “sıfır hatalı” donanım ve yazılımlar üretebilmektedir.

3. Bilgisayar Biliminin Temelleri ve Biçimsel Yöntemler (Formal Methods): Güvenilir yazılımların arkasında üst düzey programlama dilleri, yapısal programlama ve modülerlik gibi devrimlerin yattığını aktarıyor. Daha sonra işin matematiğine, yani Biçimsel Yöntemlere (Formal Methods) değiniyor. “Dafny” dili üzerinden yaptığı bir demoda, kodun matematiksel olarak hatasız olduğunun derleme aşamasından önce nasıl kanıtlanabileceğini gösteriyor.

4. Yapay Zeka ile Ajan Tabanlı Kodlama (Agentic Coding) ve Yazılım 3.0: Sunumun en çarpıcı noktası, LLM’lerin (Büyük Dil Modelleri) kod yazımına dahil olmasıdır. LLM’ler doğaları gereği rastgele (non-deterministic) olsalar da, onlara doğru spesifikasyonlar (kurallar), katı tipli diller ve biçimsel doğrulama araçları (Dafny, Coq vb.) verildiğinde kusursuz kodlar üretebilirler.

5. Maliyet Devrimi: Geleneksel “yüksek güvenceli” (high-assurance) uzay/havacılık kodunun satır başı maliyeti 1.000–3.000 dolar iken, standart yazılım kodunun satır başı maliyeti 10–100 dolar civarındadır. Schleier-Smith, yapay zekâ ajanları ve biçimsel yöntemler birleştiğinde, en yüksek kalitedeki “sıfır hatalı” kodun maliyetinin 100 ila 10.000 kat arasında düşeceğini; hatta satır başı maliyetin sentin bile altına ineceğini savunuyor.

Sonuç: Yapay zeka ajanları sayesinde “yüksek güvenceli ve hatasız” yazılım üretmek sadece büyük ve zengin şirketlerin tekelinden çıkıp son derece ucuz ve sıradan bir işlem haline gelecektir. Bu sayede gelecekte sıfır hatalı yazılım deneyimleri yaygınlaşacaktır.

44. LLM Çağında Derleyiciler , Yusuf Olokoba, Muna

Bu video, yapay zeka modellerinin dağıtımını (deployment) ve kullanımını kökten basitleştirmeyi amaçlayan bir yazılım mühendisliği projesini anlatmaktadır.

Temel Sorun: Altyapı Karmaşası Şu anki yapay zeka mühendisliğinde yeni bir açık kaynaklı modeli (örneğin Hugging Face’ten) denemek oldukça zahmetlidir. Geliştiricilerin Docker konteynerleri kurması, karmaşık altyapılarla uğraşması ve modeli bir API arkasına sarması gerekir. Geliştiricilerin asıl istediği şey ise, karmaşık ayarlar yapmadan tıpkı OpenAI API’sini kullanır gibi (basit bir istemci ile) herhangi bir modeli çalıştırabilmektir.

Ayrıca konuşmacı, yapay zekanın geleceğinin “Hibrit Çıkarım” (Hybrid Inference) olduğuna inanıyor; yani cihazda (edge/lokal) çalışan küçük modellerle, bulutta çalışan büyük modellerin birlikte kullanımı. Bu geleceğe uyum sağlamak için hantal Python ve Docker ortamlarından çıkıp donanıma daha yakın, daha düşük seviyeli dillere geçmek gerekiyor.

Çözüm: Python tabanlı Yapay Zeka Derleyicisi Konuşmacı ve ekibi, geliştiricilerin basit Python kodlarını alan ve bunları her ortamda çalışabilen, kendi kendine yeten (self-contained) hızlı C++ veya Rust tabanlı çalıştırılabilir dosyalara (binary) dönüştüren bir derleyici geliştirmiştir. Örnek olarak Google’ın 270 milyon parametreli “EmbeddingGemma” modelini kullanıyorlar.

Sistem Nasıl Çalışıyor? (Teknik Adımlar)

1. İzleme ve Ağaç Çıkarma (Tracing & IR): Derleyici öncelikle Python kodunu okur ve bunu bir grafiğe veya “Ara Temsil”e (IR : Intermediate Representation) dönüştürür. Başlangıçta PyTorch FX’i denemişler ancak sadece PyTorch kodlarını desteklediği ve “sahte tensörlere” ihtiyaç duyduğu için yetersiz bulmuşlar. Bunun üzerine AST (Soyut Sözdizimi Ağacı: Abstract Syntax Tree) kullanarak kendi izleme sistemlerini yazmışlar. (Not: Bu aşamada kod analizi için LLM kullanmayı denemişler, doğruluk oranı çok yüksek olsa da çok yavaş çalıştığı için geleneksel yönteme dönmüşler).
2. Tip Atama ve LLM ile Kod Üretimi (Type Propagation & Translation): Python dinamik (değişken tipleri sonradan değişebilir), C++ ise statik (değişken tipleri sabittir) bir dildir. Python’daki işlemleri C++’a çevirirken türleri (string, integer vb.) bilmek gerekir. Ekibin burada bulduğu en yenilikçi çözüm; string birleştirme, matris çarpımı gibi temel işlemleri (operation) manuel olarak C++ ile yazmak yerine, LLM’lere prompt vererek bu C++ ve Rust kodlarını yapay zekaya yazdırmaktır. Bu sayede binlerce farklı matematiksel işlemi elle kodlamaktan kurtulmuşlardır.
3. Paketleme ve Çalıştırma (Execution): Üretilen C++ kodu derlenerek dinamik bir kütüphaneye dönüştürülür. Daha sonra FFI (Foreign Function Interface) tekniği kullanılarak bu kütüphane Node.js (JavaScript) ortamına aktarılır.

Sonuç Bu mimari sayesinde geliştiriciler; sunucu kurmaya, Docker yazmaya veya özel altyapı hazırlamaya gerek kalmadan, tamamen açık kaynaklı ve lokal bir modeli tıpkı OpenAI API’si çağırıyormuş gibi (client.embeddings.create) tek satır kodla her türlü cihazda çalıştırabilme imkanına kavuşmuşlardır.

45. Ajanlar da Robottur: Otonom Sürüşün Ajan İnşasına Öğrettikleri, Jesse Hu, Abundant

Sunumun temel amacı; Waymo ve Google gibi şirketlerde otonom sürüş (sürücüsüz araç) ve robotik alanında çalışmış olan konuşmacının, dijital yapay zeka ajanlarının (özellikle kodlama ajanlarının) geliştirilme sürecinin fiziksel robotların geliştirilme süreciyle neredeyse tamamen aynı zorluklara ve prensiplere sahip olduğunu anlatmasıdır.

Sunumda öne çıkan ana başlıklar ve dersler şunlardır:

1. %1'e Karşı %99 Problemi Tıpkı robotikte olduğu gibi, dijital ajanlarda da yapay zeka “modeli” işin sadece %1'ini oluşturur. İşin geri kalan %99'u altyapı, değerlendirme (eval), araç entegrasyonu (API’ler, terminaller), simülasyon ve çevrimdışı eğitim döngüleridir (offline stack). Kazanan takımlar sadece en iyi modele değil, en iyi altyapıya sahip olanlardır.

2. Açık Döngü (Open Loop) vs. Kapalı Döngü (Closed Loop) Sadece bir eylem yapıp işe yaramasını ummak (açık döngü, örneğin bir komut dosyasını çalıştırıp bırakmak) başarısızlığa mahkumdur. Tıpkı direksiyonu çevirdikten sonra aracın ne kadar döndüğünü sensörlerle kontrol eden bir araba gibi, ajanların da yaptıkları işlemlerin sonucunu sürekli kontrol edip (geri bildirim alıp) hatalarını düzeltebildiği “kapalı döngü” sistemlere ihtiyacı vardır.

3. Zamanın Parçalanması ve Gerçek Zamanlılık (Time Discretization) Robotlar dünyayı saniyede defalarca (örneğin 50 Hz) tarar ve anlık tepki verir. Dijital ajanlar ise şu an daha çok “sıra tabanlı” (bir sen konuş, bir ben konuşayım) tasarlanmıştır. Bu durum, aniden çıkan bir pop-up penceresi veya uzun süren bir bilgisayar işlemi gibi gerçek zamanlı müdahale gerektiren durumlarda ajanların yetersiz kalmasına neden olur.

4. Durumsuzluktan (Stateless) Durumlu (Stateful) Yapıya Geçiş Ajanlar, her şeyin sıfırdan başladığı temiz test ortamlarından çıkıp, kalıcı dosyaların, geçmişin ve karmaşık durumların olduğu “stateful” (örneğin gerçek bir Sanal Makine, VM) ortamlarda çalışmaya başlamıştır. Bu da ajanların “buraya nasıl geldim ve etrafımda ne var?” gibi soruları çözmesini gerektirir ve değerlendirme süreçlerini çok karmaşıklaştırır.

5. Eğitim Dışı Durumlar ve Hata Zincirleri (Out of Distribution & DAgger) Ajanlar insanları taklit ederek eğitilirler (Imitation Learning). Ancak, eğitim sırasında hiç görmedikleri ufak bir sapma (örneğin farklı bir web sitesi tasarımı) ile karşılaştıklarında kafaları karışır ve yanlış tıklamalar yaparak hatalar zincirine (cascading errors) neden olurlar.

6. Simülasyonun Zorunluluğu Gerçek dünyada (veya gerçek bir işletim sisteminde) eylemlerin sonuçları ve maliyetleri vardır. Ajanların hata yaptığında sistemi bozmaması veya kendi hatalarından güvenle öğrenebilmesi için, tıpkı sürücüsüz araçlarda olduğu gibi milyonlarca senaryonun denenebileceği gelişmiş “simülasyon” ortamlarına ihtiyaç vardır.

7. Sürekli Gelişim Döngüsü (Hill Climbing) Ajanları geliştirmek için deneme-yanılma (tahmin et ve kontrol et) yöntemine ihtiyaç vardır. Ürünü kullanıma sunmak, gerçek dünyadan log (veri) toplamak, bu verileri simülasyona geri beslemek ve modeli bu doğrultuda sürekli iyileştirmek şarttır.

Konuşmacı, dijital yapay zeka ajanlarının şu anki durumunu otonom sürüş teknolojisinin 2015 yılındaki haline benzetmektedir. Şu an elimizde çok iyi “demolar” ve tahmin modelleri var, ancak bu ajanların gerçek dünyada başından sonuna kadar hatasız işlem yapabilen (uçtan uca güvenilir) hale gelmeleri için tıpkı robotik mühendisliğinde kullanılan prensiplerin (simülasyon, geri bildirim döngüleri, hata kurtarma mekanizmaları) ajan geliştirme sürecine de tam anlamıyla entegre edilmesi gerekmektedir.

46. Backlog.md: Yapay Zekâ Ajanlarıyla Görev Yönetimi için Terminal Kanban Panosu, Alex Gavrilescu, Funstage

Alex Gavrilescu, hem insanlar hem de YZ ajanları (Claude vb.) için ortaklaşa çalışmak üzere tasarlanmış açık kaynaklı bir proje yönetim aracı olan Backlog.md’yi tanıtmaktadır.

Yapay zeka kodlama asistanlarının büyük projelerde “bağlam penceresini” (context window) aşması veya saatlerce yanlış yönde kod yazması sorunundan yola çıkılarak geliştirilen bu araç, büyük özellikleri küçük ve yönetilebilir Markdown görevlerine bölmeyi amaçlar.

Backlog.md’nin Temel Özellikleri:

• Terminal üzerinden veya web arayüzüyle kullanılabilen bir Kanban panosudur.
• Görevler, projenizin Git deposunda (repo) basit Markdown dosyaları olarak saklanır. Ayrı bir veritabanına veya API’ye ihtiyaç duymaz.
• Yapay zeka ajanlarıyla iletişim kurmak için MCP (Model Context Protocol) ve CLI (Komut Satırı) araçlarını kullanır. Bu sayede YZ ajanları projeyi anlar, mevcut görevleri arayabilir ve yeni görevler oluşturup silebilir.
• Ekip üyeleri arasında Git aracılığıyla her zaman senkronize kalır.

Backlog.md ile AI Destekli Çalışma Akışı (3 Aşama):

1. Görev Oluşturma (Task Creation): Kullanıcı ne istediğini YZ’ye anlatır. YZ, projeyi ve kuralları analiz ederek; başlık, açıklama ve net “kabul kriterleri” (acceptance criteria) içeren bir Markdown görev dosyası oluşturur. (1. İnsan Onay Aşaması)
2. Uygulama Planı (Implementation Plan): YZ, kodu yazmadan önce mimariyi nasıl değiştireceğine ve hangi dosyalara dokunacağına dair bir plan çıkarır. (2. İnsan Onay Aşaması, Konuşmacı bunun en önemli adım olduğunu, YZ’nin doğru yönde gidip gitmediğinin burada kontrol edilmesi gerektiğini belirtiyor.)
3. Görev Yürütme (Task Execution): Plan onaylandıktan sonra YZ kodu yazar, testleri gerçekleştirir ve görevi Kanban panosunda “Yapılıyor” (In Progress) durumundan “Tamamlandı” (Done) durumuna taşır.

Sistemin Sağladığı Avantajlar:

• Daha İyi Bağlam Yönetimi: Görevler dar kapsamlı olduğu için YZ bağlamı kaybetmez ve sadece istenen şeye odaklanır.
• Kolay Geri Alma (Rollback): YZ hata yaparsa veya gereksiz kod yazarsa, sadece o küçük görev geri alınıp (rollback), talimatlar düzeltilerek işlem kolayca baştan başlatılabilir.
• Paralel Çalışma: Git worktree (çalışma ağacı) kullanılarak birden fazla YZ ajanı farklı görevler üzerinde aynı anda çalıştırılabilir.

Gavrilescu sunumunu, Backlog.md aracının kendi kodunun %99'unun da yine bu araç ve yapay zeka ajanları kullanılarak yazıldığını belirterek sonlandırmaktadır.

47. Kodlama Ajanlarında Lezzet Geliştirmek: Uygulamalı Meta Nöro-Sembolik RL, Ahmad Awais, CommandCode

CommandCode şirketinin kurucusu ve CEO’su Ahmad Awais, yeni bir yapay zeka kodlama asistanını (agent) tanıtıyor. Bu aracın piyasadaki diğer araçlardan en büyük farkı, “lezzet” (taste) sahibi olması.

Mevcut Yapay Zeka Modellerinin Problemi Awais’e göre mevcut yapay zeka modelleri (LLM’ler) doğası gereği “tembel” çalışıyor. Bu modeller, çalışabilen kodlar üretseler bile, genellikle “slop” olarak adlandırdığı jenerik, sıradan ve özensiz kodlar yazıyorlar. Bir geliştiricinin; kodun okunabilirliği, sürdürülebilirliği, dosya mimarisi veya kullandığı spesifik kütüphaneler (örneğin npm yerine pnpm, test için Vitest kullanmak gibi) gibi kişisel tercihleri yapay zeka tarafından göz ardı ediliyor. Yapay zekayı yönlendirmek için uzun kural dosyaları (rules.md vb.) yazmak da çoğu zaman yetersiz ve zahmetli kalıyor.

CommandCode’un Çözümü: Kişisel Tarzı Öğrenmek CommandCode, “doğru” kod yazmanın ötesine geçerek geliştiricinin “görünmez tercih mimarisini” (kodlama tarzını ve lezzetini) sürekli olarak öğreniyor.

• Sürekli Öğrenme: Siz kod yazarken ve yapay zekanın yazdığı kodu düzenlerken, CommandCode sizi izliyor. Açıkça belirtmeseniz bile hangi araçları, isimlendirme standartlarını ve klasör yapılarını sevdiğinizi öğreniyor.
• Demo Karşılaştırması: Videoda standart bir yapay zeka (Claude Code) ile CommandCode karşılaştırılıyor. Her ikisinden de bir CLI (Komut Satırı Arayüzü) aracı yapması isteniyor. Claude düz, basit ve jenerik bir kod yazarken; CommandCode, Awais’in daha önceki tercihlerinden öğrendiği üzere otomatik olarak TypeScript, Commander, Vitest, tsup ve pnpm kullanarak, Awais’in tam olarak sevdiği klasör mimarisinde kodu oluşturuyor. Bunu yapmak için açık bir talimata ihtiyaç duymuyor.
• Teknik Altyapı: Sistem, Sürekli Pekiştirmeli Öğrenme (Continuous Reinforcement Learning) ve Nöro-Sembolik (Neuro-Symbolic) bir mimari kullanarak çalışıyor.

Gelecek Vizyonu: “Lezzet (Taste)” Ekosistemi Awais, yapay zeka kodlamasının bir sonraki sınırının bu “lezzet/tarz” olacağına inanıyor. Büyük dil modelleri (LLM’ler) dünyanın metinlerini öğrendi, “Taste” (lezzet) modelleri ise geliştiricilerin niyetlerini öğrenecek.

Gelecekteki vizyonları, tıpkı açık kaynak kod depoları gibi “Taste (Lezzet) Depoları” oluşturmak. Böylece bir geliştirici; ünlü bir yazılımcının “React tarzını”, belirli bir projenin tasarım standartlarını veya kendi şirketinin CTO’sunun kodlama lezzetini kendi yapay zekasına entegre ederek o kalitede ve düzende kod üretebilecek.

48. Durumsuz Kâbuslardan Dayanıklı Ajanlara, Samuel Colvin, Pydantic

Bu video, Pydantic’ten Samuel Colvin’in Pydantic AI, Temporal, Pydantic Logfire ve Pydantic Evals araçlarının entegrasyonunu ve yeteneklerini sergilediği kapsamlı bir sunumdur. Videonun temel odak noktası, uzun süren yapay zeka (LLM) iş akışlarında yaşanan kesinti sorunlarını çözmektir.

Temel Sorun ve Çözüm: “Dayanıklı Yürütme” (Durable Execution) Geleneksel LLM iş akışlarında (örneğin uzun bir araştırma görevi), sunucunun çökmesi, bağlantının kopması veya sistemin yeniden başlatılması durumunda tüm bağlam (context) kaybolur ve işlemin en baştan başlaması gerekir. Colvin, bu sorunu çözmek için arka planda iş akışının durumunu kaydeden Temporal platformunu Pydantic AI ile birlikte kullanıyor. Bu sayede süreç kesilse bile kaldığı yerden devam edebiliyor.

1. Demo: 20 Soru Oyunu

• İki yapay zeka ajanı (biri soru soran, diğeri cevaplayan) nesneyi tahmin etmek için “20 Soru” oynar.
• Temporal Olmadan: İşlem yarıda kesilirse (örneğin Colvin süreci manuel olarak sonlandırdığında), ajanlar her şeye sıfırdan başlamak zorunda kalır.
• Temporal İle: Ajanlar Temporal ile “sarıldığında” (wrapped), süreç çöktüğünde veya %20'lik rastgele bir hata simüle edildiğinde bile sistem önceki adımları hatırlar. İşlem yeniden başlatıldığında, önceki LLM çağrıları saniyeler içinde önbellekten (cache) geri döner ve oyun tam olarak kaldığı yerden devam eder.

Araya Giren Araçlar: Logfire ve Pydantic Evals

• Logfire: Colvin, iş akışının her bir adımını, ne kadar sürdüğünü ve hataları görselleştirmek için arka planda Pydantic Logfire’ı kullanıyor.
• Pydantic Evals: Farklı LLM modellerinin performansını karşılaştırmak için kullanılır. Colvin, GPT-oss-120b, Gemini ve Claude 3.5 Haiku’nun karşılaştırarak Gemini’ın çok daha hızlı çalıştığını ancak hızı uğruna bazen yanlış cevaplar uydurduğunu (halüsinasyon) tespit ettiğini gösteriyor.

2. Demo: Derin Araştırma (Deep Research)

• Daha karmaşık ve gerçek dünya kullanımına uygun bir örnektir. Sistem tek bir yapay zeka yerine, belirli görevleri olan ajanlardan oluşur (Planlama Ajanı, Paralel Arama Ajanları ve Analiz Ajanı).
• Sistem internette arama yaparken süreç manuel olarak durdurulur.
• Süreç tekrar başlatıldığında, Temporal sayesinde sistem yeniden planlama yapmaz veya aynı aramaları tekrar gerçekleştirmez (bu adımlar zaten milisaniyeler içinde önbellekten yüklenir). Doğrudan bir sonraki adıma (analiz aşamasına) geçer. Bu durum büyük bir maliyet ve zaman tasarrufu sağlar.

Colvin sunumun sonunda yakında çıkacak olan Pydantic AI Gateway adlı yeni bir platformu duyuruyor. Bu platform, geliştiricilerin farklı büyük dil modellerinden (LLM) kolayca çıkarım (inference) satın almalarına ve kurumsal ihtiyaçlar için kendi sunucularında (self-hosting) barındırmalarına olanak tanıyacak.

49. 20 Milyon Pull Request Verisinin Yapay Zekâ Dönüşümü Hakkında Gösterdikleri , Nick Arcolano, Jellyfish

Bu analiz; Haziran 2024'ten günümüze kadar 1.000'den fazla şirketten ve 200.000 geliştiriciden toplanan 20 milyon “Pull Request” (PR: Çekme İsteği) verisine dayanmaktadır. Sunum, yapay zekanın yazılım dünyasındaki gerçek etkilerine dair dört temel soruyu yanıtlıyor:

1. Yapay Zekanın Benimsenmesi Ne Durumda?

• Etkileşimli Araçlar (Copilot, Cursor vb.): Geliştiricilerin bu araçları kullanım oranı muazzam bir hızla artmıştır. Geçen yaz %22 olan medyan kullanım oranı, günümüzde %90'lara ulaşmıştır.
• Otonom Ajanlar (Devin vb.): Otonom yapay zeka ajanlarının kullanımı hala çok erken aşamadadır. Şirketlerin sadece %44'ü bunları denemiştir ve yazılan tüm PR’ların sadece %0.2'sinden azı bu ajanlar tarafından üretilmektedir.

2. Verimlilikte Ne Kadarlık Bir Artış Beklenmeli? Yapay zeka araçlarını %0'dan %100 oranında (her kod yazımında) kullanmaya geçen şirketlerde ciddi verimlilik artışları gözlemlenmiştir:

• PR Üretim Hızı (Throughput): Ortalama bir geliştiricinin haftalık birleştirdiği (merge) PR sayısında 2 kat artış görülmektedir.
• Döngü Süresi (Cycle Time): İlk kodlamadan (commit) birleştirmeye (merge) kadar geçen süre %24 oranında kısalmıştır.

3. Yan Etkiler ve Kod Kalitesi Nasıl Etkileniyor?

• Daha Büyük PR’lar: YZ kullanan ekiplerin gönderdiği PR’ların boyutu, eklenen yeni kod satırı bazında %18 daha büyüktür. Ancak dokunulan dosya sayısı aynı kalmıştır (YZ kodu tek bir dosya içinde daha fazla üretmektedir).
• Kalitede Düşüş Yok: YZ kullanımının artmasıyla yeni hata (bug) biletlerinde veya geri alınan (revert) PR’larda istatistiksel bir artış görülmemiştir. Hatta geliştiricilerin YZ’yi hata çözmek için kullanması nedeniyle çözülen hata sayısında artış vardır.

4. Beklentiler Gerçekleşmiyorsa Sorun Nerede? (Kod Mimarisi Faktörü) Eğer şirketiniz YZ kullanmasına rağmen verimlilik artışı göremiyorsa, sorun kod mimariniz olabilir. Veriler, mimarinin YZ verimliliği üzerinde kritik bir rol oynadığını gösteriyor:

• Merkezi Mimari (Monolitik / Monorepo): Kodlarını daha az sayıda repoda tutan şirketlerde YZ verimliliği ortalamanın çok üzerine çıkarak 4 kat artışa ulaşmaktadır.
• Dağıtık Mimari (Mikroservisler / Çoklu Repo): Kodları çok fazla repoya dağılmış olan şirketlerde, YZ kullanımının PR üretimine hiçbir olumlu etkisi olmadığı (hatta hafif negatif etkisi olduğu) görülmüştür.
• Nedeni: Mevcut yapay zeka araçları ve ajanları, farklı repolara dağılmış kodlar arasındaki “bağlamı” (context) anlamakta zorlanmaktadır. YZ, tek bir repo içinde harika çalışırken, çapraz repolarda sistemin bütününe hakim olamadığı için verimlilik sağlayamamaktadır.

Etkileşimli yapay zeka kodlama araçları rüştünü ispatlamış ve geliştirici verimliliğini (PR hızını) ortalama 2 kat artırmıştır. Ancak bu teknolojiden maksimum faydayı sağlamak, şirketlerin kod mimarilerine ve YZ’ye doğru “bağlamı” sunabilmelerine sıkı sıkıya bağlıdır. Dağıtık mikroservis mimarisine sahip şirketlerin bu kazanımları elde etmesi şimdilik daha zordur.

50. Teknik Mimari için Yapay Zekâ Yardımcıları: İnşa Etmediğiniz En Yüksek ROI’li Kullanım Alanı , Boris B., Catio

Kodlama için kullanılan yapay zeka yardımcı pilotları (örneğin GitHub Copilot) artık sektörde standart hale gelmiş ve verimliliği artırmış olsa da, yazılım geliştirme döngüsündeki en kritik aşama olan “teknoloji mimarisi” hala geride kalmıştır. Konuşmacılar, asıl yatırım getirisinin (ROI) mimaride kazanıldığını veya kaybedildiğini vurguluyor. Kötü bir mimari yönelim, ne kadar hızlı kod yazılırsa yazılsın teknik borca (tech debt) ve verimsizliğe yol açar.

Mevcut Durum ve Karşılaşılan 3 Temel Zorluk Şu an birçok şirkette mimari kararlar e-tablolar, kulaktan dolma bilgiler ve içgüdülerle yönetiliyor. Teknoloji liderlerinin (CTO’lar, Mimarlar) karşılaştığı 3 ana sorun şunlardır:

1. Mimari Görünürlük Eksikliği (Kör Uçuş): Sistemler büyüdükçe karmaşıklaşır. Servislerin, bağımlılıkların ve sistemin zaman içindeki değişiminin canlı, bütüncül ve güvenilir bir haritası (baseline) yoktur.
2. Veriye Dayalı Yatırım Getirisi (ROI) Çıkaramamak: Alınan mimari kararların (maliyet, performans, risk açısından) işletmeye olan etkisini verilerle savunmak ve önceliklendirmek çok zordur.
3. Geliştiricilere Ölçeklenebilir Rehberlik Sunamamak: Sorumlulukların geliştiricilere kaydığı (shift-left) günümüzde, geliştiriciler yeterli mimari uzmanlığa sahip değildir. Mevcut mimari ekipleri (Architecture Guilds) ise her talebi manuel inceledikleri için bir “darboğaz” haline gelmektedir.

Çözüm: Mimari Yardımcı Pilotun 3 Temel Bileşeni Catio, bu sorunları çözmek ve “şirketlerin ateş etmeden önce doğru nişan almasını” sağlamak için bir Mimari Yardımcı Pilot vizyonu sunuyor. Bunun 3 ana bileşeni var:

1. Canlı Mimari Haritası (Dijital İkiz): Bulut, Kubernetes, loglama platformları gibi her yerden veri çekerek sistemin sürekli güncellenen, canlı bir dijital ikizini (haritasını) oluşturmak.
2. Çoklu Yapay Zeka Ajanları ile Sistem Önerileri (Multi-Agent AI): Sadece basit dil modellerine (LLM) değil, büyük mimari modellere ve simülasyonlara dayanarak çalışan sistemler. Bu sistemler, iş hedefleriyle uyumlu, gerekçesi açıklanabilir ve ROI tabanlı yönlendirmeler yapar.
3. Sohbet Tabanlı Rehberlik ve Üretken Tasarım: Geliştiricilerin doğrudan etkileşime girebileceği bir yapay zeka ajanı. Bu ajan, geliştiricilerin sorularını yanıtlar, şirket standartlarına/kurallarına uygun tasarımlar üretir ve mimari inceleme sürecini otomatikleştirerek darboğazları ortadan kaldırır.

Boris ve Toufic, mimari yardımcı pilotların şirketlere stratejik bir avantaj sağlayacağını belirtiyor. Geleneksel sistemlere saplanıp kalmamak için şirketlerin bu teknolojiye adapte olması gerektiğini savunuyorlar. Önerilen strateji ise; bu sistemi tüm şirkette aynı anda başlatmak yerine, küçük bir portföy alanında pilot uygulama olarak başlatıp elde edilen başarı (ROI) sonrası tüm organizasyona yaymaktır.

51. Kodlama Ajanları Sayesinde Kendi Kendini Düzelten Altyapı , Mahmoud Abdelwahab, Railway

Web uygulamalarındaki altyapı sorunlarını (yüksek CPU kullanımı, bellek sızıntıları, HTTP 500 hataları vb.) kendi kendine çözen (self-healing) otonom bir yapay zeka sisteminin nasıl kurulacağı anlatılmaktadır.

Normal şartlarda bir sunucuda sorun çıktığında, geliştiriciler uyarı (alert) alır, logları ve metrikleri manuel olarak inceler, sorunun kaynağını bulur, kodu düzeltir ve yeniden dağıtıma (deploy) çıkar. Bu yavaş ve yorucu bir süreçtir.

2. Önerilen Otomasyon İş Akışı (Workflow): Konuşmacı, sadece uyarılara bağlı kalmak yerine belirli aralıklarla (örneğin her 15 dakikada bir) çalışan bir sistem önerir:

• İzleme (Monitoring): Sistem tüm projeyi tarar; CPU, RAM ve HTTP hata oranlarını kontrol eder.
• Veri Toplama (Context Gathering): Eğer belirlenen eşiklerin üzerinde bir hata tespit edilirse (örneğin bir servisin çökmesi), sistem o servise ait logları, derleme (build) geçmişini ve diğer bağlantılı verileri otomatik olarak çeker.
• Planlama: Toplanan veriler ışığında sorunun ne olduğuna dair detaylı bir analiz ve çözüm planı oluşturulur.

3. Kullanılan Teknolojiler:

• Dayanıklı İş Akışları (Durable Workflows, Ingest vb.): Sistemdeki bu çok adımlı işlemlerin (veri çekme, yapay zekaya gönderme vb.) kesintiye uğramaması ve bir hata olursa baştan başlamak yerine kaldığı yerden devam edebilmesi için bu yapı kullanılır.
• Yapay Zeka Kodlama Ajanı (OpenCode): Açık kaynaklı ve terminal tabanlı bir yapay zeka aracıdır. Arka planda başsız (headless) bir sunucu olarak çalıştırılır ve bir API aracılığıyla sistemle haberleşir.

4. Sonuç ve Çözüm (Otomatik Pull Request): Hazırlanan analiz ve çözüm planı OpenCode ajanına iletilir. Yapay zeka ajanı; arka planda GitHub deposunu klonlar, gerekli kod düzeltmelerini (fix) yapar, test ortamını hazırlar ve doğrudan Github üzerinde bir Pull Request (PR: Çekme İsteği) oluşturur.

Bu sistem sayesinde, bir sunucu hatası yaşandığında geliştiriciler sorunu aramakla uğraşmazlar. Sistem sorunu kendi kendine tespit eder, sebebini bulur, kodu yazar ve geliştiricinin önüne sadece “Sorun buydu, bu kodu yazarak çözdüm, onaylıyor musun?” şeklinde bir Pull Request (PR) sunar. Geliştirici sadece kodu inceleyip birleştirerek (merge) sorunu dakikalar içinde çözer.

52. Codex CLI’a Alt Ajanlar Eklemek, Brian John, Betterup

BetterUp şirketinde Kıdemli Full Stack Mühendisi olan Brian John’un Codex CLI (Komut Satırı Arayüzü) içine alt ajanların (subagents) nasıl entegre edileceği (“hack’leneceği”) üzerine yaptığı bir sunumdur.

Brian John, günlük işlerinde Claude Code’u sıklıkla kullanıyor ve sunduğu alt ajan (subagent) özelliklerini çok başarılı buluyor. Ancak tek bir araca veya modele bağımlı kalmak (vendor lock-in) istemiyor. Codex CLI’ın modellerinin çok iyi olduğunu düşündüğü için, alt ajan mimarisini Codex ortamında da kullanabilmek amacıyla kendi çözümünü geliştiriyor.

Alt Ajanların Önemi (Bağlam Yönetimi) Alt ajanların en büyük avantajı bağlam yönetimidir (context management). Ana ajan, bir problemi alt ajana devreder; alt ajan kendi token’larını harcayarak arka planda çalışır ve ana ajana sadece nihai cevabı döndürür. Bu sayede ana ajanın “bağlam penceresi” (context window) gereksiz adımlarla şişmemiş ve temiz kalmış olur.

Sistem Tasarımı Tasarım temelde şu şekilde işliyor:

1. Ana Codex Oturumu, hangi alt ajanın çalışması gerektiğine karar verir.
2. Özel olarak yazılmış bir sarmalayıcı (wrapper) Python betiği (agent-exec) devreye girer.
3. Bu betik, Evlat Codex oturumunu başlatır. Evlat ajan görevi yapar ve sonucu geçici bir dosyaya yazar.
4. Sarmalayıcı betik bu dosyayı okur ve standart çıktı (stdout) üzerinden ana ajana iletir.

Karşılaşılan Zorluklar ve İzinler (Permissions) Bu sistemi kurarken karşılaşılan en büyük zorluk, Codex’in katı “sandbox” (güvenli alan) kısıtlamaları olmuş. Sistemin çalışması için tehlikeli komutlara onay vermeden, minimum izinlerle (minimum required permissions) bir denge kurulması gerekmiş:

• Ana süreç: Komut çalıştırabilmek için en azından çalışma alanına yazma (workspace-write) iznine sahip olmalı.
• Evladın süreci: Dosya yazabilmesi için yine yazma iznine sahip olmalı, OpenAI kimlik bilgilerine erişebilmeli, ancak ebeveyn sandbox’ının engellemelerine takılmamak için Codex’in “Rollout Recorder” (loglama) özelliğinin kapatılması (disable) gerekmiş.

Güvenlik (Agents Rule of 2) Brian, Meta’nın hazırladığı bir makaleye atıfta bulunarak ajan güvenliğinde üç ana riskten bahseder: Güvenilmez girdileri işlemek, hassas verilere erişim ve dış sistemlerle iletişim/durum değiştirme. Kendi sisteminin dışarıdan güvenilmez girdi almadığını, API üzerinden sadece dışarıyla iletişim kurduğunu belirterek bu mimariyi “Daha Düşük Riskli” (Lower Risk) olarak sınıflandırır. Ancak düşük riskin, “sıfır risk” anlamına gelmediğini vurgular.

Akıllı Bir Çözüm: İzin İsteme Yorgunluğunu Aşmak Codex’e alt ajanı nasıl çağıracağını AGENTS.md adlı bir talimat dosyasıyla öğretiyor. Burada çok zekice bir yöntem kullanıyor: Eğer alt ajana gidecek komut argümanları doğrudan komut satırına yazılırsa, argümanlar her değiştiğinde Codex kullanıcıdan “Bu komutu çalıştırayım mı?” diye onay istiyor. Bu can sıkıcı durumu aşmak için Codex’e değişkenleri önce bir dosyaya yazmasını, ardından hep aynı sabit komutu çalıştırmasını söylüyor. Komut string’i hiç değişmediği için kullanıcıdan sadece bir kez onay (sürekli izin) alması yeterli oluyor.

Sunumun sonunda Brian, hazırladığı açık kaynaklı projeyi (kelime sayacı ve dosya yazıcı gibi basit ajanlarla) terminal üzerinde canlı olarak test ediyor. Codex’in asenkron çalışma yeteneği olmadığı için Claude’a kıyasla işlemlerin daha yavaş (seri halde) gerçekleştiğini, ancak Codex’in doğası gereği daha çok kendi kendine çalışan (hands-off) bir yapıda tasarlandığı için bunun kabul edilebilir olduğunu belirtiyor. Projenin kaynak kodlarını GitHub üzerinden paylaşıyor.

53. Bağlam Mühendisliği: Graf Yapılarıyla Noktaları Birleştirmek, Stephen Chin, Neo4j

Neo4j Geliştirici İlişkileri Başkan Yardımcısı Stephen Chin’in yapay zeka sistemlerinde mantık ve doğruluk sorunlarını çözmek için Agentic GraphRAG (Ajan Tabanlı GrafRAG) kullanımını anlattığı bir sunum.

1. LLM’lerin (Büyük Dil Modelleri) Sınırları ve “Yarım Beyin” Problemi Chin, üretken yapay zeka (GenAI) projelerinin önemli bir kısmının başarısızlıkla sonuçlandığını belirtiyor. LLM’ler dil işleme ve metin üretme konusunda harika olsalar da mantık kurma, doğrusal düşünme ve olgusal gerçeklik konularında yetersiz kalıyorlar (sadece dil yetenekleri olan “yarım bir beyin” gibi çalışıyorlar). Chin, OpenAI’nin gelişmiş o3 modelinin bile mantık ve matematik içeren basit bir okul bulmacasını çözerken nasıl ön yargılı (bias) davranıp mantıksız ve yanlış sonuçlar ürettiğini bir örnekle gösteriyor.

2. Ajanlar (Agents) ve MCP (Model Context Protocol) Bu sorunları aşmak için birden fazla yapay zeka “ajanının” birlikte çalıştığı, gözlem yaptığı ve eyleme geçtiği sistemler kullanılıyor. Ancak bu ajan sistemlerini yönetmek, araçları entegre etmek ve güvenliği sağlamak zor olabiliyor. Bunun çözümü olarak MCP (Model Context Protocol) tanıtılıyor. MCP, tıpkı cihazlar için “USB-C” portu neyse, yapay zeka uygulamalarının veri kaynaklarına ve araçlara bağlanması için de standart bir açık protokoldür. Neo4j, MCP üzerinde çalışan veritabanı sorgulama (Cypher) ve hafıza modülleri geliştirmiştir.

3. Hafıza ve Yapı Olarak “Graflar” (Knowledge Graphs) Ajanların iş akışları ve hafızaları (memory) doğası gereği birer graf (ağ) yapısındadır. Sadece vektör aramasına (Vector Search) dayalı standart RAG sistemleri, bağlamı tam anlayamadıkları için eksik cevaplar verirler. GraphRAG ise vektör araması ile Bilgi Graflarının (Knowledge Graphs) gücünü birleştirir.

Nasıl Çalışır: LLM kullanıcı sorusunu alır -> Vektör araması ile veritabanındaki en alakalı “düğüm (node)” bulunur -> Graf yapısı sayesinde bu düğümle ilişkili olan tüm diğer veriler çekilir -> Bu zengin bağlam LLM’e sunularak halüsinasyon yapmadan, eksiksiz ve çok daha doğru bir cevap üretmesi sağlanır.

4. Gerçek Dünya Örneği: Klarna Finansal teknoloji şirketi Klarna, kurum içi bilgi sistemlerinde sadece standart bir LLM kullanmak yerine Neo4j ile bir GraphRAG sistemi kurdu. Şirket içi belgeleri, İK sistemlerini ve Wiki’leri birleştirerek çalışanların sorularına yüksek doğrulukla yanıt veren bu sistem, ilk yılında 250.000 soru yanıtladı ve çalışanlar arasında %85 gibi devasa bir benimsenme oranına ulaştı.

Özetle sunum; yapay zekanın “halüsinasyon” ve mantık hatalarını çözmek için metinsel aramanın ötesine geçip, veriler arasındaki ilişkileri (grafları) kullanan ajan tabanlı mimarilerin geleceğin standardı olduğunu savunuyor.

54. Evals Hakkında Zor Kazanılmış 5 Ders, Ankur Goyal, Braintrust

Yapay zeka sistemlerinin test edilmesi ve değerlendirilmesi (AI evaluations / evals) süreçlerinden elde edilen 5 temel dersi anlatan bir sunumdur. İşte videonun detaylı Türkçe özeti:

1. Etkili değerlendirmeler (evals) kendini belli eder

• İyi bir değerlendirme (eval) sisteminiz olup olmadığını anlamanın yolları vardır. Başarılı bir sisteme sahipseniz; piyasaya yeni bir yapay zeka modeli çıktığında (örn. GPT-4o), ürününüzü bu yeni modele 24 saat içinde entegre edip güncelleyebilirsiniz.
• Kullanıcılardan gelen şikayetleri ve geri bildirimleri kolayca alıp test süreçlerinize (evals) doğrudan bir veri olarak ekleyebilmelisiniz.
• Değerlendirmeler sadece hataları yakalamak (savunma) için değil, yeni bir özelliği piyasaya sürmeden önce ne kadar iyi çalışacağını öngörmek (hücum) için kullanılmalıdır.

2. Harika değerlendirmeler bilinçli bir mühendislik gerektirir

• İnternetteki hazır sentetik veri kümelerine veya standart puanlayıcılara (scorers) güvenmeyin.
• Veri kümeleriniz, kullanıcıların gerçekte ne deneyimlediğini yansıtmalı ve gerçek dünyayla sürekli olarak senkronize edilmelidir.
• Puanlama fonksiyonlarınız (scorers), uygulamanızın “teknik gereksinim belgesi” (PRD) gibi olmalıdır. Kendi projenize ve hedeflerinize özel puanlama kriterleri yazmalısınız.

3. Bağlam (Context) mühendisliği, yeni istem mühendisliğidir

• Modern yapay zeka ajanlarında (agents), yazdığınız asıl sistem promptu toplam token kullanımının sadece %3–5'ini oluşturur. Geri kalan devasa kısım, modelin kullanacağı araçların tanımları (tool definitions) ve bu araçlardan dönen yanıtlardır.
• Bu nedenle araçları modele nasıl tanıttığınız çok önemlidir. Örneğin, modele veriyi JSON yerine YAML formatında sunmak, gereksiz token kullanımını azaltır ve modelin veriyi anlamasını çok daha verimli hale getirir.

4. Yeni bir modelin her şeyi değiştirmesine hazırlıklı olun

• Model sağlayıcıları (OpenAI, Anthropic, Google vb.) yeni bir model yayınladığında kurallar değişir.
• Daha önce %10 başarı oranıyla çalışan ve “kullanılamaz” olarak rafa kaldırdığınız vizyoner bir özellik, yeni bir modelle aniden %58 başarıya ulaşıp piyasaya sürülmeye hazır hale gelebilir.
• Bu yüzden, mevcut modellerin çözemeyeceği kadar zor (iddialı) testler hazırlamalı ve yeni modeller çıktığında bunları hemen test ederek fırsatları yakalamalısınız.

5. Sadece istemleri değil, tüm değerlendirme sistemini eniyileyin

• Uygulamanızı iyileştirmek için sadece sistem isteminde kelimeleri değiştirmek yeterli değildir.
• Veri kümenizi, isteminizi, kullandığınız araçları ve puanlama fonksiyonlarınızı bir bütün (sistem) olarak eniyilemelisiniz. Konuşmacı, tüm bu sistemi otomatik olarak eniyileyen “Loop” adında yeni bir özellik tanıtmış ve bu sayede başarı oranının %8.9'dan %39.14'e nasıl sıçradığını göstermiştir.

Soru-Cevap (Q&A) Bölümü:

• Aşırı Uyum (Overfitting) Riski: Bir izleyici, her kullanıcı şikayetini teste eklemenin sistemi o verilere aşırı uydurup uydurmayacağını sordu. Konuşmacı, hiçbir kullanıcı verisine sahip olmamanın daha büyük bir risk olduğunu belirtti. Ancak, her veriyi otomatik eklemek yerine, araya insan muhakemesi koyarak sadece uygulamayı gerçekten zorlayacak/geliştirecek nitelikli geri bildirimlerin testlere eklenmesi gerektiğini söyledi.
• Modeller Arasındaki Farklar: Basit görevlerde modeller arasında büyük farklar görülmese de, özellikle çok adımlı ve karmaşık hedefleri olan yapay zeka ajanlarında (agentic workflows) yeni ve güçlü modellerin (örn. Claude 3.5 Sonnet) performansı dramatik bir şekilde değiştirdiği vurgulandı.

55. Ajanik Bir Platform İnşa Etmek, Ben Kus, CTO Box

Bu video, kurumsal içerik yönetimi platformu Box’ın CTO’su Ben Kus’un, şirketin yapay zeka yolculuğunu ve özellikle ajanik mimarilere nasıl geçiş yaptıklarını anlattığı bir sunumdur.

Box, büyük şirketlerin (Fortune 500'ün üçte ikisi dahil) belgelerini ve verilerini yöneten bir platformdur. Kurumsal verilerin %90'ı sözleşmeler, PDF’ler ve raporlar gibi “yapılandırılmamış (unstructured)” verilerden oluşur. Üretken Yapay Zeka (GenAI) öncesinde, bu belgelerden anlamlı ve yapılandırılmış veri çıkarmak (Data Extraction) geleneksel makine öğrenimi (ML) ve OCR yöntemleriyle çok zor, pahalı ve kırılgan bir süreçti.

2. GenAI’nin İlk Aşaması: Beklentiler ve Hayal Kırıklığı Box, ilk aşamada standart Büyük Dil Modellerini (LLM örn. GPT-3/4) sisteme entegre etti. Sistem başlangıçta sihir gibi çalıştı; basit sözleşmelerden veri çekmek için modele sadece “Şu alanları çıkar” demek yetiyordu ve eski ML modellerinden çok daha başarılıydı.

Ancak müşteriler 300 sayfalık, yüzlerce farklı veri alanı içeren ve karmaşık risk analizleri gerektiren zorlu belgeler getirmeye başladığında sistem çökmeye başladı. Modellerin bağlam sınırı aşıldı, OCR hataları tüm süreci bozdu ve YZ halüsinasyon görmeye (yanlış bilgi üretmeye) başladı. Box, sistemi düzeltmek için sürekli yeni kurallar (heuristics) ve karmaşık kodlar ekledikçe, mimari içinden çıkılmaz ve kırılgan bir hale geldi.

3. Çözüm: Ajan (Agentic) Mimariye Geçiş Box, tek bir “sihirli” LLM istemi ile her şeyi çözmeye çalışmak yerine, süreci parçalara bölen Ajan (Agentic) tabanlı bir mimariye (Yönlendirilmiş Grafik / Directed Graph) geçti. Bu yeni sistemde süreç şu adımlarla işliyor:

• Hazırlık: Belgedeki veri alanları akıllıca gruplandırılıyor.
• Veri Çıkarma: Her görev için en uygun araçlar (Farklı LLM’ler, RAG, OCR aracı) kullanılıyor.
• Yargıç YZ (LLM-as-a-judge): Başka bir YZ modeli, çıkarılan verinin doğruluğunu kontrol ediyor. Yanlışsa, sistemi yeniden denemesi için geri gönderiyor.

Bu yaklaşım sadece veri çıkarmada değil; akıllı Soru-Cevap (Agentic RAG) ve internette veya belgeler içinde kendi kendine araştırma yapabilen “Derin Araştırma (Deep Research)” özelliklerinde de başarıyla kullanıldı.

4. Çıkarılan Dersler (Lessons Learned) Ben Kus, bu süreçten elde ettikleri mühendislik tecrübelerini 3 ana maddeyle özetliyor:

1. Ajan (Agentic) mimariyi erkenden kurun: Karmaşık problemleri çözmek için tek bir modele güvenmeyin. Sistemi erkenden ajan tabanlı bir yapıya oturtun.
2. Geliştirmesi çok daha kolaydır: Sistem küçük adımlara bölündüğü için, yeni bir YZ modeli çıktığında veya bir hata oluştuğunda tüm sistemi değiştirmek yerine sadece ilgili “ajanı” veya aracı güncelleyebilirsiniz.
3. Mühendislik kültürünü iyileştirir: Mühendislerin sadece “prompt” yazmak yerine; sistem mimarisi, durum grafikleri (state diagrams) ve araç-kullanımı (tool use) gibi daha mantıksal çerçevelerde düşünmesini sağlar.

Gelen bir soru üzerine Kus; YZ modellerinin (OpenAI, Anthropic, Google vb.) çok hızlı güncellendiğini ve Box olarak müşterilerine her zaman en iyi modeli seçme özgürlüğü sunduklarını belirtti. Bu yüzden modellere “İnce Ayar (Fine-tuning)” yapmaya karşı olduklarını, bunun yerine iyi bir ajan mimarisi ve yönlendirme (prompting) ile ilerlemenin çok daha esnek ve başarılı sonuçlar verdiğini vurguladı.

56. Transformer’lar Görüntü Alanını Nasıl Tamamen Ele Geçirdi, Isaac Robinson, Roboflow

Sunum, görüntü işlemede yıllarca standart olan Evrişimli Sinir Ağları (CNN) ile Vision Transformer’ların (ViT) karşılaştırmasıyla başlıyor.

• CNN’ler: Bir nesnenin resmin neresinde olursa olsun aynı şekilde algılanmasını sağlayan güçlü bir “tümevarımsal önyargıya” (inductive bias) sahiptir.
• ViT’ler (Vision Transformers): Görüntüyü küçük parçalara (patch) böler ve kelime jetonları (token) gibi işler. Doğal bir yapısal önyargıları yoktur, bu da başlangıçta onların çok yüksek işlem gücü (n4karmaşıklığı) gerektirmesine neden olmuştur.

Görüntü İşleme Mimarilerinin Evrimi ve ViT’in Zaferi Başlangıçta ViT’lerin işlem yükü sorununu çözmek için çeşitli ara modeller geliştirildi:

• Swin: Hesaplama yükünü azaltmak için yerel pencereler ekleyerek CNN’lere benzer bir önyargı oluşturdu.
• ConvNeXt: Transformer’lardan öğrenilen dersleri alıp tekrar klasik CNN mimarisine uyguladı.
• Hiera: Modele yapısal önyargı eklemek yerine, bu önyargıları (tıpkı dil modellerindeki gibi) “ön eğitim” (pre-training) aşamasında modele öğretmeyi denedi.

Ancak günün sonunda kazanan yine orijinal ve basit ViT mimarisi oldu. Bunun iki ana nedeni vardı:

1. Büyük Dil Modelleri (LLM) dünyasında geliştirilen “Flash Attention” gibi hızlandırma algoritmalarının ViT’lere entegre edilmesi.
2. Eksik olan yapısal önyargıların, Maskeli Otomatik Kodlayıcılar (MAE) gibi devasa ve ViT’e özel ön eğitim (pre-training) yöntemleriyle modele sonradan başarılı bir şekilde öğretilebilmesi.

Temel Modellerin (Foundation Models) Pratik Sorunu Bu ilerlemeler SAM (Segment Anything Model) serisi gibi devasa modellerin doğmasını sağladı (SAM→MobileSAM→SAM2→SAM3). Ancak SAM3 gibi modeller muazzam yetenekli olsalar da 800 milyon parametreye ulaştılar. Bu “tek beden herkese uyar” (one-size-fits-all) yaklaşımı, modellerin düşük güç tüketen kenar (edge) cihazlarda veya gerçek zamanlı uygulamalarda (gerçek hayat senaryolarının çoğunda) kullanılmasını imkansız hale getirdi.

Roboflow’un Çözümü: RF-DETR Bu donanım ve dağıtım sorununu çözmek için Roboflow, RF-DETR modelini geliştirdi. Bu modelin temel özellikleri şunlardır:

• Devasa ön eğitimlerin gücünü ve LLM hızlandırma tekniklerini kullanır.
• Buna ek olarak, Sinirsel Mimari Arama (NAS) ile uyumlu esnek ayar düğmeleri eklenmiştir.
• Bu esneklik sayesinde model, dağıtılacağı donanımın kısıtlamalarına göre uyarlanabilir.

Sonuç: RF-DETR, SAM3'ün ince ayar (fine-tuning) yapılmış haline kıyasla aynı doğruluk oranında 40 kata kadar hız artışı veya bir miktar doğruluk artışıyla 15 kat hız artışı sağlayarak bu devasa modelleri gerçek hayatta (edge cihazlarda) kullanılabilir hale getirmiştir.

57. Sohbet Ajanına Ses Kazandırmak, Luke Harries, ElevenLabs

ElevenLabs şirketinden Luke Harries’in mevcut metin tabanlı yapay zeka sohbet botlarına (chat agent) nasıl ses yeteneği kazandırılacağını anlattığı bir sunumdur. Sunumun öne çıkan temel noktaları şunlardır:

• Sesin Önemi: 2025 yılı yapay zeka sohbet botlarının yılı olsa da, sadece metin tabanlı arayüzler geleceği temsil etmiyor. Sesli iletişim; çok daha doğal, metne göre 3 kat daha hızlı, daha erişilebilir ve çok kanallı (örneğin müşteri hizmetleri telefon hatlarına veya Zoom toplantılarına entegre edilebilir) bir etkileşim sunuyor.
• Mevcut Sistemleri Çöpe Atmama (Geliştirici Problemi): Geliştiriciler mevcut sohbet botlarını, yönlendirme (routing), RAG (Erişim Destekli Üretim) ve araç çağırımı (tool calling) gibi özellikleri kurmak için zaten büyük emek harcadı. Sesli asistanlara geçiş yapmak için tüm bu arka planı sıfırdan yeniden inşa etmek mantıklı değil.
• Çözüm: “Voice Engine”: ElevenLabs, mevcut metin tabanlı botlarınızı baştan yazmanıza gerek kalmadan onları sesli asistanlara dönüştüren Voice Engine (Ses Motoru) adlı yeni bir ürünü tanıtıyor. Bu sistem, mevcut botunuzun etrafını saran bir “paket” gibi çalışıyor.

Voice Engine’in Öne Çıkan Özellikleri:

• Endüstri lideri doğrulukta sesten metne (STT) ve metinden sese (TTS) modelleri.
• Duyguya ve bağlama duyarlı tepkiler.
• Doğal insan iletişimindeki gibi “söz alma” (turn-taking) ve kullanıcının “söz kesmesini” (interruption) pürüzsüzce yönetebilme yeteneği.
• Entegrasyonu çok kolaylaştıran Sunucu (Server) ve İstemci (Client) SDK’ları.
• Ayrıca web sitelerine kolayca eklenebilecek modern, açık kaynaklı UI (kullanıcı arayüzü) bileşenleri.

Kullanıcılara İki Seçenek: Sunumun sonunda iki farklı geliştirme yolu sunuluyor:

1. Zaten bir botunuz varsa Voice Engine kullanarak ona sadece ses eklemek.
2. Her şeye sıfırdan başlıyorsanız, tamamen yönetilen ElevenLabs Agents Platform’unu kullanmak.

Özetle sunum, geleceğin yapay zekasında rekabet edebilmek için sohbet botlarının sese geçiş yapması gerektiğini ve ElevenLabs’in bu süreci sadece birkaç satır kodla yapılabilecek kadar basitleştirdiğini vurgulamaktadır.

58. İşlem Hatları Neden Sesli GYZ İnşa Edemiyor? , Neil Zeghidour, Gradium AI

Bu konuşmada, Gradium’ın Kurucu Ortağı ve CEO’su Neil Zeghidour, Sesli Yapay Zekanın (Voice AI) mevcut durumunu değerlendiriyor ve ünlü bilimkurgu filmi ”Her”deki gibi kusursuz, insansı bir sesli asistana ne zaman ve nasıl ulaşabileceğimizi tartışıyor.

• Beklenti ve Gerçeklik Arasındaki Uçurum: “Her” filmindeki yapay zeka, anında tepki veren, duygu durumunu anlayan ve akıcı konuşan bir yapıdadır. Ancak Zeghidour, günümüzdeki popüler sesli yapay zeka sistemlerinin (örneğin mevcut demoların) gerçek dünyada hala yüksek gecikme (latency) sorunları yaşadığını ve doğal hissettirmediğini vurguluyor.
• Kademeli Sistemlerin (Cascaded Systems) Sınırları: Günümüzde çoğu sesli yapay zeka STT (Sesten Metne) -> LLM (Büyük Dil Modeli) -> TTS (Metinden Sese) sırasıyla çalışır. Zeghidour, bu zincirin, özellikle yapay zeka bir işlem yaparken (örneğin internetten bir bilgi çekerken) insan sohbetine aykırı, uzun sessizliklere neden olduğunu belirtiyor.
• Bağlamsal Doldurucular (Contextual Fillers): Gradium, bu uzun sessizlikleri çözmek için geçici bir mühendislik çözümü sunuyor. Yapay zeka arka planda veri ararken, sistemin “Bunu senin için hemen kontrol ediyorum…” gibi “doldurucu” cümleler kurmasını sağlayarak diyaloğun kopmasını engelliyorlar.
• Yarı Çift Yönlü (Half-Duplex) vs. Tam Çift Yönlü (Full-Duplex) İletişim: Gecikmeyi azaltmak için geliştirilen yeni “Sesten Sese” (Speech-to-Speech) modeller bile genellikle yarı çift yönlü çalışıyor. Yani sistem ya sadece dinliyor ya da sadece konuşuyor. İnsanlar ise tam çift yönlü iletişim kurar; birbirlerinin sözünü kesebilir, karşıdaki konuşurken “hı-hı”, “evet” gibi onaylama sesleri (backchanneling) çıkarabilirler. Zeghidour’un eski ekibiyle geliştirdiği “Moshi” modeli tam çift yönlü iletişimi başaran ilk örneklerden biri olsa da, ticari ve hatasız bir ürün olmaktan henüz uzaktır.
• Ölçeklenebilirlik ve Gizlilik Sorunu: Büyük sesli yapay zeka modellerini bulutta (GPU’larda) çalıştırmak şirketler için çok maliyetlidir ve kullanıcı gizliliği açısından riskler taşır.
• Yeni Ürün: Gradium Phonon: Zeghidour konuşmanın sonunda, bu maliyet ve gizlilik sorunlarını çözmek için geliştirdikleri Phonon adlı yeni modeli tanıtıyor. Phonon, buluta veya güçlü GPU’lara ihtiyaç duymadan doğrudan cihaz üzerinde (örneğin akıllı telefonların CPU’sunda) çalışan, son derece hızlı, ucuz ve gizlilik odaklı bir TTS (Metinden Sese) modelidir.

Özetle: Neil Zeghidour, “Her” seviyesinde bir sese ulaşmanın sanıldığı gibi kolay veya standartlaşmış (commodity) bir durum olmadığını, sektörün gecikme, söz kesme dinamikleri ve maliyet gibi sorunları aşmak için hala çok ciddi bilimsel ve mühendislik yeniliklerine ihtiyaç duyduğunu savunmaktadır.

59. TTS Modelleri Neden Artık LLM’lere Benziyor? , Samuel Humeau, Mistral

Mistral AI’dan Samuel Humeau, şirketlerinin yeni açık kaynaklı Metinden Sese (Text-to-Speech, TTS) modelini ve modern ses üretimi mimarilerindeki ana eğilimleri anlatıyor.

• Gerçek Zamanlı Yapay Zeka Ajanları ve Gecikme (Latency): TTS sistemlerinin kullanım alanı artık makaleleri sese çevirmekten ziyade, gerçek zamanlı sesli sohbet botlarına (ajanlara) kaymıştır. Bu alandaki en büyük zorluk, insanlarla doğal bir sohbet hissi yaratabilmek için “gecikme süresini” (latency) en aza indirmektir.
• Ses Klonlama ve Marka Ses Kimliği: Humeau, modelin sadece birkaç saniyelik bir referans ses ile anında ses klonlayabildiğini canlı bir demo ile gösteriyor (bir Fransız aksanını ve kendi sesini klonluyor). Gelecekte büyük şirketlerin, tıpkı görsel logoları gibi kendi “ses kimliklerini” (vocal identity) oluşturacaklarını öngörüyor.
• Teknik Mimari ve Büyük Dil Modelleri (LLM) Yaklaşımı: Modern ses üretimi, tıpkı metin üreten LLM’ler gibi otoregresif (autoregressive) mimarilere yönelmektedir. Ancak ses verisinin (audio) boyutu metne göre çok büyüktür (yüksek bit hızı).
• Ses Sıkıştırma (Codec’ler) ve Flow Matching: Sesi doğrudan üretmek yerine, sistem sesi “token”lara sıkıştıran codec’ler kullanır. Mistral’in modeli, ses çerçevelerindeki tokenları tek tek üretmek (depth transformers) yerine, eşzamanlı olarak üretmeyi sağlayan ve difüzyon (diffusion) modellerine benzeyen “Flow Matching” adlı bir teknik kullanmaktadır.
• Hız ve Performans: Model, LLM’den gelen metin akışını alır almaz sesi üreterek (streaming) yaklaşık 70 milisaniye gibi çok düşük bir gecikme süresine ulaşmaktadır.

Sonuç olarak Humeau, geliştiricileri çok düşük gecikmeyle çalışan, ses klonlama yeteneğine sahip bu yeni açık kaynaklı modeli denemeye ve teknik makalesini okumaya davet ediyor.

60. ⭐MCP UI: Sınırları Genişletmek, Liad Yosef ve Ido Salomon, MCP Apps

Bu sunumda Ido Salomon ve Liad Yosef, YZ ajanlarıyla iletişim kurma şeklimizi kökten değiştirmeyi amaçlayan MCP-UI (yeni ve resmi adıyla MCP Apps) protokolünü ve bu teknolojinin gelecekteki “Yeni Web” vizyonunu anlatıyor.

1. Temel Sorun: Sadece Metin Yetersiz Günümüzde YZ sohbet botlarıyla (ChatGPT, Claude vb.) iletişim çoğunlukla metin üzerinden ilerliyor. Ancak konuşmacılara göre “metin en kötü yöntemdir”. Uzun metin duvarları kullanıcı deneyimini düşürürken, şirketlerin marka kimliklerini ve özel etkileşimlerini (butonlar, grafikler vb.) YZ sohbetine taşımasını engelliyor.

2. Çözüm: MCP Apps ile Etkileşimli Arayüzler Geliştirilen bu standart sayesinde, arka plandaki araçlar ve şirketler, YZ’ye sadece metin yanıtları dönmek yerine kendi kullanıcı arayüzlerini (UI) doğrudan sohbet penceresine gönderebiliyor.

• Anthropic ve OpenAI gibi devlerle ortaklık kurularak resmi bir standart haline getirildi.
• Shopify, Hugging Face, VS Code, Cursor, Postman ve GitHub gibi platformlar tarafından hızla benimsendi.

3. Sistem Nasıl Çalışıyor?

• Kullanıcı YZ’ye bir soru sorar veya komut verir.
• YZ, ilgili araca (MCP Server) istekte bulunur.
• Araç, metin yerine bir UI kaynağı (HTML/React bileşeni vb.) döndürür.
• YZ Asistanı (Host, örneğin Claude), bu arayüzü sohbet penceresinde güvenli bir şekilde (sandbox içinde) görselleştirir.
• Kullanıcı bu arayüzle doğrudan etkileşime girebilir (örneğin bir ürünü sepete ekleyebilir veya bir grafikteki veriye tıklayabilir). Bu etkileşimler çift yönlü olarak sisteme geri iletilir.

4. “Yeni Web” Paradigması Konuşmacılar bunun sadece teknik bir güncelleme değil, web’i algılama şeklimizde bir devrim olduğunu vurguluyor:

• Artık farklı işlemler için onlarca sekme veya web sitesi açmaya gerek kalmayacak.
• Uygulamalar artık kullanıcının tüm yolculuğunu (user journey) kontrol etmiyor. Bunun yerine uygulamalar, kişisel YZ asistanınıza küçük “arayüz parçacıkları” veriyor.
• Örneğin; bir tatil planlarken YZ asistanınız Google’dan takvimi, Booking’den haritayı ve Amazon’dan hediyeleri çekip tek bir sohbet ekranında sizin için birleştirebiliyor.

5. UI Üretim Esnekliği MCP Apps çok esnek bir yapıya sahip:

• Önceden Tanımlı (Predefined) UI: Şirketin kendi kodladığı, birebir kendi markasını yansıtan arayüzler.
• Üretken (Generative) UI: YZ’nin kullanıcının isteğine göre anında, sıfırdan oluşturduğu arayüzler. MCP Apps protokolü her ikisini de destekliyor.

Hedef, yapay zeka asistanları içindeki kullanıcı arayüzleri için küresel bir standart oluşturmak. Tıpkı web siteleri gibi, geliştiricilerin “Bir kere yazıp, tüm YZ platformlarında çalıştırabileceği” (Write once, run everywhere) bir ekosistem inşa ediliyor. Konuşmacılar geliştiricileri SDK’ları kullanmaya ve resmi Discord topluluğuna katılarak bu yeni web devriminin bir parçası olmaya davet ediyor.

61. Edge’de Yapay Zekâyı Hızlandırmak , Chintan Parikh ve Weiyi Wang, Google DeepMind

Google AI Edge ürün yöneticisi Chintan Parikh yapay zeka modellerinin uç cihazlarda (edge devices) yerel olarak çalıştırılmasına ve bu sürecin nasıl hızlandırılacağına odaklanmaktadır.

1. Gemma 4 Uç (Edge) Modelleri:

• Google DeepMind, cihaz içi (on-device) kullanım için optimize edilmiş Gemma 4 modellerini (özellikle 2 Milyar ve 4 Milyar parametreli versiyonları) tanıttı. Bu modeller Hugging Face üzerinden açık kaynaklı olarak (Apache 2.0 lisansıyla) erişilebilir durumdadır.
• Avantajları: Yapay zekayı cihazda çalıştırmak; ağ gecikmesini ortadan kaldırır (hız), hassas verilerin sunucuya gitmesini engeller (gizlilik), internet bağlantısı gerektirmez (çevrimdışı kullanım) ve bulut/API maliyetlerini düşürür.
• Yeni Yetenekler: Gemma 4 modelleri artık karmaşık görevleri yerine getirebilmek için; İşlev Çağırma (Function Calling), Yapılandırılmış JSON Çıktısı ve yapay zekanın yanıt vermeden önce düşünme sürecini gösteren Düşünce Zinciri (Chain of Thought) gibi gelişmiş aracılık (agentic) özelliklerine sahiptir.

2. Google AI Edge Galeri Uygulaması:

• Google, geliştiricilerin bu modellerin yeteneklerini test edebileceği açık kaynaklı bir Galeri Uygulaması sunmaktadır.
• Bu uygulama sayesinde kullanıcılar, Wikipedia’dan veri çekme, fotoğraf yükleyerek içeriğe uygun müzik üretme, uyku/ruh hali verilerini analiz edip grafik oluşturma gibi görevleri tamamen cihaz üzerinde internet olmadan gerçekleştirebilirler.
• Geliştiriciler uygulamanın GitHub reposunu kullanarak kendi yapay zeka “becerilerini” (skills) kodlayabilir ve toplulukla paylaşabilirler.

3. LiteRT Çerçevesi (Eski adıyla TensorFlow Lite):

• LiteRT, yapay zeka modellerini cihazlara entegre etmek için kullanılan ana çerçevedir. Yalnızca TensorFlow’u değil, PyTorch ve JAX modellerini de destekler.
• Çoklu Platform: Android, iOS, Windows, macOS, Linux, Web ve IoT (Örn: Raspberry Pi) gibi birçok platformda sorunsuz çalışacak şekilde tasarlanmıştır.
• Yüksek Performans: CPU, GPU ve NPU (Nöral İşlem Birimi) hızlandırmalarını destekler. Sunumdaki verilere göre mobil cihazlarda alternatiflerine (örneğin Llama.cpp) göre 35 kata kadar daha hızlı çalışabilmektedir.

4. Araçlar ve Demo:

• Geliştiriciler için modelleri analiz etmeye yarayan Model Explorer, farklı cihazlarda hız testi yapmayı sağlayan bulut tabanlı AI Edge Portal ve terminal üzerinden kolay kullanım sağlayan CLI araçları tanıtılmıştır.
• Sunumun sonunda, bir Raspberry Pi ve yerel bir kamera kullanılarak çalışan küçük bir robot demosu gösterilmiş, bu teknolojinin akıllı ev kameraları gibi cihazlarda gizliliği koruyarak nasıl kullanılabileceği soru-cevap bölümünde tartışılmıştır.

Özetle Google, Gemma 4 modelleri ve LiteRT aracı ile geliştiricilere, buluta ihtiyaç duymadan, hızlı, güvenli ve maliyetsiz bir şekilde telefonlardan robotlara kadar her türlü cihazda gelişmiş yapay zeka uygulamaları geliştirmeleri için tam kapsamlı bir ekosistem sunmaktadır.

62. Bir Yapay Zekâ Ajanına Hayatımın Anahtarlarını Verdım (Ve Olanlar) , Radek Sienkiewicz (@velvetshark-com)

OpenClaw geliştiricilerinden (maintainer) Radek’in, kişisel ve profesyonel hayatının tüm anahtarlarını bir yapay zeka (AI) ajanına nasıl teslim ettiğini anlatmaktadır.

1. Her Şey Bir Anda Olmadı (Adım Adım İlerleme) Radek, sistemin tüm erişimini (e-postalar, notlar, dosyalar, takvim, işletim sistemi) yapay zekaya bir kerede vermediğini vurguluyor. Bu süreç; sadece WhatsApp üzerinden basit sohbetlerle başlamış, ardından Telegram ve Discord’a geçmiş ve her adımda yapay zekaya duyulan güvenin test edilmesiyle yavaş yavaş inşa edilmiş.

2. Sistemin Kalbi: “Bilgi Tabanı” (Knowledge Base) Yapay zeka ajanının bu kadar işlevsel olmasını sağlayan şey, Radek’in yıllardır Obsidian uygulamasında tuttuğu 3.000'den fazla (iş, özel hayat, projeler, araştırmalar) nottan oluşan bilgi tabanıdır. Ajan bu notları indeksleyerek Radek’in hayatı, projeleri ve bağlantıları hakkında derin bir bağlama (context) sahip oluyor. Yeni eklenen bir linki veya notu analiz edip, geçmiş notlarla ilişkilendirebiliyor.

3. Gece Mesaisi (Sabaha Hazırlık) Ajan, her gece saat 04:00 sularında arka planda çalışarak kendini güncelliyor, çalışma alanını ve hafızasını yedekliyor, indeksleri yeniliyor ve Radek sabah uyandığında her şeyin hazır olması için günlük özetleri oluşturuyor.

4. Yapay Zeka Ajanının 5 Temel Görevi Radek, ajanının yaptığı işleri 5 kategoriye ayırıyor:

• Arka Plan İşlemleri (Ambient Operations): Sistemin güncel, yedeklenmiş ve çalışır durumda tutulması.
• Dikkat Filtreleme (Attention Filtering): E-postaları ve bildirimleri tarayarak sadece acil ve önemli olanları (örn. ödenmemiş bir Netflix faturası, süresi dolmak üzere olan bir domain) Radek’e sunması.
• Yürütme Desteği (Execution Support): Bağlamı (context) anlayarak e-postalara taslak yanıtlar yazması, YouTube videolarını araştırması, gelen kutusunu düzenlemesi.
• Hafıza Oluşturma (State and Memory Building): Öğrendiği yeni bilgileri Obsidian’daki notlara kalıcı olarak işlemesi.
• Güven ve Kontrol (Trust and Control): Sistemin sınırlarını belirlemek için soul.md (davranış kuralları) veya critical_rules.md (asla yapılmaması gerekenler) gibi basit metin dosyaları kullanılarak ajanın kontrol altında tutulması.

5. Karşılaşılan Zorluklar Sistem büyüdükçe hatalı hafıza kayıtlarının birikmesi, gürültülü (gereksiz) notların yanlış bağlantılar kurması ve otomasyonların zaman zaman kırılarak operasyonel risk yaratması gibi sorunlar yaşanabiliyor. Radek bunları, sınırları netleştirerek çözdüğünü belirtiyor.

Radek sunumunu şu felsefeyle bitiriyor: İnsanlar genellikle tembeldir (“Geçmişteki sen” hiçbir şey yapmak istemez). Bu yüzden her şeyi yapabilen, yorulmayan bir “Gelecekteki sen” (Yapay Zeka Ajanı) yaratmalısınız. Geliştiricilere tavsiyesi ise; her şeyi bir anda otomatize etmeye çalışmamaları, tek bir can sıkıcı sorunu çözerek başlamaları, zamanla güven inşa etmeleri ve kişisel ajanları “sıkıcı ama güvenilir bir altyapı” haline getirmeleridir.

63. Yapay Zekâ Fiyatlandırmasında Ustalaşmak, Mayank Pant, Stripe

Yapay zeka şirketleri, geleneksel SaaS (Hizmet olarak yazılım) şirketlerinden 3 kat daha hızlı büyüyor. Ancak bu muazzam hız, fiyatlandırmayı son derece zorlaştırıyor. Geleneksel sabit abonelik veya sadece kullanıma dayalı (usage-based) fiyatlandırma modelleri YZ için yetersiz kalıyor. Çünkü yapay zekada donanım (compute) maliyetleri öngörülemiyor, sistemi çok kullanan az sayıda kullanıcı kâr marjlarını hızla eritebiliyor ve teknik fiyatlandırma terimleri (API çağrısı, token sayısı vb.) son kullanıcıların kafasını karıştırıyor.

Sektördeki Eğilim: Hibrit Modele Geçiş Pant’ın sunduğu verilere göre, YZ pazarındaki şirketler hızla Hibrit Fiyatlandırma modeline (Sabit temel abonelik ücreti + Kullanıma bağlı ölçeklenen ücret) geçiş yapıyor. Sektördeki lider YZ şirketlerinin %56'sı halihazırda bu modeli kullanıyor.

Doğru YZ Fiyatlandırması İçin 5 Adımlı Strateji

1. Değerinizi Tanımlayın (Define Your Value): Fiyatlandırmanızı ürününüzün teknik olarak ne yaptığına (örn. API çağrıları) göre değil, müşteriye sağladığı değere (zaman tasarrufu, üretilen sunum sayısı, ROI vb.) göre belirleyin. Müşterinin umrunda olan şey altyapı değil, elde ettiği sonuçtur.
2. Ücretlendirme Metriğinizi Seçin (Select Your Charge Metric): Teknik karmaşıklığı müşteriden gizleyin. En iyi yöntemlerden biri özellikleri “Krediler” (Credits) halinde paketlemektir. Örneğin müşteriye aylık 100 kredi verip, bu kredilerin arka planda hangi işlemlere denk geldiğini kendi iç sisteminizde yönetebilirsiniz.
3. Fiyatlandırma Modelinizi Belirleyin (Pick Your Pricing Model): Sadece abonelik veya sadece kullandıkça öde modelleri yerine, ikisinin en iyi yönlerini alan Hibrit modeli seçin. Bu model hem öngörülebilir bir gelir sunar hem de kullanımla birlikte maliyetlerinizi koruyarak ölçeklenmenizi sağlar.
4. Güvenlik Çerçeveleri Oluşturun (Build in Guardrails): Müşteriyi şoke eden faturalardan (“bill shock”) ve kendinizi zarardan korumak için sınırlar koyun. Harcama limitleri belirleyin, kullanıcı kotasının %50'sine, %75'ine ulaştığında otomatik bildirimler gönderin ve sistemi korumak için hız sınırları (rate limiting) uygulayın.
5. İterasyon Yapın (Iterate): Fiyatlandırmayı statik bir şey olarak değil, sürekli gelişen bir ürün gibi düşünün. Piyasaya hızlı çıkın, verileri analiz edin, müşteri geri bildirimlerini alın ve fiyatlarınızı sürekli olarak yeni eklenen özelliklere göre güncelleyin. Hızlı büyüyen AI şirketleri fiyatlarını son 2 yılda 3'ten fazla kez değiştirmiştir.

Sık fiyat değiştirmenin müşterileri rahatsız edip etmeyeceği sorusu üzerine Pant; kredi sisteminin bu değişiklikleri müşteriden soyutlamak için harika bir araç olduğunu ve eski müşterilerin eski fiyatlarda tutulup (grandfathering) yeni müşterilerin yeni fiyatlarla sisteme dahil edilebileceğini belirtiyor. Son olarak, bu kadar hızlı fiyatlandırma denemeleri yapabilmek için (Stripe gibi) esnek ve güçlü bir faturalandırma altyapısına sahip olmanın kritik olduğunu vurguluyor.

64. tldraw Üzerinde Canvas İçinde Ajanlar, Steve Ruiz, tldraw

Konuşmacı Steve Ruiz, tldraw’ın hem çevrimiçi bir beyaz tahta hem de başka ürünler geliştirmek için kullanılabilecek bir SDK olduğunu tanıtıyor. Sunumunda, yapay zeka (AI) ile entegre edilen çeşitli tldraw projelerini ve özelliklerini sergiliyor.

İlk olarak, 2023 yılında popüler olan “Make Real” uygulamasını gösteriyor. Bu uygulama, çizilmiş bir kullanıcı arayüzünü (UI) alıp çalışan bir prototipe dönüştürmeyi amaçlıyor. Bir düğmenin rengini değiştirmeye çalışırken yaşanan ufak bir aksaklıktan sonra demo tanrılarına atıfta bulunuyor.

Ardından, “Computer” adlı bir projede zincirleme istemlerin (prompt) nasıl kullanıldığını ve “Teach” projesinde bir YZ ajanının canvas üzerinde nasıl işbirliği yaptığını gösteriyor. “Üzgün bir kedi çiz” komutunu veriyor, ardından “kediyi mumu üflet” ve “fare çiz” diyerek YZ’nin çizimi detaylandırmasını sağlıyor. YZ, kedinin şaşkın yüz ifadesini, muma üfleyen bir rüzgar efektini ve fareyi ekliyor.

Daha sonra, birden fazla YZ ajanının (Fairies/Periler) bir canvas üzerinde eş zamanlı ve koordineli bir şekilde çalıştığı bir demoyu sunuyor. Bu ajanlar, kullanıcının “daha fazla hayvan çiz” komutuna yanıt olarak kuş ve tilki gibi hayvanları çizmek için görevleri aralarında paylaşıyorlar.

Steve, bu hacklenebilir canvas’lar ve ajanlarla ilgili güvenlik sorunlarına değiniyor. Özellikle web tabanlı uygulamalarda kod enjeksiyonu gibi risklerin yönetilmesinin zor olduğunu belirtiyor. Bu sorunu aşmak için, tldraw’ın bir Electron sarıcısı olan masaüstü uygulamasını kullanıyor. Bu uygulamada, YZ ajanları doğrudan kullanıcının yerel bilgisayarında JavaScript kodu yazarak arayüzü etkileşimli hale getirebiliyor. Bir karakter çizerek bacak uzunluğunu ayarlayan bir sürgü ve tişört rengini değiştiren butonlar gibi etkileşimli öğeler oluşturuyor ve YZ bu öğeler için HTML ve JavaScript kodunu otomatik olarak üretiyor.

Sunumunu, yerel, dosya tabanlı uygulamaların YZ ajanlarıyla birleştiğinde büyük bir potansiyel sunduğunu, ancak bu “keskin araçların” dikkatli kullanılması gerektiğini vurgulayarak bitiriyor.

65. Hepsini Yöneten Tek Giriş: MCP için Uygulamalar Arası Erişim , Garrett Galow, WorkOS

Ürün yöneticisi işinin en zorlayıcı kısımlarından biri olan “toplantı planlama” sürecini kolaylaştırmak için geliştirdiği yapay zeka destekli asistanı (özel bir MCP sunucusunu) tanıtıyor.

Videonun temel noktaları şunlardır:

• Sorun ve Çözüm: Toplantı ayarlamak zaman alıcı bir iştir. Konuşmacı bu sorunu çözmek için Büyük Dil Modellerinden (LLM) yararlanan ve “Pipes” altyapısını kullanan bir zamanlayıcı asistan geliştirmiştir.
• Pipes ile Kimlik Doğrulama: Sistem, Linear (proje yönetim aracı) ve Google Takvim gibi üçüncü parti uygulamalara erişmek için “Pipes” kullanır. Pipes, kullanıcı yetkilendirmesini (Authorization URL), erişim anahtarlarını (Token) ve bu anahtarların yenilenmesi gibi karmaşık arka plan işlemlerini çok kolay bir şekilde yönetir.
• Canlı Demo Süreci:

1. Veri Çekme (Linear): Konuşmacı, yapay zekaya “Linear’daki Pipes projesinde kimlerin çalıştığını” sorar. Sistem ekranda bir izin penceresi açar. Konuşmacı Linear hesabı için erişim izni verdikten sonra asistan, projede çalışan kişileri (Dan, konuşmacının kendisi ve Alex) listeler.
2. Uygunluk Kontrolü (Google Takvim): Konuşmacı, projeyi incelemek için bu ekiple bir toplantı zamanı bulmasını ister. Sistem bu kez Google Takvim’i okumak için izin penceresi açar. İzin verildikten sonra herkesin takvimini kontrol eder ve uygun saatleri listeler.
3. Toplantı Ayarlama: Konuşmacı “Salı 9:30'u ayarlayabilir misin?” der. Sistem, yeniden izin istemeye gerek kalmadan (çünkü erişim anahtarı zaten alınmıştır) toplantıyı doğrudan oluşturur ve Google Takvim davetiyesinin linkini paylaşır.

Yani Galow, “Pipes” kullanarak üçüncü parti uygulamaları (ve onların kimlik doğrulama süreçlerini) kendi yapay zeka projelerinize entegre etmenin ne kadar pratik ve sorunsuz olduğunu göstermektedir.

66. ⭐ MCP = Mega Bağlam Problemi, Matt Carey

Cloudflare’dan Matt Carey’nin yapay zeka ajanlarının devasa API’leri nasıl daha verimli ve güvenli bir şekilde kullanabileceği üzerine yaptığı bir sunumu içermektedir.

Temel Problem: Bağlam Penceresinin (Context Window) Aşılması Geleneksel olarak ajanlara dış dünyayla etkileşim kurmaları için “araçlar” (tools/function calling) verilir. Ancak Cloudflare gibi 2.500'den fazla uç noktası (endpoint) olan devasa bir API’yi ajana tek seferde sunmaya kalktığınızda, bu durum 2.3 milyon token’lık bir veri oluşturarak LLM’lerin bağlam penceresini anında doldurur ve sistemi işlevsiz hale getirir.

Çözüm Arayışları ve Kademeli Keşif (Progressive Discovery) Tüm araçları aynı anda yüklemek yerine, ajanın araçları “ihtiyaç duydukça keşfetmesi” gerektiği fikri ortaya çıktı. Bunun için üç yöntem denendi:

1. CLI (Komut Satırı Arayüzü): Ajanlara komut satırı erişimi vermek işe yarar ancak kabuk (shell) erişimi gerektirdiği için her senaryoya uygun değildir.
2. Araç Arama (Tool Search): Ajanın ihtiyacı olan aracı bulması için bir “arama aracı” kullanması.
3. Kod Modu (Code Mode , Asıl Odak): Ajana tüm API uç noktalarını vermek yerine, sadece API’nin veri tiplerini (TypeScript tanımlarını) verip, ajandan o API’yi kullanacak kendi kodunu yazmasını istemek.

Kod Modunun Önündeki Engel: Güvenlik Ajanın kod yazıp bunu çalıştırması harika bir fikir olsa da, müşteriler (geliştiriciler) yapay zeka tarafından üretilen “güvenilmeyen (untrusted)” kodları kendi sistemlerinde çalıştırmaktan haklı olarak korktular. Bu kodlar sonsuz döngülere girebilir, gizli verilere (sır/secret) erişebilir veya sistemi çökertebilirdi.

Cloudflare’ın Çözümü: İzole Korumalı Alanlar (Sandboxes) Cloudflare bu sorunu çözmek için yapay zekanın ürettiği kodları (JavaScript, TypeScript veya Python) dinamik, anlık ve son derece izole edilmiş “Worker” (sandbox/korumalı alan) ortamlarında çalıştıran bir sistem geliştirdi. Ajan kod yazar, bu kod güvenli bir sanal ortamda çalıştırılır ve sadece izin verilen ağlara veya verilere erişebilir.

Gelecek Vizyonu Carey, API’lerin ajanlar tarafından kullanımının geleceğini şu şekilde özetliyor:

• Programatik Araç Çağrısı: Ajanlar artık hazır araçları çağırmak yerine, hedeflerine ulaşmak için anında kod yazıp çalıştıracaklar.
• Kaydedilmiş Mini Script’ler: Ajan, bir görevi başarmak için yazdığı ve çalışan kodu “kaydedecek”. Bir dahaki sefere aynı görev istendiğinde, sıfırdan düşünmek veya keşfetmek yerine doğrudan bu kaydedilmiş hızlı script’i çalıştıracak.
• Basitleşen Sunucular: MCP (Model Context Protocol) gibi yapılar sadece bir ara yazılım (middleware) görevi görecek. Ajanların kod çalıştırdığı istemci (client) tarafı çok daha yetenekli hale gelecek.

Özetle sunum; devasa API’lerin ajanlara öğretilmesi yerine, ajanlara “güvenli bir alanda kendi kodlarını yazarak API’leri kullanma yeteneği” verilmesinin yapay zeka mühendisliğinin geleceği olduğunu savunuyor.

67. ⭐ 1 Dolarlık Yapay Zekâ Guardrail’leri: Fine-Tune Edilmiş ModernBERT’lerin Beklenmedik Etkinliği, Diego Carpentero

Bu video, yapay zeka (özellikle Büyük Dil Modelleri , LLM) sistemlerine yönelik giderek karmaşıklaşan siber saldırıları ve bu saldırılara karşı ModernBERT gibi kodlayıcı (encoder) modelleri kullanarak nasıl 1 doların altında bir maliyetle, düşük gecikmeli ve yerel (self-hosted) güvenlik bariyerleri (guardrails) oluşturulabileceğini anlatmaktadır.

1. Yapay Zeka Saldırı Vektörlerinin Evrimi

Başlangıçta sadece basit “istem enjeksiyonu (prompt injection)” ile sınırlı olan saldırılar, günümüzde çok daha karmaşık ve otonom (ajan tabanlı) hale gelmiştir. Konuşmacı 6 temel saldırı vektörünü tanımlıyor:

• Doğrudan Enjeksiyon (Prompt Vector): Kullanıcının doğrudan sisteme komut vererek modelin güvenlik kurallarını aşması ve gizli sistem talimatlarını (örn. Bing’in “Sydney” kod adı ve kuralları) sızdırmasıdır. Temel sorun, LLM’lerin sistem komutları ile kullanıcı verisini birbirinden ayıramamasıdır.
• Dolaylı Enjeksiyon (Context Vector): Zararlı komutların web sitelerine, belgelere veya e-postalara gizlenmesidir. LLM bu dış kaynakları okuduğunda, sanki sistem komutuymuş gibi bu zararlı talimatları yerine getirir (örn. Wikipedia’ya gizlenmiş bir komutla güvenlik kontrollerini atlatmak).
• LLM İç Yapı Vektörü (LLM-Internals): Modelin matematiksel olasılıklarını sömüren bir saldırıdır. İnsanlar için anlamsız görünen özel “harf/kelime dizileri (gibberish suffix)”, modelin güvenlik (hizalama) duvarını yıkarak zararlı içerik üretmesine neden olur.
• RAG Vektörü (Bilgi Getirme): Şirketlerin bilgi veri tabanlarındaki belgelerin çok küçük bir kısmının (%0.0001 bile yeterli) zehirlenmesidir. Model bir soruya yanıt ararken bu zehirli veriyi çeker ve saldırganın istediği manipüle edilmiş yanıtı verir.
• MCP Vektörü (Model Bağlam Protokolü): Kullanıcının arayüzde gördüğü kısa ve masum “araç özeti” ile modelin arka planda okuduğu detaylı “araç talimatları” arasındaki asimetriden faydalanır. Kullanıcı masum bir işlemi onayladığını sanırken, model gizli talimatlar yüzünden kullanıcının özel şifrelerini (SSH, API vb.) dışarı sızdırabilir.
• Ajan Vektörü (Agentic Vector): Otonom yapay zeka ajanlarını kandırarak zararlı linklere tıklatmaya, bilgisayara zararlı yazılım indirmeye veya sahte kütüphaneler kurarak tedarik zinciri saldırıları yapmaya (uzaktan kod çalıştırmaya) yönelik saldırılardır.

2. “Sıfır Güven (Zero Trust)” Boşluğu

Konuşmacı, LLM’lerde klasik siber güvenlikteki “Sıfır Güven” (hiçbir şeye güvenme, her şeyi doğrula) prensibinin eksik olduğunu belirtiyor. Modeller, kendi içlerindeki güvenlik kurallarını (“hizalama”, alignment) kesin bir kural olarak değil, sadece bir olasılık olarak değerlendirir. Veri ve komut ayrımı olmadığı için, sadece modelin kendisine güvenmek büyük bir güvenlik zafiyetidir.

3. Çözüm: ModernBERT ile Güvenlik Bariyerleri (Guardrails)

Sistemin girdi, çıktı, bilgi getirme (RAG) ve ajan işlemleri gibi tüm aşamalarına güvenlik kontrol noktaları eklenmelidir. Bu iş için başka bir devasa LLM’i “hakem” olarak kullanmak çok yavaş (saniyeler sürer) ve pahalıdır. Bunun yerine, ModernBERT gibi kodlayıcı (encoder) modeller kullanmak çok daha mantıklıdır.

Neden ModernBERT?

• Tüm bağlamı aynı anda (çift yönlü) anlar.
• Çok hızlıdır (35 milisaniyenin altında tepki verir).
• Tek bir GPU’da saatler içinde eğitilebilir (fine-tuning).
• Kendi sunucularınızda (Self-hosted) çalışarak veri gizliliğini korur.

4. ModernBERT’in Mimari Yenilikleri

Modelin bu kadar verimli olmasını sağlayan teknik geliştirmeler şunlardır:

• Alternatif Dikkat (Alternating Attention): Her tokenin diğer tüm tokenlere bakması bellek israfıdır. Global dikkat ile yerel (kayan pencere) dikkati birleştirerek bellek ihtiyacını %70 oranında azaltır.
• Doldurmayı Kaldırma ve Dizi Paketleme (Unpadding & Sequence Packing): Farklı uzunluktaki metinleri işlerken GPU’nun boşluklarla (padding) uğraşarak israf yapmasını engeller; anlamlı metinleri paketleyerek tek seferde işler.
• Derin ve Dar Mimari: Daha az boyut (dimension) ama daha fazla katman (layer) kullanarak semantik anlamayı artırır.
• Döner Konumsal Kodlama (RoPE): Tokenlerin sırasını ezberlemek yerine vektörleri döndürerek uzun metinlerde bağlamın kaybolmasını engeller.
• Flash Attention 2: GPU içindeki çip üstü hızlı belleği verimli kullanarak donanım seviyesinde optimizasyon sağlar.

5. Uygulama ve Sonuçlar

Konuşmacı, InjectGuard adlı 75.000 örneklik bir veri kümesi kullanarak ModernBERT modeline ince ayar (fine-tuning) yapmıştır.

• Sonuç olarak model, sadece 35 milisaniyelik bir gecikmeyle zararlı ve güvenli komutları yaklaşık %85 doğrulukla ayırt etmeyi başarmıştır.
• Videonun sonundaki demoda, modelin anlamsız metin saldırılarını (gibberish), gizlenmiş veri sızdırma komutlarını ve manipüle edilmiş Wikipedia sayfalarını başarıyla “Unsafe (Güvensiz)” olarak işaretlediği gösterilmektedir.

Ana Fikir: Yapay zeka güvenliği kritik bir aşamadadır ve devasa modellere veya pahalı çözümlere bağımlı kalmadan, herkesin kendi donanımında çalıştırabileceği, hızlı, ucuz ve etkili güvenlik katmanları oluşturmak mümkündür.

68. Minimax M2: 1 Numaralı Açık Modeli İnşa Etmek , Olive Song, MiniMax

Minimax M2; kodlama ve “aracı” (agentic) görevler için özel olarak eğitilmiş, 10 milyar aktif parametreye sahip, açık ağırlıklı (open-weight), hızlı ve maliyet açısından oldukça verimli bir modeldir. Piyasaya sürüldüğü ilk haftada Hugging Face’te en çok indirilen modeller arasına girmiş ve benchmark testlerinde üstün başarı göstermiştir.

Modelin Başarısını Sağlayan 4 Temel Özellik (Eğitim Stratejisi):

1. Kodlama ve Geliştirici Deneyimi: Model, 100 binden fazla ölçeklendirilmiş gerçek dünya kodlama ortamında eğitilmiştir. En önemli farkı, uzman yazılım geliştiricilerin “ödül modeli” (reward model) olarak kullanılmasıdır. İnsan uzmanlar, modelin sorunları nasıl tanımladığına ve nasıl kod yazdığına dair kesin geri bildirimler vererek modelin Python, Java, C# gibi birçok dilde güvenilir ve kullanıcı dostu olmasını sağlamıştır.
2. Uzun Vadeli Görev Takibi (Interleaved Thinking , İç İçe Geçmiş Düşünme): Geleneksel modeller, araçları (tools) kullanırken tek bir “düşünme” aşamasından sonra aracı çalıştırıp sonucu verir. M2 ise her araç kullanımından sonra ve ortamdan gelen her yeni yanıtta tekrar düşünür. Bu özellik, borsa verileri gibi sürekli değişen (dinamik ve gürültülü) ortamlarda modelin hatalarını fark edip stratejisini değiştirmesini ve uzun soluklu görevleri başarıyla tamamlamasını sağlar.
3. Sağlam Çerçeve Genelleştirmesi (Scaffold Generalization): Modelin sadece tek bir yapay zeka aracı platformuna (agent framework) alışmaması için eğitim verilerinde kasıtlı olarak değişiklikler (perturbations) yapılmıştır. Sistem komutları, kullanıcı komutları ve araç bilgileri sürekli değiştirilerek modelin her türlü yeni sisteme ve ortama kolayca adapte olması sağlanmıştır.
4. Çoklu Aracı (Multi-Agent) Ölçeklenebilirliği: Model küçük ve ucuz olduğu için, farklı görevler üstlenen birden fazla M2 modeli (örneğin; biri araştırma yapan, diğeri kod yazan, bir başkası rapor hazırlayan ajanlar) aynı anda paralel olarak çalıştırılabilir ve birbiriyle entegre edilebilir.

Olive Song sunumun sonunda, gelecekte piyasaya sürülecek olan M2.1 ve M3 modellerinden bahsederek; bu modellerin daha iyi kodlama, daha geniş bağlam hafızası, ses/video entegrasyonu ve daha proaktif özellikler sunacağının müjdesini veriyor.

69. LLM Uygulamanızı Alan Uzmanı Yapın: Uzman Sistem Nasıl Kurulur?, Christopher Lovejoy, Anterior

Anterior şirketinde Klinik Yapay Zeka Başkanı (ve eski bir tıp doktoru) olan Dr. Christopher Lovejoy’un sağlık gibi belirli sektörlere özel (domain-native) Büyük Dil Modeli (LLM) uygulamaları geliştirme stratejisi üzerine yaptığı bir sunumdur.

1. Temel Sorun: “Son Mil Problemi” (The Last Mile Problem) Lovejoy, LLM’leri sağlık gibi uzmanlık gerektiren alanlara uygulamanın zorluğunu “son mil problemi” olarak tanımlıyor. Yapay zeka modelleri ne kadar güçlü olursa olsun, sektöre özgü karmaşık iş akışlarını, nüansları ve belirsizlikleri (örneğin bir doktorun notlarındaki “konservatif tedavi” kavramının sınırlarını) tek başlarına tam olarak anlayamazlar. Modeller genellikle %95 başarı oranında tıkanır; %99 ve üzerine çıkmak için ekstra bir sisteme ihtiyaç vardır.

2. Ana Felsefe: Modellerden Ziyade Sistemler Önemlidir Dikey (sektörel) yapay zeka uygulamalarında kazananlar, en karmaşık modellere sahip olanlar değil; alan uzmanlarının (domain experts) bilgilerini sisteme en iyi entegre eden yapıyı kuranlar olacaktır.

3. Çözüm: Uyarlanabilir Alan Zekası Motoru (Adaptive Domain Intelligence Engine) Lovejoy, %95'lik başarıyı %99.2'ye çıkaran ve iki ana aşamadan oluşan kendi geliştirdikleri döngüsel sistemi tanıtıyor:

A. Ölçüm (Measure):

• Metrikleri Belirlemek: Müşteri (kullanıcı) için gerçekten neyin önemli olduğunu tanımlamak (örneğin sağlık sigortasında yanlış onay sayısını en aza indirmek).
• Hata Modu Ontolojisi (Failure Mode Ontology): Yapay zekanın neden başarısız olduğunu sınıflandırmak. (Örn: Yanlış belge çıkarma, hatalı klinik muhakeme veya kuralları yanlış yorumlama). Bu hata modları ile iş metrikleri birleştirilerek en çok zarara yol açan hatalar tespit edilir.

B. İyileştirme (Improve):

• Gerçek Verilerle Hata Veri Kümeleri: Sentetik veriler yerine, doğrudan canlı sistemden (production) alınan ve hata içeren verilerle veri kümeleri oluşturulur.
• Alan Uzmanları İçin Araçlar (Tooling): Sistem, kodlama bilmeyen alan uzmanlarına (örneğin doktorlar veya avukatlar) özel arayüzler sunar. Uzmanlar bu araçları kullanarak yapay zekanın çıktılarını inceler, hataları sınıflandırır ve modelin bilmediği sektörel kuralları/bilgileri sisteme öneri olarak ekler.
• Mühendislik Döngüsü: Mühendisler, uzmanların oluşturduğu bu hata veri kümelerini kullanarak sistemi günceller ve değişikliklerin işe yarayıp yaramadığını hızla test eder.

Önemli Çıkarımlar (Takeaways):

• Yalnızca en iyi LLM’leri kullanmak yeterli değildir; etrafında veriye dayalı, alan bilgisini içeren bir sistem inşa edilmelidir.
• Alan uzmanları (doktorlar, avukatlar vb.), yapay zeka çıktılarını inceleyip hataları tespit ederek sistemin kalbi olmalıdır.
• Başarılı bir alana özgü LLM uygulaması; canlı üretim verilerini kullanan, sürekli kendini geliştiren ve sürece hakim bir Alan Uzmanı Ürün Yöneticisi (Domain Expert PM) tarafından yönetilen bir sistemdir.

70. ⭐ Ajanınızı Eğitin: RL ile Güvenilir Ajanlar Geliştirmek, Kyle Corbitt, OpenPipe

Bu video, Kyle Corbitt’in AI Engineer World’s Fair’de (Yapay Zeka Mühendisleri Dünya Fuarı) Pekiştirmeli Öğrenme (RL , Reinforcement Learning) kullanarak güvenilir yapay zeka ajanları (agent) oluşturmak üzerine yaptığı bir sunumu içermektedir.

Sunum, “ART-E” adında, kullanıcıların e-posta kutularında doğal dille arama yapmasını ve sorularına cevap bulmasını sağlayan bir yapay zeka asistanı geliştirme süreci üzerinden ilerlemektedir.

1. Doğrudan Pekiştirmeli Öğrenmeye (RL) Başlamayın

• Corbitt, bir ajan geliştirirken hemen RL eğitimine geçilmemesi gerektiğini vurguluyor.
• İlk adımda, piyasadaki en iyi modelleri (o3, Gemini, GPT-4 vb.) kullanarak sadece iyi yazılmış komutlarla (prompting) bir temel (baseline) oluşturulmalıdır. Bu sayede araçlardaki hatalar ayıklanır, RL’ye gerçekten ihtiyaç olup olmadığı görülür ve RL ile geçilmesi gereken hedefler belirlenir.

2. RL ile Elde Edilen Çarpıcı Sonuçlar Sadece komutlarla çalışan en iyi model (o3) %90 doğruluk oranına ulaştığında, ekip çok daha küçük ve açık kaynaklı bir modeli (Qwen 2.5 14B) RL ile eğitti. Elde edilen sonuçlar:

• Doğruluk (Accuracy): %90'dan %96'ya çıktı (önceki modelin yaptığı hataların %60'ı düzeltildi).
• Maliyet (Cost): 1000 işlem başına 55 dolardan 0.85 dolara düştü.
• Hız/Gecikme (Latency): Yanıt süresi 5.6 saniyeden 1.1 saniyeye indi.
• Eğitim Maliyeti: Bu RL eğitimini yapmak eskiden çok zor olsa da, şu an sadece 80 dolarlık GPU maliyeti ve yaklaşık 1 haftalık bir mühendislik süresi aldı.

3. Modern RL’deki İki Büyük Zorluk ve Çözümleri

• Gerçekçi Ortam (Realistic Environment): Ajanın eğitilebilmesi için gerçekçi bir e-posta kutusuna ihtiyacı vardı. Ekip, bunun için ABD Adalet Bakanlığı tarafından halka açılan meşhur Enron e-posta veri setini (500 bin gerçek e-posta) kullandı.
• Ödül Fonksiyonu (Reward Function): Ajanın doğru yapıp yapmadığını bilmesi gerekir. Ekip, Gemini 2.5 Pro modelini kullanarak Enron e-postalarını okuttu ve bu e-postalardan “gerçekçi sorular ve kesin doğru cevaplar” (altın veri kümesi) üretti. Ajanın bulduğu cevap, bu altın cevapla eşleştiğinde ajan ödüllendirildi.

4. Ek Ödüller ve Cezalarla Davranışı Şekillendirme Sadece doğru cevabı bulmak yeterli değildir. Ajanın davranışını mükemmelleştirmek için ek cezalar/ödüller eklendi:

• Ajanın e-posta kutusunda gereksiz yere defalarca arama yapmasını engellemek için daha az adımda (turn) sonuca ulaşması ödüllendirildi.
• Ajanın cevabı bilmediği halde uydurması (halüsinasyon) cezalandırıldı. Bunun yerine “bilmiyorum” demesi teşvik edildi.

5. Ödül Hackleme (Reward Hacking) Sorunu Ajanlar bazen sorunu gerçekten çözmek yerine, ödül sistemindeki bir açığı bularak puan toplamaya çalışırlar (Örneğin; bir yarış oyununda bitiş çizgisine gitmek yerine, olduğu yerde dönüp durarak ekstra puan kazanmayı öğrenen yapay zeka).

• Ekip, Hacker News için başlık üreten başka bir RL projesinde ajanın makaleyi okumak yerine her seferinde “Google çalışanlarının %80'ini işten çıkardı” gibi dikkat çekici ama uydurma tek bir başlık atarak hile yaptığını fark etti.
• Çözüm: Ajanın çıktılarını (rollouts) insan gözüyle düzenli olarak kontrol etmek ve ajanın hile yaptığını fark ettiğinizde bu hileli davranışa özel yeni bir ceza (penalty) kuralı eklemektir.

Sunum, büyük ve pahalı modeller yerine, küçük modellerin o spesifik göreve yönelik olarak Pekiştirmeli Öğrenme (RL) ile eğitilmesinin çok daha ucuz, hızlı ve başarılı sonuçlar verdiğini kanıtlamaktadır. Tüm proje kodları ve veri setleri açık kaynak olarak paylaşılmıştır.

71. Jane Street’te Yapay Zekâ Mühendisliği, John Crepezzi

Bu video, Jane Street şirketinde Yapay Zeka Asistanı (AI Assistance) ekibinde çalışan John Crepezzi’nin, şirketin kendine has yazılım geliştirme ekosistemi için özel yapay zeka araçlarını nasıl geliştirdiklerini anlattığı bir sunumdur.

Temel Problem: Piyasada Bulunan Yapay Zeka Araçlarının Yetersizliği Piyasadaki standart kod yazan Büyük Dil Modelleri (LLM’ler, örn. GitHub Copilot), Jane Street için işe yaramamaktadır. Bunun iki ana nedeni vardır:

1. OCaml Dilinin Kullanımı: Şirket hemen hemen her şey (web, arka uç, Vim eklentileri, hatta FPGA donanım kodlaması) için OCaml dilini kullanmaktadır. Piyasada OCaml ile yazılmış açık kaynak kod çok az olduğu için, LLM’ler bu dilde kod yazma konusunda oldukça başarısızdır.
2. Özel Geliştirme Ortamı: Şirketin tamamen kendi geliştirdiği derleme (build) sistemleri, dağıtık kod inceleme aracı (“Iron”) ve Mercurial tabanlı devasa bir “monorepo” sistemi vardır. Ayrıca şirketteki geliştiricilerin %67'si editör olarak Emacs kullanmaktadır. Standart araçlar bu özel altyapıya entegre olamamaktadır.

Hedeflenen Çözüm Ekip, geliştiricinin yazacağı kısa bir metin komutuyla (prompt), birden fazla dosyada tip kontrolünden (type-check) geçen, derlenebilen ve hatasız çalışan 100 satırın altındaki kod farkları (diff) üretebilecek kendi özel yapay zeka sistemini kurmayı hedeflemiştir.

Veri Toplama Stratejisi (Workspace Snapshotting) Modeli OCaml dilinde eğitebilmek için [Bağlam, Komut, Kod Farkı] (Context, Prompt, Diff) şeklinde veri kümelerine ihtiyaçları vardı. Ancak:

• Mevcut “Özellikler/PR’lar” (Pull Request) çok büyüktü (500–1000 satır) ve açıklamaları yapay zekayı eğitmek için uygun değildi.
• “Commit” mesajları ise (“bunu düzelttim” gibi) anlamsızdı ve bağlamdan yoksundu.

Çözüm: Çalışma Alanı Anlık Görüntüleme (Workspace Snapshotting) adı verilen bir yöntem geliştirdiler. Geliştiricilerin arka planda kod yazma süreçlerinden ve derleme (build) sonuçlarından her 20 saniyede bir kesit aldılar. Bu sayede “Yeşil -> Kırmızı -> Yeşil” modelini yakaladılar: Yani kodun çalıştığı (Yeşil), geliştiricinin bir hata yaptığı/bozduğu (Kırmızı) ve hatayı çözüp kodu tekrar çalışır hale getirdiği (Yeşil) anları izole ettiler. Bu kod değişikliklerini alıp başka bir LLM’e vererek, “Bu değişikliği yapmak için bir insanın yazacağı ideal komut/açıklama ne olurdu?” sorusuyla veri setlerindeki “Komut” (Prompt) kısmını otomatik olarak ürettiler.

Değerlendirme ve Pekiştirmeli Öğrenme (RL) Yapay zekanın “iyi kod” yazabilmesi için modelin Pekiştirmeli Öğrenme (Reinforcement Learning) ile eğitilmesi gerekiyordu. Onlar için “İyi Kod” sadece sözdizimi doğru olan kod değil, derlenen ve testleri geçen koddur. Bunun için CES (Code Evaluation Service) adında bir sistem kurdular. Bu sistem, LLM’in ürettiği kodu alıp, önceden hazırlanmış bir derleme ortamında test ediyor. Kod başarılı olursa modele “ödül” vererek, onun çalışan kod yazma yeteneğini geliştiriyor.

Editör Entegrasyonu (AIDE) VS Code, Emacs ve Neovim kullanan geliştiriciler için her editöre özel baştan eklenti yazmak yerine “AIDE” adında arka planda çalışan merkezi bir servis (sidecar application) yazdılar. Yapay zeka modelleri, bağlam oluşturma ve derleme testleri bu serviste çalışıyor. Editörler ise sadece bu servisle konuşan “ince” (thin) birer arayüz olarak işlev görüyor. Bu sayede yapay zeka modelinde bir güncelleme yaptıklarında, geliştiricilerin editörlerini yeniden başlatmalarına gerek kalmıyor.

Jane Street, kendi özel dilleri olan OCaml ve kendi kapalı ekosistemleri için, hazır araçları kullanmak yerine; Meta’nın Hack dili için uyguladığı yöntemlerden ilham alarak, geliştiricilerin kod yazım süreçlerinden otomatik veri üreten ve bu verilerle derlenebilir kod üreten özel bir yapay zeka kod asistanı sistemi geliştirmeyi başarmıştır. Gelecekte RAG (Erişim Destekli Üretim) ve çoklu ajan (multi-agent) mimarileri üzerine çalışmayı planlamaktadırlar.

72. İhtiyacınız Olan Tek Şey MCP, Samuel Colvin, Pydantic

Colvin, “MCP is all you need” (Tek İhtiyacınız Olan Şey MCP) başlıklı konuşmasına başlığın bilerek abartılı seçildiğini belirterek başlıyor. MCP’nin her sorunu çözemeyeceğini kabul etmekle birlikte, geliştiricilerin çoklu ajan (multi-agent) iletişimini gereksiz yere karmaşıklaştırdığını ve MCP’nin özellikle otonom ajanlar arasındaki iletişimde son derece güçlü bir çözüm sunduğunu savunuyor.

Standart Çoklu Ajan Sorunu Geleneksel yapıda bir ana ajan (agent), çeşitli araçlara (tools) bağlanır. Ancak bu araçlar da kendi içlerinde LLM (Büyük Dil Modeli) kullanması gereken alt ajanlar olabilir. Her bir alt ajana ayrı ayrı LLM erişimi sağlamak, hem yapılandırma açısından zordur hem de maliyetleri artırır.

Çözüm: MCP ve “Sampling” (Örnekleme) Özelliği Konuşmanın teknik odak noktası, MCP’nin henüz çok bilinmeyen ama çok güçlü olan “Sampling” özelliğidir. Sampling, bir MCP sunucusunun (alt ajanın veya aracın), bağlı olduğu istemcinin (ana ajanın) LLM bağlantısını kullanabilmesine olanak tanır.

Yani süreç şöyle işler:

1. Ana ajan (istemci), MCP sunucusundan bir işlem yapmasını (bir aracı çalıştırmasını) ister.
2. MCP sunucusu (araç) bu işlemi yaparken bir LLM’e ihtiyaç duyarsa, doğrudan API’ye gitmek yerine ana ajana “Benim için LLM’e şu soruyu sor” der.
3. Ana ajan LLM’den cevabı alır ve araca geri iletir.

Demo Uygulaması (Pydantic AI ile) Colvin, bu kavramı göstermek için Pydantic AI kullanarak bir araştırma ajanı demosu yapıyor. Ajanın görevi, BigQuery üzerinden PyPI (Python paketleri) indirme istatistiklerini sorgulamaktır.

Demonun öne çıkan teknik faydaları şunlardır:

• Bağlam (Context) Tasarrufu: Alt ajan (araç), soruyu SQL’e çevirir ve BigQuery’de çalıştırır. Eğer SQL hata verirse, araç kendi içinde LLM’i kullanarak sorguyu düzeltip tekrar dener. Tüm bu deneme-yanılma süreci ana ajandan gizlenir. Böylece ana ajanın “bağlam penceresi” (context window) gereksiz SQL hatalarıyla şişmez.
• Anlık Geri Bildirim (Logging/Progress): Uzun süren işlemler sırasında, alt ajan çalışmaya devam ederken ana ajana (ve dolayısıyla kullanıcıya) “Sorgu çalıştırılıyor”, “Hata alındı, tekrar deneniyor” gibi anlık durum güncellemeleri (loglar) gönderebilir.

Colvin, MCP’nin sadece IDE’ler (Cursor, Claude Desktop vb.) için bir eklenti sistemi olmadığını; otonom alt ajanların ana ajanın LLM’ini kullanarak, maliyetli bağlam pencerelerini şişirmeden, çok daha modüler ve verimli bir şekilde çalışabilmesini sağlayan bir altyapı sunduğunu belirtmektedir.

73. ⭐Kendi Kendini Kodlayan Ajanlar , Colin Flaherty, Augment Code

Augment Code şirketinde Yapay Zeka Araştırmacısı olan Colin’in “Yapay Zeka Mühendisi Zirvesi”nde (AI Engineer Summit) gerçekleştirdiği “Kendini Kodlayan Ajanlar Geliştirmek” (Building Self-Coding Agents) başlıklı sunumunu içermektedir.

Temel Başarı: Kendini İnşa Eden Yapay Zeka Yapay zeka geliştirici araçları 2023'te “otomatik tamamlama” (autocomplete), 2024'te ise “sohbet botları” (chatbots) olarak hayatımızdaydı. 2025 ve sonrasının ise “Ajanlar” (Agents) dönemi olacağı öngörülüyor. Colin ve ekibi, bu vizyonla kendi kendini kodlayan bir ajan geliştirmiş. Bu ajan, insan gözetimi altında, kendi 20.000 satırlık kod tabanının (codebase) %90'ından fazlasını bizzat kendisi yazmış.

Ajan Neler Yapabiliyor?

• Entegrasyonlar: Slack, Jira, Notion, Linear ve Google Arama gibi 3. parti araçların entegrasyonlarını kendi koduna ekleyebiliyor. Eksik dokümantasyon olduğunda internette arama yaparak API’ların nasıl kullanılacağını öğrenebiliyor.
• Kendi Testlerini Yazmak: Verilen görevler doğrultusunda alt süreçler (subprocess) çalıştırarak kendi birim testlerini (unit test) yazabiliyor.
• Kendi Kendini Optimize Etmek: En etkileyici özelliklerinden biri; ajan yavaş çalıştığını fark ettiğinde kendi kodunu analiz etmiş (profiling), darboğazları tespit etmiş ve işlemleri hızlandırmak için kendi koduna “process pool” (işlem havuzu) ekleyerek kendini optimize etmiş.
• Hafıza ve Öğrenme: Bir dosyayı düzenlerken yetkilendirme (credential) eksikliğiyle karşılaşırsa, kullanıcıya ne yapması gerektiğini soruyor. Kullanıcıdan aldığı cevabı (örneğin şifrelerin nerede saklandığını) bir “hafıza aracına” kaydederek gelecekte aynı sorunu yardımsız çözebiliyor.

Ajanlar Hakkındaki Yaygın Yanılgılar (Yanlış Varsayımlar) Colin, geliştirme sürecinde sektördeki bazı yanlış varsayımları şöyle düzeltiyor:

1. “Tam Otonom (L5) ajanlar artık aramızda” yanılgısı: Gerçek dünyada yazılım mühendisliği sıfırdan temiz bir kod yazmak değildir; karmaşık ve dağınıktır. Ajanlar henüz başıboş bırakılacak seviyede tam otonom değildir.
2. “Ajanlar belirli kategorileri (örn. Sadece Frontend) ele geçirecek” yanılgısı: Teknolojinin doğası genel amaçlıdır. Ajanları “frontend veya backend ajanı” olarak sınıflandırmak yerine, “çözebildikleri görevlerin karmaşıklık seviyesi”ne göre değerlendirmek daha doğrudur.
3. “Ajanlar insan mühendisler gibidir” yanılgısı: İnsanlardan çok farklı güçlü ve zayıf yönleri vardır. Basit bir matematiksel mantığı kuramayabilirler ama bir insan mühendisin günlerini alacak bir arayüz kodunu saniyeler içinde hatasız yazabilirler.

Çıkarılan Önemli Dersler

• Ajanı Şirkete “İşe Almak” (Onboarding) Şarttır: Bir ajan ancak ona sağladığınız “bağlam” (context) kadar iyidir. Ajanın tıpkı yeni bir çalışan gibi şirket içi dokümanlara, Slack mesajlarına ve kod tabanına erişimi olmalıdır.
• Kod Artık Ucuz, Önemli Olan Testler: Yapay zeka ile kod üretmek artık çok kolay. Ajanlara daha fazla otonomi verebilmenin önündeki tek engel “iyi yazılmış testler”dir. Testin olmadığı bir yerde ajanlar sistemi bozacak hatalar (race conditions vb.) yapabilir.
• Kendi Hatalarını Düzeltme Gücü: Ekip, kullandıkları yapay zeka modelini 6 ay daha yeni bir sürümle güncellediğinde performans sadece %4 artmış. Ancak ajana testleri çalıştırıp hatalarını görerek kendini düzeltme (iterasyon) yeteneği verdiklerinde performans %20 artmış.

Ajanların (Agents) dünyasında yazılım mühendisliği şekil değiştiriyor. “Kod yazmak” değerini kaybedip sıradanlaşırken; ürün yönetimi, doğru tasarımı kurgulamak, müşteri geri bildirimlerini toplamak ve çok iyi test altyapıları kurmak mühendisliğin en değerli yetenekleri haline geliyor.

74. ⭐Pratik GraphRAG: Bilgi Grafikleriyle LLM’leri Daha Akıllı Hale Getirmek, Michael, Jesus ve Stephen, Neo4j

1. Geleneksel Sistemlerin ve Standart RAG’in Sınırlamaları Büyük Dil Modelleri (LLM’ler) kurumsal bilgi eksikliği yaşar, “halüsinasyon” (yanlış bilgi üretme) eğilimindedir ve verdikleri cevapların kaynağını açıklayamazlar. Verileri zenginleştirmek için kullanılan standart RAG (sadece vektör veritabanları kullanan sistemler) ise eksik kalır; çünkü vektör aramaları veriler arasında sadece istatistiksel “benzerlik” bulur, ancak “bağlamı” (context) ve kesin “ilgililiği” (relevance) tam olarak kavrayamaz.

2. Çözüm: GraphRAG (Bilgi Grafları + LLM’ler) GraphRAG, LLM’lerin yaratıcılığı ve dil yetenekleri ile Bilgi Graflarının (Knowledge Graphs) sunduğu gerçekleri, mantığı ve bağlamı birleştirir.

• Daha Yüksek Doğruluk: Microsoft ve data.world gibi kurumların araştırmaları, GraphRAG’in standart yöntemlere göre çok daha doğru sonuçlar verdiğini (bazı testlerde 3 kat iyileşme) göstermektedir.
• Açıklanabilirlik (Explainability): Vektörlerin kara kutu (black-box) yapısının aksine, bilgi graflarındaki düğümler (nodes) ve ilişkiler sayesinde yapay zekanın o cevaba nasıl ulaştığı net bir şekilde görülebilir.
• Tam Bağlam: Sisteme sadece ilgili birkaç cümle değil, o bilginin etrafındaki tüm ilişkisel ağ sunulur.

3. GraphRAG Nasıl Çalışır? (Ana Aşamalar) Sunumda GraphRAG’in arka plandaki çalışma mantığı şu adımlarla açıklanır:

• Bilgi Grafı Oluşturma:
• Parçalama (Chunking): Yapılandırılmamış veriler (örneğin bir PDF veya metin), yapısal alt parçalara ayrılır.
• Çıkarım (Extraction): LLM’ler kullanılarak metin içerisindeki varlıklar (kişiler, şirketler, lokasyonlar vb.) ve bu varlıklar arasındaki ilişkiler tespit edilerek bir graf şeması oluşturulur.
• Zenginleştirme (Enrichment): Topluluk tespiti veya PageRank gibi graf algoritmaları kullanılarak veriler daha da anlamlı hale getirilir ve gruplandırılır.
• Arama ve Erişim (Retrieval): Sadece basit bir vektör eşleştirmesi yapmak yerine, sistem bilgi grafına giriş noktaları bulur, ilişkiler üzerinden seyahat eder (graph traversal) ve soruyu yanıtlamak için gereken tüm kapsamlı bilgiyi toplayarak LLM’e iletir.

4. Pratik Araçlar ve Örnekler Konuşmacılar, geliştiricilerin bu sistemi kolayca kurabilmesi için sundukları bazı pratik araçları gösterdiler:

• Knowledge Graph Builder: PDF’leri, YouTube videolarını, Wikipedia makalelerini veya yerel dosyaları otomatik olarak okuyup bunlardan bilgi grafları çıkaran bir araç.
• NeoConverse (Ajan Yaklaşımı): Yapay zekanın sadece vektör araması yapmakla kalmayıp, farklı graf arama araçlarını (tools) çağırarak karmaşık soruları adım adım çözdüğü ajan (agent) tabanlı bir sistem.
• Açık Kaynaklı Paketler: Geliştiricilerin kendi projelerine entegre edebilmeleri için GraphRAG Python package gibi kütüphaneler sunulmaktadır.

Özetle; GraphRAG, yapay zeka uygulamalarını sadece kelime tahmini yapan bir yapıdan çıkarıp, veriler arasındaki ilişkileri “anlayan”, bağlamı kavrayan ve sunduğu bilgiyi açıklayabilen güvenilir, kurumsal düzeyde bir sisteme dönüştürmektedir.

76. Ajan Geliştirme Yaşam Döngüsü, Zack Reneau-Wedeen, Sierra

Sierra şirketinden Zack Reneau-Wedeen’in işletmeler için güvenilir ve yetenekli yapay zeka temsilcileri (AI agents) geliştirme süreçlerini anlattığı bir sunumdur. Sunumun temel odak noktası “Temsilci Geliştirme Yaşam Döngüsü” (Agent Development Life Cycle: ADLC) kavramıdır.

1. Yapay Zekanın Geçmişi ve İterasyonun Gücü Konuşmacı, 2016 yılında Google Lens ekibindeyken yapay zekanın “chihuahua köpekleri ile yaban mersinli kekleri” ayırt etmeye çalıştığı ilkel günlerden bahsediyor. O dönemde AI modellerinin bir “slot makinesi” gibi tahmin edilemez çalıştığını belirtiyor. Ancak bugünkü gelişmiş seviyeye sihirle değil, on yıllık sürekli ve adım adım iyileştirme (iterasyon) süreciyle gelindiğini vurguluyor.

2. İşletmeler İçin Yeni İhtiyaç: AI Temsilcileri 1995'te web sitelerine, 2015'te mobil uygulamalara sahip olmak nasıl bir standart haline geldiyse, 2025'te de işletmelerin müşterilerine hizmet verecek yapay zeka temsilcilerine sahip olmasının bir zorunluluk olacağını ifade ediyor.

3. Chubbies Örneği: Duncan Smuthers Bu yeni döneme örnek olarak giyim markası Chubbies için Sierra tarafından geliştirilen “Duncan Smuthers” adlı yapay zeka temsilcisini gösteriyor. Duncan sadece sorulara yanıt veren bir bot değil; markanın eğlenceli dilini konuşan, empati kuran, beden tavsiyesi veren, envanter kontrolü yapan, kargo takibi ve para iadesi gibi karmaşık işlemleri otonom bir şekilde yürütebilen bir temsilcidir.

4. Temel Sorun: “Jelatin Üzerine Bina İnşa Etmek” Zack, Büyük Dil Modellerinin (LLM) geleneksel yazılımlardan farklı olduğunu söylüyor. Geleneksel yazılımlar kesin, hızlı ve katı kurallara (eğer/öyleyse) bağlıyken; LLM’ler tahmin edilemez, bazen yavaş fakat çok esnek ve akıl yürütebilen sistemlerdir. Bu yüzden LLM’ler ile ürün geliştirmeyi “jelatin üzerinde bina inşa etmeye” benzetiyor. Sadece “kutu içinden çıktığı haliyle” kullanılamayacaklarını belirtiyor.

5. Çözüm: Temsilci Geliştirme Yaşam Döngüsü (ADLC) LLM’lerin bu güvenilmez yapısını aşmak ve kusursuz müşteri deneyimi sunmak için Sierra, geleneksel yazılım geliştirme döngüsünden ilham alarak ADLC’yi kurmuş. Döngü şu aşamalardan oluşuyor:

• Kalite Güvencesi (QA) ve Denetim: Müşteriler, “Deneyim Yöneticisi” aracı üzerinden AI’ın müşteriyle yaptığı konuşmaları gerçek zamanlı olarak denetleyebiliyor.
• Hata Raporlama ve Test: Eğer YZ yanlış bir envanter bilgisi verirse, bu raporlanıyor. Sistem bu hatadan yola çıkarak yeni bir test senaryosu oluşturuyor.
• Sürüm ve Güncelleme: Testlerden geçen düzeltmelerle YZ güncelleniyor. Bu sayede YZ ajanı (kusursuz olmasa bile) her geçen gün daha da iyiye gidiyor.

6. Sesli Modeller ve Gelecek Sunumun sonlarına doğru, SiriusXM gibi on milyonlarca abonesi olan dev şirketler için bu döngünün çok daha hayati olduğunu vurguluyor. Ayrıca Sierra’nın yeni “sesli” yapay zeka özelliklerinden bahsederek, sesten sese iletişim kurabilen yapay zeka modellerinin çok daha düşük gecikmeyle (gecikmesiz) doğal sohbetler kurabildiğini belirtiyor.

Zack sunumunu, Büyük Dil Modellerinin aslında insanlara çok benzediği (tahmin edilemez, bazen yavaş ve matematikte çok iyi olmayan) tespitiyle bitiriyor. Ancak bu insan benzeri yapının, bilgisayarlarla daha önce hiç kuramadığımız kadar “empatik” ve kusursuz müşteri deneyimleri tasarlamamıza olanak tanıdığını vurguluyor.

77. ⭐ İhtiyacınız Olan Tek Şey Geri Besleme Döngüleri (Tek Atışlayamazsınız), Mehedi Hassan, Granola

Akıllı bir toplantı notları uygulaması olan Granola’nın Ürün Mühendisi Mehedi Hassan, yapay zeka (YZ) özelliklerini geliştirip kullanıcılara sunarken (production) karşılaştıkları zorlukları ve buldukları çözümleri anlatıyor.

Sunumun ana fikri: “Bunu tek atışta halledemezsiniz” (You can’t just one shot it). Yani, bir yapay zekaya basit bir komut verip ürünü piyasaya sürmek yeterli değildir.

Temel Sorunlar: Basit bir YZ sohbet botunu canlıya aldığınızda çeşitli sorunlarla karşılaşırsınız:

• Kontrolsüzlük ve Maliyet: Web aramaları yavaş çalışabilir, karmaşık sorgular “token” maliyetlerini patlatabilir ve dışarıdan alınan hizmetler aniden bozulabilir.
• Bağlam Kopukluğu ve Halüsinasyon: YZ, kullanıcının yazım dilini taklit edemeyebilir veya yanlış bilgiler verebilir (örneğin iş toplantılarını futbol antrenörüyle yapılan toplantılarla karıştırmak).
• Kişiselleştirme Eksikliği: Tek bir komut (prompt) herkesi memnun edemez. Bir satış temsilcisi toplantı notlarında “sonraki adımları” görmek isterken, bir mühendis “engelleyici sorunları (blockers)”, bir İK çalışanı ise tamamen farklı bir şeyi görmek ister.

Granola’nın Çözümleri:

1. “Kara Kutuyu” Şeffaflaştırmak (İzleme, Tracing Araçları): Büyük Dil Modelleri (LLM) genellikle arka planda ne yaptığı bilinmeyen “kara kutular” olarak görülür. Granola ekibi, modelin arka planda attığı her adımı (hangi araçları kullandı, nasıl akıl yürüttü, ne kadar maliyet çıkardı) baştan sona izleyebilecekleri kendi iç sistemlerini kurdu. Bu arayüz sayesinde sadece mühendisler değil, ürün ve müşteri deneyimi ekipleri de bir çıktının neden hatalı olduğunu anında görebiliyor.

2. Test ve Geliştirme Sürecini Hızlandırmak (Web Shell): YZ modelleriyle çalışırken çok fazla farklı varyasyonu test etmek gerekir. Ancak Granola bir masaüstü (Electron) uygulaması olduğu için yeni bir özelliği test etmek (kodu indirmek, bağımlılıkları kurmak, uygulamayı çalıştırmak) çok zahmetliydi. Bunu çözmek için uygulamanın ön yüzünü (frontend) bir “web kabuğuna” (web shell) dönüştürdüler. Artık her kod değişikliğinde (Pull Request) otomatik olarak bir web önizleme linki oluşuyor. Bu sayede yeni YZ özellikleri web tarayıcısı üzerinden anında, paralel olarak ve başkalarıyla paylaşılarak çok hızlı bir şekilde test edilebiliyor.

Başarılı bir yapay zeka ürünü geliştirmek, en baştan “mükemmel komutu” (prompt) yazmakla ilgili değildir. Asıl mesele, hataları görebileceğiniz ve çok hızlı denemeler yapabileceğiniz bir geri bildirim döngüsü (feedback loop) kurmaktır. Bu döngü ne kadar hızlı olursa, ortaya çıkan ürün de kullanıcıya o kadar “sihir” gibi hissettirir.

78. How we solved Context Management in Agents, Sally-Ann Delucia

Arize şirketinde Ürün Yöneticisi (Head of Product) olan SallyAnn’in, “Alyx” adını verdikleri kendi yapay zeka ajanlarını geliştirirken bağlam yönetimi (context management) konusunda edindikleri tecrübeleri ve çıkardıkları dersleri anlattığı bir sunumdur.

Temel Problem: İstem (Prompt) Mühendisliğinden Bağlam (Context) Mühendisliğine Geçiş SallyAnn, günümüzde yapay zeka ajanlarının başarısında “istem (prompt) mühendisliğinden” ziyade “bağlam mühendisliğinin” kritik hale geldiğini vurguluyor. Modelin bağlam penceresine ne kadar token sığdırılacağı değil, modelin stratejik olarak neyi göreceğinin seçilmesi asıl meseledir. Yanlış bağlam sunulması, modelin yanlış cevaplar vermesine neden olur; bu nedenle bağlam yönetimi sadece mühendislik değil, aynı zamanda bir ürün ve UX (kullanıcı deneyimi) problemidir.

Kısır Döngü ve Başarısız Çözümler Alyx’i geliştirirken, analiz edilen verilerin sürekli büyümesi nedeniyle bağlam sınırına takılıp ajanın çökmesine yol açan bir kısır döngüye girdiler. Bu sorunu çözmek için denedikleri bazı ilk yöntemler başarısız oldu:

• Basit Kırpma (Naive Truncation): Sadece metnin ilk kısmını tutup gerisini silmek. Bu yöntem, ajanın eski konuşmaları tamamen unutmasına yol açtı.
• Özetleme (LLM Summarization): Uzun metinleri özetleyerek bağlama koymak. Bu yöntem ise tutarsız, güvenilmez ve önemli bilgilerin kontrol dışında kaybolmasına sebep olduğu için işe yaramadı.

Başarılı Çözümler: Bağlam Penceresinden Kaçış Yolları Ekip, bu sorunları aşmak için üç temel strateji geliştirdi:

1. Akıllı Kırpma ve Bellek (Smart Truncation + Memory): Verinin sadece “başı” (head) ve “sonu” (tail) bağlamda tutuldu. Ortada kalan büyük veri ise silinmek yerine bir veritabanına (belleğe) kaydedildi. Ajan, ihtiyaç duyduğunda kimlik numaraları (ID) aracılığıyla bu belleğe gidip geçmiş bilgileri geri çağırabiliyor. SallyAnn bunu “Bağlam modelin ne göreceğini, bellek ise neyin hayatta kalacağını belirler” şeklinde özetliyor.
2. Alt Ajanlar (Sub-Agents): Tüm bağlamın tek bir ana ajanda toplanmasının yanlış olduğu anlaşıldı. Özellikle büyük veri arama/tarama gibi ağır görevler “alt ajanlara” devredildi. Alt ajan ağır veriyi işleyip sadece sonucu ana sohbete (ana ajana) aktarıyor. Böylece ana sohbetin bağlamı temiz ve kısa kalıyor.
3. Uzun Oturum Değerlendirmeleri (Long Session Evals): Kullanıcılar sohbetleri sıfırlamadığı için bağlam hataları uzun konuşmaların sonlarında ortaya çıkıyordu. Bunu test etmek için 10 konuşma adımını (turn) yapay olarak yükleyip 11. adımı test ettikleri bir değerlendirme sistemi kurdular.

Hala Üzerinde Çalışılan Zorluklar Her ne kadar büyük ilerleme kaydetseler de SallyAnn çözülmesi gereken güncel sorunlara da değindi:

• Çok uzun konuşmalarda ve kullanıcı sekmeler arası geçiş yaptığında gerçek bir uzun vadeli belleğe (long-term memory) hala ihtiyaç var. Şu anki bellek sistemi sadece mevcut sohbetin içindeki bağlamı saklıyor.
• Neyin bağlamda kalıp neyin çıkarılacağına dair kararlar hala “sezgisel” (heuristic) yöntemlerle (başını/sonunu tutmak gibi) yapılıyor. Bunun için daha net ölçümlere (metrics) ve bir “bağlam bütçesi” prensibine ihtiyaç var.

Yani Yapay zeka ajanları kötü istemler (prompts) yüzünden değil, kötü bağlam (context) yüzünden başarısız olurlar. Başarılı bir ajan inşa etmek için bağlam mühendisliğine, bellek yönetimine ve sürekli test etmeye (evaluations) odaklanmak şarttır.

79. Two Roads to Durable Agents: Replay vs. Snapshot, Eric Allam

Trigger.dev kurucu ortaklarından Eric, yapay zeka ajanlarının (AI agents) üretim ortamlarında (production) uzun süreli, karmaşık ve kesintisiz çalışabilmesi için gereken altyapısal değişimi anlatıyor. Sunumun temel odak noktası, ajanların bir hata durumunda çökmeden kaldığı yerden devam edebilmesini (dayanıklılık) sağlamaktır.

Tarihsel Bağlam ve Sorun Eric, web arka uç (backend) mimarilerinin CGI ve PHP günlerinden bu yana yaklaşık 30 yıldır “durumsuz” (stateless) çalıştığını hatırlatıyor. Sistemler arası işlemler (ödeme alma, e-posta atma gibi yan etkiler) karmaşıklaştığında, kodlar bir hatada her şeyi baştan yapmasın diye “yeniden oynatma” (replay) adında bir günlükleme modeli geliştirildi.

Ancak günümüzde yapay zeka ajanları ile durum değişti. Eskiden kodlar LLM’i (Büyük Dil Modelleri) yönetirken, artık LLM’ler kodları yönetiyor. Ajanlar insan etkileşimi için saatlerce veya günlerce bekleyebiliyor ve binlerce işlem adımı (turn) gerçekleştirebiliyor. Bu kadar uzun süren “oturumlar” (sessions) için eski “yeniden oynatma” (replay) metodu, günlüklerin logaritmaik olarak devasa boyutlara ulaşmasına neden olduğu için çöküyor.

Çözüm: İki Parçalı Dayanıklı Ajan Mimarisi Ajanların bekleme sürelerinde sunucu maliyetlerini artırmadan kalıcı olabilmesi için sistemin ikiye bölünmesi gerekiyor:

1. Bağlam Günlüğü (Context Log): Kullanıcı mesajları, araç çağrıları (tool calls) ve sonuçların tutulduğu kayıt defteridir. Bu kısım kolayca veritabanlarında saklanabilir, kod güncellemelerinden etkilenmez ve makine çökse bile ajan hafızasını korur.
2. Yürütme Anlık Görüntüsü (Execution Snapshot): Ajanın arka planda çalıştırdığı kodların, bellek durumunun (memory) ve açık dosyaların tam olarak o anki halidir.

Teknik Zorluklar ve Firecracker Eric, yürütme durumunu “dondurmak” ve “geri yüklemek” için geçmişte CRIU gibi teknolojileri denediklerini ancak konteynerlerle iyi çalışmadığını belirtiyor. Bunun yerine günümüzde Firecracker mikro sanal makinelerini (microVMs) kullanıyorlar.

Firecracker tüm makinenin anlık görüntüsünü alabiliyor. Başlangıçta bu işlem çok fazla bellek (örn. 512 MB) gerektirip sistemi yavaşlatsa da; özel sıkıştırma (seekable zstd) ve ihtiyaç duyuldukça yükleme (lazy restore) teknikleri sayesinde bu boyut 14 MB’a kadar düşürülmüş. Bu sayede dondurulan bir ajan, sadece 17 milisaniye gibi inanılmaz bir hızda tekrar aktif hale (uyanma) gelebiliyor.

Sunum, yapay zeka mühendisliğinin geleceğinin; “Bağlam Günlüğü” ile “Hızlı Anlık Görüntü (Snapshot)” teknolojilerinin birleşiminden geçtiğini vurguluyor. Bu yaklaşım, bizi son 30 yılın durumsuz (stateless) mimarisinden çıkarıp, uzun süre yaşayabilen ve hatalardan kurtulabilen “durumlu” (stateful) bilgi işlem dönemine taşıyor.

81. Viktor: Your Last Hire, Fryderyk Wiatrowski

Bu videoda Viktor adlı girişimin kurucu ortağı Fryderyk, şirketlerin Slack üzerinden çalışan ve tıpkı bir insan gibi iş arkadaşı olarak görev yapan “ilk yapay zeka çalışanı” Viktor’u tanıtıyor.

Şubat 2024'te piyasaya sürülen ve beklentilerin çok ötesinde bir büyüme yakalayan Viktor’un hikayesi, yapay zekanın araçlardan ziyade şirket çalışanlarına dönüşümünü anlatıyor.

Sunumun öne çıkan ana başlıkları şunlardır:

• Viktor Nedir? Klasik web tabanlı yapay zeka asistanlarının (ör. ChatGPT) aksine Viktor’un ayrı bir web arayüzü yoktur; doğrudan Slack kanallarında yaşar. Ekiplerle sohbetlere katılır, mesaj dizilerine (thread) yanıt verir ve 3000'den fazla iş aracına entegre olarak görevleri yerine getirir.
• Geniş Şirket Bağlamı (Context): İnsan çalışanların kendi departmanlarıyla sınırlı bilgisi varken, Viktor tüm şirket genelinde yatay bir bilgiye sahiptir (Örneğin, pazarlama görevlerini yaparken yazılım kod tabanına da erişebilir).
• Gelişim Süreci: Ekip, yapay zeka asistanı vizyonuna 2023'te web tarayıcılarında çalışan jace.ai ile başlamış, ardından bunu otonom bir e-posta asistanına dönüştürmüş ve edindikleri tecrübelerle “şirket çalışanı” modeline (Viktor) geçiş yapmıştır.
• Kişisel Ajan vs. Şirket Ajanı (Ölçeklenme Zorlukları): Tek bir kişiye hizmet eden yapay zeka ile 100 kişilik bir ekibe hizmet eden yapay zeka arasında büyük farklar vardır. Hafızanın hızla tükenmesi, hiyerarşik bilgilerin gizliliği (yönetim kanalındaki bilgilerin yazılım kanalına sızmaması) ve insanların karmaşık iletişim alışkanlıkları (konuyu unutup yeni DM başlatmak vb.) çözülmesi gereken temel zorluklar olmuştur.
• Neden Arayüz Olarak Slack Seçildi? Web uygulamalarında kullanıcılar yapay zekadan anında (30 saniye içinde) yanıt bekler. Ancak Slack’te bir “iş arkadaşından” kod yazmasını isterseniz, bunun 10 dakika sürmesi kullanıcıyı şaşırtır ve etkiler. Slack, beklentileri ve gecikme (latency) toleransını yönetmek için mükemmel bir arayüzdür.
• Kişilik Önemlidir: Viktor’un altyapısında Claude 3 Opus kullanılmıştır. Ekip, daha ucuz ve kodlamada iyi olan GPT-4'e geçmeyi denediğinde kullanıcılar isyan etmiştir. Çünkü Opus’un “hafif ukala/esprili” tarzı, kullanıcıların onu bir robot değil, bir iş arkadaşı olarak benimsemesini sağlamıştır.
• Kazanılması Gereken Proaktiflik: Viktor verileri inceleyip (örneğin A/B testleri) insanlara sormadan proaktif önerilerde bulunabilir. Ancak yeni “işe alınan” bir yapay zekanın ilk günden herkese mesaj atması “gözetleme” hissi yaratır. Bu nedenle yapay zekanın proaktif olmadan önce ekibin güvenini kazanması gerekir.
• Bir Araç Değil, İşe Alım: Konuşmacı, Viktor’a kişisel maillerin değil, yalnızca görmesi istenen şirket araçlarının yetkisinin verilmesi gerektiğini vurguluyor. O bir yazılım aracı değil, dijital bir personeldir.

Fryderyk sunumunu, harika bir iş arkadaşı olmanın üç kuralıyla (işi bitirmek, şirketi iyi tanımak ve dost canlısı olmak) özetliyor ve “Gelecekte şirketlerin yapay zeka araçları değil, yapay zeka çalışanları olacak” vizyonunu vurgulayarak bitiriyor.

82. A Piece of Pi: Embedding The OpenClaw Coding Agent In Your Product , Matthias Luebken

Tavon AI firmasından Matthias, açık kaynaklı ve minimalist bir yapay zeka kodlama ajanı altyapısı olan “PI”ın (aynı zamanda OpenClaw platformunun temelini oluşturur) yazılım ürünlerine nasıl entegre edilebileceğini anlatıyor.

1. Ajanlarda “Deneme Yanılma” Dönemi ve Unix Felsefesi Konuşmacı, yapay zeka kodlama ajanları alanında henüz yerleşik mimari kalıpların (design patterns) olmadığını, şu an “deneme yanılma ve keşfetme” aşamasında olduğumuzu vurguluyor. Ajan sistemleri tasarlarken, Ken Thompson’ın ünlü Unix felsefesi olan “Bir işi yapan ve onu iyi yapan programlar yazın” ilkesinin benimsenmesi gerektiğini savunuyor. Ajanlar için devasa ve karmaşık entegrasyonlar kurmak yerine, ajanların kolayca kullanabileceği küçük, basit komut satırı araçları (CLI) oluşturmak en iyi yaklaşımdır.

2. PI ve Bir Ajanın Temel Mantığı Mario Zechner tarafından geliştirilen PI, geliştiricilerin ajan mantığını anlaması ve denemeler yapması için harika bir açık kaynaklı araçtır. Temel düzeyde bir “ajan” (agent), kendisine verilen hedefe ulaşmak için belirli araçları (tools) bir döngü (loop) içerisinde tekrar tekrar çalıştıran bir Büyük Dil Modelinden (LLM) ibarettir.

3. Örnek Senaryo: CRM Asistanı Matthias, PI kullanarak oluşturduğu terminal tabanlı bir “CRM Müşteri Adayı Değerlendirme” ajanı örneğini gösteriyor. Bu ajan:

• CRM sistemindeki kayıtları okuyabiliyor.
• Puanlama yapabiliyor.
• Önemli bir özellik olarak: Sistemde bir veriyi değiştirmeden (örneğin müşterinin durumunu güncellemeden) önce, olay dinleyicileri (event listeners/hooks) sayesinde araya girip insan onayı isteyebiliyor.
• Sadece terminal metinleriyle değil, web arayüzündeki açılır menülerle de etkileşime girecek şekilde genişletilebiliyor.

4. Gerçek Dünya Uygulaması: Otomatik E-posta Yanıtlama Sistemi Konuşmacı, bir müşterileri için kurdukları çoklu ajan (multi-agent) sistemini anlatıyor:

• Sisteme bir e-posta gelir.
• Bir yönlendirici (gateway), bu e-postayı ilgili müşteriden sorumlu olan ajana iletir.
• Ajan, o müşterinin profili ve kuralları hakkında bilgi sahibi olduğu dosyaları okur.
• Kendi başına şirketin CRM ve ERP sistemlerine (araçlar vasıtasıyla) bağlanarak gerekli sipariş veya stok bilgilerini çeker.
• Gelen e-postaya verilecek yanıtı bir taslak olarak hazırlar.
• Son kullanıcı (satış personeli), arka planda çalışan bu karmaşık yapay zeka sürecini hiç görmez; sadece e-posta kutusuna düşen ve onayını bekleyen taslağı görür.

Kodlama ajanları, gelecekte yazılım sistemlerinin temel yapı taşlarından biri olacaktır. Matthias, geliştiricilere açık kaynaklı PI aracını indirip, ajanların sınırlarını görmek ve kendi uygulamalarına nasıl dahil edebileceklerini keşfetmek için bolca deneme yapmalarını (tinkering) tavsiye ediyor.

83. Intent Engineering: into the Dark Factory , Vincent Koc

Bu konuşmada Comet’ten Vincent Koc, yapay zeka değerlendirmelerinin (evaluations/evals) statik testlerden adaptif sistemlere nasıl evrilmesi gerektiği üzerine kapsamlı bir sunum yapıyor.

1. Statik Testlerin Yetersizliği: Geleneksel yazılım mühendisliğinde kullanılan sabit testler (birim testleri vb.) ve statik yapay zeka benchmarkları (kıyaslama testleri), günümüzün dinamik yapay zeka sistemleri için yetersiz kalmaktadır. Koc, sürekli değişen ve adapte olan yapay zeka ajanlarını, statik bir yazılımmış gibi değerlendirmenin (test etmenin) büyük bir hata olduğunu ve sektörde bu konuda bir “boşluk” (Kaos Mühendisliği eksikliği) olduğunu vurguluyor.

2. Yapay Zekanın Evrimi: Koc, yapay zeka ajanlarının gelişimini üç aşamada özetliyor:

• İstem (Prompt) Mühendisliği (2022–2023): Modelleri yönlendirmek için rastgele kelimelerin deneme-yanılma yoluyla kullanıldığı dönem.
• Bağlam (Context) Mühendisliği (2024–2025): RAG (Geri Getirim Artırımlı Üretim), araç kullanımı (tool calling) ve karmaşık iş akışlarıyla yapay zekanın yönlendirildiği günümüz aşaması.
• Niyet (Intent) Mühendisliği (2026+): Yapay zeka ajanlarının kullanıcının niyetini anlayıp, kendi kendine optimize olabildiği, kullanıcının deneyimine göre kendini değiştirebildiği geleceğin aşaması.

3. “Kireçlenme Problemi” (Calcification Problem): Yapay zeka sistemleri kullanıcılara göre adapte olup değiştikçe, standart ve sabit değerlendirme metrikleri (benchmarklar) işlevsiz hale gelir. Sistem kendi kendine optimize olurken, onu ölçen testlerin sabit kalması mantıksızdır. Koc, statik benchmarklara olan bu aşırı bağlılığı aşılması gereken bir sorun olarak görüyor.

4. Çözüm: Niyet Odaklı ve Adaptif Değerlendirmeler: Koc’a göre “Değerlendirmeler (Evals) öldü” söylemi tam olarak doğru değil; sadece form değiştirmeleri gerekiyor. Geleceğin değerlendirme sistemleri şu özelliklere sahip olmalı:

• Kendi Kendini Düzenleyen Testler (Self-Curating): Sabit veri kümeleri yerine, kullanıcı etkileşimlerinden elde edilen veriler (traces) analiz edilerek, sistemin başarısız olduğu %20'lik uç vakaları (edge cases) bulan ve bunlardan otomatik olarak yeni test senaryoları üreten yapılar kurulmalı.
• Sürekli Değerlendirme (Always-on Evaluation): Testler bir kere yapılıp biten bir şey olmaktan çıkıp, sistem çalışırken arka planda sürekli çalışan ve anormallikleri tespit eden (telemetry in the loop) kapalı bir döngüye dönüşmeli.
• Değerlendirici Olarak Ajanlar: Değerlendirme testleri statik bir veri seti olmaktan çıkmalı; o testler de tıpkı test ettikleri modeller gibi “kendi kendini optimize eden, yaşayan yazılımlar (ajanlar)” haline gelmelidir.

Vincent Koc, yapay zeka geliştiricilerine ve araştırmacılarına seslenerek: değerlendirmeleri sabit bir veri seti olarak görmeyi bırakmalarını, bunun yerine yapay zeka sistemlerini test etmek için yine dinamik, kendini yenileyen ve amaca yönelik (intent-based) yapay zeka ajanları inşa etmelerini tavsiye ediyor.

84. Lessons from Trillion Token Deployments at Fortune 500s, Alessandro Cappelli

Adaptive ML Kurucu Ortağı ve Müşteri İlişkilerinden Sorumlu Başkanı Alessandro Cappelli’nin Kurumsal Yapay Zekayı Ölçeklendirerek Üretime Almak (Deploying Enterprise AI at Scale) üzerine yaptığı bir sunumu içermektedir.

1. “Son Mil” Yanılgısı ve Üretime Alma Problemi: Üretken Yapay Zeka (GenAI) projelerinin %95'i ilk prototip (MVP) aşamasından tam üretime (production) geçemeden başarısız olmaktadır. Çoğu şirket, MVP oluşturmanın işin en zor kısmı olduğunu düşünür; ancak asıl zorluk modeli üretime almak ve orada sürekli olarak iyileştirmektir. Prompt mühendisliği (Prompting) ve Denetimli İnce Ayar (Supervised Fine-Tuning: SFT) gibi mevcut yöntemler, modeli sistematik ve matematiksel olarak sürekli geliştirmek için yetersiz kalmaktadır.

2. Çözüm: Pekiştirmeli Öğrenme (Reinforcement Learning: RL): Cappelli’ye göre, modelleri üretime taşımanın ve sürekli iyileştirmenin anahtarı Pekiştirmeli Öğrenme’dir (RL). RL, SFT’ye kıyasla orantısız bir şekilde daha etkilidir.

• Küçük Modellerle Yüksek Performans: RL, çok daha küçük modeller kullanarak devasa modellerin (örneğin GPT-4) performansına ulaşmayı sağlar.
• Ölçeklenebilirlik ve Maliyet: Küçük modeller kullanmak bulut maliyetlerini ciddi oranda düşürür.
• Hız (Düşük Gecikme): Özellikle sesli asistanlar veya müşteri hizmetleri botları gibi gerçek zamanlı tepki gerektiren sistemlerde küçük modeller çok daha hızlı çalışır.
• Veri Sahipliği: Şirketler açık kaynaklı modelleri kendi verileriyle eğittikleri için veri gizliliği ve sahipliği konusunda tam kontrole sahip olurlar.

3. Yapay Zeka Ajanları (AI Agents) Dönemi: YZ dünyası basit sohbet botlarından, karmaşık görevleri yerine getiren “Ajanlara” doğru kaymaktadır. Ajanlar sistemlerle (veritabanları vb.) doğrudan etkileşime girdiği için hata payları çok düşüktür. RL, yapısı gereği bir “çevre (environment)” içinde deneme-yanılma yoluyla çalıştığı için Ajanları eğitmek için en doğal ve başarılı yöntemdir.

4. Veri Darboğazını Aşmak: Yapay zeka eğitimindeki en büyük sorunlardan biri, yüksek kaliteli eğitim verisi bulmanın zor ve pahalı olmasıdır. RL kullanan ajanlar, tanımlanan hedeflere (ödül mekanizması) ulaşmaya çalışırken kendi sentetik verilerini üretebilirler. Bu da şirketleri sürekli olarak veri etiketleme maliyetinden kurtarır.

5. İnsan Darboğazını (Human-in-the-Loop) Ortadan Kaldırmak: İnsan geri bildirimi çok değerlidir ancak yavaş, pahalı ve ölçeklenmesi zordur. Adaptive ML, insanları sürekli veri etiketlemek yerine sadece kuralları ve değerlendirme kriterlerini belirlemek için kullanmayı önerir. Günlük geri bildirim ve puanlama işlemleri ise iş metrikleri (KPI’lar) veya “Yargıç olarak Büyük Dil Modelleri (LLMs as Judges)” tarafından otomatik olarak yapılır.

6. Adaptive Engine (RLOps Platformu): Pekiştirmeli öğrenmeyi (özellikle PPO gibi algoritmaları) sıfırdan kurmak son derece karmaşıktır. Adaptive ML, şirketlerin Llama, Mistral, Gemma gibi açık kaynaklı modelleri kolayca değerlendirebileceği, RL ile ince ayar (tune) yapabileceği ve üretime alabileceği dünyanın ilk RLOps (Pekiştirmeli Öğrenme Operasyonları) platformu olan “Adaptive Engine”i sunmaktadır.

Sunum, şirketlerin yapay zekayı gerçek iş süreçlerine entegre edebilmeleri için devasa ve pahalı kapalı modellere bağımlı olmak yerine, Pekiştirmeli Öğrenme (RL) ile eğitilmiş, daha küçük, hızlı, ucuz ve hedefe yönelik açık kaynaklı modeller kullanmaları gerektiğini savunmaktadır.

85. Building a Chess CoacAnant Dole and Asbjorn Steinskog, Take Take Take

Bu video, Magnus Carlsen tarafından kurulan “Take Take Take” şirketinde çalışan Anant Dole ve Asbjorn Steinskog’un, uygulamaları için geliştirdikleri Yapay Zeka Destekli Satranç Koçu’nun arkasındaki teknolojiyi anlattıkları bir sunumdur.

Yapay Zeka ve Satranç Geçmişi ile LLM’lerin Zayıflığı

• “Take Take Take”, arkadaşlarınızla satranç oynayabildiğiniz ve oyun sonrasında yapay zeka destekli analizler alabileceğiniz bir mobil uygulamadır.
• Büyük Dil Modelleri (LLM’ler) dil verileri üzerinde eğitildikleri için satranç tahtasındaki hamleleri matematiksel olarak hesaplayamazlar. Bu yüzden kendi başlarına satranç oynamaya veya yorumlamaya çalıştıklarında hızlıca “halüsinasyon” görmeye başlarlar ve mantıksız hamleler önerirler.
• Satranç Koçu Nasıl Çalışıyor? (Teknik Altyapı) Yapay zekanın halüsinasyon görmesini engellemek için doğrudan hamleyi bulması istenmez. Bunun yerine sistem şu aşamalardan geçer:
• İlk olarak oyun, en güçlü ve klasik satranç motoru olan Stockfish üzerinden geçirilir ve pozisyondaki en doğru hamle (çözüm) bulunur.
• Hamlenin neden iyi veya kötü olduğunu açıklayabilmek için pozisyondaki çatal (fork), açmaz (pin) veya zayıf piyon yapıları gibi taktiksel/konumsal temalar özel dedektörlerle analiz edilir.
• Oyuncunun seviyesine (rating) göre bir insanın o hamleyi yapma olasılığını tahmin eden, insan verisiyle eğitilmiş Maia adlı sinir ağı kullanılır. Böylece hamlenin bulunmasının ne kadar zor olduğu tespit edilir.
• Tüm bu yapılandırılmış kesin bilgiler bir LLM’e (Büyük Dil Modeli) verilir. LLM’in buradaki tek görevi, kendisine sunulan bu teknik verileri insanların okuyabileceği doğal bir dil (yorum) haline getirmektir. Bu sayede modelin kendi kendine yanlış bir satranç bilgisi uydurmasının önüne geçilir.

Sürekli Gelişim ve Otonom Ajanlar

• Kullanıcılar uygulamadaki bir maç analizini (yorumu) “kötü” olarak işaretleyip geri bildirim gönderdiğinde, bu durum otomatik olarak bir bildirim sistemine düşer.
• Burada Claude tabanlı otonom bir yapay zeka ajanı devreye girer. Ajan, hatalı yorumu inceler, algılayıcıları (dedektörleri) veya bilgi istemlerini (prompt) günceller, yeni bir yorum üretip test eder ve takımın onaylaması için bir kod değişikliği talebi (Pull Request) oluşturur. Geliştiriciler yoldayken bile telefondan bu onayı verebilir.

Hız ve Kalite Dengesi

• Bu sistem son kullanıcılara yönelik olduğu için maç biter bitmez analizlerin hazır olması gerekir. Bu nedenle yüksek hız sunan Gemini Flash modeli kullanılmıştır. Diğer büyük modeller test edildiğinde daha iyi sonuçlar verseler de süre açısından çok yavaş kalmışlardır.
• Sunumun ana dersi şudur: Eğer yapay zekayı mantık gerektiren (satranç gibi) kapalı bir sistemde kullanacaksanız, veri/matematik hattını dil üretiminden kesinlikle ayırmalısınız.

86. Your Agent Can Now Train Models , Merve Noyan, Hugging Face

Bu video, Hugging Face ekibinden Merve Noyan’ın, yapay zeka ajanlarının artık kendi modellerini eğitebildiği ve Hugging Face ekosistemindeki yeni özellikleri anlattığı sunumunu içermektedir.

Açık Kaynak ve Hugging Face Ekosistemi

• Açık Kaynağın Önemi: Merve Noyan, makine öğrenmesinde açık kaynaklı modellerin gizlilik, güvenlik ve performans kontrolü açısından kritik olduğunu vurguluyor. Açık modellerin artık kapalı modellerle performans açısından yarıştığını belirtiyor.
• Hugging Face Hub: 3 milyona yakın model, veri seti ve “Space” (uygulama) barındıran Hub, artık ajan odaklı modeller için özel filtreler ve karşılaştırma araçları sunuyor.

Yapay Zeka Ajanları İçin Yeni Yetenekler

• Görsel Yetenekler (Vision LMs): Yeni nesil modellerin (Gemma 4, Qwen 2.5 gibi) artık ilk günden görsel işleme yetenekleriyle geldiğini ve ajanların bilgisayar ekranlarını kullanarak işlem yapabildiğini açıklıyor.
• Hugging Face Skills (Beceriler): Ajanlara eklenebilen bu yeni araçlar sayesinde, bir ajana sadece komut vererek bir modeli belirli bir veri setiyle eğitmesini (fine-tune) söyleyebiliyorsunuz. Ajan, gerekli olan VRAM miktarını ve maliyeti hesaplayıp eğitimi başlatabiliyor.
• MCP (Model Context Protocol) Sunucusu: Hugging Face Hub’ı doğrudan dil modellerine bağlayarak modeller, veri setleri ve “Space”ler arasında arama yapma imkanı tanıyor.

Yerel Ajanlar ve Geliştirici Araçları

• Yerel Çalıştırma: Llama.cpp ve Hermes ajanları gibi araçlarla, verilerin dışarı çıkmasına gerek kalmadan yerel cihazlarda güçlü kodlama ajanları kurulabiliyor.
• İzleme (Traces): Ajanların çalışma süreçlerini ve geçmişlerini saklamak için “Traces” adı verilen yeni bir veri seti türü tanıtıldı.

Örnek Uygulama: OCR Projesi

• Sunumun sonunda, Hugging Face araçları kullanılarak 30.000 akademik makalenin nasıl OCR (optik karakter tanıma) sürecinden geçirildiği anlatılıyor. Ajan, en uygun OCR modelini seçiyor, gerekli kodu yazıyor ve eğitimi Hugging Face altyapısında başlatıyor.

87. ⭐CI/CD Is Dead, Agents Need Continuous Compute and Computers , Hugo Santos and Madison Faulkner

CI/CD Neden “Öldü”?

• İnsan Ölçeği vs. Agent Ölçeği: Geleneksel CI/CD sistemleri, haftada birkaç kod değişikliği (PR) yapan insan geliştiriciler için tasarlanmıştır. Ancak yapay zeka agentları, binlerce kısa ömürlü dal (branch) ve PR oluşturabilir. Bu hız, mevcut sistemleri kilitlemektedir.
• İnceleme Darboğazı: Manuel kod incelemeleri (code review), agentların üretim hızı karşısında çok yavaş kalmaktadır. Binlerce PR’ın insan tarafından incelenmesi imkansız hale gelmiştir.

Yeni Yaklaşım: Sürekli Hesaplama (Continuous Compute)

• Döngüsel Geliştirme: Yazılım süreci artık PR odaklı değil, “niyet ve plan” (intent and plan) odaklı bir döngüye dönüşmektedir. Agentlar kodu yazar, kendi iç doğrulamalarını (test/build) yapar ve sürekli bir döngü içinde geliştirir.
• Dış Doğrulama: Gelecekte kod incelemelerini de insanlar değil, güvenlik veya API uyumluluğu konusunda uzmanlaşmış diğer LLM’ler (yapay zeka modelleri) yapacaktır.

İnsanın Değişen Rolü

• İnsan geliştiriciler artık kod satırlarını tek tek incelemek yerine, agentın sunduğu nihai sonucu onaylayan bir konuma geçmektedir. Örneğin; kod yerine, o özelliğin çalıştığını gösteren bir videoyu veya güvenlik raporunu onaylamak yeterli olacaktır.

Altyapı ve Performans İhtiyacı

• Hız Kritik: Build ve test süreçlerinin uzun sürmesi, agent döngüsünü bozar. Bu süreçlerin saniyeler içinde gerçekleşmesi gerekir.
• Stateful (Durumsal) Altyapı: Her seferinde sıfırdan başlamak yerine, hafızası ve durumu (state) olan, yüksek performanslı bir bilgi işlem altyapısı gereklidir.

CI/CD kavramı tamamen yok olmuyor ancak “Sürekli Hesaplama” döngüsünün içine entegre oluyor. Gelecekte yazılım, çok sayıda agentın paralel çalıştığı, insanların ise sadece niyet ve sonuçları yönettiği bir yapıya benzeyecektir.

Kaynaklar

[1] YouTube/AI Engineer, (3 Ara 2025), No Vibes Allowed: Solving Hard Problems in Complex Codebases , Dex Horthy, HumanLayer:

[https://www.youtube.com/watch?v=rmvDxxNubIg&list=PLcfpQ4tk2k0Xq5OF1xbCsMrABt5LnbKuo&index=29]

[2] YouTube/AI Engineer, (3 Ara 2025), Building Cursor Composer — Lee Robinson, Cursor:

[https://www.youtube.com/watch?v=fL1iJHtl51Q&list=PLcfpQ4tk2k0Xq5OF1xbCsMrABt5LnbKuo&index=31]

[3] YouTube/AI Engineer, (8 Ara 2025), Don’t Build Agents, Build Skills Instead — Barry Zhang & Mahesh Murag, Anthropic:

[https://www.youtube.com/watch?v=CEvIs9y1uog&list=PLcfpQ4tk2k0Xq5OF1xbCsMrABt5LnbKuo&index=28]

[4] YouTube/AI Engineer, (12 Ara 2025), Hard Won Lessons from Building Effective AI Coding Agents — Nik Pash, Cline:

[https://www.youtube.com/watch?v=I8fs4omN1no&list=PLcfpQ4tk2k0Xq5OF1xbCsMrABt5LnbKuo&index=25]

[5] YouTube/AI Engineer, (15 Ara 2025), Coding Evals: From Code Snippets to Codebases — Naman Jain, Cursor

[https://www.youtube.com/watch?v=tHN44yJoeS8&list=PLcfpQ4tk2k0Xq5OF1xbCsMrABt5LnbKuo&index=24]

[6] YouTube/AI Engineer, (17 Ara 2025), Code World Model: Building World Models for Computation — Jacob Kahn, FAIR Meta:

[https://www.youtube.com/watch?v=sYgE4ppDFOQ&list=PLcfpQ4tk2k0Xq5OF1xbCsMrABt5LnbKuo&index=23]

[7] YouTube/AI Engineer, (17 Ara 2025), AI Kernel Generation: What’s working, what’s not, what’s next — Natalie Serrino, Gimlet Labs:

[https://www.youtube.com/watch?v=6guQG_tGt0o&list=PLcfpQ4tk2k0Xq5OF1xbCsMrABt5LnbKuo&index=22]

[8] YouTube/AI Engineer, (22 Ara 2025), Making Codebases Agent Ready — Eno Reyes, Factory AI:

[https://www.youtube.com/watch?v=ShuJ_CN6zr4&list=PLcfpQ4tk2k0Xq5OF1xbCsMrABt5LnbKuo&index=19]

[9] YouTube/AI Engineer, (22 Ara 2025), Amp Code: Next Generation AI Coding — Beyang Liu, Amp Code:

[https://www.youtube.com/watch?v=gvIAkmZUEZY&list=PLcfpQ4tk2k0Xq5OF1xbCsMrABt5LnbKuo&index=18]

[10] YouTube/AI Engineer, (24 Ara 2025), Why Agent Hype can fall short of reality — Joel Becker, METR:

[https://www.youtube.com/watch?v=RhfqQKe22ZA&list=PLcfpQ4tk2k0Xq5OF1xbCsMrABt5LnbKuo&index=17]

[11] YouTube/AI Engineer, (27 Ara 2025), How Claude Code Works — Jared Zoneraich, PromptLayer

[https://www.youtube.com/watch?v=RFKCzGlAU6Q&list=PLcfpQ4tk2k0Xq5OF1xbCsMrABt5LnbKuo&index=16]

[12] YouTube/AI Engineer, (8 Oca 2026), Automating Large Scale Refactors with Parallel Agents — Robert Brennan, OpenHands:

[https://www.youtube.com/watch?v=rcsliSIy_YU&list=PLcfpQ4tk2k0Xq5OF1xbCsMrABt5LnbKuo&index=9]

[13] YouTube/AI Engineer, (14 Oca 2026), Identity for AI Agents — Patrick Riley & Carlos Galan, Auth0:

[https://www.youtube.com/watch?v=VSdV-AdSlis&list=PLcfpQ4tk2k0Xq5OF1xbCsMrABt5LnbKuo&index=4]

[14] YouTube/AI Engineer, (19 Oca 2026), How METR measures Long Tasks and Experienced Open Source Dev Productivity — Joel Becker, METR:

[https://www.youtube.com/watch?v=k1t2xyWMUdY&list=PLcfpQ4tk2k0Xq5OF1xbCsMrABt5LnbKuo&index=3]

[15] YouTube/AI Engineer, (19 Nis 2026), Code Mode: Let the Code do the Talking — Sunil Pai, Cloudflare:

[https://www.youtube.com/watch?v=8txf05vVVl4&list=PLcfpQ4tk2k0V3a6nNCVfYxVRfcJ-BNQo7&index=1]

[16] YouTube/AI Engineer, (19 Nis 2026), The Future of MCP — David Soria Parra, Anthropic:

[https://www.youtube.com/watch?v=v3Fr2JR47KA&list=PLcfpQ4tk2k0V3a6nNCVfYxVRfcJ-BNQo7&index=2]

[17] YouTube/AI Engineer, (18 Nis 2026), The Friction is Your Judgment — Armin Ronacher & Cristina Poncela Cubeiro, Earendil:

[https://www.youtube.com/watch?v=_Zcw_sVF6hU&list=PLcfpQ4tk2k0V3a6nNCVfYxVRfcJ-BNQo7&index=4]

[18] YouTube/AI Engineer, (17 Nis 2026), Harness Engineering: How to Build Software When Humans Steer, Agents Execute — Ryan Lopopolo, OpenAI:

[https://www.youtube.com/watch?v=am_oeAoUhew&list=PLcfpQ4tk2k0V3a6nNCVfYxVRfcJ-BNQo7&index=6]

[19] YouTube/AI Engineer, (17 Nis 2026), Building pi in a World of Slop — Mario Zechner:

[https://www.youtube.com/watch?v=RjfbvDXpFls&list=PLcfpQ4tk2k0V3a6nNCVfYxVRfcJ-BNQo7&index=7]

[20] YouTube/AI Engineer, ( 20 Nis 2026), Gemma, DeepMind’s Family of Open Models — Omar Sanseviero, Google DeepMind:

[https://www.youtube.com/watch?v=_gVFUEdhCyI&list=PLcfpQ4tk2k0V3a6nNCVfYxVRfcJ-BNQo7&index=8]

[21] YouTube/AI Engineer, (23 Nis 2026), Software Fundamentals Matter More Than Ever” — Matt Pocock:

[https://www.youtube.com/watch?v=v4F1gFy-hqg&list=PLcfpQ4tk2k0V3a6nNCVfYxVRfcJ-BNQo7&index=9]

[22] YouTube/AI Engineer, (23 Nis 2026), The End of Apps — Kitze, Sizzy.co:

[https://www.youtube.com/watch?v=4fntwuOoedA&list=PLcfpQ4tk2k0V3a6nNCVfYxVRfcJ-BNQo7&index=10]

[23] YouTube/AI Engineer, (21 Nis 2026), How AI is changing Software Engineering: A Conversation with Gergely Orosz, ‪@pragmaticengineer‬:

[https://www.youtube.com/watch?v=CS5Cmz5FssI&list=PLcfpQ4tk2k0V3a6nNCVfYxVRfcJ-BNQo7&index=11]

[24] YouTube/AI Engineer, (20 Nis 2026), The New Application Layer — Malte Ubl, CTO Vercel:

[https://www.youtube.com/watch?v=XKup1pj-34M&list=PLcfpQ4tk2k0V3a6nNCVfYxVRfcJ-BNQo7&index=12]

[25] YouTube/AI Engineer, (21 Nis 2026), Taste & Craft: A Conversation with Tuomas Artman, CTO Linear & Gergely Orosz, ‪@pragmaticengineer‬

[https://www.youtube.com/watch?v=wjk0ulMAkbc&list=PLcfpQ4tk2k0V3a6nNCVfYxVRfcJ-BNQo7&index=13]

[26] YouTube/AI Engineer, (22 Nis 2026), Agents need more than a chat — Jacob Lauritzen, CTO Legora:

[https://www.youtube.com/watch?v=XNtkiQJ49Ps&list=PLcfpQ4tk2k0V3a6nNCVfYxVRfcJ-BNQo7&index=14]

[27] YouTube/AI Engineer, (29 Nis 2026), Andrej Karpathy: From Vibe Coding to Agentic Engineering:

[https://www.youtube.com/watch?v=96jN2OCOfLs]

[28] YouTube/AI Engineer, (30 Nis 2026), Replacing 12K LoC with a 200 LoC Skill — David Gomes, Cursor:

[https://www.youtube.com/watch?v=WE_Gnowy3uw]

[29] YouTube/AI Engineer, (29 Nis 2026), Everything I Learned Training Frontier Small Models — Maxime Labonne, Liquid AI:

[https://www.youtube.com/watch?v=fLUtUkqYHnQ]

[30] YouTube/AI Engineer, (30 Nis 2026), LLM codegen fails and how to stop ’em — Danilo Campos, PostHog:

[https://www.youtube.com/watch?v=juoNbJiZUi0]

[31] YouTube/AI Engineer, (1 May 2026), Agents for Everything Else — swyx:

[https://www.youtube.com/watch?v=zepu8Kk6FBQ]

[32] YouTube/AI Engineer, (28 Nis 2026), Gemma 4 Deep Dive — Cassidy Hardin, Researcher, Google DeepMind:

[https://www.youtube.com/watch?v=_A367W_qvc8]

[33] YouTube/AI Engineer, (28 Nis 2026), Why building eval platforms is hard — Phil Hetzel, Braintrust:

[https://www.youtube.com/watch?v=_fQ7Z_Wfouk]

[34] YouTube/AI Engineer, (28 Nis 2026), Scaling GitHub for your Agents — Sam Morrow, GitHub:

[https://www.youtube.com/watch?v=0n3MKk7r60w]

[35] YouTube/AI Engineer, (26 Nis 2026), Collaborative AI Engineering: One Dev, Two Dozen Agents, Zero Alignment — Maggie Appleton, GitHub:

[https://www.youtube.com/watch?v=ClWD8OEYgp8]

[36] YouTube/AI Engineer, (28 Nis 2026), Gateways are All You Need — Karan Sampath, Anthropic:

[https://www.youtube.com/watch?v=CD6R4Wf3jnY]

[37] YouTube/AI Engineer, (24 Nis 2026), What Do Models Still Suck At? — Peter Gostev, Arena.ai, BullshitBench:

[https://www.youtube.com/watch?v=R7A8rX-09Zw]

[38] YouTube/AI Engineer, (6 May 2026), The Multi-Agent Architecture That Actually Ships — Luke Alvoeiro, Factory:

[https://www.youtube.com/watch?v=ow1we5PzK-o]

[39] YouTube/AI Engineer, (5 May 2026), The Small Model Infrastructure Nobody Built (So We Did) — Filip Makraduli, Superlinked:

[https://www.youtube.com/watch?v=qdh_x-uRs9g]

[40] YouTube/AI Engineer, (3 May 2026), Context Is the New Code — Patrick Debois, Tessl:

[https://www.youtube.com/watch?v=bSG9wUYaHWU]

[41] YouTube/AI Engineer, (3 May 2026), Software Engineering Is Becoming Plan and Review — Louis Knight-Webb, Vibe Kanban:

[https://www.youtube.com/watch?v=W76woOYHlvY]

[42] YouTube/AI Engineer, (20 Ara 2025), The Infinite Software Crisis — Jake Nations, Netflix:

[https://www.youtube.com/watch?v=eIoohUmYpGI&t=370s]

[43] YouTube/AI Engineer, (22 Ara 2025), The 3 Pillars of Autonomy — Michele Catasta, Replit:

[https://www.youtube.com/watch?v=MLhAA9yguwM]

[44] YouTube/AI Engineer, (13 Ara 2025), Proactive Agents — Kath Korevec, Google Labs:

[https://www.youtube.com/watch?v=v3u8xc0zLec&t=1s]

[45] YouTube/AI Engineer, (24 Kas 2025), Vision: Zero Bugs — Johann Schleier-Smith, Temporal:

[https://www.youtube.com/watch?v=qLqttdO33UM]

[46] YouTube/AI Engineer, (24 Kas 2025), Compilers in the Age of LLMs — Yusuf Olokoba, Muna:

[https://www.youtube.com/watch?v=q2nHsJVy4FE]

[47] YouTube/AI Engineer, (24 Kas 2025), Agents are Robots Too: What Self-Driving Taught Me About Building Agents — Jesse Hu, Abundant:

[https://www.youtube.com/watch?v=qqXdLf3wy1E]

[48] YouTube/AI Engineer, (24 Kas 2025), Backlog.md: Terminal Kanban Board for Managing Tasks with AI Agents — Alex Gavrilescu, Funstage:

[https://www.youtube.com/watch?v=zMXKhhwiCIc]

[49] YouTube/AI Engineer, (24 Kas 2025), Developing Taste in Coding Agents: Applied Meta Neuro-Symbolic RL — Ahmad Awais, CommandCode:

[https://www.youtube.com/watch?v=kWOQS3XPZ10]

[50] YouTube/AI Engineer, (24 Kas 2025), From Stateless Nightmares to Durable Agents — Samuel Colvin, Pydantic:

[https://www.youtube.com/watch?v=flf_IKnFYnE]

[51] YouTube/AI Engineer, (24 Kas 2025), What Data from 20m Pull Requests Reveal About AI Transformation — Nick Arcolano, Jellyfish:

[https://www.youtube.com/watch?v=WqZq8L-v9pA]

[52] YouTube/AI Engineer, (24 Kas 2025), AI Copilots for Tech Architecture: The Highest-ROI Use Case You’re Not Building — Boris B., Catio:

[https://www.youtube.com/watch?v=QRWdapxMdSY]

[53] YouTube/AI Engineer, (24 Kas 2025), Infra that fixes itself, thanks to coding agents — Mahmoud Abdelwahab, Railway:

[https://www.youtube.com/watch?v=Q5IVm_CxN2w]

[54] YouTube/AI Engineer, (24 Kas 2025), Hacking Subagents Into Codex CLI — Brian John, Betterup:

[https://www.youtube.com/watch?v=5eJqXtevlXg]

[55] YouTube/AI Engineer, (24 Kas 2025), Context Engineering: Connecting the Dots with Graphs — Stephen Chin, Neo4j

[https://www.youtube.com/watch?v=LLuKshphGOE]

[56] YouTube/AI Engineer, (23 Ağu 2025), Five hard earned lessons about Evals — Ankur Goyal, Braintrust

[https://www.youtube.com/watch?v=a4BV0gGmXgA]

[57] YouTube/AI Engineer, (24 Ağu 2025), Building an Agentic Platform — Ben Kus, CTO Box:

[https://www.youtube.com/watch?v=12v5S1n1eOY]

[58] YouTube/AI Engineer, (8 May 2026), How Transformers Finally Ate Vision — Isaac Robinson, Roboflow:

[https://www.youtube.com/watch?v=VhfAVA3BG2I]

[59] YouTube/AI Engineer, (9 May 2026), Give Your Chat Agent a Voice — Luke Harries, ElevenLabs:

[https://www.youtube.com/watch?v=DCZZ3AJKzuc]

[60] YouTube/AI Engineer, (10 May 2026), Voice AI: when is the “Her” moment? — Neil Zeghidour, Gradium AI:

[https://www.youtube.com/watch?v=P_RI1kCkRbo]

[61] YouTube/AI Engineer, (9 May 2026), Why TTS Models Now Look Like LLMs — Samuel Humeau, Mistral:

[https://www.youtube.com/watch?v=3jGAU2sbAyY]

[62] YouTube/AI Engineer, (6 May 2026), MCP UI: Extending the frontier — Liad Yosef and Ido Salomon, MCP Apps:

[https://www.youtube.com/watch?v=o-zkvb0iFDQ]

[63] YouTube/AI Engineer, (5 May 2026), Accelerating AI on Edge — Chintan Parikh and Weiyi Wang, Google DeepMind:

[https://www.youtube.com/watch?v=Lm8BLHkxiAo]

[64] YouTube/AI Engineer, (3 May 2026), I Gave an AI Agent the Keys to My Life (Here’s What Happened) — Radek Sienkiewicz (@velvetshark-com):

[https://www.youtube.com/watch?v=sJ2jc7leKBk]

[65] YouTube/AI Engineer, (1 May 2026), Mastering AI Pricing — Mayank Pant, Stripe:

[https://www.youtube.com/watch?v=CrqPcIZOOXA]

[66] YouTube/AI Engineer, (1 May 2026), Agents on the Canvas in tldraw — Steve Ruiz, tldraw:

[https://www.youtube.com/watch?v=sPUjIBH5Cwg]

[67] YouTube/AI Engineer, (28 Nis 2026), One Login to Rule Them All: Cross-App Access for MCP — Garrett Galow, WorkOS:

[https://www.youtube.com/watch?v=EmhRyw6xeT0]

[68] YouTube/AI Engineer, (25 Nis 2026), MCP = Mega Context Problem — Matt Carey:

[https://www.youtube.com/watch?v=YBYUvGOuotE]

[69] YouTube/AI Engineer, (16 Nis 2026), $1 AI Guardrails: The Unreasonable Effectiveness of Finetuned ModernBERTs — Diego Carpentero:

[https://www.youtube.com/watch?v=YZHPEkfy2kc]

[70] YouTube/AI Engineer, (13 Ara 2025), Minimax M2: Building the #1 Open Model — Olive Song, MiniMax:

[https://www.youtube.com/watch?v=lY1iFbDPRlw]

[71] YouTube/AI Engineer, (28 Tem 2025), Make your LLM app a Domain Expert: How to Build an Expert System — Christopher Lovejoy, Anterior:

[https://www.youtube.com/watch?v=MRM7oA3JsFs]

[72] YouTube/AI Engineer, (20 Tem 2025), How to Train Your Agent: Building Reliable Agents with RL — Kyle Corbitt, OpenPipe:

[https://www.youtube.com/watch?v=gEDl9C8s_-4]

[73] YouTube/AI Engineer, (28 Mar 2025), AI Engineering at Jane Street — John Crepezzi

[https://www.youtube.com/watch?v=0ML7ZLMdcl4]

[74] YouTube/AI Engineer, (18 Tem 2025), MCP is all you need — Samuel Colvin, Pydantic:

[https://www.youtube.com/watch?v=bmWZk9vTze0]

[75] YouTube/AI Engineer, (21 Nis 2025), Self Coding Agents — Colin Flaherty, Augment Code:

[76] YouTube/AI Engineer, (11 Nis 2025), You can’t just one shot it — Mehedi Hassan, Granola

[https://www.youtube.com/watch?v=ON5LIT0M4do]

[77] YouTube/AI Engineer, (22 Tem 2025), Practical GraphRAG: Making LLMs smarter with Knowledge Graphs — Michael, Jesus, and Stephen, Neo4j:

[https://www.youtube.com/watch?v=XNneh6-eyPg]

[78] YouTube/AI Engineer, (11 Nis 2025), The Agent Development Life Cycle — Zack Reneau-Wedeen, Sierra:

[https://www.youtube.com/watch?v=0vBKv9yAQi4]

[79] YouTube/AI Engineer,(10 May 2026), How we solved Context Management in Agents — Sally-Ann Delucia

[https://www.youtube.com/watch?v=esY99nYXxR4]

[80] YouTube/AI Engineer, (10 May 2026), Two Roads to Durable Agents: Replay vs. Snapshot — Eric Allam, CEO, Trigger.dev

[https://www.youtube.com/watch?v=svCnShDvgQg]

[81] YouTube/AI Engineer, (11 May 2026), Viktor: Your Last Hire — Fryderyk Wiatrowski:

[https://www.youtube.com/watch?v=ohKt066uFhg]

[82] YouTube/AI Engineer,(11 May 2026), A Piece of Pi: Embedding The OpenClaw Coding Agent In Your Product — Matthias Luebken, Tavon

[https://www.youtube.com/watch?v=vAIDdLKB6-w]

[83] YouTube/AI Engineer,(13 May 2026), Intent Engineering: into the Dark Factory — Vincent Koc

[https://www.youtube.com/watch?v=4VhbYlfC7Gs]

[84] YouTube/AI Engineer,(13 May 2026), Lessons from Trillion Token Deployments at Fortune 500s — Alessandro Cappelli, Adaptive ML

[https://www.youtube.com/watch?v=X6NShR2ccOg]

[85] YouTube/AI Engineer, (14 May 2026), Building a Chess Coach — Anant Dole and Asbjorn Steinskog, Take Take Take

[https://www.youtube.com/watch?v=FlzpEGHNVKQ]

[86] YouTube/AI Engineer, (14 May 2026) Your Agent Can Now Train Models — Merve Noyan, Hugging Face

[https://www.youtube.com/watch?v=OV56RddyFuU]

[87] YouTube/AI Engineer, (14 May 2026), CI/CD Is Dead, Agents Need Continuous Compute and Computers — Hugo Santos and Madison Faulkner

[https://www.youtube.com/watch?v=VktrqzQgytY]