Yazılım Ekiplerinde Yapay Zekâ Utancı: Mühendisler Neden Gizliyor

Yazılım mühendislerinin büyük çoğunluğu bir yapay zekâ asistanı kullanıyor ve önemli bir kısmı bunu kimseye söylemiyor. Slack’in 2024 sonbahar Workforce Index araştırmasına göre masa başı çalışanların %48’i, kod yazmak dahil gündelik işlerde yapay zekâ kullandığını yöneticisine söylemekten rahatsızlık duyacağını belirtiyor. DORA 2025 raporu ise yazılım profesyonelleri arasında yapay zekâ kullanımını %90 olarak ölçüyor. İki araştırma farklı kitleleri ölçüyor, ama aradaki boşluğun bir nedeni var. Görüşüm şu: yapay zekâ kullanımını gizlemek gerçek bir sosyal cezaya verilen akılcı bir tepkidir, dolayısıyla çözüm bireysel suçluluk değil, ekip normudur. Yargılanmayı hak eden yalnızca üç çizgi var: gönderilen koda sahip çıkmak, verinin onaylı araçların içinde kalması ve bir beceri ölçülürken dürüst davranmak. Geri kalan her şey araç meselesidir.

Mühendisler yapay zekâ kullanımını neden kendine saklıyor#

Slack anketi rahatsız olanlara nedenini de sormuş. En sık verilen yanıtlar sırasıyla şöyle: hile gibi hissettiriyor (%47), daha az yetkin görünme korkusu (%46), tembel görünme korkusu (%46). Şirket politikası %21 ile en sonda. Yani engel, düzenlemeden çok önce sosyal bir engel. Microsoft’un LinkedIn ile 31 ülkede 31.000 kişiyle yürüttüğü 2024 Work Trend Index de aynı yöne işaret ediyor. İşte yapay zekâ kullananların %52’si en önemli işlerinde kullandığını kabul etmeye isteksiz, %53’ü ise bunun kendisini kolay vazgeçilebilir gösterdiğinden endişeli.

Ethan Mollick bu örüntüye 2023’te bir ad verdi: gizli yapay zekâ kullanıcıları (Mollick’in deyimiyle “secret cyborgs”). Gayri resmi bir anket, üretken yapay zekâ kullananların yarısından fazlasının en azından bazen bunu kimseye söylemeden kullandığını gösteriyordu. Mollick üç neden sıralıyor: açık yasaklar, yapay zekâyla yazılmış işin farklı bir ölçütle değerlendirileceği kuşkusu ve görünür verimlilik artışının işten çıkarmaya davetiye çıkaracağı korkusu. Üçü de işin kalitesiyle ilgili değil.

Sorunun kökü araçlardan eski. Pek çok ekip mühendisi hâlâ görünür emekle değerlendiriyor: editörde geçen saatler, diff’teki satır sayısı, herkesin tanık olduğu uğraş. Bir asistan, emek ile çıktı arasındaki bağı koparıyor. O ölçüm sürdüğü sürece, bir işi yardım alarak bir öğleden sonrada bitiren mühendis ya yavaş ya da hile yapmış görünür. Sessizlik, üçüncü seçenek olarak kendiliğinden ortaya çıkar.

Kontrollü deneylerdeki ceza#

Korku hayal ürünü değil. Reif, Larrick ve Soll, 2025’te PNAS’ta toplam 4.439 katılımcıyla dört ön kayıtlı deney yayımladı. Yapay zekâdan yardım alanlar, bir insandan yardım alanlara ya da yardım kaynağı belirtilmeyenlere göre daha tembel, daha az yetkin ve daha az özenli bulundu. Etki yaş, cinsiyet ve meslekten bağımsız olarak sürdü ve işe alım kararlarına kadar uzandı. Kendisi nadiren yapay zekâ kullanan yöneticiler, her gün yapay zekâ kullandığı söylenen adayı işe almaya daha az istekliydi.

