AI Slop’un Faturasını Mühendis Öder, PM Önleyebilir

Brandolini’nin Cümlesi Bedava Üretimle Karşılaştı

Alberto Brandolini 2013’te bir cümle yazdı. Saçmalığı çürütmek için gereken enerji, onu üretmek için gereken enerjiden bir mertebe büyüktür. Brandolini yasası diye anılan bu cümle sosyal medya tartışmaları için söylenmişti. Bugün bir sprint planlamasına da uyuyor.

Simon Willison 2024 mayısında istenmemiş AI çıktısına “slop” demeyi önerdi ve kelime tuttu. Bir ekipte slop çoğunlukla spec, PRD, toplantı özeti ve kullanıcı hikayesi olarak karşına çıkıyor. Üretmesi dakikalar alıyor. Okuyup çürütmesi ise bir insanın saatini istiyor ve o insan, spec’i koda dökecek mühendis oluyor.

Darboğaz bu yüzden üretimden karara kaydı. Bir dokümanı yazmanın maliyeti sıfıra yaklaşınca, hangisinin yazılmaya değer olduğuna karar vermek geriye kalan tek pahalı iş oluyor. Marty Cagan’ın INSPIRED kitabında anlattığı ürün keşfi de zaten bu “ne yapılacak, neden yapılacak” sorusunun etrafında dönüyor.

Hız hissine de güvenmemek gerekiyor. METR 2025 temmuzunda, kendi açık kaynak depolarında çalışan 16 deneyimli geliştiriciyle 246 görevlik kontrollü bir deney yayımladı. AI araçlarının serbest olduğu görevler yüzde 19 daha uzun sürdü. Geliştiriciler çalışmadan önce yüzde 24 hızlanma bekliyordu, çalışmadan sonra da yüzde 20 hızlandıklarına inanıyordu. Örneklem dar ve tek bir çalışma, genellenemez. Yine de hızlanma hissiyle ölçümün örtüşmediği bir durum var ve ekip “bu hafta çok doküman çıktı” diye sevinirse aynı hataya düşer.

Slop Belirsiz Brief’ten Başlar

Üretilmiş bir PRD’nin yanına bir sayfalık brief koy. On sayfalık doküman eksiksiz görünür, başlıkları yerindedir ve her bölüm doludur. Ama bölümlere yakından bakınca hepsinin aynı belirsiz cümlenin farklı sözcüklerle uzatılmış hali olduğunu görürsün. Brief ise kısadır ve her cümlesi bir karara yaslanır.

Slop tam burada üretilir. “Kullanıcı deneyimi iyileştirilmeli” cümlesi makuldür, ama kime, hangi ekranda, neye göre iyileşeceğini söylemez. Böyle bir cümle çürütülemez, çünkü ortada çürütülecek bir iddia yok. Çürütülemeyen cümleyi herkes başını sallayıp geçer, hatayı da ancak teslim edilen çıktı gösterir.

Kaynak çoğu zaman modelin yeteneği olmuyor. Girdi bulanıksa model bulanıklığı akıcı paragraflara çevirir. Doğrulanmamış varsayım da aynı yoldan geçer. “Kullanıcılar bildirimleri kaçırıyor” cümlesi bir PM’in tahminiyse ve kimse bunu kayıtlara bakıp sınamadıysa, AI o tahminin üzerine on sayfa kurar. Sayfa arttıkça varsayım daha doğru görünür, çünkü etrafında kalabalık bir doküman vardır.

Tek bir kontrol yeter: dokümandaki her cümle için “bunu silsem biri fark eder mi?” diye sormak. Fark eden çıkmıyorsa cümle gider. Aynı kontrolü eline geçen bir PRD’ye uygula, silinebilir cümleleri işaretle ve geriye kalanın brief’te yazan karara ne kadar yaklaştığına bak. Çoğu zaman geriye bir paragraf kalır, o paragrafın hakkını veren de PM olur.

Dört Noktada İmza Aranır

Adında bir insan olmayan doküman kimsenin değildir. Başlığın altındaki “hazırlayan” satırında yazan kişi dokümanın her cümlesini toplantıda savunabilmeli. Savunamıyorsa o cümleyi yazmamış, yalnızca geçirmiştir.

Bu kuralı her yere yaymak ekibi yorar. Toplantı notuna imza aramanın anlamı yok. Slop’un girdiği yerlerden dördünde imza aranır:

