Peçete Çiziminden Çalışan Uygulamaya: Yapay Zekayla Bir Fikirden Yazılım Nasıl Geliştirilir
Herkesin uygulama fikirleri vardır. Çoğu “şu güzel olurdu” aşamasında ölür — fikirler kötü olduğu için değil, “bunun var olmasını istiyorum” ile “bu var” arasındaki boşluğun eskiden bir geliştirici tutmayı ya da kod öğrenmeyi gerektirmesi yüzünden. İkisi de bir salı öğleden sonrasında olmuyor.
Bu boşluk şimdiye kadar olduğundan daha küçük. Yapay zeka uygulama oluşturucuları istediğini sade bir dille anlatmana ve karşılığında çalışan bir uygulama almana izin veriyor — veritabanı, arayüz, mantık, hepsi. Bir fikirden uygulamayı aylarla değil, saatlerle geliştirebilirsin.
Ama “istediğini anlat” o cümlede çok ağır bir yük taşıyor. Zor kısım hiçbir zaman kodlama değildi. Gerçekte neye ihtiyacın olduğunu çözmekti.
İsimle Değil, Fiille Başla
Çoğu insan uygulama fikrini bir şey olarak anlatır: “Köpek gezdiriciler için Uber gibi” ya da “Serbest çalışanlar için bir proje yönetim aracı.” Bu bir sunum, spesifikasyon değil. Bir yapay zeka oluşturucusu bununla pek bir şey yapamaz çünkü bir davranışı değil, bir kategoriyi anlatıyor.
İnsanların uygulamanla ne yapacağıyla başla. Üç ile beş arası eylem yaz:
- “Bir köpek gezdiricisi uygulamayı açar ve bugünkü rezervasyonlarını görür”
- “Bir köpek sahibi bir saat dilimi seçer ve bir gezinti ayırtır”
- “Gezdirici bir gezintiyi tamamlandı olarak işaretler ve sahip bir fotoğraf alır”
Bunlar geliştirilebilir. Her biri bir ekrana, bir veritabanı tablosuna ve bir mantık parçasına karşılık gelir. Yapay zeka oluşturucusunun asansör konuşmana ihtiyacı yok — yapılacaklar listene ihtiyacı var.
Mexico City’de bir kişisel antrenör olan Carlos, müşterilerinin seans ayırtabileceği ve antrenmanlarını takip edebileceği bir uygulama istiyordu. İlk denemesi şuydu: “Bana bir fitness uygulaması geliştir.” Sonuç, hazır antrenman planları olan jenerik bir egzersiz kütüphanesiydi — ihtiyacı olan şeyin tam tersi.
İkinci denemesi her gün gerçekten yaptığı şeyleri listeledi:
- Müşteriler hafta için müsait saat dilimlerini görür
- Bir dilim ayırtır ve WhatsApp onayı alır
- Her seanstan sonra Carlos ne yaptıklarını kaydeder (egzersizler, setler, ağırlık)
- Müşteriler geçmişlerini açar ve zaman içindeki ilerlemeyi görür
O ikinci tarif, saatler içinde kullanabileceği bir şey üretti.
Önce Tek Bir Ekran Geliştir
Kafanda on özellik olabilir. Birini geliştir.
Temel soruna en yakın olan ekranı seç — uygulamanın yaptığı ve başka hiçbir şeyin yapmadığı şey ya da insanların en sık kullanacağı şey. Carlos için bu rezervasyon ekranıydı. Diğer her şey (antrenman kaydı, ilerleme grafikleri, bildirimler) daha sonra gelebilirdi.
Tek bir ekranla başladığında, üç güzel şey olur.
Oluşturucunun nasıl düşündüğünü öğrenirsin. Her yapay zeka oluşturucusunun yerleşim, veri yapısı ve etkileşim kalıpları hakkında görüşleri vardır. Tek bir ekran geliştirmek, onunla nasıl iletişim kuracağını öğretir — hangi tariflerin iyi sonuçlar ürettiğini ve hangilerinin daha fazla ayrıntı gerektirdiğini.
Hızlıca kullanılabilir bir şey elde edersin. Çalışan tek bir ekran, yarısı bitmiş on ekrandan çok daha faydalıdır. Carlos’un müşterileri iki saat içinde seans ayırtıyordu. Antrenman kaydı üç gün sonra geldi. Her şeyi birden geliştirmeye çalışsaydı, hâlâ üzerinde uğraşıyor olurdu.
Gerçekten neye ihtiyacın olduğunu keşfedersin. Geliştirmeden önce önemli olduğunu düşündüğün özellikler, kullanmaya başladıktan sonra önemli olanlarla nadiren aynıdır. Carlos ilerleme grafiklerinin can alıcı özellik olacağını varsaydı. Müşterileri iki dokunuşla bir rezervasyonu yeniden planlayabilmeyi daha çok önemsedi.
Bir Arkadaşına Anlatır Gibi Anlat
Bir yapay zeka oluşturucusuyla konuştuğunda, uygulamayı senin yerine geliştirecek bir arkadaşına anlatıyormuş gibi yap. “Çakışma algılamalı bir RESTful rezervasyon API’si uygula” demezsin. “Biri zaten alınmış bir saat dilimi seçtiğinde, onun yerine bir sonraki müsait olanı göster” dersin.
Sade dil, teknik dilden daha iyi çalışır çünkü uygulamaları değil sonuçları anlatır. Yapay zeka uygulamayı çözer. Senin işin, kullanıcının ne gördüğü ve ne yaptığı konusunda spesifik olmaktır.
İyi çalışan bazı tarifler:
- “‘Ayırt’ düğmesine tıkladıklarında, saatin hâlâ müsait olup olmadığını kontrol et. Müsaitse, onayla. Başka biri kaptıysa, bir mesaj göster ve en yakın boş dilimi öner.”
- “Panel üstte üç sayı göstermeli: toplam müşteri, bu haftaki seans ve bu ayki gelir. Bunun altında, müşteri adı ve saatiyle bugünkü seansların bir listesi.”
- “Bir seanstan sonra, ne yaptığımızı yazmak istiyorum — ‘squat 3x10 80kg, bench press 3x8 60kg’ gibi — ve bunun o müşterinin geçmişine kaydedilmesini istiyorum.”
Her birinin kalıbı şu: kim ne yapar, ne zaman ve sonra ne olur.
Önce Kullan, Sonra Düzelt
Herhangi bir şeyin ilk versiyonu, tahmin edemeyeceğin şekillerde yanlış olacaktır. Bu bir başarısızlık değil — bu sürecin kendisi. Yapay zekayla geliştirmenin avantajı, ilk seferde doğru yapman değil. Bir şeyleri düzeltmenin haftalar yerine dakikalar sürmesidir.
Carlos rezervasyon ekranının ilk versiyonunu gördüğünde üç şey onu rahatsız etti:
- Saat dilimleri 30 dakikalık bloklar halinde gösteriliyordu ama seansları 50 dakikaydı
- Bir müşterinin ona doğrudan mesaj atmadan iptal etmesinin yolu yoktu
- Onay mesajı İngilizceydi ama müşterileri İspanyolca konuşuyordu
Her düzeltme on dakikadan az sürdü. Sorunu anlattı, oluşturucu ayarladı ve devam etti. Geleneksel bir yazılım dükkanıyla, bunlardan herhangi biri bir destek talebi ve bir bekleyiş olurdu.
Temel alışkanlık: uygulamanı başkasına göstermeden önce kendin kullan. Her düğmeye tıkla. Her formu doldur. Onu kırmaya çalış. Kendin bulduğun hatalar, kullanıcılarının senin için bulduklarından daha ucuza düzeltilir.
Senden Olmayan Birine Göster
Ona güvenecek kadar kullandıktan sonra, onu bir gerçek kullanıcının önüne koy. Beş değil. On değil. Bir.
Carlos rezervasyon linkini önce teknolojiyle en rahat olan müşterisine verdi. Bir seans ayırttı, yeniden planladı ve sonra ona mesaj attı: “Geçen hafta ne yaptığımızı nereden görürüm?” Henüz antrenman geçmişi görünümünü geliştirmemişti. Ama artık sırada hangi özelliği geliştireceğini tam olarak biliyordu — tahminle değil, gerçek bir insanın gerçek bir şeyi yapmaya çalışıp bir duvara çarpmasını izleyerek.
Bir kullanıcı sana neyin kafa karıştırıcı olduğunu söyler. Beş kullanıcı sana neyin popüler olduğunu söyler. İkinci tür faydalı olmadan önce ilk türe ihtiyacın var.
Hazır Olmadan Yayınla
Uygulamanın faydalı olması için tamamlanmış olmasına gerek yok. Birinin şu anda yaptığı şey yerine — ki bu muhtemelen bir elektronik tablo, bir WhatsApp grubu ya da hiçbir şey — kullanacağı kadar iyi bir sorunu çözmesi gerekir.
Carlos rezervasyon sistemini 15 müşterisinin hepsine sadece üç özellikle yayınladı: bir dilim ayırt, bir dilimi iptal et ve yaklaşan seansları görüntüle. Antrenman kaydı yok. İlerleme grafikleri yok. Ödeme entegrasyonu yok.
Bunları sonraki haftalar boyunca, müşterilerinin gerçekten istediğine göre birer birer ekledi. Antrenman kaydı, üç müşteri aynı hafta istedikten sonra geliştirildi. Ödeme entegrasyonu bir ay sonra, Carlos hâlâ ücretleri nakit ve Venmo ile topladığını fark ettiğinde geldi.
O ilk cumartesi öğleden sonrasının altı hafta sonrasında, 15 ödeme yapan müşterinin her gün kullandığı bir uygulaması vardı. Rezervasyonları yönetiyor, antrenmanları takip ediyor, ilerlemeyi gösteriyor ve randevu hatırlatmaları gönderiyordu. Toplamda belki 20 saat harcamıştı — akşamlara ve hafta sonlarına yayılmış — ve geliştirmeye 0 dolar.
Önceki sistemi bir Google Takvim, bir Google E-Tablo ve bir WhatsApp yayın listesiydi. İşe yarıyordu ama rezervasyon hataları her hafta oluyordu çünkü müşteriler bir saat talep etmeden önce takvimi kontrol etmeyi unutuyordu.
İnsanları Yavaşlatan Üç Hata
Her şeyi birden geliştirmeye çalışmak. Tek bir ekranla başla. Çalıştır. Sonra bir sonraki şeyi ekle. Kapsam kayması, kötü kodun hiç öldürmediğinden daha fazla uygulama fikrini öldürür.
İş akışını anlatmak yerine bir rakibi kopyalamak. Uygulamanı “Calendly gibi ama kişisel antrenörler için” diye anlatırsan, farklı renklerde bir Calendly klonu alırsın. Bunun yerine gerçek iş akışını anlat ve Calendly’nin nasıl çalışman gerektiğine karar verdiği gibi değil, senin nasıl çalıştığına uyan bir şey al.
Mükemmelliği beklemek. İlk versiyonun pürüzleri olacak. Yine de yayınla. Bir gerçek kullanıcının kafası karışmış yüzünden, henüz kimsenin denemediği ekranları bir hafta cilalamaktan daha çok şey öğreneceksin.
Gerçek Engel Hiçbir Zaman Teknik Değildi
Yapay zeka uygulama oluşturucuları var olmadan önce, bir fikrin varsa ve kod yazamıyorsan üç seçeneğin vardı: kod öğren (aylar), bir geliştirici tut (binlerce dolar) ya da fikrin gitmesine izin ver (bedava). Çoğu insan üçüncü seçeneği seçti — fikirleri kötü olduğu için değil, diğer ikisi zaman ya da para açısından pahalı olduğu için.
Şimdi bir fikirden bir uygulamayı bir günde geliştirebilirsin. Bir prototip değil. Bir maket değil. Bir veritabanı, kullanıcı hesapları ve gerçek mantığı olan çalışan bir uygulama. Engel artık teknik değil. Netlik — neye ihtiyacın olduğunu bir yapay zekanın geliştirebileceği kadar spesifik anlatabilir misin?
Bir arkadaşına açıklayabiliyorsan, onu geliştirebilirsin.
Bir fikrin üzerinde oturuyorsan, onu Proyecta ile geliştirmeyi dene. Tek bir ekranla başla — en çok önemli olanla — ve ne olduğunu gör.