DEV Community: Gaurav Kumar Singh

From Junior to Staff: How to Build a Safe Team Culture as an Engineerr

Gaurav Kumar Singh — Sun, 04 Oct 2026 04:51:01 +0000

When people talk about "psychological safety" on dev teams, it usually sounds like corporate HR talk or something managers are supposed to fix. But after 10+ years in the industry, I can tell you this: managers only write the policies. Individual engineers build the actual culture every day in PR comments, Teams messages, design reviews, and live production incidents.

Whether you're a junior dev shipping your first PR or a Staff engineer designing core systems, you don't need a manager title to make your team a safe, high-performing place to work. Here is how you can build that culture from the ground up.

1. Get Comfortable Saying "I Don't Know"

Tech has a massive imposter syndrome problem. Juniors feel like they have to know everything, while seniors feel forced to pretend they never make mistakes. The result? People hide bugs, guess instead of asking, and avoid taking on risky tasks.

The Power of Senior Ignorance

When a senior engineer openly says "I don't know" or "Can someone walk me through this?", the entire vibe in the room changes. It signals to everyone else that it's okay to be human.

In Teams Chat: Don't just nod along in public channels. Ask openly: "I'm not familiar with how our auth middleware rotates tokens here : can someone drop a link to the docs or give a quick walkthrough?"
In Code Reviews: Be honest when something isn't your domain: "I haven't touched this database driver before, so I'm focusing my review on the business logic rather than the connection pool logic."
When You Break Stuff: Own your mistakes casually: "Staging build is down because I forgot to run migrations locally. My bad fixing it now."

When you normalized learning in public, you make it safe for others to ask questions early before a small confusion turns into a production outage.

2. Ask Questions That Don't Put People on the Defensive

The way you word PR feedback or design critiques directly impacts whether a teammate collaborates with you or puts up a wall. Aggressive questions trigger defensiveness; curious questions lead to real problem-solving.

Reframing Your Comments

Small adjustments to your tone can turn a harsh review into a productive discussion:

High-Tension Phrasing	High-Safety / Curious Phrasing
"Why did you use a loop here instead of Map?"	"Help me understand the trade-offs of using a loop vs. a Map here."
"This design won't scale."	"What happens to this queue if traffic spikes 10x during a big sale?"
"Why didn't you follow the style guide?"	"Looks like the linter missed this formatting issue—should we tweak the linter config or leave this as an exception?"

Quick Tips for Better Framing:

Focus on the code, not the person: Ask "How does this function handle null values?" instead of "Why didn't you handle nulls here?"
Assume your peer is competent: Start with the assumption that they had a good reason for their approach based on the context they had.
Ask for feedback on your own ideas: End design docs or PR descriptions with open prompts like "Where do you think this design breaks?" or "What edge cases am I missing?"

3. Have Your Teammates' Backs When Things Go Wrong

Team culture isn't tested when everything is quiet—it's tested during Severity 1 outages or intense architecture reviews. As a peer, you have massive power to de-escalate high-stress moments.

Scenario A: The Live Outage

During a Sev-1 incident, pressure is high and people panic—especially if they think their code caused it.

Kill the blame game instantly: If someone says "I think my PR broke prod," step in: "Don't worry about root cause right now. We fix the issue first, figure out why later. Let's get a rollback done."
Pair up: Don't leave one engineer struggling alone on an incident call while everyone watches. Jump in: "I'll dig through the logs while you check the database."

Scenario B: Harsh Design Reviews

Design reviews can quickly feel like an interrogation if multiple seniors gang up on one flaw.

Redirect aggressive feedback: If someone is grilling a presenter, jump in: "That's a fair point about DB locks. Let me write that down as an item to investigate so we can let them finish the rest of the proposal."
Include quieter voices: If someone gets talked over, bring them back: "I think He/She was about to make a point about the API contract"

Summary Checklist

Building a good engineering culture doesn't require a title change. Start with these three daily habits:

Be open about what you don't know. Normalize learning out loud.
Focus on trade-offs and curiosity in PRs. Trade "Why did you..." for "Help me understand..."
Protect your peers during stress. Focus on fixing prod over placing blame, and keep design reviews constructive.

Culture comes down to everyday dev-to-dev interactions. Lead by example from where you sit today, and you'll naturally grow into the kind of leader engineers actually want to work with.

The Rise of Automated API Abuse

Gaurav Kumar Singh — Wed, 16 Sep 2026 13:59:09 +0000

APIs help apps talk to each other. Websites, mobile apps, payment systems, login pages, and many online tools use APIs every day.

But attackers also target APIs. Today, automation and AI make this easier and faster.

What Is Automated API Abuse?

Automated API abuse happens when bots or scripts misuse an API.

Instead of a real person using an app slowly, a bot sends many requests very quickly.

For example, attackers may use bots to try many passwords, create fake accounts, scrape data, test stolen cards, abuse discounts, send spam, or search for weak API endpoints.

How AI Makes It Worse

AI helps people build software faster. This is useful for developers, but attackers can also use it.

Attackers can use AI to write attack scripts, understand API documents, find weak endpoints, change attacks quickly, and create many request types.

This means even less-skilled attackers can build stronger attacks.

Bots Move at Machine Speed

Humans are slow. Bots are fast.

A real user may send a few requests in a minute. A bot can send thousands.

Bots can also use many IP addresses, accounts, and devices. This makes the attack harder to spot.

Why Rate Limiting Is Not Enough

Rate limiting controls how many requests a user or IP address can send.

For example, an API may allow only 100 requests per minute.

This helps, but attackers can avoid simple limits by using many IP addresses, many accounts, different headers, and different locations. They can also slow down the attack just enough to stay below the limit.

Simple rate limits often miss modern API abuse.

Why Static WAFs Struggle

A Web Application Firewall, or WAF, blocks known bad traffic.

Older WAFs often use fixed rules. They look for known attack patterns.

But API abuse can look normal. The request may use the correct URL, format, and login token.

The problem is not always the request itself. The problem is the behavior.

