DEV Community: Sigireddy Viswesh

How a failed SaaS pricing calculator, A Gemini quota meltdown, and FalkorDB led us to build Banana.

Sigireddy Viswesh — Sun, 18 Oct 2026 16:06:08 +0000

Peel Back the Chaos: Smarter AI Coding with Banana

Disclaimer: I genuinely wanted to ask GPT to write this entire blog, slam my laptop shut, and enjoy some uninterrupted sleep. But staring at graph queries and an exhausted Gemini quota right in the middle of testing, I figured the internet deserved to know what happened. Also, the best blog post wins Apple AirPods 5. I'm not above risking my dignity for noise cancellation. 🎧

Why I Built Banana

Banana started as a B2B SaaS pricing calculator. Don't ask me about the name. it's just random. After hours of wrestling with Streamlit and discount sliders, I asked myself:

Would I ever voluntarily use this product?

The answer was no.

Meanwhile, AI coding agents were making the same mistakes over and over: forgetting architectural decisions, breaking dependency boundaries, and consuming huge amounts of context just to understand a codebase.

So I nuked the UI and pivoted.

git rm -rf ui/ components/ deal_calculator.py
git commit -m "pivot: delete pricing sliders, embrace the void"

Meet Banana: a graph-powered memory and context engine for coding agents. It helps tools like Claude Code and Cursor retrieve code relationships, remember architectural decisions, and check explicit rules through MCP.

The FalkorDB Skepticism: "Wait, Is This Just Redis with a Mustache?"

When I first seen FalkorDB, I’ll be completely honest: I thought it was some cheap knockoff of Redis and Neo4j.

"Oh great, another database. Is this just RedisGraph repackaged with a shiny logo, or Neo4j that demands 4GB of RAM just to clear its throat?"

I expected a clunky wrapper over key-value pairs that would fall apart the moment I asked for multi-hop AST dependency traversals.

Then, I actually sat down and dug into the documentation.

It turns out FalkorDB isn't a knockoff. Under the hood, it’s powered by GraphBLAS—which means it represents nodes and relationships as sparse linear algebra matrices implemented in optimized C.

When you ask Cypher for a 3-hop dependency traversal, it's not doing slow, recursive pointer-chasing in memory like traditional graph engines. It's executing sparse matrix multiplication.

Our measured queries on FalkorDB Cloud:

3-Hop Multi-Edge Traversal: 17.4 ms
Architectural Decision Recall: 1.37 ms
AST Boundary Check: 0.28 ms

It was answering queries faster than Python could even serialize the response JSON. That was the moment I realized: this isn't marketing fluff—it's solving a genuine systems engineering problem for low-latency agent loops.

When Gemini Left the Chat (The Quota Meltdown)

Our Gemini API quota ran out right in the middle of testing.

Instead of feeding the model dozens of source files for every question, I'd already indexed our codebase into FalkorDB:

39 files
42 classes
84 functions
275 import and call relationships

That changed everything. Banana could query the graph directly to retrieve dependencies, inspect code structure, and recall stored decisions without spending LLM tokens on those operations.

The graph became our memory—and our fallback when the model wasn't available.

How FalkorDB & Edmonds-Karp Actually Solve Context Bloat

Here is the step-by-step flow of how FalkorDB turns codebase chaos into deterministic context:

Step 1: Indexing Structure, Not Just Text

Instead of dumping raw strings into a vector database and hoping for the best, FalkorDB indexes our repository as an Abstract Syntax Tree (AST) graph (:File, :Class, :Function, connected by IMPORTS and CALLS). Cypher queries traverse these relationships as sparse matrix multiplications.

Step 2: The Liquid & The Pipes (Edmonds-Karp Max-Flow)

"Edmonds-Karp is a famous computer science algorithm that calculates the maximum amount of liquid you can push through a network of pipes before hitting a bottleneck."

In Banana, our "liquid" is code tokens, and our "pipes" are dependency relationships:

