Finansal bir motorda olasılıksal çıktı basit bir hata olmaktan çıkıyor. Kullanıcı verilerini işleyen bir uygulama için tahminli sonuçlar sinir bozucu olabilir; ancak hayat boyu tasarrufların kar topu etkisini modelleyen bir finansal motor içinse mutlak bir sorumluluktur. DividendFlow adlı projemizde — ABD’nin 38 binden fazla hisse senedi için vergi farkındalıklı temettü büyüme ve DRIP (Dividend Reinvestment Plan) motoru geliştirirken, LLM’leri çalışma zamanı olarak kullanma eğiliminin tamamen dışında kaldık. İşte nedeni ve nasıl bir çözüm ürettiğimiz.
Doğal Dil Komutları Neden Güvenilir Bir Çalışma Zamanı Değil?
LLM’lerle yapılan işlemlerdeki en temel varsayım, doğal dil komutlarının güvenilir bir şekilde kod yerine çalıştırılabileceğidir. Oysa ki "Prompt Is Not Runtime" başlıklı ve Hacker News’ta büyük ilgi gören makale de vurguladığı gibi, bu yaklaşım Finans Teknolojileri (FinTech) gibi hassasiyet gerektiren alanlarda ciddi riskler barındırıyor.
Temettü büyüme hesaplamaları, geri beslemeli (recursive) bir yapıya sahiptir. Başlangıç sermayesi alınır, temettü ödemesi hesaplanır, yerel vergi oranları (Nitelikli Temettü ile Normal Gelir vergisi arasındaki fark gibi) çıkarılır, ardından hisse senetleri kısmi olarak alınarak yeni hisse sayısı bir sonraki ay için yeniden hesaba katılır. Bu döngü, onlarca yıl boyunca tekrarlanır.
LLM tabanlı bir motorun hata payı, basitçe %0.1 gibi görünse de yıllar içinde katlanarak büyür:
- Bir LLM, REIT’ler (Örneğin $O) veya BDC’ler (Örneğin $MAIN) için %15’lik sabit bir federal vergi oranı uygulayabilir — çünkü "bildiği" kadarıyla bu şirketler temettü öder.
- Oysa REIT’ler ve BDC’ler normal gelir dağılımı yapar ve bu dağılımlar, standart gelir dilimlerine göre (en fazla %37) vergilendirilir.
- Yalnızca birinci yıldaki %0.1’lik bir hata, 20 yıl sonunda kullanıcının 50.000 dolar eksik birikime yol açabilir.
Finansal bir motor, "vibes" üzerine kurulamaz. Olasılıksal bir modele ne kadar "koruma" eklerseniz ekleyin, matematiksel olarak güvenli hale getiremezsiniz.
Sıfır Bağımlılıkla, Tamamen Belirleyici TipScript
LLM API’larına token başına ödeme yapmak ve zaman zaman ortaya çıkan hayal ürünü çıktılarla uğraşmak yerine, tüm hesaplama motorunu %100 belirleyici TipScript ile yazdık. Bu yaklaşım, hem maliyetleri düşürdü hem de çıktının her koşulda aynı kalmasını sağladı.
Aşağıdaki kod parçası, temettü birikim (DRIP) hesaplamasının nasıl çalıştığını gösteriyor:
export async function calculateDRIP(ticker: string, config: TaxConfig) {
const payoutHistory = await fetchEdgeCachedDividends(ticker);
return payoutHistory.reduce((accumulator, payment) => {
const netPayout = applyJurisdictionTax(payment.amount, config);
const sharesAcquired = netPayout / payment.sharePrice;
return accumulator + sharesAcquired;
}, initialShares);
}Bu fonksiyonun en önemli özelliği, aynı girdilerle her çalıştırıldığında tamamen aynı çıktıları üretmesidir. Hiçbir sıcaklık ayarı, tohum parametresi veya API maliyetinden endişe etmek gerekmiyor.
Next.js 15 Server Components ile Matematiği Taşımak
38 binden fazla hisse senedi için 30 yıl boyunca aylık olarak yapılan karmaşık bileşik hesaplamalar, müşteri tarafı JavaScript’i için oldukça ağır bir yük oluşturabilir — özellikle yavaş bağlantılar üzerinden mobil cihazlarda.
Bu nedenle, hesaplama motorunu tamamen Next.js 15 Server Components (RSC) üzerine taşıdık. Bu mimari sayesinde:
- İstek Akışı: Kullanıcı vergi ayarını değiştirdiğinde (ABD, İngiltere ISA’sı veya Kanada TFSA’sı), sayfa durumu URL parametreleriyle güncellenir. Next.js, hesaplamayı doğrudan sunucuda çalıştırır ve tarayıcıya yalnızca grafik için gerekli koordinatlar gönderilir.
- Performans: İstemci tarafında hiçbir ağır matematik işlemi yapılmaz. Başlangıç paket boyutu minimal kalır ve projeksiyonlar 150 milisaniyenin altında render edilir.
Bu yaklaşım, hem performansı optimize eder hem de hesaplama yükünü kullanıcının cihazından uzaklaştırarak daha erişilebilir bir deneyim sunar.
Kullanıcı Verilerini Toplamamak: Teknik Moat’ın Temeli
Günümüzde geliştirici ekosistemi, bulut platformlarının aniden uygulama barındırmayı durdurması (örneğin GCP’nin Railway’yi engellemesi) veya telemetri skandallarıyla sarsılıyor. DividendFlow olarak biz de teknik avantajımızı hiçbir kullanıcı verisini toplamamak üzerine kurduk.
- Veritabanı Yok: Tüm portföyler ve senaryolar doğrudan tarayıcının LocalStorage’unda saklanır veya URL adres çubuğuna kodlanarak aktarılır.
- Kimlik Doğrulama Duvarı Yok: Kullanıcıların giriş yapmasına, banka hesaplarını bağlamasına veya e-posta adreslerini paylaşmasına gerek yok.
Eğer barındırma sağlayıcımız yarın bizi engellese, statik paketimizi kopyalayıp beş dakika içinde bare-metal bir VPS’e dağıtabiliriz. Mantık tamamen devletsiz (stateless), barındırıcıdan bağımsız ve kullanıcıya ait olarak kalır.
Sonuç: Basitliği Seçmek, Hype’a Hayır Demek
Modern web, basit bir fayda uygulaması için bile PostgreSQL, kimlik doğrulama sağlayıcıları, LLM ajanları ve SOC2 uyumluluk denetimleri gerektirecek kadar karmaşık hale geldi. Bazen, bir mühendis olarak en "senior" hareket, hype’a karşı durmak, belirleyici kodu yazmak ve matematiği sunucuya yaptırmaktır.
Günümüzde birçok proje, "komutları çalışma zamanı gibi kullanmak" eğiliminin cazibesine kapılsa da, FinTech gibi alanlarda bu yaklaşımın riskleri açıkça görülüyor. DividendFlow, LLM’lerin sunduğu kolaylığın yerine, matematiksel doğruluğu ve kullanıcı gizliliğini ön plana çıkararak yepyeni bir standart oluşturuyor. Belki de asıl soru şu: Komutları çalışma zamanı gibi görmek, sağlam durum makineleri yazmayı unuttuğumuz için mi bu kadar cazip geliyor? Deneyimlerinizi yorumlarda paylaşın — tartışalım.
Yapay zeka özeti
FinTech’te LLM’leri çalışma zamanı gibi kullanmak neden tehlikeli? Belirleyici TipScript ve Next.js 15 Server Components ile vergi hesaplamalarında %100 doğruluk ve 150ms performans nasıl sağlandı.
