Özellik Bazlı Yapay Zekâ Yapım Maliyeti Tahmini — Basit Bir Bütçe Yöntemi

Neden yapay zekâ yapım maliyetleri öngörülemez hissedilir

Yapay zekâ destekli yapım süreçleri, aniden pahalılaşana kadar ucuz hissedebilir. Çünkü sabit bir özellik fiyatı için ödeme yapmıyorsunuz. Denemeler için ödüyorsunuz: mesajlar, üretilen kod, revizyonlar, testler ve yeniden çalışma. Plan bulanıksa, deneme sayısı hızlıca artar.

Çoğu maliyet sıçraması aynı birkaç kalıptan kaynaklanır:

• Kapsam ima ediliyor, yazılmıyor (örneğin "auth ekle" ama roller, sağlayıcılar veya parola sıfırlama yok).
• Yeniden denemeler birikir (neredeyse doğru olan bir prompt 3–10 takip isteğine yol açar).
• Spesifikasyonlar inşa sırasında değişir (yeni alanlar, yeni ekranlar, farklı kurallar), bu yüzden önceki işler değiştirilir.
• Gizli gereksinimler geç ortaya çıkar (yükleme, doğrulama, kenar durumlar, hata durumları).
• "Bir küçük düzenleme daha" sessizce birden fazla ekranda yeniden tasarıma dönüşür.

Tahmin yaparken, aslında nelere bütçe ayırdığınızı netleştirin:

1. Platformunuzun talep ettiği krediler veya kullanım birimleri
2. Tokenlar (promptların ve çıktının boyutu)
3. Zaman (sizin inceleme, test ve düzeltme süreniz)

Her tahmini tek bir sayı değil, bir aralık olarak değerlendirin. Bir özellik UI'da küçük görünüp mantık açısından büyük olabilir ya da tam tersi. En iyi durum güçlü bir ilk taslaktır. En kötü durum birkaç düzeltme döngüsüdür.

Bu rehberin geri kalanı tekrarlanabilir özellik kovaları kullanır: auth, CRUD, entegrasyonlar ve UI yeniden tasarımları. Kredi tabanlı bir vibe-coding platformu kullanıyorsanız, örneğin Koder.ai (koder.ai), bunu çabucak hissedersiniz: "bir gösterge paneli oluştur" ile başlayıp sonra roller, denetim kayıtları ve yeni bir düzen eklemek, bu kısıtlamaları baştan yazmaktan çok daha fazla kredi yakar.

Krediler ve tokenlar basitçe

İnsanlar genellikle üç farklı fikri karıştırır: tokenlar, krediler ve yapım adımları. Bunları ayırmak maliyetleri tahmin etmeyi kolaylaştırır.

Bir token, modelin okuduğu ya da yazdığı küçük bir metin parçasıdır. Promptunuz token kullanır, modelin cevabı token kullanır ve uzun bir sohbet geçmişi modelin tekrar okuması gerektiği için token kullanır.

Bir kredi, platformunuzun kullandığı faturalama birimidir. Koder.ai gibi araçlarda krediler genelde model kullanımını ve sohbetin arkasındaki platform işlerini kapsar (örneğin ajanların görev çalıştırması, dosya oluşturma ve sonuçları kontrol etme). İç detayları bilmenize gerek yok, ama kullanımın neyi büyüttüğünü tanımanız gerekir.

Bir yapım adımı, projede yapılan anlamlı bir değişikliktir: "e-posta ile giriş ekle", "kullanıcılar tablosunu oluştur", veya "bu ekranı bir endpoint'e bağla" gibi. Tek bir özellik genellikle birçok adıma ihtiyaç duyar ve her adım birden fazla model çağrısı tetikleyebilir.

Kullanım, uzun bağlam (büyük speslar, devasa sohbet geçmişi, referans verilen çok sayıda dosya), çok sayıda yineleme, büyük çıktılar (tam dosya yeniden yazımları, büyük kod blokları) veya modelin tahmin etmek zorunda kaldığı belirsiz istekler olduğunda hızlıca yükselir.

