DEV Community: Sahil Singh

Why Your AI App Lies to You? And How to Catch It Before Your Users Do

Sahil Singh — Sun, 28 Jun 2026 08:50:06 +0000

I spent 3-4 weeks building an AI-powered research assistant.

It could pull from documents, search the web, synthesize answers, and respond in seconds. It was impressive, but then I thought that before shipping using it as a normal user will be a lot useful for me and the agent itself in terms of review.

Then I started actually checking its answers.

It was wrong about 30% of the time. Not obviously wrong confidently, fluently, authoritatively wrong. It cited papers that didn't exist. It quoted statistics with the wrong numbers. It described a company's product as if it were still 2022.

The scariest part? It never once said "I don't know."

That was the moment I understood that building an AI app and building a trustworthy AI app are two completely different problems.

The confidence illusion - what hallucination actually means

"Hallucination" is the industry word for when an AI makes things up. It sounds dramatic, like the model is having a psychedelic episode. The reality is more mundane and in some ways more unsettling.

Large language models don't retrieve facts the way a search engine does. They're not looking things up in a database. They're pattern-matching across billions of pieces of text they were trained on and generating the most statistically plausible next word, then the next, then the next.

Think of it like a student who never admits they didn't study. Asked a question they don't know, they don't say "I'm not sure." They construct the most convincing-sounding answer they can from the fragments they do remember and they say it with complete confidence.

The model has no internal alarm that fires when it's about to say something false. It doesn't experience uncertainty the way you do. It just... generates.

This is not a bug that will be patched in the next version. It's a fundamental property of how these systems work. Building around it is the job.

Three ways your AI is probably lying right now

Before we talk solutions, let's make the problem concrete. In my experience building and debugging LLM systems, hallucinations tend to fall into three categories.

1. Fabricated citations

Ask an AI to back up a claim with sources, and it will often invent them. The journal name sounds real. The author names sound real. The title is exactly what you'd hope to find. The paper does not exist.

I caught this in my own system when a user asked for research on a niche medical topic. The AI returned four citations formatted perfectly in APA style none of which I could find anywhere. When I dug into the retrieval logs, the model hadn't found strong matches, so it had filled the gap by generating plausible-looking references from scratch.

2. Confident wrong numbers

Statistics are particularly dangerous territory. "Studies show that 73% of..." is a sentence structure the model has seen thousands of times. It knows how to complete it convincingly. It does not know whether 73 is the right number.

In one test, I asked my system a question about market size figures. It returned a number that was off by an order of magnitude but the sentence around it was so well-constructed that I almost missed it.

3. Outdated information presented as current fact

LLMs have a training cutoff. The model doesn't know what it doesn't know about the world after that date. So when asked about a company's current leadership, a product's current pricing, or a law's current status it answers based on what was true when it was trained, with no caveat that things may have changed.

Your users will not know this. They will trust the answer.

Why RAG helps — but doesn't fully solve it

At some point in every AI project, someone says "just use RAG" as if it's the answer to everything. Retrieval-Augmented Generation is genuinely powerful. But it's not a magic fix, and I want to be honest about where it falls short.

Here's the plain-English version of what RAG does: instead of relying solely on what the model memorized during training, you give it a library to look things up in. When a user asks a question, you first search your library for the most relevant documents, then hand those documents to the model along with the question. Now it's answering based on real, current, specific information rather than memory alone.

This dramatically reduces hallucinations. But it doesn't eliminate them.

The failure modes I've hit in production:

Bad retrieval. If the search returns the wrong documents because the query was ambiguous, or the embedding didn't capture the right semantic meaning the model answers from irrelevant context. Garbage in, garbage out.

Context window overflow. When you retrieve too many chunks, older ones get pushed out of the model's attention window. Information that was technically "given" to the model effectively disappears.

Hybrid search mismatches. Pure semantic search misses exact keyword matches. Pure keyword search misses conceptual similarity. I use BM25 + semantic search in combination but tuning that balance for your specific domain takes real iteration.

The model ignoring the retrieved context. Sometimes the model has such strong priors about a topic that it partially ignores what you gave it and fills in from training data anyway. This one is particularly tricky to catch.

RAG is essential. It's not sufficient.

