DEV Community: Naveen Vandanapu

Rethinking Expense Splitting: A Graph-Based Approach with LLM Integration

Naveen Vandanapu — Fri, 26 Dec 2025 06:28:39 +0000

The Problem with Traditional Expense Splitters

If you've ever used group expense splitting tools, you know the drill: great concept, but many implementations leave something to be desired. A common pain point is when timelines mix expenses from different groups, making it difficult to focus on a specific trip or event. Want to quickly review just your weekend getaway expenses? You might find yourself scrolling through unrelated bills and dinner splits from other groups.

This counter-intuitive design pattern got me thinking: there has to be a better way.

A Graph-Based Mental Model

The breakthrough came when I realized expense splitting is fundamentally a graph problem. Here's the elegant simplicity:

Nodes represent people in your group
Directed edges represent money owed (A → B means A owes B)
Edge weights are the amounts

When you add an expense, you're essentially creating edges in this graph. If Alice pays $120 for lunch shared equally among three people, she's owed $40 by Bob and $40 by Charlie. That's two edges: Bob → Alice ($40) and Charlie → Alice ($40).
This mental model is intuitive because it mirrors how we naturally think about debts: "I owe Alice $40" is a directed relationship with a value attached.

Building expense-splitter

Armed with this insight, I built expense-splitter as a graph-based tool. Key design decisions:

Group isolation: Each group is its own separate graph. Your Napa trip expenses never mix with your apartment utilities.
Flexible splitting: Support for equal splits, weighted splits, and percentage-based splits—all translating cleanly to edge calculations.
Clean settlements: The graph makes it trivial to calculate who owes whom. No more confusing chains of "Alice pays Bob who pays Charlie"—just direct settlements.

The MCP Integration: Where It Gets Interesting

Here's where modern AI tooling transforms the experience. I packaged expense-splitter as an MCP (Model Context Protocol) tool and built an agent using Google's Agent Development Kit (ADK) in Go.
The result? A conversational interface that's actually intuitive:

User: let's do expense splitting

Agent: I can help with that! First, let's create a group.
What would you like to name it?

User: create a group called napa-trip

Agent: Great! I've created a group called 'napa-trip'.
Now, who are the members of this group?

User: add alice, bob, charlie to the group

Agent: I've added Alice, Bob, and Charlie to the napa-trip group.
Now, let's add some expenses...

No clicking through forms. No dropdown menus. Just natural conversation.

Adding Expenses Naturally

The real magic shows when adding expenses:

User: add an expense by alice for lunch. 120$

Agent: I've added a $120 expense for lunch, paid by Alice.
What's the next expense?

User: it's for snacks and drinks by charlie. 60$

Agent: Got it. $60 for snacks and drinks, paid by Charlie, has been added.

Even complex splits feel natural:

User: add an expense by bob for show tickets with unequal weights

Agent: Okay, Bob paid for show tickets with unequal weights.
What was the total amount? And how would you like to split
the weights among Alice, Bob, and Charlie?

User: 100

Agent: And what are the unequal weights for Alice, Bob, and Charlie?

User: alice: 1, bob:2, charlie:1

Agent: I've added the $100 expense for show tickets, paid by Bob,
with the following weights: Alice 1, Bob 2, Charlie 1.

Bob paid $100 but his share (weight 2 out of 4 total) was $50, so he's actually only owed $50.

The Payoff: Clear Settlements

When you're ready to settle up:

User: get group details now

Agent: Here are the details for the 'napa-trip' group:

**Members:** Alice, Bob, Charlie

**Settlement Details:**

- Bob needs to pay Alice $15
- Charlie needs to pay Alice $20
- Charlie needs to pay Bob $5

Visualizing the Graph: DOT Notation

One of the advantages of modeling expenses as a graph is that you can actually see the structure. The tool exports the graph in DOT notation, which can be visualized using Graphviz:

