Yapay zeka çağında eleştirel düşünme (Critical Thinking)

• Yapay zekanın kod, tasarım ve yanıt ürettiği bir ortamda bile doğru soruları sorma ve varsayımları sorgulama becerisi olarak eleştirel düşünme, mühendislerin ve ekiplerin performansını belirleyen temel yetkinliktir
• Problem çözmenin tüm sürecinde Who·What·Where·When·Why·How olmak üzere altı sorudan yararlanarak insanları, problemi, bağlamı, zamanlamayı, nedenleri ve uygulama biçimini sistemli şekilde gözden geçirmek gerekir
• Yapay zeka yanıtları bir stajyerin önerdiği taslak gibi doğrulanması gereken bir çıktı olarak ele alınmalı; gerçek problem tanımı, kanıt toplama, bağlamı anlama, neden analizi ve iletişim sorumluluğu insanda kalmalıdır
• Zaman baskısı, önyargılar ve kulağa makul gelen yapay zeka yanıtları nedeniyle aceleci sonuçlara ve geçici yama türü çözümlere kaymak kolaydır; bunu önlemek için 5 Whys, deneyler ve veri doğrulama gibi kanıta dayalı düşünme pratikleri tekrar tekrar uygulanmalıdır
• Eleştirel düşünme, alçakgönüllü merakı ve kanıta verilen önemi benimseyen ekip kültürü içinde güçlenir; yapay zeka ne kadar gelişirse gelişsin, “doğru problemi, doğru nedenle, doğru şekilde çözmek” hâlâ insana özgü bir avantajdır

---

Yapay zeka çağında eleştirel düşünmeye genel bakış

• Yapay zekanın kod, tasarım ve yanıt ürettiği bu çağda insanın eleştirel düşünme becerisi eskisinden daha önemli hâle geliyor
  • Otomasyon ne kadar gelişirse gelişsin, doğru soruları sormak, varsayımları sorgulamak ve bağımsız düşünmek insana ait bir rol olarak kalıyor
  • Yanlış sorular ve yanlış tanımlanmış problemler üzerine kurulan yapay zeka çıktıları, projeleri daha hızlı biçimde yanlış yöne itebilir
• Eleştirel düşünme için Who·What·Where·When·Why·How çerçevesi kullanılarak somut uygulama ilkeleri sunuluyor
  • Her soru; problem tanımını, paydaşları, bağlamı, zamanlamayı, neden analizini ve uygulama/iletişim yöntemlerini gözden geçirmek için bir araç işlevi görüyor
  • Yapay zeka destekli ortamlarda bu altı başlığı kaçırmamak, proje başarısızlıklarını azaltmanın ve aşağı akıştaki sorunları önlemenin anahtarıdır

tl;dr: Yapay zeka ekipleri için eleştirel düşünme kontrol listesi

• Who: Yapay zekayı her şeyi bilen bir varlık değil, doğrulanması gereken bir girdi olarak görmek ve yanıtı kimin ürettiğini her zaman kontrol etmek gerekir
  • LLM yanıtlarını bir insan görüşüyle özdeşleştirmeden, kaynağı ve sorumluluğu ayrı değerlendiren bir bakış açısı gerekir
• What: Çözüme koşmadan önce gerçek problem tanımını ve başarı kriterlerini netleştirmek gerekir
  • Yüzeysel gereksinimler yerine, kullanıcı deneyimi ve veriye dayanarak gerçekten çözülmesi gereken problem açıkça tanımlanmalıdır
• Where: Çözümün uygulanacağı bağlam ve ortam (sandbox, production, kullanıcı cihazı vb.) dikkate alınmalıdır
  • Bir ortamda iyi çalışan çözümün başka bir ortamda yan etki yaratabileceği akılda tutulmalıdır
• When: Basit bir heuristic'in yeterli olduğu durumlarla derin analiz gerektiren durumları ayırt etmek gerekir
  • Acil yamalar ile kök neden analizinin zamanlamasını ayırarak, zaman baskısı altında bile asgari titizlik korunmalıdır
• Why / How: 5 Whys ile kök nedeni takip etmek ve iletişimde görüşler yerine veri ve kanıtı merkeze almak gerekir
  • İddialardan çok dayanakları, sezgiden çok deney ve ölçüm sonuçlarını öne çıkaran bir tutum gerekir

