Yapay zeka ile uygulamayi cikardiniz ama kodun durumu hic icinize sinmedi mi?

Akliniza bircok soru geliyor olabilir. Örnegin yük altinda stabil calisak mi? Paralel islemler veriler üzerinde hata izleri birakacak mi vs. Eger akliniza hicbir soru gelmiyor ve uygulamayi hemen canliya almak istiyorsaniz, bu yaziyi önce okuyun derim :)

Yazilim sadece kodun calisiyor olmasi ile bitmez. Localhost üzerinden tek bir kullanici ile test edilmis bir uygulama henüz hicbir seye hazir degildir. “Lokalde calisiyor ama” söylemlerinin ana sebebi de budur.

Yapay zekanin ürettigi kodu nasil güvenilir hale getirirsiniz? Burada benim gibi artik hic kod yazmadiginizi farz ediyorum. En alttan yukariya dogru atilmasi gereken adimlari siralayacagim.

## Birim Testleri
Her prompt icinde mutlaka “test etmeyi de unutma” ibaresi olmali. Yapay zeka olusturdugu her satir kod icin karsiligi olan bir birim testi yazacaktir.

## Entegrasyon Testleri
Bu testler entegre edimis bir sistem de (api + db) mevcut apilerin onay/kabul kriterlerine uygunlugunu test ederler. Bu tür testlerde yapay zeka tarafindan olusturulmalidir.

## Code Coverage
Mevcut testlerin ne oranda kodu kapsadigini anlayabilmek icin code coverage araclari ile ölcüm yapilmasi gerekmektedir. Ben yapay zekaya arada bir “kod kapsama seviyemiz” nedir diye soruyorum. Aldigim cevap genelde tüm sistem geneli icin gecerli olan %90 civarinda oluyor. Ayrica yapay zekadan mevcut testleri inceleyerek, hangi alanlar icin test yazilabilecegi analizini istiyorum. Bu sekilde zaten eksik olan tüm birim testleri ortaya cikmis oluyor.

## Onay/Kabul Testleri
Yazilimci bu noktadan itibaren uygulamayi test etme islemini kendi eline almak durumundadir, cünkü uygulamadan olan beklentilerin onay/kabul kriterleri ile net olarak ifade edilmeleri gerekmektedir. Burada yine given/when/then tarzi onay/kabul kriterlerinin yer aldigi tanimlamalar ihtiva eden test spec dosyalari olusturulur. Bu spec dosyalarinin test koduna dönüstürülmesi gerekmektedir. Burada yine yapay zekadan bu spec dosyalarindan test kodunu olusturacak minik bir test catisi olusturmasi istenir. Buradaki en büyük avantaj beklentilerin plain text ile ifade edilmesi lakin gerekli test kodunun olusturulma isleminin yapay zekaya birakilmadir. Test kodu dogasi itibari ile cok kirilgan bir yapiya sahiptir. Yazilimcinin test kodu yazmak yerine, beklentilerini ifade ettigi spec dosyalari olusturmasi, kirilgan olan test kodun bakim yükümlülügünü yapay zekaya aktarmaktadir.

## Test Harness
Uygulamanin karmasik bir kismi oldugunu düsünelim. Ben burada kendi calismamdan bir örnek vereyim. Cloud main backend ile müsteri isletmelerinde benzer yapida calisan custom onprem backend sistemlerinin karsilikli olarak verisel senkronize edilmesi gerekiyor. Onprem tarafindan örnegin olusan siparislerin düzenlli olarak cloud main backende aktarilmasi lazim. Ayni sekilde cloud main backend üzerinde yapilan tüm degisiklikler verinin ait oldugu onprem instance tespit edilerek SSE üzerinden oraya aktarilmasi gerekiyor. Burada cok karmasik bir replikasyon implementasyonu var.

Bu yapiyi onbinlerce siparis ve benzeri verilerle test edebilmek icin yapay zekadan bir test harness catisi olusturmasini istedim. Bu test harness bünyesinde onbinlerce siparisi otomatik olarak onprem üzerinde olusturuluyor ve akabinde bu verilerin cloud main backende intikal edip, etmedikleri test harness catisi tarafindan kontrol ediliyor. Bu bir yük testi degil, ben sadece onprem veritabaninda olusan her satirin dogru bir sekilde cloud main backend aktarilmasini test etmek istedim.

