Niyet Programlama ve Yapay Zekâ Destekli Yazılım Mühendisliği

Programlamanın makine kodundan doğal dil ve yazılım geliştirme ajanlarına uzanan soyutlama çizgisini; niyet, algoritma, doğrulama, mesleki dönüşüm ve kritik sistemler açısından ele alan kapsamlı ders notu.

1. Programlamaya yeniden bakmak

Programlama çoğu zaman bir programlama dilinde kod yazmakla özdeşleştirilir. Oysa kod, programlamanın kendisi değil, insanın çözüm düşüncesini bilgisayara aktarmak için kullandığı gösterimlerden biridir.

Bir programlama problemi en temel biçimiyle şu zincir üzerinden düşünülebilir:

Problem → zihinsel model → algoritma → gösterim → yürütme

Bir mühendis önce problemi anlamaya, sonra bu problem için bir çözüm tasarlamaya çalışır. Çözüm bir algoritma, durum makinesi, veri akışı, kural kümesi, matematiksel model veya bunların birleşimi olabilir. Programlama dili ise bu çözümün bilgisayar tarafından işlenebilecek biçimde ifade edilmesini sağlar.

Bu nedenle programlama tarihine yalnızca dillerin tarihi olarak bakmak eksiktir. Aynı zamanda bu tarih, insanın makineye ne istediğini giderek daha yüksek bir soyutlama düzeyinden anlatabilmesinin tarihidir.

İlk dönemlerde programcı bilgisayara büyük ölçüde nasıl çalışması gerektiğini söylüyordu. Günümüzde üretken yapay zekâ ve yazılım geliştirme ajanlarıyla birlikte giderek daha fazla ne istediğimizi, hangi sınırlar içinde istediğimizi ve doğru sonucun hangi koşulları sağlaması gerektiğini tarif ediyoruz.

Bu değişim programlamayı ortadan kaldırmaz. Programlama etkinliğinin insan tarafından görülen katmanını değiştirir.

2. Makineye yaklaşmaktan makineden uzaklaşmaya

Bilgisayar programlama tarihinde her büyük gelişme, belirli bir ayrıntı sınıfının programcıdan gizlenmesiyle birlikte gelmiştir.

Makine kodunda işlemci komutlarının sayısal karşılıklarıyla çalışmak gerekirken, assembly dili bunlara sembolik adlar verdi. Yüksek seviyeli diller bellek adresleri ve işlemci komutları yerine değişkenler, fonksiyonlar ve veri yapıları sundu. İşletim sistemleri donanım ayrıntılarının önemli bölümünü soyutladı. Kütüphaneler ve çatı sistemleri tekrar eden altyapı işlerini hazır bileşenlere dönüştürdü.

Kabaca şu gelişim çizgisinden söz edilebilir:

Makine kodu
    ↓
Assembly
    ↓
Yüksek seviyeli programlama dilleri
    ↓
Kütüphaneler ve çalışma zamanları
    ↓
Çatı sistemleri ve alan dilleri
    ↓
Görsel ve düşük kodlu geliştirme
    ↓
Doğal dil ile yapay zekâ destekli geliştirme

Bu çizginin ortak özelliği, her aşamada programcının doğrudan yönetmek zorunda olduğu ayrıntı miktarının azalmasıdır.

C diliyle yazılmış bir döngü, makine düzeyinde çok sayıda işlemci komutuna dönüşebilir. Java'da tek bir koleksiyon işlemi altında bellek yönetimi, çalışma zamanı denetimleri ve sanal makine davranışları bulunabilir. Bir Spring Boot bildirimi arkasında HTTP sunucusu, yönlendirme, serileştirme ve bağımlılık yönetimi gibi geniş bir altyapı çalışabilir.

Yapay zekâ destekli programlama bu soyutlama eğiliminin devamı olarak görülebilir.

Önce:

for (int i = 0; i < values.length; i++) {
    ...
}

yazarken artık bazı görevlerde:

Bu kayıtları mevcut sıralama davranışını değiştirmeden
tarihe göre grupla ve en düşük ek bellek maliyetiyle işle.

gibi bir niyet tarif ediyoruz.

Aradaki temel fark, yapay zekânın yalnızca bir sözdizimi dönüştürücüsü olmamasıdır. İfade edilen amacı yorumlar, bağlamı kullanır, çözüm yolları üretir ve bunları programlama diliyle somutlaştırır.

