Yapay zekâ ile uygulama yapmak

Yapay zekâ uygulamanın hangi kısmını gerçekten kuruyor?

Modelleri adil yargılayan bir yanıt bir sayı ister ve biz sayımızı kendi ürünlerimizden birinden aldık; çünkü son satırına kadar sayabildiğimiz tek proje o.

Serbest çalışma pazaryeri eklentimiz rgb-freelance ın üç klasörü var. Ekranlar klasörü 3.231 satır, ekranların arkasındaki mantık 11.597 satır ve görünüm, yani CSS ile JavaScript, 3.135 satır. Toplamda 17.963 satır ve bunun içinde ekranların payı beşte birin biraz altında. Bu bir mobil uygulama değil ve öyle olduğunu iddia etmiyoruz; kullanıcıları, projeleri, mesajları ve dosyaları olan bir web ürünü ve bölünme biçimi mobil uygulamada da gördüğünüz biçim.

Şimdi haritayı modellerin üzerine koyun. O beşte bir, yani ekranlar, modellerin bugün gerçekten iyi kurduğu şeyin ta kendisi: formlar, listeler, boş durumlar, duyarlı yerleşim. Ortadaki o üçte iki, yani kimin neyi gördüğü, paranın nerede hesaplandığı ve sunucu yanıt vermediğinde ne olduğu ise üretilmiş kodun genelde eksiksiz göründüğü ama olmadığı yer.

Yani "uygulamayı yapay zekâ ile yap" iddiası ne yalan ne de hikâyenin tamamı. Daha kesini: en hızlı kısmı daha hızlı yapıyor. Beklentiniz buysa gerçek bir kazanç elde edersiniz; beklentiniz bitmiş bir ürünse aradaki farkı gerçek kullanıcınız olduğunda keşfedersiniz.

Prototipleme hızı: gerçekten değişen şey

Riskler listesinden önce, çok az yapılan bir itiraf: burada gerçekten bir şey değişti ve onu küçümsemek, şişirmek kadar özensiz.

Bir ürüne başlamanın en zor kısmı olan şey, yani bir fikri elle tutulup birine gösterilebilecek bir şeye çevirmek, artık aynı toplantının içinde mümkün. Sahte veriyle üç ekran, bir giriş akışı ve kayan bir liste. Bu, uygulama için web den bile önemli; çünkü insanlar bir fikri telefonda kağıttakinden başka türlü yargılar.

Bu hızın gerçek değeri en az düşünülen yerde: işi çöpe atmanın maliyetinde. İlk sürüm yarım gün sürdüğünde ondan vazgeçmek de kolaydır. İlk sürüme aylarını veren ekipler ona o oranda bağlanır ve kötü fikri daha geç bırakır. Ucuz kodun yalnızca bir tasarruf değil gerçekten stratejik bir avantaj olduğu tek yer burasıdır.

Ve sınırı açıkça söyleyelim, çünkü her yerde bulanıklaşıyor: prototip ürün değildir. Çalışan bir prototip henüz ne gerçek bir kullanıcı görmüştür, ne zayıf bir ağ, ne de bilerek yanlış girdi gönderen birini. İkisi arasındaki mesafe, önceki bölümdeki aynı üçte ikidir ve hiçbir model onu sizin için kısaltmaz. Bu tartışmayla web tarafında karşılaştıysanız, vibe coding, faydaları ve tehlikeleri aynı tavrı kod üzerinde daha ayrıntılı alıyor.

Bir modelin yazdığı uygulamada bozulan dört şey

Bu dördü tahminle yazılmadı; her birinin bir kaynağı var ve her kaynak, aracı satan şirketin kendi sözü.

Bir, uygulamanın içindeki anahtar. Önce bir yanlış anlamayı kaldırmak gerekiyor: uygulamanın içindeki her anahtar tehlike değildir. Google un Firebase anahtarları hakkındaki kendi sayfası, bunların "tasarım gereği herkese açık" olduğunu ve yalnızca projenizi ve uygulamanızı tanımladığını, kurulumunuz kılavuza uyuyorsa sır gibi davranılması gerekmediğini ve kodunuza koymanın güvenli olduğunu yazıyor. Ama aynı sayfa, üretilmiş uygulamalarda tam olarak beliren açık bir istisna taşıyor: herkese açık bir anahtarın izin listesine Gemini Developer API yi asla koymayın. Yani yapay zekâ anahtarını uygulamanın içinde Firebase anahtarının yanına bırakan bir model, görünüşte aynı şeyi yapmış ve fiilen hesabınızı açık bırakmıştır.

