İlk ilkelerden yapay zekâ öncelikli yazılım tasarımı: uygulayıcı rehberi

Çoğu ekip yapay zekâyı altındaki tek bir varsayımı gözden geçirmeden benimsedi; bu yüzden çıktı hızlandı ve sistemler kötüleşti.

İşte çoğu mühendislik ekibinin henüz yüksek sesle söylemediği soru: model kodu yazabiliyorsa artık tam olarak neyde iyi olmamız gerekiyor?

Duyduğum cevaplar çoğunlukla savunmacı. Komut mühendisliği. Yapay zekâ çıktısını gözden geçirmek. Hangi araca uzanacağını bilmek. Hepsi gerçek beceriler, hepsi gerçek kaymanın sonrasında ve hiçbiri pratikte sürekli gördüğüm şeyi açıklamıyor: aynı araçları, aynı çeyrekte, aynı modellerle benimseyen ekipler tümüyle farklı yerlerde bitiyor. Bir grup daha hızlı yayına alıyor ve yazılım tutuyor. Diğeri daha hızlı yayına alıyor ve sonraki çeyreği neyi bozduğunu bulmakla geçiriyor.

Aynı araçlar. Zıt sonuçlar. O fark modelle ilgili değil.

Kimsenin hesaba katmadığı yükseltici

DORA’nın 2025 yapay zekâ destekli yazılım geliştirme durumu raporu buna sayılar koydu. Teknolojide çalışan kişilerin yüzde 90’ı artık işte yapay zekâ kullanıyor ve yüzde 80’den fazlası üretkenliklerini artırdığına inanıyor. Bunların ikisi de şaşırtıcı değil. Önemli olan bulgu üçüncüsü: daha yüksek yapay zekâ kullanımı, yazılım teslim verimindeki artışla ve yazılım teslim kararsızlığındaki artışla aynı zamanda ilişkili.

Bunu tekrar okuyun, çünkü savın tamamı bu. Araç, ekipleri yayına almada hızlandırdı ve şeyleri çalışır durumda tutmada kötüleştirdi. Biri ya da diğeri değil. İkisi.

DORA’nın çerçevelemesi yapay zekânın bir yükseltici olduğu: üzerine düştüğü uygulamayı ne olursa olsun büyütüyor. Güçlü sistemler güçleniyor. Zayıf sistemler zayıf olmada hızlanıyor.

Bu da ilginç sorunun hiçbir zaman “yapay zekâyı nasıl benimseriz” olmadığı anlamına geliyor. “Yapay zekâ bizde neyi büyütüyor” idi. Ve bunu cevaplamak herhangi bir araç kararından daha geriye gitmeyi gerektiriyor.

Araçtan değil sorundan akıl yürütün

İlk ilkelerden düşünmek, anlamsızlığa kadar tekrarlanmış ifadelerden biri; o yüzden bununla ne demek istediğim ve ne demek istemediğim konusunda açık olayım.

Benzetmeyle akıl yürütmek, yapay zekâ benimsemesinin çoğunun göründüğü şey. Bir geliştirme iş akışımız vardı. Yeni bir yetenek geldi. Yeteneğin iş akışına nerede oturduğunu sorduk, onu en az direnç noktasında (genellikle kod yazımında) ekledik ve geri kalan her şeyi aynı bıraktık. Ayakta toplantılar, talepler, iş turları, inceleme, hepsi korundu. İş akışı verili kabul edildi ve araç ona uyduruldu.

İlk ilkelerden akıl yürütmek daha zor bir soru soruyor. Süreci yazılım kurma konusunda gerçekten, fiziksel olarak doğru olana kadar soyun. Sonra bu doğrulardan hangisini modelin değiştirdiğini ve hangisine dokunmadığını sorun. Ayakta kalandan yeniden kurun.

Bunu dürüstçe yapın ve yapay zekânın tam olarak tek bir şeyi değiştirdiğini bulacaksınız; o da kategorinin sattığı şey değil.

Kod üretme maliyeti neredeyse sıfıra gitti. Kodun ne olması gerektiğine karar verme maliyeti kıpırdamadı.

Kullanışlı her şey bu tek asimetriden çıkıyor. Aşağıda, herhangi bir uygulayıcının ezbere söyleyebilmesini istediğim dört sonuç var.

Bir: veri modeli üründür

Ekran her uygulamanın en uçucu kısmı ve başlamak için en çekici yer, çünkü görebildiğiniz kısım. Aynı zamanda atması en ucuz olması gereken kısım.

Veri modeli tersi. Neyi sorabileceğinizi, neyi dizinleyebileceğinizi, herkesi korkutan bir göç olmadan sonradan neyi değiştirebileceğinizi belirliyor. Sonraki her yetenek o katmanda verilmiş, ya da doğaçlanmış, seçimlerle kısıtlanıyor.

