Ünite 12 / 12

AI Kodlama Araçları ve İş Akışı Entegrasyonu

Kazanimlar:

  • Editör tamamlaması, sohbet asistanı, CLI ajanı ve CI otomasyonu kategorilerini görevlere eşleyebilme
  • Özerklik seviyesini riske göre ayarlayıp CLI ajanlarına 'önce plan' disiplini uygulayabilme
  • AI kullanımını onaylı araç, doğrulama kapısı, şeffaflık ve sorumluluk üzerine kurulu bir ekip sistemine dönüştürebilme

Buraya kadar AI'yı tek tek görevlerde (kod yazma, inceleme, test, debugging) kullanmayı öğrendik. Bu son ünitede parçaları birleştiriyoruz: farklı AI kodlama araçlarını tanıyıp doğru işe doğru aracı eşleştirmek ve bunları günlük geliştirme akışınıza — editörden sürüm kontrolüne, CI/CD hattından ekip yönetişimine — güvenle yerleştirmek. Amaç, dağınık "ara sıra AI'ya sorma" alışkanlığını, tutarlı ve denetlenebilir bir çalışma sistemine dönüştürmektir.

Araç türlerini tarafsız kategorilerle ele alıyoruz (belirli ürün adları hızla değişir; önemli olan kategorinin ne yaptığıdır). Her kategorinin bir "tatlı noktası" ve bir risk profili vardır; ustalık, hangi görevde hangisine ne kadar özerklik vereceğinizi bilmektir.

AI Kodlama Araçlarının Kategorileri

1. Editör içi tamamlama. IDE'nizde (kod yazdığınız geliştirme ortamı) siz yazarken satır/blok öneren eklentiler. Tatlı nokta: akış içi hız, kalıp kod. Risk: dar bağlam, öneriyi düşünmeden kabul etme.

2. Sohbet/yan panel asistanı. IDE'ye gömülü, kod tabanınızın bir kısmını görebilen sohbet arayüzü. Tatlı nokta: açıklama, refactor, test, hata analizi. Risk: verdiğiniz bağlamla sınırlı, doğrulama gerektirir.

3. CLI ajanları (agentic tools). Komut satırından çalışan, birden çok dosyayı okuyup değiştirebilen, komut çalıştırabilen, çok adımlı görevleri kendi başına yürütebilen araçlar. Tatlı nokta: çok dosyalı değişiklikler, tekrar eden görevler, "şu özelliği ekle" türü işler. Risk: yüksek özerklik = yüksek etki; kontrolsüz bırakılırsa geniş ve doğrulaması zor değişiklikler üretir.

4. Hat/otomasyon entegrasyonu. PR'lara otomatik inceleme yorumu bırakan, test öneren veya changelog üreten CI (Continuous Integration — her değişikliği otomatik derleyip test eden hat) botları. Tatlı nokta: yorulmayan ilk süzgeç, tutarlılık. Risk: gürültü, sahte güven.

İpucu: Özerklik arttıkça denetim de artmalıdır. Editör tamamlaması küçük ve anlık olduğu için hafif denetlenir; bir CLI ajanının çok dosyalı değişikliği ise bir insan PR'ı gibi, hatta ondan daha dikkatli incelenmelidir.

Adım Adım: AI'yı İş Akışına Yerleştirmek

  1. Görevi araca eşleyin. Küçük akış içi ek → tamamlama; anlama/refactor/test → sohbet; çok dosyalı, tekrarlı iş → CLI ajanı; sürekli ilk süzgeç → CI entegrasyonu.
  2. Özerklik seviyesini seçin. Ajana ne kadar serbestlik? Salt-okunur öneri mi, yoksa dosya değiştirme + komut çalıştırma mı? Riske göre ayarlayın.
  3. Bağlamı besleyin. Proje kurallarını (stil, mimari, "yapma"lar) araca kalıcı olarak tanıtın; her seferinde tekrar anlatmak yerine bir proje talimat dosyası kullanın.
  4. Doğrulama kapılarını koruyun. AI değişikliği de insan değişikliği gibi: derleme, test, inceleme ve (kritikse) uzman onayından geçer. AI'nın PR açması onayı atlamaz.
  5. Ölç ve ayarla. Neyin gerçekten hızlandırdığını, nerede düzeltme yükü arttığını izleyin; işe yaramayan kullanımları budayın.

Üç Mini Vaka