Bu sekilde karmasik uygulama özellikleriin yük altinda ne kadar dogru ve stabil calistiklari test edilebilir.

Eger cikan sonuclara güvenmiyorsaniz, benim yaptigim gibi yapay zekadan iki veritabanini sync log dosyasi isiginda kiyaslamasini isteyebilirsiinz. Gün sonunda hakikaet veritabanindaki veride yatmaktadir.

## Yük Testleri

Load ya da performance testing icin bircok arac mevcut. Bunun icin yapay zeka destegi almak gerekmiyor diyebilirsiinz, ama cikan sonuclarin analizi icin yine yapay zeka kullanilabilir.

## Uygulama Loglari

Tek bir log yerine her büyük islem icin bir log dosyasi tahsis edilebilr. Benim uygulamada örnegin sync islemleri, siparis transaksiyonlari, merge islemleri, sse watchdog icin ayri birer log dosyasi var. Buna paralel tüm loglarin toplandigi ana bir log dosyasi da mevcut, lakin bir hata bulmak icin bu dosyayi yapay zekaya verip, contexti patlatmanin ve tokenleri yakmanin bir anlami yok.

Bunun yerine hem hata aramak hem de implementasyonu check etmek icin kücük log dosyalarini yapay zeka ile paylasiyorum. Bu sekilde cok implementasyon hatasi kesfedebildim.

## Baska Modelleri Ile Cross-Check
Ben implementasyon icin opus-4.6, analiz icin opus-4.7 kulllaniyorum. 4.7 kod yazma konusunda biraz ucuk, ama analizleri cok iyi. Bu yüzden analizleri yüksek modelle yapip, implementasyon icin bir alt modeli kullaniyorum. Bu sekilde opus-4.6 nin aklina bile gelmeyenleri, eksikleri ya da hatalari opus-4.7 ile kesfetmek ve tamamlatmak münkün. Bu yüzden “güven iyidir, ama kontrol daha iyidir” demek geliyor icimden :)

## Sürekli Entegrasyon
Her commit ile kodun derlenmesi ve mevcut testlerin kosturulmasi gerekir. Eger test kirilmalari varsa, bu yapisal bir degisikligin yan etkilerinin olduguna isaret eder. Bu yüzden sürekli entegrasyon (continuous integration) kullanilmasi gereken önemli süreclerden birisidir. Tüm testlerin calisiyor olmasi yeni bir sürüm olusturmanin ilk adimi olmalidir.

Artik kodu yapay zeka yaziyor, bunu kabul ettik. Peki biz yazilimci olarak isin neresindeyiz? Bunu burada uzun uzun anlatmak istemiyorum. Yazilimci olarak isimiz baska alanlara kaymis durumda, ama artik kod yazmayacagiz.

Artik en önemli görevlerimizden birisi test yazmak / yazdirmak ve yapay zekanin olusturdugu kodun yani olusturmak istedigimiz ürünün davranislarini test etmek. Ama test kodunu da tamamen yapay zekaya birakmak, onun calip, onun oynadigi bizim ise sadece seyredici oldugumuz bir ortam dogurur. Bu da istedigimiz bir durum olamaz. Bizim girdileri ve ciktilari kontrol edebilecegimiz yeni bir soyutluk seviyesine ihtiyacimiz var.

Cogumuz “yapay zekaya testleri de yazdirabiliriz, hem de bunu bizden daha genis kapsamli yapar” diyecektir. Burada bazi problemler görüyorum:

• Kodu degistiren yapay zekanin testleri de adapte etmesi tehlikeli ve bu kontrol edilemez sonuclar dogurabilir (kendi calip, kendisi oynar metaforu)
• Statik test kodu sürekli kirilmaya müsait oldugundan, bakimi cok zordur. Yine burada “bunu yapay zeka halleder” demek uygun degil, cünkü elimizde tutmak istedigimiz bir kontrol mekanizmasina ihtiyacimiz var
• Test etmek istiyoruz lakin kod yazmak, bakimini yapmak ve adapte gibi detaylar ile ugrasiyoruz. Bunun yerine nasil yerine ne sorusunu sormamiz gerekmektedir. Neyi test ediyoruz sorusu test etmek istedigimiz isletme mantigina odaklanmamizi saglayacaktir. Burada imperatif düsünce yerine neyin test edildigini tayin ettigimiz deklaratif düsünce tarzina gecmis oluyoruz.