Who: Katılımcılar, sorumluluk ve etki alanı

• Problemi tanımlayan ve çözümüne katılan insanların ve bakış açılarının bileşimi (kim dahil, kim dışarıda) eleştirel düşünmenin başlangıç noktasıdır
  • Mühendis, PM, kullanıcı, alan uzmanı gibi paydaşlar belirlenmeli ve karar süreçlerine uygun biçimde dahil edilmelidir
  • Problemler çoğu zaman birden fazla ekibi ve kullanıcıyı etkilediği için, önce “kiminle görüşmeliyiz, kime haber vermeliyiz?” diye sormak gerekir
• Tek sesli fikir birliğinin yarattığı groupthink (grup düşüncesi) riskini azaltmak için farklı bakış açıları bilinçli biçimde sürece katılmalıdır
  • Karşıt görüşe ya da farklı bakış açısına sahip kişileri dışlamak, veri ve varsayımların doğruluğu test edilmeden bunların doğru kabul edilmesi riskini artırır
  • Dışarıdan bir bakış ya da ekip dışından birini davet edip probleme “taze gözle” bakmasını sağlamak da nesnelliği artırmanın bir yoludur
• Yapay zekanın yaygınlaşmasıyla birlikte “Bu kimin cevabı; insanın mı, yapay zekanın mı?” sorusunu ayırt eden bir bakış zorunlu hâle geldi
  • LLM yalnızca istatistiksel bir motordur; bu yüzden “bunu kim söyledi?”nden çok “hangi dayanakla söyledi?” sorulmalıdır
  • Yapay zeka kodu bir stajyerin kodu gibi ele alınmalı; inceleme, test ve bağlama uygunluk doğrulamasının sorumluluğu insanda olmalıdır
• Son aşamada sorumluluk ve etki alanı (kim sorumlu, kim etkilenecek) da birlikte düşünülmelidir
  • Acil bir yama bugün yöneticinin talebini karşılayabilir; ancak sonrasındaki bakım ve arıza yükü başka mühendislerin ya da kullanıcıların üzerine kalabilir
  • API değişikliğinin mobil uygulama ya da diğer mikroservisler üzerindeki etkisinde olduğu gibi, “bu kararın sonuçlarını kim üstlenecek?” sorusu her zaman hesaba katılmalıdır

What: Gerçek problem tanımı ve kanıt toplama

• Eleştirel düşünmenin özü, “gerçek problemin ne olduğunu” doğru tanımlamaktır
  • “Bir yapay zeka özetleme özelliği ekleyelim” gibi bir talep geldiğinde, önce amacın veri anlayışını artırmak mı, yorgunluğu azaltmak mı, yoksa başka bir şey mi olduğu sorulmalıdır
  • Kullanıcının yaşadığı zorluğun veri fazlalığı mı, görselleştirme eksikliği mi, yoksa açıklama yetersizliği mi olduğuna göre çözüm tamamen değişebilir
• Harvard Business Review'nun da vurguladığı gibi, problem tanımına yeterli zaman ayırmak yanlış probleme kaynak harcama riskini azaltır
  • Gereksinimler ve başarı kriterleri açıkça yazılmalı, “hangi durumda problemi çözmüş sayılacağız?” konusunda uzlaşılmalıdır
  • Doğrudan “problem çözme moduna” atlamaya yol açan plunging-in bias (aceleyle işe dalma önyargısı) bilinçli şekilde kontrol edilmelidir
• Belirtiler yerine somut olguları toplayan kanıta dayalı problem tanımı önemlidir
  • “Servis yavaş” ifadesi muğlaktır; hangi sayfanın, hangi sorgunun, hangi isteğin yavaş olduğunu verilerle daraltmak gerekir
  • “Neyin yavaş olduğu, neyin ne zamandan beri değiştiği, yakın zamanda neyin değiştirildiği” gibi sorularla log'lar ve metrikler incelenmelidir
• Bir çözüm ya da sonuca ilişkin olarak “bu sonucu destekleyen kanıt nedir?” sorusu tekrar tekrar sorulmalıdır
  • Yapay zeka nedeni null pointer olarak gösteriyorsa, bu log'lar, testler ve yeniden üretim deneyleriyle doğrudan doğrulanmalıdır
  • Bir performans iyileştirmesi iddia ediliyorsa, farklı ortamlarda ve farklı çalıştırmalarda metriklerin tutarlı biçimde iyileşip iyileşmediği kontrol edilmelidir