Aynı çalışmadaki iki sınır koşulu, liderler için ana bulgudan daha önemli. Haftada bir ya da her gün yapay zekâ kullanan değerlendiricilerde ceza anlamlı olmaktan çıktı. Sık kullanan yöneticiler, yine sık kullanan adayları tercih etti. Yargı, değerlendiricinin bir özelliği; bu da ekibin değiştirebileceği bir şey.

Beyanın kendi bedeli de var. Schilke ve Reimann’ın Organizational Behavior and Human Decision Processes dergisinde 2025’te yayımlanan 13 deneyi var. Yapay zekâ kullandığını açıklayanlara, açıklamayanlardan daha az güveniliyor; neden, işin daha az meşru görülmesi. Beyanın gönüllü ya da zorunlu olması fark yaratmadı; üçüncü bir kişi tarafından ifşa edilmek ise kendi beyanından daha kötü sonuç verdi. Dolayısıyla şeffaf olma tavsiyesi dürüst ama bedelli bir tavsiye. Ekip o bedeli üstlenmezse fatura bireye kesiliyor. Aynı bulgu gizlemeyi de uzun vadede kötü bir bahis yapıyor: kod incelemesi ile git geçmişi olan bir ekipte ifşa olasılığı yüksek ve ifşa daha pahalı.

Yapay zekâ destekli koda karşı en güçlü itiraz#

İtirazı yanıtlamadan önce en güçlü hâliyle dinlemek gerekiyor. Yazılım bir kavrama disiplinidir. Ghostty’nin yapay zekâ politikası şartı açıkça koyuyor: “The human-in-the-loop must fully understand all code.” (Döngüdeki insan, kodun tamamını eksiksiz anlamalıdır.) Yazar değişikliği açıklayamıyorsa kodu anlayan tek kişi inceleyici olur, çoğu zaman o da olmaz. Öz değerlendirme burada güvenilmez. METR’in 2025 başındaki randomize deneyinde 16 deneyimli açık kaynak geliştiricisi kendi depolarında 246 görev yaptı. Yapay zekâya izin verildiğinde %19 daha yavaştılar ama sonrasında %20 hızlandıklarına inanıyorlardı. Kendi hızını bu kadar yanlış ölçen biri kendi kavrayışını da yanlış ölçüyor olabilir. Maliyet de yer değiştiriyor. Stack Overflow’un 2025 anketinde yapay zekâ araçlarına dair en büyük şikâyet, neredeyse doğru ama tam doğru olmayan çözümler (%66); neredeyse doğru kodun üretimi ucuz, incelemesi pahalı. Son olarak junior mühendisler için beceri kaybı endişesi var: hiç çalıştırılmayan beceri gelişmez, asistan da o çalıştırmayı ortadan kaldırır.

Bu listedeki her madde doğru ve her madde sahiplik ile beyan lehine bir argüman. Hiçbiri utanç lehine değil. Utanç kullanımı yer altına iter ve dikkatli bir inceleyicinin tam da ihtiyaç duyduğu sinyali siler: hangi parçalar üretildi, hangileri yeniden yazıldı, yazarın kendi kavrayışı nerede en ince. Kavrama itirazının yanıtı bir inceleme sorusudur, örneğin yazardan retry yolunu anlatmasını istemek. O soru ancak inceleyici nereye soracağını bildiğinde işe yarar. Gizli kullanım o boşluğu da gizler; asistanın sağlayamayacağı yargı ise Phronesis ve yapay zekâ kodlama ajanları yazısının konusu.

Hız sayısının kendisi de ihtiyat istiyor. METR’in Şubat 2026 güncellemesi, yapay zekâsız çalışmak istemediği için çalışmaya katılmayı reddeden geliştiricilerin arttığını bildiriyor; bu, yeni verileri zayıflatıyor. METR, geliştiricilerin artık büyük olasılıkla yapay zekâyla hızlandığını düşünüyor; yine de hızlanmanın büyüklüğüne dair kendi kanıtını zayıf olarak niteliyor. Kalıcı bulgu, hissedilen hız ile ölçülen hız arasındaki fark.