A static WAF may miss abuse when requests look valid, attackers change their patterns, real accounts are used, traffic comes from many places, or the abuse happens slowly over time.

Why APIs Are Easy Targets

Many apps have lots of APIs. Some are public, some are private, and some are forgotten.

APIs become risky when they have weak authentication, share too much data, trust user input too much, are not monitored, or are not updated.

Attackers use automation to test these weak points quickly.

Business Impact

Automated API abuse can cause serious damage.

It can lead to account takeover, data leaks, fraud, higher server costs, slow services, poor customer experience, and loss of trust.

Better Protection

Companies need more than basic rate limits and static WAF rules.

Better protection includes bot detection, behavior monitoring, strong login security, API discovery, anomaly detection, adaptive rate limits, and good logging and alerts.

Security teams should ask:

Does this behavior look normal for a real user?

Automated API abuse is growing because APIs are everywhere and AI makes automation easier.

Traditional rate limiting and static WAFs still help, but they are not enough alone.

Modern API security must watch behavior, detect bots, and react quickly before abuse causes damage.

The Great AI Mirage: Are We Buying Innovation or Just Badges?

Gaurav Kumar Singh — Sat, 22 Aug 2026 04:56:01 +0000

Everywhere you look, the narrative is the same: innovation begins and ends with AI/ML. Companies are desperate. They are pouring millions of dollars into integrations—often just to plug in a basic AI chatbot—simply to stamp an "AI-Powered" badge on their landing pages.

But if we strip away the marketing hype and look at the actual reality, a troubling question emerges: Where is the world-changing technology built by AI?

Outside of tech demos, the everyday consumer experience hasn't fundamentally shifted. Instead, the AI landscape currently looks like a modern gold rush, but with a twist:

The Only People Making Money Are Selling Shovels: Except for a select few selling hardware, infrastructure, or generative AI tokens, most companies are bleeding cash on AI.
The "Badge" Economy: Massive capital is being spent on optics and FOMO (Fear Of Missing Out) rather than tangible, revolutionary utility.
Missing Breakthroughs: We see incremental software updates, but we haven't seen a completely new, world-changing technology emerge that solves fundamental human problems better than traditional tech.

Are we investing in the next internet, or are we just funding the most expensive marketing campaign in tech history?

It's time to shift the conversation from how much we are spending on AI to what value it is actually delivering to the end-user.

🗣️ To my network of founders, developers, and tech leaders:
Are you seeing genuine, foundational innovation from AI in your sectors, or is the pressure to get the "AI badge" overshadowing real product value? Let's discuss in the comments.

An Evening in the Monsoon Season - Rain, Tea, and Samosas

Gaurav Kumar Singh — Sat, 01 Aug 2026 04:42:52 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art

Inspiration

