Dört yetişkin şahıs düşünün.

Birincisi yapay zeka araçları ile henüz temas etmedi.

İkinci şahıs ücretsiz yapay zeka araçları ile sadece laklak yapıyor, resim çizdiriyor.

Üçüncü şahıs ücretli yapay zeka araçlarından yararlanıyor ve günlük işlerini yapay zeka ajanları ile otomatize etmeye başlamış.

Dördüncü şahıs üçüncü şahsın yaptığı işlerin yanında yapay zeka araçları ile vibe coding yapıyor ve kendisi için çalışır uygulamalar geliştirmeye başlamış.

– Birinci şahıs: izleyici

– İkinci şahıs tüketici

– Üçüncü şahıs: operatör

– Dördüncü şahıs: üretici

Beşinci bir tip daha var: Sistem tasarımcısı

Beşinci şahıs yalnızca uygulama geliştirmiyor. Birbirine bağlı uygulamaları, ajanları ve iş süreçlerini bir araya getirerek otonom çalışan sistemler oluşturuyor. Gereksinimleri, süreçleri, istisnaları ve başarı kriterlerini tanımlıyor.

Siz hangisisiniz?

Yapay zeka çağında hangisi ayakta kalacak?

Yapay zeka ile standalone bir uygulama geliştirmek birkaç günlük bir çalışma gerektirebilir.

Burada Loop Engineering ile yapay zekaya otonom olarak yazılım geliştirtmek mümkün.

Aynı işi Prompt Engineering ile yapmaya kalkarsanız, birkaç günlük çalışma rahatlıkla bir haftalık tam zamanlı uğraşa dönüşebilir.

Loop Engineering ile her türlü uygulamanın otonom olarak geliştirilebileceğini düşünebilirsiniz. Ancak durum ne yazık ki öyle değil.

Eğer birbirine bağımlı birden fazla uygulama geliştiriyorsanız, işin içine süreçler de giriyor. Bu noktadan itibaren artık tek bir uygulama değil, bir ekosistem ya da platform geliştiriyorsunuz ve bu ekosistemin içindeki süreçlerin en ince ayrıntısına kadar tanımlanmış olması gerekiyor.

“Bunu istiyorum, hadi yap!” demek artık yeterli olmuyor.

Üstelik detaylı tanımlama da tek başına yeterli değil.

Karmaşık bir uygulama ekosisteminin birbirine bağımlı parçalarını oluşturmak, Loop Engineering kullansanız bile haftalar alabiliyor.

Gerekli analiz ve tasarım çalışmaları önceden yapılmadığında loop çok sık aralıklarla bloke oluyor ve sizin müdahale etmeniz gerekiyor. Bu da otonom geliştirme yaklaşımının en önemli avantajını, yani insan müdahalesini en aza indirme hedefini ortadan kaldırıyor.

Özetle:

Küçük uygulamalar (örneğin bir Todo App) geliştirmek için çok fazla mühendislik çalışmasına ihtiyacınız yok. Nasıl bir uygulama istediğinizi söylemeniz ve Vibe Coding yapmanız çoğu zaman yeterli.

Ancak karmaşık uygulama ekosistemlerinde bu çalışma tarzı sürdürülebilir değil.

Burada gerçek yazılım mühendisliği devreye girmek zorunda.

Gereksinim analizi, yazılım mimarisi, süreç modelleme, uygulamalar arası bağımlılıkların yönetimi ve entegrasyon mimarisinin oluşturulması ciddi tecrübe gerektiren işler.

Yapay zeka kod yazma problemini büyük ölçüde çözdü. Ancak neyin, neden, nasıl ve hangi sırayla geliştirilmesi gerektiği problemini ortadan kaldırmadı.

Hatta tam tersine, yazılım mühendisliğinin bu tarafını hiç olmadığı kadar önemli hale getirdi, cünkü otonom yazılım geliştirme, mühendisliğin ortadan kalkması değil, mühendisliğin kod yazımından önce yapılmasıdır.