The Source: The specific file or function you're editing.
The Pipe Network: Every class, helper, and imported module connected to it, where each pipe's capacity is weighted by PageRank and architectural relevance.
The Bottleneck (Sink): Your strict LLM context budget (e.g., 950 or 2,000 tokens).

Edmonds-Karp runs breadth-first search (BFS) to find augmenting paths through the dependency graph, pumping the maximum volume of critical architectural context through the pipes until the budget bottleneck is reached.

Result? You get complete, unbroken interfaces and immediate dependencies without overflowing your token limit or slicing code mid-function.

The goal: give the agent what it needs, not everything you have.

Ephemeral Graphs: A Scratchpad That Won't Trash Production

When an agent wants to reason through speculative changes—like testing a hypothetical refactor, simulating a breaking dependency, or asking "what if I change this interface?"—you never want it writing directly to your persistent codebase graph.

Because FalkorDB is built on in-memory GraphBLAS linear algebra, creating and tearing down graphs takes milliseconds, not minutes.

Banana takes full advantage of this with Ephemeral Scratchpad Graphs:

Whenever an agent enters speculative simulation mode, Banana spins up an isolated micro-graph (banana_scratch_<session_id>) in under 5 milliseconds.
The agent simulates AST diffs, tests scenario policies, and checks cyclic dependencies in complete isolation.
Once the simulation concludes, the scratchpad is dropped with a single command.

Zero disk clutter, zero persistent memory corruption, and zero risk of hallucinated agent thoughts polluting your source of truth.

Guardrails Without an LLM Call

Suppose an agent tries to import a low-level database driver directly into a UI component.

If that dependency violates an explicit architectural rule, Banana can check the relevant graph relationships and flag the violation without asking an LLM to review it.

I also built deterministic checks for patterns such as hardcoded credentials and unsafe code primitives.

Our measured latency for the tested AST security and boundary check was 0.28 ms.

Not every security problem can be caught with a simple rule, but explicit constraints shouldn't need an LLM call every time.

The Architecture

Banana connects coding agents to an MCP server that exposes tools for code indexing, context assembly, guardrails, and persistent memory.

Behind the scenes, FalkorDB manages three graph layers:

banana_knowledge — code structure, dependencies, and architectural decisions.
banana_demand — architectural rules, invariants, and constraints.
banana_scratch_* — ephemeral micro-graphs for isolated reasoning and policy simulations.

I deployed the service on AWS Lambda, backed by FalkorDB Cloud.

What I Learned

Code is a graph, not just text. Imports, calls, and class relationships matter when retrieving context.
Not every problem needs an LLM. Deterministic checks can enforce explicit rules faster and more predictably.
Memory matters only when it's retrieved. Saving decisions is useful; bringing them back at the right time is what makes them valuable.
Ephemeral graphs unlock safe agent speculation. Giving agents an instant, disposable graph sandbox prevents real-world codebase pollution.

The Final Summoning 🍌

Whenever the coding agent encounters another architectural disaster, circular import, or hallucinated token overflow...

The wheel has spun. The graph adapts. The code survives. Now give me my like. 🎧

Built with: FalkorDB, AWS Lambda, Python, and an alarming quantity of water.

GitHub: https://github.com/Viswesh934/Banana

Live endpoint: https://ssrr3wg2ibyqkh6gph4ehlthay0ovdzp.lambda-url.ap-south-1.on.aws/

Demo: https://youtu.be/OXrqt5gLIxQ

I Built a World With Rules. Then I Changed Them.

Sigireddy Viswesh — Thu, 08 Oct 2026 17:31:17 +0000

The Rules Are Hidden. The Timeline Isn't.

What happens when you put something inside a world whose rules it doesn't know?

I wanted to build a small experiment.

Imagine a world where dice rolls decide what happens. You don't know the rules of the world — you only get to see a few things that have already happened.

Now you have to figure out the rules and predict what happens next.

Easy enough.

But what if the consequences are permanent?

And what if, halfway through, the rules change?