Küçük prompt değişiklikleri maliyeti sarsabilir çünkü kaç denemeye ihtiyaç duyduğunuzu değiştirir. "Eksiksiz bir auth sistemi" istemek, istemediğiniz seçenekleri davet eder. "Sadece e-posta ve parola, sosyal giriş yok, tam olarak iki ekran" ise hareketli parçaları azaltır.

Geçerli bir kural: daha az hareketli parça, daha az yeniden deneme demektir.

Özellik-öncelikli maliyet tahmin yöntemi

"Ekranlar" veya "mesajlar" yerine, kullanıcının yüksek sesle adlandıracağı özellikler üzerinden tahmin yapmayı bırakın. Bu bütçeyi çıktılara bağlar, sohbetin ne kadar konuşkan olduğuna değil.

Her özellik için üç kısmı tahmin edin:

• Build: kodu üret ve uygulamaya bağla
• Test: akışı çalıştır, bariz hataları düzelt, temel kenar durumlarını işle
• Revise: çalıştığını gördükten sonra ikinci geçiş (metin düzenlemeleri, doğrulama, küçük UX düzeltmeleri)

Çoğu aşım testte ve revizyonda olur, ilk taslakta değil.

Her parça için bir aralık kullanın: düşük (basit), tipik (biraz gidip gelme), yüksek (sürprizler). Platformunuz kredi tabanlıysa kredilerle takip edin. Tokenları doğrudan takip ediyorsanız tokenlarla takip edin. Amaç aynı: gerçeklik değiştiğinde dürüst kalan bir tahmin.

İki satır kendi kendine verilen aşırı harcamaları önlemeye yardımcı olur:

1. Bilinmeyenler tamponu (%10–20) ayrı bir satır olarak. Bunu özelliklerin içine gizlemeyin.

2. Daha sonra istenen değişiklikler kabul edildikten sonra gelen yeni fikirler için ayrı bir kova ("aynı zamanda ekipleri ekle", "gösterge panelini X gibi yap"). Eğer bunu ayırmazsanız, normal değişiklikleri orijinal tahmine yansıtmak zorunda kalırsınız.

İşte kopyalayabileceğiniz hafif bir şablon:

Feature: Password login
- Build:    low 30 | typical 60 | high 120
- Test:     low 15 | typical 30 | high 60
- Revise:   low 10 | typical 20 | high 40
Subtotal (typical): 110

Buffer (15%): 17
Later changes (held): 50

Bunu her özellik (auth, CRUD, bir entegrasyon, UI yenilemesi) için tekrarlayın. Planınız için "typical" kullanın ve en kötü senaryo kontrolü için "high" kullanın.

Yaygın özellikleri tahmin etmek: auth ve CRUD

Auth ve CRUD basit görünüyor ama kapsam bulanıksa pahalılaşırlar. Bunları bir menü gibi değerlendirin: her seçenek maliyeti artırır.

Auth: sadece "giriş" demeyin, tam şekli tanımlayın

Erişim kontrolü için "bitti"nin ne olduğunu yazın. En büyük sürücüler giriş yöntemleri ve izin yollarının sayısıdır.

Açık olun:

• Giriş yöntemleri (e-posta/parola, magic link, Google, Apple, SSO)
• Roller ve izinler (admin/editor/viewer ve her rolün yapabildikleri)
• Parola kuralları (uzunluk, karmaşıklık, kilitlemeler, sıfırlama akışı)
• Oturum kuralları (süresi, çıkış, beni hatırla davranışı)
• Hesap yaşam döngüsü (davetler, devre dışı bırakma/silme, e-posta doğrulama)

Sadece "auth ekle" derseniz, sıradan bir çözüm elde edersiniz ve kenar durumları sonradan yamamak için ödeme yaparsınız. Şekli baştan kararlaştırmak daha ucuzdur.

CRUD: sadece tablolar değil, ekranlar ve kuralları sayın

CRUD maliyeti, sahip olduğunuz varlık sayısı ve her birinin ne kadar davranış gerektirdiği tarafından belirlenir. Pratik bir model: her varlık genellikle 3–6 ekran anlamına gelir (liste, detay, oluştur, düzenle, bazen admin veya denetim görünümleri), artı API çalışmaları ve doğrulama.