İş etiğinin üç çizgisi#

Birini yapay zekâ kullandığı için yargılamak meşru mu? İşi üç çizgiye göre yargılayın. Kimse otomatik tamamlamayı, bir Stack Overflow yanıtını ya da IDE’nin refactor komutunu beyan etmez, çünkü kodun kaynağı inceleyiciye gereken hiçbir şeyi söylemez. İnceleyici ya da değerlendirici için işe yarayan soru, koda şu anda kimin sahip çıktığıdır. Bu çerçeve, devralınan kod için hesap verebilirlik ve suçlama yazısındaki çerçevenin aynısı: yazarlık geçmiştir, sahiplik şimdiki zamandır.

Birinci çizgi sahiplik. ACM/IEEE-CS Yazılım Mühendisliği Etik Kuralları, kişinin kendi işinin tam sorumluluğunu kabul etme görevini ilk maddesine (1.01) koyuyor; ACM Etik Kuralları (2.1) hem süreçte hem üründe yüksek kalite istiyor. Linux çekirdeğinin kodlama asistanları rehberi ilkeyi prosedüre çeviriyor. Yapay zekâ ajanı Signed-off-by satırı ekleyemez; üretilen kodun tamamını gönderen insan inceler ve katkının tam sorumluluğunu üstlenir. Açıklayamadığınız, savunamadığınız kodu göndermek mesleki bir kusurdur. Taslağını bir araçla çıkarmak kusur değildir.

İkinci çizgi veri sınırı. ACM Etik Kuralları 1.7 gizliliğe saygı, 2.3 ise mesleki çalışmaya ilişkin kuralları bilmeyi ve onlara uymayı istiyor. Şirkete ait kaynak kodu herkese açık bir sohbet botuna yapıştırmak ikisini de ihlal eder. Samsung 2023’te mühendisleri tam olarak bunu yapınca üretken yapay zekâ kullanımını kısıtlamak zorunda kaldı. Microsoft’un Work Trend Index raporuna göre yapay zekâ kullananların %78’i kendi araçlarını işe getiriyor; bu sayı, çizginin pratikte nerede koptuğunu söylüyor: ekip onaylı bir araç sunmuyorsa kişisel hesap varsayılan hâline geliyor. Yönetişim tarafı yapay zekâ kodlama araçları: güvenlik riskleri ve yönetişim yazısında ele alınıyor.

Üçüncü çizgi, neyin ölçüldüğünü dürüstçe temsil etmek. ACM Etik Kuralları 1.3, kişinin kendi nitelikleri dahil dürüst ve güvenilir olmasını istiyor. Somut hâliyle: bir mülakat, take-home ödevi ya da sertifika sınavı yardımsız beceriyi ölçüyorsa, yapay zekâyı sessizce kullanmak yanlış beyandır. Değerlendirme sonuçları ya da yapay zekâyla iş birliğini ölçüyorsa değildir. İki kural da meşru olabilir. Şart, her birinin açıkça söylenmesi.

Üç çizginin dışında kalan her şey (taslak çıkarmak, boilerplate, test iskeleti, yabancı bir API’yi anlamak) araç meselesidir ve varsayılan olarak kimseyi ilgilendirmez.

Bir yazılım ekibi ne yapabilir#

Yazılı bir tutum ve örnek olan lider#

DORA’nın AI Capabilities Model çalışması, yedi yetkinlik arasında açık ve iletilmiş bir yapay zekâ tutumunu ilk sıraya koyuyor. DORA’ya göre bu tutum, politikanın içeriği ne olursa olsun, yapay zekânın olumlu etkisini büyütüyor ve çalışanlar için sürtünmeyi azaltabiliyor. Slack’in verisi de aynı yöne bakıyor: yapay zekâ kullanımını paylaşmaktan rahatlık duyan çalışanların iş için yapay zekâ kullanmış olma olasılığı %67 daha yüksek. Onaylı araçları sayan, hangi verinin nereye gidebileceğini söyleyen ve yapay zekâ yardımının değerlendirmede hiçbir sonucu olmadığını belirten bir sayfa, gizlemeye yol açan tahmin yürütmenin çoğunu ortadan kaldırır.

