# AI İşi Yaparken İnsan Sürecin Neresinde Olmalı?

> İnsan yalnızca brief'i yazıp son çıktıyı kontrol etmemeli; AI kod, doküman veya analiz üretirken sürecin tamamında nasıl yer almalı?

> 💡 **Özet: Ana Çıkarımlar**
> - **Bir iş tanımı uygulamadan önce tamamlanmaz.** Kod, doküman veya analiz üzerinde çalışırken ilk talepte görünmeyen kararlar ortaya çıkar.
> - **AI “nasıl”ı hızlandırabilir. “Ne” ile “nasıl” arasındaki geri bildirimi ise kendiliğinden korumaz.** İnsan brief'i yazıp son çıktıyı onaylamakla yetiniyorsa uygulama sırasında öğrenilenler şirkete geri dönmez.
> - **Giriş seviyesi işleri azaltmak gelecekteki muhakeme kapasitesini de etkileyebilir.** Daha az deneyimli çalışanları gerçek senaryo, kaynak, veri tanımı, istisna ve sonuç incelemesinin içine almak gerekir.

AI işi yaparken insanın rolü yalnızca başta brief yazmak ve sonda çıktıyı kontrol etmek olamaz. İşin ne olduğu, uygulama sırasında ortaya çıkan istisnalar, eksik tanımlar ve çelişen kurallar üzerinden netleşir. Bu yüzden insanın döngünün tamamında bulunması gerekir: soruyu kurarken, seçenekleri değerlendirirken, uygulamanın açığa çıkardığı yeni bilgiyi yorumlarken ve sonucu gerçek kullanım koşullarında sınarken.

![AI tarafından hazırlanan ekran ve testler yeni soruları görünür kılarken ekip gereksinimi yeniden değerlendiriyor](/images/inline-ai-human-in-the-loop/implementation-reveals-requirement.webp)

Bu yazıya yazılım geliştirmeden bir örnekle başlayacağım. Aynı mesele kapsamlı bir doküman hazırlanırken veya analiz sistemi kurulurken de ortaya çıkıyor; kod örneği yalnızca en görünür başlangıç noktası.

Şöyle bir proje düşünün. Bir ürün ekibinden, müşterinin üyeliğini uygulama içinden dondurabileceği bir ekran isteniyor. Brief'te form alanları, onay düğmesi ve gönderilecek e-posta yazıyor. Bir kodlama ajanı ekranı, servisi ve testleri kısa sürede hazırlıyor.

Sonra birkaç soru çıkıyor. Dondurma tarihi fatura döneminin ortasına gelirse ücret nasıl hesaplanacak? Müşterinin erişimi hemen mi kesilecek? Yeniden başladığında eski fiyatı korunacak mı? Açık siparişi bulunan bir hesap dondurulabilecek mi?

Bu sorular teknik temizlik listesinin dışında. Her biri ürünün müşteriye verdiği sözü, finans kayıtlarını ve destek sürecini değiştiren bir iş kararı. Uygulama biçimi üzerinde çalıştıkça, istenen işin ne olduğunu da yeniden öğreniyoruz.

AI kodu doğru ve hızlı yazsa bile bu öğrenme ihtiyacı ortadan kalkmıyor. Aynı mekanizma kapsamlı bir dokümanda veya geniş analiz yapan bir sistemde de çalışır. Dokümanın bölümlerini ve kanıtlarını kurarken hangi kararın henüz verilmediği görülür. Analiz sistemi veriyi bir araya getirirken şirketin aynı metriği farklı biçimlerde tanımladığı ortaya çıkar. AI işi üretirken açığa çıkan bu bilgi, işin kapsamını da değiştirebilir.

Şirket “ne”yi insanın belirlediği, “nasıl”ı yapay zekânın uyguladığı iki ayrı kutu gibi yönetirse en değerli geri bildirim yollarından birini kesebilir.

## AI işi yaparken gereksinim netleşir

