DEV Community: Bhavnish

☕ Hot Tea & Crispy Samosa – Interactive Comfort Food Experience

Bhavnish — Sun, 09 Aug 2026 09:02:15 +0000

☕ Overview

An interactive frontend web experience showcasing the ultimate Indian comfort food combination: hot tea (chai) and a crispy samosa with spicy chutneys!

🌟 Features

☕ Interactive Tea Cup: Take a sip to smoothly lower the liquid level with realistic tilt animations.
🥟 3D Vector Samosa: Dip the samosa into green mint & red tamarind chutneys with smooth 3D motion.
🌶️ Dynamic Chutney Dip Effect: Real-time chutney stain appears on the samosa tip when dipped!
🫖 Refill System: Easily refill the tea cup and reset the samosa with one click.
💨 Vapor/Steam Animations: Custom CSS floating steam effect over hot tea and fresh samosa.

🛠️ Tech Stack

HTML5
Pure CSS3 (3D Transforms, Custom Keyframe Animations, Radial Gradients, Inline SVGs)
Vanilla JavaScript

🔗 Live Demo & CodePen

Direct Link: View CodePen Demo

Possessed by Production: The Ghost Execution That Ran Code Nobody Ever Wrote

Bhavnish — Sat, 08 Aug 2026 06:29:04 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

I deleted a single console.log statement from our payment worker, merged the PR, and went to grab tea. Ten minutes later, PagerDuty was screaming.

Memory usage on our background pods spiked to 99.8%. Outgoing webhooks failed with orphan closure errors, and Postgres rows started getting overwritten with payloads from different users.

I panicked and reverted the commit. I put the console.log back.

And just like magic... the errors stopped. Memory dropped back to 180MB. Everything went green.

Reverting a one-line PR and having production fix itself is terrifying. It means your architecture isn't actually stable—it's riding on accidental side-effects.

14 Hours in DevTools: What Happened?

If adding console.log fixes your backend, you are relying on luck and OS buffer timing.

I spent 14 hours taking heap snapshots (node --inspect) and diffing memory dumps across V8 garbage collection cycles. Here is what happened under the hood:

The Timing Trap: In Node.js, printing to stdout isn't always instant and non-blocking. That tiny log call introduces microsecond I/O pauses that inadvertently acted as an accidental sync guard.
The Floating Promise: We had a background logging task running inside an un-awaited Promise chain inside our request handler.
V8 Scope Reclamation: When console.log(user.id) was present, V8 retained an explicit reference to user in the parent scope.

When I removed the log, V8 JIT optimizations kicked in. During aggressive Garbage Collection, V8 marked the parent context as dead before the background callback finished writing to Redis. The callback resolved into an invalidated scope context.

The Broken Code

app.post('/api/checkout', async (req, res) => {
  const user = req.user;

  db.saveOrder(req.body).then(async (order) => {
    await telemetry.logTransaction(user.id, order.amount);
  });

  return res.json({ status: "queued" });});

The Fix

import { AsyncLocalStorage } from 'node:async_hooks';

app.post('/api/checkout', async (req, res) => {
  const userId = req.user.id;
  const payload = req.body;

  try {
    const result = await db.transaction(async (trx) => {
      const order = await trx.saveOrder(payload);
      await telemetry.logTransaction(userId, order.amount);
      return order;
    });

    return res.json({ status: "processed", orderId: result.id });
  } catch (err) {
    logger.error('Checkout pipeline failed', { err, userId });
    return res.status(500).json({ error: "Transaction failed" });
  }
});

What This Incident Taught Me

Accidental synchronization is real: If removing a log breaks your service, you have a race condition.

Respect V8 internals: JIT compilers are aggressive. Don't leave floating background callbacks hoping scope stays alive.

Always await your promises: Unhandled floating promises will eventually bite you under high concurrency.

The AI Slop Tsunami: Why "10x Coding Speed" Is Ruining Software Engineering

Bhavnish — Fri, 07 Aug 2026 13:21:23 +0000

*Software engineering has a dirty secret: typing speed was never the bottleneck.
*
The real bottleneck has always been thinking, analyzing edge cases, and making sure the architecture actually works.
Today, AI is flooding our codebases with a tsunami of low-quality code. On paper, management celebrates "10x productivity." In reality, we are just shipping unverified slop at record speed.

The Junior Illusion