3. Sözdiziminden niyete

Geleneksel programlamada mühendisin zihnindeki temel soru çoğu zaman şöyledir:

“Tasarladığım algoritmayı bu programlama diliyle nasıl ifade ederim?”

Yapay zekâ destekli geliştirmede soru giderek değişmektedir:

“Sistemin göstermesi gereken davranışı, sınırları ve doğruluk ölçütlerini nasıl ifade ederim?”

Bu değişim küçük görünse de yazılım üretiminin merkezini değiştirmektedir.

Geleneksel akış:

Problem
  ↓
Algoritma
  ↓
Programlama dili
  ↓
Derleyici / yorumlayıcı
  ↓
Makine

Niyet odaklı akış ise daha çok şöyledir:

Problem
  ↓
Niyet
  ↓
Belirtim
  ↓
Bağlam ve kısıtlar
  ↓
Yapay zekâ / ajan
  ↓
Programlama dili
  ↓
Derleyici / çalışma zamanı
  ↓
Makine

Programlama dili ortadan kalkmamıştır. İnsan ile programlama dili arasına yeni bir yorumlama ve üretim katmanı girmiştir.

Bu nedenle doğal dile doğrudan “yeni programlama dili” demek teknik olarak yanıltıcı olabilir. Doğal dil belirsizdir; aynı cümle farklı biçimlerde yorumlanabilir. Java, C veya Rust ise biçimsel sözdizimi ve açık semantik kurallara sahiptir.

Daha doğru ifade şudur:

Doğal dil, programlama sürecinin yeni yüksek seviyeli denetim arayüzlerinden biri haline gelmektedir.

4. Niyet programlama nedir?

Niyet programlama, geliştiricinin çözümün bütün uygulama ayrıntılarını doğrudan yazmak yerine ulaşılacak davranışı, sınırları, korunacak özellikleri ve doğruluk ölçütlerini tarif ettiği geliştirme yaklaşımı olarak düşünülebilir.

Buradaki “niyet”, yalnızca:

Kullanıcı yönetimi ekle.

gibi bir istek değildir.

Mühendislik açısından gerçek bir niyet daha fazla bilgi taşır:

Mevcut kullanıcı yönetiminin davranışını koru.

Yeni kullanıcı kaynağını mevcut yetkilendirme modeline ekle.

Veritabanı şemasını değiştirme.

Mevcut API sözleşmelerini bozma.

Yetki kontrolünü atlayan hiçbir yürütme yolu oluşturma.

Başarısız dış servis çağrılarında mevcut hata semantiğini koru.

Burada geliştirici artık yalnızca istenen davranışı değil, değişiklik uzayının sınırlarını da tarif etmektedir.

Bu nedenle niyet programlamanın daha doğru modeli şöyledir:

Niyet = yapılacaklar + yapılmayacaklar + korunacak değişmezler + başarı ölçütleri

Buna bağlam, araçlar ve doğrulama eklendiğinde mühendislik süreci oluşur:

Niyet
+
Belirtim
+
Bağlam
+
Kısıtlar
+
Araçlar
+
Doğrulama

İyi sonuç yalnızca iyi yazılmış bir komuta bağlı değildir. Yapay zekâ ile kod üretiminde asıl belirleyici, “zekice prompt”tan çok proje mimarisi, kurallar, örnekler, araçlar, bellek ve sınırların doğru bağlama verilmesidir.

5. Prompt mühendisliği ile niyet programlama aynı şey değildir

Bir yapay zekâ modeline iyi komut yazabilmek yararlı bir beceridir. Ancak bunu niyet programlamanın tamamı olarak görmek yetersizdir.

Örneğin:

Daha hızlı çalışan bir sürüm yaz.

bir komuttur; fakat mühendislik belirtimi değildir.

“Daha hızlı” sözü şu soruları cevaplamaz:

Hangi yük altında?
Ortalama gecikme mi, en kötü gecikme mi?
İşlem hacmi mi artırılacak?
Bellek artabilir mi?
Tutarlılık değişebilir mi?
Sonuçların sırası korunacak mı?
Davranış değişikliğine izin var mı?
Ölçüm hangi donanımda yapılacak?

Bu nedenle daha olgun yapay zekâ destekli yazılım geliştirmede odak prompt mühendisliğinden bağlam ve belirtim mühendisliğine kaymaktadır.