Tutumun görünür bir sahibi olmalı. Reif’in deneylerinde ceza, haftada bir ya da her gün yapay zekâ kullanan değerlendiricilerde anlamlı olmaktan çıktı. O hâlde en ucuz müdahale, liderin herkesin gördüğü bir kanalda bu RFC’nin taslağını bir asistanın çıkardığını ve neyi değiştirdiğini söylemesi. O cümle, altındaki herkes için bedeli düşürür. Bedeli şu: liderler çoğunlukla yapay zekâyla parlatılmış metni beyan eder, yapay zekâyla üretilmiş kodu asla; sinyal yarım kalır. Beyan, mühendislerin gizlediği iş türünü de kapsamalı. O cümle, bir sonraki seviyenin kapısı olarak iletişim yazısında anlatılan türden bir iletişim eylemi.

İnceleme meta verisi olarak beyan#

Linux çekirdeğinin kuralı ürün ekipleri için çalışan bir model. Assisted-by etiketi yapay zekâ desteğini tek satırda kayda geçirir, sorumluluk olduğu gibi kalır. Ürün ekibindeki karşılığı, pull request şablonunda Yapay zekâ desteği başlığını taşıyan kısa, serbest metinli bir alan. Alan şunu sorar: hangi araç, diff’in hangi bölümleri ve yazarın neyi değiştirip neyi reddettiği. Boş bırakmak serbest. Tek amacı inceleme dikkatini yönlendirmek ve şablon bunu alanın kendi açıklama metninde söylemeli.

Genelleştirilmiş bir örnek nedenini gösteriyor. Bir mühendis veri migration’ının taslağını asistanla çıkarıyor, yarısına yakınını yeniden yazıyor ve PR açıklamasında ikisinden de söz etmiyor. İnceleyici retry yolunun düşünülerek yazıldığını varsayıyor, hafif bir bakıştan sonra onaylıyor ve asistanın uydurduğu bir koşul staging ortamına ulaşıyor. Üretilen bölümü adlandıran tek bir satır, inceleyicinin dikkatini gereken yere koyardı. İnceleme, meta veri eksik olduğu için kötü geçti. Yazarın sessizliği ise beyanın güvenli olduğunu hiç söylememiş bir ekibe verilen akılcı bir tepkiydi.

Alanın bozulduğu nokta, suçlama filtresine dönüşmesi. Yapay zekâ destekli PR’lar ekstra incelemeden geçerken diğerleri kolayca onaylanıyorsa insanlar alanı doldurmayı bırakır ve ekip gizli kullanıma geri döner. Önlem açık olmalı: alan inceleme odağını yönlendirir, değerlendirmede hiçbir zaman görünmez. Ghostty öbür uçta duruyor: dış katkıcılardan zorunlu beyan, bakımcılara muafiyet ve yapay zekâ çöpü (slop) gönderen katkıcıların herkese açık bir teşhir listesi. Beyanı kapı olarak kullanmak açık kaynaktaki spam baskısı altında savunulabilir; bir ürün ekibinin içinde ise güvensizlik olarak okunur.

Aşama aşama belirtilen işe alım kuralları#

Canva, kodlama mülakatlarında adayların yapay zekâ kullanmasında ısrar ediyor ve onunla nasıl iş birliği yaptıklarını değerlendiriyor. Anthropic’in aday rehberi ise bir aşama aksini söylemedikçe take-home ödevlerinde ve canlı mülakatlarda yapay zekâ istemiyor ve adaylardan şeffaflık bekliyor. Yapay zekâya açık iki şirket, iki zıt kural ve ikisi de aynı nedenle dürüst: her biri aşamanın neyi ölçtüğünü söylüyor. Bedeli, dürüst kuralların mülakat tasarımını değiştirmeyi gerektirmesi. Canva formatını yeniden kurdu. Kariyer sayfasında bir kez yazılıp mülakatın kendisinde hiç tekrarlanmayan kural, söylenmiş sayılmaz.