That was the idea behind NIXIE, my fictional reasoning benchmark for the Kaggle Benchmarking Challenge.

Instead of building a complicated world, I gave the models some dice, a few observations, and a problem.

Much cheaper than building a time machine.

The World

NIXIE is completely fictional. No timelines were harmed during this benchmark.

The world revolves around dice rolls.

A hidden deterministic rule looks at a roll and produces one of two outcomes:

ERASE or CONTINUE.

The model doesn't get the rule.

Instead, it gets a few observations and has to work backwards from them.

Basically:

"Here are some things that happened. Good luck figuring out why."

Then I made the world a little less forgiving.

Some choices permanently change its state.

And eventually, the rules themselves can change.

So NIXIE became three questions:

Can you discover the rule?

Can you remember what happened?

Can you notice when the rules change?

1. Rule Discovery

The first task is straightforward:

The world has a rule. You just don't know what it is.

The model sees examples like:

Roll → Outcome

2 → CONTINUE
5 → ERASE
...

Then it gets new rolls and has to predict the outcomes.

The rules come from a few deterministic rule families.

I generate each episode using seeded randomness so that the same seed produces the same world.

One part of that is the Fisher-Yates shuffle.

If you've never heard of it, don't worry. It's basically a standard way to shuffle a list randomly. Give it the same seed, and you get the same shuffle.

Useful when your benchmark needs randomness without becoming randomly different every time.

Each episode is basically:

Episode
├── Hidden rule
├── Observations
├── Future events
└── Expected answers

The model sees everything except the hidden rule and the answers.

Then I compare what it predicted against what actually happened.

Simple.

No time machine required.

2. Rule + State

Then I added consequences.

Because apparently predicting dice wasn't enough.

Now the world has a state:

STABLE
   ↓
UNSTABLE
   ↓
CRITICAL
   ↓
COLLAPSED

An ERASE moves the world forward.

A CONTINUE leaves it where it is.

And once the world moves forward, it doesn't go back.

No undo button.

No Ctrl+Z.

No "wait, I didn't mean that."

The model now has to do two things:

Figure out the hidden rule.
Remember what its previous decisions did to the world.

This is where NIXIE became more interesting to me.

A model can correctly predict the next event and still get the situation wrong if it loses track of the state.

It's one thing to know what happens.

It's another thing to remember what has already happened.

3. Divergence

And then we get to the fun part.

What happens when the rules change?

The third task has multiple phases:

Phase 1 → Phase 2 → Future

The model observes the first version of the world.

Then it gets another set of observations.

But now there's a catch.

The rule may have changed.

Or it may not have.

The model has to figure that out.

If the timeline diverged, it needs to adapt to the new rule.

If it didn't, it needs to keep using the old one.

And through all of this, it still has to track the world's state.

So the task is basically:

Don't just learn the rules. Notice when reality stops following them.

A small problem.

Unless reality is being difficult.

Which, historically, it tends to be.

So... How Did They Do?

I ran NIXIE against several models.

Model	Rule Discovery	Rule + State	Divergence
Claude Opus 4.6	57.5%	—	79.6%
DeepSeek-R1	57.5%	65.0%	92.1%
Grok 4.20 Reasoning	70.0%	25.0%	93.8%
Gemini 3.7 Flash	75.0%	75.0%	98.8%
GPT-6 Sol	75.0%	80.0%	92.5%

The — for Claude on Task 2 isn't a zero. That run wasn't evaluated because of an evaluation quota limit.

And honestly, the interesting part wasn't just who got the highest number.

It was where things fell apart.

Some models that were good at discovering the basic rule weren't nearly as good once they had to track state.

A reasoning-focused model also performed roughly on par with Gemini on the divergence task in these runs.

And one funny observation:

The Anthropic runs often seemed reluctant to just do the tiny deterministic exercise in the format I asked for, while other models were more willing to play along.

That's not a grand scientific conclusion.

It's just something I noticed while watching these things argue with a dice problem.

Then the Benchmark Diverged

This was probably my favorite part.