İyi bir yapay zekâ ajanının bilmesi gerekenler arasında şunlar bulunabilir:

sistem mimarisi,
kodlama kuralları,
alan modeli,
veri modeli,
API sözleşmeleri,
güvenlik sınırları,
bilinen teknik borçlar,
performans hedefleri,
geçmiş mimari kararlar,
değiştirilmemesi gereken davranışlar,
kabul ölçütleri.

6. Vibe coding

“Vibe coding” kavramı 2025 yılında Andrej Karpathy'nin doğal dille istenen davranışın tarif edildiği, üretilen kodun ayrıntılarına fazla inilmeden sonuç üzerinden ilerlenen bir çalışma biçimini tanımlamasıyla yaygınlaştı.

En yalın biçimiyle süreç şöyle ilerleyebilir:

İsteği yaz
   ↓
AI kodu üretsin
   ↓
Çalıştır
   ↓
Hata oluşursa hata mesajını AI'ya ver
   ↓
Yeni sürümü dene

Bu yaklaşım küçük araçlar, denemeler, kişisel uygulamalar ve hızlı prototipler için son derece verimli olabilir.

Sorun, aynı yöntemin risk sınıfı gözetilmeden üretim sistemlerine taşınmasıdır.

Bir programın:

“çalışıyor gibi görünmesi”

ile:

“bütün tanımlı koşullarda doğru davranması”

aynı şey değildir.

7. Yapılandırılmış yapay zekâ destekli geliştirme

Vibe coding ile geleneksel mühendislik arasında geniş bir alan bulunur.

Deneyimli geliştirici:

problemi analiz eder,
çözüm sınırlarını belirler,
mimari kararı verir,
yapay zekâya belirli bir alt görevi verir,
üretilen değişikliği inceler,
başarısızlığı teşhis eder,
düzeltmeyi yeniden yapay zekâya yaptırabilir.

Burada yapay zekâ karar verici olmaktan çok uygulama hızlandırıcısıdır.

8. Ajanlı mühendislik

Yazılım ajanı yalnızca tek bir cevap üreten sohbet modeli değildir.

Bir görev alabilir, ortamı inceleyebilir, dosyaları okuyabilir, komut çalıştırabilir, sonucu gözlemleyebilir ve sonraki adımı buna göre belirleyebilir.

Basitleştirilmiş ajan çevrimi şöyledir:

Hedefi algıla
    ↓
Planla
    ↓
Eylem gerçekleştir
    ↓
Sonucu gözle
    ↓
Gerekirse planı değiştir
    ↓
Yinele

Bu nedenle güçlü bir dil modeline sahip olmak tek başına güçlü bir yazılım geliştirme sistemi oluşturmaz.

9. Yazılım geliştirme yaşam döngüsünün değişimi

Geleneksel yazılım geliştirme yaşam döngüsü kabaca şu aşamalardan oluşur:

Gereksinim
↓
Analiz
↓
Tasarım
↓
Kodlama
↓
Test
↓
Dağıtım
↓
Bakım

Çevik yöntemler ve DevOps bu aşamalar arasındaki süreyi önemli ölçüde kısaltmıştı. Yapay zekâ ise aşamaların arasındaki sınırları daha fazla bulanıklaştırmaktadır.

Bir geliştirici bugün aynı oturum içinde gereksinimi tartışabilir, veri modelini değerlendirebilir, API taslağını oluşturabilir, kod üretebilir, test hazırlayabilir, hatayı inceleyebilir ve belge yazabilir.

10. Mimari neden hâlâ önemlidir?

Yapay zekâ mimari seçenekler önerebilir; ancak gerçek mimari kararlar yalnızca teknik bilgilerden oluşmaz.

Örneğin:

dağıtık mı, merkezi mi?
tutarlılık mı erişilebilirlik mi?
düşük gecikme mi yüksek işlem hacmi mi?
hazır ürün mü kurum içi geliştirme mi?
genel çözüm mü özel çözüm mü?

sorularının cevapları işletme, operasyon, mevzuat, ekip yapısı ve gelecekteki kullanım biçimiyle ilgilidir.

11. Olumsuz belirtim

Geleneksel gereksinim çoğunlukla sistemin yapacağı işi tarif eder:

Kullanıcı, raporu dışa aktarabilmelidir.

Yapay zekâ ile mevcut ve karmaşık kod tabanları değiştirilirken yalnızca olumlu gereksinim yeterli olmayabilir.