**
Junior devs buy an AI subscription, type a prompt, copy-paste 1,000 lines of code in 10 seconds, and feel like Senior Engineers.
Without understanding even 1% of the generated logic, they skip the entire learning process.
Writing a prompt isn't engineering. When that code crashes in production six months from now - and the AI fails to fix it - you're completely on your own.

The Managerial Blindspot

**
Non-technical managers love this illusion because they only care about ticket speed. To them, a developer sitting quietly for two hours thinking through a problem looks "slow."
Meanwhile, the junior generating 10 AI PRs a day looks like a genius - until the entire system breaks down.
Seniors are left cleaning up the mess, reviewing massive AI pull requests buried with subtle bugs. After hours of headache, they give up:
_

The biggest threat to production isn't hackers - it's a burned-out Senior Engineer blindly hitting 'Approve PR' at 4:45 PM just to escape Slack notifications.
_

The Death of Debugging Muscle

**
Real engineering muscle is built through struggle.
Failing 50 times, getting frustrated, tracking down a bug, and fixing it manually - that painful process is what actually turns juniors into Senior Engineers.
If you use AI to skip the struggle today, you won't have the brains to debug the system tomorrow. AI is built to speed you up - not to replace your brain.
...
Be honest in the comments: Have you ever hit 'Approve PR' at 4:45 PM just to escape Slack notifications?

The Ghost in the Machine: Why AI Can Write Code, But Fails Miserably at Documenting ‘Institutional Debt’

Bhavnish — Sat, 01 Aug 2026 05:29:25 +0000

Lately, my LinkedIn feed is flooded with posts saying AI is replacing Technical Writers. The logic? “If ChatGPT can code, it can easily write a README file.”

As someone who deals with real codebases, my answer is simple: No, it can’t. People are missing the point of what documentation actually is. AI can understand syntax, but it completely fails at dealing with Institutional Debt.

The Reality of “Jugaad”

Let’s be honest. In the real world, software architecture is rarely perfect. Under tight deadlines, developers don’t write clean code. They deploy quick patches and temporary workarounds — our classic jugaad — just to keep the server alive on a Friday night.

They always say, “I’ll document this next week.” But next week never comes.

This hidden, unwritten knowledge inside a developer’s head is Institutional Debt (or Tribal Knowledge). And this is where AI hits a wall.

AI Knows “What”, Not “Why”

If you feed a messy codebase to an AI, it will happily tell you WHAT the code does. It will describe functions and variables perfectly.
But AI can never tell you WHY that specific workaround was built three years ago.

It doesn’t know about the weird legacy server bug that crashes the API every Sunday.
It doesn’t know the history of past architectural failures that forced the team to use that patch.
If you blindly trust AI to optimize or rewrite that code based on syntax alone, it will break the system. AI lacks the human context of why the chaos exists.

Writers are “Software Detectives”

Technical writing isn’t just about formatting Markdown files or knowing good English.

A great Technical Writer is a detective. Our real job is getting on a call with a tired senior engineer, asking the right questions, and digging out that tribal knowledge before they quit.

When a senior dev leaves, they take a chunk of the company’s undocumented brain with them. AI can’t stop this brain drain. A human writer can.

The Bottom Line

AI writes for machines. Humans document decisions for other humans.

So, next time a tech leader thinks of replacing writers with an AI key to save budget, they should ask themselves: Is your AI ready to take the blame when production crashes because of an undocumented legacy bug?

Probably not.

Fixing One Automation Problem Just Created Ten New Bugs

Bhavnish — Fri, 24 Jul 2026 04:29:58 +0000

TL;DR: Replacing developers with fragile AI web agents sounds great on slides—until a 2px layout change breaks your entire production workflow.

We’ve been hearing a lot of noise lately about how AI agents are going to replace traditional developers. The theory is that these agents can just navigate web interfaces directly, click buttons like a human, and bypass complex backend infrastructure entirely. It sounds incredibly efficient on paper. But when you look at how software actually operates in the real world, this logic falls apart completely.

Let’s look at a simple, everyday scenario to understand the actual reality.

The “Button Color” Problem

Imagine you make a minor layout update to your website. Maybe you change a primary action button’s colour from blue to red, or shift its position slightly to improve user experience.

If a human developer encounters this change, they don’t blink. They instantly understand the context — it’s just a visual tweak. They update the system or integration in minutes, and everything keeps running smoothly.