How to actually catch lies: evaluation pipelines explained?

This is where most teams drop the ball not because they don't care, but because evaluation feels less urgent than shipping. It isn't. Every hallucination your users catch is a trust deficit you'll spend months recovering from.

Here's what I track, and why each metric matters.

Retrieval precision

Before the model even generates an answer, did we retrieve the right documents? I measure this by taking a set of known question-answer pairs, running them through the retrieval step only, and checking whether the correct source document appears in the top results. If retrieval is broken, no amount of prompt engineering will save you.

Hallucination rate

This is harder to measure at scale, but critical. I built a separate evaluation pipeline where a second LLM call checks whether the generated answer is actually grounded in the retrieved context. It's not perfect, but it catches the most egregious fabrications. When I first ran this on my system, the hallucination rate was sitting at 31%. After three rounds of prompt iteration, I got it down to under 8%.

p95 latency

Reliability and speed are both trust signals. A system that's accurate but times out 5% of the time still erodes confidence. I track p95 latency (the latency at the 95th percentile what your slowest users actually experience) because averages hide the outliers that hurt you most.

Answer quality scoring

Beyond factual correctness, I run A/B prompt tests where outputs are rated on relevance, completeness, and clarity. This is more subjective, but over time the signal is real. Moving from a vague system prompt to a carefully structured one with few-shot examples improved my quality scores by about 30%.

The tooling I use for all of this is LangSmith it sits alongside LangChain and gives you full observability into every step of your chain: what was retrieved, what was passed to the model, what came back, and how long each step took. If you're building serious LLM applications and you're not using something like this, you're flying blind.

Confidence scoring and human handoff the last line of defence

Even with great retrieval and careful evaluation, some queries will always fall into the gap between what your system knows and what the user needs. The honest engineering answer to this is not to guess harder. It's to know when to stop guessing.

In my research assistant, I implemented confidence-based human handoff. Here's how it works: every answer comes with a confidence signal derived from how well the retrieved documents matched the query, and how consistent the model's answer is with the source material. When that confidence falls below a threshold, instead of returning a potentially wrong answer, the system flags the conversation for live human review and seamlessly hands off to a human agent streamed in real time over WebSocket so the user barely notices the transition.

This is, I think, the most underrated idea in applied AI right now.

We've spent decades teaching humans that admitting uncertainty is a sign of weakness. In AI systems, it's the opposite. A system that says "I'm not confident enough to answer this, let me connect you with someone who can" is infinitely more trustworthy than one that confidently makes something up.

Engineering "I don't know" into your AI is not a fallback. It's a feature.

A practical checklist: before you ship your AI feature

If you're building something with an LLM in the stack, here's what I'd make non-negotiable before it touches real users.

Build an eval dataset first. At least 50 question-answer pairs that cover your important use cases, including edge cases and known failure modes. You need this before you can measure anything.
Measure retrieval precision separately from generation quality. Don't conflate them. A bad answer might be a retrieval failure, not a model failure and they need different fixes.
Track hallucination rate with an automated checker. Imperfect but essential. Even a rough signal tells you whether things are getting better or worse as you iterate.
Set confidence thresholds. Decide in advance what your system does when it isn't sure. Route to a human, return a "I couldn't find a confident answer" message, or at minimum flag the response as low confidence.
Monitor in production, not just in testing. Real user queries will surprise you. Real user queries will break things your test set never imagined. Set up logging from day one.
Run prompt A/B tests before treating any prompt as "done." Your first system prompt is almost certainly not your best one. Treat it like code iterate, measure, improve.

The uncomfortable truth

We're in a moment where it's easier than ever to appear to have built something intelligent, and harder than ever to actually have built something trustworthy. The gap between a demo that impresses and a product that earns long term user trust is exactly the gap this article is about.

The teams that close that gap the ones that build eval pipelines before they're on fire, that treat hallucination rate as seriously as uptime, that design "I don't know" into their systems from the start are the ones building AI products that will still have users in two years.

Everyone else is building demos.

[Boost]

Sahil Singh — Sun, 28 Jun 2026 06:31:46 +0000

Angular vs React: My Developer Showdown (With Real Bumps, Bruises & Breakpoints)

Sahil Singh — Mon, 01 Dec 2025 17:59:50 +0000