Şunların da tarif edilmesi gerekir:

Mevcut yetkilendirme davranışını değiştirme.

Veritabanı şemasını değiştirme.

Dinleyici tarafındaki çalışan davranışı etkileme.

Yeni bağımlılık ekleme.

Eşzamanlı çalışma semantiğini değiştirme.

Bu tür ifadeler olumsuz belirtim olarak düşünülebilir.

Niyet programlamada güçlü bir görev tanımı dört parçadan oluşabilir:

Ne yapılacak?
Ne yapılmayacak?
Neler değişmeden kalacak?
Doğruluk nasıl kanıtlanacak?

12. Kod tabanı sistemin tamamı değildir

Bir yapay zekâ ajanı bütün kaynak kodu okuyabilir ve yine de sistemi tam olarak anlayamayabilir.

Kod tabanı ≠ sistem

Gerçek sistem daha geniştir:

Sistem =
Kod
+ Veri
+ Altyapı
+ Donanım
+ Kullanıcılar
+ Operasyon
+ Güvenlik
+ Geçmiş
+ Kurumsal kısıtlar
+ Alan bilgisi

Bu durum özellikle eski sistemlerde örtük bilgi sorununu önemli hale getirir.

13. Yapay zekâ neleri iyi yapabilir?

Bugünkü üretken yapay zekâ sistemleri yazılım geliştirmede özellikle örüntüsü güçlü görevlerde etkilidir.

Bunlar arasında:

tekrar eden kod üretimi,
API istemcisi yazımı,
veri dönüşümleri,
temel algoritmalar,
kod açıklama,
belge üretme,
biçim değiştirme,
test taslakları,
hata adaylarını bulma,
eski API kullanımlarını yenileme,
kod tabanında ilgili bölümleri bulma,
küçük ve orta ölçekli yeniden düzenleme,
çok dosyalı uygulama değişiklikleri

bulunabilir.

14. Yapay zekâ neleri güvenilir biçimde yapamaz?

Bu soruya kalıcı bir “yapamazlar listesi”yle cevap vermek doğru değildir. Model yetenekleri hızla değişmektedir.

Daha doğru yaklaşım güvenilirliği incelemektir.

Sorunlar arasında:

eksik bağlam,
yanlış varsayım,
var olmayan API veya bağımlılık üretme,
sınır durumlarını kaçırma,
yerel olarak doğru görünen fakat sistem genelinde yanlış değişiklik,
gereksinimi farklı yorumlama,
sessiz davranış değişikliği

bulunabilir.

Asıl soru:

“AI bunu yapabilir mi?”

değil,

“Bu çıktının doğru olduğuna hangi kanıtla güvenebiliriz?”

olmalıdır.

15. Üretim kolaylaştıkça doğrulama zorlaşır

Yapay zekâ öncesinde uygulama genellikle darboğazlardan biriydi.

Ajanlar birkaç dakika içinde yüzlerce veya binlerce satırlık değişiklik oluşturabilir.

Bu durumda yeni darboğaz oluşur:

Eski darboğaz:
uygulama

Yeni darboğaz:
doğrulama

Ajanın otuz saniyede ürettiği değişikliği bir mühendisin anlaması yarım saat sürebilir.

16. Test artık yalnızca hata bulma aracı değildir

Yapay zekâ destekli geliştirmede testlerin ek bir işlevi vardır.

Test, niyetin makine tarafından doğrulanabilir biçimidir.

Bu nedenle testler ve değerlendirme kümeleri yapay zekâ için bir çeşit yürütülebilir belirtime dönüşmektedir.

17. Determinizm sorunu

Klasik programlama büyük ölçüde deterministik yapılara dayanır.

f(x) → y

Üretken model ise olasılıksal üretim yapar.

Bu ilginç bir mühendislik durumu oluşturur:

Olasılıksal geliştirme süreci
        ↓
Deterministik olması beklenen yazılım

Bu nedenle tekrar üretilebilirlik, sürüm denetimi, fark incelemesi, test ve izlenebilirlik daha önemli hale gelir.

18. Kritik sistemlerde niyet programlama

Bir tanıtım uygulamasında yapılan yanlışlık ile kritik sistem hatası aynı risk sınıfında değildir.

Kritik sistemlerde yanlış davranış:

