- Yapay zekayı basit bir araç değil, temel bir teknoloji olarak ele alan bir geliştirme kültürü oluşuyor
- Mevcut sürüm yönetimi, dashboard, şablon, dokümantasyon ve secret yönetimi yaklaşımları yapay zeka çağına uyum sağlayacak şekilde değişiyor
- Git, artık koddaki satır bazlı değişikliklerden çok prompt ve test sonuçları merkezli bir durum yönetimi yaklaşımı olarak yeniden yorumlanıyor
- Agent'lar hem kod yazarı hem de kod tüketicisi haline gelirken, araçların kendisini yeniden tasarlama ihtiyacı artıyor
- Dashboard'lar ve UI'lar doğal dil tabanlı arayüzlere dönüşüyor; insanlarla yapay zeka agent'larının birlikte kullandığı bir yapıya evriliyor
- Dokümantasyon, hem insanlar hem de yapay zeka için bir bilgi tabanına dönüşüyor ve agent'ların anlayabileceği biçimlerde yeniden yapılandırılıyor
1. AI-Native Git: Yapay zeka agent'ları için sürüm yönetiminin yeniden tanımlanması
- Git başlangıçta, insanların doğrudan yazdığı koddaki satır düzeyindeki değişiklik geçmişini izlemek için tasarlandı
- Ancak yapay zekanın kodun büyük bölümünü otomatik olarak üretip değiştirdiği bir ortamda, bu tür ince ayrıntılı takip daha az önemli hale geliyor
- Geliştiriciler artık değişikliğin kendisinden çok ortaya çıkan davranışın uygunluğuna (testlerin geçmesi, düzgün çalışması vb.) odaklanıyor
- SHA, bir değişiklik olduğunu gösterir ama neden değiştiği ya da değişikliğin geçerli olup olmadığı hakkında bilgi vermez
- Özellikle büyük çaplı değişikliklerde veya otomatik üretilmiş kodda, geliştiriciler diff'i tek tek incelemiyor
- AI-first workflow içinde, aşağıdaki unsurların birleşimi daha faydalı bir birim haline geliyor
- Prompt: kod üretimini yönlendiren girdi
- Test: beklenen davranışı doğrulayan test
- Spec ve constraints gibi tasarımsal gereksinimler
- Bunların tamamı, tek bir versionable bundle olarak kabul edilip yönetiliyor ve izleniyor
- Bu yaklaşım bir adım daha ileri götürüldüğünde, Agent-Driven workflow'da Source of Truth; prompt'lara, veri şemalarına, API contract'larına ve mimari intent'e doğru upstream kayabilir
- Sonuç olarak kod, derlenmiş bir çıktı gibi görülür ve kaynak değil, bu girdilerin bir yan ürünü olarak ele alınır
- Git, bir kod çalışma alanı olmaktan çok artifact log gibi çalışır
- Kimin, hangi modelle, hangi prompt'u kullanarak kod ürettiği
- Hangi testlerin geçtiği
- Hangi bölümlerin insan incelemesi gerektirdiği gibi metadata bilgilerini birlikte saklar
- Değişiklik geçmişine prompt, amaç, ilgili testler ve üretimi yapan model bilgisi gibi unsurlar da dahil edilir
- Diamond gibi AI reviewer araçlarıyla entegrasyon sayesinde otomatik review akışları mümkün olabilir
- Agent'ların ürettiği kod ile insanların yönettiği korumalı alanları ayırabilen yapılar gibi daha zengin metadata katmanları oluşturulabilir
- AI-Native Git workflow'su düşünüldüğünde
- Prompt'lar ve bunlara dayalı değişim akışı, test sonuçları, çalışan agent bilgileri ve bundle bilgilerinin birlikte görüldüğü yeni bir Git dashboard biçimi ortaya çıkabilir
2. Dashboard'lar → Synthesis: dinamik yapay zeka tabanlı arayüzlere evrim
- Yıllardır dashboard'lar; gözlemlenebilirlik sistemleri, analiz araçları ve bulut konsolları (AWS gibi) gibi karmaşık sistemlerle etkileşim kurmanın temel arayüzü oldu
- Ancak aşırı sayıda kontrol öğesi, grafik ve sekme nedeniyle UX yükü oluştu; kullanıcıların bilgi keşfi ile aksiyon alma arasında kaybolması kolaylaştı
- Özellikle uzman olmayan kullanıcıların veya birden fazla ekibin birlikte çalıştığı ortamlarda, bu dashboard'lar göz korkutucu ve verimsiz araçlar olarak algılanabiliyor
- Kullanıcılar neye ulaşmak istediklerini biliyor ama nerede aramaları gerektiğini veya hangi filtreleri uygulayacaklarını çoğu zaman bilmiyor
- Yeni nesil yapay zeka modelleri bu sorunu çözme potansiyeli sunuyor
- Dashboard'ları sabit bir tuval değil, keşfedilebilir ve etkileşimli bir alan olarak yeniden yorumlamayı mümkün kılıyor
- LLM'ler kullanıcıları şu şekillerde destekleyebilir:
- “Bu API'nin rate limit ayarını nereden değiştiririm?” gibi kontrol konumunu bulma
- “Son 24 saatte staging ortamındaki tüm servislerde görülen hata trendini özetle” gibi veri birleştirme ve özetleme
- “İş durumuma göre bu çeyrekte dikkat etmem gereken metrikleri öner” gibi gizli içgörü önerileri
- Hâlihazırda Assistant UI gibi teknolojiler, agent'ların React bileşenlerini birer araç gibi kullanmasını destekliyor
- İçerik nasıl dinamik ve kişiselleştirilmiş hale geldiyse, UI da kullanıcı niyetine göre yeniden şekilleniyor ve konuşmalı biçimde evriliyor
- Statik dashboard'lar yakında demode olarak görülebilir
- Örnekler:
- Kullanıcı “Geçen hafta sonu Avrupa'da yaşanan anormallikleri göster” dediğinde, filtreleri elle değiştirmeden özet log'lar ve trendler otomatik olarak sunulabilir
- “Geçen hafta NPS puanı neden düştü?” sorusuna karşılık yapay zeka; anket duygu analizi, ürün dağıtımlarıyla korelasyon analizi ve tanısal bir özet sunabilir
- Daha geniş açıdan bakıldığında, agent'lar yazılımın tüketicisi haline gelirse 'dashboard' kavramının kendisinin de yeniden tasarlanması gerekir
- Örneğin dashboard'lar, Agent Experience için optimize edilmiş görünümler render edebilir
- Sistem durumunu algılayıp karar verebilmeleri ve eyleme geçebilmeleri için yapılandırılmış, programatik olarak erişilebilir arayüzler sunabilir
- Bunun sonucunda insan kullanıcı UI'ı ile agent UI'ının birlikte var olduğu ikili bir arayüz yapısı ortaya çıkabilir
- Her iki UI aynı durumu paylaşır, ancak tüketim biçimine göre farklı şekilde yapılandırılır
- Agent'lar mevcut uyarı, cron job ve koşul tabanlı otomasyonların rolünü üstlenirken, çok daha fazla bağlam ve esneklik taşıyan uygulayıcılar haline gelir
- Örnek:
- Mevcut:
if error rate > threshold then send alert
- Agent tabanlı: “Hata oranı yükseliyor. Sebep bu servis; etkilenen bileşenler ve önerilen aksiyonlar şunlardır”
- Böylece dashboard'lar yalnızca gözlem yapılan yerler değil, insanlarla yapay zekanın birlikte çalıştığı, sentez yaptığı ve eylem gerçekleştirdiği alanlar olarak yeniden tanımlanır
3. Dokümanlar; araç, indeks ve interaktif bilgi tabanı birleşimine evriliyor
- Geliştiricilerin doküman kullanım biçimi değişiyor
- Eskiden içindekiler tablosunu takip ederek veya spec'i baştan sona okuyarak ilerlenirdi; artık ise "önce soru sorma" yaklaşımı yaygınlaşıyor
- “Bu spec'i çalışayım” yerine, “Bilgiyi benim istediğim şekilde yeniden düzenle” düşüncesi öne çıkıyor
- Bu değişim dokümanın biçimini de etkiliyor; statik HTML ya da Markdown yerine, indeksler, embedding'ler ve tool-aware agent'larla desteklenen interaktif bilgi sistemlerine dönüşüm yaşanıyor
- Buna bağlı olarak Mintlify gibi araçlar ortaya çıkıyor
- Mintlify, dokümanları yalnızca anlam temelli aranabilir bir veritabanı olarak düzenlemekle kalmıyor; aynı zamanda çeşitli platformlarda agent'lar için bağlam kaynağı olarak kullanılıyor
- Örneğin AI IDE, VS Code eklentileri ve terminal agent'larında Mintlify dokümanları gerçek zamanlı referans materyali olarak kullanılıyor
- Bunun nedeni, kod üreten agent'ların güncel dokümanları öğrenme tabanlı bağlam olarak kullanması
- Bu nedenle dokümanın amacı da kökten değişiyor
- Dokümanlar artık yalnızca insan okuyucuya bilgi aktarmak için değil, agent tüketicileri için yapılandırılmış bir kaynak olarak tasarlanmalı
- Bu yeni dinamikte dokümanlar, yapay zeka agent'ları için bir kullanım kılavuzu işlevi görüyor
- Bu, yalnızca içerik sunmak değil; bir sistemin nasıl doğru şekilde kullanılacağını açıklayan bir biçim anlamına geliyor
4. Şablondan üretime: create-react-app'in yerini alan vibe coding
- Geçmişte bir projeye başlamak için
create-react-app, next init, rails new gibi statik şablonlardan birini seçmek yaygındı
- Bu şablonlar tutarlı bir uygulama yapısı sunsa da, geliştiricinin niyetine veya yığınına göre özelleştirmek zordu ve çerçevenin varsayılanlarına uyulması gerekiyordu
- Sonuç olarak, varsayılan ayarların dışına çıkmak için çok fazla manuel refaktöring gerekiyordu
- Artık bu akış, Replit, Same.dev, Loveable, Chef by Convex, Bolt gibi text-to-app platformlarının ve Cursor gibi yapay zeka IDE'lerinin ortaya çıkmasıyla değişiyor
- Geliştirici örneğin “Supabase, Clerk, Stripe içeren bir TypeScript API sunucusu” diye tarif ettiğinde, yapay zeka birkaç saniye içinde otomatik olarak özelleştirilmiş bir proje kurabiliyor
- Ortaya çıkan başlangıç yapısı, genel bir şablon değil; geliştiricinin niyetine ve kullandığı yığına optimize edilmiş bir yapı oluyor
- Bu değişim, ekosistemin dağıtım yapısını da dönüştürüyor
- Eskisi gibi birkaç çerçevenin ekosistemin merkezini kaplaması yerine, çeşitli araç ve mimarilerin bir araya geldiği özelleştirilmiş üretim akışları yaygınlaşıyor
- Artık kilit nokta, hangi framework'ü seçeceğinden çok “ne yapmak istediğini” anlatmak
- Bir geliştirici Next.js ve tRPC kombinasyonunu, bir başkası Vite ve React'i seçse de, her biri için doğrudan çalıştırılabilir proje üretilebiliyor
- Elbette standart yığınların da avantajları var:
- Ekip üretkenliğinin artması, onboarding verimliliği, hata ayıklama kolaylığı gibi
- Ancak framework'ler arası refaktöring yalnızca teknik bir mesele değil; ürün, altyapı ve organizasyonel yetkinliklerle de iç içe
- Kırılma noktası ise framework değiştirme maliyetinin düşmüş olması
- Yapay zeka ajanları projenin niyetini anlayıp büyük ölçekli refaktöringi yarı otomatik şekilde gerçekleştirebiliyor
- Bu da deney yapmayı kolaylaştırıyor ve erken aşamada farklı yığınları deneme ya da geri alma esnekliği sağlıyor
- Sonuç olarak, framework seçimi geri alınabilir (decision reversible) hale geliyor
- Örneğin: Next.js ile başlayıp sonra Remix + Vite'a geçmek ve tüm refaktöringin ajan tarafından yapılması
- Framework lock-in azalırken, güçlü görüşlere sahip (opinionated) yığınlar da rahatça denenebilir
5. .env'nin ötesi: ajan merkezli ortamlarda secret yönetimi
- On yıllardır
.env dosyaları; API anahtarları, veritabanı URL'leri ve servis token'ları gibi secret'ları yerelde basitçe yönetmenin temel yolu oldu
- Bu yöntem basit, taşınabilir ve geliştirici dostu olsa da, yapay zeka IDE'lerinin veya ajanların kod yazdığı, servis dağıttığı ve ortamları koordine ettiği durumlarda sorun yaratıyor
- Yani .env dosyasının gerçek sahibinin kim olduğu belirsizleşiyor
- Bu sorunu çözmeye yönelik yeni bir akım ortaya çıkıyor
- Örneğin, en güncel MCP spesifikasyonu OAuth 2.1 tabanlı bir kimlik doğrulama çerçevesi içeriyor
- Bu yapı, yapay zeka ajanlarına ham secret'lar yerine kapsamı sınırlı token'lar (scope-based, revocable tokens) verme yönünde bir işaret sunuyor
- Örneğin ajan, tüm AWS anahtarlarını almak yerine yalnızca “S3'e dosya yükleme” gibi sınırlı bir eyleme izin veren kısa süreli kimlik bilgileri (credential) alıyor
- Bir başka eğilim de yerel secret broker'ların ortaya çıkması
- Bunlar yerelde veya uygulamanın yanında çalışarak, ajanlar ile hassas secret'lar arasında aracılık eden servisler görevi görüyor
- Ajan,
.env dosyasına doğrudan erişmek veya secret'ları hardcode etmek yerine, belirli bir iş talep ettiğinde broker bunu gerçek zamanlı değerlendirip yetki veriyor
- Örneğin: “Staging'e deploy et” veya “Logları Sentry'ye gönder” talebi
- Broker bunları just-in-time yaklaşımıyla işler ve tüm erişimler denetlenebilir bir kayıt izi bırakır
- Bu yaklaşım, secret erişimini dosya sistemi yerine API tabanlı bir yetki modeline taşıyor
- Sonuç olarak, secret yönetimi
.env yapılandırmasından OAuth tabanlı yetki kontrolü mimarisine evriliyor
6. Erişilebilirliğin evrensel arayüze dönüşmesi: LLM'lerin gözünden uygulamalar
- Son dönemde Granola ve Highlight gibi uygulamalar macOS erişilebilirlik izinleri istiyor; ancak bunun amacı geleneksel engelli desteği değil, yapay zeka ajanlarının arayüzü gözlemleyip onunla etkileşime girebilmesi
- Bu, geçici bir hack değil; daha köklü bir arayüz dönüşümünün habercisi olarak görülebilir
- Erişilebilirlik API'leri aslında görme veya hareket engeli olan kullanıcılar için dijital erişilebilirliği artırmak amacıyla geliştirildi
- Ancak bu API'ler genişletildiğinde, yapay zeka ajanları için evrensel bir arayüz katmanı işlevi görebilir
- Piksel konumuna tıklamak veya DOM scraping yapmak yerine, yardımcı teknolojilerin arayüzü yorumlaması gibi, uygulamalar anlamsal (semantic) düzeyde gözlemlenip işletilebilir
- Erişilebilirlik ağaçları zaten düğmeler, başlıklar, giriş alanları gibi yapılandırılmış arayüz öğelerini açığa çıkarıyor
- Buna intent, role ve affordance gibi metadata'lar eklenirse, ajanlar amaç ve bağlama göre çok daha hassas şekilde işlem yapabilir
- Bu yönelim şu tür yeteneklere doğru genişleyebilir:
- Context extraction: erişilebilirlik/semantic API'leri üzerinden ekranda görünen öğeleri, etkileşime açık unsurları ve kullanıcının mevcut eylemini sorgulama
- Intentful execution: birden fazla API çağrısını elle zincirlemek yerine, “Sepete ürün ekle ve en hızlı teslimatı seç” gibi yüksek seviyeli bir hedef tanımlayıp arka uçta yürütme adımlarının oluşturulması
- Fallback UI for LLMs: erişilebilirlik özellikleri, genel kullanıma açık API'si olmayan uygulamaların bile ajanlar tarafından kullanılabilmesini sağlayan bir yedek arayüz sunar
- Geliştiriciler, görsel arayüz veya DOM'a ek olarak, ajanların algılayabileceği bir render surface'i structured annotation'lar veya erişilebilirlik odaklı bileşenlerle tanımlayabilir
- Kısacası, erişilebilirlik API'leri artık yalnızca insanlar için değil, yapay zeka ve sistemlerin etkileşimi için de temel bir arayüz katmanı haline geliyor
7. Asenkron ajan işlerinin yükselişi
- Geliştiriciler kod yazma ajanlarıyla doğal biçimde iş birliği yapmaya başladıkça, asenkron iş akışlarına geçiş hızlanıyor
- Ajanlar arka planda paralel işler yürütüyor ve belli bir seviyeye geldiklerinde sonucu raporluyor
- Bu etkileşimler giderek pair programming'den çok görev orkestrasyonuna (task orchestration) benzemeye başlıyor
- Yani geliştirici hedefi iletiyor, ajan işi yapıyor ve daha sonra kontrol ediliyor
- Önemli nokta, bunun yalnızca işi hafifletmesi değil, iş birliğinin kendisini sıkıştırması
- Örneğin başka bir ekipten yapılandırma dosyası güncellemesi, hata triyajı veya bileşen refaktörü istemek yerine,
geliştirici niyetini doğrudan ajana aktarabilir ve bunu arka planda işlemesini söyleyebilir
- Eskiden senkron toplantılar, departmanlar arası handoff'lar ve uzun inceleme döngüleri gerekirdi,
artık ise istek → üret → doğrula (request → generate → validate) döngüsü doğal biçimde gerçekleşiyor
- Ajanlarla etkileşim kurma biçimleri de genişliyor
- Yalnızca IDE veya CLI içinde prompt girmekle sınırlı kalmadan, şu yöntemler de mümkün:
- Slack mesajıyla iş istemek
- Figma mockup'ına yorum yazmak
- Kod diff'ine veya PR'a satır içi yorum eklemek (ör. Graphite review assistant)
- Yayınlanmış uygulama önizlemesine geri bildirim eklemek
- Sesli veya arama tabanlı arayüzler üzerinden değişiklikleri sözlü olarak anlatmak
- Bu değişim, ajanların geliştirme yaşam döngüsünün tamamında yer almasını sağlıyor
- Yalnızca kod yazmakla kalmayıp tasarım yorumlama, geri bildirim uygulama ve platform genelinde hata triyajı da yapıyorlar
- Geliştirici, hangi iş parçacıklarının ilerletileceğine, dışarıda bırakılacağına veya birleştirileceğine karar veren bir orkestratör (orchestrator) rolünü üstleniyor
- Bu akış, nihayetinde ajan tabanlı iş parçacıklarının yeni bir “Git branch” kavramı haline gelebileceğine işaret ediyor
- Artık statik kod fork'ları yerine, amaç odaklı dinamik iş parçacıkları asenkron olarak çalışıp tamamlandıklarında entegre ediliyor
8. MCP: Evrensel standarda bir adım daha yaklaşan Model Context Protocol
- Kısa süre önce MCP üzerine derinlemesine analiz yazısı yayımlandıktan sonra, MCP benimsenme hızı ivme kazandı
- OpenAI resmî olarak MCP'yi benimsedi, çeşitli yeni özellikler spesifikasyona birleştirildi ve
giderek daha fazla araç geliştiricisi MCP'yi ajanlar ile gerçek dünya arasındaki temel arayüz olarak kabul ediyor
- MCP özünde iki önemli sorunu çözüyor:
- LLM'lerin ilk kez karşılaştıkları görevleri de yerine getirebilmeleri için gerekli bağlamı sağlamak
- N×M tipi özel entegrasyonları ortadan kaldırıp, araçların standart bir arayüz (sunucu) sunması ve tüm ajanların (istemcilerin) bunu kullanabilmesiyle yapıyı sadeleştirmek
- İleride MCP benimsenmesinin daha da artması bekleniyor ve
uzak MCP ile fiilî bir MCP kayıt dizini (de-facto registry) ortaya çıkarsa,
birçok uygulama varsayılan olarak MCP arayüzü yerleşik halde piyasaya çıkabilir
- Geçmişte API'ler SaaS araçlarını birbirine bağlayıp iş akışları kurmayı mümkün kıldığı gibi,
MCP de yapay zeka ajanları için birlikte çalışabilir bileşenlerden oluşan bir ekosistem yaratabilir
- MCP istemcisi yerleşik platformlar artık yalnızca “AI destekli” olmakla kalmaz,
ajanların erişebildiği bir yetenek ağına doğrudan bağlanabilen bir ekosistemin parçası haline gelir
- MCP'nin istemci ve sunucuları yalnızca mantıksal kavramlardır; fiziksel olarak ayrılmış değillerdir
- Bu, herhangi bir MCP istemcisinin sunucu da olabileceği, tersinin de mümkün olduğu anlamına gelir
- Bu sayede şu tür yüksek düzeyde birleştirilebilirlik (composability) mümkün olur:
- Örn: Bir kodlama ajanı, istemci olarak GitHub issue'larını alırken aynı anda sunucu olarak başka bir ajana test coverage veya kod analizi sonuçları sağlayabilir
- MCP, araçlar ile ajanların organik şekilde etkileşime girdiği bir ekosistem için temel arayüz katmanı olarak konumlanıyor
9. Soyutlanmış primitive'ler: Her yapay zeka ajanının ihtiyaç duyduğu kimlik doğrulama, ödeme ve depolama
- Vibe coding ajanları giderek güçlendikçe daha da netleşen gerçek şu:
ajanlar çok miktarda kod üretebilir, ancak bu kodun bağlanacağı güvenilir bir temele ihtiyaç vardır
- İnsan geliştiriciler ödemede Stripe'a, kimlik doğrulamada Clerk'e ve veritabanında Supabase'e güvendiği gibi,
ajanların da güvenilir ve birleştirilebilir servis primitive'lerine ihtiyacı vardır
- Bu servisler net API sınırları, kullanımı kolay SDK'lar ve makul varsayılan ayarlar sunar;
giderek daha fazla biçimde ajanların runtime arayüzü rolünü üstlenirler
- Örneğin SaaS uygulamaları üreten bir araç yapılırken, ajan doğrudan kimlik doğrulama sistemi veya ödeme mantığı kurmak yerine,
Clerk ve Stripe kullanarak hızlı ve güvenli şekilde entegre olabilir
- Bu kalıp olgunlaştıkça servisler yalnızca API sunmanın ötesine geçip şunları da açığa çıkarabilir:
- Şema (schema): yapılandırılmış veri tanımları
- Yetenek metadatası (capability metadata): yapılabilecek işlerin tanımı
- Örnek akışlar (example flows): nasıl entegre edileceğine dair örnekler
→ Böylece ajanlar entegrasyonu daha güvenilir şekilde gerçekleştirebilir
- Hatta bazı servisler yerleşik bir MCP sunucusuyla birlikte piyasaya çıkabilir
- Örn: Clerk, MCP sunucusu üzerinden kullanılabilir ürün listesini görüntüleme, yeni fiyat planı oluşturma, abonelik düzenleme gibi yetenekleri açığa çıkarabilir
- Ajanlar API spesifikasyonu ya da doküman aramak yerine doğal dille istekte bulunur,
MCP sunucusu da yetki kapsamı ve kısıtlar içinde isteği doğrulayıp işler
- Örn:
> “Aylık 49 dolarlık bir Pro planı oluştur ve kullanıma dayalı ek ücretlendirme ayarla”
→ Clerk'in MCP sunucusu bu isteği yorumlayıp yürütür
- Web'in ilk dönemlerinde
rails new nasıl hızlı geliştirmeyi mümkün kıldıysa,
ajan çağında da güvenilir primitive'lere (drop-in identity, ödeme, erişim kontrolü vb.) ihtiyaç var
- Bunlar, ajanların üretim amacıyla kullanabileceği kadar soyutlanmış olmalı,
aynı zamanda uygulama büyüdükçe ölçeklenebilen bir yapıya sahip olmalıdır
Sonuç
- Bu 9 kalıp, yalnızca mevcut geliştirme biçimlerinin üzerine AI eklenmediğini; yazılım üretme biçiminin ajan, bağlam ve niyet merkezli olarak baştan tanımlandığını gösteriyor
- Buna bağlı olarak geleneksel geliştirici davranış kalıpları da değişiyor ve bunu destekleyen yeni toolchain'ler ile protokoller (MCP vb.) hızla ortaya çıkıyor
- Git, şablonlar, dashboard'lar ve dokümantasyon yöntemleri gibi mevcut temel araç katmanları AI ile birlikte kökten yeniden tasarlanıyor
- Bu geçiş döneminde, yeni geliştirici ekosistemini oluşturacak yeni nesil araçlar ve altyapılara yönelik inşa ve yatırım faaliyetlerinin hızlanması bekleniyor
8 yorum
Gerçekten 1 numarayı yapan biri var mı..?
LLM'ler aynı girdiye karşı aynı çıktıyı garanti etmiyor; böyle bir yaklaşımda konfigürasyon yönetiminin gerçekten işe yarayabildiği mi söyleniyor...
Yoksa ben hâlâ onu fazla tek boyutlu mu kullanıyorum
temperatureseçeneğini 0 olarak ayarlarsanız, aynı girdi için aynı çıktının garanti edildiğini biliyorum.Nasıl olsa birkaç ay sonra modelin kendisi yine değişeceği için bunun bir anlamı yok, değil mi?
Bunu bir kenara bıraksak bile, insan müdahalesini hiç hesaba katmaması fazla kesin bir yaklaşım gibi görünüyor,
Basit sayısal ya da mesaj düzeltmelerinde LLM yerine insanın devreye girmesi daha verimli olur.
Derin içgörüler hissettiren bir yazı. Yine a16z kalitesi.
https://tr.news.hada.io/topic?id=21091
Bunu okuyup sonra bunu okuyunca, gerçekten bu mu doğru diye düşündüm.