Kod pahalı olduğunda bu sıra kendini zorunlu kılıyordu. Kimse üzerinde düşünmediği bir şemaya karşı yüz ekranı elle yazmıyordu, çünkü yüz ekranı elle yazmak bir çeyrek sürüyordu. Üretim o doğal kapıyı kaldırdı. Artık hiçbir insanın gözden geçirmediği bir veri modeline karşı bütün bir arayüz üretebiliyorsunuz ve tamamlanmış görünecek.

O yüzden sıranın bilinçli hale gelmesi gerekiyor. Önce model, sonra sözleşme, sonra arayüz. Geleneksel olduğu için değil; pahalı kararların değiştirmesi hâlâ ucuzken verildiği tek sıra olduğu için.

İki: ertelenmiş bir karar yine de verilir

Bu, uygulayıcıların hafife aldığı olan.

Açıkça vermediğiniz her karar yine de veriliyor. Onu üretici, üretim anında, işinizi, uyumluluk yüzeyinizi, göç geçmişinizi ya da sonraki çeyrek planlarınızı içermeyen bir bağlamdan veriyor. Model karar vermeyi reddetmiyor. Makul bir şey seçip devam ediyor.

Feshedilmiş aboneliği olan bir kullanıcı hâlâ neyi görebiliyor? İki kişi aynı kaydı değiştirdiğinde ne oluyor? Bir posta adresi tek mi ve neyin içinde tek? Bu soruları kimse komutlamadı, o yüzden kimse cevaplamadı ve uygulamanın artık üçüne de bir cevabı var; çıkarımla seçilmiş, yalnızca üretimde ona çarparak keşfedilebilir.

Bu, yapıcı topluluklarının yüzde 70 sorunu diye adlandırdığı şeyin arkasındaki mekanizma. İlerleme kalan iş zor olduğu için değil, kalan iş yüzlerce üretim önce sessizce verilmiş ve tüm şeyi sökmeden artık değiştirilemeyen kararlar tarafından engellendiği için duruyor.

Bunu düzelten uygulamanın artık bir adı var: spesifikasyon odaklı geliştirme. Önce gereklilikleri, kısıtları ve başarı ölçütlerini yazın. O belgeyi doğruluğun kaynağı olarak ele alın. Ajanın ona göre kurmasına izin verin. GitHub Spec Kit’i yayınladı, AWS Kiro’yu yayınladı ve yakınsama bir tesadüf değil.

Üç: üretim bedavayken kısıtların yazılması gerekir

Onlarca yıl boyunca doğruluk kısmen kod yazma maliyeti tarafından taşındı. Bir kuralı gerçekleştiren bir yazılım insanının o kuralı akılda tutması gerekiyordu. Bir insan kafasındaki örtük bilgi, bir kısıtı saklamak için kabul edilebilir bir yerdi, çünkü döngüde her zaman bir insan vardı.

O saklama yeri artık işlemiyor. Bir kısıt makine tarafından okunabilir bir yerde ifade edilmemişse (bir şema kısıtı, bir tip, bir doğrulama kuralı, bir test, bir spesifikasyonda açık bir satır) üretici açısından var değil. Yalnızca şaşırmak üzere olan kişinin belleğinde var.

Bu, yapay zekâ öncelikli tasarımın pratik özü ve gösterişsiz. Değişmezleri onları zorunlu kılabilen katmana itin. “Boş değil” ve “tek” bir form işleyicide değil veritabanında. Tipler bir kod yorumunda değil sınırlarda. Yetkilendirme, birinin bir erişim noktasına yazmayı hatırladığı bir koşul değil sistemin değerlendirdiği bir ilke.

Dışa taşıdığınız her kısıt, modelin artık yanlış yapamayacağı bir karar.

Dört: artık iki kullanıcı için kuruyorsunuz

Son olan en yeni ve çoğu ekibin hiç içselleştirmediği.

Uygulamanızın artık iki tür kullanıcısı var. Biri bir ekrana bakan bir kişi. Diğeri bir programlama arayüzünü çağıran bir ajan; arayüzünüzü hiç görmüyor ve iyi tasarımla ikna edilemiyor. Bir yetenek kullanıcı arayüzünüzde var ama programlama arayüzünüzde yoksa, ajan ekonomisi açısından var değil.

Bunun bir tasarım sonucu var: eşitlik hoş bir eklenti değil. Bir insanın arayüz üzerinden yapabildiği her şey, tanımlı, belgelenmiş ve bulunabilir bir yüzey üzerinden erişilebilir olmalı. Bu ayrıca GraphQL’in ajan kullanımı için REST’ten daha iyi oturmasının nedeni: kendini tanımlayan bir şema, bir insanın önce entegrasyon notları yazması gerekmeden bir makinenin keşfedebileceği bir şey.