veri kaybına,
hizmet kesintisine,
güvenlik açığına,
hukuki sonuca,
fiziksel zarara

neden olabilir.

Bu nedenle kritik sistemlerde:

Risk arttıkça
↓
belirtim kesinliği artmalı
↓
doğrulama artmalı
↓
gözlemlenebilirlik artmalı
↓
yetki sınırları daralmalı
↓
insan denetimi güçlenmeli

19. Kritik sistemlerde hızın yanlış yorumlanması

Yapay zekâ araçlarının en görünür avantajı hızdır.

Ancak yazılım mühendisliğinde geliştirme süresinin kısalması tek başına başarı değildir.

Bir özellik iki saat yerine on dakikada üretilebilir.

Fakat hata incelemesi iki saat sürüyorsa, üretimde sorun çıkarıyorsa, teknik borç oluşturuyorsa veya güvenlik açığı yaratıyorsa gerçek verim artışı tartışmalıdır.

20. Teknik borcun üretim hızı da arttı

Yapay zekâ iyi kodu hızlı üretebilir.

Aynı nedenle kötü kodu da hızlı üretebilir.

Bu nedenle yapay zekâyı doğrudan bir “kalite artırıcı” olarak görmek yanlıştır.

Daha doğru ifade şudur:

Yapay zekâ bir kapasite çarpanıdır.

21. Junior geliştirici için fırsat

Yapay zekâ junior geliştiricinin üretkenliğini büyük ölçüde artırabilir.

Junior geliştirici bilmediği bir API'yi inceleyebilir, örnek kod üretebilir, hata mesajını açıklatabilir, alternatif algoritmalar görebilir ve test senaryosu üretebilir.

Doğru kullanıldığında öğrenme hızını ciddi biçimde artırabilir.

22. Junior geliştirici için risk

Aynı araç farklı biçimde kullanıldığında öğrenmeyi zayıflatabilir.

Bir geliştirici problemi tam anlamadan komut verir, üretilen kodu kopyalar, çalışıyorsa kabul eder ve hatada tekrar yapay zekâya dönerse çalışan ürün oluşturabilir; fakat mühendislik yetkinliği aynı hızda gelişmeyebilir.

Bu nedenle önemli sorulardan biri şudur:

AI, uzmanlaşmak için daha önce yapmak zorunda olduğumuz uygulama işlerini ortadan kaldırırsa yeni uzmanlar nasıl yetişecektir?

23. Yetkinlik yanılsaması

Yapay zekâ ile junior bir geliştirici birkaç dakika içinde son derece profesyonel görünen mimari belge, test, uygulama kodu, API veya SQL üretebilir.

Ortaya çıkan ürün kişinin gerçek bilgi düzeyinden çok daha ileri görünebilir.

Senior düzeyinde görünen çıktı
≠
senior düzeyinde muhakeme

24. Senior geliştiricinin değişen rolü

AI uygulama maliyetini azalttıkça senior geliştiricinin muhakeme gücü daha değerli hale gelebilir.

Deneyimli mühendis hangi çözümün uygulanmaması gerektiğini, hangi mimari sınırın korunacağını, hangi optimizasyonun gereksiz olduğunu ve hangi hatanın üretimde ağır sonuç doğuracağını çoğu zaman deneyimle bilir.

25. Senior geliştirici için beceri körelmesi

Risk yalnızca junior geliştiriciye ait değildir.

Senior geliştirici de yıllarca belirli işleri tamamen yapay zekâya devrederse düşük seviyeli hata ayıklama, SQL sorgu analizi, bellek davranışı veya karmaşık eşzamanlılık sorunları gibi alanlarda refleks kaybedebilir.

Sağlıklı yaklaşım, yapay zekânın mühendisin yerine düşünmesi değil, mühendisle birlikte daha yüksek soyutlama düzeyinde çalışmasıdır.

26. Programcı kimdir?

Programcı algoritmayı kodlar, veri yapılarını kullanır, programlama dilini bilir ve hataları düzeltir.

Yapay zekânın en doğrudan etkilediği rol de budur; çünkü sözdizimsel üretim ve tekrar eden uygulama işleri otomasyona en uygun yazılım görevleri arasındadır.

27. Yazılım geliştirici kimdir?

Yazılım geliştirici yalnızca kod yazmaz.

Bir özelliğin gereksinimini, uygulamasını, entegrasyonunu, testini ve bakımını birlikte ele alır.