But if an AI agent is running that exact same workflow? It instantly breaks. AI is fundamentally rigid; it does not possess human intuition. The moment a visual pattern or structural tag shifts unexpectedly, the agent throws a hard error because it is searching for a specific, pre-trained layout.

To fix this, you end up facing a ridiculous paradox: you now have to spend extra engineering hours building a separate, highly specific “AI-friendly UI” just so the machine can understand what changed. You try to solve one automation issue, and you accidentally create ten new infrastructure bugs. AI might be smart, but it completely lacks the situational awareness of a human brain.

The Corporate Trap: Cheap Code is Expensive

Right now, large multinational corporations are rushing into a massive trap. They are obsessed with cutting budgets, downsizing engineering talent, and plugging AI tools directly into their core operations to make things “fast and easy.”

It’s a massive blunder, and here is why:

The Security and Hacking Threat: AI doesn’t create anything genuinely original. It simply repackages and reorganizes code and patterns that already exist on the public internet. If your entire application logic and automation scripts are written by generic models, your system becomes incredibly predictable. In the cybersecurity world, predictability is an absolute nightmare. Hackers can easily map out and exploit these standardized AI patterns, leaving your security compliance and data protection completely vulnerable.

The Illusion of Smartness: Trying to act over-smart by replacing human intuition with automated scripts works fine for surface-level tasks, but it fails miserably under stress. Software maintenance requires a deep understanding of business logic, edge cases, and systemic context — things a machine learning algorithm simply cannot replicate.

The Bottom Line

At the end of the day, AI is a fantastic tool to assist people, but it makes for a terrible master. Leaving critical software and infrastructure decisions entirely to automation is a recipe for disaster. The companies trying to bypass human developers to save a quick buck are going to learn the hard way that short-term savings always lead to massive long-term tech debt. Some jobs belong to humans, and they should stay that way.
What’s your take? Have you faced cases where AI automation actually increased your debugging workload? Let’s debate in the comments! 👇

[Boost]

Bhavnish — Fri, 24 Jul 2026 03:41:59 +0000

Bhavnish

Jul 22

The Aura Game: Why Smart Developers Secretly Let Codebases Burn

#techtalks #career #programming #webdev

2 min read

The Aura Game: Why Smart Developers Secretly Let Codebases Burn

Bhavnish — Wed, 22 Jul 2026 18:55:48 +0000

Every software engineer hides a dark secret in their codebase...

Every software engineer hides a dark secret in their codebase. It’s a ticking time bomb — a bug they spotted days ago but chose completely to ignore. They knew exactly when it would explode, how much money the company would lose, and how much chaos it would cause.

Yet, they left it alone. Why? Because in the modern tech corporate world, writing flawless code is a fast track to getting laid off.

The 3 AM Hero Entry

Picture this: It’s a weekend night. Suddenly, the production server goes down. Slack channels are flooded with panic emojis, managers are sweating bullets, and the CEO is demanding answers. The entire company is facing a massive crisis.

Right on cue, everyone remembers the one developer who can fix this. They call them up like they are summoning a god.

The developer logs in, shares their screen, types a single line of code, and fixes the bug. Instantly, the graphs turn green. The Slack chat explodes with applause. If the developer’s office crush happens to be watching the incident channel, she is completely blown away.

With one single hotfix, the developer hits two targets at once: the system is saved, the crush is impressed, and they achieve legendary status in the office.
But why create the theater in the first place?

The Efficiency Trap: Why Perfect Code Gets You Fired

Here is the unfiltered reality of how corporate management thinks.
If a developer does their job perfectly, the system never breaks. Weeks pass without a single server crash. To a non-technical manager, team leader, or CEO, a perfectly stable system doesn’t look like great engineering — it looks like the developers have no work to do. They start thinking:

Our system is running so smoothly. What are we even paying these engineers for? Let’s just fire them, cut the budget, and use AI to handle the small updates. AI is cheaper anyway.

This is the exact loop that forces smart human engineers to play defensive chess. If you solve the problem silently on a Tuesday afternoon before anyone notices, your value drops to zero. Management forgets you exist.

To survive, developers let the bug breathe. They wait for the problem to catch everyone’s attention and grow into a real threat. Only when the panic hits its peak do they step in to resolve it.

It’s the only way to get your Aura ++ points and force the company to realize your true worth.

The Final Takeaway

