- Büyük dil modelleri (LLM'ler), görsel, metin ve kod üretebilir hale gelerek yaratıcı alanlarda büyük bir etki yarattı
- İlk başta insan eli hatalı çizilmiş görseller, yanlış bilgiler söyleyen çıktılar gibi komik sonuçlar çoktu, ancak giderek iyileşiyorlar
- Bu modeller ortaya çıkmadan önce, makinelerin yaratıcı düşünemeyeceği iddiası otomasyona karşı temel argümandı; ancak artık bu argüman giderek zayıflıyor
- Peki şimdi nereye gitmeliyiz?
Framework: Yazılım geliştirme yetkinlik seviyeleri
- Yazılım geliştirme, yalnızca kod yazmaktan ibaret değil
- Programcı imajı, karanlık bir odada bilgisayara bakıp yoğun şekilde kod yazan biri olsa da gerçekte kod yazmaktan çok başka işlere zaman harcanır
- İş kullanıcılarından gereksinim toplama
- Gereksinimleri koda modellenebilir hale gelecek şekilde rafine etme
- Tasarımcılar ve ürün yöneticileri gibi ekip arkadaşlarıyla çözümü görselleştirme ve planlama
- Diğer geliştiricilerle teknik tasarım yapma ve iyileştirme
- Altyapı kurulumu, yapılandırma, boilerplate vb.
- Gerçek kod yazımı
- Hata ayıklama, başkalarının kodunu anlama, dokümantasyon yazma vb.
- Production dağıtımı
- Production sorunlarına müdahale
- Ve daha birçok iş
- "AI geliştiricilerin yerini alacak" denmesi, AI'ın yukarıdaki işlerin tamamında yetkin olması gerektiği anlamına gelir
- Ancak yukarıdaki listeye bakıldığında, bu işlerin bazıları gelecekte otomatikleşebilir olsa da bazıları henüz otomatikleştirilebilir görünmüyor
Otonom araçlarda otomasyon seviyelerinin sınıflandırılması
- Otonom araç alanı, otomasyon seviyelerini sınıflandırma yöntemi geliştirdi
- Bu sınıflandırma, mevcut teknolojinin neleri yapabildiğini net biçimde açıklar ve siyah-beyaz düşünceden kaçınır
- Bu sınıflandırmayı yapay zeka tabanlı yazılım geliştirmeye uygularsak
- En düşük seviye, daha önce sahip olduğumuz durumdur; yani işte yapay zekanın hiç yer almadığı seviye. Elbette derleyiciler, build süreçleri gibi başka otomasyon türleri vardı ama bunlar yapay zeka değil, insanlar tarafından yazılmış deterministik otomasyonlardı
- Sonraki seviye ise bugün sahip olduğumuz durum
- Geliştiricilerin ChatGPT veya GitHub Copilot kullanarak destek alması
- Geliştiriciler bunu test yazmak, boilerplate kod üretmek, refactoring yapmak, kodu/hataları anlamak için kullanıyor
- Sohbet üzerinden bir ekip arkadaşı geliştiriciyle konuşur gibi soru sorup yardım alınabilir, ancak bilgisayara erişimi olmadığı için dosya oluşturamaz, build komutları çalıştıramaz veya production'a dağıtım yapamaz
- En yüksek seviye ise projenin bir kısmını ya da tamamını bir "AI coder"a devretmektir
- AI coder gereksinimleri alır, kodu yazar, hataları düzeltir ve nihai ürünü production'a dağıtır
- Bunun gerçekleşmesine daha aylar olduğunu düşünüyordum, ancak şu anda yalnızca basit geliştirme görevlerini yerine getirebilse de gelecekte gelişme potansiyeli taşıdığını Devin demosu göstermiş oldu Devin, ilk AI yazılım mühendisi
- AI modelinin yeteneklerinin yanı sıra, çözümün ne kadar doğru olduğunu da düşünmek gerekir
- Bu modeller halüsinasyona yatkın olabiliyor veya istenen sonucu almak için belirli şekilde prompt verilmesi gerekebiliyor
- Bu da benimsemeyi zorlaştırıyor ve çoğu kişinin bu aşamada AI asistanlarından vazgeçmesine neden oluyor
- Ancak bu da iyileşiyor ve en yeni modellerde bu düzeyde prompt engineering gerekmiyor
- Ayrıca model, yalnızca eğitim verisine bağımlı kalmak yerine web'de gezinerek 'öğrenebilmeli'
- Bu, kütüphanelerin ve programlama dillerinin yeni sürümleri çıktıkça önemli hale geliyor
Framework: Dış kaynak kullanılarak yapılan yazılım geliştirme
- Artık yetkinlik çerçevesini kurduğumuza göre bunun ekip ya da organizasyon yapısı üzerinde nasıl bir etkisi olur? Şirketler yazılım geliştirmeyi farklı şekillerde yapar:
- Tamamen in-house
- Az sayıda vendor ile ağırlıklı olarak in-house
- Çok sayıda vendor ile az miktarda in-house
- Tamamen vendor üzerinden
- AI coder, dış kaynaklı bir yazılım vendor'ü/danışmanı gibi düşünülebilir
- Şirket içi ekibin vendor'ün işini denetlemesi önemlidir
- Bu sorun sözleşmelerle çözülebilir, ancak sözleşmeler genellikle belirli bir tedarikçi veya projeyle sınırlıdır; bu yöntemle uzun vadeli hedefler dayatılamaz
- Vendor'ü yönlendirebilecek küçük de olsa bir şirket içi ekip bulundurmak iyi olur
- Aynı şekilde, bir AI coder'ı EC2 instance'ı gibi kiralayabilseniz bile, işi denetleyen yazılım geliştiricilerden oluşan bir şirket içi ekip bulundurmak avantajlıdır
Framework: Yazılım geliştirme, karmaşıklığın modellenmesidir
- İş problemlerini çözmekten söz ederken Excel örneği verilebilir.
- Excel'in giriş eşiği çok düşüktür; bununla veri düzenleyebilir, veri analizi yapabilir veya bazı süreçleri otomatikleştirebilirsiniz
- Ancak ayrıntılı erişim kontrolü, desteklenmeyen sistemlerle entegrasyon, test edilebilirlik, yeniden kullanılabilirlik, vendor lock-in gibi konulardaki eksiklikleri nedeniyle karmaşık iş akışları için uygun değildir
- Power Automate gibi "low-code" çözümler için de durum aynıdır
- "İş kullanıcıları, yazılım geliştiricilerin yardımı olmadan bir AI coder kullanarak bu karmaşık iş akışlarını oluşturabilir mi?"
- Düşününce, Excel ve low-code araçları on yıllardır var; buna rağmen yazılım geliştiriciliği mesleği neden hâlâ varlığını sürdürüyor?
- Bunun nedeni, yazılım geliştirmeyi yalnızca kod yazmak olarak görmek
- Karmaşık problemler, bu karmaşıklığı etkin şekilde yönetebilen ve iş problemlerini gerçek dünyadaki alan bilgisinden dijital modellere dönüştürebilen insanlara ihtiyaç duyar
- Başka bir deyişle, bir inşaat mühendisi yardımı olmadan YouTube eğitimleriyle ahşap bir kulübe yapabiliyor olmanız, 10 katlı bir binayı da aynı şekilde yapabileceğiniz ve yapmanız gerektiği anlamına gelmez
- Bu işi doğru yapmayı öğrenirken zamanla siz de inşaat mühendisine dönüşebilirsiniz
- Mesele sadece bunu düzgün öğrenmek için zaman yatırıp yatırmayacağınız ya da yetkin bir mühendisi işe alıp almayacağınızdır
- Dolayısıyla ister Excel kullanın ister en yeni AI coder'ı, eğer karmaşık mantığı modelliyorsanız hâlâ yazılım geliştiricisisiniz
- Sadece iş gereksinimlerini ifade etmek için kullandığınız araç değişir: spreadsheet formülleri, kod, prompt'lar vb.
Framework: Pastanın büyüklüğü
- Bu konu etrafındaki kaygıların çoğu, yazılım geliştirme pazarının büyüklüğünün aynı kalacağı varsayımına dayanıyor; yani AI coder'ların yavaş yavaş insanlardan "pazar payı" alacağı varsayılıyor
- "İş problemi çözme" pazarının büyüklüğü yazılım geliştirmeden çok daha büyük olduğu için, yazılım geliştirme yakın zamanda ortadan kalkmayacaktır
Framework: Biçimsel iş mantığı tanımı
- İş mantığı her zaman açık ve biçimsel bir şekilde tanımlanmalıdır
- Bu yüzden programlama dilleri, 'if', 'switch' gibi İngilizce sözcükler kullansalar bile bu sözcüklerin anlamını çok katı biçimde tanımlar ve yanlış sözcük kullanılırsa çalışmaz. Düşünürseniz Excel formülleri veya low-code akışları için de aynı durum geçerlidir
- Gelecekte AI coder'lar konuşma dilindeki İngilizce komutlarla yazılım ürünü üretebilse bile, arka planda oluşturulan iş mantığı için temel bir biçimsel tanımın var olmaya devam edeceğini düşünüyorum
- Bu, bugün kullandığımız dil ve framework'lerden çok farklı görünebilir, ancak iş mantığının bu biçimsel tanımı kulağa hâlâ büyük ölçüde 'kod' gibi geliyor
- AI coder'lar bu iş mantığını deterministik bir şekilde konuşma dilindeki İngilizce ile üretebilir hale gelene kadar, arka planda üretilen kodu anlayıp gerektiğinde değiştirebilecek insanlara hâlâ ihtiyaç olacak. Yani yazılım geliştiricilere
Sonuç
- İşin doğası değişecek ve kullandığımız araçlar bugünkünden çok farklı hale gelecek, ancak yakın gelecekte de yazılım geliştiriciler için bir pazarın var olmaya devam edeceğini düşünüyorum
7 yorum
Devin, ilk yapay zeka yazılım mühendisi
OpenDevin - yapay zeka yazılım mühendisi Devin'in açık kaynak uygulaması
OpenAI ün kazanmadan önce bile, yapay zekanın benimsenmesinin en geç olacağı ya da imkansız görüldüğü sanat alanından başlayarak kendi kapsamını genişlettiğini görünce, şu anda yalnızca "insan"ın yapabileceğini düşündüğümüz şeylerin de "güvende" olmayabileceği düşüncesi bir an aklıma geldi.
Ana metin ve https://tr.news.hada.io/topic?id=13557 yazısındaki gibi
şu anda geliştirici pastasının kesin olarak küçüleceği ve bunun daha da hızlanacağı doğru mu?
Yapay zeka promptlarının önemi gün geçtikçe daha fazla öne çıktıkça, daha net spesifikasyon tanımı ve gereksinimlerin düzenlenmesinin zorunlu olduğunun farkına varan kullanıcılar giderek artacaktır; bu da sonuçta gelecekte geliştiricilerin çalışması açısından avantajlı bir yönde etkide bulunabilir gibi görünüyor.
Kod insanların içindir ve makinenin kod yazması hâlâ insana ihtiyaç duyulduğu anlamına geldiğinden, bunun çok uzak geleceğe yönelik bir gelişim yönü olduğunu düşünmüyorum. İlk dönemde denenen backend-GPT'de (https://github.com/RootbeerComputer/backend-GPT) olduğu gibi, istediğimiz soruları bir tür kara kutuya atarsak onun DB'ye erişip veriyi işlemesi ve bunun öncesiyle sonrasındaki deneyime insanın kısmen müdahil olması şeklinde gelişeceğini düşünüyorum.
Sanırım chat GPT ve Copilot hakkında çok konuşulan konulardan biri de prompt engineering. Genelde programlama için toplantılar yapıyor, sözlü olarak hızlıca iletişim kuruyor, toparlayıp teyit ediyoruz; bu süreçleri AI coder'a nasıl verimli biçimde aktarabileceğimiz ve onunla nasıl etkili iletişim kurabileceğimiz de önemli bir unsur gibi görünüyor ^^.
> "Yapay zeka geliştiricilerin yerini alacak" sözü, yapay zekanın yukarıdaki tüm işlerde yetkin olması gerektiği anlamına gelir.
-> Bunlar, insan yaptığı için gerekli olan prosedürler olabilir ve sonuçta tüm bu prosedürlerden geçildiğinde ortaya çıkan kod adlı çıktı belirli bir örüntü taşıyabilir diye düşünüyorum. Tıpkı Go oyununda da açılış dizilimleri ya da joseki gibi şeylerin gerekli olduğu düşünülürken, aslında bunun sadece insanın bilişsel alanı içinde bilgiyi işleyebilmesi için kaçınılmaz bir yöntem olduğunun ortaya çıkması gibi.