Vaka 1 — CLI ajanı çok dosyalı yeniden adlandırmayı üstlendi. Bir ekip, 60 dosyaya yayılmış bir kavramı yeniden adlandıracaktı. Bir CLI ajanına görevi verip önce bir plan istediler, planı onayladılar, sonra değişikliği yaptırıp tüm test paketini çalıştırdılar. Ajan 3 dosyada bir kenar durumu kaçırdı; testler yakaladı, düzeltildi. Elle yaklaşık 3 saatlik iş, denetimli hâliyle 50 dakikada bitti.

Vaka 2 — Kontrolsüz özerklik geri tepti. Başka bir geliştirici, bir ajana "bu modülü iyileştir" deyip serbest bıraktı; ajan 18 dosyayı değiştirip iki bağımlılık ekledi. Değişiklik o kadar genişti ki incelenemedi ve geri alınmak zorunda kaldı. Ders: ajanlara dar kapsam, net kabul kriteri ve önce-plan-sonra-uygula disiplini verin.

Vaka 3 — CI inceleme botu ilk süzgeç oldu. Bir ekip, PR'lara otomatik AI inceleme yorumu bırakan bir bot kurdu. Bot, null kontrol eksikleri ve stil sorunlarını yakalayınca insan incelemeciler zamanlarını iş mantığına ayırabildi. Ancak ekip, botun "onay" vermediğini net kurala bağladı: en az bir insan onayı hâlâ zorunluydu. Gürültüyü azaltmak için botu yalnızca yüksek/orta şiddetli bulgu bırakacak şekilde ayarladılar.

Dört Kopyalanabilir Şablon

CLI ajanı için "önce plan" disiplini:

Görev: {{net, dar kapsamlı görev}}Kabul kriteri: {{ölçülebilir sonuç}}Kısıt: yalnızca {{şu dizin/dosyalar}} üzerinde çalış; yeni bağımlılık ekleme.Önce DEĞİŞİKLİK YAPMADAN bir plan sun: hangi dosyalar, ne değişecek, hangitestler çalışacak. Planı ONAYLAMAMI bekle. Sonra adım adım uygula, her adımdatestleri çalıştır.

Proje talimat dosyası (araçlara kalıcı bağlam):

Bu projede AI araçları için kalıcı kurallar:- Dil/sürüm: {{...}}. Stil: {{...}}.- Mimari kısıt: {{ör. katmanlar arası şu yön}}.- ASLA: sır gömme, üretim verisi kullanma, {{yasak kütüphaneler}}.- Her değişiklik test edilebilir olmalı; kamuya açık API imzasını sorMADAN değiştirme.- Emin olmadığında dur ve sor.

Görev-araç eşleme kararı:

Şu görevi tanımlıyorum: {{görev}}. Bunu hangi araç sınıfıyla yapmalıyım: (a) editör tamamlama, (b) sohbet asistanı,(c) CLI ajanı, (d) CI otomasyonu? Gerekçeni, riskini ve önerilen özerklikseviyesini (salt öneri / dosya değiştir / komut çalıştır) yaz.

CI inceleme botu davranış kuralı:

PR incelemesinde yalnızca YÜKSEK ve ORTA şiddetli bulguları yorum olarak bırak.Her bulgu: kategori, şiddet, önerilen düzeltme. Stil tercihi düzeyindekinotları ayrı, tek bir özet yoruma topla. Sen ONAY VERME; insan onayı zorunlu.

Zayıf prompt / Güçlü prompt

Zayıf: (CLI ajanına) "Ödeme modülünü daha iyi hâle getir."
Güçlü: (CLI ajanına) "Yalnızca src/payments/ altında çalış. Görev: refund() fonksiyonundaki tekrarlı doğrulama mantığını tek bir yardımcıya çıkar; davranış ve imzalar değişmesin. Önce plan sun ve onayımı bekle; sonra uygula ve tests/payments/ paketini çalıştır. Yeni bağımlılık ekleme."

Güçlü sürüm kapsamı daraltır, kabul kriterini ve kısıtları koyar, "önce plan" disiplinini dayatır. Belirsiz "daha iyi yap" istekleri, geniş ve denetlenemez değişikliklerin baş sebebidir.

Araç sınıfı

En iyi olduğu iş

Özerklik

Denetim ağırlığı

Editör tamamlama

Akış içi küçük ek

Düşük

Hafif (anlık okuma)

Sohbet asistanı

Anlama, test, refactor

Orta

Orta (çıktı doğrulama)

CLI ajanı

Çok dosyalı, tekrarlı