Let’s address the cosmic question that haunts every newbie, junior, or “someone-just-handed-me-the-frontend” developer: Angular or React? Which should you choose? Grab your coffee—this could save you days of doomscrolling through dev forums. No company names or resume flexes here, just my personal journey as a developer who’s tangoed with both.

Who Should Choose What?

1) React is your buddy if:

You want to start fast and love JavaScript like it’s your favorite hoodie.
You like flexibility, minimal boilerplate, and the freedom to go wild with libraries.
You’re slotting into an existing project and don’t want to rewrite the world.
You want something gentle on the learning curve (your brain cells will thank you).

2) Angular, on the other hand, is perfect if:

You crave structure, TypeScript discipline, and clear rules (team projects—hello!).
You’re starting something big, complex, and enterprise-y from scratch.
You want one framework to rule them all—routing, forms, HTTP, you name it, it’s included.
You like big words like “dependency injection” (impress your dev friends!).

One big mental unlock: React is a UI library that you assemble into a full stack of tools, while Angular is a full framework that hands you an ecosystem from day one. With React, you decide how to handle routing, state, forms; with Angular, those decisions are mostly baked in.

Which Is Better… When?

Here’s a slightly beefed-up table so your decision isn’t just a coin toss:

Scenario	Angular	React
Learning curve	Steep (bring snacks).	Gentle (bring coffee).
Starting from scratch	Great for big/complex apps.	Great for MVPs and smaller apps.
Incremental adoption	Harder (framework-first mindset).	Super easy, can add to existing pages.
Freedom to choose libs/tools	Not much, it’s opinionated.	Do whatever, sky’s the limit.
Built-in features	Forms, HTTP, DI, routing, testing.	Mostly UI; fetch rest via libraries.
Suitability for large teams	Excellent due to enforced patterns.	Good, but conventions must be enforced by team.
Mobile app support	Via Ionic / NativeScript.	React Native is first-class.
Performance focus	Optimized for large, structured apps.	Fantastic for dynamic UIs via Virtual DOM.

In practice, React shines when UI needs to be very interactive and you want rapid iteration—think dashboards, chat apps, SaaS tools, and startups living on AB tests. Angular shines when you’re building long-lived, complex platforms with forms, roles, workflows, and a bunch of developers pushing code simultaneously.

When I Fought With Both (And Survived)

React: Built a full-stack fitness microservices app where React powered the frontend talking to multiple backend services—user, activity, and AI recommendations. OAuth2 authentication, an API gateway, and AI-generated suggestions meant a lot of moving parts, but React’s component-based design made it easy to break the UI into small, testable pieces and plug into tools like Material UI and custom hooks. It felt like assembling IKEA furniture—sometimes the manual felt thin, but oh boy, could I arrange the room any way I wanted.

Angular: Worked on complex, enterprise-style features where accessibility, keyboard navigation, cross-browser quirks, and consistent UX were non-negotiable. Angular’s opinionated structure—modules, services, DI, routing—helped keep everything organized, especially when multiple devs were touching the same screens and features. The structure and “do it this way” style felt strict at first, but painless when collaborating across teams.

React (again – MERN mode): Built an AI-powered chatbot using the MERN stack with secure authentication (JWT, HTTP-only cookies), role-based access control, and chat history stored in MongoDB. React made it simple to manage distinct UI states (loading, streaming replies, error, history) and experiment with layout and styling without rewriting the app architecture. Flexible UI design and easy state management patterns made the chatbot a breeze to evolve compared to a heavier framework setup.

All this gave me a kind of personal rule of thumb:

“Need freedom + fast experiments + pretty UI?” → React.
“Need consistency + long-term maintainability + strict structure?” → Angular.

The Learning Process: Enter the Gauntlet

From a “how painful is this on a Monday morning” standpoint, React feels faster to get productive, while Angular rewards you later when your app and team start getting big and messy. To make this more practical, here’s a simple 30/60/90-style roadmap you can actually follow.

30/60/90 Day Learning Roadmap

Think of this not as strict rules, but as a sane plan that fits alongside college, work, or side projects.