digraph "napa-trip" {
  "alice" [label="alice"];
  "bob" [label="bob"];
  "charlie" [label="charlie"];
  "alice" -> "bob" [label="$25.00"];
  "alice" -> "charlie" [label="$20.00"];
  "bob" -> "alice" [label="$40.00"];
  "bob" -> "charlie" [label="$20.00"];
  "charlie" -> "alice" [label="$40.00"];
  "charlie" -> "bob" [label="$25.00"];
}

This represents the complete debt graph showing every individual obligation. Notice that this is the raw graph showing all pairwise debts from each expense. The settlement algorithm then simplifies this:

Alice owes Bob $25 but Bob owes Alice $40 → Net: Bob owes Alice $15
Charlie owes Alice $40 but Alice owes Charlie $20 → Net: Charlie owes Alice $20
Charlie owes Bob $25 but Bob owes Charlie $20 → Net: Charlie owes Bob $5

The beauty of the graph representation is its transparency. You can:

Visualize it: Paste into any Graphviz tool to see the network of obligations
Debug it: See exactly how each expense contributed to the final settlements
Audit it: Verify the math by tracing through the edges
Understand it: The visual representation makes the settlement logic obvious

This level of transparency is rare in expense splitting tools. Most are black boxes where you input expenses and get settlements without seeing the underlying logic. By exposing the graph, users who want to understand why they owe a certain amount can trace it back through the structure. Clean, minimal, and derived directly from the graph structure. No intermediate transfers, no confusion.

Why This Matters

The combination of a sound data model (graphs) and an intuitive interface (conversational AI) creates something genuinely better than existing solutions:

Cognitive alignment: The graph model matches how we think about debts
Context preservation: Groups stay separate, making it easy to review specific events
Conversational ease: No UI to learn, just describe what you want
Extensibility: MCP tools can be integrated with various AI platforms (Claude Code, custom agents, etc.)

Technical Architecture

For those interested, the stack is:

Core logic: Graph-based settlement calculation implemented in Go
MCP layer: Exposed as Model Context Protocol tool implemented in Go
Agent: Built with Google's Agent Development Kit - ADK in Go
Interface: Natural language via LLM

The MCP abstraction means the same tool can be used from CLI tools like Claude Code, web interfaces, or custom agents—wherever you can connect an LLM.

Open Source

I’ve open-sourced the implementation at
https://github.com/vnaveen-mh/expense-splitter
If you’re experimenting with MCP, agent elicitation, or graph-based modeling, feel free to fork it and build on top of it.

Conclusion

Sometimes the best solutions come from stepping back and asking: "What's the fundamental structure of this problem?" For expense splitting, it was recognizing the graph nature of debts and obligations.
Combined with modern AI tooling, we can finally build interfaces that feel as natural as asking a friend, "Hey, what do I owe you?"
The code is a testament to how good abstractions—both in data modeling and tool interfaces—can transform user experience from frustrating to delightful.

Have you experienced similar frustrations with existing tools? I'd love to hear about problems you've solved by rethinking the fundamental data model.

LLMs + Tool Calls: Clever But Cursed

Naveen Vandanapu — Thu, 11 Dec 2025 15:51:44 +0000

A real example of how LLMs creatively use tools — and why sandbox safety matters more than most people realize.

LLMs are great for generating code, but they can also get a bit too creative sometimes.

Today I ran into one of those clever but cursed AI moments that’s too interesting not to share — especially for anyone building LLM + tool calling systems.

I added a simple LuaExecutor tool to my Genkit app. I wanted to start simple: a single Genkit Flow, a single tool (LuaExecutor) and a Lua VM to run Lua code from within a Go application such as gopher-lua - that's it.

Intended Purpose: To ask LLM something like - "generate a Lua script to do something and run it"

Then I casually asked the model:

Generate a Go program that demonstrates context cancellation — and run it.

Note that I asked to generate a Go program, not Lua code.

Simple so far. An innocent request... nothing suspicious. But, what happened next surprised me.

Instead of saying “I can’t run Go,” the model improvised:

Generated the Go code
Embedded it inside a multiline Lua string
Used os.execute("go run main.go") from generated Lua code
Captured and returned the Go program’s output as if this was totally normal 🤯

This moment hit me from three different mindsets:

🧪 As a Research Engineer

This was incredibly creative — almost agent-like reasoning across languages.

🛡️ As a Product Builder

This was a red flag.

A narrowly scoped Lua tool had quietly become a general-purpose shell executor and ended up overwriting my source code. Fortunately, I recovered it using git history.

A great reminder that:

Sandboxing is extremely critical for tool call execution
Tools must have clear boundaries
System prompt design is critical - it is your first safety layer. It should not only tell (or guide) the model what to do, but also explicitly declare what not to do.
LLMs will exploit any capability you expose (often in surprising ways)

Safety > Cleverness

🙂 As a user

I'd expect predictable behavior.

If I ask for Go, just show me Go — don’t wrap it in Lua and spawn processes behind the scenes. Users trust depends on clear, bounded behavior.

Final Thoughts

This wasn’t a bug. It was the model being too smart, and it perfectly demonstrates why building safe, resilient LLM apps/tools requires real engineering discipline.

All of this reinforces a timeless reminder:

With more power comes more responsibility

Building an AI-Powered App Entirely in Go: From Simple Prompt to Smart Pipeline

Naveen Vandanapu — Fri, 28 Nov 2025 16:49:32 +0000

The Challenge

I've shipped AI features in many stacks, but over a weekend, I wanted to answer one question: "Can I build a complete, production-quality AI app using only Go?"

Not just a proof of concept. A real application with:

Structured AI flows
Content moderation
Smart interpretation
Reactive UI
Type safety end-to-end

The result?

An AI Welcome Note Generator that evolved from a 10-line prompt to a multi-stage pipeline with safety filters and natural language understanding—all without leaving Go.

This article walks through how everything fits together — from the simplest flow to a smart, multi-stage LLM pipeline.

See It In Action

Welcome Note Generator Demo

Watch the application in action: from simple prompts to smart, moderated AI flows

The Stack

Backend:

Genkit — AI flow orchestration (the star of the show)
Gin — HTTP routing and middleware
Gemini 2.0 Flash — Fast, powerful LLM
Ollama — Local model support

Frontend (yes, in Go):

Templ — Type-safe HTML templates
Datastar — Reactive UI via Server-Sent Events (zero JavaScript!)
Tailwind CSS — Clean, responsive styling

Production:

Rate limiting (configurable, per-IP)
CSRF protection (with a clever workaround)
Docker deployment
Structured logging

Deployment:

Docker
Google Cloud Run

Architecture Overview

Before we dive into flows, here’s the full system at a glance:


          ┌──────────────────────────────┐
          │          Browser UI          │
          │  (Templ + Datastar + HTMX)   │
          └──────────────┬───────────────┘
                         │
                HTTP Form / SSE Streams
                         │
              ┌──────────▼───────────┐
              │         Gin          │
              │   (Handlers & API)   │
              └──────────┬───────────┘
                         │
                  Call Genkit Flow
                         │
            ┌────────────▼────────────┐
            │         Genkit          │
            │  Flows / Prompts / AI   │
            └────────────┬────────────┘
                         │
            ┌────────────▼─────────────┐
            │      Model Provider      │
            │   (Gemini / Ollama)      │
            └──────────────────────────┘

Everything downstream of Gin is strongly typed, observable, traceable, and testable thanks to Genkit flows.

The Journey: Five Versions, Five Lessons

Version 1: Keep It Simple

I start every AI project with the bare minimum:

a flow that takes a string
generates text
returns it directly


genkit.DefineFlow(g, "welcomeV1",
    func(ctx context.Context, occasion string) (string, error) {

        system := "You write simple, warm welcome notes."

        resp, err := genkit.Generate(
            ctx, g,
            ai.WithSystem(system),
            ai.WithPrompt(
                fmt.Sprintf(`Generate a welcome note for "%s".`, occasion),
            ),
        )
        if err != nil {
            return "", err
        }

        return resp.Text(), nil
    })