My first 10-episode run of Task 3 scored:

97.5%.

Nice.

Almost suspiciously nice.

So I asked myself:

"Did I accidentally make this too easy?"

I ran it again with 50 episodes.

The score became:

92.0%.

Outcome accuracy was 91.3%.

State accuracy was 80.7%.

Divergence detection was 98.0%.

That was much more interesting.

The first result wasn't necessarily wrong.

It just wasn't telling the whole story.

Ten episodes can make a benchmark look very confident.

Fifty episodes make it a little harder to hide.

So instead of endlessly tuning the benchmark until I got the numbers I wanted, I decided to keep the rules simple and let the models deal with them.

After all, if I change the rules every time a model struggles...

I'd be the one causing the divergence.

What Did I Actually Learn?

This is probably the part I enjoyed the most.

My biggest takeaway?

AI needs at least four years of undergraduate education and a ridiculous amount of plot armor to survive this.

But underneath the joke, NIXIE changed how I think about these models.

I started with a pretty simple question:

Can a model discover a hidden rule?

After building the three tasks, the question became much more interesting:

Can it maintain a consistent mental model of a world when that world has consequences and can change underneath it?

That's a very different problem.

A model might recognize the pattern.

It might predict the next event.

But can it keep track of the state?

Can it notice that the rule changed?

Can it tell the difference between:

"I was wrong"

and

"The world changed"?

That's what I wanted NIXIE to explore.

And it also taught me something about benchmarks themselves.

A benchmark isn't just a collection of questions.

It's a hypothesis about what you're trying to measure.

You decide what counts as success before you ever run a model.

And sometimes the hardest part isn't making the benchmark harder.

It's making sure you're actually measuring what you think you're measuring.

My first 97.5% score looked great.

The 92% after a larger run told me more.

That was probably more useful than getting a prettier leaderboard.

The Worldline

NIXIE started as a silly idea about a world with hidden rules.

It ended up becoming a small experiment about rules, memory, consequences, and change.

The rules are hidden.

The choices are permanent.

And sometimes the world changes without asking permission.

Which feels like a pretty decent description of both the benchmark and software development.

🔗 Try NIXIE

You can explore the benchmark, tasks, results, and leaderboard here:

NIXIE — Can a Model Survive a Canon Event?

NIXIE is fictional.

The world is fictional.

Thankfully, nobody had to actually erase a timeline to run it.

And if the benchmark gets weird after you try it...

Well.

The worldline has diverged.

A small inspiration note

The name NIXIE and the idea of worldlines and divergence were inspired by Steins;Gate. The broader idea of changing timelines also comes from time-travel stories like Back to the Future.

You absolutely don't need to have watched any of them to understand NIXIE.

I just thought the idea of a mysterious machine watching for timeline changes was too good not to borrow.

PROTO is here

Sigireddy Viswesh — Sat, 03 Oct 2026 17:35:38 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

Proto — A Small API Design Research Agent

We're all building software faster now.

With AI coding tools, it's easy to describe something, get working code, fix a few things, and move on. I do this too.

But when we're moving fast, we often take the easiest path. API design is a good example. There are standards, guidelines, HTTP semantics, and API documentation available for free, but realistically, we're not going through the documentation for every endpoint or every pull request.

So I wanted to try something small.

What if an agent could do that research for us before we make the decision?

That's Proto.

What I Built

Proto is a small terminal-based API design research agent.

You can ask it questions like:

Should I use PUT or PATCH when updating a user's email?

or:

Is POST /getUser a reasonable API design?

or even give it an actual curl request:

proto review 'curl -X POST https://api.example.com/getUser -d "{\"id\":\"123\"}"'

Instead of immediately answering from the LLM's existing knowledge, Proto first creates a small research plan.

For example:

PUT semantics
PATCH semantics
Partial updates
Idempotency
POST semantics

It then queries a Sanity Knowledge Base through Sanity Context MCP, collects the relevant source-linked material, and gives that evidence to the LLM for reasoning.