İki, kimsenin yazmadığı izin. Üretilmiş kod genelde iyimser yolu eksiksiz kurar, kötümser yolu hiç kurmaz. OWASP Mobile Top 10 birinci sırayı hatalı kimlik bilgisi kullanımına veriyor ve yaygınlığını yaygın, saptanabilirliğini kolay, etkisini şiddetli olarak derecelendiriyor; yani bu hata sınıfı hem sık olur hem de kolay bulunur, ki bu kötü bir birleşim. Üretilmiş koda sorulacak ilk soru şudur: bu kullanıcının buna izni olduğu nerede denetlendi?

Üç, gelecek ay bakımı yapılamayan kod. Önceki ikisinin aksine bu risk bir güvenlik riski değil ve bu yüzden daha geç yüzeye çıkıyor. Sorun kötü kod değil, sahipsiz kod: dört farklı yanıttan gelen, her biri kendi kalıbını taşıyan dört parça ve hiçbirinin neden orada olduğunu kimsenin bilmemesi. Yapay zekâyla hiç ilgisi olmayan basit bir çözümü var: herhangi bir kod parçasını kabul etmeden önce ne yaptığını tek cümleyle söyleyebilin.

Dört, lisans. Burada da gerçek, iki yaygın anlatının da ötesinde ölçülü. GitHub ın Copilot belgeleri, önerilerin herkese açık kodla karşılaştırıldığını ve bir eşleşme bulunduğunda dosyaların adreslerinin ve o koda uygulanan lisansın adının, kendiniz karar verebilesiniz diye kaydedildiğini yazıyor. Aynı sayfa bu eşleşmelerin tipik olarak önerilerin yüzde birinden azında görüldüğünü söylüyor ve daha önemli iki nokta: denetim yalnızca kabul edilmiş satır içi öneriler için çalışıyor ve kendi yazdığınız kod ya da değiştirdiğiniz bir öneri hiç denetlenmiyor. Yani bir ölçüm aracı var ama sınırlı ve açık olması evrensel bir varsayılan değil bir ayar.

Doğru sıra: önce şartname, sonra kod

Yukarıdaki dört maddenin ortak bir kökü var ve teknik değil: henüz kimse kararları vermemişken bir modelden kod yazması istendi. Model karar vermez, boşluğu doldurur ve boşluğu gördüğü en alışıldık şeyle doldurur.

O yüzden sırayı değiştirin. Bu sırayla üç geçiş ve hiçbirini atlamayın.

Birinci geçiş şartnamedir ve içinde hiç kod yoktur: sade dille özellik listesi, verinin şekli ve kimin neyi görüp neyi değiştirdiği. Uygulama arka ucu nedir yazısını okuduysanız, bu o erişim tablosudur ve yeri tam olarak burasıdır, üretimden önce.

İkinci geçiş üretimdir ve girdisi sizin sözlü anlatımınız değil birinci geçişin çıktısıdır. İkisi arasındaki fark büyüktür: özellik listesi ve verinin şekli modelin önündeyken tahmin edecek bir şey kalmaz ve ürettiği kod bir belgeyle karşılaştırılabilir.

Üçüncü geçiş gözden geçirmedir ve kodu üreten oturumun içinde yapılmamalıdır. Tek bir belirli soruyla ayrı bir geçiş: bu kod nerede kullanıcının doğru söylediğini varsayıyor. O geçiş, bir sonraki bölümde tarif olarak beliren şeydir.

Üçünde de geçerli olan ve en basiti olan bir kural: tek cümleyle açıklayamadığınız hiçbir üretilmiş kod projeye girmez. Mutlaka yanlış olduğu için değil, bozulduğunda kimsenin nereden başlayacağını bilmemesi yüzünden. Yapay zekâ ile kod yazmak aynı kuralı programlama dili tarafından açıyor.