AI Kodlama Ajanları Neden Net Gereksinimler İstiyor?

AI Kodlama Ajanları Neden Net Gereksinimler İstiyor?

May 14, 2026 agentic development ai coding software specifications development workflow code generation technical requirements product engineering startup development

Yapay Zeka Zamanında Spesifikasyon Sorunu Hiç Yeni Değildi—Sadece Daha Belirgin Hale Geldi

Ajanlar yardımıyla kod yazmanın içinde gizli kalmış rahatsız edici bir gerçek var: Sorun asla kod yazmak değildi. Sorun hangi kodu yazacağına karar vermekti.

Fred Brooks 1986'da No Silver Bullet adlı çalışmasında bunu zaten fark etmişti. Yapay zeka devrimleri—nesne yönelimli tasarım, zaman paylaşımı, yapılandırılmış programlama—sadece mütevazı ilerlemeler sağlamıştı çünkü hepsi tesadüfi karmaşıklıkla (kod yazmanın karışıklığı) uğraşıyordu, temel karmaşıklığa (düşünmenin zorluğu) değil. Yazılım mühendisliğinin asıl işi her zaman belirtim aşaması olmuştur: paydaşları birleştirmek, dengeleri ayarlamak ve henüz inşa edilmemiş bir sistem için gereksinimleri netleştirmek.

Şimdi kod yazmayı yapay zekaya bıraktık ve herkes belirtim sorununun da ortadan kaybolacağını düşünüyor. Spoiler: kaybolmadı.

"Detaylı Spesifikasyon" ile "Doğal Dilde Yazılmış Spesifikasyon" Aynı Şey Değil

İşte burada işler karmaşıklaşıyor. Günümüz araçlarının birçoğu—yapay zekaya dayalı PRD üreticilerinden görüşlü spesifikasyon doğrulayıcılara—aynı varsayımla çalışıyor: Eğer yapay zeka doğru sorularını sorsa, spesifikasyon boşlukları kendiliğinden kapanacak.

Bu, doğal dilin resmi sistemlerin gerektirdiği hassaslığı kodlayabileceğini varsayıyor. Ama bu ters gidiş.

Resmi gösterim tam da doğal dilin belirsizliğinden dolayı ortaya çıktı. Güzel bir ürün spesifikasyonu yazabilirsin—akıcı, bir hikaye anlatıyor, paydaşlar başlarını sallıyor—yine de bir yapay zeka ajanının güvenilir kod üretmesi için gereken teknik titizliği eksik bırakabilirsin. "Kullanıcılar dashboard'unu 2 saniyede görmeli" ile "Analytics dashboard'unun P95 gecikmesi 2000ms'nin altında, 99. yüzdelik kapağı 5000ms olmalı" arasındaki fark stilistik görünse de, aslında spesifikasyonun ta kendisidir.

Muğlak bir spesifikasyonu yapay zeka kod ajanına beslersin, çıktıda sihirli bir netlik bulmazsın. İki sonuçtan biriyle karşılaşırsın:

  1. Muğlaklık garip kod olarak ortaya çıkar. Ajan teknik açıdan işlevsel ama mimaride sorgulanacak şeyler üretir ve sen üç sprint boyunca refaktorlamekle meşgul olursun.

  2. Ajan boşlukları sessizce doldurur. Eğitim verilerinde var olan desenleri—binlerce benzer proje, binlerce emsal—uygular ve asla almadığın varsayımları güvenle ürüne çıkarır.

İkisinin de kazanç yüzü yoktur.

Ajan Tabanlı Kodlama Gerçekten Nerelerde İşe Yarar?

Açıkçası, ajan tabanlı geliştirme dar alanlarda parlıyor. Landing sayfalar, CRUD uygulamalar, boilerplate entegrasyonlar, standart e-ticaret akışları—bunlar işler çünkü yakınsak problemlerdir. Eğitim verilerinde binlerce benzer uygulama vardır. Ajan yeni zorlukları çözmüyor; çok ölçekte kalıp eşleştiriyor.

Ve bu değerlidir. Tek girişimci yapay zekanın yardımıyla işletme kapasitesini 10 katına çıkarabilir. Küçük bir ekip idari araçları haftalar yerine saatlerde hazır edebilir. Bu gerçek verimlilik.

Ama dikkat et: bu başarı yüksek spesifikasyon netliğinden doğar, ona rağmen değil. Problem alanı o kadar iyi anlaşılır ki spesifikasyon neredeyse örtülü olabilir.

Geri kalan her şey için—kişiye özel iş mantığı, orijinal entegrasyonlar, gelecekteki geliştirmeyi açan mimar kararları—hala insanlar düşünüyor ve o düşünüş işin ta kendisidir. Yapay zeka yazma kısmını hızlandırır. Düşünme kısmını hızlandırmaz. Daha iyi bir yol olduğu için bir şeyi yazmasını reddedemez; sana söylediklerini yazabilir sadece.