Ajan için kurun ve insan arayüzü yan etki olarak basitleşir. Yalnızca insan için kurun ve teslim tarihi baskısı altında bir programlama arayüzünü sonradan ekliyor olacaksınız; bir arayüz tasarlamak için mümkün olan en kötü zaman.

Bunu atlamanın verilerdeki görüntüsü

GitClear 2023’ten 2026’ya 623 milyon kod değişikliğini analiz etti ve sürdürülebilirlik tablosu yukarıdaki her şeyle tutarlı.

2023 taban çizgisine göre tekrarlanmış kod blokları yüzde 81 yukarıda. Tek bir gönderim içinde kopyala yapıştır 2022’de yüzde 9,4’ten 2026’nın ilk yarısında yüzde 15,7’ye çıktı. Hata maskeleyen yapılar yüzde 47 yukarıda. Aynı zamanda dosyalar arası işlev çağrıları, kod yeniden kullanımının mevcut en açık göstergesi, yüzde 35 aşağıda ve kodu düzenleme etkinliği 2022’de değişikliklerin yüzde 21’inden 2026’da şu ana kadar yüzde 3,8’e çöktü.

Mühendislik insanları artık kodu düzenlemekten yaklaşık beş kat daha sık kopyalayıp yapıştırıyor. 2022’de bu oran diğer yöne işliyordu.

Bunların hiçbiri model kalitesi sorunu değil. Yeniden kullanım yerine tekrar, yüzeye çıkarmak yerine yutan hata işleme, olmayı bırakan kodu düzenleme: üretim ucuz ve yapı açıkça kimsenin işi olmadığında elde ettiğiniz şeyler. Çıktı yerel olarak makul ve küresel olarak tutarsız; bu da tam olarak ekrandan başlayan bir iş akışının saptayamadığı arıza biçimi.

Bu hafta başlayarak bu şekilde nasıl çalışılır

Bunların hiçbiri bir yeniden yapılanma gerektirmiyor. Dört ya da beş alışkanlığın sırasını değiştirmeyi gerektiriyor.

1. Veri modelini ilk ekrandan önce yazın. Varlıklar, ilişkiler, çokluk, bir satırı tek kılan şey, silmede neyin ardından geldiği. Buradaki bir saat projedeki en kaldıraçlı saat ve araçların sizi etkin biçimde atlamaya davet ettiği saat.
2. Gözden geçirdiğiniz yapıntı spesifikasyon olsun, kod değişikliği değil. Spesifikasyon doğruysa ve üretim ona sadıksa, binlerce satır üretilmiş kodu gözden geçirmek tiyatro. Onları üreten belgeyi gözden geçirin. Tartışma hâlâ ucuzken spesifikasyon üzerine tartışın.
3. Adlandırabildiğiniz her kısıtı dışa taşıyın. Üretmeden önce asla ihlal edilmemesi gereken kuralları listeleyin ve her birini sistemin onu zorunlu kıldığı bir yere koyun. Konuşmada kalan her şey eninde sonunda konuşmaya hiç katılmamış bir şey tarafından ihlal edilecek.
4. Programlama arayüzünü ürün yüzeyi olarak tasarlayın. Sonra insan arayüzünü onun kullanıcılarından biri olarak ele alın. Bu, mühendislikten çok bir sıralama seçimi ve onu geç sıralamak onu pahalı kılan şey.
5. Yalnızca verim için değil kararsızlık için ölçüm koyun. DORA’nın bulgusu hızın ve kırılganlığın birlikte arttığı; dolayısıyla yalnızca hızı ölçmek size kendi eğiliminizin iyi yarısını gösterecek. Değişiklik başarısızlık oranı ve geri yükleme süresi, yükselticinin sizin için çalışıp çalışmadığını söyleyen sayılar.

Bunun bedeli ne

Bir ödünleşme yokmuş gibi davranmak yerine bu konuda dürüst olmak istiyorum.

Bu şekilde çalışmak bir projenin ilk haftasında daha yavaş ve sonraki her hafta belirgin biçimde daha hızlı. Bu gerçek bir maliyet, başta ödeniyor, tam olarak ivmenin en değerli göründüğü ve bir rakibin görünür bir şey yayına aldığı anda. Bunların hepsini atlayan ekibin kazanıyor göründüğü iş turları olacak.

Disiplin açısından da bedava değil. Kısıtları yazmak bir arayüzün belirmesini izlemekten daha az keyifli. Bir spesifikasyonu gözden geçirmek kodu gözden geçirmekten daha az doyurucu. Bu alışkanlıklar teslim tarihi baskısı altında çürüyor ve bu, onları önemli kılan aynı baskı.