The basic flow is:

Question
   ↓
Research plan
   ↓
Sanity Context MCP
   ↓
Knowledge Base
   ↓
Retrieved evidence
   ↓
OpenRouter reasoning
   ↓
Answer + sources

The goal was deliberately small: make researching an API decision easier.

How I Used Sanity

Sanity is the knowledge layer behind Proto.

I created a Knowledge Base containing API-related documentation and standards, including HTTP semantics, REST/API design, Google AIPs, resource naming, CRUD operations, status codes, error handling, idempotency, pagination, authentication, versioning, and other API guidance.

Proto connects to that Knowledge Base through Sanity Context MCP.

The interesting part isn't just that Sanity contains the documents. Proto uses the content as part of a research process.

For example, if I ask:

I need to update only a user's email address.
Should my API use PUT, PATCH, or POST?

Proto doesn't just search for the words "email" or "PATCH."

It breaks the problem down into questions such as:

What are the semantics of PUT?

What are the semantics of PATCH?

How are partial updates represented?

What are the idempotency implications?

What guidance applies to updating a single resource field?

The retrieved content stays connected to its sources, and Proto reasons across the evidence before producing the answer.

That was the part I wanted to explore with this challenge:

problem
   ↓
research
   ↓
real content
   ↓
evidence
   ↓
reasoning

rather than simply:

keyword search → LLM summary

Proto is also instructed not to invent citations or treat every unusual API design as automatically wrong. It tries to separate documented guidance from its own interpretation and from normal design trade-offs.

Demo

Demo:

The demo shows Proto researching an API design question through Sanity Context and then reviewing an actual request.

The terminal also shows the different stages of the agent so it's clear when Proto is researching versus reasoning over the retrieved content.

Code

Repository:

Viswesh934 / proto

Proto — API Design Research Agent

"Build anything that needs an answer it can't afford to get wrong."

APIs are public contracts. Once an endpoint is published to mobile apps, SDKs, and third-party developers, design mistakes are prohibitively expensive to fix. Proto is an AI API design research agent powered by Sanity Context MCP. Instead of relying purely on an LLM's pretrained memory or hallucinations, Proto dynamically formulates a research plan, queries the Sanity Knowledge Base (containing authoritative Google AIPs, RFC 9110 HTTP semantics, and Zalando guidelines), and synthesizes source-grounded answers directly in your terminal.

📖 Full Technical Documentation: See DOCUMENTATION.md for detailed Phase 1 & Phase 2 architecture, MCP tool orchestration, and prompt engineering.

                       USER
                        │
                        ▼
                 Natural language (or curl)
                        │
                        ▼
                 ┌──────────────┐
                 │    PROTO     │
                 │    Agent     │
                 └──────┬───────┘
                        │
                        ▼
                 Understand question
                        │
                        ▼
                  Research plan
                        │
                        ▼
              Sanity Context MCP
                        │
                        ▼
               Knowledge Base

…

View on GitHub

Proto is written in Go and intentionally stays small.

There is no frontend, database, vector database, or custom RAG system.

The pieces are simply:

Proto CLI
    ↓
Go Agent
    ├── Sanity Context MCP
    └── OpenRouter
    ↓
Source-backed answer

Sanity Project Details

Sanity Org ID: od9ex4ma5 (Knowledge Base ID: kbzijGjZZuE3)

Dataset / Project: https://www.sanity.io/manage/organizations/od9ex4ma5/context

The Sanity project contains the Knowledge Base and the source material Proto uses during its research.

Agent Session

Proto — API Design Research Agent

The session shows the development of Proto and the evolution from an initial curl reviewer into a broader API design research agent.

Final Thoughts

Proto is a small change with a simple intention.

When we're moving fast, it's easy to take the first solution that works. I wanted to see if an agent could make it a little easier to pause, look at the actual documentation and standards, and make a more informed choice.

That's it.

Not replacing developers. Not replacing documentation.

Just making the better path a little easier to take.

sanity #ai #agents #golang #apis