• Problem tanımı. Yanlış sorunun üstüne kurulan iş ne kadar temiz teslim edilirse edilsin yanlış sorunu çözer. Bu cümleyi bir insan kendi ağzıyla yazmalı.
• Kabul kriteri. Test edilemeyen kriter bitti demenin ölçüsü olamaz.
• Release notu. Müşteriye neyin değiştiğini söyleyen tek metin bu ve yanlış söz verirse faturayı destek ekibi öder.
• Hata mesajı, onay e-postası ve ekrandaki tek satırlık açıklama gibi kullanıcıya dönük metinler. Kullanıcı bunları ürünün sesi olarak okur.

Kıdemli mühendis bu noktalardan birinde bir varsayım görürse “Bu cümle hangi veriye dayanıyor?” diye sorabilmeli. İmzalı dokümanda soracak biri, cevap verecek biri var. İmzasız dokümanda soru havada kalır.

“Model öyle yazdı” cevap sayılmaz. Sahip varsayımı ya kaynağıyla gösterir ya da siler. İkisi de beş dakikada biter. Başlamak için brief şablonuna ve PR şablonuna “Dayandığım varsayımlar” diye bir alan, altına da bir isim koymak yeter.

Ekip düzeyinde üç erken belirti var. PR açıklamaları uzuyor ama bilgi vermiyor, toplantı notlarını kimse açmıyor ve aynı fikir üç farklı dokümanda tekrarlanıyor. Bunlardan biri görünüyorsa imza noktalarına dön.

Demosu Olan Fikre Hayır Demek

Prototip çıkarmak ucuzlayınca aday sayısı patlıyor. Toplantıdan üç fikir çıkıyor ve ertesi sabah üçünün de çalışan bir demosu masada duruyor. Demosu olan fikre hayır demek, yalnızca anlatılmış bir fikre hayır demekten çok daha zor.

Teknik borcun bir akrabası burada doğuyor, ben ona AI borcu diyorum. Yapılmış ama kimsenin istemediği özellikler, bakımı süren ama açılmayan ekranlar ve yarım kalmış deneyler bu borcun kalemleri. Her biri test, dokümantasyon ve bir gün birinin dönüp okuması anlamına geliyor. Üretimin maliyeti sıfıra yaklaştı, sahiplenmenin maliyeti yerinde duruyor.

PM’in asıl filtre işi de buraya düşüyor. Önceliklendirme çerçevelerinin amacı, çıtayı geçemeyen fikri kapıda tutmak ve geçen fikre ekibin dikkatini bırakmak. Hayır, listeye giren her kalemin kaydını da tutar: neden yapılmadığı yazılırsa üç ay sonra aynı fikir yeniden demoyla geldiğinde tartışma sıfırdan başlamaz.

Müşteriyle temas da burada devredilemiyor. AI özeti kullanıcı görüşmesinin yerini tutmaz. Görüşme kaydı, destek biletleri ve ham veri PM’in elinde kalmalı, özet yalnızca ikinci okuma olmalı. Filtrelemek için önce neyin filtrelendiğini kendi gözüyle görmek gerekir.

Çıta Ekibin Kendi Brief’leriyle Konur

Teknik yönetici olarak PM’i AI konusunda denetlemek yerine ortak bir çıta koymak daha işe yarıyor. Somut hali kısa bir klasör: iyi ve kötü brief’lerin yan yana durduğu, her birinin altında neden öyle olduğunun yazılı olduğu.

Kötü örnek şöyle: “Kullanıcılar faturalarını kolay yönetsin, akıllı bir fatura paneli geliştir.” Kimin hangi sorunla geldiği, ne zaman bitti sayacağımız belli değil.

İyi örnek ise şöyle: “Destek kayıtlarında en sık tekrarlanan şikayet, fatura PDF’ini bulamayan kullanıcılar. Kullanıcı son altı faturayı girişten sonra üç tıklamada indirebilmeli. Yapmayacağız: toplu indirme, e-postayla gönderim.” Bir sayfa, bir sahibi var, bir mühendis ya da bir model sınayabilir ve kapsam dışını da söylüyor.

Bu iki örnek senin ekibinin geçmişinden seçilmeli, bu yazıdan kopyalanmamalı. Çıta PM’e dışarıdan dayatılırsa ekip onu bir kural olarak sürdürür, kendi brief’lerinden çıkarsa kalite ölçüsü olarak sahiplenir.

Bu hafta ekibinin son üç brief’ini al, her cümleye “silsem biri fark eder mi?” diye sor ve geriye kalanı ekip kanalında paylaş. Neyin kaldığına bakınca bir sonraki kuralı nereye koyacağını görürsün.