The tech world loves to glorify “firefighters” — the heroes who jump into active server fires and save the day. But the industry completely ignores the “fire preventers” — the engineers who write code so clean that a fire never starts in the first place.

So, the next time you see a developer sitting quietly at their desk looking completely free, do not assume they are being lazy or have nothing to do. The truth is, they have probably already completed their work hours ago. They are just waiting for the right moment to deploy their aura.
.
.
.
Have you ever witnessed a '3 AM Hero' entry, or been the quiet fire-preventer whose work went unnoticed? Drop your stories below! 👇

The Archaeology of Git Blame: Why AI Doesn’t Understand the Panic Behind Your Code

Bhavnish — Fri, 10 Jul 2026 18:44:38 +0000

Imagine you are digging through a legacy codebase, and you stumble upon a comment like this:
**Please do not touch this line. Everything breaks if you delete it. Just leave it alone**
If you are a human developer, you know exactly what to do. You don’t try to be a hero. You don’t ask questions. You just back away slowly and let it run, because you respect the unwritten rules of software engineering.

But what happens when you hand that same file over to an AI coding tool?

The AI scans the syntax, completely ignores the human warning, and thinks: “This block is highly inefficient. Let me refactor it to match clean-code textbook standards.”

And just like that, it’s a Sunday night, the production server is down, data is messed up, and you’re stuck fixing a nightmare.

Why does this happen? Because AI understands code syntax, but it fundamentally fails at understanding human trauma.

The 3 AM Reality Check

AI tools are great at writing clean logic in a vacuum. But real-world software development doesn’t happen in a perfect lab. It happens under tight deadlines, changing business requirements, and intense pressure.

AI can never comprehend the context of a developer sitting at their desk at 3 AM, surviving on cheap coffee, desperately trying to deploy a hotfix before the client notices a bug. That weird, seemingly useless line of code wasn’t written by mistake — it was a survival tactic.

When a seasoned developer leaves a weird comment, they are passing down tribal knowledge. They are telling you:

I spent three days fighting this system, and this hack is the only thing keeping us afloat.

Code is for Machines, Context is for Humans

Relying blindly on AI to rewrite or clean up your entire codebase is a massive trap. AI looks at code as math. It doesn’t know about the developer who left the company two years ago, or the weird legacy database integration that nobody wants to touch.

AI can write code for machines to execute, but it cannot document the why behind human decisions.

The next time you run a git blame and see a desperate comment, remember that a human went through hell to write that. AI might be the future of syntax, but human context is what actually keeps the software running. Don't let a clean-code algorithm delete the human history that holds your app together.

The Placebo Bug: Why Smart Developers Leave Mistakes in Their Code on Purpose

Bhavnish — Wed, 08 Jul 2026 18:24:13 +0000

A few days ago, I was talking to a junior developer who was literally sweating bullets. He had just pushed a feature for a staging website that barely gets 500 users a month.

But looking at his senior developer’s reaction? You’d think the guy was managing the infrastructure for Amazon’s Prime Day Sale.

“Scale check kiya? What if 10,000 users hit this exact API at 3 AM? Refactor this logic.”

The code was perfectly fine for their current requirement. But the senior dev had to find a flaw to justify his hierarchy. This is where the tragedy of modern software engineering begins, and a brilliant, toxic survival hack takes over: The Placebo Bug.

What is a Placebo Bug? (The Strategic Distraction)

When experienced developers realize that their managers or seniors have a habit of “kami nikalna” (finding faults just for the sake of it), they stop giving them perfect code.

Instead, they intentionally leave a very small, harmless, and obvious mistake in the front-end or the script.

Maybe an unaligned button.

Maybe a funny typo in an error message (like writing “Succesfully” instead of “Successfully”).

Maybe a massive padding that makes the UI look slightly weird.

When the senior reviews the code, their eyes immediately light up. “Arey! Look at this alignment. Everything else is fine, but fix this button first.”

The junior says, “Sorry, my bad. Fixing it right away.”

Two minutes later, a new commit is pushed. The senior feels proud that they added value, the junior’s core complex architecture passes without unnecessary refactoring, and everyone goes home happy.

It’s not good engineering; it’s human management.

This is actually a very old trick in the tech world, famously known as “The Corporate Duck” story.

Years ago, a game designer noticed that his manager always forced changes on every project just to prove he was the boss. So, the designer tried a hack: he put a totally random, funny Duck on the main character’s head. The manager reviewed it and said, “Everything looks perfect, just remove that duck.” The duck was deleted, and the actual important work was saved without any annoying changes.

