DEV Community: SRIHARI P V

I Built an "Amazon-Style" AI Review Summarizer for Any Dataset (NLP, Transformers, Streamlit)

SRIHARI P V — Thu, 18 Jun 2026 01:30:00 +0000

Have you seen those new AI-generated review summaries on Amazon? They are incredibly useful for buyers, but there’s a catch: they are completely locked inside Amazon’s ecosystem.

If you are a developer, PM, or data scientist trying to analyze 5,000 scattered App Store reviews, Shopify comments, or Zendesk tickets, you are still stuck doing it manually or relying on basic word clouds.

I wanted to fix that. So, I built NEXUS 🧠—a production-grade Review Intelligence Engine that brings that exact "Amazon-style" AI analysis to any dataset.

Here is a deep dive into the architecture and how I put it together. 👇

🏗️ 1. The Deep Learning Baseline
Before jumping into massive pre-trained models, I wanted to establish a strong, custom baseline.

The Data: Trained on the Sentiment140 dataset (1.6 Million records).

The Architecture: I built a custom deep Bidirectional LSTM using TensorFlow/Keras. I utilized a 128-dim Embedding layer and stacked Bi-LSTMs to capture deep contextual sequences.

Optimization: Used aggressive Dropout(0.5) layers and EarlyStopping on validation loss to halt training dynamically and restore the best weights, preventing overfitting.

🤖 2. The Transformer Inference Pipelines
To achieve zero-shot classification and granular emotional analysis in the live app, I loaded lightweight HuggingFace pipelines directly into memory:

Sentiment: DeBERTa-v3 for highly accurate Zero-Shot classification (Positive, Neutral, Negative).

Emotional Topography: RoBERTa-go_emotions to extract 28 micro-emotions, which I mapped to heuristic scores (Joy, Frustration, Urgency, Resolve).

⚙️ 3. The "Amazon-Style" Intelligence Engine
Here was the biggest challenge: heavy generative LLMs (like DistilBART) consume massive RAM and are prone to hallucination.

Instead of relying purely on an LLM to write the summary, I wrote a deterministic Component-Impact Engine. It uses Regex and Pandas to chunk sentences, extract hardware/software components (battery, screen, software, ports), calculate the failure/praise rates of each, and dynamically synthesize a natural language summary.

The output? Exactly what engineering needs to see: "Customers heavily praise the screen and UI, but express deep frustration with the battery life."

✨ 4. The Frontend UX/UI
Streamlit is fantastic for Python devs, but out-of-the-box, it can look a bit generic. I wanted a premium, glossy feel. I injected hundreds of lines of custom CSS to override the default DOM, creating a "glassmorphism" aesthetic with animated micro-interactions, gradient borders, and custom Plotly charts.

NEXUS doesn't just say a review is "negative"—it tells the engineering team exactly what is breaking so they can push a fix faster.

I'd love to hear your thoughts! Have you experimented with DeBERTa vs. custom Bi-LSTMs for your own sentiment projects? Let's chat in the comments! 💬

Link- https://sentimentanalyser-ucccl9ut869ugpmqid2ttg.streamlit.app/