Yüksek

Ağır (plan + tam inceleme)

CI otomasyonu

Sürekli ilk süzgeç

Orta

Orta (kural + insan onayı)

Ekip Yönetişimi: Bireysel Beceriden Ortak Sisteme

AI'yı bireysel olarak iyi kullanmak başlangıçtır; asıl olgunluk, ekip düzeyinde tutarlı bir sistemdir. Bu sistem birkaç sütuna dayanır: onaylı araç listesi (hangi araçlar hangi veriyle kullanılabilir — 10. üniteden), doğrulama kapıları (AI değişikliği de aynı derleme/test/inceleme kapılarından geçer — 11. üniteden), şeffaflık (bir değişikliğin AI destekli olduğunu belirtmek, gerektiğinde izlenebilirlik sağlar) ve sorumluluk netliği (imzayı atan, hesabı veren insan bellidir). Bu çerçeve, hızı korurken riski sınırlar ve yeni ekip üyelerinin de aynı disiplinle çalışmasını sağlar.

Dikkat: Bir aracın özerkliği ne kadar yüksekse — özellikle dosya değiştirebilen, komut çalıştırabilen CLI ajanları — onu üretim ortamına, gizli verilere ve geri döndürülmesi zor işlemlere erişimi konusunda o kadar sıkı sınırlayın. Yıkıcı komutları (kalıcı silme, dağıtım) insan onayına bağlayın.

Sık yapılan hatalar

  • Görev-araç uyumsuzluğu. Çok dosyalı bir işi editör tamamlamasıyla ya da küçük bir eki ağır bir ajanla yapmaya çalışmak.
  • Ajanı serbest bırakmak. Dar kapsam ve "önce plan" olmadan verilen ajan görevleri, incelenemez değişiklikler üretir.
  • Doğrulama kapılarını AI için gevşetmek. "AI yaptı, hızlı geçelim" en tehlikeli istisnadır; kapılar herkes için aynıdır.
  • Bağlamı her seferinde elle vermek. Proje kurallarını kalıcı bir talimat dosyasına yazmamak, tutarsızlık ve tekrar üretir.
  • CI botunun onayını insan onayı sanmak. Bot bir süzgeçtir; hesap verebilir insan onayı zorunludur.

Özetle

AI kodlama araçları dört ana kategoriye ayrılır: editör tamamlaması, sohbet asistanı, CLI ajanları ve CI otomasyonu. Ustalık, görevi doğru araca ve doğru özerklik seviyesine eşlemektir; özerklik arttıkça denetim de artar. Araçlara kalıcı proje bağlamı verin, çok dosyalı ajanlara "önce plan" disiplini dayatın ve AI değişikliğini insan değişikliğiyle aynı doğrulama kapılarından geçirin. Bireysel beceriyi; onaylı araç listesi, doğrulama kapıları, şeffaflık ve sorumluluk netliği üzerine kurulu bir ekip sistemine dönüştürün. AI uçtan uca bir hız çarpanıdır; imzayı atan ve hesabı veren, her zaman yetkin insandır.

Uygulama görevi

Önümüzdeki hafta yapacağınız üç gerçek görevi listeleyin. Her biri için "görev-araç eşleme kararı" şablonunu kullanıp hangi araç sınıfını ve hangi özerklik seviyesini seçeceğinizi gerekçesiyle belirleyin. Sonra bir CLI ajanı (veya sohbet asistanı) için "önce plan" disipliniyle dar kapsamlı bir görev çalıştırın: planı onaylayın, uygulatın, testleri çalıştırın ve değişikliği bir insan PR'ı gibi inceleyin. Son olarak ekibiniz için 5 maddelik bir "AI kullanım kuralı" taslağı yazın (onaylı araçlar, veri kuralı, doğrulama kapısı, özerklik sınırı, sorumluluk).

Kontrol listesi

  • [ ] AI kodlama araç kategorilerini ve her birinin tatlı noktasını ayırt edebiliyorum.
  • [ ] Görevi doğru araç sınıfına ve uygun özerklik seviyesine eşliyorum.
  • [ ] Araçlara kalıcı proje bağlamı (talimat dosyası) veriyorum.
  • [ ] CLI ajanlarına dar kapsam ve "önce plan" disiplini uyguluyorum.
  • [ ] AI değişikliklerini insan değişikliğiyle aynı doğrulama kapılarından geçiriyorum.
  • [ ] Ekip düzeyinde onaylı araç, veri kuralı, şeffaflık ve sorumluluk çerçevesini savunuyorum.