Today, developers do the exact same thing to survive:

The CSS Bait: Changing a button’s padding from 16px to 30px on purpose, just so the senior can say, "Hey, fix the spacing."

The Obvious Typo: Writing “Succesful” instead of “Successful” in a login alert so they have an easy mistake to catch.

The Dark Side: Why This Culture is Driving Developers to Insecure AI

While the Placebo Bug sounds like a funny corporate hack, the reality behind it is quite dark.

When seniors create an atmosphere of fear instead of mentorship, new developers stop experimenting. When a fresher is constantly grilled for minor things, they panic. Out of fear, they do the worst thing possible: They start relying blindly on AI tools.

Whenever an error comes, instead of reading the documentation or understanding the root cause, they copy the code, throw it into an AI tool, and say, “Please make this perfect.”

The AI looks at the internet data, patches something together, and gives a clean-looking solution. The code runs on staging, the senior approves it, and the ticket is closed.

But here is the catch: AI gives you code that works, not code that is secure.

Months later, when that same code hits production, unexpected errors start popping up. Security loopholes appear, data leaks happen, or the system gets vulnerable to hacks. Why? Because the code was generated by a tool that patches historical data, handled by a fresher who didn’t understand it, and approved by a senior who was too busy looking at margins and paddings.

AI tools are great at giving you quick solutions, but they don’t understand corporate anxiety. AI will give you code that passes the basic test, but it won’t care if that code has hidden security flaws.

When we scare freshers, we don’t make them better engineers — we just teach them how to copy-paste faster. And that is how companies end up with broken, insecure systems.

We Need to Fix the Bond, Not Just the Code

If a fresher writes code for the first time, seniors need to understand their mental state. Instead of gatekeeping and showing authority, they need to appreciate the effort and guide them toward the next steps.

When you over-criticize a beginner, you don’t make them a better developer — you just make them better at hiding their mistakes.

The bond and understanding between a senior and a junior developer need to be solid. If a junior feels safe enough to say, “Hey, I don’t know how this scales, can you help me?” the company wins. But if the junior is forced to play mind games like leaving “Placebo Bugs” or copy-pasting unverified AI code just to survive the review, the tech stack is a ticking time bomb.

Stop treating staging websites like NASA rocket launches. Build trust, not just features.

Why AI Can Code, But Still Struggles to Clean a Messy Room (The Moravec’s Paradox)

Bhavnish — Tue, 07 Jul 2026 06:21:24 +0000

Imagine an AI that sits inside a computer and solves the world’s toughest math equations or writes complex code in seconds. Sounds superhuman, right? But now, imagine putting that same AI inside a robot and asking it to do something simple: “Hey, can you clean up my messy bedroom?” Surprisingly, the robot’s system would probably crash. A task that a 5-year-old kid can do effortlessly becomes an impossible mission for the world’s most advanced artificial intelligence. Why is that?

In science, this mind-bending reality is called Moravec’s Paradox. It simply means that things that are hard for humans (like playing chess or doing calculus) are incredibly easy for AI. But things that are completely natural to us (like looking around, walking, or picking up a shirt) are the hardest things for a machine to learn.

The Shirt Folding Test vs. The Local Barber

To understand this better, let’s look at two simple examples:

1.The Shirt Test: If you tell an AI to fold a soft shirt, it gets confused. Why? Because fabric changes shape constantly with every touch. A human kid uses their eyes and hands to balance the physics of the cloth instantly. For a robot, every single fold requires billions of mathematical calculations.

2.The Barber Challenge: Think about getting a haircut. An AI might have a double-degree in computer science, but if you give it a pair of scissors, it will probably mess up. It doesn’t understand the unique texture of human hair or how to navigate the shape of a head. Meanwhile, a local barber does it flawlessly and with style every single day because of experience and human touch.

Conclusion: Why Humans Will Always Be King

Lately, everyone is terrified that AI is going to steal all human jobs and leave us with nothing to do. But this paradox proves that AI is just a tool. It is built to help us socially connect and make our software tasks easier.

At the end of the day, the human mind is always king because humans created AI in the first place. A machine can never truly outsmart the human brain. The real future isn’t about replacing humans; it’s about learning how to balance our own intelligence with AI tools. When it comes to the real world — both physically and mentally — humans will always come first.