I built an App that judges your face to play music (So you don't have to scroll Spotify) 🎧

SRIHARI P V — Tue, 16 Jun 2026 13:00:00 +0000

We've all been there. You open Spotify or YouTube, stare at your 47 different playlists, and spend 15 minutes trying to figure out if your current existential dread requires Lo-Fi Beats or Heavy Metal.

I decided that making decisions is overrated. Why not let a neural network look at your face and decide how you feel instead?

Say hello to Viso Vibe: https://viso-vibe.streamlit.app/

On the outside, it looks like a sleek, high-end, premium audio interface. On the inside? It’s a beautifully stitched-together monster of Python, custom JavaScript hacks, and ONNX models running inside a container.

Here is exactly how this absolute unit of an app works:

The Streamlit Catfish Frontend: Streamlit is amazing for data apps, but it usually looks like... a data app. I didn't want that. So, I brutally injected raw HTML, CSS, and JS to completely murder the default styling. Custom #06060F dark background? Checked. Noise textures? Checked. Turning a standard file/camera input into a glowing, animated shutter button? Absolutely.

The Dual-Model Brains (ONNX): When you click that glowing shutter, your photo is converted into a NumPy array and fed into the pipeline. First, detection.onnx hunts down your face, draws a box, and crops it. Then, emotion.onnx uses a neural network (HSEmotionRecognizer) to analyze your facial muscles and calculate a probability score across 7 baseline emotions.

The Emotional Router: To avoid choice paralysis, I boiled human emotion down into 4 distinct musical lanes:

1.Happiness/Surprise ➔ Happy (Solar Palette ☀️)

2.Sadness ➔ Sad (Cobalt Palette 🌊)

3.Anger/Disgust/Fear ➔ Angry (Crimson Palette 🔥)

4.Neutral ➔ Calm (Sage Palette 🌿)

The Passive-Aggressive Feedback: Before the track even starts, Google Text-to-Speech (gTTS) generates a custom voice track saying, "You seem [emotion]. Let me play something for you." It base64 encodes it into an invisible HTML tag to voice-line you the second the page updates.

The Ninja Media Player: Streamlit's audio players are static and boring. So, I used streamlit.components.v1.html to inject a massive custom UI card. It renders an HTML canvas orbital visualizer with floating particles and reactive audio bars. To get the actual music, a completely hidden div loads the official YouTube IFrame API. The app triggers a random index between 0 and 50 within my curated mood playlists, and the custom player buttons pipe invisible commands like player.playVideo() right to the hidden YouTube element. No YouTube player layout visible, just vibes.

🔥 Try it out & Roast/Review it!
It is live right now: 👉 https://viso-vibe.streamlit.app/

Go ahead, try to fake a smile to get a happy playlist, or give it your worst Monday morning stare to trigger the Angry (Tamil Mass Beats) queue.

I need your help with two things:

Playlist Suggestions: What absolute bangers, deep-cut YouTube mixes, or hidden lo-fi tracks am I missing? Tell me what needs to go into the Happy, Calm, Sad, or Angry databases!

Code Roast: Tell me what you think of using hidden IFrames and raw JS to bypass UI limitations.

Drop your thoughts and playlist recommendations in the comments! 👇

Why We Need to Stop Forcing AI into Internet Dead Zones (And a Simple Fix)

SRIHARI P V — Sat, 06 Jun 2026 12:30:00 +0000

I think we’ve reached a point where our collective default answer to every single software problem is: "Just throw an LLM API at it and call it a day."

I was deep in a rabbit hole last week looking at how high-stakes, heavy industries—like underground mining, heavy manufacturing, or shipping yards—handle safety protocols and operator certifications. We are talking about environments where missing a single detail (like a pressure threshold on a specific valve) isn't just a bug; it's a massive, life-threatening disaster.

The standard modern advice is: "Just spin up a cloud-hosted vector database, build a standard RAG pipeline, and let ChatGPT handle it!"

But if you step out of the silicon valley bubble and look at a real industrial site, that entire plan falls apart instantly for two incredibly simple reasons:

The Connected Dead Zone: You cannot hit an OpenAI or Anthropic endpoint from the bottom of an underground mining shaft or inside a heavily shielded concrete manufacturing bay. Internet connectivity isn't a given; it's a luxury.

The Probability Trap: Large Language Models are probabilistic. They guess the next word based on mathematical distributions. If you ask an LLM about a shutdown protocol, and it decides that "1500 PSI" sounds statistically similar to "2500 PSI," it will confidently lie to you.

When people’s lives depend on strict manuals, you cannot use a system that guesses.

So I started experimenting with a different approach. What if we stop trying to make the AI "think" or "search," and instead use it purely to format data that we’ve already locked down mathematically?

I put together a local prototype to test this approach, using zero cloud dependencies. Here’s how it works.

Step 1: Ditch Vector Search for a Local Graph
Standard RAG relies on vector similarity (guessing what words mean). I didn't want guessing. I used Neo4j running locally to parse unstructured safety manuals into a strict Knowledge Graph. Every safety rule becomes a physical node with exact attributes attached.

Step 2: Math Before AI
If a safety inspector needs an exam that is exactly 40% "Emergency Protocols" and 60% "Routine Checks," an LLM cannot reliably count or balance that.

So, before the AI is even involved, a python script queries the graph. It looks at the sliders, balances the percentages, and pulls the exact rules needed to meet the quota. It locks these facts in a box.

Step 3: The Traversal Algorithm (DCWGT)
To actually make that math work, I wrote a custom algorithm called Dynamic Cognitive-Weighted Graph Traversal (DCWGT).

It treats the Neo4j database like a multi-dimensional optimization puzzle. When it receives the constraints from the UI, it doesn't just blindly grab the first nodes it sees. It sorts the available rules based on their embedded metadata—like their Risk Score (1-10) and Cognitive Depth.

But here is the coolest part: What happens if the user requests 5 Emergency rules, but that specific machine section only has 3? Standard logic would just throw a system error. Instead, the DCWGT algorithm uses a "recursive sibling fallback." It dynamically traverses up the graph tree and laterally searches for contextually linked "sibling" categories to borrow rules from.

It ensures the mathematical quota is always met, grabs those verified facts, and locks them into an unchangeable data payload.

Step 4: The Local LLM as a "Dumb" Formatter
Only after the algorithm has 100% locked down the facts do we hand them to an AI.

Instead of paying for expensive cloud APIs, I set up Llama-3 to run entirely locally on my machine's CPU using Ollama. I feed the locked rules into a strict prompt that tells the LLM: "You are an absolute compiler. Turn these exact facts into a multiple-choice test. Do not invent anything outside this context."

Because the LLM is physically blocked from browsing the internet or pulling from its own probabilistic memory, it acts purely as a text formatter. It cannot hallucinate.

3 Famous "Bugs" That Actually Built the Tech World We Live In Today

SRIHARI P V — Wed, 03 Jun 2026 13:30:00 +0000

So I was deep in a debugging session last week — one of those 3 AM, "why is this even happening" kind of nights — and I started going down a rabbit hole.

What if the bug I'm staring at isn't a bug? What if some of the most iconic moments in tech history were born from a broken line of code that nobody meant to write?

Turns out, yes. Absolutely yes. Here are three real stories that prove bugs aren't always your enemy.

🕰️ 1. The Y2K Bug — The $300 Billion Accident That Modernized the Entire World

Let's go back to the 1970s. Computer memory was brutally expensive back then. We're talking about the kind of expensive where engineers lost sleep just thinking about storage costs. So programmers all across the industry made one very logical, very reasonable decision — they stored years using only two digits.

1975 became 75. 1999 became 99. Simple, clean, memory-efficient.

And every single one of those engineers thought the same thing: "These machines will be scrap metal long before the year 2000. This is someone else's problem."

Nobody was wrong. They just all thought the same way.

Fast forward to 1999. A quiet, creeping panic started spreading through boardrooms, government offices, and server rooms worldwide. Because people suddenly realized what happens when the clock ticks from December 31, 1999 to January 1, 2000.

The computers would read the year as 00.

And 00 is less than 99.

So in the brain of every system running that two-digit logic — banks, hospitals, airports, nuclear plants, stock exchanges — January 1, 2000 would not register as the year 2000.

It would register as January 1, 1900.

Interest calculations would go haywire. A loan taken in "99" would show a debt of 100 years. Flight systems wouldn't know which year it was. Power grids could trip. The entire digital backbone of civilization was built on a two-digit shortcut.

What happened next was remarkable.

The world didn't collapse. It didn't collapse because humanity triggered the single largest software maintenance project in history. Governments pumped hundreds of billions into it. Millions of developers were hired overnight. Companies dug through every codebase they owned — decades of COBOL, FORTRAN, legacy systems nobody had touched in years — and patched them line by line.

And in doing all of that frantic patching, something unexpected happened. All those ancient, crumbling systems that companies had been holding together with prayers and old documentation? They got replaced. Upgraded. Retired. The Y2K bug forced the entire planet to modernize its IT infrastructure in a way that would have taken another 20 years otherwise.

The bug that almost ended the world ended up jump-starting the modern tech era instead.

🕹️ 2. The Atari Easter Egg — One Developer's Rebellion That Changed Software Forever

The year is 1979. Warren Robinett has spent months building Adventure for the Atari 2600 — one of the most complex games of its era. Dungeons, dragons, a castle, a sword, a goblin. This was genuinely impressive work.

There was just one problem. Atari had a policy: no developer names on the games. No credits. No acknowledgment. The developers were invisible ghosts who built the product, handed it over, and disappeared. Management thought this would prevent competitors from poaching their talent.

Warren Robinett decided that was not going to fly.

Without telling anyone, he spent time coding something secret — something so cleverly hidden that even Atari's own QA team wouldn't find it. He built a hidden room inside the game. To reach it, you had to find a tiny, single-pixel object called "the dot." It was so small that it was nearly invisible on a CRT television. You had to carry that dot through a specific wall in a specific location — and if you did it right, a passage appeared.

Inside that passage was a room with flashing rainbow colors and three words on the screen:

"Created by Warren Robinett."

When Atari found out, they were furious. They called it unauthorized code. They called it a hack. They demanded it be removed. But by the time they found it, the cartridges were already manufactured and on shelves across America.

So they waited for the complaints to come in.

They never came. What came instead was obsession.

Players started whispering about it. Word spread through schoolyards and arcades. People started hunting for it. Finding the hidden room became a rite of passage. The game sold more because of the mystery, not in spite of it.

Atari realized they had stumbled onto something. They pivoted completely — not only did they stop trying to remove Easter eggs, they encouraged developers to hide secrets in their games.

That one act of rebellion by a single frustrated developer gave birth to the entire concept of the Easter egg in software. Every hidden message, every secret level, every "you found it" moment you've ever experienced in a game, an app, or a website traces its origin back to Warren Robinett and a tiny invisible dot on a brown Atari cartridge.

🏎️ 3. Bowie Knife99 — The AI That Became a Legend in Forza Horizon 6

This one is happening right now. And it might be the wildest of all three.

Forza Horizon 6 launched in May 2026, set in Japan — mountain passes, neon-lit Tokyo streets, touge battles through the countryside. Stunning game. But within literally one day of release, something unexpected was going viral.

Not a feature. Not a trailer. An AI driver named bowie knife99.

Here's what you need to understand about how Forza Horizon 6 works. The game uses a technology called Drivatar — a machine learning system that's been part of the Forza series for years. The way it works is actually fascinating. Every time you play, the Drivatar system is watching. It records your braking points, your acceleration timing, how you take corners, how aggressive you are at overtaking. It builds a digital model of your driving style. Then it takes that model and releases it into other players' games as an AI opponent — even when you're offline.

So the AI opponents in Forza aren't generic bots. They're digital copies of real people. Your friends show up in your races. Strangers show up in your races. And in theory, it creates a living, breathing grid that feels more human than any scripted AI.

In theory.

What nobody planned for was bowie knife99.

Nobody knows who the real person behind the account is. Their Xbox profile is set to private. But their Drivatar — the AI copy of their driving behavior — has been showing up in races all over the world and doing something that no normal racer does.

It deliberately rams people.

Not by accident. Not as a product of bad cornering. It veers off the racing line specifically to collide with other players. It appears out of nowhere at full speed at corners. It wins races it has no business winning. It sabotages your lead race after race. And then it disappears, only to reappear three turns later, faster than before.

Players started posting clips. Then more clips. Then hundreds of clips. Reddit, TikTok, Twitter — all flooded with "bowie knife99 just ruined my race." The memes exploded. Someone compared it to the legendary Wii Sports Mii named Matt that nobody could beat. The official Xbox UK account tweeted "Happy Bank Holiday Monday to everyone except bowie knife99." Walmart banned the username in-store displays.

This became the biggest gaming meme of 2026, and it wasn't written by a developer. It wasn't planned. It wasn't even a bug in the traditional sense.

What happened was that the Drivatar system worked exactly as designed — it learned from a real player who drives like an absolute maniac, built a perfect digital replica of that chaos, and then unleashed it on every Forza player on the planet simultaneously. Because in the early days of the game, the pool of Drivatars was small and everyone was racing the same ones. So bowie knife99 was everywhere, all at once.

Playground Games said they were "working on balancing Drivatars." But by then, nobody wanted it fixed.

The chaos became the culture. The "bug" became the personality of the entire game.

💡 Why I'm telling you this

I've been thinking about this a lot since that 3 AM debugging session.

All three of these stories involve someone doing something that wasn't supposed to happen — a shortcut that spread too far, a hidden room that wasn't meant to ship, an AI that learned the wrong lesson from the right player.

And all three of them ended up changing everything.

The next time you're staring at weird behavior in your code and thinking "this is just broken" — maybe slow down for a second. Ask yourself what's actually happening. Because sometimes what looks like a failure is just a design choice that hasn't been discovered yet.

What's the most unexpected "bug" you've ever found in something you were working on? Drop it in the comments — genuinely curious.

Engineering Krishi-Route: A Real-Time Geospatial Logistics Engine (MERN + Leaflet)

SRIHARI P V — Wed, 03 Jun 2026 05:30:00 +0000

Logistics is the silent killer of agricultural profit. In India, a farmer's margin is often destroyed not by the harvest itself, but by the sheer cost of transporting a partial truckload of crops to the market.

I wanted to solve this at the architectural level. I didn't just want to build another standard CRUD app; I needed a real-time, geospatial routing engine that could dynamically pool cargo from multiple nearby farmers to share transport costs.

Enter Krishi-Route.

⚙️ The Architecture

To build a high-performance routing system, I needed a stack that could handle rapid geospatial queries and render them instantly on the client side without locking up the main thread.

Frontend: React + Leaflet.js for interactive, lightweight map rendering, bypassing the heavy overhead of commercial mapping APIs.
Backend: Node.js & Express to handle the asynchronous routing logic and user authentication protocols (JWT).
Database: MongoDB with Geospatial Indexing (2dsphere) to calculate proximity boundaries at the database layer.

🧠 The Core Challenge: Geospatial Pooling

The hardest part of this build wasn't rendering the map—it was the math behind the matching algorithm.

If Farmer A needs to ship 200kg of tomatoes, and Farmer B (15km away) needs to ship 300kg of onions to the same market, the system needs to recognize they can share a 500kg capacity truck.

Instead of relying solely on expensive external routing APIs for every single coordinate check, I leveraged MongoDB's native geospatial aggregation pipelines combined with custom distance calculations to filter the nearest compatible cargo nodes before calculating the final route.

The Aggregation Payload

Here is a look under the hood at how the backend handles the proximity matching:

// Step 1: Define vehicle constraints
const capacity = VEHICLE_CAPACITY[vehicleType] || 30;

// Step 2: Database Query - Find active, compatible transit nodes
const existingPlans = await TravelPlan.find({
    travelDate,
    vehicleType,
    status: 'planned',
    farmerId: { $ne: req.user._id } // Exclude the requesting farmer
})
    .populate('farmerId', 'name farmerProfile')
    .populate('mandiId', 'name');

// Step 3: Proximity & Capacity Filtering
const poolingMatches = existingPlans.filter(p => {
    // Check if the combined load fits the exact vehicle capacity constraint
    const fits = (p.quantity + Number(quantity)) <= capacity;
    return fits && p.mandiId; // Return only valid, destination-bound nodes
});

📈 The Output: Profit Routing

By calculating the shared transport cost dynamically, Krishi-Route flips the script. Instead of eating the cost of an empty truck, farmers get an instant projection of the money they will save when they join a shared cargo pool.

🚀 Final Thoughts

Building Krishi-Route pushed me out of standard web development and into the realm of system architecture and geographic mapping. It forced me to think about database speeds, mathematical formulas like Haversine, and how code translates into physical, real-world logistics.
Explore the architecture here:

💻 GitHub Repository: https://github.com/LORDMOSTER/Krishi-Route