Yapay zekâ sorusu olmayan performans değerlendirmesi#

Shopify’ın notu “reflexive AI usage” (refleks hâline gelmiş yapay zekâ kullanımı) ilkesini temel beklenti yapıyor ve performans ile akran değerlendirmelerine yapay zekâ kullanımı soruları ekliyor. Niyet açık ve gizlemeyi gerçekten hızla bitiriyor. Benim önerim buna karşı. Kullanma eylemini notlamak göstermelik kullanım üretir. Bir görev için asistanın yanlış araç olduğuna karar veren mühendis yine de kullanma baskısı hisseder; değerlendirme sorusu da artık bir araç tercihine uyumu ölçer. Değerlendirme sonuçları, yargıyı ve bir değişikliği açıklayıp savunabilme becerisini notlamalı. Tek sert sınır üç çizgi olmalı. Bedeli, kalibrasyon. Sonuçları notlamak emek göstergelerini notlamaktan zordur. Sessiz bozulma, sonucun çıktı hacmine kayması; asistan hacmi bedavaya şişirir. Koruma, açıkla-ve-savun ölçütü, çünkü kavrayışsız hacim o ölçütten geçemez.

Varsayılanın geçerli olmadığı durumlar#

Ucuz, sonuçsuz beyan artı üç açık çizgi şeklindeki varsayılan, yapay zekâ kullanımının neredeyse evrensel olduğu ve kod incelemesinin rutin olduğu bir ürün ekibini varsayar. Ekibin, cezayı yeniden üreten küçük alışkanlıklardan da kaçındığını varsayar: PR alanını itiraf gibi ele almak, işe yarayan soru yazarın değişikliği açıklayıp açıklayamadığıyken kodun nereden geldiğini denetlemek ve kendi bildirilen hız artışlarını kanıt saymak. Üç durum varsayılanı geçersiz kılar. Yardımsız beceriyi açıkça ölçen değerlendirmelerde (mülakat, take-home ödevi, bazı sertifikalar) ya hiç kullanılmaz ya da teslimden önce beyan edilir. Araç kullanımını kısıtlayan ya da beyan gerektiren müşteri ve mevzuat sözleşmeleri ekip alışkanlığının önüne geçer. Çekirdek ya da Ghostty gibi kendi politikası olan açık kaynak projelerinde, katkıcının kendi ekibi ne yaparsa yapsın, projenin kuralı uygulanır. Bu üçünün dışında, birinin yapay zekâ kullanıp kullanmadığı inceleme meta verisi olarak kalır; yargı ise neyin gönderildiğine, verinin nereye gittiğine ve neyin iddia edildiğine saklanır. Bir lider için makul ilk adım, tek satırlık beyanı kendi bir sonraki pull request’ine koymak ve ekibin ardından ne yaptığını izlemek.

Kaynaklar#