• LLM yanıtları çoğu zaman makul görünse de doğruluğu garanti edilmeyen hipotezler olarak ele alınmalıdır
  • İnsanlar “yeterince makul görünen” bir yanıt duyduğunda ek araştırmayı bırakma eğilimindedir; bu kombinasyon özellikle tehlikelidir
  • Eleştirel düşünme; yapay zekanın, ekip arkadaşlarının ve kişinin kendi fikirlerinin tümünü test edilmesi gereken hipotezler olarak görür ve yanlış olabilecekleri varsayımıyla başlar

Where: Bağlam, ortam ve kapsam farkındalığı

• Çözülmek istenen problemin ve çözümün nerede ortaya çıktığını ve nerede uygulanacağını (bağlamı) anlamak önemlidir
  • Belirli bir mikroservisteki CPU sıçramasının tüm sistem arızası sanılmasını önlemek için, sorunun doğduğu tam nokta bulunmalıdır
  • Kullanıcının akıllı telefonu, edge cihazı ya da cloud sunucusu gibi çalışma ortamlarına göre aynı kod bambaşka kısıtlara sahip olabilir
• Debug sürecinde istek akışını ve bileşen sınırlarını izleyerek “hata nerede oluşuyor?” sorusu daraltılmalıdır
  • Sorunun client, API gateway, backend ya da database'in hangi noktasında çıktığı log'lar ve izleme araçlarıyla ayrıştırılmalıdır
  • Özellik fikri tartışılırken de bunun kullanıcı yolculuğunun hangi aşamasını etkilediği ve kullanım sıklığının hangi bölümde yoğunlaştığı birlikte değerlendirilmelidir
• Deney ve dağıtımlarda da nerede test edileceği önemli bir karar unsurudur
  • Staging, şirket içi ortam ya da production trafiğinin bir bölümü gibi test konumuna göre elde edilecek güven düzeyi ve risk değişir
  • Gerçek kullanıcıların bir kısmına A/B testiyle gösterim yapmak, gerçek dünya sorunlarını hızlı bulmayı sağlayabilir; ancak etki alanını sınırlayacak korumalar da gerekir
• “Yan etkiler nerede ortaya çıkabilir, ne kadar yayılabilir?” sorusunu önceden hayal etmek deneyimli mühendisin ayırt edici özelliğidir
  • Ortak bir kütüphane değiştiğinde, bunu kullanan diğer servisler ve ekipler listelenmeli; sürüm çıkmadan önce bildirim ve test planı hazırlanmalıdır
  • Belirli bir modüldeki optimizasyonun başka modüllerde karmaşıklık artışı ya da veri formatı değişikliği gerektirip gerektirmediği gibi sistem çapındaki etkiler de birlikte gözden geçirilmelidir

When: Zaman ekseni ve derinlik seçimi

• Problemin ne zaman ortaya çıktığı ve ne zaman harekete geçildiği gibi “ne zaman” bilgisi, neden analizinde temel ipuçlarından biridir
  • “Sistemin en son ne zaman düzgün çalıştığı ve sonrasında nelerin değiştiği” bir zaman çizelgesi üzerinde düzenlenirse, neden daha hızlı daraltılabilir
  • Yeni deployment, gece batch işlemi ya da ayar değişikliği gibi belirli zaman olaylarıyla arıza zamanını ilişkilendirme alışkanlığı önemlidir
• Karar vermede ne zaman derine inileceğini ve ne zaman bir heuristic'in yeterli olacağını ayırt etmek, eleştirel düşünmenin ana boyutlarından biridir
  • Her probleme tam analiz uygulamaya çalışmak takvim ve kaynaklar açısından sürdürülemez olduğundan, analiz derinliği risk ve etkiye göre ayarlanmalıdır
  • Gece yarısı yaşanan bir incident'ta servis yeniden başlatma gibi kısa vadeli hafifletme adımlarıyla sistemi toparlayıp, kök nedeni mesai saatlerinde araştırmak gerçekçi bir stratejidir