Yeni bir projeye başladığınızda en büyük sorunlardan biri, projenin lokalde çalışan bir versiyonunu oluşturmaktır. Bunun için kodu, testleri ve dokümantasyonu okumanız, takıldığınız yerlerde çalışma arkadaşlarınıza danışmanız gerekir.

Bunların artık neden gerekli olmadığını kendi yaşadığım bir örnekle açıklayayım.

Altı ay önce Go ile bir Remote Device Management sistemi geliştirdim. Daha doğrusu ben değil, Opus geliştirdi. :)

Altı aydır dönüp bu projeyle hiç ilgilenmedim. Neler yaptığımı bile zar zor hatırlıyorum. Biraz dokümantasyon hazırlamışım. Onları okudum ve kabaca ne yapmam gerektiğine dair bir fikir oluştu. Ama bu bilgiler hala lokalde çalışan bir sistem kurmam için yeterli değildi.

GPT’ye sadece “kokalde çalışan bir sistem istiyorum” demem yeterli oldu.

Şu anda dashboard UI lokalde çalışıyor. Agent’ın derlenmesi ve Android üzerinde çalıştırılması aşamalarını da geçtik. Kısa bir süre sonra Android cihazının ekranına bağlanıp cihazı yönetebileceğim. Üstelik bütün bunları kod okumadan, testleri incelemeden, dokümantasyona gömülmeden ve kimseye soru sormadan yaptım.

Kısaca özetleyecek olursak:

İnsan unutuyor ama yapay zeka unutmuyor.

Daha doğrusu, insanın unuttuğu bilgiyi yapay zeka mevcut sistemden yeniden çıkarabiliyor. Artık bir projeye hakim olmak için önce bütün kodu anlamak zorunda değiliz. Ne yapmak istediğimizi bilmemiz yeterli olabiliyor.

Klasik yazılım geliştirme metotları ve araçları birer birer patlamaya başladı.

Anthropic, Git kullanımından kendi geliştirdiği Scion isimli kaynak kod yönetim sistemine geçmeye başlamış.

Neden?

Günde 30.000’den fazla merge yapan, on binlerce yapay zeka ajanının eş zamanlı çalıştığı bir ortamda Git artık ihtiyaçları karşılamakta zorlanıyor.

Aslında burada çok daha büyük bir dönüşüme şahit oluyoruz.

Bugün kullandığımız yazılım geliştirme araçlarının ve metotlarının neredeyse tamamı insanlar için tasarlandı.

Git, IDE, pull request, code review, sprint, Scrum…

Bunların hepsi insanların kod yazdığı, birbirlerinin kodlarını incelediği ve sınırlı bir üretim kapasitesine sahip olduğu bir dünyanın ürünleri.

Şimdi ise yazılımı insanlar değil, giderek daha fazla yapay zeka ajanları üretiyor.

İnsanlar için tasarlanmış araçlarla, insanlardan binlerce kat daha hızlı çalışabilen ajanları yönetmeye çalışıyoruz.

Doğal olarak bu araçlar ve yöntemler birer birer darboğaza dönüşmeye başlıyor.

Bence önümüzdeki dönemde yalnızca yazılım geliştirme yöntemlerinin değil, yazılım mühendisliğinin bütün araç ekosisteminin yeniden şekillendiğini göreceğiz, cünkü mesele artık mevcut araçları yapay zekaya uyarlamak değil.

Yapay zekanın çalışma biçimine uygun yeni bir yazılım mühendisliği inşa etmek.

Git bunun ilk örneklerinden biri. Sonuncusu olmayacak.

Benim anlamadığım bir şey var!

Yazılımcıların asıl görevi neydi?

Kod yazmak mı?

Hayır! Kod yazmak bir eylem, amaç değil. Amaç, bu eylem aracılığıyla bir ürün ortaya çıkarmak.

Yazılımcıların asıl görevi, istenilen ürünü geliştirmektir. Bundan daha merkezi bir görevleri hiçbir zaman olmadı.

Peki günümüz yazılımcıları yapay zeka ile gelen değişim karşısında neden bu kadar zorlanıyor?

Ürün geliştirmek hiçbir zaman bugünkü kadar kolay olmamıştı.