CRUD kapsamını belirlerken varlıkları adlandırın ve alanları, tipleri ve doğrulama kurallarını (zorunlu, benzersiz, aralıklar) dahil edin. Ardından liste davranışını tanımlayın: filtreler, sıralama, sayfalandırma ve arama. "Arama" basit bir contains filtresi olabileceği gibi çok daha ağır bir şey de olabilir.

Ayrıca admin ekranlarının kullanıcı ekranlarından farklı olup olmadığını kararlaştırın. Ayrı düzenler, ekstra alanlar ve toplu işlemler işi iki katına çıkarabilir.

Hızla maliyeti artıran kenar durumları: satır düzeyinde izinler, denetim logları, CSV içe/dışa aktarma, soft delete ve onay iş akışları. Bunların hepsi yapılabilir, ancak ne istediğinizi açıkça seçtiğinizde bütçe öngörülebilir kalır.

Tahminleri tahmine dayalı olmadan entegrasyonlar

Entegrasyonlar maliyetli hissedilir çünkü iş gizlenmiştir. Çözüm: "X'e bağlan" yerine küçük, test edilebilir parçalara ayırın. Bu tahmini daha öngörülebilir kılar ve daha temiz bir prompt verir.

İyi bir entegrasyon kapsamı genelde şunları içerir:

• Bağlanma ve kimlik doğrulama (API anahtarları veya OAuth, token yenileme)
• Bir nesne uçtan uca (mutlu yol)
• Senkron davranışı (webhooklar veya zamanlama, sayfalandırma, hız limitleri)
• Hata yönetimi (yeniden deneme, idempotentlik, yeniden çalıştırma yolu)
• Test ve kenar durumları (bozuk veri, eksik izinler, zaman aşımı)

Prompt atmadan önce veri sözleşmesini kilitleyin. Hangi nesneleri ve tam alanları gerektiğini listeleyin. "Müşterileri senkronize et" muğlakken, "Customer{id, email, status} ve Order{id, total, updated_at} senkronize et" modelin ekstra tablolar, ekranlar ve endpointler icat etmesini engeller.

Sonra yön ve sıklığı kararlaştırın. Tek yönlü senkron (yalnızca içe aktarım) iki yönlü senkrondan çok daha ucuzdur çünkü iki yön conflict kuralları ve daha fazla test gerektirir. Eğer iki yönlü yapmak zorundaysanız, önceden hangi verinin galip geleceğini seçin (kaynak tek doğru, son yazma kazanır veya manuel inceleme).

Arızalar için plan yapın; sanki kesinlikle olacakmış gibi davranın. API kapandığında ne olacağını belirleyin. Bir log girdisi + uyarı ve manuel "yeniden çalıştır" butonu genellikle yeterlidir. Minimal tutmak, istemediğiniz bir tam operasyon sistemi için ödeme yapmanızı önler.

Son olarak üçüncü taraf tuhaflıkları ve testler için bir tampon ekleyin. Basit API'ler bile sayfalandırma, garip enumlar, tutarsız dokümantasyon ve hız limitleri getirir. Entegrasyon testi ve düzeltmeleri için %20–40 eklemek gerçekçidir.

Yeniden tasarım ve UI değişikliklerini tahmin etmek

UI işleri bütçelerin sessizce sızdığı yerdir. "Yeniden tasarım" renkleri değiştirmekten tüm akışı yeniden inşa etmeye kadar değişebilir; bu yüzden neyin değiştiğini adlandırın: düzen, bileşenler, metin veya kullanıcı adımları.

Davranışı etkileyen değişiklikleri görsel-only değişikliklerden ayırın. Görsel-only sadece stilleri, boşluğu ve bileşen yapısını etkiler. Bir butonun ne yaptığına, doğrulamanın nasıl çalıştığına veya verinin nasıl yüklendiğine müdahale ediyorsanız bu artık özellik işidir.

Sayfa listesi gibi kapsamlandırın