Input: "birthday party"
Output: A friendly welcome message

This version teaches the foundation:

flows are typed Go functions
prompt → model → response is explicit
Genkit generates schemas, observability, and HTTP endpoints automatically

The UI for this version is a single input box and a result area — powered purely by Templ + Datastar, no JS.

Lesson: Start with string → string. Get the basics working before adding complexity.

Version 2: Add Structure

Real apps need more than a text box. Users want control. Let's move from raw text to structured fields:

occasion or context
language of choice
length of the generated note
tone or style of the note to be generated

type WelcomeInput struct {
    Occasion string `json:"occasion"` // Occasion or Context
    Language string `json:"language"` // English, Spanish, etc.
    Length   string `json:"length"`   // Short, Medium, Long
    Tone     string `json:"tone"`     // Formal, Casual, Friendly
}

The flow signature changes to:

func(ctx context.Context, in *WelcomeInput) (string, error)

This step lets users customize the note through clean dropdowns.

Lesson: Structured input = better UX. Genkit handles validation automatically.

Version 3: Structured Output + Metadata

This is the moment Genkit's flows become truly powerful. Instead of parsing text, we tell the LLM to return typed JSON:
The model returns typed metadata, not just a string and Genkit parses it into typed data and validates it against the schema for us.

V3 Output

type WelcomeOutput struct {
    Note     string            `json:"note"`
    Occasion string            `json:"occasion"`
    Language string            `json:"language"`
    Length   string            `json:"length"`
    Tone     string            `json:"tone"`
    Metadata map[string]string `json:"metadata"`
}

Flow V3 (structured input → structured output)

resp, err := genkit.GenerateData[WelcomeOutput](
    ctx, g,
    ai.WithSystem(systemPrompt),
    ai.WithPrompt(userPrompt),
)

Now we get:

The welcome note
Extracted occasion
Metadata (sentiment, safety score, comments)

I update UI to showcase metadata panels and structured JSON output.

Lesson: GenerateData[T] gives you type-safe AI responses. The LLM becomes a structured API.

Safe Flow: Add Content Moderation

Production AI needs safety and guardrails. I built a two-stage pipeline:

Generate the welcome note
Moderate it with a second LLM call
If flagged, sanitize and return both versions

Safety Sequence Diagram


      ┌────────┐      ┌───────────────┐      ┌───────────────┐
Input │  User  │ ---> │ Generate Note │ ---> │ Moderate Note │
      └────────┘      └───────────────┘      └───────┬───────┘
                                                     │
                                          Block?  Sanitize?
                                                     │
                                      ┌──────────────▼──────────────┐
                                      │   SafeWelcomeNoteOutput     │
                                      └─────────────────────────────┘

Moderation Prompt (small but effective)

You are a content safety filter. Remove or rewrite:

- toxicity
- insults
- hate speech
- threats
- explicit content
- sensitive details

Return JSON:
{
"note": "... sanitized note ...",
"blocked": false,
"moderationNote": "reason"
}

Safe Flow Logic

// Stage 1: Generate
note := generateWelcomeNote(input)

// Stage 2: Moderate
moderation := moderateContent(note)

if moderation.Blocked {
    return SafeOutput{
        Note:           moderation.SanitizedNote,
        OriginalNote:   note,
        Blocked:        true,
        ModerationNote: moderation.Reason,
    }
}

UI is updated with amber sanitization banner — with "View original (flagged)" collapsible detail.

Lesson: Don't trust raw LLM output. Use a second model to validate safety.

Smart Flow: Interpret Natural Language

The final evolution: let users describe what they want in plain English.

User input:

I need a short, friendly welcome note for my hotel guests arriving this weekend

What happens:

Interpret the description → extract structured parameters
Generate the note using those parameters
Moderate the output for safety

Smart Flow Pipeline

Raw Description
      │
      ▼
Interpretation Flow (LLM → structured input)
      │
      ▼
V3 Generator (structured → JSON note)
      │
      ▼