Buna sevinmemiz gerekmez mi?

Sorun şu ki yıllarca kullandığımız araçları mesleğimizin amacıyla karıştırdık.

Kod yazmayı o kadar merkeze koyduk ki kod yazmadan ürün geliştirilebileceği gerçeğini kabullenmekte zorlanıyoruz.

Oysa değişen şey mesleğimizin amacı değil, o amaca ulaşmak için kullandığımız yöntemler.

Artık mesele ne kadar iyi kod yazabildiğiniz değil, ne kadar iyi ürün geliştirebildiğiniz.

Bence yazılım mühendisliği tarihinde bundan daha heyecan verici bir dönem yaşanmadı.

Eskiden hata bulmak için kod içinde debug yapardık.

En son ne zaman debugger kullandığımı hatırlamıyorum.

Debug yapmak benim için hiçbir zaman iyi bir alışkanlık değildi, çünkü çoğu zaman sistemin nasıl çalıştığına dair zihinsel modeldeki eksikliklere işaret ederdi.

Yapay zeka ile birlikte debugging de bambaşka bir boyuta taşındı.

Artık kodun içinde breakpoint’ler koyup, değişkenlerin değerlerini inceleyerek hatanın kaynağını aramıyorum.

Gördüğüm hatayı yapay zekaya bildiriyorum. O da kodu analiz ediyor, hatanın kaynağını tespit ediyor ve gerekli düzeltmeleri yapıyor.

Benim rolüm ise yapılan düzeltmenin gerçekten problemi çözüp çözmediğini ve sistemin beklenen davranışlarını koruyup korumadığını doğrulamak.

Yani debugging ortadan kalkmadı. Sadece işi yapan değişti.

Eskiden hatanın nerede olduğunu bulmaya çalışırdık. Şimdi hatanın ne olduğunu doğru tarif etmeye çalışıyoruz.

Kod seviyesindeki debugging’den davranış seviyesindeki debugging’e geçiyoruz.

Otuz yıla yakın yazılımcı kariyerimde iki büyük kırılma yaşadım.

Bunlardan ilki imperatif programlamadan fonksiyonel programlamaya geçişti. Çok uzun süre imperatif kod yazmaya alışmış bir beyin, fonksiyonel programlamaya kolay adapte olamıyor. O dönemde çok zorlandığımı hatırlıyorum.

İkinci büyük kırılmayı ise üç sene önce yapay zeka ile tanıştığımda yaşadım. İlginç olan, bu sefer hiç zorlandığımı hatırlamıyorum.

Bunun nedenini düşündüm ve şöyle bir sonuca vardım:

İlk kırılmada düşünme biçimimi değiştirmek zorundaydım. İkinci kırılmada ise zaten sahip olduğum düşünme biçimini doğrudan kullanmaya başladım.

İmperatif programlamadan fonksiyonel programlamaya geçerken beynimi yeni bir programlama paradigmasına adapte etmek zorundaydım. Yıllarca edindiğim alışkanlıklar, yeni düşünme biçiminin önünde engel oluşturuyordu.

Yapay zekaya geçişte ise tam tersi bir durum yaşadım.

Artık algoritmaları adım adım ifade etmek zorunda değildim. Ne istediğimi, neden istediğimi, hangi koşulların sağlanması gerektiğini ve hangi sınırların aşılmaması gerektiğini anlatmam yeterliydi.

Aslında başka bir yazılımcıya iş verirken de böyle davranıyordum. Ona değişkenleri, döngüleri ve koşulları tarif etmiyordum. Problemi ve beklentilerimi anlatıyordum.

Yapay zeka ile de aynı şeyi yapmaya başladım.

Bir başka önemli nokta ise soyutlama seviyesi.

Otuz yıla yakın yazılım geliştirmiş biri olarak zaten uzun zamandır problemleri yalnızca kod seviyesinde düşünmüyordum. Mimari, gereksinimler, iş süreçleri ve sistem davranışları düşünce dünyamın önemli bir bölümünü oluşturuyordu.

Yapay zeka, bu düşünme biçimine doğrudan karşılık gelen bir araç sundu.

