DEV Community: Vishal Somaraju

We built a security gate for Git pushes. Then we gave it a memory.

Vishal Somaraju — Tue, 29 Sep 2026 19:14:02 +0000

One of the most annoying things about security issues in a project is that you can fix the same type of problem more than once.

You find a vulnerability.

You fix it.

A few days later, something similar happens again.

And your security tool starts from zero.

That was the idea behind SecurePush.

We wanted to build something that could sit in the normal Git workflow and check code before it gets pushed, but we also wanted it to remember what happened in previous reviews.

That is where Hindsight came in.

So what is SecurePush?

SecurePush is basically a security gate for git push.

Instead of pushing code directly to the remote repository, SecurePush checks the changes first.

The flow is pretty simple.

You make your changes.

You run:

git push

SecurePush picks up the changed files and reviews them for security issues.

If it finds something, it explains what is wrong and suggests a fix.

You can accept the fix or reject it.

If you accept it, SecurePush applies the change and runs the checks again.

If everything passes, the push continues.

If there is still a problem, the push is blocked.

Simple enough.

But the interesting part comes after that.

What if it remembered?

Let's say SecurePush finds a hardcoded credential in your project.

It tells you about it and suggests moving it to an environment variable.

You accept the fix.

The fix is applied.

The tests pass.

The push goes through.

Normally, that's the end of it.

But we don't want SecurePush to forget that entire interaction.

We use Hindsight to remember it.

Not the actual secret.

The useful information around it.

Something like:

A hardcoded credential was found in scripts.js. The developer accepted the environment variable fix and the tests passed.

Now that information is part of the repository's security memory.

Then comes the second push

Later, you make another change.

SecurePush doesn't just look at the new code.

Before reviewing it, it checks the repository's previous security memory.

It might find that the repository has already had a similar credential issue before.

That context is then given to the security review.

So instead of every review being completely isolated, the agent has some idea of what happened before.

And this is the part we wanted to demonstrate with Hindsight.

First review:

It finds the problem.

The developer makes a decision.

The result gets remembered.

Later review:

A similar situation comes up.

The previous decision can be recalled.

The current code is still checked normally, but now there is some history behind the review.

We also wanted the memory to be visible

We didn't want Hindsight to just be something hidden in the backend that we mention during the presentation.

So we added a Memory section to SecurePush.

It shows what the repository has remembered from previous security reviews.

You can see things like the type of issue, the file involved, what the developer decided, whether the fix worked, and other relevant information.

The idea is simple.

You should be able to see what the system remembers instead of just being told that it has memory.

There was one important problem

If SecurePush is supposed to find secrets, we obviously can't just store those secrets in its memory.

So before something is retained, sensitive values are removed.

We want to remember:

A hardcoded credential was found and the developer moved it to an environment variable.

We don't want to remember:

API_KEY = "actual-secret"

That was an important part of building the memory layer properly.

The complete flow

So the final workflow looks like this:

Code change

↓

git push

↓

SecurePush scans the changes

↓

Previous security memory is recalled

↓

Security issue is found

↓

Developer accepts or rejects the fix

↓

Fix is applied and verified

↓

Push is allowed or blocked

↓

The result is remembered

And the next review can use that memory.

What we actually found interesting

For me, the interesting part wasn't just getting an LLM to find a security vulnerability.

There are already plenty of tools that can do that.

The interesting part was seeing what happens when the system doesn't forget every interaction.

A normal security scan can tell you what is wrong with the code right now.

With memory, the system can also have some context about what happened in the repository before.

That opens up a lot of possibilities beyond SecurePush too.

Repositories have a lot of history.

Why a certain decision was made.

Which fixes were tried.

Which security issues kept coming back.

What the team accepted or rejected.

A lot of that knowledge normally stays scattered across commits, issues, chats, and people's heads.

We wanted to see what happens when some of that knowledge can actually be remembered and used during the next interaction.

That's what we built with SecurePush.

**A security gate that doesn't just check your code.

It remembers what happened before.**

How CascadeFlow Cut Our Review Cost Without Hurting Quality

Vishal Somaraju — Sun, 28 Jun 2026 17:38:59 +0000

*Most AI dev tools have the same bad habit: *
send everything to the biggest model available and hope the bill feels reasonable later.
That works for demos. It doesn't work when you're actually building something.
A five-line hello world should not cost the same as reviewing auth middleware touching JWTs, SQL, async flows, and environment variables. But a lot of tools treat every snippet like a production incident. Same model, same cost, every time — regardless of what the code actually is.
That was the problem we kept running into while building Refyn. We were working under real time pressure, and the fastest way to burn both budget and reliability was dumb routing. We'd already watched Gemini fail completely — four supposedly valid API keys from three different Google accounts, all returning "API key not valid." To this day we don't know why. Then a Groq model got decommissioned mid-testing, mid-session, with a 400 error and no warning. After that, "just send everything to one model" stopped sounding simple. It started sounding fragile.
CascadeFlow became our answer: score the code first, then decide how much model you actually need.

What Refyn Is :
Refyn is a browser-based VS Code-style code review workspace — React, Vite, Monaco Editor, Tailwind, Framer Motion on the frontend, Node.js and Express on the back.
You paste code, hit Analyze, get structured issues back with severity tags, a quality score, and a Smart Fix button. Standard stuff. The part that isn't standard is what happens before the model call.
Refyn has two layers most review tools skip entirely.
The first is Hindsight memory. It remembers your recurring patterns across sessions and injects that history into future prompts. By your third review, it's leading with your known weak spots instead of treating you like a stranger.
The second is CascadeFlow-style routing. Before any model runs, Refyn scores the code on a 0–100 complexity scale. Simple code takes the cheap fast path. Security-sensitive or structurally dense code escalates automatically.
Both of these came out of necessity, not ambition. Gemini was removed entirely after it became unusable. Groq became primary. OpenRouter became the backup layer with four free model fallbacks. Piston replaced Judge0 for execution because Docker overhead was too heavy locally and too expensive in production. The architecture we shipped was shaped by what kept breaking.