28. Yazılım mühendisi kimdir?

Yazılım mühendisliği, çalışan kod üretmekten daha geniştir.

Bir sistemin güvenilir, sürdürülebilir, ölçeklenebilir, güvenli, ölçülebilir ve değiştirilebilir olmasını hedefler.

29. Bilgisayar mühendisi

Bilgisayar mühendisliği yazılımın donanımdan bağımsız olmadığını hatırlatır.

Gerçek sistemler işlemci, bellek, önbellek, depolama, ağ, giriş/çıkış ve hızlandırıcılar üzerinde çalışır.

Bu nedenle yüksek trafikli ve gerçek zamanlı sistemlerde “çalışan kod” ile “uygun mühendislik çözümü” arasındaki fark büyüktür.

30. Bilgisayar bilimcisi

Bilgisayar biliminin yapay zekâ çağında değerini kaybettiği düşüncesi yanlıştır.

Hesaplanabilirlik, karmaşıklık, algoritma analizi, grafik kuramı, kriptografi, bilgi kuramı ve dağıtık algoritmalar temel olmaya devam eder.

AI birkaç saniyede O(n²) bir çözüm üretebilir. Milyonlarca kayıt altında neden çöktüğünü anlamak bilgisayar bilimi bilgisidir.

31. Yazılım bilmek ile kod yazmak farklılaşmaktadır

Bir kişi çok az kod yazarak büyük uygulamalar üretebilir.

Ancak bu durum şu soruyu doğurur:

Yazılımı anlamadan yazılım üretilebilir mi?

Belirli düzeyde evet.

Ancak karmaşık sistemlerde yapay zekânın ürettiği çözümün yanlış olduğunu anlamak için çoğu zaman aynı alan hakkında yeterli bilgi gerekir.

AI'nın yaptığı işi kontrol edebilmek için yaptığı işi belirli ölçüde sizin de anlamanız gerekir.

32. Kod satırı artık üretkenlik ölçüsü değildir

Bir ajan birkaç dakikada on bin satır kod üretebilir.

Bu on bin satır büyük değer yaratabilir, gereksiz olabilir veya teknik borç olabilir.

Bu nedenle üretkenlik, üretilen kod miktarıyla değil; çözülmüş problem, hata oranı, üretim kesintisi, değişiklik başarısızlık oranı, bakım maliyeti, performans ve güvenlik gibi ölçülerle değerlendirilmelidir.

33. Performans mühendisliği

Yapay zekâ performans konusunda yararlı öneriler üretebilir.

Fakat “hızlandır” isteği tehlikelidir.

Gecikme ↔ işlem hacmi
Bellek ↔ CPU
Tutarlılık ↔ erişilebilirlik
Ön hesaplama ↔ bellek
Paralellik ↔ eşzamanlılık maliyeti

Performans niyetinin ölçülebilir olması gerekir.

34. Eşzamanlılık

Eşzamanlılık yapay zekâ ile üretilmiş kodda özellikle dikkat gerektiren alanlardan biridir.

Kod derlenebilir, testleri geçebilir, tek kullanıcıyla çalışabilir ve yine de üretimde yarış durumu oluşturabilir.

Bu nedenle kritik eşzamanlılık davranışlarında yalnızca çıktı incelemek yetmez. Korunacak değişmezler açıkça tanımlanmalıdır.

35. Dağıtık sistemler

Dağıtık sistemlerde niyet programlama daha da zorlaşır.

Ağ bölünmesi, gecikmeli mesaj, yeniden deneme, yinelenen istek, sıralama, saat farkı ve kısmi başarısızlık gibi sorunlar sistem genelinde oluşur.

Bir yapay zekâ “retry ekle” isteğini yerine getirebilir. Fakat yanlış retry politikası aynı işlemin iki kez yapılmasına neden olabilir.

36. Siber güvenlik

Yapay zekâ güvenlik çalışmalarında güçlü bir yardımcıdır.

Kod tarayabilir, zayıf örüntüler bulabilir, kayıtları ilişkilendirebilir ve saldırı senaryoları üretebilir.

Ancak güvenlik karşıt davranışlı bir alandır.

Bu nedenle sistem kötü niyetli girdiler altında da değerlendirilmeli, en az yetki, saldırı yüzeyi ve güven sınırları açık biçimde tasarlanmalıdır.

37. Adli bilişim