Yani yapay zekaya geçiş benim için yeni bir düşünme biçimi öğrenmekten ziyade, zaten sahip olduğum düşünme biçimini kullanabileceğim bir ortama geçmek anlamına geliyordu.

Burada çok ilginç bir paradoks var.

Fonksiyonel programlamaya geçerken beynimi makinenin anlayabileceği farklı bir modele adapte etmek zorundaydım.

Yapay zekaya geçerken ise makine benim düşünme ve ifade biçimime adapte olmaya başladı.

Birincisinde insan makineye yaklaşıyordu.

İkincisinde makine insana yaklaşıyor.

Sanırım yapay zekaya geçişte hiç zorlanmamamın temel nedeni bu.

İlk defa yazılım geliştirmek için bir programlama dilinin düşünme biçimine adapte olmak zorunda kalmadım.

Bu sefer teknoloji benim düşünme biçimime adapte oldu.

Aynen gelen bir yorumu paylaşıyorum. Sonra problemin ne olduğunu açıklamaya çalışacağım.

“ancak ai tarafindan cok kez yanlis sonuc olduguna emin oldugum cevaplar aldim eminmisin dedigimde haklisin deyip yeni bir kod verdi.. ya da verdigi koddaki guvenlik aciklari saymakla bitmez.”

Öncelikle şunu belirtelim:

Bu şekilde yapay zeka ile yazılım geliştirilmez.

Karşınızda deterministik olmayan bir yapı var. Tabii ki zaman zaman kafasına göre bir şeyler anlatacak. Tabii ki size sürekli “Haklısınız!” diyecek. Bunlar yapay zekanın bilinen davranış biçimleri.

Burada üç temel noktaya dikkat etmek gerekiyor.

Birincisi: Yapay zekayı sürekli sorgulayarak, “Emin misin?” diye sorarak doğru sonuçlara ulaşamazsınız. Çünkü verdiği cevapların doğruluğunu kendisinin teyit etmesi güvenilir bir doğrulama yöntemi değildir.

İkincisi: Yapay zeka için kontrol ve denetim mekanizmalarının oluşturulması gerekiyor.

Bu mekanizmaların önemli bir kısmını analiz yeteneği güçlü başka bir yapay zeka modeliyle oluşturabilirsiniz. Her model hem analiz hem de yazılım geliştirme konusunda aynı derecede başarılı olmayabiliyor.

Bir model gereksinimleri analiz eder, başka bir model uygulamayı geliştirir, üçüncü bir model de ortaya çıkan sonucu bağımsız olarak denetler.

Üçüncüsü: Deterministik olmayan bir yapıdan deterministik beklentilerinizi karşılayan çıktılar almak istiyorsanız, çalışma çerçevesini ve beklentilerinizi çok net ifade etmeniz gerekiyor.

Bunun için iki önemli aracımız var:

Onay/kabul kriterleri: Uygulamanın hangi koşullarda doğru çalıştığını tanımlar.

İnvariantlar: Sistemin hangi koşullarda olursa olsun ihlal etmemesi gereken kuralları tanımlar.

Kabul kriterleri olmadan uygulamanın beklenen davranışları sergilediğinden, invariantlar olmadan da sistemin temel kurallara uygun çalıştığından emin olamazsınız.

Ancak bunları tanımlamak da tek başına yeterli değildir. Bu kuralların otomatik olarak doğrulanabildiği mekanizmalar oluşturmanız gerekir. Özellikle güvenlik söz konusu olduğunda bağımsız kontroller de şarttır.

Asıl problem yapay zekanın yanlış kod üretmesi değil, yanlış kodun doğruymuş gibi kabul edilmesine izin veren geliştirme yöntemidir.

Yapay zekaya güvenerek yazılım geliştirilmez. Yapay zekanın ürettiklerini doğrulayabilen bir sistem kurarak yazılım geliştirilir.

Emin mısın diye soran birisi ne yazık ki ne yaptığının farkında bile değildir.

Dikkat ettiyseniz, yapay zekanın yazılımcılar tarafından kabullenilme oranı son altı ayda dramatik bir şekilde arttı.