The Routing Problem :
The math is simple: most code is not equally hard to review, but most LLM integrations price it as if it is.
If you always call the expensive path, costs drift upward even when quality doesn't improve. A tiny utility function doesn't need the same review budget as an authentication service. But without routing logic, it gets the same one anyway.
Refyn's cost model is explicit in cascadeService.js. Groq runs at roughly $0.00002 per 1K tokens. The premium baseline for savings comparison is $0.000075 per 1K tokens. On a 100-token review:

Premium baseline: 100 / 1000 * 0.000075 = $0.0000075
Groq route: 100 / 1000 * 0.00002 = $0.000002
Savings: ~73%

That's why the stats bar matters. Cost control becomes visible instead of theoretical. You're not trusting a dashboard you check monthly — you see it on every single review.
The reliability half of the problem is messier. During our build, one Groq model name worked fine, then returned a 400 saying it had been decommissioned. OpenRouter's first free model list started returning 404s because the free tier had quietly rotated. If your routing assumes providers stay stable, your app breaks the moment they act like providers.

How cascadeService.js Works :
The scorer doesn't try to be academically perfect. It tries to be fast, explainable, and useful enough to make better runtime decisions.
jsexport const scoreComplexity = (code, language) => {
let score = 0;
const lines = code.split("\n").length;

if (lines > 200) score += 30;
else if (lines > 100) score += 20;
else if (lines > 50) score += 10;
else score += 5;

for (const model of FALLBACK_ORDER) {
if (model === routing.model) continue;
try {
const result = await MODEL_FNmodel;
if (result.success) {
return enrichResult(result, model, startTime, code, memoryData, {
...routing,
model,
reason: ${routing.model} unavailable — fell back to ${model},
});
}
} catch (e) {
console.error([Cascade] ${model} threw:, e.message);
}
}
That fallback chain exists because the real world is messy. We needed it after Gemini became unusable, after Groq changed model availability mid-session, and after one genuinely embarrassing moment where the backend returned "All models failed to analyze" because our .env file was sitting in the wrong folder. We spent a solid chunk of debugging time blaming providers before realizing config was the actual bug. Classic.
When OpenRouter takes over, it cycles through a list of free models:
jsconst FREE_MODELS = [
"openrouter/free",
"meta-llama/llama-3.3-70b-instruct:free",
"qwen/qwen3-coder:free",
"google/gemma-4-31b-it:free"
];
That list exists because our first version had models that had already rotated out of the free tier. Hardcoded model names age fast. Lesson learned the annoying way.

The Demo Moment :
The best part of Refyn is that the routing is visible.
Paste a small utility function and the stats bar shows:
Model: Groq | Complexity: 12/100 | Cost: $0.000002 | Saved: 72% vs Mixtral | Latency: 340ms
That one line explains the product better than anything else we built.
Then paste something security-sensitive — auth middleware, token parsing, a SQL query builder, anything touching .env or jwt. The complexity score jumps. The selected model changes without you touching a dropdown. The UI makes the decision legible: this review was escalated because the code looked riskier.
That transparency was the thing we kept coming back to. We'd already lived through the opposite — a system that looked smart in screenshots but hid all the runtime decisions. Once model, cost, latency, and savings were visible on every review, the routing story stopped being abstract.

What Hindsight Adds :
CascadeFlow decides which model to use. Hindsight decides what that model should remember.
In aiRouter.js, Refyn loads memory before analysis, builds a context string from past patterns, passes that into the selected model, and saves new patterns after a successful review. Memory is part of the runtime path, not a side feature.
We earned that the hard way. Our first memoryService.js was calling a /memories endpoint that didn't exist — every request silently died in 404s. The fix was switching to the official @vectorize-io/hindsight-client SDK and using recall() and retain() properly. Then we hit the second bug: the SDK returns { results: [...] }, not a plain array, so our parsing was quietly wrong the whole time.
Once that was fixed, the memory panel started populating correctly. Pattern count climbed to 14 across sessions. Then we noticed it reset to zero on page refresh — React state only, not reloaded from Hindsight. Fixed with a useEffect that calls the backend on mount. Small bug, big trust issue. If memory disappears on refresh, it feels fake even when it isn't.

What We'd Build Next :
GitHub PR integration — Refyn works well as a paste-and-review workspace. The natural next step is routing decisions happening file by file inside pull requests instead of one snippet at a time.
Team memory banks — Individual memory is already useful. Shared memory across a team means recurring security issues, preferred patterns, and project-specific conventions survive across contributors, not just sessions.
Budget enforcement — Refyn already calculates cost and savings. Hard limits, escalation warnings, and cost caps per session are the next layer that makes routing operational rather than just visible.

Closing :
Building Refyn taught me that AI cost control is mostly a routing problem disguised as a model problem.
We didn't win by finding one perfect provider. Gemini failed. Groq changed underneath us. OpenRouter free models rotated. Our own .env setup broke everything once. What held up was a system that could score the work, choose the cheapest reasonable path, and recover when something went wrong.
That's the part I trust now. Not the model names. The routing.