Prompt is Not Runtime: Why I Rejected LLM State-Machines for Deterministic FinTech

Prompts are Heuristics, Not Code

There is an excellent article trending on Hacker News right now titled "Prompt Is Not Runtime." It targets a major architectural delusion of the current AI-hype cycle: the idea that we can use natural language prompts as a reliable execution runtime for business logic.

When you are building software that handles user data, a "probabilistic" output is annoying. But when you are building a financial engine designed to model the Snowball Effect of life savings, a probabilistic output is an absolute liability.

When I built DividendFlow—a tax-aware dividend growth and DRIP engine for 38,000+ US tickers—I had to reject the "prompt-as-a-runtime" trend entirely.

Here is why your domain logic must remain strictly deterministic, and how Next.js 15 Server Components allow us to run complex tax math at the Edge in under 150ms.

1. The High Cost of Probabilistic Math

In dividend growth investing, the calculation of future income is recursive. You take a starting principal, calculate the dividend payout, subtract the localized tax drag (Qualified vs. Ordinary rates), purchase fractional shares, and feed the new share count back into the loop for the next month.

If your "runtime" is an LLM agent or a prompt-based state machine, you are dealing with a standard deviation of accuracy.

• An LLM might apply a flat 15% federal tax rate to a REIT ($O) or a BDC ($MAIN) because it "knows" they pay dividends.
• But REITs and BDCs pay ordinary income distributions, which are taxed at standard income brackets (up to 37%).
• A 0.1% error in Year 1 compounds over 20 years into a $50,000 shortfall in the user's projected nest egg.

A financial engine cannot operate on "vibes." You cannot wrap a probabilistic model in enough "guardrails" to make it mathematically safe.

2. Our Architecture: Zero-Dependency TypeScript

Instead of outsourcing our logic to an API call that bills us per token and occasionally hallucinates, we built the compounding engine in 100% deterministic TypeScript.

// Deterministic state-management for compounding math
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);
}

By keeping the core math in vanilla TypeScript, we achieved 100% predictability. Every single run with the same inputs yields the exact same outputs. No temperature settings, no seed parameters, no API overages.

3. Shipping Math, Not JavaScript, via Next.js 15

Running 30 years of monthly recursive compounding loops (360 iterations) for 38,000+ tickers is computationally heavy for client-side JavaScript, especially on mobile devices over slow connections.

We offloaded the calculation engine entirely to Next.js 15 Server Components (RSC).

• The Request Flow: The user toggles a tax setting (US, UK ISA, or Canadian TFSA) -> The page state updates via URL parameters -> Next.js executes the math on the server -> The browser receives only the coordinates for the graph.
• The Performance: Zero heavy math happens on the client. The initial bundle size stays minimal, and projections render in under 150ms.

4. Why We Don't Collect Your Data

The developer ecosystem has been rocked by cloud platform suspensions (like GCP blocking Railway) and telemetry scandals.

At DividendFlow, we built our technical moat by deciding not to collect user data at all.

• No Database: All portfolio portfolios and scenarios are stored in your browser's LocalStorage or encoded directly in the URL address bar.
• No Auth Wall: You don't need a login, you don't need to link your bank account, and we don't harvest your email.

If our host bans us tomorrow, we can copy our static bundle and deploy it to a bare-metal VPS in 5 minutes. The logic is stateless, host-agnostic, and entirely owned by the user.

Conclusion

We have over-engineered the modern web to the point where simple utility apps require a PostgreSQL DB, an Auth provider, an LLM agent, and a SOC2 compliance audit.

Sometimes, the most "senior" move you can make as an engineer is to say no to the hype, write deterministic code, and let the server do the math.

Check out the deterministic speed:

👉 DividendFlow.org

Are we treating prompts as runtimes because we've forgotten how to write robust state-machines? Let’s fight it out in the comments.