Eskiden “Yapay zeka kod yazamaz!” deniliyordu. Şimdi ise “Yapay zeka ile kod yazmak mesele değil, asıl mesele onu yönetebilmek!” deniliyor.

Kabulleniş, gerçeklerin her zaman en az 3-6 ay gerisinden geliyor.

Burada çok büyük bir sıkıntı görüyorum.

Çünkü yapay zekanın gelişim hızı ile yazılımcıların bu gelişimi kabullenme hızı arasında giderek büyüyen bir uçurum var.

Eğer bu gidişata yeterince hızlı adapte olunamazsa, bazı şeyler için artık çok geç olabilir.

Örneğin, tecrübeli bir senior developer altı aylık bir zaman diliminde yapay zekayı çok iyi kullanan, onunla uçtan uca ürün geliştirebilen bir yazılımcıya dönüşebilir.

Ama aynı altı ayı, bazı gerçekleri kabullenmekte zorlandığı için kaybederse, kariyerini ciddi anlamda riske atabilir.

Çünkü o altı ay boyunca sadece yapay zeka gelişmiyor. Onu kabullenmiş ve kullanmaya başlamış diğer yazılımcılar da gelişiyor.

Aradaki fark her geçen gün biraz daha açılıyor.

Asıl tehlike yapay zekanın yazılımcıların yerini alması değil, bazı yazılımcıların değişimi kabullenene kadar diğerlerinin çoktan yeni bir seviyeye ulaşmış olması.

Bu yüzden bugün kaybedilen altı ay, yarın altı aylık çalışmayla telafi edilemeyebilir.

Kod yazmak için IDE, yapay zeka ajanlarıyla etkileşime girmek için CLI kullanmak artık gereksiz.

Kod yazmıyoruz. O halde neden bir kod editörü kullanalım?

Ajanlarla sürekli etkileşime girmek de zaman kaybından başka bir şey değil. 30 farklı CLI penceresinde 30 ajanı yönetmeye çalışmak ölçeklenebilir bir yöntem değil.

Yapay zekaya işleri devrediyoruz ama bu sefer de ajanları yönetmek için bilgisayar başına mahkûm oluyoruz.

Geriye ne kalıyor?

– Dark Software Factory

– Loop Engineering

Dark Software Factory, yazılım üretim sürecinin insan müdahalesine ihtiyaç duymadan çalışmasını sağlayan yapı.

Loop Engineering ise bu yapının içinde ajanların iş paketlerini tamamlayana, kabul kriterlerini karşılayana ve sistem invariantlarını sağlayana kadar otonom çalışmasını sağlayan yöntem.

Bu ikisi bir araya geldiğinde IDE’ye, CLI’ye veya ajanlarla sürekli etkileşime girmeye ihtiyaç kalmıyor.

Biz ürünü tanımlıyoruz, kabul kriterlerini ve sınırlarını belirliyoruz. Gerisini yazılım fabrikası hallediyor.

Amacımız yapay zeka ajanlarıyla daha verimli çalışmak değil, onlarla çalışmak zorunda kalmamaktır.

Nokia ile günümüz yazılımcılarının kaderleri arasında ilginç paralellikler var.

Nokia bir zamanlar cep telefonu piyasasının tartışmasız lideriydi. Piyasadaki hakimiyetinin verdiği rahatlıkla kendisini yeterince yenileme ihtiyacı duymadı.

Sonra Apple geldi ve bütün oyunu değiştirdi.

Apple sadece yeni bir telefon üretmedi. Telefonun ne olduğunu yeniden tanımladı.

Nokia’nın elinde dünyanın en iyi mühendisleri vardı. Telefon üretmeyi çok iyi biliyorlardı. Ama artık mesele daha iyi telefon üretmek değildi. Telefon kavramının kendisi değişmişti.

Nokia bu dönüşüme ayak uyduramadı ve piyasadaki hakimiyetini kaybetti.

Gelelim günümüz yazılımcılarına.

Biz de yıllarca yazılım geliştirmeyi kod yazmak üzerinden tanımladık.

