1. Problem: token faturası büyüdü, muhasebe yetişemedi
2025 boyunca AI ürünlerinin çoğu, özellikle coding agent tarafında, iki şeyle satıldı: daha fazla model erişimi ve daha fazla kullanım. Kurum içindeki doğal soru da buna göre şekillendi: ekipler bu araçları yeterince kullanıyor mu? Token tüketimi, agent saatleri, oluşturulan satır sayısı, açılan PR sayısı, çağrı hacmi, hepsi birer hareket göstergesiydi. Ama hareket ile ilerleme aynı şey değil.
Cognition'ın 4 Haziran 2026'da paylaştığı duyuru bu yüzden önemli. Ana tweet, Devin'in ödenen tutardan daha az mühendislik değeri üretmesi halinde Cognition'ın kullanımı fonlayacağını, bunun üst sınırının 10 milyon dolar olduğunu söylüyordu. Kısa alıntıyla, şirket AI endüstrisinin productive output
tarafına dönmesi gerektiğini ilan etti.1
Bu, basit bir indirim kampanyası değil. Çünkü "ücret iadesi" gibi görünen şeyin arkasında daha sert bir soru var: Bir AI agent'ın gerçek mühendislik değerini, tek tek oturumlar üzerinden nasıl ölçersin? Kullanıcıya bir dashboard gösterdiğinde oradaki saat, dolar veya değer iddiası neye dayanır? Ve daha önemlisi, vendor bu ölçümü kendi bilançosuna bağlayacak kadar güvenebilir mi?
not every token delivers real value
. Bu cümle, yazının neredeyse tamamının omurgası.
measuring activity to measuring output
. Yani mesele kullanım değil, çıktı muhasebesi.
Benim okumam şu: AI ürünlerinde ilk dalga, model kapasitesini satın almaktı. İkinci dalga, bu kapasiteyi iş akışına gömmekti. Üçüncü dalga ise kapasiteyi ölçülebilir sorumluluğa çevirmek olacak. Cognition'ın guarantee modeli tam bu üçüncü dalganın erken ama ciddi bir örneği.
2. Garanti modeli ne diyor?
Cognition'ın garanti sayfasındaki yapı sade: Devin Cloud'u anlamlı ölçekte kullanan uygun enterprise müşteriler için, tamamlanan Devin görevleri üzerinden eşdeğer insan mühendislik saati tahmin ediliyor. Bu saatler standart bir global oranla dolar değerine çevriliyor. Sözleşme döneminin sonlarına doğru müşterinin gerçek tüketimiyle karşılaştırılıyor. Eğer değer tüketimden düşükse, Cognition aradaki farkı ücretsiz kullanım kredisiyle kapatıyor, üst sınır 10 milyon dolar.2
Burada "garanti" kelimesi biraz yanıltıcı olabilir. Bu, her bug için sigorta, her kötü merge için tazminat veya her iş sonucunun finansal etkisini birebir üstlenmek değil. Ugo Catry'nin dışarıdan yaptığı eleştirel QRT bu noktayı iyi yakalıyor: pahalı üretim hataları garanti kapsamının doğal olarak dışında kalıyor, asıl yenilik "saat tasarrufu" ölçerinde.3
Yine de bu küçültülecek bir şey değil. SaaS dünyasında vendor genelde aracı satar, iş sonucunun riskini alıcı taşır. Cognition burada kısmi de olsa risk transferi yapıyor: "Bu araç değer üretmezse, kullanım maliyetinin bir kısmını biz karşılarız." Bu yüzden duyuru hem ürün ölçümü, hem fiyatlama, hem de enterprise satın alma psikolojisi açısından anlamlı.
Enterprise alıcı açısından asıl soru "garanti var mı?" değil, "garantiyi tetikleyen ölçüm itiraz edilebilir mi?" sorusu. Sağlam bir modelde müşteri hangi session'ın faydalı sayıldığını, hangi PR'ın dışarıda bırakıldığını, saat tahmininin hangi girdilere dayandığını ve metodoloji değişirse geçmiş dashboard verisinin değişip değişmediğini görebilmeli. Aksi halde garanti, risk paylaşımından çok vendor'ın kendi skor tahtasına bağlı bir satış vaadine dönüşür.
3. Token cost, ROI, ROT ve üretken saat
Silas Alberti'nin QRT'sindeki en ilginç kavram return on tokens
, hatta parantez içinde "ROT" önerisi. Silas'ın anlatısında altı ay önce herkesin "tokenmaxxing" yaptığı, sonra agent kullanımının bazı müşterilerde çok hızlı büyüdüğü ve harcamanın anlamlı bir bütçe kalemine dönüştüğü söyleniyor. Bu aşamada token harcamak hâlâ iyi olabilir, ama sadece gerçek productivity gain üretiyorsa.4
Burada önemli nüans şu: ROT, ROI'nin yerine geçen nihai metrik değil. ROT daha çok ROI'ye giden dar bir köprü. ROI işin finansal sonucunu, yani bug fix'in ciroyu, riski, müşteri kaybını veya operasyon maliyetini nasıl etkilediğini sorar. ROT ise daha altta, belirli bir token veya agent harcamasından ne kadar faydalı çalışma çıktığına bakar.
ROT'u en sağlıklı haliyle "token başına para kazancı" diye değil, "AI harcaması başına güvenilir üretken çıktı" diye okumak gerekir. Payda sadece ham token olmayabilir: ACU, seat, cloud runtime, review zamanı ve agent yönetim maliyeti de bu harcamanın parçasıdır. Pay ise doğrudan ciro değil; faydalı tamamlanmış iş, eşdeğer insan saati, kalite filtresinden geçmiş çıktı ve yeniden işleme maliyeti düşülmüş kapasitedir. Bu yüzden ROT, CFO'nun nihai ROI hesabına veri taşıyan teknik muhasebe katmanı gibi davranır.
Token cost: en kolay sayaç
Token tüketimi maliyeti gösterir, ama işi göstermez. Bir agent boşa döngüde kalırsa token yakar. İyi bir prompt kısa sürede değer yaratırsa daha az token yakabilir. Bu yüzden token cost, verimliliğin değil maliyetin başlangıç satırıdır.
Yorum
AI ürünlerinde "kullanım arttı" cümlesi yakında tek başına zayıf kalacak. Daha iyi cümle şu olacak: "Kullanım arttı, boşa giden oturum oranı düştü, eşdeğer üretken saat arttı, kalite/risk cezası kontrol altında kaldı."
4. Cognition bunu nasıl ölçüyor?
Teknik makalenin merkezinde iki aşamalı bir agent var. Önce tamamlanan Devin session'ın faydalı çıktı üretip üretmediğini sınıflandırıyor. Sonra faydalıysa, aynı çıktının insan mühendis tarafından ne kadar sürede üretileceğini tahmin ediyor. Bu tahmin için yalnızca final diff'e bakmıyor: kullanıcının mesajları, varsa PR, Devin'in tüm eylem izi, log okuma, kod içinde gezinme, lint düzeltme gibi ara hareketler ve DeepWiki'den gelen codebase bağlamı birlikte kullanılıyor.5
Bu nokta kritik. Lines of code veya PR sayısı niye zayıf? Çünkü bir mekanik refactor binlerce satır değiştirebilir, iki satırlık bir bug fix ise saatlerce teşhis gerektirebilir. Üstelik bazı değerli işler kod üretmez: bug triage, güvenlik taraması, analytics query, PR review, sistem keşfi. Cognition'ın modelinin farkı, "çıktının büyüklüğü" ile "çıktıya varmak için gereken mühendislik emeği"ni ayırmaya çalışması.
1. Faydalılık filtresi
PR varsa, merge edilen PR'lar dahil ediliyor, kapalı veya merge edilmemiş PR'lar daha konservatif biçimde dışarıda bırakılıyor. PR yoksa, non-code üretken işleri tutmak için ayrı sınıflandırma kullanılıyor.
2. İnsan yolu tahmini
Estimator, Devin'in attığı her adımı insan emeği saymıyor. Aksine, aynı çıktıya bir insan nasıl giderdi, kullanıcı ne kadarını zaten çözmüştü, codebase ne kadar tanıdıktı gibi sorulara bakıyor.
3. Konservatif referans
Model, insan mühendisin ilgili uzmanlığa sahip olduğunu varsayıyor. Böylece Devin'in cross-functional avantajı abartılı saat tahminlerine dönüşmesin diye ölçüm aşağı çekiliyor.
4. Dolar karşılığı
Üretken saat tahmini global bir mühendislik oranıyla parasal değere çevriliyor. Garanti mekanizması, bu değeri müşterinin Devin tüketimiyle karşılaştırıyor.
Mini ROT hesaplayıcı
Bu araç Cognition'ın gerçek metodolojisi değildir. Sadece kavramı hissettirmek için basitleştirilmiş bir simülasyon: agent oturumları kaç saat tasarruf sağlıyor, bu saatlerin parasal karşılığı tüketimi aşıyor mu?
5. Validasyon: iyi ama sihirli değil
Cognition'ın teknik yazısındaki en iyi taraf, sadece "ölçüyoruz" dememesi. Modelin nerede iyi, nerede gürültülü olduğunu da yazıyor. Ground-truth veri seti 126 kullanıcıdan 258 gerçek enterprise session içeriyor. Held-out evaluation set 233 session. Estimator'ın log-space korelasyonu 0.74, r_log^2 değeri 0.54. Yaklaşık yarı oturum gerçek tahminin 2 katı içinde kalıyor. Bireysel tahminlerde 2-3 kat hata yaygın, ama hataların kabaca unbiased ve bağımsız olması toplulaştırmada işe yarıyor.6
Bu sonuçların doğru okuması şu: estimator tek bir session için fatura kesmeye yetecek kadar kesin değil, ama büyük kullanım portföyünde yön tayin etmeye yetecek kadar sinyal üretiyor. Log-space korelasyonun anlamı da burada: model, "bu iş 20 dakika mı 2 gün mü?" ölçeğinde göreli büyüklüğü yakalamaya çalışıyor; dakika hassasiyetinde hakemlik yapmıyor. Garanti modeli de bu yüzden tek tek tartışmalı session'lara değil, sözleşme dönemi sonunda toplam tüketim ile toplam tahmini üretken değerin karşılaştırılmasına dayanmalı.
Özellikle line-count karşılaştırması önemli. Teknik yazıda, sadece eklenen ve silinen satır sayısıyla insan tahmini arasındaki ilişki zayıf çıkıyor. Bu sonuç sezgisel olarak doğru: modern yazılım işinde emek diff'te değil, çoğu zaman araştırmada, teşhiste, bağlam kurmada, trade-off değerlendirmesinde ve doğru şeyi değiştirmekte saklı.
Riskler de net. Ground truth self-report, yani kullanıcıların kendi zaman tahminlerine dayanıyor. Örneklem, gönüllü ve daha engaged kullanıcılara kayabilir. Saatler business value değildir. Kaliteyi tam yakalamaz, bir agent'ın merge sonrası saklı bug üretmesi negatif değer yaratabilir. Bu sınırlar, modelin değerini azaltmıyor, ama onu doğru yere koyuyor: Bu bir ROI oracle'ı değil, üretken kapasite tahmincisi.
Buradaki en tehlikeli çeviri hatası, "Devin 100 saat kazandırdı" cümlesini "şirket 100 saatlik değer kazandı" diye okumak olur. Üretken saat kapasite metriğidir; business value ise öncelik, kalite, risk, zamanlama ve alternatif maliyetle belirlenir. Kritik bir incident'ı bir saat erken çözmek ile backlog'daki düşük etkili bir refactor'ı bir saat hızlı yapmak aynı üretken saat olabilir, ama aynı şirket değeri değildir.
Benim kırmızı çizgim
Vendor'ın kendi yazdığı ölçer, vendor'ın garanti kontratını tetikliyorsa, yakında "bağımsız AI productivity auditor" ihtiyacı doğar. Audit log, frozen methodology, müşteri tarafı örneklem denetimi ve bağımsız benchmark raporları enterprise sözleşmelerinin parçası haline gelir.
6. Cognition ekibinin QRT'leri ne söylüyor?
Ana duyuru tek cümlelik bir iddia gibi görünse de, Cognition ekibinden gelen QRT'ler parçaları tamamlıyor. Kurucu anlatısı "activity değil output", araştırma anlatısı "trace + prompt ile zaman tahmini", enterprise anlatısı "ROI en çok sorulan konu", tasarım/ürün anlatısı ise "tokens spent != engineering value" çizgisine oturuyor.
| Kişi | Rol | Ana fikir | Kaynak |
|---|---|---|---|
| Scott Wu | Founder | Token kullanımını productivity ölçmek için kötü bir fikir olarak çerçeveliyor, endüstrinin activity'den output'a geçmesini istiyor. | QRT |
| Silas Alberti | Founding team, research | Tokenmaxxing döneminden spend accountability dönemine geçişi anlatıyor, ROT kavramını öneriyor ve Ryan Bai'nin ölçüm araştırmasına işaret ediyor. | QRT |
| Ryan Bai | Research | LLM'lerin zaman tahmininde kötü olmasına rağmen full session trace ve prompt hill-climbing ile r_log=0.74 noktasına gelindiğini söylüyor. | QRT |
| Jeff Wang | Enterprise leadership | ROI'nin müşterilerden gelen bir numaralı konu olduğunu, garantinin buna yanıt olduğunu söylüyor. | QRT |
| Anna Mitchell | Marketing, Cognition | AI waste tartışmasının sadece spend kesmekle değil, AI'ın ne teslim ettiğini ölçmekle çözüleceğini vurguluyor. | QRT |
| Jared Zoneraich | Builder in residence | Bu hamleyi hem GTM hem engineering inovasyonu olarak görüyor: garanti için önce her session'ın saat değerini tahmin etmek gerekiyor. | QRT |
| Katie Cheng | Engineering & design | Garanti sayfasını yapan taraftan net özet: token harcaması mühendislik değerine eşit değil, enterprise kazananları fiyatını kanıtlayabilenler olacak. | QRT |
| Ben Pan | Research | Ryan Bai'nin teknik raporunu, Devin session'larından insan eşdeğer mühendislik saati tahmin etme sistemi olarak işaret ediyor. | QRT |
Bu QRT'lerden çıkan ilginç tablo şu: Cognition aynı anda üç kitleye konuşuyor. CTO'ya "ölçülebilir üretkenlik" diyor. CFO'ya "değer düşükse krediyle kapatırız" diyor. AI araştırmacısına ise "tek tek session trace'lerinden zaman tasarrufu tahmin edebiliyoruz" diyor. Bu üçü birleşince garanti sadece slogan olmaktan çıkıp bir ürün, ölçüm ve satış mimarisine dönüşüyor.
Bu yüzden guarantee modeli sadece pazarlama sayfası değil, enterprise satış döngüsünde bir sürtünme azaltıcı. CTO için argüman "agent'lar gerçekten mühendislik kapasitesi üretiyor mu?"; CFO için "harcama boşa çıkarsa downside nasıl sınırlanıyor?"; procurement için "vendor performans iddiasını sözleşmeye bağlayabiliyor mu?" şeklinde ayrışır. Cognition'ın hamlesi bu üç soruya aynı mekanizmayla cevap vermeye çalışıyor: kullanım verisi, üretken saat tahmini ve kredi bazlı risk paylaşımı.
7. Bu model hangi kapıları açıyor?
AI guarantee modelleri tutarsa, önümüzdeki birkaç yılda üç yeni kategori görebiliriz.
1. Productivity ledger
Her agent session için muhasebe satırı: kullanılan token/ACU, kullanıcı talebi, sonuç, faydalı çıktı sınıfı, tahmini insan saati, kalite sinyali, risk notu, tekrar çalışma maliyeti. Bu ledger olmadan enterprise AI harcaması büyüdükçe yönetilemez hale gelir. En iyi agent platformları, chat transcript veya PR listesi değil, üretkenlik muhasebesi sunacak.
2. Outcome SLA ve garanti pazarı
Bugünkü garanti kullanım kredisi seviyesinde. Bir sonraki dalga, kategoriye göre farklı SLA'ler olabilir: support agent için çözülmüş ticket, sales agent için nitelikli lead, coding agent için accepted PR, compliance agent için review coverage. Her kategori kendi "faydalı çıktı" tanımını ve itiraz mekanizmasını ister.
Bu yüzden tek bir "AI productivity guarantee" standardı çıkması zor; daha olası olan, kategori bazlı garanti aileleri. Coding agent için accepted PR ve üretken mühendislik saati anlamlı olabilir. Support agent için çözülmüş ticket, yeniden açılma oranı ve CSAT etkisi gerekir. Compliance agent için coverage, false negative riski ve denetlenebilir gerekçe zinciri öne çıkar. Garanti dili standartlaşabilir, ama ölçülen outcome her kategoride ayrı bir muhasebe disiplini ister.
3. Üçüncü taraf ölçüm ve sigorta
Garanti büyüdükçe alıcı "ölçeri kim denetliyor?" diye soracak. Bu, synthetic evaluator panelleri, çoklu model hakemliği, müşteri tarafı shadow scoring, bağımsız audit firmaları ve belki sigorta ürünleri yaratır. Vendor metrikleri ile bağımsız metrikler arasındaki fark, yeni pazarlık alanı olur.
Bir AI garanti modeli nasıl tasarlanmalı?
Aşağıdaki mini karar ağacı, bir AI ürününde garanti fikrinin hangi ölçüm olgunluğuna ihtiyaç duyduğunu düşünmek için.
Önce outcome tanımı, sonra ölçüm, en sonda garanti.
Cognition'ın hamlesi bana göre "AI is cheap" anlatısının sonuna işaret ediyor. AI ucuz değil, eğer boşa çalışıyorsa çok pahalı. AI pahalı da değil, eğer ölçülebilir çıktı üretiyorsa düşük maliyetli kapasite. Farkı belirleyen şey token fiyatı değil, workflow ve ölçüm mimarisi.
8. Sonuç: token ekonomisinden çıktı ekonomisine
Cognition'ın AI Productivity Guarantee modeli mükemmel mi? Hayır. İnsan saatini business value ile karıştırma riski var. Kalite ve negatif etkileri eksik yakalayabilir. Vendor'ın kendi estimator'ı ile kendi garanti şartını ölçmesi doğal güven soruları yaratır. Ayrıca kredi iadesi, prod hasarı veya fırsat maliyeti gibi daha büyük riskleri kapsamaz.
Ama yine de önemli. Çünkü AI pazarında ölçüm bir süredir geriden geliyordu. Önce modeller geldi, sonra agent workflow'ları geldi, şimdi de bu workflow'ların finansal ve operasyonel hesabı gelmeye başlıyor. "Kaç token yaktık?" sorusu yerini yavaş yavaş "hangi session faydalıydı, kaç saat kazandırdı, hangi workflow boşa döndü, bu harcamanın geri dönüşü ne?" sorusuna bırakıyor.
ROT kavramı burada güzel bir ara durak. ROI kadar büyük, soyut ve şirket bağlamına bağımlı değil. Token cost kadar yüzeysel de değil. Eğer doğru kurulursa, model seçimi, prompt tasarımı, context mimarisi, agent orkestrasyonu ve enterprise enablement kalitesini aynı tabloda konuşmayı sağlar.
Bence asıl shift şu: AI vendor'ları artık sadece kapasite değil, ölçülebilir güven satmak zorunda kalacak. Devin bunu ilk yapanlardan biri olabilir. Ama bu fikir sadece coding agent'larda kalmaz. Müşteri destek, satış, sigorta operasyonu, hukuk inceleme, finansal analiz ve iç bilgi yönetimi gibi her agent kategorisinde benzer garanti dilini göreceğiz.
Kısa hüküm
Token cost optimizasyonu bitmedi, ama artık tek başına strateji değil. Yeni strateji, token'ı üretken çıktıya, üretken çıktıyı güvenilir ölçüme, ölçümü de fiyatlama ve garantiye bağlamak.