• NASA örneğinde de işaret edildiği gibi, stres ve zaman baskısı altında insanın yargı hatası yapma olasılığı hızla yükselir
  • Hızlı karar gerektiren durumlarda bile, “neresi geçici önlem, neresi mutlaka yeniden gözden geçirilmeli?” noktaları önceden işaretlenmelidir
  • “Bu şimdilik geçici çözüm; sonra mutlaka neden analizi ve kalıcı önlem yapılacak” şeklinde not ya da ticket bırakmak bile uzun vadeli kaliteye katkı sağlar
• Sınırlı zaman içinde titizliği korumak için önceliklendirme ve triage kullanılmalıdır
  • En riskli varsayımlar önce test edilmeli, daha az önemli kararlar sonraya bırakılmalıdır
  • Yeni özellik tasarımında algoritmanın geçerliliği ve riski daha büyükse, UI detaylarından önce algoritma doğrulamasına zaman ayırmak gerekir
• Eleştirel düşünme, “yardım isteme zamanı”nı ve “durup yeniden düşünme zamanı”nı fark etme becerisiyle de bağlantılıdır
  • Belirli bir süre ilerleme yoksa başka birinin bakışını sürece katmak; sprint sonu ya da release öncesi gibi anlarda bilerek durup gözden geçirme noktaları koymak gerekir
  • Analiz felci ile aceleci sonuçlar arasında, mevcut karar için yeterli bilgi olup olmadığını kendine sorma alışkanlığı önemlidir

Why: Motivasyon, neden ve dayanakları derinleştirmek

• “Bunu neden yapıyoruz?” sorusunu tekrar tekrar sormak, anlamsız moda akımlarını ve taklitçiliği elemek, gerçek değere odaklanmak için bir filtre görevi görür
  • Yeni yapay zeka aracı kullanımı ya da özellik ekleme taleplerinde, bunun rakibi yakalama çabası mı yoksa gerçek kullanıcı sorununu çözme girişimi mi olduğu netleştirilmelidir
  • “Neden önemli?” sorusuna ikna edici bir yanıt verilebildiğinde, uygulama sürecindeki sayısız detay kararında tutarlılık korunabilir
• Bir problem ortaya çıktığında 5 Whys tekniği ile yüzeydeki nedenden daha derin kök nedenlere inmek önemlidir
  • Örneğin model doğruluğundaki düşüşte, veri dağılımı değişimi, yeni veri kaynağı eklenmesi, doğrulama eksikliği ve izleme yetersizliği gibi zincirleme nedenler adım adım takip edilmelidir
  • Nihai neden veri pipeline doğrulamasının eksikliği ya da izleme yokluğuysa, yalnızca yeniden eğitim yapmak problemi kökten çözmez
• “Why” sorularında insanlar doğrulama yanlılığına ve aceleci sonuçlara kolayca kapılır
  • Daha önce yaşanan bir memory leak gibi tanıdık bir nedene zihnin takılması, yeni ayar değişiklikleri ya da veri değişiklikleri gibi diğer olasılıkların göz ardı edilmesine yol açabilir
  • İlk akla gelen açıklamaya razı olmamak için, kişinin kendisine “başka hangi olası nedenler var, bunu çürüten bir kanıt var mı?” diye sorması gerekir
• Geçmiş şirket örneklerinde görüldüğü gibi, “neden”i yanlış anlamak, pazar payı kaybı ya da strateji başarısızlığı gibi sorunların uzun süre düzeltilememesine yol açabilir
  • Her şeyi dış etkenlere bağlayıp iç süreç, kalite ya da kültür sorunlarını görememek, yanlış reçetelerin tekrar edilmesine neden olur
• İyi mühendis, alçakgönüllü bir merakla “neden”i sorar ve kendi varsayımlarının yanlış olabileceğine açık kalır
  • Bir fikrin başarılı olacağına inanırken bile, “neden böyle düşündüğünü; bunun veri mi sezgi mi olduğunu” ayırır ve doğrulama yönünü buna göre belirler
  • Karardan sonra gerekçeleri belgelendirip paylaşarak, koşullar değiştiğinde önce dayanakların yeniden gözden geçirilmesini mümkün kılar

How: Uygulama yöntemi ve iletişim

• Eleştirel düşünmeyi günlük hayatta uygulamanın yolları soru sorma biçimi, kanıt doğrulama ve iletişimi yapılandırma olmak üzere üç eksende toplanır
  • Belirsiz “iyi mi kötü mü?” soruları yerine, “hangi kullanıcı ihtiyacını nasıl karşılıyor, nerede başarısız olabilir?” gibi somut ve açık uçlu sorular sorulmalıdır
  • Bilinenlerle bilinmeyenleri ayrı listelere yazmak ve bilinmeyenleri nasıl deneyip ölçeceğini planlamak önemli bir alışkanlıktır