Modul Sinavi

1. Bir kodlama asistanının temelinde yatan büyük dil modeli, kodu üretirken aslında ne yapar?

  • A) Verilen bağlama dayanarak en olası devamı örüntüsel olarak tahmin eder ✔
  • B) Kodu gerçekten derleyip çalıştırarak doğru sonucu garantiler
  • C) Tüm internetteki kodu canlı olarak tarayıp en doğrusunu kopyalar
  • D) Kodun mantığını bir insan mühendis gibi kavrayıp niyeti anlar

Aciklama: LLM kodu bir insan gibi 'anlamaz'; çok büyük bir metin ve kod havuzundan öğrendiği örüntülere dayanarak, verilen bağlama en olası devamı üretir. Bu yüzden çıktının kalitesi doğrudan verdiğiniz bağlam ve talimatın kalitesine bağlıdır ve her çıktı doğrulanmalıdır.

2. AI'nın var olmayan bir fonksiyonu veya kütüphaneyi ikna edici biçimde uydurmasına ne denir ve tek gerçek panzehri nedir?

  • A) Buna derleme hatası denir; panzehri daha güçlü donanımdır
  • B) Buna halüsinasyon denir; panzehri kodu ve kullanılan her API'yi doğrulamaktır ✔
  • C) Buna regresyon denir; panzehri modeli yeniden başlatmaktır
  • D) Buna bağlam taşması denir; panzehri prompt'u kısaltmaktır

Aciklama: Buna halüsinasyon denir ve yazılımda en pahalı hatalardan birine yol açar. Tek gerçek panzehri doğrulamadır: kullanılan her fonksiyon, API ve paketin gerçekten var olduğunu ve kodun çalıştığını teyit etmek. Modelin kendinden emin tonu, doğruluk kanıtı değildir.

3. AI ile kod üretirken çıktının kalitesini ve tutarlılığını en çok artıran yaklaşım hangisidir?

  • A) Hiç bağlam vermeden 'bana bunu yaz' diyerek modeli serbest bırakmak
  • B) Mümkün olan en uzun ve süslü prompt'u yazmak
  • C) Girdi/çıktı sözleşmesini, kenar durumları, sürümü ve stili belirtip örnek vermek ✔
  • D) Üretilen kodu okumadan doğrudan birleştirmek

Aciklama: Fonksiyonun girdi/çıktı tiplerini (sözleşmesini), kenar durumlarını, dil/sürümünü ve stil kısıtını siz belirleyip modele örnek vermek, tahminden kesinliğe geçişi sağlar. Bağlamsız 'bana şunu yaz' istekleri her seferinde farklı ve çoğu zaman kenar durumları atlayan kod üretir.

4. Yabancı bir kod tabanını AI ile keşfederken, bir fonksiyonun adı 'validateAndSave' olmasına rağmen AI özeti yanlış olabilir. Doğru yaklaşım nedir?

  • A) İsim açıklayıcı olduğundan AI özetine tam güvenmek
  • B) Fonksiyonu hiç okumadan doğrudan değiştirmek
  • C) Yalnızca fonksiyon adına bakıp karar vermek
  • D) AI açıklamasını hipotez sayıp kritik iddiaları kodda satır satır doğrulamak ✔

Aciklama: AI, koddaki isme bakıp 'ne yapıyor gibi göründüğünü' anlatabilir ama gerçekte mantık farklı (hatta ters) olabilir. Bu yüzden AI açıklaması bir hipotezdir; özellikle güvenlik, yetki veya para akışı içeren kritik iddialar ilgili satırlarda gözle doğrulanmalıdır.

5. AI destekli kod incelemesinde 'AI baktı, temiz' demenin en büyük tehlikesi nedir?

  • A) AI yanlış negatif üretebilir; kaçırdığı gerçek hatalar sahte bir güven yaratır ✔
  • B) AI incelemesi çok yavaş olduğundan zaman kaybettirir
  • C) AI yalnızca İngilizce yorum yaptığından ekip anlamaz
  • D) AI her zaman gereğinden fazla yorum yaptığından PR birleşmez

Aciklama: AI hem yanlış pozitif (olmayan sorunu işaretleme) hem de yanlış negatif (gerçek hatayı kaçırma) üretir. Yanlış negatifler sessizdir; en tehlikeli hatalar incelemede hiç bahsi geçmeyenlerdir. Bu yüzden AI bir ilk süzgeçtir, onay değildir; birleştirme kararı hesap verebilir bir insanındır.