Nothing says comfort like a piping hot cup of cutting chai on a rainy monsoon afternoon in India. Listening to the pitter-patter of raindrops against the window while soft, slow music plays in the background, paired with a plate of crisp pakodas, sizzling samosas and a hot cup of tea (adrak wali chai (Ginger Tea ) —it’s pure bliss.

I wanted to capture that nostalgic, warm atmospheric vibe entirely using HTML and CSS. From the rich gradient of brewed tea and gentle ripples in the cup to the soft wisps of steam rising against the rainy backdrop, this is a tribute to India's favorite monsoon ritual!

Demo

Codepen:

codepen.io

Journey

Building this piece was all about mastering fine visual details and CSS animations:

Layering & Shapes: Creating the teacup, saucer, and interior liquid surface using carefully placed border-radius, box-shadow, and radial-gradient properties to achieve realistic depth and lighting.

Steam Wisps: I created subtle steam animation keyframes (@keyframes steamRise) using soft radial gradients and CSS filter: blur() to give the steam a naturally diffused look as it dissipates into the air.

Surface Ripples: Adding delicate, looping CSS animations to simulate gentle ripples on the tea's surface.

What I Learned & What's Next

Fine-tuning the animation timing and keyframe delays was key to making the steam and ripples feel natural rather than mechanical. Next, I’d love to add interactive elements—like hover effects that react to cursor movement or toggleable light/dark themes!

Building this project evolved from a pure CSS art experiment into a full-fledged React application! Here are a few key insights from the process:

Fine-Tuning Animations: Adjusting animation timing and keyframe delays was critical for making the rising steam and subtle surface ripples feel natural rather than mechanical.
Audio Integration & State Management: Implementing ambient sound effects (like soothing rain and background tunes) required managing React state effectively to ensure smooth audio playback and control toggles.
User Customization: Adding a dedicated settings panel gave users control over sound, themes, and interactive elements to create their ideal cozy environment.

🔗 Live Links & Project Code

🚀 Live Demo: Chai & Samosa Monsoon Experience
📂 GitHub Repository: gaurav101/chai-samosa-monsoon

The Secret Debugging Tool You're Not Using

Gaurav Kumar Singh — Sun, 26 Jul 2026 06:22:32 +0000

We’ve all been there: It’s 11 PM, the bug is still alive, your tests are failing, and you’re about to throw your laptop out the window.

We usually view debugging as a pure logic problem: stack traces, breakpoints, and logs. But Emotional Intelligence (EQ) is often the real reason you fix a bug in 20 minutes instead of 3 hours.

Here is how EQ actually applies to your daily workflow:

1. Spotting Tunnel Vision Before It Wastes Your Time

Frustration causes confirmation bias. You start forcing your initial hypothesis ("It MUST be the cache!") even when the logs say otherwise.

EQ Move: Recognize physical signs like tight shoulders or rage-typing. Take a 5-minute bio-break. Stepping away resets your mental stack, which is usually faster than another hour of blind grinding.

2. Separating `code.hasBug()` from `dev.isBad()`

A stubborn bug easily triggers imposter syndrome: "A senior dev would have solved this already." That inner voice just adds noise to your debugging stack.

EQ Move: Reframe the problem objectively:
- ❌ "I don't know what I'm doing." (Emotion)
- ✅ "This async function isn't returning the expected payload." (Fact)

Debug the code, not your self-worth.

3. Handling Spicy Bug Reports

A ticket comes in: "This is completely broken, who let this ship?!" Your gut reaction might be to get defensive or send a passive-aggressive response.

EQ Move: Filter out the noise. Translate panic or bad phrasing into actionable facts. Reply calmly to de-escalate, pull the missing repro steps, and ship the fix without unnecessary Slack drama.

4. Rubber Ducking and Asking for Help (Ego-Free)

How many times have you fixed a bug just by explaining it out loud to a peer? Sitting in silent frustration for hours doesn't make you a hero; it just delays the feature.

EQ Move: Treat asking for help as an optimization tactic. Send a concise message with context: > "Hey, expecting X, getting Y. Already tried A and B. Got 5 mins to glance at this snippet?"

5. Staying Cool During Prod Outages

Panicked devs make bad hotfixes and type typos straight into production consoles.

EQ Move: The calmest dev in the room becomes the effective incident commander. Slow down, verify facts before firing off commands, and keep communication clear. Clear heads drop downtime.

TL;DR

Debugging isn't just Dev vs. Code—it’s Dev vs. Emotional Reactivity. The fastest problem solvers aren't always the ones who memorized the entire language spec. They’re the ones who catch their frustration early, communicate clearly under pressure, and keep their head clear.

Next time you get stuck, ask yourself: "Am I debugging the system, or am I debugging my mood?" Fix the mood first, and the logic gets a lot easier to trace.

The Most Critical Architecture in Tech: Psychological Safety

Gaurav Kumar Singh — Fri, 17 Jul 2026 12:19:11 +0000

Every engineer knows that sudden, cold dread when a production build breaks. But what happens after the break tells you everything about your engineering culture. If the first instinct is to find someone to blame, your team has a critical bug in its foundation — and no amount of CI/CD tooling will patch it.

Psychological safety isn't an HR buzzword. It's a technical property of the system, as real as uptime or test coverage. It's the human try/catch block that keeps a team resilient under failure. Strip it out, and innovation stalls, code quality degrades, and tech debt quietly compounds until the whole thing collapses under its own weight.

Why Psychological Safety Is a Codebase Concern

When engineers are afraid of looking incompetent, they don't just feel bad — they ship worse software. That fear propagates directly into the codebase in a few predictable ways:

Silent outages, slow recovery. When people fear reprimand, they hide mistakes, delay escalating bugs, or slap a quick patch over the symptom instead of digging into the root cause. Teams with high safety run blameless postmortems that ask how the system failed, never who failed it — and they recover faster because of it.
Tech debt that never gets paid down. When failure isn't safe, people stop taking risks. Nobody volunteers to refactor the legacy monolith if a resulting bug could show up in their performance review. Teams default to "fragile but predictable" over "robust but risky," and the debt just piles up.
Pull requests as combat instead of collaboration. In low-safety environments, code review stops being a shared search for edge cases and turns into something to survive.

The data behind it: When Google ran Project Aristotle to find out what made their best teams tick, they looked at everything — educational background, personality types, seniority mix. The answer had almost nothing to do with who was on the team and everything to do with how they treated each other. Psychological safety came out as the single strongest predictor of team performance, ahead of every other factor they measured.

Anti-Patterns That Quietly Rot Team Culture

Just like code smells, these are easy to miss day-to-day but corrosive over time:

The brilliant jerk. A highly skilled developer who belittles others in reviews or design discussions. Tolerating this — even because they "ship fast" — tells the rest of the team that output matters more than how people are treated.
Weaponized nit: comments. Nitpicks used to assert dominance in a PR rather than to actually improve the code. The tell is volume and tone: constructive nitpicking is occasional and specific; weaponized nitpicking is constant and personal.
Treating bugs as personal failure. An unhandled exception in prod is a gap in your test suite, not a character flaw in whoever wrote the line. Teams that internalize this stop hiding bugs and start writing tests for them.

Engineering a Safer Culture

Safety doesn't happen by accident — it's a design pattern, and it takes the same intentionality as any other piece of architecture.

1. Model vulnerability from the top

Leads and staff engineers need to actually say "I don't know," "I was wrong," and "I need help here" — out loud, in public channels, not just in 1:1s. When a senior engineer tells the story of the time they dropped a production database, it gives everyone else permission to be human.

2. Critique the code, not the person

This is the single highest-leverage habit for review culture, and it's a small rewrite:

- Your code is inefficient here.
+ Let's look at the time complexity of this loop — if the dataset
+ grows, we might hit a bottleneck. What do you think about a Map
+ instead of nested iteration?

Same technical point, zero identity attached to it. The reviewer isn't softening the feedback — the feedback is exactly as direct. It's just aimed at the loop instead of the person who wrote it.

3. Kill the async anxiety loop

In remote and hybrid teams, a context-free message is its own kind of memory leak — it sits in someone's head consuming cycles until it's resolved.

- We need to talk about your PR.
+ Hey, I left a couple of architecture questions on your PR —
+ no rush, let's chat about options at tomorrow's sync 👍

The fix costs one extra sentence. The anxiety it prevents can cost an afternoon of someone's focus.

The Bottom Line

We pour money into high availability, automated pipelines, and fault-tolerant infrastructure. But the most critical system any team runs is the human one underneath all of it. If your developers don't feel safe to fail, your software will eventually fail the same way — quietly, and in production.

Psychological safety isn't the soft stuff. It's the infrastructure everything else runs on.

How to Thrive (Not Just Survive) as a Developer in the Age of AI

Gaurav Kumar Singh — Sat, 11 Jul 2026 12:54:36 +0000

The narrative around Artificial Intelligence and software engineering has shifted dramatically. We are no longer asking if AI will change development, but rather how we change with it.

If your value as a developer is tied solely to how fast you can churn out boilerplate code, write standard API endpoints, or memorize syntax, the landscape is becoming challenging. AI can do those things in seconds. However, this isn't a death sentence for the engineering career—it is an evolution. The industry is moving away from pure "code generation" and shifting toward system architecture, integration, and governance.

To remain indispensable, you need to know exactly where to direct your energy and what pitfalls to avoid.

Where to Focus Your Energy

To stay relevant, you must position yourself in the areas where AI struggles: high-level abstraction, complex contextual reasoning, and human leadership.

1. System Design and Enterprise Architecture

AI is excellent at writing isolated functions, but it struggles with massive, interconnected systems. Focus on how components interact at scale. Understanding how to slice a monolithic application into resilient microservices, orchestrate microfrontends, or design cloud-native solutions is where the high-value work lies.

2. Code Governance and Quality Assurance

With AI generating code at unprecedented speeds, codebases are expanding faster than ever. The world doesn't just need people who can create code; it needs gatekeepers who can validate it. Your role will increasingly focus on setting quality standards, establishing robust CI/CD pipelines, and ensuring that AI-generated code adheres to strict security, compliance, and performance metrics.

3. Mentorship and Team Leadership

The influx of AI tools means junior engineers can produce code much earlier in their careers, but they often lack the foundational experience to spot subtle architectural flaws or security vulnerabilities. Senior developers must step up as leaders, guiding less experienced teammates on why certain architectural patterns matter, preventing burnout, and maintaining engineering discipline within the team.

4. Deep Systems and Performance Optimization

While AI can write functional code, it often writes resource-heavy or unoptimized code. Specializing in low-level systems programming, memory safety, and fine-tuning performance-critical applications gives you a massive edge. Knowing how to wring every ounce of efficiency out of a system remains a highly prized human skill.

What to Take Care of (The Pitfalls to Avoid)

Staying relevant isn't just about learning new skills—it's also about avoiding the bad habits that AI tools can induce.

The "Copilot Crutch" Warning: Relying too heavily on AI tools for basic problem-solving can cause your foundational engineering muscles to atrophy. If you don't understand the underlying logic of the code your AI assistant suggests, you cannot safely maintain or debug it when things break.

Watch out for Architectural Drift: AI generates code based on local context (the file you are working on). It doesn't inherently understand your entire organization's long-term technical roadmap or governance model. Left unchecked, AI-assisted development can lead to a bloated, fragmented codebase.
Don't skip the "Why": Always question AI suggestions. If a Large Language Model gives you an elegant solution, take a moment to understand why it works before accepting the pull request.
Guard your Domain Knowledge: Technical skills matter, but understanding the business logic and user experience is what converts code into a successful product. AI doesn't know your customers; you do.

The Evolution of the Developer Role

To visualize this shift, look at how the daily responsibilities of a resilient software engineer are changing:

Traditional Developer Focus	AI-Era Developer Focus
Writing boilerplate, configurations, and repetitive unit tests.	Designing system boundaries, security models, and data flows.
Memorizing language syntax and API frameworks.	Evaluating and integrating complex, multi-system dependencies.
Fixing syntax errors and basic debugging.	Auditing AI-generated code for hidden vulnerabilities and tech debt.
Functioning as an isolated individual contributor.	Acting as a technical leader, mentor, and strategic translator for business needs.

Moving Forward

The goal is to stop competing with AI at what it does best (speed and volume) and start leveraging it to do what humans do best (strategy, empathy, and holistic design). By shifting your mindset from being a "code writer" to a "software architect and custodian," you ensure that your skills remain not just relevant, but entirely essential to the future of technology.

Sick of App Store Ads? So I Built My Daughter Her Own Drawing PWA

Gaurav Kumar Singh — Thu, 02 Jul 2026 14:14:45 +0000

"Daddy, another ad?"

If you have young kids who use an iPad, you may know this problem.

Last week, my daughter was using a free drawing app. She was happy and busy making her art. But every few minutes, a loud ad came on the screen. She could not skip it. It stopped her drawing again and again.

After this happened many times, she looked at me and said:

"I just want to draw. Can we make our own app without ads?"

At first, I could have said that making an app takes too much time. But then I thought, why not try?

So we made it a small weekend project.

My daughter became the product boss. She asked for rainbow brushes, a big drawing space, fun sounds, and no pop-ups. I worked on the code.

Together, we built this:

unicorn-draw.vercel.app

The tool that helped us build it fast was Google AI Studio with Gemini.

The Tech Stack

I wanted the app to be easy to use on an iPad. I also did not want to deal with the App Store.

So I made it as a Progressive Web App, or PWA. This means it works like an app, but it runs in the browser.

Here is what I used:

HTML5 Canvas API for drawing
CSS for big buttons and bright colors
Service Worker so the app can work offline
Web App Manifest so it can be added to the home screen
Google AI Studio and Gemini to help write and improve the code

Because it is a PWA, my daughter can open it from the iPad home screen. It runs full screen. It has no ads, no tracking, and no hidden pop-ups.

Building with Google AI Studio

Google AI Studio made the work much faster.

First, I asked Gemini to make a simple drawing app using HTML5 canvas. I also asked it to support touch events, so it would work well on an iPad.

Then my daughter tested the first version. She quickly asked for a magic rainbow brush and a simple clear button.

I gave the code back to Gemini and asked it to add a rainbow brush. I also asked it to make the buttons look more fun for a drawing app.

After that, I used Gemini to help create the PWA files, like manifest.json and the service worker.

In a short time, the app started to feel like a real tablet app.

Source Code

The project is open source.

You can see the full code here:

GitHub Repository: gaurav101/unicorn-draw

How to Install It on an iPad or Phone

You can add the app to your home screen in a few seconds.

Open unicorn-draw.vercel.app in your browser.
On iPhone or iPad, tap the Share button. On Android, tap the three dots menu.
Tap "Add to Home Screen".
Open it from the home screen and start drawing.

Now your child has a simple drawing app with no ads.

What I Learned

1. AI Helps You Build Faster

Gemini did not just write code for me. It helped me move fast.

Instead of spending time on small setup work, I could focus on how the app should feel for my daughter.

The whole project took only a couple of hours.

2. Kids Can Learn That They Can Build Things

The best part was not the app.

The best part was seeing my daughter understand something important:

Technology is not something we only have to use. If something is annoying or broken, we can try to make a better version.

That was the real win.

Markdown to Styled HTML in Java

Gaurav Kumar Singh — Sun, 28 Jun 2026 08:22:14 +0000

If you have ever built a Java application that converts Markdown to HTML—whether for a blog engine, a documentation site, or user-generated comments—you have likely run into a frustrating roadblock.

You pull in a solid library like commonmark-java, pass your Markdown string, and get perfectly valid semantic HTML blocks. But then you render it on the frontend and realize it looks completely unstyled.

Modern CSS frameworks like Tailwind CSS, Bootstrap, or Bulma rely heavily on utility classes. They don't automatically style raw <h1>, <p>, or <blockquote> tags unless you wrap them in heavy global stylesheet overrides. To fix this in Java, you are usually forced to write verbose custom tag renderers, map complex attribute providers, or write messy string-replacement wrappers.

That is exactly the problem FluentMarkdown solves.

💡 What is FluentMarkdown?

FluentMarkdown is a lightweight, zero-boilerplate Java library built directly on top of commonmark-java. It introduces a clean, fluent API that automatically injects the proper CSS framework classes into your HTML elements during the parsing phase.

Instead of fighting your CSS framework, you can map your tags instantly using built-in presets or completely custom styles.

🛠️ Getting Started

1. Installation

The library is explicitly lightweight (only four core files) and requires Java 17 or later. You can add it via Maven:

<dependency>
    <groupId>io.github.gaurav101</groupId>
    <artifactId>fluentmarkdown</artifactId>
    <version>1.0.4</version>
</dependency>

2. Quick Start: Use a Framework Preset

If you use Tailwind, Bootstrap 5, or Bulma, FluentMarkdown has pre-mapped configurations ready to go.

Here is how easily you can render fully-styled Tailwind HTML:

import io.github.gaurav101.fluentmarkdown.Markdown;

public class App {
    public static void main(String[] args) {
        String markdown = "# Hello World\nThis is a paragraph.";

        // One fluent chain handles it all
        String tailwindHtml = Markdown.from(markdown)
                                      .withTailwind()
                                      .toHtml();

        System.out.println(tailwindHtml);
    }
}

Output:

<h1 class="text-4xl font-extrabold tracking-tight mb-4 mt-6">Hello World</h1>
<p class="mb-4 leading-relaxed text-base">This is a paragraph.</p>

Switching frameworks is as simple as swapping .withTailwind() for .withBootstrap() or .withBulma().

🧠 Advanced Usage

🔒 Step 3: XSS Protection (Safe Mode)

If you are processing untrusted user input (like blog comments), rendering raw HTML can expose your app to Cross-Site Scripting (XSS) attacks. FluentMarkdown includes a built-in .safe() modifier that strips out malicious inline scripts and raw HTML blocks seamlessly.

String unsafeInput = "<script>alert('hack')</script>\n\n# Safe Title";

String safeHtml = Markdown.from(unsafeInput)
                          .withTailwind()
                          .safe() // Strips dangerous HTML
                          .toHtml();

🎨 Step 4: Custom Style Configurations

Don't use a standard CSS framework? You can build an immutable StyleConfig to map your own internal design system classes to any HTML tag.

import io.github.gaurav101.fluentmarkdown.StyleConfig;

StyleConfig myCustomConfig = StyleConfig.builder()
        .tag("h1", "custom-main-title")
        .tag("p", "body-text text-muted")
        .tag("a", "global-link")
        .build();

String customHtml = Markdown.from(markdown)
                            .withStyle(myCustomConfig)
                            .toHtml();

🔄 Step 5: Extend Existing Presets

If you love the Tailwind preset but want to tweak just one or two elements (like changing the link color), you can merge and overwrite tags dynamically:

import io.github.gaurav101.fluentmarkdown.Presets;

StyleConfig modifiedTailwind = StyleConfig.builder()
        .mergeFrom(Presets.tailwind()) // Start with Tailwind defaults
        .tag("a", "text-indigo-600 underline") // Overwrite just the anchor tag
        .build();

🎯Conclusion

FluentMarkdown provides a highly practical solution to a common backend UI problem. It keeps your Java code clean, readable, and perfectly married to modern frontend utilities.

Give the project a look, try it out in your next Java project, and don't forget to drop a ⭐️ on the repository!

👉 GitHub Repository: gaurav101/FluentMarkdown

The Hidden Cost of the AI Hype

Gaurav Kumar Singh — Thu, 25 Jun 2026 15:55:00 +0000

We talk a lot about what AI can build.

Code generation. Faster prototypes. Automated debugging. One-shot apps. Entire products created in hours.

And yes, AI is powerful.

But there is a quieter cost we are not talking about enough:

AI hype is starting to weaken the motivation to learn core engineering deeply.

That should worry us.

1. The "Why Bother?" Mindset

When the dominant narrative says AI can generate code instantly, many engineers start asking:

Why should I spend months mastering frameworks, architecture, databases, networking, or system design?

At first, that sounds practical. If a tool can help, why not use it?

But there is a difference between using AI to move faster and using AI to avoid understanding.

Core engineering is not just about writing code. It is about knowing why something works, where it breaks, how it scales, and how to fix it when the generated answer is wrong.

If we skip that learning, we create engineers who can prompt systems but cannot reason deeply about systems.

That is a dangerous tradeoff.

2. The Funding and Praise Monopoly

Right now, AI gets most of the attention.

Budgets move toward AI. Leadership praises AI initiatives. Teams are pushed to add AI features even when the fundamentals are still weak.

Meanwhile, excellent core engineering often goes unnoticed.

The people improving reliability, performance, developer experience, infrastructure, security, and maintainability are still doing high-impact work. But in many places, that work is being treated as less exciting simply because it is not branded as AI.

This creates pressure.

Engineers feel they must pivot to AI, not always out of interest, but out of fear. Fear of being left behind. Fear of being replaced. Fear that their existing expertise is no longer valued.

That is not innovation. That is anxiety disguised as progress.

3. The "AI-First" Discount

There is another subtle problem.

When someone builds something impressive today, the reaction is often:

AI probably generated that.

That assumption discounts real skill.

It ignores the planning, debugging, tradeoffs, refactoring, architecture, and judgment behind the work. AI may assist, but it does not automatically create good software.

Great engineering still requires taste. Context. Discipline. Experience. The ability to make hard decisions when requirements are messy and systems are complex.

When we assume every good output came from AI, we quietly devalue human craftsmanship.

AI Is an Accelerator, Not a Substitute

AI can help us move faster.

It can explain concepts, generate drafts, find bugs, write boilerplate, and help us explore ideas quickly.

But AI is not a replacement for engineering fundamentals.

If we stop learning the building blocks, we weaken the entire ecosystem AI depends on. Someone still needs to understand distributed systems. Someone still needs to design reliable APIs. Someone still needs to debug production failures at 2 AM. Someone still needs to know when the AI-generated solution is wrong.

The future should not be "AI instead of engineers."

It should be AI with stronger engineers.

What We Should Value

We need to keep rewarding the work that keeps technology stable:

Strong system design
Clean architecture
Reliable infrastructure
Secure software
Maintainable codebases
Deep debugging skills
Thoughtful technical leadership

AI can support this work, but it cannot replace the need for people who understand it deeply.

The best engineers of the future will not be the ones who blindly rely on AI.

They will be the ones who use AI wisely while continuing to sharpen their fundamentals.

Building a Safe, Local AI Coding Agent with Node.js

Gaurav Kumar Singh — Fri, 19 Jun 2026 03:57:12 +0000

Welcome to the 4th article of the MCP and RAG with JS series.

In this article, we will learn what AI agents are by building a practical, beginner-friendly coding agent in JavaScript. We will use a locally running LLM, Mistral on Ollama.

You do not need any paid subscription or API key. Everything runs locally on your machine, so this is accessible for learning, testing, and experimenting.

What We Are Building

We are building a local personal coding agent.

It runs in the terminal and helps us understand a JavaScript project. It can:

list project files
read project files
search text
explain code
find possible bugs
propose code changes

The important safety rule is this:

The agent can inspect files, but it does not directly edit them. If it wants to change something, it only returns a patch proposal for a human developer to review.

So in simple words, we are building a small local coding assistant.

Why This Helps Us Learn

AI agents can sound complicated, but most agent systems use a few common patterns.

In this project, we will learn those patterns with plain JavaScript:

Agent loop: repeat until the model gives a final answer.
Tool calling: let the model request specific JavaScript functions.
Tool allowlist: only allow approved tools to run.
System prompt: tell the model how it should behave.
JSON action protocol: make the model respond with structured JSON.
Model adapter: keep the Ollama HTTP code in one small file.
Safety boundary: keep file access inside the project root.
Human-in-the-loop changes: propose patches instead of applying them.
Tests for safety: verify path traversal, large file, and missing file behavior.

These same ideas appear in larger AI-agent frameworks. This project keeps them small enough to understand.

The Big Idea

A normal chatbot usually works like this:

User asks question -> Model answers

An agent works more like this:

User asks question
  -> Model decides what to do
  -> JavaScript runs a safe tool
  -> Model sees the tool result
  -> Model answers

The model does not directly read your files or run commands. It asks for a tool, and your JavaScript code decides whether that tool is allowed.

That is the main idea behind this project.

Project Structure

You can explore and clone the complete codebase in the coding-agents GitHub repository.
The important files are:

.
|-- package.json
|-- src
|   |-- cli.js
|   |-- agent.js
|   |-- ollama.js
|   `-- tools.js
`-- test
    `-- tools.test.js

Each file has a clear job:

src/cli.js: terminal entry point
src/agent.js: agent loop and tool dispatch
src/ollama.js: local Ollama API client
src/tools.js: safe filesystem tools
test/tools.test.js: safety and tool behavior tests

1: CLI Entry Point

The app starts in src/cli.js.

It imports the agent:

import { runAgent } from "./agent.js";

Then it chooses the project root and model:

const root = options.root || process.cwd();
const model = options.model || process.env.OLLAMA_MODEL || "mistral";

This means:

use --root if the user provides it
otherwise use the current folder
use --model if provided
otherwise use OLLAMA_MODEL
otherwise use mistral

The CLI supports two modes.

One-shot mode:

npm start -- "Explain src/tools.js"

Interactive mode:

npm start

In both cases, the CLI eventually calls:

const answer = await runAgent({ goal, root, model, verbose });

So the CLI is only responsible for input and output. The real agent behavior lives in runAgent.

2: Agent Loop

The main function is in src/agent.js:

export async function runAgent({ goal, root, model, verbose = false }) {

At the start, it creates the available tools:

const { createTools } = await import("./tools.js");
const tools = createTools({ root });

Passing root is important. It tells the tools which folder they are allowed to inspect.

Then the agent creates a message history:

const messages = [
  {
    role: "system",
    content: buildSystemPrompt(tools)
  },
  {
    role: "user",
    content: goal
  }
];

The system message contains rules for the model. The user message contains the developer's request.

Then the agent runs a loop:

for (let step = 1; step <= MAX_STEPS; step += 1) {
  const prompt = renderPrompt(messages);
  const raw = await generateWithOllama({ prompt, model });
  const action = parseAction(raw);

  // final answer or tool call
}

MAX_STEPS is set to 8, so the agent cannot loop forever.

This loop is the heart of the agent:

messages -> prompt -> model -> action -> tool or final answer

3: System Prompt

The system prompt tells the model how to behave.

In this project, the prompt says the model should:

inspect files before making project-specific claims
never claim a patch was applied
use propose_patch only for suggested changes
return exactly one JSON object

It also describes the available tools:

const toolDescriptions = Object.entries(tools)
  .map(([name, tool]) => `- ${name}: ${tool.description} Parameters: ${JSON.stringify(tool.parameters)}`)
  .join("\n");

This lets the model know what it can ask for.

The model must respond in one of two shapes.

To call a tool:

{"type":"tool","name":"read_file","arguments":{"path":"src/example.js"}}

To finish:

{"type":"final","answer":"Your answer here."}

This is a simple JSON action protocol. It is easy to understand because there is no hidden framework magic.

4: Local Model Adapter

The file src/ollama.js keeps the Ollama API call separate from the rest of the app.

The default local URL is:

const DEFAULT_OLLAMA_URL = "http://127.0.0.1:11434";

The function sends the prompt to Ollama:

const response = await fetch(`${baseUrl}/api/generate`, {
  method: "POST",
  headers: {
    "content-type": "application/json"
  },
  body: JSON.stringify({
    model,
    prompt,
    stream: false,
    options: {
      temperature
    }
  })
});

Then it returns the model text:

const data = await response.json();
return data.response || "";

This file has one job:

prompt in -> Ollama HTTP request -> model response out

Keeping this in one file makes it easier to swap models later.

5: Tool Calling

After Ollama responds, the agent parses the response:

const action = parseAction(raw);

If the model gives a final answer, the agent returns it:

if (action.type === "final") {
  return action.answer;
}

If the model asks for a tool, the agent checks whether that tool exists:

const tool = tools[action.name];
if (!tool) {
  messages.push({
    role: "tool",
    content: JSON.stringify({
      error: `Unknown tool: ${action.name}`,
      allowedTools: Object.keys(tools)
    })
  });
  continue;
}

This is very important.

The model cannot invent tools. It can only use tools that exist in the local JavaScript object.

Then the agent runs the tool:

const result = await tool.run(action.arguments || {});

And sends the result back into the message history:

messages.push({
  role: "tool",
  content: JSON.stringify({
    tool: action.name,
    result
  })
});

Now the model can use real project information instead of guessing.

Example flow:

User: Explain src/tools.js
Model: calls read_file
JavaScript: reads the file safely
Model: sees the file content
Model: gives final explanation

6: Safe Tools

The tools live in src/tools.js.

The project has four tools:

list_files
read_file
search_text
propose_patch

Each tool has:

description: tells the model what it does
parameters: tells the model what arguments it accepts
run: the actual JavaScript function

Example shape:

read_file: {
  description: "Read a UTF-8 text file from inside the project root.",
  parameters: {
    path: "File path relative to project root."
  },
  run: async ({ path: filePath } = {}) => {
    // safe implementation
  }
}

The tools are intentionally narrow.

list_files lists files under the project root.

read_file reads one text file if it is safe and not too large.

search_text searches project files for a string or regex.

propose_patch returns a patch proposal, but does not apply it.

That last point matters. The model can suggest changes, but a human still reviews them.
** use a safe regex engine if you are planning to expose the agent to external user inputs. **

7: Path Safety With `safeResolve`

The most important safety function is:

export function safeResolve(root, requestedPath) {
  const absolute = path.resolve(root, requestedPath);
  const relative = path.relative(root, absolute);

  if (relative.startsWith("..") || path.isAbsolute(relative)) {
    throw new Error(`Path escapes project root: ${requestedPath}`);
  }

  return absolute;
}

This blocks path traversal.

For example, this should be allowed:

src/tools.js

But this should be blocked:

../outside.txt

Why?

Because the agent should only inspect the selected project folder. Model output is not trusted input, so every requested path goes through safeResolve.

This is one of the most important lessons in agent development:

Give the model useful tools, but put real safety checks in code.

8: Size Limits

The tool layer also avoids reading huge files:

const MAX_READ_BYTES = 80_000;
const MAX_SEARCH_FILE_BYTES = 250_000;

read_file throws an error if a file is too large.

search_text skips files that are too large.

This protects the model context and keeps the agent responsive.

9: Patch Proposals, Not Auto-Edits

The propose_patch tool returns:

{
  summary,
  patch,
  applied: false,
  note: "Patch proposal only. Review before applying."
}

This is a human-in-the-loop design.

The agent can help you think and propose changes, but it does not silently modify your files.

For a beginner agent, this is a good safety tradeoff.

10: Tests for Safety

The project uses Vitest.

From package.json:

{
  "scripts": {
    "test": "vitest run",
    "test:watch": "vitest"
  }
}

The tests cover the dangerous parts:

safeResolve allows normal paths
safeResolve blocks ../ traversal
list_files handles missing directories
read_file rejects missing paths and directories
read_file rejects large files
search_text skips large files
propose_patch returns applied: false

Example traversal test:

expect(() => safeResolve(fixtureProjectRoot, "../outside.txt")).toThrow(/escapes project root/);

Example large-file test:

await expect(tools.read_file.run({ path: "large-read.txt" })).rejects.toThrow(/too large to read safely/);

Tests are not just for correctness here. They protect the safety boundary of the agent.

Complete Request Flow

If you run:

npm start -- "Explain src/tools.js"

the flow is:

src/cli.js receives the request.
It calls runAgent.
src/agent.js creates safe tools.
The system prompt describes the rules and tools.
src/ollama.js sends the prompt to local Ollama.
The model returns a JSON action.
If it asks for a tool, the agent checks the allowlist.
The tool runs with safety checks.
The tool result goes back to the model.
The model returns a final answer.

That is an AI agent in practical terms.

It is an LLM connected to a controlled loop, safe tools, and clear rules.

How to Run It

Requirements:

Node.js 18 or newer
Ollama installed
Mistral pulled locally

Pull the model:

ollama pull mistral

Start Ollama:

ollama serve

Run the agent:

npm start

Ask one question:

npm start -- "Explain src/agent.js"

Inspect another project:

npm start -- --root /path/to/project "Find bugs in the main CLI file"

Run tests:

npm test

Run syntax checks:

npm run check

What to Remember

An AI agent is not just an LLM.

An AI agent is usually:

LLM + loop + tools + context + safety rules

In this project:

the CLI gets the user request
the agent loop manages steps
Ollama provides the local model
tools provide controlled abilities
safeResolve protects file access
tests protect the safety behavior

The model can request actions, but JavaScript decides what actually runs.

That is the key idea.

Final Thoughts

This project is intentionally small, but it teaches the foundation behind many larger agent systems.

Once you understand this version, you can explore more advanced ideas like:

memory across chat turns
streaming model output
richer tool schemas
patch validation
confirmation-based patch applying
MCP tools
RAG over larger codebases

But the core idea stays the same:

Mistral is a good simple default for learning, but when you are building stronger coding agents, coding-focused models usually give better results. Good options to try are qwen2.5-coder, deepseek-coder, and Gemma.

Build useful tools, keep them narrow, and let your application code enforce the safety boundaries.

SOLSTICE: Planetary Balance

Gaurav Kumar Singh — Tue, 16 Jun 2026 04:17:53 +0000

This is a submission for the June Solstice Game Jam

What I Built

Solstice Balance is an interactive 3D calibration simulator where the player stabilizes Earth's obliquity (target 23.44°) and rotational speed to prevent a simulated thermal collapse.
Players use thruster-style controls to correct tilt and spin while reacting to procedurally generated cosmic disturbances (solar flares, gravitational tides, meteors).
The goal was to make a tactile, physics-driven experience that ties to the June Solstice theme—balancing seasonal geometry with emergent hazards.

Game Demo

Play the live demo: https://solstice-game.vercel.app/
(Recommended: open in a desktop browser for best WebGL and audio support.)

solstice-game.vercel.app

Code

Full source code and development history: https://github.com/gaurav101/solstice-game

How I Built It

AI Assistance: Utilized Google Gemini to pair-program, debug complex WebGL contexts, and rapidly iterate on the core physics calculations and WebGL Sound generation.
Framework: React + TypeScript with Vite for fast iteration.
3D & Physics: Three.js for rendering and cannon-es for rigid-body physics to simulate tilt, spin, and meteor impacts.
Audio: WebAudio-based synth engine and sampled effects for real-time atmospheric feedback.
UI: Tailwind CSS for a clean, rapid HUD layout; React state syncs real-time telemetry (score, alignment, RPM) seamlessly with the WebGL loop.
Performance Optimization: Employed procedural textures, batched particle systems, and defensive resource disposal to prevent memory leaks across scene restarts. ## How to play the game Below is your official flight manual to successfully calibrate Earth's rotation and orientation, countering severe space weather, and maintaining life-supporting equilibrium.

Notable design choice: The game loop runs inside a single requestAnimationFrame driven effect that cleanly tears down Three/Cannon resources when switching game states to completely avoid leaking WebGL contexts.

How To Play the Game (https://solstice-game.vercel.app/)

🛰️ 1. The Core Objective

Your active task is to guide and maintain Earth's planetary parameters in specified target alignment zones:

Target Axial Obliquity: 23.0° to 23.9° (aiming precisely for the natural June Solstice angle of 23.44°).
Target Rotational Velocity (Spin): 1.0 to 2.5 RPM (Revolutions Per Minute).
Planetary Ecosystem Integrity: Must remain above 0%. Integrity decays rapidly any second Earth remains outside optimal thresholds.

🎮 2. Control Layout

Counter-act deep space gravitational pull and harsh solar winds by applying immediate corrective torque.

Keyboard Input	Control Board Thruster	Operational Action
`W` or `▲ Up`	Pitch Forward	Tilts Earth's axis forward pointing towards the Sun
`S` or `▼ Down`	Pitch Backward	Tilts Earth's axis backward away from the Sun
`A` or `◀ Left`	Spin Faster	Speeds up the Earth's west-to-east spin velocity
`D` or `▶ Right`	Spin Slower	Applies electromagnetic dragging to slow rotation down

☀️ 3. Key Calibration Rules

📍 The Solstice sweet spot (23.44°)

When Earth is tilted at 23.44°, the North Pole is angled perfectly toward the Sun. In this position, you will see a bright circular sunlit ring over the Arctic region (the Midnight Sun) while the Antarctic Circle remains in winter shadow. This is the June Solstice Threshold.

Maintaining the axis inside the green 23.0° - 23.9° band raises your Calibration Accuracy.
Every second spent inside optimal zones awards Equilibrium Points.

🌀 The Rotational Band (1.0 to 2.5 RPM)

Static Risk (Spin below 0.3 RPM): If the Earth stops spinning, one side of the planet is cooked under permanent radiation, and the other freezes in absolute darkness. Ecosystem integrity will drop exponentially!
Erosion Risk (Spin above 3.5 RPM): Rotating too fast generates cosmic atmospheric drag that will tear away the ozone layers. Ecosystem integrity drops rapidly.

🚨 4. Galactic Disturbance Hazards

The orbital field is subject to unexpected external solar interferences that will knock you out of alignment:

Coronal Mass Ejections (Solar Flares): Strong electromagnetic storms that apply extreme pitch forces, abruptly throwing off the planetary tilt obliquity.
Atmospheric Gravitational Tides: Tidal fluctuations that can speed up or slow down Earth's spin speed.
Meteor Incursions: Direct strikes that transfer kinetic momentum, rotating or tipping Earth suddenly.

Listen for the Audio Synth’s pitch and tempo: The onboard audio system uses warning buzzers and frantic tempo modulation to signal when parameters are entering danger thresholds.

🏆 5. Tips for Pro-Commanders

Pulsed Thrusters over Static Holding: Do not hold down thruster buttons endlessly. Tap controls in short bursts to counteract drift, letting the friction settle the planet in the optimal zone.
Balance First, Tilt Second: If you are knocked completely off-course, prioritize bringing the planetary spin back into the 1.0 - 2.5 RPM band first to stop thermal decay, then nudge the obliquity to the target solstice angle.
Observe the Shaders: Watch the gorgeous daytime sunlight and glittering nightly city light shaders. If you see city light configurations rotating either too fast or not at all, immediately act!

Initialize engine calibration, steady the core, and save the Solstice!

Prize Categories

Best Google AI Usage: Google Gemini was instrumental in prototyping the initial graphics setup, debugging tricky 3D coordinate transformations, and ensuring the physics-driven gameplay integrated perfectly with React's state management.