İyi yazılımcı olmak; iyi kod yazmak, algoritmaları bilmek, tasarım kalıplarına hakim olmak, temiz kod yazmak ve karmaşık sistemleri kod seviyesinde anlayabilmek demekti.

Bütün mesleki kimliğimizi bu yetenekler üzerine inşa ettik.

Sonra yapay zeka geldi.

Yapay zeka sadece kod yazmayı hızlandıran yeni bir araç getirmedi. Yazılım geliştirmenin ne olduğunu yeniden tanımlamaya başladı.

Artık kod yazmadan yazılım geliştirebildiğimiz bir döneme girdik.

Ama birçok yazılımcı hala eski dünyanın kavramlarıyla düşünüyor.

Yapay zekanın yazdığı kodun kalitesini, okunabilirliğini, hangi tasarım kalıplarını kullandığını tartışıyoruz.

Yapay zekayı daha hızlı kod yazmak için kullanmaya çalışıyoruz.

Tıpkı Nokia’nın daha iyi telefon üretmeye çalışması gibi.

Oysa değişen şey kod yazma hızımız değil, yazılım geliştirme biçimimizin kendisi.

Yazılımcının görevi artık kod üretmekten, üretilecek sistemin ne yapması gerektiğini tanımlamaya, sınırlarını çizmeye ve ortaya çıkan ürünün doğruluğunu güvence altına almaya doğru kayıyor.

Bunun için de farklı yeteneklere ihtiyacımız var.

Problem analizi, gereksinim mühendisliği, sistem tasarımı, kabul kriterleri, invariantlar ve yapay zeka ajanlarını organize edebilme becerileri ön plana çıkıyor.

Nokia’nın mühendisleri bir gecede kötü mühendisler haline gelmediler. Sadece sahip oldukları uzmanlığın değer yarattığı dünya değişti.

Bugün yazılımcıların karşı karşıya olduğu durum da bundan çok farklı değil.

Yıllarca bizi başarılı kılan yetenekler, gelecekte bizi başarılı kılacak yeteneklerle aynı olmak zorunda değil.

Buradaki asıl tehlike yapay zekanın kod yazabilmesi değil.

Asıl tehlike, yazılımcıların kendi mesleki kimliklerini kod yazma becerisinden bağımsız olarak yeniden tanımlayamamaları.

Nokia’nın sorunu telefon üretememesi değildi. Telefonun artık neye dönüştüğünü yeterince hızlı kavrayamamasıydı.

Yazılımcıların sorunu da kod yazamamaları olmayacak.

Yazılım geliştirmenin artık neye dönüştüğünü kavrayamamaları olacak.

One-Shot Product mı, MVP First mü?

Yazılım geliştirirken tek seferde bütün bir ürünü ortaya çıkarmak mı, yoksa birçok iterasyonla bir MVP’yi zaman içinde ürüne dönüştürmek mi daha iyi sonuç verir?

Benim favorim One-Shot Product.

Neden?

İterasyon bazlı MVP geliştirme yaklaşımının büyük ölçüde klasik yazılım geliştirme metodolojilerinden miras kaldığını düşünüyorum.

Eskiden bir ürünü geliştirmek aylar, hatta yıllar sürerdi. Müşteri de çoğu zaman ne istediğini tam olarak bilmezdi.

Bu yüzden önce bir MVP geliştirilir, müşteriye gösterilir, geri bildirimler alınır ve ürün birçok iterasyonla adım adım tamamlanırdı.

Artık bu yönteme eskisi kadar ihtiyacımız yok.

Eskiden aylar süren bir uygulamayı bugün yapay zeka ajanlarıyla birkaç gün içinde ortaya çıkarabiliyoruz.

Benim izlediğim yöntem şöyle:

Önce GPT ile inebildiğim en derin noktaya kadar analiz seansları yapıyorum.

Ürünü bütün yönleriyle ele alıyoruz. Gereksinimleri, mimariyi, iş akışlarını, kabul kriterlerini ve sistem invariantlarını netleştiriyoruz.