Safe Flow (moderation + sanitization)
      │
      ▼
SmartWelcomeFlowOutput

Smart Flow Output

This includes:

note (possibly sanitized)
structured fields
metadata
original note (if sanitized)
moderation reason
raw user description
parsed interpretation

type SmartFlowOutput struct {
    *SafeWelcomeNoteOutput              // everything from safe welcome note output
    RawDescription string               // what user typed
    ParsedInput    *WelcomeNoteInput    // result of Interpretation Flow LLM output
}

UI is updated with extra sections such as - "Here's how the AI interpreted your request".
This feels magical for user.

Lesson: Chain flows together. Each step is clean, testable, and observable.

The Interesting Technical Bits

1. CSRF Challenges: Combining Gin and Gorilla

Gin is great for routing and middleware. Gorilla has battle-tested CSRF protection. But they don't play nicely out of the box.

Gorilla CSRF expects http.Handler, while Gin uses its own handler chain. I needed to combine the best of both.

The solution: Wrap the Gin router with CSRF middleware:

// In cmd/web/main.go
router := gin.New()
// use router as needed to define routes

// Wrap Gin with Gorilla CSRF
handler := csrf.Protect(
    cfg.CSRF.Key,
    csrf.SameSite(csrf.SameSiteStrictMode),
    // ... other options
)(router)

// Helper middleware to add CSRF token to Gin context
    router.Use(func(c *gin.Context) {
        c.Set("csrf_token", csrf.Token(c.Request))
        c.Next()
})
// handler is of type http.Handler and ready to be used
mux := http.NewServeMux()
mux.Handle("/", handler)

2. Configurable Rate Limiting

I built per-IP rate limiting with zero rebuilds for config changes:

# Environment variables
RATE_LIMIT_REQUESTS_PER_MINUTE=30
RATE_LIMIT_BURST_SIZE=5

The middleware uses Go's golang.org/x/time/rate for token bucket limiting. Clean, efficient, and Docker-friendly.

3. Reactive UI Without JavaScript

Datastar + Templ = reactive UI via Server-Sent Events:

<form data-on-submit="@post('/api/smart/generate')">
  <textarea name="description"></textarea>
  <button>Generate</button>
</form>

<div data-signal-loading>Loading...</div>
<div data-signal-result>{result.note}</div>

The server streams updates, the browser reacts—all type-safe in Go.

Why This Architecture Works (and scales)

1. Go is the perfect LLM backend

Fast
Typed
Memory-efficient
Simple concurrency model
Deployable anywhere

2. Genkit flows > hand-rolled AI wrappers

Observability
Schemas
Generation tracing
Safe replayability
Validation
Type inference

3. Templ + Datastar feel like React without React

Full reactivity
No client bundles
No JS toolchain

4. Multi-stage flows model real AI workloads

Generation
Interpretation
Moderation
Structured output
Pipeline composition

This mirrors real systems: customer support bots, agents, RAG pipelines, content tools, internal automation.

Try It Yourself

The full code is open source. You can:

Run it locally with Ollama (no API keys needed)
Deploy with Docker (one command)
Swap Gemini for other models
Extend the flows with your own logic

Key files:

internal/flows/ — All 5 flow versions
web/middleware/ — Rate limiting, CSRF, logging
web/templates/ — Templ components
Dockerfile — Production-ready Alpine build

Final Thoughts

This project started as a small experiment:

“What if I built an AI product entirely in Go?”

It ended up demonstrating something bigger. Go's simplicity, Genkit's type safety, and a few well-chosen tools can give you:

Fast iteration
Clean architecture
Production-ready features
Type safety from frontend to LLM

Start with V1. Add structure when you need it. Layer in safety and smart features as you go.

The code is simple and the results are powerful.

Built with Go 1.25, Genkit 1.2, and a love for clean code.

🔗 GitHub: View the code
🚀 Live Demo: Try it live

Originally published on Medium: https://medium.com/p/0d9be75d3d00 — posting here for the dev.to community as well.