Ve bunun bir kısmı gerçekten uygulanmıyor. Bu hafta sonu bir fikri sınıyorsanız ve sonucu atmayı planlıyorsanız atın: yukarıdakilerin hiçbiri iki günlük ömrü olan yazılım için yapmaya değmez. Buradaki sav, gösterimlerinden uzun yaşayan uygulamalarla ilgili.

Hiçbir zaman otomatikleştirilemeyen kısım

Kod üretimi çevresinde kurulmuş bazı roller küçülecek. Bazıları yok olacak. Aksini iddia etmek kimsenin hazırlanmasına yardım etmiyor ve size her mühendislik işinin güvende olduğunu söyleyen kişiler size iyilik yapmıyor.

Ama asimetrinin gerçekte ne yaptığına bakın. Kararların ifade edilmesini otomatikleştirdi ve kararların kendilerine tümüyle dokunmadı. Ne kurulacak. Ne kurulmayacak. Hangi değişmezler geçerli. Sistemin asla ne yapmaması gerektiği. Sınırların nerede durduğu ve kimin geçmesine izin verildiği.

O iş her zaman zor kısımdı. Yalnızca yazma emeğinin altında gizliydi; iş gibi görünecek kadar pahalı olan yazma.

Yazmak hiçbir zaman iş değildi.

İlgili okumalar

Uygulamanın derinlemesine hali: spesifikasyon odaklı geliştirme. Bir araç seçiyorsanız: 2026’nın en iyi yapay zekâ uygulama oluşturucuları.

Sıkça sorulan sorular

“Yapay zekâ öncelikli yazılım tasarımı” ne anlama geliyor? Bir uygulamayı, kodun çoğunun elle yazılmak yerine üretileceği ve bazı kullanıcıların insan değil ajan olacağı varsayımı çevresinde tasarlamak. Pratikte bu, veri modelinin, kısıtların ve programlama arayüzü sözleşmesinin baştan açıkça tanımlandığı anlamına geliyor, çünkü bunlar üretimin sizin için veremeyeceği kararlar.

Yapay zekâ öncelikli tasarım, yalnızca yapay zekâ kod araçları kullanmaktan nasıl farklı? Yapay zekâ araçları kullanmak, değişmemiş bir iş akışına bir yetenek ekliyor. Yapay zekâ öncelikli tasarım iş akışının işlem sırasını değiştiriyor: arayüzden önce model ve sözleşme, gözden geçirilen yapıntı olarak spesifikasyon, zorunlu kılınabilir katmanlara itilmiş kısıtlar. DORA’nın 2025 araştırması yapay zekâ benimsemesinin verimi ve kararsızlığı birlikte yükselttiğini buldu; bu da araç değiştiğinde ama uygulama değişmediğinde olan şey.

Yapay zekâ döneminde yazılım tasarımının ilk ilkeleri neler? Dördü ayakta kalıyor: veri modeli üründür ve ekran onun bir görünümüdür; açıkça vermediğiniz her karar üretici tarafından örtük olarak verilir; kısıtlar birinin kafasında değil makine tarafından zorunlu kılınabilir bir yerde yaşamalıdır; ve uygulamanız artık hem bir insan arayüzüne hem de ajanlara dönük bir programlama arayüzüne hizmet ediyor ve bunların eşitliğe ihtiyacı var.

Bu şekilde tasarlamak ekipleri yavaşlatıyor mu? İşi eklemek yerine başa yüklüyor. Bir veri modelinde ve bir spesifikasyonda toplanan kararlar, birinin nasılsa verdiği kararlar: ya başta bilinçle ya da sonradan tahmin eden bir model tarafından örtük olarak. İkinci yol düzeltmelerin geldiği yer ve düzeltmeler daha hızlı değil.

Spesifikasyon odaklı geliştirme, yapay zekâ öncelikli tasarımla aynı şey mi? Spesifikasyon odaklı geliştirme uygulama; yapay zekâ öncelikli tasarım daha geniş mimari sonuçlar kümesi. Spesifikasyon odaklı geliştirme, spesifikasyonu yazmayı ve ona göre üretmeyi kapsıyor. Yapay zekâ öncelikli tasarım ayrıca veri modelleme sırasını, kısıtların nerede zorunlu kılındığını ve insan kullanıcıların yanında ajan kullanıcılar için tasarlamayı kapsıyor.

Bunların hepsini atlamak ne zaman sorun değil? Prototipler, gösterimler, tek kullanımlık iç işler ve atmayı planladığınız her şey. Bu yük yalnızca gerçek kullanıcıları, gerçek veriyi ve zaman içindeki değişimi atlatması gereken yazılım için taşımaya değer.