6. AI'ya yalnızca kodu verip test yazdırdığınızda ortaya çıkan en sinsi tuzak nedir?

  • A) AI her zaman çok fazla test yazıp kod tabanını şişirir
  • B) AI kodun mevcut (belki yanlış) davranışını 'doğru' diye test edip hatayı sabitler ✔
  • C) AI test yazarken kodu otomatik olarak siler
  • D) AI testleri yalnızca mutlu yol için değil hep kenar durum için yazar

Aciklama: AI, koda bakıp mevcut davranışı test eden beklentiler (assertion) yazma eğilimindedir. Kod baştan yanlışsa, AI bu yanlış davranışı 'doğru' diye sabitler. Bu yüzden testin beklentileri kodun mevcut çıktısına göre değil, olması gereken kurala (spesifikasyona) göre yazılmalıdır.

7. Bir hatayı AI ile ayıklarken hipotezlerin isabetini en çok belirleyen şey nedir?

  • A) Prompt'un ne kadar kibar yazıldığı
  • B) Sorunun kaç kez tekrar sorulduğu
  • C) Modele sağlanan kanıtın kalitesi: tam hata mesajı, yığın izi, girdi ve beklenen davranış ✔
  • D) Kodun hangi renk temayla yazıldığı

Aciklama: AI hatayı sizin gördüğünüz gibi görmez; yalnızca ona verdiğiniz kanıtı bilir. Tam hata mesajı, yığın izi, tetikleyen girdi ve beklenen davranış verildiğinde model gerçek olasılıkları sıralar; kanıt yoksa tahmin (halüsinasyon) yürütür ve sizi yanlış ize sürükler.

8. Üretim log'larını analiz için AI'ya vermeden önce yapılması gereken en kritik adım hangisidir?

  • A) Log'u olduğu gibi, tüm günü kapsayacak şekilde yapıştırmak
  • B) Log'u önce büyük harfe çevirmek
  • C) Log satırlarını alfabetik sıraya dizmek
  • D) Kişisel veriyi ve sırları maskeleyip yalnızca ilgili pencereyi vermek ✔

Aciklama: Ham üretim log'ları IP, e-posta, oturum kimliği, token ve bazen açık sır içerir. Bunları maskelemeden bir AI aracına yapıştırmak ciddi bir gizlilik ihlalidir. Ayrıca log dar bir zaman penceresine filtrelenmeli; ama önce gelen zorunluluk hassas veriyi temizlemektir.

9. AI, log analizinde iki olayın 'aynı anda' olduğunu söyleyip birini kök neden ilan ederse ne yapılmalıdır?

  • A) Korelasyonu nedensellik saymayıp iddiayı metrik ve kodla doğrulamak ✔
  • B) AI zaman ilişkisi kurduğu için nedeni kesin kabul etmek
  • C) İlk suçlanan bileşeni hemen yeniden başlatmak
  • D) Log'ları tümüyle silip yeniden toplamak

Aciklama: Log analizinde en yaygın tuzak korelasyonu nedensellikle karıştırmaktır. AI'nın kurduğu zaman ilişkisi bir ipucudur, kanıt değil. Gerçek nedensellik için zamanlama, mekanizma ve mümkünse tekrarlanabilirlik gerekir; iddia metrik ve kodla doğrulanmalıdır.

10. AI ile refactoring yaparken pazarlıksız olan altın kural ve onu güvenceye alan şey nedir?

  • A) Kodun daha kısa olması; bunu satır sayısı garanti eder
  • B) Davranışın değişmemesi; bunu mevcut davranışı yakalayan testler güvenceye alır ✔
  • C) Kodun daha çok yorum içermesi; bunu AI garanti eder
  • D) Tüm dosyanın tek seferde yeniden yazılması; bunu ajan garanti eder

Aciklama: Refactoring, kodun dıştan görünen davranışını değiştirmeden iç yapısını iyileştirmektir; altın kural davranışın sabit kalmasıdır. Bunu güvenceye alan şey testlerdir: değiştirmeden önce mevcut davranışı yakalayan bir test ağı kurulur ve her adımdan sonra çalıştırılır. Test ağı olmadan refactoring bir kumardır.

11. Dokümantasyon üretiminde AI'nın bilemediği ve uydurması tehlikeli olan katman hangisidir?

  • A) Kurulum adımlarının nasıl çalıştırılacağı
  • B) Bir fonksiyonun parametre listesi
  • C) Bir tasarım kararının 'neden' böyle verildiğinin gerekçesi ✔
  • D) Kodun hangi dilde yazıldığı

