Yapay zekâ yapım maliyeti tahmini basitleştirildi: her özellik için kredi ve token tahmini yapın, prompt kapsamını kesinleştirin ve yeniden çalışmayı önleyerek uygulamanızı bütçe içinde tutun.
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:
Tahmin yaparken, aslında nelere bütçe ayırdığınızı netleştirin:
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.
İ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.
"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:
Ç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:
Bilinmeyenler tamponu (%10–20) ayrı bir satır olarak. Bunu özelliklerin içine gizlemeyin.
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.
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.
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:
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 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.
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:
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.
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.
"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:
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.
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.
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:
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.
Ç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ı:
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.
Ç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.
"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.
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:
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.
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:
| Feature | What's included | Low | Typical | High |
|---|---|---|---|---|
| Login + roles | Sign in, sign out, two roles (Admin, User), protected pages | 1 cycle | 2 cycles | 4 cycles |
| CRUD module 1 | "Employees" list, create/edit, basic validation, search | 2 cycles | 3 cycles | 6 cycles |
| CRUD module 2 | "Assets" list, create/edit, assign to employee, audit fields | 2 cycles | 4 cycles | 7 cycles |
| One integration | Send an event to an external service when an asset is assigned | 1 cycle | 2 cycles | 5 cycles |
Checkpoint'leri sıkı tutacak bir prompt sıralaması:
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.
Bütçeyi bir aralık olarak ayırın çünkü ödediğiniz sabit bir özellik fiyatı değil, denemeler (mesajlar, üretilen kod, revizyonlar, testler ve yeniden çalışma) için ödeme yapıyorsunuz. Maliyetler şunlarla artar:
Küçük bir UI değişikliği bile mantık, veri veya akışları etkiliyorsa pahalı olabilir.
Tokenler, modelin okuduğu/yazdığı metin parçalarıdır (sizin promptunuz, modelin çıktısı ve modelin tekrar okuması gereken sohbet geçmişi).
Krediler, platformunuzun faturalama birimidir (genellikle model kullanımı artı sohbetin arkasındaki ajan işleri, dosya oluşturma ve sonuç kontrolü gibi platform işleri için).
Yapım adımları, projede yapılan anlamlı değişikliklerdir (örneğin bir tablo eklemek, bir ekranı bağlamak, bir endpoint eklemek). Bir özellik genellikle birçok adıma ihtiyaç duyar ve her adım birden çok model çağrısı tetikleyebilir.
Kullanıcıların yüksek sesle adlandıracağı özelliklerde tahmin yapın ("parola girişi", "çalışan listesi", "varlık atama") — "ekranlar" veya "mesajlar" yerine. Her özellik için üç kısmı bütçeleyin:
Her parça için düşük/typical/yüksek aralıkları atayın ve bunları toplayın.
İki ayrı satır ekleyin:
"Sonrasında değişiklikler"i ayrı tutmak, orijinal tahmini normal kapsam büyümesi için suçlamanızı engeller.
Auth için "bitti"nin ne anlama geldiğini yazın. En büyük maliyet sürücüleri:
Öngörülebilir maliyet istiyorsanız tek bir yöntem (e-posta/parola) ve 1–2 rol ile başlamak mantıklıdır.
CRUD maliyeti davranışa bağlıdır, sadece tablolara değil. Her varlık için şunları tanımlayın:
CSV içe/dışa aktarma, audit loglar, onay iş akışları veya satır bazlı izinler eklerseniz bunları ayrı özellik satırları olarak bütçeleyin.
“X’e bağlan”ı, test edilebilir küçük parçalara ayırın:
Ayrıca veri sözleşmesini kilitleyin (tam alanlar) ki model ekstra tablolar veya ekranlar icat etmesin. Entegre üçüncü tarafların tuhaflıklarına ve testlere %20–40 eklemek gerçekçidir.
Sayfanın ne değişeceğini açıkça yazın: düzen, bileşenler, içerik veya kullanıcı adımları.
Görsel değişiklikleri davranış değişikliklerinden ayırın. Görsel değişiklikler yalnızca stilleri ve bileşen yapısını etkiler. Bir butonun işlevini, doğrulamayı veya veri yüklemesini değiştirirseniz bu bir özellik işi olur.
Tahmin için kapsamı şu gibi listeleyin:
Kısa bir kontrol listesi kullanın:
Küçük parçalar halinde oluşturun: bir ekran veya endpoint üretin, çalıştırın, düzeltin, sonra devam edin. Her parça için kabul testleri yazmak, aynı işi iki kez ödemenizi önler.
İki başarısız tekrar sonrası girişinizi değiştirin; sadece "tekrar deneyin" demek token yakar ama sonuca yaklaştırmayabilir. Yapılacaklar:
Her adımın sonunda değişen dosyaların kısa bir özetini isteyin ki istenmeyen değişiklikleri hızlıca fark edin.
UI değişiklikleri genellikle en az iki kontrol ister: masaüstü ve mobil. Hızlı bir erişilebilirlik temel kontrolü ekleyin (kontrast, odak durumları, klavye navigasyonu).