Şahsen, Bakın şimdi, yazılım dünyasında yıllardır aynı cümleyi farklı ambalajlarla duyup duruyoruz: “Artık işler çok değişti.” AI geldi, ajanlar çıktı, kod tamamlama araçları uçtu, CI/CD boru hattı olgunlaştı, dokümantasyon otomatikleşti… ama işin aslı şu ki, proje teslim etmenin o garip ağırlığı pek de kaybolmadı. Hâlâ aynı duvara tosluyoruz.
Ne yalan söyleyeyim, İşin %90’ı bitti sanılırken en zor kısım tam orada başlıyor.
Geçen ay Kadıköy’de bir ürün ekibiyle sohbet ederken tam da bunu anlattım. Ekranda çalışan bir prototip vardı, herkes keyifliydi — yüzlerde o “aa bu iş bitti” ifadesi vardı yani. Sonra biri “bir de edge case’ler var” dedi ve oda bir anda sessizleşti. O an hepimizin yüzünde aynı ifade belirdi: “Aaa doğru ya…” Tanıdık geldi mi? Bu yazı biraz o hissin peşinden gidiyor (bizzat test ettim)
Bu paradoks bana hep şunu düşünduruyor: başlamak ayrı şey, bitirmek ayrı şey. Başlangıç çoğu zaman heves işi; bitiriş ise sabır, seçicilik ve biraz da soğukkanlılık istiyor — özellikle AI araçlarıyla birlikte insanlar daha hızlı üretmeye başlayınca bu fark daha da belirgin hale geldi. Hız arttıkça eksik kalan küçük ayrıntılar daha görünür oluyor çünkü. Küçük değil aslında. Sonradan can yakan detaylar onlar.
Neden Son %10 Hep Bu Kadar Ağır Geliyor?
Şunu söyleyeyim, Kısa cevap şu: teknik olarak ufak görünse de karar yükü açısından devasa oluyor — valla güzel iş çıkarmışlar —. İlk %90’da çoğu zaman iskelet kurulur, akış oturur, kaba hatlar çıkar — hepsi nispeten mekanik işler. Ama son bölümde performans testleri devreye girer, güvenlik açığı çıkabilir, kullanıcı deneyimi “idare eder” seviyesinden “gerçekten iyi” seviyesine taşınmak zorunda kalır ve bunların her biri bir karar gerektirir.
Kısa bir not düşeyim buraya.
Bir de şu var. O son dilimde artık koddan çok bağlam konuşulur. “Bunu niye böyle yaptık?”, “Bu buton neden burada?”, “Bu hata mesajını müşteri görürse ne olur?” gibi sorular çıkar ortaya. Açık konuşayım, birçok ekip ilk etapta bu soruları küçümsüyor. Sonra teslim tarihi yaklaşınca herkes aynı masada aynı dosyaya bakıp boş boş susuyor… olmuştu bana da 2023’te İzmir’de çalıştığım küçük bir SaaS projesinde.
Orada dashboard gayet tatlı görünüyordu ama export özelliği neredeyse final boss gibiydi. CSV geliyor ama karakter seti bozuk. PDF çıkıyor ama mobilde kayıyor. Yetki kontrolü düzgün ama loglama eksik. Neden önemli bu? Bunların her biri tek tek minik mesele gibi duruyor — toplamda ise haftayı yutuyor.
Bunu biraz açayım.
Dört Aşama: Herkes Aynı Yoldan Geçmiyor
Yıllardır bu konuya bakınca dört farklı yaklaşım görüyorum. Resmi bir model değil bunlar — ama pratikte fena halde işe yarıyor. Sahada defalarca gördüm; bazen aynı kişide bile farklı günlerde bambaşka modlar açık oluyor. İnsanlar tutarsız, demek istiyorum.
1) Yeni başlayan: Çalışıyorsa tamamdır
Bilmem anlatabiliyor muyum, Yeni başlayan biri için esas hedef ekranda bir şey görmek oluyor. Kodun mimarisi mi? Biraz sonra bakılır. Test mi? Zaten önce özellik çalışsın da (şaşırtıcı ama gerçek). Bu yaklaşımın avantajı hız ve cesaret — insan gereksiz yere fren yapmıyor, ilerliyor.
İtiraf edeyim, Gel gelelim dezavantajı da belli: teknik borç sessizce birikir. Bir feature hafta sonu uğraşıyla çıkar ama üç hafta sonra kimse nasıl çalıştığını anlayamaz hale gelir. Kimse. Bazen o kodu yazan kişi bile.
2) Profesyonel görünen evre: Her şey kusursuz olsun
Burası biraz tuhaf bölge, nasıl desem… İnsan deneyim kazandıkça özgüveni artıyor ama aynı anda korkuları da büyüyor — “ya yanlış olursa, ya eksik kalırsa” diye. Artık Docker olsun, güvenlik taraması olsun, release note olsun, her şey yerli yerinde olsun isteniyor. Fena değil tabii; hatta çoğu zaman gerekli.
Neyse, bilmem anlatabiliyor muyum, Ama bazen bu evre fazla cilaya kaçabiliyor. Geçen sene Berlin’de katıldığım küçük bir toplantıda bunu birebir duydum: ekip aylarca paketleme stratejisini tartışmış ama kullanıcıya gidecek ana akışı hala donduramamıştı (inanın bana). Kağıt üstünde süperdi, pratikte ise hayal kırıklığı yaratıyordu. Böyle olunca kılıfı bitirmiş ama ürünü bitirememişsin demek oluyor.
3) Düşünür tipi: “Biz tam ne yapıyoruz?”
Düşünür aşamasında insan daha keskin bakmaya başlıyor; kalite algısı yükseliyor. Bazen iş akışını kilitleyecek kadar yükseliyor bu algı. Kendimden biliyorum — 2024 baharında Ankara’da yürüttüğüm bir danışmanlık işinde aynı PR’ı üç kez reddettiğimi hatırlıyorum, çünkü her seferinde başka bir açıdan eksik buluyordum. Evet, biraz fazla seçiciydim. Bu konuyla ilgili OriginOS 7: Vivo’da Sıradaki Büyük Yazılım Dalgası yazımıza da göz atmanızı tavsiye ederim.
Evet, doğru duydunuz. Bu konuyla ilgili Confdroid Selinux: Puppet ile Güvenliği Otomatikleştirmek yazımıza da göz atmanızı tavsiye ederim.
Tuhaf ama, Burasının tehlikesi şu: insan sadece kötü kodu değil kendi kodunu da sevmez hale gelebiliyor. O noktada ilerlemek yerine sürekli yeniden düşünme döngüsüne giriyorsunuz. Döngü kırılmıyor. Hiç kırılmıyor.
4) Bitirici: Ne zaman bırakacağını bilen kişi
Burada, bilmem anlatabiliyor muyum, Asıl olgunluk burada geliyor bence. Bitirici kişi son %10’un zamanın %90’ını yiyebileceğini bilir ve buna sinirlenmez; planını buna göre kurar zaten. Hangi kısımlar gerçekten kullanıcıya değer veriyor? Hangi detay sadece mühendis egosu? İşte can alıcı soru bu (yanlış duymadınız)
Son %10’u bitirebilmek için önce şunu kabul etmek gerekiyor: Her şeyi mükemmel yapmak zorunda değilsiniz; bazı şeyler yalnızca yeterince iyi olmalı.
AI Varken Neden Hâlâ Aynı Çileyi Yaşıyoruz?
Şunu fark ettim: Doğal soru bu. Madem yapay zekâ var, neden hâlâ son kısım bu kadar uğraştırıyor? Cevap aslında basit: araçlar hız veriyor ama karar vermiyor. En azından henüz tam olarak vermiyor diyelim. Kod önerisi almak kolaylaştı diye ürünün anlamlı şekilde tamamlanması kolaylaşmıyor.
Ve işler burada ilginçleşiyor.
Editör masasında bu haberi incelerken ben de kendi küçük testimi yaptım açıkçası. Yerel bir projede agent tabanlı (söylemesi ayıp) bir IDE’ye basitçe “repo’ya göz at” dedim; güzelce incelemeye başladı — şaşırdım açıkçası, fena değildi — ama güvenlik politikasına takıldı ve safça terminal komutu önermeye yöneldi. Yani sorunun çözümü yerine ritüele kaydı biraz. Tanıdık geldi mi? Bana baya geldi.
Araçlar ilk yüzde inanılmaz yardımcı oluyor. Hız kazanıyorsunuz. Ama kritik kenar durumlarında hâlâ insanın ince sezgisine ihtiyaç var — bitirme kasınız yine sizde kalıyor.
Peki, bir de şu var: kurumsal tarafta onay mekanizmaları yüzünden zaten yavaş olan süreçler AI ile daha görünmez hale gelebiliyor,. Ekipler yanlışlıkla “her şeyi otomasyon halleder” rehavetine giriyor (ciddiyim). Sonra baktıklarında ay geçmiş, feature hâlâ staging’de bekliyor (ciddiyim)
| Aşama | Zihniyet | Sorun | Çözüm yaklaşımı |
|---|---|---|---|
| Başlangıç | “Çalışsın yeter” | Kaba işçilik | MVP + net sınırlar |
| Profesyonellik | “Mükemmel olmalı” | Aşırı mühendislik | Zorunlu olmayan işleri kısmak |
| Düşünürlük | “Doğru şeyi mi yapıyoruz?” | Kilitlenme riski | Kullanıcı etkisini ölçmek |
| Bitiricilik | “Değer varsa tamamla” | Kapsam şişmesi olmadan kapatma ihtiyacı | Pareto mantığıyla önceliklendirme |
Küçük Startup ile Kurumsal Takım Aynı Sorunu Yaşamıyor Mu?
Kısmen benzerler. Ama baskının şekli farklı.
Küçük startup’ta sorun genelde kaynak azlığıdır — para, insan, zaman, hepsi kıt. Kurumsal tarafta ise onay ve süreç fazlalığı var; para var, insan var ama sistem kendini frenlemeye programlamış sanki. İkisi de yorucudur ama farklı yerlerden sıkıştırır insanı (en azından benim deneyimim böyle) PostgreSQL’de Bağlantı Patlaması: PgBouncer ve Supavisor yazımızda bu konuya da değinmiştik.
Startup tarafında o son %10 çoğu zaman nakit akışına bağlanıyor. “Bir haftalık gecikme sorun değil” denir — ama aslında öyledir. Ben geçen yıl Eskişehir’de görüşme yaptığım iki kişilik bir girişimde bunu çok net gördüm. Ürün sahibi bana resmen şöyle dedi: “Özellik hazır sayılır (ben de ilk duyduğumda şaşırmıştım). Edge case’leri erteledik.” Dürüstçe söyleyeyim, kulağa rahatlatıcı geliyor — ama kullanıcı trafiği artınca o ertelemenin faturası çat diye çıkıyor. Hani ne farkı var diyorsunuz, değil mi? Kaçınılmaz.
Kurumsalda ise başka türden sıkıntılar var. Bazen feature bitmiş oluyor fakat hukuk onayı bekleniyor; bazen security review uzuyor; bazen de release notlarının tonu bile tartışma konusu oluyor. İşte tam burada finisher zihniyeti lazım: hangi kısmın gerçekten yayına değdiğini bilmek.
- Küçük ekipte: kapsam daraltmak hayat kurtarıyor.
- Büyük organizasyonda: onay zincirini sadeleştirmek gerekiyor. — ciddi fark yaratıyor
- Aynı problem: son %10 için gerçekçi sınır koyamamak.
Peki Ne Yapmalı?
Lafı gevelemeden söyleyeyim. Birkaç basit ama bir o kadar zor şey var.
- Önce “bitmiş” tanımını netleştirin — “bitti” ne anlama geliyor, herkes aynı şeyi mi anlıyor?
- Sadece kullanıcı etkisi olan işleri sona bırakın; kozmetik detayları sonra toparlayabilirsiniz, gerçekten.
- Eğer iki saatlik iş üç günlük tartışma çıkarıyorsa, orada kapsam kaçmıştır demektir.
- Sürüm öncesi mutlaka “gerekirse ertelenebilir” listesi hazırlayın — bu liste baya işe yarıyor, küçümsemeyin.
Kendi kendime uyguladığım küçük yöntemler
Açık konuşayım, ben artık her projede üç soru soruyorum. Bu özellik kimin canını yakacak? Yapmazsak ne olur? Yaparsak gerçekten fark eder mi? Cevap yoksa — ya da cevap “hmm, emin değilim” ise — iş çoğu zaman abartılmıştır.
Bir gece saat 01:30’da İstanbul’da otururken eski notlarımı karıştırdığımı hatırlıyorum. O sırada fark ettim ki beni en çok yoran şey yazdığım kod değil, “acaba daha iyisi var mı?” sorusunu sonsuza dek döndürmekti. O gün bugündür final çizgisini erken çizmeye çalışıyorum. Çoğu zaman kusursuz olmuyor. Zaten mesele de o değil.
Burada amaç acele etmek değil; neyin tamamlanmayı hak ettiğini ayırmak. Bana göre profesyonellik bu kadar basit ve bu kadar zor işte. Basit çünkü çerçeve net: öncelikli değeri teslim et. Zor çünkü ego sürekli araya giriyor. Hep giriyor.
Sıkça Sorulan Sorular
“Son %10 neden hep daha uzun sürüyor?”
Garip gelecek ama, Çünkü son bölümde belirsizlik azalmaz, aksine görünür olur. Kenar durumları,
entegrasyon sorunları ve kullanıcı beklentileri tam orada ortaya çıkar. Kod küçük görünür ama etkisi büyür.
“AI araçları bu problemi çözmez mi?”
Kısmen çözerler; özellikle üretimin ilk kısmında hız kazandırırlar. Ama hangi detayı gerçekten bitireceğinize yine insan karar verir. Yani araç hız verir, yön vermez gibi düşünün.
“Mükemmeliyetçilik kötü mü?”
Tam kötü demek haksızlık olur.
Kalite standardını korur.
Ama sınırı kaçarsa teslimi geciktirir ve takım enerjisini emer.
“Bitirmeyi öğrenmek için ne yapmalıyım?”
Kullanıcı etkisini ölçün,kapsam sınırı koyun ve gereksiz cilayı erken kesin.
Bir şey değer yaratmıyorsa ertelemeniz normaldir.
Bitirmek bazen bırakmayı bilmektir.
Kaynaklar ve İleri Okuma
Orijinal yazı — The 90%-Done Paradox
Şöyle söyleyeyim, Microsoft DevOps Documentation (resmi)
GitHub Actions Dokümantasyonu (resmi)
Daha önce benzer biçimde ürün tarafındaki ince dengeyi anlattığımız Kod Yazmak Yetmiyor: UI’da Asıl Farkı Ne Belirliyor? yazısına da göz atabilirsiniz; özellikle son cilalama aşamasıyla ilgili güzel bağlantılar kuruyor.
Size bir şey söyleyeyim, Eğer AI araçlarının pratikte nerede tökezlediğini merak ediyorsanız Claude Code, Codex CLI ve Gemini CLI: 2026’nın En İyi AI Terminal Agent’ı Hangisi? yazımızdaki karşılaştırma da bu konuya başka açıdan bakıyor.Anlatının arka planında güvenlik tarafını seven okurlar için Tarayıcıda Gizli Veri Avı: Yapay Zekâya Gitmeden Önce başlıklı içerik de oldukça ilgili duruyor.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