"Tüm uygulamayı yeniden tasarla" demekten kaçının. Tam olarak hangi ekranların dahil olduğunu listeleyin. Ekranları listeleyemiyorsanız, tahmin yapamazsınız.

Kapsamı kısa ve somut tutun:

• Dahil sayfalar (örneğin: Giriş, Kontrol Paneli, Ayarlar)
• Dahil durumlar (boş, yükleniyor, hata, başarılı)
• Ne değişiyor (düzen, bileşenler, içerik, akış)
• Referans stil (kısa notlar: renkler, tipografi, boşluk)
• İzin verilen geçiş sayısı (örneğin: 1 build geçişi + 1 cilalama geçişi)

Bu tip bir prompt modeli, modelin tüm kod tabanında tasarım tahminleri yapmasını engeller; tahminleri uzun söyleşilere sürükleyen asıl sebep budur.

QA geçişlerini atlamayın

UI değişiklikleri genelde en az iki kontrol ister: masaüstü ve mobil. Küçük bir erişilebilirlik temel kontrolü ekleyin (kontrast, odak durumları, klavye navigasyonu), tam bir denetim yapmasanız bile.

Pratik bir tahmin metodu:

(sayfa sayısı) x (değişim derinliği) x (geçiş sayısı)

Örnek: 3 sayfa x orta derinlik (yeni düzen + bileşen düzeltmeleri) x 2 geçiş (build + cilalama) öngörülebilir bir kredi dilimidir. Ayrıca onboarding akışını değiştiriyorsanız, onu ayrı bir satır olarak ele alın.

Adım adım: promptlarda bütçelenmiş kapsam oluşturma

Kredileri kontrol etmenin en ucuz yolu, modelden yapmasını istemeden önce ne istediğinize karar vermektir. Yeniden çalışma maliyetlerin yükselttiği yerdir.

Bir paragrafla kullanıcıyı ve hedefi belirtin. Örneğin: "Küçük bir klinik resepsiyonisti giriş yapar, hastaları ekler, randevuları planlar ve bugünün listesini görür." Bu sınırları koyar ve modelin ekstra roller, ekranlar veya akışlar icat etmesini caydırır.

Sonra ürünü modüller değil, ekranlar ve eylemler olarak tanımlayın. "Randevular modülü" demek yerine "Takvim ekranı: oluştur, yeniden planla, iptal et, ara" yazın. Bu işi sayılabilir hale getirir.

Sadece veri için gerekli olanları dahil edin. Henüz her alanı belirtmeniz gerekmez, sadece özelliği gerçek yapanlar. Güçlü bir prompt genelde şunları içerir:

• Kullanıcılar ve roller (kim ne yapabilir)
• Eylemlerle birlikte ekranlar (kullanıcının tıkladığı şeyler)
• Temel tablolar ve ana alanlar (ne saklanmalı)
• Kabul kontrolleri (nasıl çalıştığını anlarsınız)
• Kapsam dışı (ne yapılmayacak)

Kabul kontrolleri, iki kez ödeme yapmanızı önler. Her özellik için 2–4 kontrol yazın: "Kullanıcı e-posta yoluyla parola sıfırlayabilir" veya "Randevu oluşturma çakışmayı engeller" gibi. Koder.ai kullanıyorsanız, bu kontroller Planlama Modu'na doğal olarak uyar.

Kapsam dışı maddeleri açıkça belirtin: "admin panel yok", "ödeme yok", "çoklu dil yok", "dış takvim senkronizasyonu yok." Bu, sürpriz "iyi olurdu" işlerini önler.

Küçük parçalarda oluşturun ve her parçadan sonra yeniden tahmin yapın. Basit bir ritim: bir ekran veya endpoint üret, çalıştır, sorunları düzelt, sonra devam et. Bir parça beklenenden pahalıysa, sonraki parçanın kapsamını kesin veya azaltın.

Kaliteden ödün vermeden prompt maliyetlerini düşük tutma

Çoğu maliyet sıçraması, bir mesajda çok fazla iş yapmaktan gelir. Modeli bir ekip arkadaşı gibi ele alın: küçük, net adımlarla bilgilendirin.