Bir geliştirici bunu şöyle demiş: "Yapay zeka kod yazabilir ama X'i yapmadan önce neden daha iyi bir yol olmadığını söylemek konusunda ilk düşünceden geçilmeden kod yazmasını reddedemez." Bu ürün düşüncesi, kod giydirilmiş biçimde. Ve bu değiştirilmez.

Asıl Darboğaz: İnsanlar Arasındaki Teslim Edilen İşte Oluşan Sürtüşme

Eğer spesifikasyon zor kısımsa ve yapay zeka spesifikasyonu çözmüyorsa, ne çözer?

Cevap aldatıcı kadar basit: İnsan iletişimindeki sürtüşmeyi azaltmak.

Bir ürün müdürü mühendise kısa bir açıklama verdiğinde ve o mühendis kenar durumları ve dengeleri anlamak için bir hafta açıklama toplantılarında harcamak zorunda kaldığında, spesifikasyon sorunu var. Bir tasarımcının modelleri kimsenin söylemeyen backend kısıtlamalarıyla çatışınca, spesifikasyon sorunu var. Bir yapay zeka ajanı belirtilmemiş iş gereksinimlerinden sapan varsayımlara dayalı kod üretince, spesifikasyon sorunu var.

Çözüm daha sofistike bir ajan veya daha iyi bir spesifikasyon doğrulama çerçevesi değil. Ajan çalışmadan önce insan arasında sohbete hassaslık zorunlu kılmak.

Bu demek:

  • Spesifikasyon birinci sınıf yapı olarak. Hoş bir belge değil, kod üretiminin bağlı olduğu sözleşme.
  • Açık denge belgelemesi. Neden güçlü tutarlılık yerine nihai tutarlılığı seçtik? Neden bu veri modeli, şu değil? Bu kararlar yazılı olmalı.
  • Hassaslığın önemli olduğu yerlerde resmi gösterim. SQL şemaları, API sözleşmeleri, performans bütçeleri—netliği zorlayan araçlar kullan.
  • Erken ajan geri bildirim döngüleri. Spesifikasyona karşı küçük bir kod dilimi oluştur, sonra spesifikasyonu muğlaklığı ortaya çıkaran koddan öğrenilerek geliştir.

Bu Senin Geliştirme İş Akışı İçin Ne Anlama Geliyor

Eğer yapay zeka yardımıyla üretim sistemleri inşa ediyorsan, tavsiye "yapay zeka ajanlarını kullanma" değil. Spesifikasyona daha ağır yatırım yap, daha azını değil.

"Hızlı hareket et" diye konuşulan bir çağda bu mantıksız görünüyor. Ama muğlak bir spesifikasyonla hızlı hareket etmek sadece yanlış hedeflere daha hızlı vurulur anlamına gelir. Ajan tabanlı geliştirmeyle gerçek kazananlar ajanlardan ne inşa edeceğini bulmalarını isteyenler değil. Ön hazırlıkta zor düşüncelerini yapmış ve ajanları yürütme tarafında bir güç çarpanı olarak kullananlar.

Özellikle girişimler ve küçük takımlar için: senin rekabet avantajın kod üretiminde değil. Spesifikasyon netliğinde. Eğer iş mantığını öyle kesin ifade edebilirsen ki yapay zeka onu güvenilir biçimde uygulayabilirse, zaten en zor sorunu çözmüşsün. Kod üretimi şimdi sadece kolay kısım.

Sonuç

Fred Brooks 1986'da haklıydı ve 2025'te de haklı. Yazılımın temel karmaşıklığı yapısında değil, tasarımında yatıyor. Yapay zeka bu temel gerçeği değiştirmedi—muğlak düşünce ile kesin kod arasındaki farkı işitilir hale getirdi sadece.

Yazılım geliştirmede verimlilik dalgasının bir sonrakisi daha iyi ajanlardan gelmeyecek. Spesifikasyon uygulamalarına acı biçimde disiplin uygulayan, gereksinim mühendisliğini birinci sınıf mühendislik disiplini olarak gören ve yapay zekayı karışıklığı maskelemek yerine netliği büyütmek için kullanan ekiplerden gelecek.

Bu yapay zeka ve yazılım geliştirmenin kesişim noktasındaki asıl fırsat. Ve bu hiçbir ajanın senin için yapamayacağı bir şey gerektirir: gerçekten ne inşa etmeye çalıştığını derinlemesine düşünmek.

Read in other languages:

RU BG EL CS UZ SV FI RO PT PL NB NL HU IT FR ES DE DA ZH-HANS EN