• Kanıt değerlendirilirken alternatif yorum olasılığı ve önyargı karışıp karışmadığı da birlikte kontrol edilmelidir
  • Tek bir performans testi sonucunun tesadüf mü yoksa tekrarlanabilir mi olduğu, başka metriklerle çelişip çelişmediği çapraz doğrulamayla incelenmelidir
  • Kendi teorisini destekleyen verilerin yanı sıra, onu çürütebilecek verileri de özellikle aramak gerekir
• Ekip düzeyinde premortem gibi yöntemlerle olası başarısızlık senaryolarını önceden varsaymak da önerilir
  • Projenin başarısız olduğunu varsayıp nedenlerini yazmak, planlama aşamasında gözden kaçan riskleri ve gizli varsayımları görünür kılabilir
• Bir çözümü aktarırken mantığı problem tanımı (What·Why) → önerilen çözüm (How) → dayanak veri ve varsayımlar sırasıyla kurmak etkilidir
  • Ön kabulleri ve trade-off'ları açıkça yazmak, başkalarının fikri doğrulamasını ve geliştirmesini kolaylaştırır; aynı zamanda kişinin kendi mantık boşluklarını fark etmesine de yardım eder
  • “Sayfa yükleme süresi dashboard bazında ortalama %25 iyileşti” örneğinde olduğu gibi, görüşlerden çok ölçülebilir olguları önce sunmak güveni artırır
• Eleştirel düşünmenin iyi işlediği ortamlarda soruları ve itirazları memnuniyetle karşılayan bir iletişim kültürü oluşur
  • Bir öneriden sonra “bu mantıkta eksik kalan bir yer var mı, endişe duyulan bir nokta var mı?” diye ekip arkadaşlarına aktif biçimde sormak fikirleri olgunlaştırır
  • Tek yönlü sunumlar yerine, birden çok kişinin mantığı birlikte sınadığı süreç çözüm kalitesini yükselten bir mekanizma olur
• Bireysel düzeyde geriye dönük değerlendirme ve öğrenmeyle düşünme biçimini sürekli geliştirmek önemlidir
  • Aceleyle verilmiş bir karar bug'a yol açtıysa, sonrasında “nerede neyi kaçırdım, bir dahaki sefere neyi farklı yapacağım?” sorularını içeren kısa bir retro yapılmalıdır
  • Başka şirketlerin postmortem'lerini ve bilişsel önyargı materyallerini okuyarak, gelecekte kaçınılması gereken düşünme tuzaklarını önceden öğrenmek de faydalıdır

Sonuç: İnsana özgü bir avantaj olarak eleştirel düşünme

• Yapay zeka kullanımının artmasıyla birlikte, eleştirel düşünme artık bir tercih değil, temel bir yetkinlik hâline geliyor
  • Who·What·Where·When·Why·How ile insanları, problemleri, bağlamı, zamanlamayı, nedenleri ve uygulama biçimlerini sistemli şekilde gözden geçirmek gerekir
• Sağlıklı ekip kültürlerinde bağımsız düşünme ve soru sorma alışkanlığı doğal bir davranış olarak kabul edilir
  • “Bu gerçekten bir çözüm mü, yoksa geçici bir yama mı?”, “Kullanıcılar bu özelliği gerçekten istiyor mu?”, “Veri gerçekten iyileşme gösteriyor mu?” gibi soruları herkes sorabilmelidir
• Eleştirel düşünme, ekibi hızlı ama geçici çözümlerin cazibesinden korur
  • Problemi üstünü örterek kapatmak yerine, kök nedeni doğrulayıp sonra harekete geçmek uzun vadede zaman ve maliyet tasarrufu sağlar
• Yapay zeka ve otomasyonun tekrar eden işleri ve ilk taslakları üstlendiği bu dönemde bile, “doğru problemi doğru nedenle doğru şekilde çözmek” insanın görevi olarak kalıyor
  • Alçakgönüllü merakı ve kanıt merkezli düşünmeyi koruyan ekipler, yapay zeka çağında da istikrarlı biçimde iyi sonuçlar üreten ekipler olacaktır