• Evidence of a social evaluation penalty for using AI (PNAS, 2025) (yeni sekmede açılır) - Reif, Larrick ve Soll’un dört ön kayıtlı deneyi (N = 4.439): yapay zekâ kullananlar daha tembel ve daha az yetkin bulunuyor, etki işe alım kararlarına uzanıyor.
• Is AI Damaging Your Professional Image? (Duke Fuqua Insights) (yeni sekmede açılır) - PNAS çalışmasının sade dilli özeti; cezanın değerlendirici yapay zekâ kullandığında kaybolduğu bulgusunu da içeriyor.
• The transparency dilemma: How AI disclosure erodes trust (OBHDP, 2025) (yeni sekmede açılır) - Schilke ve Reimann’ın 13 deneyi: beyan, algılanan meşruiyet üzerinden güveni düşürüyor ve üçüncü kişi tarafından ifşa, kendi beyanından daha kötü.
• Detecting the Secret Cyborgs (One Useful Thing) (yeni sekmede açılır) - Ethan Mollick’in yapay zekâyı kimseye söylemeden kullanan çalışanları adlandıran yazısı; nedenler ve kurumlara öneriler.
• The Fall 2024 Workforce Index (Slack) (yeni sekmede açılır) - 17.372 masa başı çalışanla anket: %48 yöneticisine yapay zekâ kullandığını söylemekten rahatsız, nedenleri ve %67’lik rahatlık-kullanım bağı.
• AI at Work Is Here. Now Comes the Hard Part (Microsoft Work Trend Index 2024) (yeni sekmede açılır) - Microsoft ve LinkedIn’in raporu: kendi aracını getirme (%78) ve önemli işlerde kullanımı kabul etme isteksizliği (%52).
• 2025 Stack Overflow Developer Survey: AI (yeni sekmede açılır) - Geliştirici benimsemesi (%84), profesyoneller arasında günlük kullanım (%51) ve “neredeyse doğru” şikâyeti (%66).
• How are developers using AI? Inside our 2025 DORA report (Google) (yeni sekmede açılır) - Yazılım profesyonelleri arasında %90 yapay zekâ benimsemesi ve beraberinde gelen güven bölünmesi.
• Introducing DORA’s inaugural AI Capabilities Model (Google Cloud) (yeni sekmede açılır) - Yedi yetkinlik; başında, politikanın içeriğinden bağımsız olarak sürtünmeyi azaltan açık ve iletilmiş yapay zekâ tutumu.
• Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (METR) (yeni sekmede açılır) - Geliştiricilerin yapay zekâyla %19 yavaşlarken %20 hızlandıklarına inandığı randomize deney.
• We are Changing our Developer Productivity Experiment Design (METR) (yeni sekmede açılır) - Yeni verilerin neden zayıf olduğunu açıklayan devam yazısı; yapay zekâsız çalışmayı reddeden geliştiriciler dahil.
• AI Coding Assistants (Linux kernel documentation) (yeni sekmede açılır) - Çekirdek kuralları: ajandan Signed-off-by yok, tam insan sorumluluğu ve Assisted-by etiketi.
• Ghostty AI Policy (yeni sekmede açılır) - Dış katkıcılardan yapay zekâ kullanımının beyanını ve gönderilen kodun eksiksiz anlaşılmasını isteyen açık kaynak politikası.
• Yes, You Can Use AI in Our Interviews. In fact, we insist (Canva Engineering) (yeni sekmede açılır) - Canva’nın kodlama mülakatlarında neden yapay zekâ istediği ve ortaya çıkan kodun tam sahipliğini beklediği.
• How to collaborate with Claude during our hiring process (Anthropic) (yeni sekmede açılır) - Aşama aşama kurallar: hazırlık ve düzeltme için yapay zekâ serbest, aksi belirtilmedikçe take-home ve canlı mülakatta yok.
• Reflexive AI usage (Shopify) (yeni sekmede açılır) - Tobi Lütke’nin yapay zekâ kullanımını temel beklenti yapan ve performans ile akran değerlendirmelerine ekleyen notu.
• ACM Code of Ethics and Professional Conduct (yeni sekmede açılır) - Dürüstlük (1.3), gizlilik (1.7), iş kalitesi (2.1) ve mesleki çalışma kurallarına uyum (2.3) ilkeleri.
• Software Engineering Code of Ethics and Professional Practice (ACM/IEEE-CS) (yeni sekmede açılır) - İlk maddesi mühendislerden kendi işlerinin tam sorumluluğunu kabul etmelerini isteyen ortak etik kuralları.
• Samsung puts ChatGPT back in the box after ‘code leak’ (The Register) (yeni sekmede açılır) - Mühendislerin şirket kodunu herkese açık bir sohbet botuna yapıştırdığı, veri sınırı çizgisini gösteren vaka.