Ne yapabiliriz?

Artik düsüncelerimizi belli kaliplara sokarak bilgisayar ile calisma zorunlulugumuz ortadan kalkmis durumda. Biz yapay zeka ile kendi dilimizde iletisim kuruyoruz. Ciktilari kontrol etmek icin kullanacagimiz yeni soyutluk seviyesi de bu.

Bir uygulamanin feature olarak tanimladigimiz ve implemente ettigimiz degisik türde davranislari olabilir. Bu davranislarin uygulama tarafindan sergilenebilmesi icin kullanicilar tarafindan tetiklenmeleri gerekir. Tanimli bir input gerekli davranis bicimi uygulandiktan sonra tanimli bir output doguracaktir. Programci olarak bu girdi ve ciktilari kendi dilimizde tanimlayabilir ve yapay zeka ya da test catisi tarafindan uygulamaya karsi kosturulmalarini saglayabiliriz.

Kendimden bir örnek vereyim. Ben testleri artik bir yml dosyasinda su sekilde specler olarak tanimliyorum:

name: 'Clean Start Test'
description: 'When SQLite-Database deleted, then app starts in default setup mode'

tags:
  - clean

setup:
  - 'Delete database'
tests:
  - name: 'App starts with setup screen'
    steps:
      - 'Start the app'
      - 'Wait 2 secs '
      - 'Expect that "Lütfen cihaz türünü seciniz" is visible'

Sonnet’e bu specleri okuyup (parse, analyse), teste dönüstürüp (generation), kosturabilen (execution) ufak capli bir framework yazdirdim.

Bu specler tanimlamis oldugum onay/kabul kriterlerini ihtiva ediyor. Bir nevi BDD (behaviour driven development) yapiyorum, ama onun ismi artik BDD degil, BDC (behaviour driven check). Testleri bu sekilde tanimladiktan sonra, kosturuyorum. Sonnet’in olusturdugu test framework testleri kosturmadan önce spec dosyalarini yapisal analiz yapiyor ve akabinde test kodunu olusturarak, bunlari kosturuyor.

Ben bir flutter uygulamasini test etmek icin bu yöntemi sectim. Bir web uygulamasini bu sekilde tamamen yapay zeka yardimi ile test etmek cok daha kolay. Playwright isminde bir MCP server mevcut. Onun yardimi ile Sonnet gibi bir LLM spec dosyasi icinde bulunan test adimlarini MCP araciligi ile bir web tarayicisina baglanarak kosturabilir.

Kisaca özetleyecek olursak:

• Artik test kodu yazmiyorum ya da bakmini yapmiyorum.
• Testlerim kirilmiyor.
• Uygulamanin davranislarina odaklaniyorum ve neyin test edilmesini gerektigini tayin ediyorum.
• Yapay zekanin sadece kodu adapte etmesine izin veriyorum, test kodunu (specler) degil. Bu sekilde neyin test edilecegi hakimiyeti bende kaliyor.
• Yapay zekadan destek alarak genis kapsamli specler olusturabiliyorum.

Bu speclerin olusturulma adimini da su sekilde otomatize edecegim. Jira bünyesinde yeni bir feature tanimlarken onay/kabul kriterlerinin de tanimlanmasi gerekiyor. Ben bir kodlama ajanina bu feature i implemente etmesini söyledigimde, ajan ilk adim olarak gerekli test spec dosyalarini. olusturacak. Ajan isini tamamladiktan sonra test icin olusturdugu spec dosyalarini derleyerek, kosturuyor olacak. Bir hata ile karsilasmasi durumunda implementasyonun istenen seviyede olmadigini anlayarak, gerekli adaptasyonlari yapmaya baslayacak. Böyle bir döngü ile aslinda hic insan interaksiyonu olmadan bir uygulamayi feature by feature implemente ettirmek mümkün.

Test ekibine hos geldin yapay zeka :)