Timeline	React Focus	Angular Focus
Days 1–30	- Refresh JS/ES6 basics (let/const, arrow functions, promises). - Learn components, props, state, JSX. - Build a tiny SPA: todo list or notes app.	- Learn TypeScript basics. - Understand components, templates, and data binding. - Build a simple CRUD app with Angular CLI.
Days 31–60	- Dive into hooks: useState, useEffect, useContext. - Add routing (React Router) and basic auth. - Learn basic global state (Context or Redux).	- Learn services, dependency injection, and HttpClient. - Work with routing, guards, and lazy loading. - Explore reactive forms and validation.
Days 61–90	- Try performance tweaks and code-splitting. - Explore Next.js or advanced patterns (custom hooks). - Build a mid-sized app (dashboard, chat, or SaaS-style UI).	- Focus on performance (OnPush, lazy modules, best practices). - Add authentication, role-based access, and interceptors. - Build a more complex app (admin panel, internal tool).

Roadmaps like these are inspired by public React and Angular guides, but tuned toward actually building stuff, not just passing tutorials.

Starter Project Ideas Tailored to Both

Because “learn X” means nothing until you’ve broken at least one app in production (kidding… mostly), here are concrete project ideas that align with microservices, APIs, and AI—things already in my stack.

React project ideas:

Fitness Activity Dashboard: A simplified version of the fitness microservices app—track workouts, integrate a public API for exercise suggestions, and show stats with charts.
AI Notes Assistant: Use an AI API to summarize or rewrite notes; React handles the UI, streaming responses, and state while the backend serves as a thin proxy.
Minimal Chatbot Frontend: Recreate the core UI of a chat app (like the MERN chatbot), focusing on chat history, typing indicators, and message states—even if the backend is mocked at first.

Angular project ideas:

Admin Panel for Microservices: Build an Angular dashboard that consumes multiple microservice APIs (user, payments, logs) with role-based routes and guards.
Internal Tools Suite: A small “suite” of tools—log viewer, feature toggles, config manager—implemented as Angular modules with lazy loading and shared components.
Hospital/Appointment Management UI: Perfect for practising complex forms, validations, and different user roles (doctor, admin, patient).

Tie these to your existing backend knowledge—Spring Boot microservices, Kafka, or AI APIs—and suddenly your portfolio isn’t “another todo app,” it’s “full-stack systems with real-world patterns.”

A Tiny Code Snippet: Same UI, Two Worlds

Here’s a super tiny “Hello Framework” example to show how differently Angular and React think, even when doing something simple.

React version:

// React: App.jsx
import { useState } from "react";

function App() {
  const [framework, setFramework] = useState("React");

  return (
    <div>
      <h1>Hello from {framework}!</h1>
      <button onClick={() => setFramework("React")}>Use React</button>
      <button onClick={() => setFramework("Angular")}>Use Angular</button>
    </div>
  );
}

export default App;

Angular version (conceptual, shortened for readability):

// Angular: app.component.ts
import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  template: `
    <h1>Hello from {{ framework }}!</h1>
    <button (click)="setFramework('React')">Use React</button>
    <button (click)="setFramework('Angular')">Use Angular</button>
  `
})
export class AppComponent {
  framework = 'Angular';

  setFramework(name: string) {
    this.framework = name;
  }
}

Same idea, different philosophies: React leans on functions, hooks, and JSX; Angular leans on decorators, templates, and class-based components with TypeScript.

Extra Nerdy Bits (Because Why Not)

Popularity: React is still more widely used overall, especially for startups and smaller teams, while Angular holds strong in enterprise ecosystems where structure and long-term maintainability are king.
Performance: React focuses on efficient UI updates via the Virtual DOM and concurrent rendering, while Angular leans on AOT compilation, tree-shaking, and newer features like Signals to stay efficient at scale.
Team fit: If your team is full of JS-first devs, React fits naturally; if they come from Java/C#/OOP backgrounds and are used to layered architectures, Angular will feel like home.

So, here’s the cheat code:

Want fast iteration, experiments, and UI-focused work? Start with React.
Want battle-tested structure and to think like an architect from day one? Go Angular.

Or do what I did: learn both, suffer twice, and then enjoy understanding why the “Angular vs React” flame wars are only fun when your build has already passed.

A Beginner’s Guide to DevOps: Where to Start and What to Learn

