Belli bir piyasa icin bir ürün gelistiriyorsunuz. Domain yani alan bilginiz yoksa, ürünün müsteri gereksinimlerini tatmin etme sansi neredeyse sifirdir. Alan bilgisine hakimiyet cok büyük bir önem tasimaktadir. Ne kadar iyi bir yazilimci olursaniz olun, eger alana uzaksaniz ve oradaki sürecleri anlamiyorsaniz, bunlari implemente edecek kodu yazamazsiniz.
Ben ürün gelistirken alan konusundaki eksiklerimi su sekilde tanimliyorum:
– Öncelikle ürün gelistirmeye baslamadan önce genis kapsamli piyasa ve alan analizi yapiyorum. Bu sürecin sonunda alana hakim dili (domain speciifc language) anliyor olmam lazim. Eger anlamakta zorlaniyorsam, analiz netlesmemistir. Bir örnek vereyim. Ürün recetesi dendiginde akliniza ne geliyor? Ilac mi? Ilk akliniza gelen ilac ise, sormaniz gereken soruyu sormamissinizdir. Bu soru “hangi alandayiz” sorusu olmalidir. Yeme icme sektörü dendiginde ürün recetesinin ne oldugunu ve nasil implemente edilmesi gerektigini biliyor olmaniz lazim. Bunu bilmiyorsaniz ürün ve stok yönetimini yapmak icin bir ürün gelistiremezsiniz.
– Ürün gelistirmeye basladigimda alan icinde bulunan ve alana hakim insanlarla birlikte calismaya calisirim. Mutlaka birileri sistemin nasil calistigini cok iyi biliyordur ve size dogru sorulari sordugunuzda anlatacaktir.
– Alanda faal olan diger ürünleri incelerim ve onlarin sürecleri nasil cözdügüne bakarim.
– Eger hicbir muhattap bulamazsam ya ürün gelistirmeyi sonlandiririm ya da karsilastigim konsepleri yapay zeka yardimi ile anlamaya ve implemente etmeye calisirim. Bu cok verimli olmasa da en azindan bir baslangic noktasi olusturabilir. Cogu zaman baska ürünlerde görüp, anlam veremedigim özellikleri de bu sekilde arastirarak, uygulanan konsept ve sürecleri anlamaya calisirim.
Yazilim müsteri icin yapilir. Müsteriinin bazi gereksinimleri vardir. Bu gereksinimler bir alanda vücut bulurlar. Alan piyasa ya da piyasalari kapsar ve gidisati sekillendirir. Kim alan diline hakim ise, piyasayi ve dolayli olarak müsteriyi anlamaya baslar.
Özetle: alan bilgisi candir.
Yapay Zeka İle Kaybolacak Meslekler
Bilindigi üzere yapay zeka aniden hayatimiza girdi ve bircok seyi köklü bir sekilde degistirdi. Bu degisim e fonksiyonu gibi cok daha hizli bir ivme ile devam edecek.
Bunu büyük bir firsat olarak algilayanlar yaninda, büyük sikintilarin bizi bekledigini düsünenler de var. Bircok meslegin yok olacagi ve insanlarin issiz kalacagi söyleniyor. Ben size kimlerin issiz kalacagini ve sadece bunun insanoglunu yasamsal anlamda ne kadar büyük bir darbogaza sokacagini söyleyeyim mi?
– Avukatlar
– Doktorlar
– Pilotlar
– Muhesebeciler
degil!
Onlar yokken de insanlar yasamlarini sürdürüyorlardi.
Asil kaybolacaklarlar ya da yetismeyecekler:
– Sairler
– Filozoflar
– Yazarlar
– Düsünürler
Simdi söyle bir elli senesi sonrasina gidin, kimsenin edebi ve filozofik eserler ortaya koyamadigi (cünkü hic kimsenin artik bu konularla ilgilenmedigi ve yapay zekanin onlara verdigi yüzeysel özetlerle yetindikleri icin) bir dönemde insanlara gelecege yönelik neyin isik tutacagini düsünün. Ne görüyorsunuz?
Sizde insanoglu bu sekilde daha mi hizli gelisecek yoksa daha hizli mi tas devrine geri dönecek?
Insanin biyolojik evrimini bir kenara birakirsak, gercek anlamda zihinsel sicramasi bahsettigim edebi ve filozofik eserler üzerinden olmustur. Günümüzde bile bu eserlere talep cok az iken, yapay zekanin gelismesi ile bizi cok büyük tehlikenin bekliyor oldugunu görmek artik zor degil.
Sair, filozof ve yazar yetistirmeyen toplumlar olaylari sorgulama yetileri olmadigi icin ya yok olurlar ya da kölelestirilirler.
Frontend First
Yapay zeka destekli calisirken uctan uca bir uygulamayi gelistiriyor olmak cok önemli. Kesinlikle frontend icin ayri, backend icin ayri analiz ve implementasyon yapilmamasi gerekiyor. Zaten klasik calisma yöntemlerinde ekipleri en cok mesgul eden durum da bu olmustur; kendi baslarina, koordine etmeden is yapmalari ya da backendin arayüzleri istedigi sekilde yönlendirmeye calismasi.
Örnegin backend tarafinda gerekli oldugunu düsündügünüz yeni bir özelligi implemente etmeye baslamayin, cünkü arayüzün ihtiyaclarini tam olarak bilemediginiz icin bu analiz / implementasyon eksik olacaktir. Bu yüzden öncelikli olarak mock vari bile olsa önce client konumunda olan arayüzün (frontend) tasarlanmasi ve ihtiyaclarinin öncelikli olarak implemente edilmesi gerekmektedir. Arkasi zaten corap sökügü gibi gelecektir.
Kendi projemdem kücük bir örnek vereyim. Tamamlanmis bir sale icin refund yapilmasi gerekiyor. Bunun icin su anki durumumuzu kiyaslayarak nelerin eksik oldugunu ve nasil implemente edilmesi gerektigini ögrenmek amacli bir analiz baslattim. Gelen cözüm önerisi makul duruyor, lakin gercekten bu kadar derin degisiklige ihtiyacimiz olup, olmadigina dair aklimda soru isaretleri olustu. Eger devam etseydim arayüzü bu degisiklikleri kullanmaya mecbur birakacaktim. Bunun yerine diger yolu yani topdown (yukaridan asagiya) yönetimi uyguladim. Arayüzü olmasi gerektigi sekilde tasarladim ve gerekli apileri ve api degisikliklerinin backend kanadinda implemente edilmesini sagladim. Bu sekilde sadece backend tarafinda gercekten ihtiyac duyulan yapilar olusmaya basladi ve ilk basta sunulan analizin overengineered oldugunu gördüm.
Yazilim gelistirme sürecinde takip edilmesi gereken bir patika var. Bu patikanin basinda müsterinin kendisi yer aliyor. Müsterinin gereksinimleri dogrultusunda arayüzler olusturulur. Akabinde bu arayüzlerin ihtiyac duydugu backend apiler implemente edilir. Backend kesinlikle bir servis katmanidir ve frontend ne istiyorsa, saglamak zorundadir. Bakmayin siz backend yazilimcilarin bu kadar havali olduklarina :) Evet zor kisim backend ama patron her daim frontenddir. Frontend ne isterse, o yapilir. Gereksinimlere hakim olanlar da frontend yazilimcilaridir.
Yapay zeka ile bu ayrim artik ortadan kaltigina göre, “frontend first” ile baslanmasi müsterinin gereksinimlerini tatmin edecek en iyi cözüme götürecektir.
Yapay Zekaya Güvenmek
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.
Bitti mi?
Yapay zeka bir uygulama özelligi tamamladiginda, bilin ki o özellilk daha cok eksik.
Yapay zeka sahip oldugu context kadar duruma hakim olabilir. Bilgi ve veri eksikliginden dolayi durumu 360 derece analiz etme ihtimali cok düsük. Bu yüzden bir uygulama özelliginin kapsamini yaziimci tayin etmek ve akabinde kontrol etmek zorundadir.
Siz bitti dediginizde bile bitmemis olabilir. Burada yapay zekanin mevcut durumu analiz etmesini istediginiz taktirde, eksik kalmis yanlari size göstebilir. Buradaki en önemli ana unsur contextin kapsayicilik özelligidir. Context icinde ne kadar cok net bilgi varsa, olusturulan uygulama özelliginin o oradan tamamlanmis olma itimali yükselir.
Burada benim cikardigim sonuc su: yapay zeka ile iteratif calismak gerekir. Her yeni bir iterasyon ile her iki taraf icin de yapilmasi gerekenler daha da netlesecektir. Her yeni iterasyon contexxt kapsama oranini artirir.
Yazılımda Döngüler
Yapay zeka ile yazilim yaparken benim döngülerim
– Gereksinimleri kücük parcalara bölüp, gerekli promptlar ile yazilimi yaptiriyorum.
– Yapay zeka entegrasyon testleri yazarken, ben onay/kabul kriterleirni ihtiva eden test specleri hazirliyorum. Bu specleri test koduna yapay zeka cevirip, kosturuyor.
– Implementasyon esnasinda kodu kabaca gözden geciriyorum ve yapay zekanin her prompt sonrasinda sundugu cözümü gözden geciriyorum.
– Implementasyon düsündügüm sekilde calisiyorsa yani uygulama blackbox olarak beklentilerimi karsiliyorsa, implementasyonu tamamlanmis sayiyorum.
– Daha güclü bir model ile otomatik code review yaptirip, acik ya da buglari analiz ettiriyorum.
– Bulunan buglar icin tekrar gerekli promptlar ile kodsal düzeltmelere gidiyorum.
– Cikan kodu tekrar daha güclü olan model tarafindan analiz ettiriyorum.
Bu islemlerin sonunda tüm onay/kabul testleri, entegrasyon testleri ve manuel testler calisiyorsa, kod prod ready statüsüne geciyor ve deploy ediliyor.
Nyet!
Tribünden bir futbol maci seyrederek, iyi bir futbolcu olunabilir mi? Nyet!
Teknolojik gelismeleri takip ederek, iyi bir yazilimci olunabilir mi? Nyet!
Insanin yaptiginda iyiye götüren tek birsey var: Just do it!
Teknolojik gelismeler büyük bir dalga gibi gelirler. Surf yapanlar o dalganin gücünü kullanirlar. Dalganin karsisina gecip, izlerseniz, gelir ve bir zaman sonra cekilir. Dalganin üzerindeyseniz, sizi tasir. Ayni sey yazilim teknolojileri icin de gecerlidir.
Ögrenmek ve yapmak iki kardes gibidir, yapmak ögretir, ögrenmek icin yapmak gerekir.
Amiga Efekti
Amiga 500 sahibi olanlar bilirler. Ram extension slotu vardi. 512KB olan hafizayi yine 512KB bir kart ile 1MB yapmistim.
Yapay zeka ile böyle bir analoji yasiyorum. Söyle ki:
Temelde yapay zeka yazilimcinin contextini büyütmüs oldu.
Yazilimci bu yeni context ile daha karmasik yapilara hükmedebiliyor, daha fazlasini görüyor, analiz edebiliyor ve daha hizli karar verebiliyor.
Aslinda yapay zeka yazilmcinin mevcut kapasini artirmak icin kullanabilecegi bir ram ve cpu extension karti.
Ben Amiga bilgisayarimin hafizasini 1MB ye yükselttigimde hicbir degisiklik hissetmemistim. Ama yapay zekada durum cok cok farkli ;-)
Iste yapay zeka bazilarinda Amiga efekti olustururken, bazilarinda level atlatan bir basamaga dönüsecek.
Claude Opus
Opus 4.7 ile deneyimlediklerim:
Yeni Opus’dan 4.6 ile yaptirdigim karmasik bir veri senkronizyon implementasyonunu analiz etmesini ve aciklarini bulmasini istedim. Yirmiye yakin madde iceren bir liste olusturdu. Bunlardan dört tanesi cok kritik. Özellilkle bunlardan ilki bir güvenlik sorunu.
Bu hatalarin critical ve high olanlarini ortadan kaldirmasini istedim. Sekiz saat süren bir calisma sonunda mevcut implementasyonu da calismaz hale getiren bir sonuc ortaya cikardi, calisan seylerde calismaz oldu.
Bu noktada Opus 4.6 birkac iterasyon ile yaptigi ya da buldugu hatalari düzeltebiliyorken, Opus 4.7 halüsinasyon sebepli gereksiz, hatali ve anlamsiz analizler sonunda implementasyonu daha da kötülestirdi.
Opus 4.7 cok iyi analiz yapabiliyor, lakin önerilerini karmasik mimari ve yapidaki bir kod tabaninda implementasyon ile taclandirmakta cok zorlaniyor. Burada islemci gereksinimini minimize edebilmek icin context kapasitesi üzerinde degisiklige gidilmis gibi duruyor. Bu yüzden Opus 4.7 benim güvenimi yitirdi.
Bundan böyle ben implementasyonu Opus 4.6 ile yapmaya devam edecegim. Akabinde Opus 4.7 ile mevcut aciklari analiz ettirip, bunlarin yine Opus 4.6 tarafindan islenmesini saglayacagim.
Opus 4.7 Opus Mythos’un temelini olusturuyor büyük bir ihtimalle, cünkü critik güvenlik sorunlarini bulmakta cok yetkin.
Lütfen
Opus-4.7 daha bi özgüveni yüksek mi ne?
Bir sorunu analiz etmesini istedim. “Tam stack lazim, yoksa sallamis olurum” diyor :).
Opus 4.6 olsa “stack lazim, verebilir misin” diye sorardi.
Yakinda o sihirli sözü söylemedin ama filan der bu.
Biraz önce ilk defa 3 gün süren bir rate limit yedim. Hemen baska bir hesap acip devam ettim. Opus’un kafasi bozulunca rate limit ile tehtit eder giibime geliyor ;-) O yüzden artik her prompt lütfen ile baslayacak.
Ben tirstim iyice. 3 bün ban ne demek ya! Bütün isin alt-üst olur. Günün sonunda kendim yaparim da, bu rahatliga alisinca artik hersey daha zor. Hicbir sey eskisi gibi olamaz artik.
Ne günlere kaldik (geldik) ya!
Zayıf Bağlam
Yapay zeka baglam sorunu nedeni ile alzheimer hastasi gibi yaptigi cogu seyi unutabilir.
Bu kücük capli islerde sorun teskil etmiyor. Lakin bir sorunu cözmek icin daire icinde dönmeye basladiginda, zayif bir baglam yapay zekanin birbiri arkasina hep ayni cözümleri uygulayarak, degisik sonuclar almaya calismasina sebep olabilir.
Burada yazilimcinin bu döngüyü kirmasi ve yapay zekaya daha önce kullandigi cözümlerin hatirlatilmasi, bunlarin bir ise yaramadiginin, sorunu tekrar baska bir perspektiften degerlendirmesi gerektigi söylenebilir. Ayrica “ayni hatalar olusuyor, dairede dönüyoruz, sorun neden cözülmüyor” gibi sözler de yapay zekayi sorunu degisik acilardan incelemeye zorlayabilir.
Bundan sonra masasinda ajanlarina bagiran, cagiran, onlari zorbalayan yazilimci görürseniz, sasirmayin :-)
Dağarcığın Gücü
Yapay zaka ile ortaya cikan isin kalitesi, yazilimcinin yetenekleri ile dogrudan iliskilidir. Yazilimci neyi yapabiliyorsa yani neye kadir ise, onu yapay zekaya yaptirabilir. Buradaki tek fark; kendisinin yapmiyor, yaptiriyor olmasidir.
Yazilimci kendisinin tek basina olusturamayacagi bir cözümü yapay zekaya yaptiramaz. Yaptirsa bile bu tesadüfi cözümü ne yönlendirebilir ne de anlayabilir.
Kelime hazinesinin genisliginin ifade gücü üzerindeki etkisi ne ise, yazilimcinin yetenek, bilgi ve tecrüsinin yapay zeka destekli cözümlerin basarisi üzerindeki etkisi de odur.
Gercek hayatta oldugu gibi yapay zekada da onu kullananin dagarciginin gücü sonucu belirler.
Gereksinimlere Odaklanma
Eskiden bir uygulama bünyesinde herhangi birsey yapilmak istendiginde sürec yazilimci icin söyle isliyordu:
Yazilimci ne yapilmasi gerektigini anladiktan sonra, bu gereksinimi hayata gecirmek icin teknik detaylar ile boguslaya basliyordu. Bu bogusmaca sonucunda asil gereksinim yazilimci odagindan cikiyor ve teknik cözüm onun yerini aliyordu. Bu sebeple istenilen degil de teknik olarak yapilabilen ortaya cikiyordu cogu zaman.
Yapay zeka ile bu odak kaynamasi artik gerekliligini yitirdi, cünkü yazilimcinin teknik detaylar ile ugrasma zorunlulugu azaldi ve bu mental yükün hafiflemesi ile tamamen yazilimci müsteri gereksinimlerine odaklanabilmekte.
Yazilimda esas olan zaten budur, müsteri gereksinimlerine odaklanma!
Analizin Analizi
Yapay zeka insanlarda oldugu gibi dogru analiz yapamadigi taktirde karmasik cözümler üretebiliyor. Söyle daha kolay olmaz mi dediginizde, haklisiniz cok karmasik düsünmüsüm, bu benim düsündügüm cözümden cok daha mantikli ve basit diyebiliyor.
Burada öne cikan durumlar:
- Yapay zaman hersey dogru analiz ve dogru implementasyonu secemeyebilir
- Yazilimcinin bu analiz sonuclarini analiz ederek, daha kolay bir cözüm olup, olmadigini kestirebilmesi ve yapay zekayi bu baglamda yönlendirebilmesi gerekebilir
- Yapay zeka tüm contexte hakim olamadigi icin ürettigi cözümler cogu zaman KISS konform olmayacaktir
- KISS olmadan zaman icinde uygulama altyapisi cok karmasiklasir ve bakimi zor hale gelir. Bu yapay zeka ile yeni özellikler ekleme sürelerini drastik bir sekilde artiracaktir.
Sonuc: sadece kod yazmayi yapay zekaya devretmek mantiklidir. Ama o implementasyona giden gerensinim ve cözüm analizi yazilimcinin sorumlulugundadir. Ilki vibe coding, ikincisi profesyonel yazilimcilik icin gerekli tek yol.
Huma Context Switch
Yapay zeka ile calisirken en limitleyici faktör yazilimcinin kendisi.
Yazilimci birden fazla ajan ile calisirken baglamlari (context) yönetimesi, context switch nedeni ile onu cok zorluyor.
Örnegin ben bu yaziyi yazarken hem frontend hem de backend ajanlari onlara verdigim görevleri yapiyorlar, ama ben kismen hangisinin hangi isi yaptigina dair bilgiyi bu yaziyi yapmak icin zihnini toplamak ve context switch yapmak zorunda oldugum icin unutuyorum.
Yapay zeka ile calisirken cözülmesi gereken bir sonraki challenge human context switch. Bu büyük bir ihtimalle yazilimciyi tamamen devre disi birakarak mümkün olacak.
Yapay Yeka İle Calışırken En Büyük Challenge
Yapay zeka ile calisirken en büyük challenge nedir?
Uydurup, uydurmadigini anlamak ve ona göre aksiyon almak.
Bir yazilimci bunu nasil tespit eder?
Yazilim tecrübesi, genis bilgi ve genel kültür seviyesi, problemi gördügünde nedenini (root cause) ic güdüsel olarak sezme kabiliyeti vb yetiler.
Böyle bir yazilimci min. 10 senede yetisebilir, o da gece gündüz kendisine bir seyler katma cabasi icinde olursa.
Ne yazik ki yazilimda da diger mesleklerde olundugu gibi hop diye saglam bir yazilimci olunamiyor. Bunu yapay zekayla da degistiremeyecek.
Bknz: https://kurumsaljava.com/2012/08/12/aci-cekmeden-ustad-olunmaz/
Çevik Yazılımın Rönesansı
Yazilim dünyasinda tas üzerinde tas kalmiyor :) Dogru bilinenler ve uygulamalar artik kendiliginden ortadan kalkmaya yüz tutuyor. Bunlarin basinda garip toplantilar var. Digerlerine diger yazilarimda deginecegim.
Düsünsenize ortada yazilim ekibi bile kalmamis, tek bir yazilimci kocaman bir ajan ordusunu orkestre ediyor ve toplanmaya gönüllü olanlar sadece yönetici tayfasi, cünkü yapacak baska isleri yok. Gözünüzde canlandirin bi… Toplanti odasinda tek bir yazilimci var ve en az 5-6 tane yönetici, scrum master, menicır, bilmem nerenin baskani vs oturuyor. Sadece toplantilar degil, bu yönetici tayfasi da ortadan kalkacak. Ajanlarin onlarin yerine gecmesi an meselesi :)
Cevik olmak icin ne gerek miyordu?
– Yönetici tayfasi
– Programciya neyi nasil yapildigini söylemek
– Takimi programci, analizci, testci diye ayirmak.
Cevikligin özünde ne vardi?
– Yapilacak tüm yazilimla ilgili isi yazilim ekibine devredip, aradan cekilmek
– Yazilimcilarin isine karismamak
– Tüm kararlari onlarin vermesini ve sorumlulugu almalarini saglamak.
Simdi bir bakiyorum da, artik yapay zeka ile full cevik yazilim yapabilmek icin tüm imkanlar bir araya gelmeye baslamis gibi görünüyor.
Cevik yazilimin rönesansi bu.
Hangisi Daha Verimli
Hangisi daha verimli?
1. Frontend programcisi api gereksinimlerini backend programcisina delege ediyor ve IO veri yapilari üzerinde uzlasma saglamalari gerekiyor. Test, entegrasyon vs derken aradan uzun bir zaman geciyor ve api tam istenildigi sekilde calismayabiliyor. Bu beraberinde uzlasma seanslari getiriyor. Frontend programcisi backend ve api development konularinda kendisini tamamen saliyor ve UI harici bir is yapmiyor. Ayni sekilde backend programcisi asil gereksnimlerden bihaber api programlamaya devam ediyor ve gereksinimleri anlama konusunda frontend yazilimcisina bagimli hale geliyor.
2. Tek bir programci hem frontend hem de backend icin gerekli calismayi yapiyor ve ihtiyac duyulan apiyi client driven backend tarafinda olustuyor. Uzlasmak zorunda kaldigi birisi olmadigi icin client icin gerekli tüm apileri ihtiyac dogrultusunda olusturuyor.
Eskiden fullstack denen bir yazilimci tipi vardi. Full denmesine ragmen ekseriyetle frontend kismindan sorumluydu. Gereksinimleri anlama konusunda backend yazilimcisindan bir adim öndeydi, cünkü müsteriye ya da son kullaniciya daha yakindi. Lakin backend konsunda cok zayifti.
Fullstack rolü tamamen tarihe karismistir. Bunun yerine bir backend yazilimcisi her iki tarafida tek basina koordine edebilecek sekilde 2 numarali satirda bahsettigim sekilde sekilde fullstack calisabilir.
EOF (End Of Fun)
Konuyu Bilmiyorlar
Yapay zeka ile gelinen son nokta…
1. En radikal yazilimcilar yazilimi tam anlamiyla birakti ve sadece gereksinimlere ve testlere odaklaniyolar.
2. Is yerinde yapay zeka kullanmasi yasak olanlar gizli gizli kendi bilgisayarlarinda kodu yazdirip, google drive ya da baska bir storage üzerinden bu kodu alip, kopyala, yapistir yapiyorlar. Bunlar aslinda birinci grupta olan yazilimcilar.
3. Yapay zekayi kesfedenler. Onlar ya kisa zamanda 1. ya da 2. gruba terfi edecekler ya da bir ise yaramadigini düsünüp, vazgececekler. Vazgecmelerinin tek sebebi yazilim konusunda temelde yeterli olmamalari.
4. Isittileri kadar konuya vakif olan yazillimcilar. Bunlarin icinden 3. gruba dahil olma potansiyeli olanlar merakli olanlari. Merakli olmayanlar bu isi birakmak zorunda kalacak olanlar.
5. Hicbir seyden haberi olmayanlar. Onlara Cem Yilmaz’in bu skecini birakiyorum