Unmesh Joshi, Rebecca Parsons ve Martin Fowler, [LLM'ler ile “ne/nasıl” döngüsü üzerine konuşmalarında](https://martinfowler.com/articles/convo-what-how.html){.dofollow target="_blank" rel="noopener"} yazılım geliştirmeyi hazır gereksinimlerin programlama diline çevrilmesi olarak görmenin neden sorunlu olduğunu anlatıyor. Yazının ana konusu, değişime dayanabilen sistemler kurmak ve bunu mümkün kılan soyutlamaları geliştirmek.

Kaynağın doğrudan alanı yazılım geliştirme. Buradaki daha geniş yorum bir çıkarım: AI'ın üretim tercihleri çözülmemiş amaçları, tanımları ve çelişkileri açığa çıkarıyorsa benzer geri bildirim doküman ve analiz işlerinde de oluşabilir.

Fowler ve çalışma arkadaşlarının “ne/nasıl döngüsü” dediği fikir, gereksinimin uygulamadan önce tamamlanmış bir talimat olmadığını gösteriyor. Veri modeli, senaryo veya mevcut sistemin sınırları üzerinde çalışırken yapılması gereken işin kendisi de netleşiyor.

Bu konuşma, LLM kullanan ekiplerin daha başarılı olduğunu kanıtlayan bir araştırma değil. Üç deneyimli yazılım uygulayıcısının geliştirdiği bir tasarım yaklaşımı. Katkısı, uygulamanın kararı hayata geçirirken kararın daha doğru kurulmasına da yardım ettiğini görünür kılması.

Yazılımda bir senaryo, veri modeli veya test ilk tarifin yanlış sınır çizdiğini gösterebilir. Kapsamlı bir dokümanda bölüm yapısı ve kaynaklar, birbirini desteklemeyen iki hedefi ortaya çıkarabilir. Analiz sisteminde bir metriğin hesaplanma biçimi, yöneticilerin aynı soruya farklı cevap verdiğini gösterebilir.

Bir LLM bu döngüde seçenekleri hızla görünür kılabilir ve ilk sürümü ucuzlatabilir. Değer, ilk çıktının hızından çok o çıktı hazırlanırken öğrenilenlerin problem tanımına geri dönmesinde oluşur.

## Üç farklı çıktı, aynı öğrenme sorunu

Üyelik örneğinde ajan ekranı eksiksiz teslim edebilir. Fakat faturalama, erişim ve fiyat koruma kararları hâlâ açıktaysa çalışan yazılım yanlış iş kuralını sisteme yerleştirebilir. Müşterinin asıl sorunu dondurma seçeneğinin eksikliği yerine hatalı tahsilattan sonra destek alamamak da olabilir.

İnsan baştaki talebi yazıp sonda çalışan ekrana bakmakla yetindiğinde bu sinyaller kaybolur. Ajan makul varsayımlarla tutarlı kod üretebilir; iş açısından yanlış varsayım böylece daha hızlı sabitlenir.

Başka bir ekip, yönetim kurulu için yeni bir pazara giriş değerlendirmesi hazırlatıyor olsun. Brief; pazar büyüklüğü, rakipler, maliyetler, riskler ve bir öneri istiyor. AI kaynakları tarayıp kapsamlı bir doküman kurabilir. Bölümler bir araya geldiğinde ise pazar büyüklüğü verilerinin farklı ürün kategorilerini ölçtüğü, maliyet hesabının entegrasyon giderini dışarıda bıraktığı veya hukuki gerekliliklerin önerilen takvimle çeliştiği görülebilir.

Bu bulgular dipnot düzeyinde ayrıntılar değildir. Pazara girme kararını, bütçeyi veya zamanlamayı değiştirebilir. İnsan dokümanı yalnızca akıcılık ve biçim açısından incelerse tamamlanmamış kararlar düzenli bir raporun içinde görünmez hâle gelir.

Üçüncü bir ekip müşteri kaybını erken gösterecek bir analiz sistemi kuruyor olsun. AI, CRM, faturalama ve destek verilerini bir araya getiren akışı hazırlayabilir. Uygulama sırasında “müşteri kaybı”nın ekipler arasında aynı anlama gelmediği ortaya çıkabilir: Üyeliğini donduran, ödemesi başarısız olan ve daha düşük pakete geçen müşteriler aynı gruba mı girecek? Başlangıç tarihi sözleşme günü mü, ilk ödeme mi?

Sistem bu seçimleri kendi içinde tutarlı biçimde yapabilir. Hangi tanımın şirketin kararına hizmet ettiği ise iş muhakemesi gerektirir. Tanımı AI seçer ve insan yalnızca grafiği onaylarsa analiz doğru hesaplanmış olsa bile yanlış soruyu cevaplayabilir.

Bu örneklerde AI'dan önce yapılacak kullanıcı görüşmesi, kapsam çalışması, kaynak incelemesi veya veri tanımı işi bütünüyle değiştirebilir. Gerekli müdahale yeni yazılım ya da yeni bir AI sistemi olmayabilir. AI gerçekten kullanıldığında ise uygulama boyunca çıkan istisnaların ve çelişkilerin problem tanımına geri taşınması gerekir.

[Anlama borcu üzerine yazarken](/tr/anlama-borcu-fatura-tek-basina-gelir){target="_blank" rel="noopener"}, kod tabanının onu açıklayabilen zihinsel modelden daha hızlı büyümesini ele almıştım. Buradaki risk daha geniş. Şirket kodu, dokümanı veya analiz sistemini açıklayabilir ama bunlar hazırlanırken iş hakkında öğrenilebilecek şeyi yine de kaçırabilir.

## “İnsan döngüde” hangi işi yapıyor?

Birçok AI çalışma düzeni, insanı son kontrol noktasına koyuyor. Ajan işi yapıyor, insan inceliyor ve onaylıyor. Bu düzen güvenlik ve kalite için gerekli olabilir. İnsanın süreçteki rolü ise hâlâ belirsizdir.

İnsan hatalı kodu, dayanağı olmayan bir iddiayı veya yanıltıcı bir metriği yakalamakla sınırlıysa bir kontrol kapısıdır. Senaryoyu ya da soruyu kuruyor, uygulamanın açığa çıkardığı çelişkiyi değerlendiriyor ve problem tanımını değiştiriyorsa öğrenme döngüsünün parçasıdır.

Aradaki fark küçük görünür, fakat şirket açısından büyüktür. Kontrol kapısı bugünkü teslimatı korur. Öğrenme döngüsü, yarın gereksinim değiştiğinde doğru kararı verebilecek insan ve kurum bilgisini geliştirir.

![Daha az deneyimli çalışan ve deneyimli meslektaşı, AI çıktısını gerçek sonuçlarla birlikte değerlendirip öğrenilenleri bir sonraki soruya taşıyor](/images/inline-ai-human-in-the-loop/learning-loop-not-final-gate.webp)

Bir AI ajanının görevi tamamlayıp tamamladığı üretim ölçüsüdür. Öğrenme için şunların da kayda girmesi gerekir:

| Aşama | Kayda girmesi gereken bilgi |
| --- | --- |
| Başlangıç | Çözülmek istenen soru veya senaryo, değişmemesi gereken kurallar ve belirsiz varsayımlar |
| Uygulama | İstisnalar, çelişen kurallar, kaynak veya veri boşlukları ve seçilen temsilin iş üzerindeki etkisi |
| İnceleme | Çıktının neyi gösterdiği, hangi risklerin açık kaldığı ve insanın reddettiği seçenekler |
| Sonrası | Uygulama sırasında değişen problem tanımı ve sonraki değişiklik için korunacak gerekçe |

Kısa bir karar kaydı yeterlidir. Bütün ajan konuşmasını arşivlemek gerekmez. Amaç, ekibin “Bu çıktı nasıl üretildi?” sorusunun yanında “Bu işi artık neden böyle anlıyoruz?” sorusuna cevap verebilmesidir.

## Giriş seviyesi iş kaybının ikinci maliyeti

[Hiç açılmayan işe alımları ele aldığım yazıda](/tr/yapay-zeka-ve-hic-yapilmayan-ise-alimlar){target="_blank" rel="noopener"}, AI'ın bir çalışanı işten çıkarmadan da giriş seviyesindeki talebi azaltabileceğini anlatmıştım. Oradaki konu iş sayısıydı. “Ne/nasıl” döngüsü ikinci bir maliyeti gösteriyor: İşe girmeyen veya gerçek uygulamaya katılmayan insanlar, kıdemli muhakemenin oluştuğu deneyim yoluna da giremiyor.

Daha az deneyimli bir çalışan, çıktının çevresindeki kararları yaşayarak kıdem kazanır. Bir geliştirici veri modelinin sonraki özelliği neden zorlaştırdığını görür. Bir analist aynı müşterinin iki raporda neden farklı sınıflandırıldığını araştırır. Kapsamlı bir doküman hazırlayan kişi, güçlü görünen bir iddianın kaynaklarla neden taşınamadığını öğrenir. Zamanla “nasıl”daki işaretlerden “ne”deki hatayı okuyabilir hâle gelir.

AI destekli daha az deneyimli bir çalışan, sınırları belli bazı görevlerde kıdemli birinin çıktısına yaklaşabilir. [Deneyim farkını incelediğim yazıda](/tr/yapay-zeka-deneyim-farkini-nasil-degistiriyor){target="_blank" rel="noopener"} bu ihtimali ve alan bilgisiyle sonuç sorumluluğunun koruduğu sınırı ele almıştım. Yeni soru, o alan bilgisi ve muhakemenin gelecekte nereden geleceği.

Eski tekrarlı işleri sırf insanlar öğrensin diye korumanın anlamı yok. İnsanları AI'ın geride bıraktığı temizlik işine sıkıştırmak da deneyim üretmez. Daha az deneyimli çalışanların sorunun kurulmasına, kaynak ve veri seçimine, istisna kararına ve sonuç incelemesine katılması gerekir. AI üretimi hızlandırırken öğrenmenin ağırlık merkezi de buraya taşınmalı.

## İnsanları hangi işe hazırladığımızı değiştirmeliyiz

[Çalışanları AI için eğitmenin neden tek başına yetmediğini](/tr/yapay-zeka-isleri-degistirirse-yeniden-egitim-yetebilir-mi){target="_blank" rel="noopener"} incelerken önce yeni rolün tanımlanması gerektiğini savunmuştum. Yeni rolü “AI aracını iyi kullanan çalışan” diye tarif ettiğimizde öğrenme ve karar sorumluluğu açıkta kalır.

Yeni çalışma düzeninde insan, çıktının her parçasını elle üretmeyebilir. Fakat şu sorumluluklar görünür biçimde birine ait olmalı:

1. Çözülmek istenen soruyu ve iş sonucunu tarif etmek.
2. Varsayımları, kaynak boşluklarını ve veri tanımlarını görünür kılmak.
3. Üretim tercihinin iş kararını değiştirdiği yeri fark etmek.
4. Ajanın ürettiği seçenekleri alan bilgisi ve kanıtla değerlendirmek.
5. Çıktının gerçek kullanım koşullarındaki sınırlarını sınamak.
6. Uygulama sırasında öğrenilenleri problem tanımına geri taşımak.
7. Sonucun sorumluluğunu ve açık kalan riskleri üstlenmek.

Bu sorumlulukların tamamı birkaç kıdemli uzmana bırakılırsa yeni bir darboğaz oluşur. Uzmanlar hem bütün ajan çıktısını inceler hem bütün iş kararlarını taşır hem de daha az deneyimli insanları yetiştirmeye çalışır. Giriş seviyesindeki çalışanlar ise kararın kurulduğu yere hiç giremez.

Takım tasarımı bu nedenle teslimat kapasitesinden fazlasını düşünmeli. Daha az deneyimli bir çalışan bir kullanıcı senaryosunun, rapordaki bir iddianın veya analizdeki bir metrik tanımının sahipliğini alabilir. Ajanın önerisini hangi kanıtla kabul ettiğini açıklayabilir. Sonuç hatalı çıktığında düzeltmeyle birlikte ilk problem tanımının nerede eksik kaldığını da inceleyebilir.

## Bir sonraki AI projesinde neyi kayda almalı?

Üretilen çıktı, tamamlanan görev ve çevrim süresi kapasite hakkında bilgi verir. Öğrenme döngüsünün korunup korunmadığını başka sorular gösterir:

- Uygulama sırasında hangi iş varsayımı değişti?
- Bu değişikliği kim fark etti ve karar nerede kayda geçti?
- Ajanın seçtiği yapı, kaynak veya veri tanımı hangi kararı kolaylaştırıyor, hangisini zorlaştırıyor?
- Aynı çıktıyı iki ekip üyesi gerekçeleriyle açıklayabiliyor mu?
- Daha az deneyimli çalışanlar çıktı temizlemekle mi uğraşıyor, problem ve uygulama kararlarına da katılıyor mu?
- Bir sonraki benzer işte ekip neyi farklı yapacak?

Bu sorulara cevap yoksa hızlı teslimatın yanında ne kaybettiğimizi bilmiyoruz.

AI işi daha hızlı üretebilir; ama işin ne olduğunu öğrenme sorumluluğunu ortadan kaldırmaz. Kod, doküman veya analiz sistemi hazırlanırken ortaya çıkan istisnalar ve çelişkiler yalnızca çözülmesi gereken sorunlar değildir. Bunlar, şirketin problem tanımını düzeltmesi için ortaya çıkan geri bildirimlerdir.

İyi bir AI çalışma düzeni insanı brief'in başına ve çıktının sonuna yerleştirmez. İnsanlar uygulama sırasında neyin değiştiğini, bunun hangi kararı etkilediğini ve sonuçtan kimin sorumlu olduğunu birlikte değerlendirir. Böyle kurulduğunda AI yalnızca üretimi hızlandırmaz; şirketin daha doğru bir iş anlayışı geliştirmesine yardım eder. İnsan uygulamanın dışına çıkarsa geriye daha hızlı üretilmiş kod, doküman veya analiz kalır, fakat onu hangi gerekçeyle ürettiğini bilen organizasyon kalmaz.

---

Language: Turkish
License: CC BY 4.0
License URL: https://creativecommons.org/licenses/by/4.0/
Scope: Evren Bal-authored text, unless this article expressly states otherwise.
Excluded: Third-party material, quoted excerpts, logos, and separately marked images retain their own rights.
Attribution: Credit Evren Bal, link to the canonical source and license, and indicate changes.
Source: https://evrenbal.com/tr/ai-isi-yaparken-insan-surecin-neresinde-olmali