Özet. Her otomasyon bir kredidir. Bugün zaman kazanırsınız, faizini ise sonradan ödersiniz: çıktıları kontrol ederek, istisnaları ele alarak, bozulanları onararak ve işi elle yapabilecek birini hazırda tutarak. Ödenmemiş bakiyeye otomasyon borcu diyoruz. Faizin gerçek olduğuna dair kanıtlar güçlü: randomize bir denemede deneyimli açık kaynak geliştiricileri yapay zeka araçlarının görev sürelerini %24 kısaltacağını öngördü, oysa işi %19 daha uzun sürede bitirdiler; Google’ın DORA 2024 raporu, yapay zeka benimsenmesindeki her %25’lik artışın teslimat hacminde %1,5’lik ve teslimat istikrarında %7,2’lik bir düşüşle birlikte geldiğini tahmin ediyor; Stack Overflow 2025 anketindeki geliştiricilerin %66’sı ise “neredeyse doğru ama tam değil” yapay zeka çıktısını en büyük hayal kırıklığı olarak gösteriyor. Yaygın beş otomasyon için kurduğumuz başa baş modeli, doğrulama, istisnalar ve bakım hesaba katıldığında bunlardan ikisinin kendini hiç amorti etmediğini, üçüncüsünün ise üç yıldan uzun süre gerektirdiğini gösteriyor. Çözüm daha az otomasyon değil. Çözüm, neyin otomatikleştirileceğine dair sahip düzeyinde muhakeme ve bir süreci makineye devretmeden önce onu elle öğrenen öğrenci disiplini.
Kimsenin kayda geçirmediği kredi
Ward Cunningham borç metaforunu, WyCash portföy sistemi üzerine 1992’de OOPSLA’da sunduğu deneyim raporunda ortaya attı. İlk seferde yazılan kodu yayına almanın borçlanmaya benzediğini yazdı: az miktarda borç, hızla geri ödendiği sürece geliştirmeyi hızlandırır; ancak tam doğru olmayan kod üzerinde geçen her dakika faiz sayılır ve bir organizasyon bu yükün altında durma noktasına gelebilir. Yirmi üç yıl sonra D. Sculley liderliğindeki bir Google ekibi, NeurIPS’te yayımlanan “Hidden Technical Debt in Machine Learning Systems” makalesinde aynı merceği makine öğrenmesine uyguladı. Açılıştaki uyarıları her otomasyon projesine uyuyor: hızlı kazanımların bedava geldiğini düşünmek tehlikelidir, çünkü gerçek dünyadaki sistemler çoğunlukla “devasa ve süregiden bakım maliyetleri” doğurur. Tüm borçların kötü olmadığını, ama her borcun ödenmesi gerektiğini de eklerler; gizli borç ise sessizce katlanarak büyüdüğü için tehlikelidir.
Otomasyon borcu, aynı olgunun bir bireyin ya da ekibin iş akışı düzeyindeki karşılığıdır. Bir Zap, bir betik, bir yapay zeka ajanı, bir e-posta kuralı ya da bir tablo makrosu, her biri görünür bir görevi ortadan kaldırır ve daha az görünür görevler yaratır:
- birinin çıktının doğru olduğunu kontrol etmesi gerekir;
- birinin otomasyonun ele alamadığı durumları yakalaması gerekir;
- bir API, bir form, bir sütun adı ya da bir model değiştiğinde birinin onu onarması gerekir;
- otomasyonun çöktüğü gün için birinin sürecin nasıl işlediğini hatırlaması gerekir.
Bu dört işin sahibi olmadığında otomasyon, devreye alındığı gün saf kâr gibi görünür ve sonrasında yavaş bir kanamaya dönüşür. İşin tehlikeli yanı, bu kanamanın kazançla nadiren aynı yerde görünmesidir. Akışı kuran kişi kazanılan saatleri raporlar; hatalarını temizleyen kişi ise hiçbir şey raporlamaz, çünkü kimse sormamıştır.
Kanıtlar gizli faiz hakkında ne söylüyor
Biri randomize bir deneme, biri büyük bir sektör anketi, biri de çok büyük bir geliştirici anketi olan birbirinden bağımsız üç veri seti aynı yönü gösteriyor. Tablo 1 yalnızca birincil belgelerde doğruladığımız rakamları içeriyor.
Tablo 1. Otomasyonun gizli maliyetler taşıdığına dair kanıtlar (doğrulanmış veriler)
| Kaynak | Örneklem | Bulgu |
|---|---|---|
| METR randomize kontrollü deneme (Becker et al., 2025) | Olgun açık kaynak projelerde 16 deneyimli geliştirici, 246 gerçek görev | Geliştiriciler yapay zekanın tamamlama süresini %24 kısaltacağını öngördü; sonrasında %20’lik bir kısalma tahmin ettiler; ölçülen etki ise tamamlama süresinde %19’luk bir artış oldu |
| Aynı çalışma, güvenilirlik analizi (Appendix C.1.4) | Geçerli etiketlere sahip 44 konunun ekran kayıtları | Geliştiriciler yapay zeka üretimlerinin %44’ünden azını kabul etti ve yapay zekaya izin verilen sürenin yaklaşık %9’unu yapay zeka çıktısını incelemeye ve temizlemeye harcadı; %75’i yapay zeka kodunun her satırını okuduğunu bildirdi |
| Google DORA, Accelerate State of DevOps 2024 | 2024’te anket yapılan yaklaşık 3.000 profesyonel | Yapay zeka benimsenmesindeki her %25’lik artışta: teslimat hacmi tahminen -%1,5, teslimat istikrarı -%7,2, değerli işe ayrılan süre -%2,6, angarya işe ayrılan süre +%0,4 |
| Google DORA 2024, güven | Aynı anket | %39,2’si yapay zeka tarafından üretilen kodun kalitesine az (%27,3) ya da hiç (%11,9) güvenmediğini bildirdi |
| Stack Overflow Developer Survey 2025 | On binlerce geliştirici (güven sorusunu 33.244 kişi yanıtladı) | %46’sı yapay zeka araçlarının doğruluğuna güvenmiyor, güvenenler ise %33; %66’sı “neredeyse doğru ama tam değil” çıktıyı bir hayal kırıklığı olarak gösteriyor ve %45,2’si yapay zeka tarafından üretilen kodda hata ayıklamanın daha fazla zaman aldığını söylüyor; %20’si kendi problem çözme becerisine daha az güvenir hale geldiğini söylüyor |
Birlikte okunduğunda bu rakamlar otomasyon borcunun anatomisini tarif ediyor.
Algı farkı ilk faiz ödemesidir. METR denemesindeki geliştiriciler acemi değildi: üzerinde çalıştıkları depolarda ortalama beş yıllık deneyimleri vardı ve çalışmanın ardından bile yapay zekanın kendilerini hızlandırdığına inanıyorlardı. Uzmanlar kendi işlerindeki etkinin yönünü bile yanlış değerlendirebiliyorsa, yeni bir otomasyonun “kazandırdığı saatler” için yapılan gelişigüzel bir tahmin zayıf bir kanıttır. Yazarlar sonuçlarının belirli bir bağlam için geçerli olduğunu (deneyimli geliştiriciler, büyük ve olgun kod tabanları, 2025 başı araçları) özenle vurguluyor; sonuç “yapay zeka herkesi yavaşlatıyor” diye okunmamalı. Aktarılabilir ders daha dar ve daha kullanışlı: hissedilen hız, ölçülen hız değildir.
Doğrulama tek seferlik değil, tekrarlayan bir maliyettir. Üretimlerin yarısından azını kabul etmek, sürenin yaklaşık onda birini inceleme ve temizlemeye harcamak ve her satırı okumak: sahibi yüksek standartlara sahip olduğunda kontrol etmek böyle görünür. Stack Overflow verileri aynı örüntüyü on binlerce geliştiricide gösteriyor: neredeyse doğru olan çıktı pahalıdır, çünkü bulunması, anlaşılması ve düzeltilmesi gerekir.
Yerel hız, sistem sonuçlarına zarar verebilir. DORA’nın bulgusu en sezgilere aykırı olanı. Yapay zeka benimsenmesi daha iyi dokümantasyon kalitesi, kod kalitesi ve bireysel üretkenlikle ilişkiliydi; ama teslimat hacmi ve istikrarı kötüleşti. Raporun hipotezi, daha hızlı üretimin ekipleri DORA’nın en temel ilkelerinden birini, küçük parti boyutlarını unutmaya ittiği yönünde: yapay zeka insanların aynı sürede daha fazla kod üretmesini sağlıyorsa değişiklik setleri muhtemelen büyüyor ve DORA daha büyük değişikliklerin daha yavaş ve istikrarsızlığa daha açık olduğunu tutarlı biçimde gözlemliyor. Rapor ayrıca değerli işe ayrılan sürenin düştüğünü, angaryaya ayrılan sürenin ise değişmediğini buldu; bu, otomasyonun vaat ettiğinin tam tersi. Bir iş akışını otomatikleştiren herkes için uyarı şu: daha hızlı adımlar daha hızlı bir sistemi garanti etmez.
Bu bulgular, ölçümün alışılmadık derecede iyi olduğu yazılım dünyasından geliyor. Bunları, insan faktörleri literatürünün genel olarak otomasyon için onlarca yıl önce tarif ettiği ve aşağıda geri döneceğimiz bir örüntünün en iyi ölçülmüş örneği olarak kullanıyoruz.
Gerçek yatırım getirisi hesabı: bir başa baş modeli
Otomasyon kararlarının çoğu saf bir hesapla verilir: çalıştırma başına kazanılan dakika, çarpı yıllık çalıştırma sayısı, eksi kurulum süresi. Tablo 2, yaygın beş bilgi işi otomasyonunu üç ek terimle yeniden hesaplıyor: çalıştırma başına doğrulama dakikası, manuel işlem süresiyle birlikte bir istisna oranı ve aylık bakım saati. Girdiler ölçüm değil, küçük bir ekip için gerçekçi olacak şekilde seçilmiş açıklayıcı varsayımlardır; önemli olan sonucun şeklidir ve hesabı kendi rakamlarınızla yeniden yapabilirsiniz.
Tablo 2. CEOtudent hesaplaması: beş otomasyonun saf ve gerçek ilk yıl getirisi (saat)
| Otomasyon | Çalıştırma başına kazanılan dakika | Yıllık çalıştırma | Kurulum saati | Saf brüt kazanç | Saf 1. yıl neti | Gizli maliyetler (brütteki payı) | Gerçek 1. yıl neti | Saf başa baş (hafta) | Gerçek başa baş (hafta) |
|---|---|---|---|---|---|---|---|---|---|
| Haftalık rapor derleme | 45 | 52 | 6 | 39,0 | +33,0 | 23,3 (%60) | +9,7 | 8,0 | 19,8 |
| Günlük gelen kutusu triyajı | 10 | 260 | 8 | 43,3 | +35,3 | 51,1 (%118) | -15,8 | 9,6 | asla |
| Aylık fatura mutabakatı | 120 | 12 | 12 | 24,0 | +12,0 | 20,4 (%85) | -8,4 | 26,0 | 173,3 |
| Potansiyel müşteri başına CRM zenginleştirme | 3 | 2.080 | 10 | 104,0 | +94,0 | 88,0 (%85) | +6,0 | 5,0 | 32,5 |
| Üç aylık yönetim kurulu dosyası biçimlendirme | 90 | 4 | 10 | 6,0 | -4,0 | 8,3 (%139) | -12,3 | 86,7 | asla |
Varsayımlar (çalıştırma başına doğrulama dakikası / istisna oranı x istisna başına manuel dakika / aylık bakım saati): haftalık rapor 10 / %10 x 30 / 1; gelen kutusu triyajı 4 / %15 x 15 / 2; fatura mutabakatı 30 / %20 x 60 / 1; CRM zenginleştirme 1 / %5 x 10 / 3; yönetim kurulu dosyası 20 / %25 x 60 / 0,5. Gizli maliyetler = yıllık doğrulama + istisnalar + bakım. Gerçek başa baş = kurulum saatinin yıllık tekrarlayan net kazanca bölümü, çarpı 52; “asla”, tekrarlayan net kazancın sıfır ya da negatif olduğu anlamına gelir.
Dört örüntü öne çıkıyor.
- Biri hariç her saf hesap bir kazanç gibi görünüyordu. Beş otomasyondan dördü saf yöntemde pozitif bir ilk yıl neti gösteriyor. Gerçek yöntemde yalnızca ikisi pozitif kalıyor ve ikisi de keskin biçimde küçülüyor: haftalık rapor +33,0’dan +9,7 saate, CRM zenginleştirme ise +94,0’dan +6,0 saate düşüyor.
- Yüksek sıklık gürültülü bir görevi kurtarmaz. Gelen kutusu triyajı yılda 260 kez çalışıyor ve her seferinde 10 dakika kazandırıyor; ama çalıştırma başına dört dakikalık kontrol, %15’lik istisna oranı ve ayda iki saatlik kural düzeltme, brüt kazancın %118’ini tüketiyor. Kendini hiçbir zaman amorti etmiyor.
- Düşük sıklık artı yüksek kurulum maliyeti klasik tuzaktır. Üç aylık yönetim kurulu dosyası saf yöntemde bile kendini amorti edemiyor ve her çalıştırmada dörtte bir ihtimalle bir saatlik manuel kurtarma gerekiyor.
- Belirleyici terim bakımdır. Fatura otomasyonu, esas olarak yalnızca 24 saatlik brüt kazanca karşı yılda 12 saatlik bakım yüzünden, altı aylık saf geri dönüş süresinden üç yılı aşkın bir süreye çıkıyor.
Tablo 3, sağlam bir otomasyonun bile insanların en sık atladığı iki gizli terime ne kadar duyarlı olduğunu gösteriyor.
Tablo 3. CEOtudent hesaplaması: haftalık rapor otomasyonu için bakım ve doğrulama yüküne göre ilk yıl gerçek net saat
| Aylık bakım saati | Çalıştırma başına 0 dk kontrol | 10 dk | 20 dk | 30 dk |
|---|---|---|---|---|
| 0 | +30,4 | +21,7 | +13,1 | +4,4 |
| 0,5 | +24,4 | +15,7 | +7,1 | -1,6 |
| 1 | +18,4 | +9,7 | +1,1 | -7,6 |
| 2 | +6,4 | -2,3 | -10,9 | -19,6 |
| 3 | -5,6 | -14,3 | -22,9 | -31,6 |
Çalıştırma başına 45 dakika kazanç, yılda 52 çalıştırma, 6 kurulum saati ve her biri 30 dakika süren %10’luk istisna oranı sabit tutulmuştur.
Aynı otomasyon, iş gerekçelerinde nadiren yer alan iki rakama bağlı olarak 30 saatlik kazançtan 32 saatlik kayba kadar uzanan bir aralıkta sonuç veriyor. Bunları henüz tahmin edemiyorsanız, süreci otomatikleştirecek kadar iyi tanımıyorsunuz demektir. Aşağıdaki argümanın özü de budur.
Otomasyon borcunun altı bileşeni
Borcun birden fazla kaynağı var. Tablo 4, kullandığımız bileşenleri, her birinin gündelik işte nasıl göründüğünü ve her birinin yankılandığı araştırmayı adlandırıyor.
Tablo 4. CEOtudent editöryel çerçevesi: otomasyon borcunun altı bileşeni
| Bileşen | Ne birikir | Erken uyarı işareti | Araştırmadaki yankısı |
|---|---|---|---|
| 1. Bakım borcu | Girdiler, araçlar, API’ler, istemler ya da modeller değiştiğinde yapılan onarımlar | “Yine bozuldu” cümlesi sohbette çeyrekte bir kereden fazla geçiyor | Sculley et al.: yapıştırıcı kod ve “Changing Anything Changes Everything” |
| 2. İstisna borcu | Otomasyonun işleyemediği durumların manuel olarak ele alınması | Kimsenin boşaltmadığı, büyüyen bir “incelenecek” klasörü | Bainbridge: operatöre, tasarımcının otomatikleştiremediği görevler kalır |
| 3. Doğrulama borcu | Neredeyse doğru olan çıktıyı kontrol etmeye harcanan zaman | Her çıktıyı “ne olur ne olmaz” diye yeniden okuyorsunuz | METR: üretimlerin %44’ünden azı kabul edildi, sürenin yaklaşık %9’u incelemeye gitti |
| 4. Bağımlılık borcu | Gizli bağlantılar: başka akışlar ya da kişiler çıktıya güvenmeye başlar | Durduğunda hiç beklemediğiniz biri şikâyet ediyor | Sculley et al.: beyan edilmemiş tüketiciler ve gizli geri besleme döngüleri |
| 5. Beceri borcu | Görevi elle yapma, değerlendirme ya da kurtarma yeteneğinin aşınması | Otomasyon çöktüğünde görevi kimse elle yapamıyor | Bainbridge: kullanılmayan beceriler körelir; Stack Overflow 2025: %20’si kendi problem çözme becerisine daha az güveniyor |
| 6. Sahiplik borcu | Adı belli bir sahip yok, bütçe yok, emeklilik tarihi yok | Sessizce çökse kimin fark edeceğini söyleyemiyorsunuz | Parasuraman ve Riley: tasarımcılar ve yöneticiler tarafından otomasyonun “kötüye kullanımı” |
Bunlardan ikisi daha fazla ilgiyi hak ediyor, çünkü en az görünür olanlar onlar.
Beceri borcu, otomasyonun kalbindeki ironidir. Lisanne Bainbridge, Automatica‘da yayımlanan 1983 tarihli “Ironies of Automation” makalesinde bu tezi üretken yapay zekadan kırk yıl önce ortaya koydu. Bir süreci otomatikleştirmek insana genellikle iki iş bırakır: otomatik sistemin çalıştığını izlemek ve çalışmadığında kontrolü devralmak. Ancak kontrolü devralmak, bir kişi yalnızca izlediğinde körelen becerilerin ta kendisini gerektirir: fiziksel beceriler kullanılmadığında zayıflar, olağandışı durumlar için gereken bilgi de ancak kullanım ve geri bildirimle gelişir. Bainbridge, dikkat araştırmalarına dayanarak, son derece motive bir kişinin bile çok az şeyin olduğu bir kaynağa yaklaşık yarım saatten uzun süre etkili dikkat veremeyeceğini de not etti. Onun ironisi şu: otomasyon ne kadar gelişmişse, insan katkısı tam da o insanın en az pratik yaptığı anda o kadar kritik hale gelebilir.
Sahiplik borcu, yönetimin hata yaptığı yerdir. Raja Parasuraman ve Victor Riley, Human Factors‘ta yayımlanan 1997 tarihli makalelerinde insanların otomasyonla kurduğu dört ilişki biçimini birbirinden ayırdı. Özetlerinde belirttikleri gibi yanlış kullanım aşırı güvendir ve izleme hatalarına ve karar önyargılarına yol açar; kullanmama ihmaldir ve çoğunlukla yanlış alarmlardan kaynaklanır; kötüye kullanım ise işlevleri “insan performansı üzerindeki sonuçları gereğince gözetmeden” otomatikleştirmektir ve insanların rollerini otomasyonun yan ürünleri olarak tanımlar. Bir yönetici ya da tek başına çalışan biri için en ilgili olanı kötüye kullanımdır: bir araç mümkün kıldığı için otomatikleştirmek, sonra da geride kalan kişinin istisnaları ve kontrolü üstleneceğini varsaymak.
Şimdi Otomatikleştir / Bekle / Asla puan kartı
Aşağıdaki karar kuralı altı bileşeni bir puanlama kontrol listesine dönüştürüyor. Herhangi bir şey kurmadan önce her soruyu 0, 1 ya da 2 ile puanlayın.
Tablo 5. CEOtudent editöryel çerçevesi: otomasyon borcu puan kartı
| Soru | 0 puan | 1 puan | 2 puan |
|---|---|---|---|
| Sıklık: görev ne sıklıkla çalışıyor? | Ayda birden az | Ayda 1 ila 8 kez | Ayda 8 kereden fazla |
| İstikrar: süreç son 3 ayda değişti mi? | Değişti ve yazıya dökülmedi | İstikrarlı ama belgelenmemiş | İstikrarlı ve bir SOP olarak yazılmış |
| Doğrulama: tek bir çıktıyı kontrol etmek, görevi elle yapmaya göre ne kadar sürüyor? | %30’un üzerinde | %10 ile %30 arası | %10’un altında |
| İstisnalar: çalıştırmaların ne kadarı bir insana ihtiyaç duyuyor? | %20’nin üzerinde | %5 ile %20 arası | %5’in altında |
| Hata maliyeti: çıktı sessizce yanlış olursa ne olur? | Bir müşteriye, düzenleyiciye ya da ödemeye ulaşır | Sonraki aşamada bir bedelle yakalanır | Ucuza ve zararsızca yakalanır |
| Sahiplik: bakım zamanı ayrılmış, adı belli bir sahip var mı? | Kimse yok | Sahip var ama zaman ayrılmamış | Adı belli sahip, ayrılmış zaman, belirlenmiş gözden geçirme tarihi |
| Beceri: biri görevi hâlâ elle yapabiliyor ve değerlendirebiliyor mu? | Kimse yapamaz | Bir kişi, pratiği kalmamış | Evet ve beceri kullanılarak canlı tutuluyor |
Karar kuralı (en fazla 14 puan):
- Şimdi otomatikleştir: 10 puan veya üzeri ve Hata maliyeti ya da Sahiplik’te sıfır yok.
- Bekle ve öğren: 6 ila 9 puan ya da İstikrar veya Sahiplik’te herhangi bir sıfır. Görevi birkaç kez daha elle yürütün, prosedürü yazıya dökün, doğrulama süresini ve istisna oranını ölçün, bir sahip belirleyin, sonra yeniden puanlayın.
- Asla (şimdilik): 5 puan veya altı ya da hem Hata maliyeti hem de Doğrulama’da sıfır. Bunlar hataların pahalı ve fark edilmesi zor olduğu görevlerdir: işi bir insan yapmaya devam etsin, araçları yalnızca yardımcı olarak kullanın.
İki tasarım tercihi bilinçli. Birincisi, Sahiplik ve Hata maliyeti veto işlevi görür, çünkü yüksek bir toplam puan, kimsenin bakımını yapmadığı bir otomasyonu ya da bir müşteriye ulaşan sessiz hataları telafi edemez. İkincisi, süreç yazıya döküldüğünde İstikrar daha yüksek puan alır, çünkü tarif edemediğiniz bir süreci doğrulayamazsınız. İşi henüz haritalamadıysanız 7 adımlı iş akışı denetimiyle başlayın ve sonucu SOP rönesansı yazısındaki yaklaşımla yazılı bir prosedüre dönüştürün. Puan kartı, hangi bilgi işi görevlerinin önce otomatikleştirileceğine dair 80/20 kuralı gibi bir önceliklendirme yönteminin yerini almaz, onu tamamlar: 80/20 merceği değerin nerede olduğunu, borç puan kartı ise o değeri tahsil edip edemeyeceğinizi söyler.
CEO+Öğrenci merceği: otomatikleştirmeden önce süreci öğrenin
Bir CEO, işletme maliyetini sormadan bir yatırımı onaylamaz. Otomasyon, işletme maliyeti olan bir yatırımdır ve sahibin işi bu maliyetlerin tamamını görmektir: teklifteki kurulum saatlerini, başka birinin masasına düşen kontrol ve onarım saatlerini ve görevi artık kimse pratik etmezse organizasyonun kaybettiği yetkinliği. Sahip düzeyinde muhakeme, her otomasyon teklifinin yanıtlaması gereken üç soruyu sormak demektir:
- Onu kim, nasıl kontrol ediyor ve bu ne kadar sürüyor? Yanıt “kimse” ya da “bakarız” ise doğrulama borcu fiyatlanmamıştır. Kontrol noktalarını bilinçli olarak yerleştirmek bir tasarım işidir ve tasarım gereği insan denetimi yazısında ele alınıyor.
- Bozulduğunda sahibi kim ve onu tutup tutmayacağımızı ne zaman gözden geçireceğiz? Gözden geçirme tarihi olmayan bir otomasyon, iptal düğmesi olmayan bir abonelikten farksızdır.
- Becerimize ne oluyor? Fiyatlama, işe alım, müşteri danışmanlığı ya da editörlük gibi muhakemenin ürünün kendisi olduğu bir görevse, görevin tamamını otomatikleştirmek, çıktıyı değerlendirmek için gereken uzmanlığı tüketir.
Tezin öğrenci yarısı pratik bir savunma sunuyor. Otomasyon borcundan kaçınmanın en güvenilir yolu, bir süreci otomatikleştirmeden önce elle anlamaktır: istisnalarını tanıyacak kadar çok yapın, kontrol adımının süresini ölçün, prosedürü yazıya dökün ve ancak ondan sonra karar verin. METR geliştiricilerinin yıllara dayanan depo deneyimi vardı ve yine de şaşırdılar; bir süreci iki kez yürütmüş biri olarak otomatikleştiren birinin elinde çok daha azı vardır. Önce öğrenmek, Bainbridge’in ironisine karşı da koruma sağlar. İşi kendiniz yaptıysanız ve ara sıra yapmaya devam ediyorsanız, otomasyonun çıktısını hâlâ değerlendirebilir ve çöktüğünde onu kurtarabilirsiniz. Bu muhakemeyi geliştirmek başlı başına bir beceridir ve yapay zeka çıktısını değerlendirme becerisi yazısında anlatılıyor.
Fırsat gerçek: Tablo 2’de beş otomasyondan ikisi hâlâ bir yıl içinde kendini amorti ediyor. İstikrarlı, sık ve kontrolü ucuz görevler, otomasyonun kendi masrafını çıkardığı yerlerdir. Kazananlar varsayılmaz, seçilir.
Hâlihazırdaki otomasyon borcunuzu nasıl ödersiniz
Bu yazıyı okuyanların çoğu zaten otomasyonlar çalıştırıyor. Dört adımlık üç aylık bir gözden geçirme, bakiyeyi kontrol altında tutar:
- Envanter. E-posta kuralları, zamanlanmış betikler, yapay zeka ajanları ve kodsuz akışlar dahil her otomasyonu listeleyin. Her birinin yanına sahibini ve birinin onun çalıştığını en son kontrol ettiği tarihi yazın. Boş hücreler sahiplik borcudur.
- Faizi ölçün. Tipik bir hafta boyunca her otomasyon için çıktıları kontrol etmeye, istisnaları ele almaya ve bozulanları düzeltmeye harcanan dakikaları kaydedin. Bu rakamları Tablo 2’deki formüle yerleştirin.
- Yeniden yapılandırın ya da emekliye ayırın. Artık kendini amorti etmeyen otomasyonların üç seçeneği var: sadeleştirmek (daha az adım, daha az bağımlılık), güvenilir çalıştıkları durumlarla sınırlayıp geri kalanını bir insana yönlendirmek ya da kapatmak. Kazandırdığından fazlasına mal olan bir otomasyonu kapatmak başarısızlık değil, kazançtır.
- Beceriyi sıcak tutun. Kritik olan her şey için sahibin görevi zaman zaman elle yürütmesini sağlayın; böylece ihtiyaç duyulduğunda yedek plan hazır olur.
Bu gözden geçirme, yapılandırılmış bir iş gününün bakım katmanına doğal olarak oturur; nereye ait olduğunu görmek için 5 katmanlı yapay zeka iş akışı yapısına bakın.
Sık Sorulan Sorular
Otomasyon borcu nedir?
Otomasyon borcu, bir görevi otomatikleştirmenin yarattığı birikmiş gelecek iştir: çıktıları kontrol etmek, istisnaları ele almak, koşullar değiştiğinde otomasyonun bakımını yapmak, ona bağımlı olanları yönetmek ve otomasyon çöktüğünde ihtiyaç duyulan insan becerisini korumak. Ward Cunningham’ın teknik borç metaforunu koddan iş akışlarına genişleten bir CEOtudent çerçevesidir.
Otomasyon borcu her zaman kötü müdür?
Hayır. Finansal borç gibi, getirisi faizden büyükse ve biri onu düzenli olarak ödüyorsa sağlıklı bir tercih olabilir. Başa baş modelimizde haftalık rapor otomasyonu, tüm gizli maliyetlerden sonra bile ilk yılında net 9,7 saat kazandırıyor. Sorun, fiyatlanmamış ve sahipsiz borçtur.
Yapay zeka otomasyonu sorunu büyütüyor mu?
Büyütebilir, çünkü yapay zeka çıktısı çoğu zaman “neredeyse doğru”dur ve bu da doğrulama yükünü artırır. Stack Overflow 2025 anketinde geliştiricilerin %66’sı bunu bir hayal kırıklığı olarak gösterdi; METR denemesinde de geliştiriciler yapay zeka üretimlerinin %44’ünden azını kabul etti. Yapay zeka ayrıca otomasyon kurmayı hızlandırır, bu da fark etmeden borçlanmayı kolaylaştırır.
Bir otomasyonun kazandırdığından fazlasına mal olup olmadığını nasıl anlarım?
Bir haftalık kontrol, istisna işleme ve onarım süresini kaydedin, yıllığa çevirin ve kazanılan brüt süreden çıkarın. Tekrarlayan net sıfır ya da negatifse, Tablo 2’deki beş örnekten ikisinde olduğu gibi otomasyon kurulum süresini asla geri kazandırmaz.
Her süreci ustalıkla öğrenene kadar otomasyonu durdurmalı mıyım?
Hayır. Puan kartını kullanın: istikrarlı, sık, kontrolü ucuz ve adı belli bir sahibi olan görevler şimdi otomatikleştirilebilir. “Bekle” kategorisi yalnızca, kurmadan önce süreci elle öğrenmek, yazıya dökmek ve ölçmek anlamına gelir.
Kaynakça
- Becker, J., Rush, N., Barnes, B., and Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR. arXiv:2507.09089v2.
- Google Cloud DORA (2024). Accelerate State of DevOps Report 2024 (v. 2024.3).
- Stack Overflow (2025). 2025 Developer Survey, yapay zeka bölümü.
- Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F., and Dennison, D. (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems 28 (NeurIPS 2015).
- Bainbridge, L. (1983). Ironies of Automation. Automatica, 19(6), 775-779.
- Parasuraman, R., and Riley, V. (1997). Humans and Automation: Use, Misuse, Disuse, Abuse. Human Factors, 39(2), 230-253 (özet).
- Cunningham, W. (1992). The WyCash Portfolio Management System. OOPSLA ‘92 Experience Report.
Tablo 1, METR denemesi, DORA 2024 raporu ve Stack Overflow 2025 anketinden doğrulanmış rakamları aktarıyor. Tablo 2 ve 3, her tablonun altında belirtilen açıklayıcı girdi varsayımlarını kullanan CEOtudent hesaplamalarıdır; her hücre bir betikle hesaplanmış ve bağımsız olarak yeniden kontrol edilmiştir. Tablo 4 ve 5, CEOtudent editöryel çerçevesidir; Tablo 4’teki araştırma yankıları ilgili bulgulara işaret eder, çerçevenin doğrulandığı anlamına gelmez.
Bu içerik, derinlemesine bir araştırmanın ardından yapay zeka desteğiyle derlenmiş ve CEOtudent editör ekibi tarafından yazılıp yayına hazırlanmıştır.