Planla başlayın, kodla başlamayın. Kısa bir plan isteyin, varsayımları ve açık soruları onaylayın, sonra ilk küçük uygulama adımını isteyin. Planlama, yapım, test, metin yazımı ve stilleme hepsini tek promptta istediğinizde uzun çıktılar ve daha fazla hata davet edersiniz.

Bağlamı sıkı tutun. Sadece değişiklik için gerekli ekranları, bileşenleri veya API notlarını dahil edin. Koder.ai kullanıyorsanız, ilgili dosyaları seçin ve adlarıyla referans verin. Ekstra dosyalar tokenları artırır ve ilgisiz alanlarda düzenlemelere yol açar.

Küçük diffler isteyin. Mümkün olduğunda bir prompt bir şeyi değiştirsin: tek bir endpoint, bir form, bir hata durumu, tek bir ekran. Küçük değişiklikler incelemesi daha kolaydır ve bir şey ters giderse ilgisiz işleri yeniden yapmak zorunda kalmazsınız.

Çalışma kuralları:

• İsteyin: önce plan, sonra bir uygulama adımı, sonra kısa bir gözden geçirme kontrol listesi
• Sağlayın: minimum bağlam (mevcut davranış, istenen davranış, kısıtlar)
• Sınırlandırın: sabit sayıda revizyon turu (ör. iki)
• Talep edin: neyin değiştiğine dair kısa özet
• Kaydedin: yeniden çalışmaya neden olanları ve prompt şablonunuzu güncelleyin

Döngüleri erken durdurun. İkinci deneme hala yanlışsa, girdiyi değiştirin, sadece kelimeleri değil. Eksik detayı ekleyin, çelişen gereksinimleri çıkarın veya başarısız örneği gösterin. "Tekrar dene" demek token yakıp ilerleme sağlamayabilir.

Örnek: "giriş + unutulan parola" ve daha iyi bir düzen istiyorsunuz. Bunu üç promptta yapın: (1) akışları ve gereken ekranları özetle, (2) sadece auth akışını uygula, (3) UI boşluklarını ve renkleri düzelt. Her adım gözden geçirilebilir ve ucuz kalır.

Bütçeyi patlatan yaygın hatalar

Çoğu aşım büyük özelliklerden değil, küçük kapsam boşluklarından kaynaklanır; bunlar tekrar turlarını, daha fazla üretilen kodu ve daha fazla düzeltmeyi çoğaltır.

Beş bütçe-katili (ve yerine ne yapmalı)

"Bitti" üzerinde anlaşmadan inşa etmek

Kod üretirseniz ve kabul kriterleri yazmadıysanız, yeniden yazımlar için ödeme yaparsınız. Önce 3–5 kabul kontrolü yazın: kullanıcı ne yapmalı, hangi hatalar gösterilmeli, hangi veriler saklanmalı.

Muğlak kelimeler kullanmak

"Modern", "güzel" ve "daha iyi yap" gibi ifadeler uzun gidip gelmelere davetiye çıkarır. Bunları "masaüstünde iki sütun düzeni, mobilde tek sütun" veya "birincil buton rengi #1F6FEB" gibi spesifiklerle değiştirin.

Bir prompta birden fazla özellik sıkıştırmak

"Auth ekle, faturalandırma ekle, admin panel ekle" takip ve yeniden tahmin etmeyi zorlaştırır. Her seferinde bir özellik yapın ve dokunulan dosyaların kısa bir özetini isteyin.

Veri modelini geç değiştirmek

Tabloları yeniden adlandırmak, ilişkileri değiştirmek veya ID tiplerini ortada değiştirmek UI, API ve migration'larda düzenlemeler gerektirir. Temel varlıkları erken kilitleyin, bazı alanları "gelecek" olarak bırakabilirsiniz.

Testleri sona bırakmak

Hatalar regenerate-fix-regenerate döngülerine dönüşür. Her özellik için küçük bir test seti isteyin, tek büyük test turu yapmayın.