Adli bilişimde yapay zekâ büyük veri kümelerinin incelenmesini kolaylaştırabilir.

Ancak adli süreçte yalnızca teknik doğruluk değil; delil bütünlüğü, izlenebilirlik, tekrar üretilebilirlik ve delil zinciri de önemlidir.

Bir modelin verdiği sonucun ikna edici görünmesi, sonucun adli olarak güvenilir olduğu anlamına gelmez.

38. Güven problemi

Bir cevabın akıcı, ayrıntılı veya teknik olması doğruluğunu kanıtlamaz.

Dilsel güven ≠ epistemik güven

Yazılım mühendisliğinde bunun karşılığı:

Derlenen kod ≠ doğru kod

Test geçen kod ≠ bütün koşullarda doğru sistem

şeklinde düşünülebilir.

39. Sorumluluk

Yapay zekâ kod üretebilir.

Ajan kodu değiştirebilir.

Sistem otomatik olarak dağıtılabilir.

Ancak üretimde zarar oluştuğunda:

“Model böyle üretti.”

mühendislik gerekçesi değildir.

40. Yapay zekâ ve eski sistemler

Yapay zekânın en değerli kullanım alanlarından biri eski ve karmaşık kod tabanları olabilir.

Ajan ilgili dosyaları bulabilir, çağrı zincirlerini açıklayabilir, eski API'leri gösterebilir ve değişiklik noktalarını önerebilir.

Fakat eski sistemlerde örtük bilgi daha fazladır.

41. Bağlam mühendisliği

Yapay zekâ ile yazılım geliştirmenin en önemli becerilerinden biri bağlamı yönetmektir.

Sürekli bağlam

Her görevde geçerli kurallar:

mimari ilkeler,
kodlama standartları,
güvenlik sınırları,
genel kısıtlar.

İsteğe bağlı bağlam

Yalnızca ilgili görevde gereken:

belirli modül belgeleri,
veri modeli,
geçmiş hata kayıtları,
ilgili kaynak kod.

42. Yazılım üreten sistemi tasarlamak

Yapay zekâ destekli geliştirmede mühendisin çıktısı giderek yalnızca kaynak kod olmayabilir.

Belirtimler
+
Bağlam
+
Ajanlar
+
Araçlar
+
Testler
+
Kalite kapıları
+
Geri bildirim

Bu sistem daha sonra kod üretir.

43. İnsan ve ajanlardan oluşan ekipler

Yapay zekâ ajanları belirli görevleri üstlenen yarı özerk yazılım bileşenleri olarak kullanıldığında ekip yapısı değişebilir.

İnsan
  ↓
Mimari karar ve görev tanımı

Ajan
  ↓
Uygulama

Test sistemi
  ↓
Doğrulama

Ajan
  ↓
Düzeltme

İnsan
  ↓
Son inceleme

44. Geleceğin temel becerisi sistem düşüncesidir

Belirli bir dili bilmek önemini kaybetmez.

Ancak tek başına yeterli farklılaştırıcı olmayabilir.

Gelecekte güçlü mühendis şu zinciri birlikte değerlendirebilen kişi olacaktır:

Gereksinim
↓
Alan modeli
↓
Mimari
↓
Veri
↓
Eşzamanlılık
↓
Güvenlik
↓
Performans
↓
Hata durumları
↓
Operasyon
↓
Gözlemlenebilirlik

45. Yazılım meslekleri ortadan kalkacak mı?

Kesin bir sayı veya tarih vermek mümkün değildir.

Ancak görev bileşimlerinin değişmesi oldukça olasıdır.

Göreli değeri azalabilecek işler:

tekrar eden kod üretimi,
standart CRUD geliştirme,
mekanik dönüşümler,
basit belge üretimi.

Göreli değeri artabilecek işler:

alan bilgisi,
mimari,
güvenlik,
performans,
belirtim,
doğrulama,
sistem düşüncesi,
teknik sorumluluk.

46. Programlama bilgisi gereksiz olacak mı?

Basit yazılım üretiminde kod bilgisine duyulan ihtiyaç azalabilir.

Ancak karmaşıklık ve risk arttıkça bu durum değişir.

Bir sistem finansal işlem yapıyor, kişisel veri işliyor, çok yüksek trafik taşıyor, gerçek zamanlı çalışıyor veya fiziksel süreç kontrol ediyorsa üretim aracının çıktısını değerlendirecek mühendislik bilgisi gerekir.