Aciklama: AI, koddan 'ne/nasıl' katmanını (fonksiyon ne yapıyor, kurulum nasıl) çıkarabilir; ama 'neden' katmanını (bir kararın tasarım gerekçesi, bir sınır değerin nedeni) bilemez. Uydurulmuş bir 'neden', gerekçesizlikten daha tehlikelidir; bu katmanı kod sahibi eklemelidir.

12. Acil bir hatayı çözerken, canlı bir API anahtarı içeren yapılandırma dosyasını onaylı olmayan bir AI aracına yapıştırmak isteyen geliştirici ne yapmalıdır?

  • A) Hız için dosyayı olduğu gibi yapıştırıp sonra sohbeti silmek
  • B) Dosyanın sonuna 'gizlidir' notu ekleyip göndermek
  • C) Anahtarı bırakıp yalnızca dosya adını değiştirmek
  • D) Sırları çıkarıp/maskeleyip yalnızca gerekli hassas olmayan bağlamı vermek ✔

Aciklama: Sırlar, kişisel veri ve gizli varlıklar onaylı olmayan araçlara asla girilmemelidir; aciliyet bu kırmızı çizgiyi askıya almaz. Doğru yaklaşım, önce sırları çıkarmak/maskelemek ve yalnızca gerekli, hassas olmayan bağlamı vermektir. Bir sır yine de sızarsa ilk iş o anahtarı derhal döndürmektir.

13. AI'nın ürettiği bir kod testten geçiyor ve üretimde çalışıyor. Bu, kodun güvenli olduğunu kanıtlar mı?

  • A) Hayır; 'çalışıyor' güvenli demek değildir, güvenlik ayrı bir doğrulama katmanı gerektirir ✔
  • B) Evet; testten geçen kod tanımı gereği güvenlidir
  • C) Evet; üretimde çalışması tüm açıkları eler
  • D) Hayır; ama yalnızca kod yavaşsa güvenlik önemlidir

Aciklama: 'Çalışıyor' ile 'güvenli' aynı şey değildir. Kod, SQL enjeksiyonu gibi bir açık içerse bile testten geçip sorunsuz çalışabilir; açık yalnızca bir saldırgan onu bulunca ortaya çıkar. Bu yüzden doğruluğun yanında güvenlik odaklı inceleme ve SAST gibi taramalar ayrı bir katman olarak yapılmalıdır.

14. Bir CLI ajanına (dosya değiştirip komut çalıştırabilen özerk araç) çok dosyalı bir görev verirken en güvenli disiplin hangisidir?

  • A) Ajana 'bu modülü iyileştir' deyip tam serbestlik vermek
  • B) Dar kapsam ve kabul kriteri verip önce plan istemek, onaylayıp adım adım uygulatmak ve testleri çalıştırmak ✔
  • C) Ajanın tüm değişikliklerini incelemeden doğrudan birleştirmek
  • D) Ajana üretim ortamına ve gizli verilere sınırsız erişim vermek

Aciklama: Özerklik arttıkça denetim de artmalıdır. Ajana dar bir kapsam ve net kabul kriteri verip önce değişiklik yapmadan bir plan istemek, planı onaylamak, sonra adım adım uygulatıp her adımda testleri çalıştırmak; geniş, incelenemez ve geri alınması gereken değişiklikleri önler.

15. Güvenlik-kritik bir yazılımda (ör. ödeme veya kimlik doğrulama) AI'nın ürettiği koddan doğan sorumluluk kimdedir?

  • A) Kod AI'dan geldiği için araç sağlayıcısında
  • B) AI yeterince gelişmişse hiç kimsede; doğrulamaya gerek kalmaz
  • C) Kodu inceleyip birleştiren ve dağıtan ekip/mühendisde; AI onayın yerine geçmez ✔
  • D) Yalnızca prompt'u yazan kişide, inceleyenlerde değil

Aciklama: AI bir hız çarpanı ve taslak üreticisidir; sorumluluğu devralamaz. Üretimdeki koddan doğan hata, açık veya ihlalin sorumluluğu, o kodu inceleyip birleştiren ve dağıtan ekiptedir. Güvenlik-kritik alanlarda AI çıktısı, yetkin bir mühendisin incelemesi ve onayının yerine hiçbir koşulda geçmez.