Somut örnek: Koder.ai'ye "CRM'i geliştir" derseniz, düzenleri değiştirir, alanları yeniden adlandırır ve endpointleri tek seferde ayarlayabilir. Ardından entegrasyonunuz bozulur ve neyin taşındığını bulmak için kredi harcarsınız. Bunun yerine "veri modelini değiştirme, sadece liste sayfasını güncelle, API rotalarına dokunma ve şu 4 kontrolü geç" derseniz sürtüşmeyi sınırlayıp maliyetleri sabit tutarsınız.

Başlamadan önce hızlı maliyet kontrol listesi

Bütçeleme, tek bir sihirli prompt değil küçük bir proje planlamak gibidir. 2 dakikalık bir kontrol çoğu aşım sorununu başta yakalar.

Aşağıdakileri gözden geçirin ve herhangi bir "hayır"ı oluşturmadan önce düzeltin:

• Kenarları sert bir özellik listesine sahipsiniz: ne yapıyor, ne yapmıyor, nerede başlıyor/bitiyor.
• Her özellik için (düşük, tipik, yüksek) bir aralık var ve ilk yapım için bir sayıya bağlı kalıyorsunuz.
• Promptunuz kabul kriterleri ve açık kapsam dışı satırları içeriyor.
• Küçük parçalarda oluşturup her parçadan sonra gözden geçiriyorsunuz: davranışı doğrulayın, değişiklikleri okuyun, sonra devam etmeye karar verin.
• En sık genişleyen bölümler için bütçe ayırdınız: entegrasyonlar ve UI revizyonları.

Koder.ai kullanıyorsanız, her parçayı bir snapshot noktası gibi düşünün: bir parça üretin, test edin, sonra devam edin. Veri modeli düzenlemeleri, geniş UI refactor'ları veya entegrasyon yeniden yazımları gibi riskli değişikliklerden önce snapshot ve rollback en değerli olanlardır.

Basit bir örnek: "Kullanıcı yönetimini oluştur" demek yerine "sadece e-posta girişi, parola sıfırlama dahil, sosyal giriş yok, admin kullanıcıları devre dışı bırakabilmeli, giriş ve sıfırlama için testler olsun" demek daha nettir. Kabul kontrolleri tekrarları azaltır; tekrarlar token ve kredi bütçelerini tüketir.

Örnek: özellik listesiyle küçük bir uygulama tahmini

Burada kopyalayabileceğiniz küçük, gerçekçi bir örnek var. Uygulama bir ekip için dahili bir araç: giriş, iki basit modül ve bir entegrasyon.

Bir "build döngüsü" kısa plan, kod üretme/güncelleme, hızlı inceleme ve düzeltme olarak varsayılır. Kredileriniz çoğunlukla kaç döngü çalıştırdığınız ve her döngünün ne kadar büyük olduğuyla izlenir.

İç araç için özellik listesi:

Checkpoint'leri sıkı tutacak bir prompt sıralaması:

1. Planlama: her özellik için alanları, ekranları, kuralları ve kapsam dışını onaylayın.
2. Sadece modül 1'i oluşturun: Employees uçtan uca oluşturun, sonra durun.
3. İnceleme: akışı test edin, hataları düzeltin ve alanları kilitleyin.
4. Modül 2 için tekrarlayın.
5. Entegrasyonu en sona ekleyin, çekirdek akışlar stabil olduğunda.

Maliyetler kod vardıktan sonra kararları değiştirdiğinizde artar. Yaygın tetikleyiciler: rol değişiklikleri, geç eklenen alanlar (özellikle birden çok modülü ve entegrasyonu etkileyenler), entegrasyon hataları (kimlik doğrulama hatası, payload uyuşmazlığı), ve formlar oluşturulduktan sonra yapılan UI yeniden tasarımları.

Sonraki adımlar: özellik-özellik planlayın, döngüler halinde oluşturun ve her döngüden sonra kredileri tekrar kontrol edin. Riskli değişikliklerden önce snapshot alın ki hızlıca geri dönebilin ve projeyi tipik aralığınız içinde tutun.