47. Niyet programlamanın felsefi yönü

Bir mühendis gereksinimi belirler, mimariyi tasarlar, kısıtları tarif eder; ajan on bin satır kod üretir ve mühendis yalnızca kritik değişiklikleri inceler.

Bu durumda programı kim yazmıştır?

Yapay zekâ mı?

Mühendis mi?

Yoksa insan ve yapay zekâdan oluşan sistem mi?

Yazarlık giderek:

Davranışı kim tasarladı?

sorusuna yaklaşabilir.

48. İnsan düşüncesi ile makine üretimi arasındaki yeni sınır

Eskiden çeviri yükünün büyük kısmı insandaydı.

Algoritmayı düşün
↓
Sözdizimini yaz
↓
Hataları düzelt

Yeni yaklaşımda çevirinin bir bölümü modele devredilmektedir:

İnsan:
Amaç + sınır + muhakeme

AI:
Uygulama + dönüşüm + tekrar

İnsan:
Doğrulama + sorumluluk

49. Temel mühendislik bilgisi neden daha önemli olabilir?

Soyutlama yükseldikçe alt katman bilgisinin günlük kullanım sıklığı azalabilir; kritik olduğunda değeri artabilir.

Bir geliştirici her gün bellek düzeniyle uğraşmayabilir. Fakat üretim ortamındaki sorun bellek baskısından kaynaklandığında bunu anlayacak kişiye ihtiyaç vardır.

Bu nedenle temel bilgi, sürekli uygulanacak mekanik beceriden çok gerektiğinde soyutlamayı delip alt katmanı anlayabilme kapasitesi haline gelebilir.

50. Niyet programlamada iyi mühendislik modeli

Pratik bir çalışma modeli şu şekilde kurulabilir.

Problemi tanımla.
Mevcut sistemi anla.
Niyeti yaz.
Kısıtları yaz.
Başarı ölçütünü yaz.
Uygun bağlamı sağla.
Değişikliği üret.
Doğrula.
Üretimi gözle.
Bilgiyi geri besle.

Böylece yapay zekâ kullanımı tek bir “prompt → kod” işlemi olmaktan çıkar ve kapalı çevrim mühendislik sistemine dönüşür.

51. Sade mühendislik yaklaşımı

Niyet programlamada ayrıntı vermek ile gereksiz ayrıntı vermek arasındaki sınır önemlidir.

Uzun komut her zaman iyi komut değildir.

İdeal olan modele her şeyi anlatmak değil, doğru şeyi anlatmaktır.

İyi belirtim:

kısa,
açık,
çelişkisiz,
ölçülebilir,
sınırları belirli

olmalıdır.

Niyet programlama, çok konuşmak değildir.

Belirsizliği azaltmaktır.

52. Sonuç

Programlama tarihinde her önemli soyutlama katmanı, insanın makineyle konuşma biçimini değiştirdi.

Bugün yeni bir katman oluşmaktadır:

İnsan
  ↓
Niyet
  ↓
Belirtim
  ↓
Yapay zekâ / ajan
  ↓
Kaynak kod
  ↓
Derleyici / çalışma zamanı
  ↓
Makine

Bu dönüşüm programlamanın sonu değildir.

Programlamanın bir sonraki soyutlama katmanıdır.

Soyutlama yükseldikçe mühendislik gereksiz hale gelmez.

Kod üretmek kolaylaştıkça yanlış kod üretmek de kolaylaşır.

Değişiklik hacmi arttıkça doğrulama zorlaşır.

Uygulama ayrıntıları görünmez oldukça temel sistem davranışını anlayan kişilerin değeri artar.

Bu nedenle geleceğin asıl ayrımı yapay zekâ kullanan ve kullanmayan geliştirici arasında olmayabilir.

Daha anlamlı ayrım şudur:

Yapay zekâ ile kod üretebilen kişi

ile

yapay zekâ aracılığıyla güvenilir bir sistemi tasarlayabilen, sınırlandırabilen ve doğrulayabilen mühendis.

Programcı için merkez uzun süre koddu.

Niyet programlamada merkez giderek doğru davranışın tanımıdır.

Kod hâlâ önemlidir.

Fakat kod artık her zaman başlangıç noktası değildir.

Bazen yalnızca iyi ifade edilmiş bir mühendislik düşüncesinin makine tarafından üretilmiş ara biçimidir.