İkimizin zihninde de net bir ürün ortaya çıktığında, Loop Engineering için gerekli iş paketlerini oluşturuyoruz.

Ardından GPT + Opus ikilisi devreye giriyor ve Software Factory içinde ürünün geliştirilmesini üstleniyor.

Ben ise ortaya çıkan ürünü finetuning olarak adlandırdığım prompt engineering yöntemiyle tamamlıyorum.

Bu aşama genellikle çok uzun sürmüyor. Çünkü ürün, Software Factory’den çoğu zaman yaklaşık %95 oranında tamamlanmış olarak çıkıyor.

Yani tek vuruşta işin büyük kısmını halletmiş oluyoruz.

Buradaki temel düşüncem şu:

Eksik de olsa bütünden yola çıkıp onu tamamlamak, parçalardan yola çıkıp bütüne ulaşmaktan çok daha kolay.

MVP First yaklaşımında ise parçalar üzerinden ilerleyerek bütünü oluşturmaya çalışıyoruz.

Bu da bana göre ciddi bir zaman kaybına neden olabiliyor. Çünkü her yeni iterasyon, yeni prompt engineering seansları, değişen gereksinimler, yeniden ele alınması gereken mimari kararlar ve mevcut ürün üzerinde sürekli müdahaleler anlamına geliyor.

One-Shot Product yaklaşımında ise önce bütünü zihinsel olarak inşa ediyor, ardından yapay zeka ajanlarına bu bütünü gerçekleştirme görevini veriyoruz.

Önce bütün, sonra parçalar.

Bence yapay zeka çağında ürün geliştirmenin temel prensiplerinden biri bu olmalı.

Yıllarca bize “Yazdığın kod için dokümantasyon da yaz!” dediler.

İlk patlayan her daim kodun içine gömülü Javadoc vari dokümantasyonlar oldu. Çünkü üvey evlat muamelesi gördüler. Kod yazmak daha zevkliydi.

Genel olarak yazılım dokümantasyonunu kod ile güncel tutmak her zaman büyük bir problem olmuştur.

Artık kod yazmıyoruz. Dokümantasyon da yazmamıza gerek yok.

Bunun için bir yapay zeka ajanına “Mevcut sistem mimarisini analiz et ve güncel mimari dokümantasyonunu hazırla.” demek yeterli.

Hatta bir adım ileri giderek, her mimari değişiklikten sonra dokümantasyonun otomatik olarak güncellenmesini sağlayabiliriz.

Böylece dokümantasyon, yazılımcının yapmak zorunda olduğu angarya bir iş olmaktan çıkıp sistemin sürekli güncel tutulan bir çıktısı haline gelir.

Eskiden dokümantasyonu biz yazardık ve kodun gerisinde kalırdı. Şimdi koddan dokümantasyon üretiyoruz.

Bunu neden yazıyorum?

Vellkam Connect bünyesinde her çalışanın erişebileceği bir Bilgi Bankası, Doküman Store ve Akademi bulunuyor.

Akademi, özellikle yeni çalışanların onboarding süreçlerinde ihtiyaç duydukları eğitim materyallerini ve sistem kullanım kılavuzlarını barındıracak.

Yeni bir çalışanı sisteme dahil etmek için ona sistemi anlatan dokümanları vermek yeterli olacak. Üstelik bu dokümanları hazırlayan da sistemin kendisi olacak.

Bu amaçla şu anda onlarca dokümanın otomatik olarak üretilmesini sağlayacak altyapıyı oluşturdum.

Onlarca yapay zeka ajanı, belirlediğim içerik ve format kurallarına göre onlarca, belki yüzlerce PDF dokümanı, kullanım kılavuzu ve eğitim materyali hazırlayacak.

Üstelik sistem değiştikçe bu dokümanlar da güncellenecek.

Buradaki asıl dönüşüm dokümantasyon yazma işini yapay zekaya devretmek değil. Dokümantasyonu, yazılım geliştirme sürecinin doğal ve otomatik bir çıktısı haline getirmek.

Artık dokümantasyon yazılımın gerisinden gelmek zorunda değil. Yazılımla birlikte yaşayabilir.