Sahil Singh — Thu, 16 Jan 2025 20:36:00 +0000

If you're new to DevOps, the journey can feel overwhelming. With so many tools, practices, and philosophies, it’s hard to know where to begin. This guide will give you a roadmap to start your DevOps journey, breaking it down into manageable steps and providing actionable advice.

What is DevOps?

At its core, DevOps is a set of practices that bridge the gap between development and operations teams, aiming to deliver software faster, more reliably, and with fewer bugs. It’s not just about tools—it’s a culture shift that emphasizes collaboration, automation, and continuous improvement.

Step 1: Understand the Basics

Before diving into tools, familiarize yourself with the foundational concepts of DevOps:

Continuous Integration (CI): Regularly merging code changes into a shared repository and running automated tests to catch bugs early.
Continuous Delivery (CD): Automatically deploying code changes to production or staging environments after passing all tests.
Infrastructure as Code (IaC): Managing infrastructure (like servers and networks) using code and automation.
Monitoring and Logging: Tracking system performance and errors to identify and fix issues quickly.
Collaboration and Culture: Encouraging communication and teamwork between developers, QA, and operations teams.

Step 2: Learn a Version Control System

A solid understanding of version control systems is essential. Start with Git, the most widely used system. Learn how to:

Create and manage repositories.
Work with branches.
Merge changes and resolve conflicts.
Use platforms like GitHub, GitLab, or Bitbucket for collaboration.

Step 3: Get Comfortable with the Command Line

Many DevOps tools require command-line interaction. Spend time learning:

Basic shell commands (e.g., ls, cd, mkdir, grep).
Bash scripting or PowerShell for automation.

Step 4: Explore CI/CD Tools

Familiarize yourself with popular CI/CD tools. Start with one and gradually expand:

Jenkins: A powerful, open-source automation server.
GitHub Actions: CI/CD workflows integrated into GitHub.
GitLab CI/CD: Built into GitLab, offering pipelines and automation.
CircleCI/Travis CI: Cloud-based CI/CD platforms.

Step 5: Learn Containerization with Docker

Containers are at the heart of modern DevOps. Docker is the go-to tool for containerization. Learn how to:

Build and run Docker containers.
Write a Dockerfile to containerize applications.
Use docker-compose to manage multi-container setups.

Step 6: Understand Orchestration with Kubernetes

Kubernetes (K8s) manages containers at scale. While it has a steep learning curve, it’s invaluable for modern deployments. Start with:

Basic Kubernetes concepts (pods, services, deployments).
Deploying a simple application to a Kubernetes cluster.
Tools like Minikube or Kind for local Kubernetes experiments.

Step 7: Embrace Cloud Platforms

Cloud computing is integral to DevOps. Familiarize yourself with one major cloud provider:

AWS: The most widely adopted cloud platform.
Azure: Microsoft’s cloud solution.
Google Cloud Platform (GCP): A growing competitor.

Focus on core services like:

Virtual machines (EC2, Azure VMs, GCE).
Storage solutions (S3, Azure Blob, GCS).
Managed Kubernetes services (EKS, AKS, GKE).

Step 8: Learn Infrastructure as Code (IaC)

IaC tools automate infrastructure provisioning. Start with:

Terraform: An open-source IaC tool that works across multiple cloud providers.
Ansible: Configuration management and automation.
AWS CloudFormation: IaC specific to AWS.

Step 9: Implement Monitoring and Logging

Monitoring tools help ensure application health and performance. Learn:
Prometheus and Grafana: For metrics and visualization.
ELK Stack (Elasticsearch, Logstash, Kibana): For logging and search.
Datadog/New Relic: Cloud-based monitoring solutions.

Step 10: Build a DevOps Project

The best way to learn is by doing. Create a small project where you:

Set up a Git repository.
Create a CI/CD pipeline.
Containerize your application with Docker.
Deploy it to a cloud provider using Kubernetes.
Monitor its performance with Prometheus and Grafana.

Final Thoughts
Starting with DevOps might seem like climbing a mountain, but by taking it step by step, you can make steady progress. Remember, DevOps is a journey—there’s always something new to learn, but that’s part of the fun!

What’s your next step in your DevOps journey? Share in the comments below!