DEV Community: Shreyas Hupare

Prompt Engineering

Shreyas Hupare — Tue, 17 Jun 2025 17:55:34 +0000

Garbage In, Garbage Out!
"The quality of your question decides the quality of ai's answer."

What is Prompt Engineering? Why it matters ?

A prompt means giving instructions to an AI model, right?
Well, not exactly. You can call it a prompt, but that alone doesn't make it prompt engineering. The real magic lies in how you ask the question. The output depends entirely on that.
So, why call it engineering? Because it's not just asking questions - it's learning how the model responds, testing different instructions, refining your approach, and building better results over time. That's an iterative, structured process - just like engineering.
So basically, prompt engineering is all about tweaking and refining your input to get the most accurate and useful output from an AI model.

Golden Rule #Don't Trust the Model Blindly

Let's get one thing straight: AI is a tool, not a truth machine.

It can hallucinate facts.
It can make assumptions.
It might sound confident and still be wrong.

So never expect it to do your job. Use it as a helpful assistant - but always verify what it gives you. It never supposed to give right answers.

Simple Checklist to improve your prompt

🧑‍🎓 1. Set the Persona
Tell the model who to become.

"You are a senior nodeJS developer working on NestJs Framework."
"You are a product manager writing a user story."
Why? Because it helps the model adopt the right tone, terminology, and context.

🙋‍♂️ 2. Say Who You Are & What you are trying to achieve
Let the model know your role too.

"I'm a beginner learning nodeJs and building simple to-do list application."
"I run a small business and want to automate emails."
This builds alignment and helps it tailor answers to your level.

📦 3. Give Clear Context
Don't leave it guessing. Do half job for AI.

❌ "Fix this code."
✅ "This is a React component giving a 'TypeError' on button click. Can you help debug it?"
Details matter. The more the model knows, the better it performs.

🧩 4. Break It Into Steps
Avoid asking everything in one go. Go modular.

❌ "Build me a chatbot with memory and emotion."
✅ "Step 1: Help me create a basic chatbot in Node.js. Step 2: How can I add memory support?"
Think of it as a conversation, not a monologue.

🔁 5. Use Examples
Give inputs and desired outputs.

Input: "I like apples and bananas"
Expected Output: ["apples", "bananas"]
It makes your expectation crystal clear.

❓ 6. Ask for Clarifications (Yes, Really)
Ask the model to review your prompt before answering.
"Before you answer, tell me if any part of this prompt is unclear or could be improved."
This practice helps catch weak spots early.

What If You're Not Getting the Results You Want?

That's part of the process. Prompt engineering is iterative - like coding.
Here's what to do:

Read your prompt again. Is it vague or missing info?
Read the response and ask: "What did it miss?"
Tweak one thing at a time and retry.
You can even ask the model: "Why might this answer not be what I expected?"

Over time, you'll build a sense for what works and what doesn't.

Learning References:
OpenAI Prompt Engineering Guide

Prompt Engineering Guide

Codeium is not Codeium anymore—It's Windsurf 🌊

Shreyas Hupare — Sun, 13 Apr 2025 17:36:20 +0000

Faster & Better coding than the Codeium extension? Meet the Windsurf Editor

Hey folks! If you've been using Codeium as your go-to AI coding buddy, it's time to update your bookmarks (and maybe your brain). Because Codeium just got a whole new name and identity:
Codeium is now Windsurf.
Same vision, same team - just with more flow. Literally.
But this isn't just a name change. It's a whole evolution. And today, we're diving deep into what's new, what's better, and why you should care - especially if you're a developer looking to level up your productivity.

Why the name change to Windsurf?

Let's be honest, Codeium was a bit of a spelling nightmare for many, and the name started to feel more about just "code" than the complete dev experience. Windsurf captures the feeling of gliding through your dev work with the wind at your back - no friction, just flow.
So…

What is the Windsurf Editor?
The Windsurf Editor is a full-fledged AI-powered IDE - not just an extension like before.
Think of it like this:
The Codeium extension lived inside your VS Code or JetBrains IDE.
The Windsurf Editor is the IDE. A standalone platform tailored from scratch to give you a tighter, faster, and more AI-native dev experience.

And yes, it's lightning fast. 🧠⚡

What happened to the old extensions?
Don't worry! The existing extensions aren't going anywhere - they've just been renamed:
Windsurf Plugins = Formerly Codeium extensions.
You can still use them in VS Code or JetBrains, but honestly, after trying the Windsurf Editor, you might not want to go back. Here's why…
Windsurf Editor vs Windsurf Plugin (Extension)

Let's talk about Cascade: Your new AI collaborator
In Windsurf Editor, chat isn't just chat anymore. It's called Cascade. Think of it like an AI teammate that understands your code and your intention.
You choose a mode - either:
✍️ Write - AI will directly make code changes in your file.
💬 Chat - More exploratory, you can ask questions and get context-aware help.
Cascade understands your workspace, your files, and even what's open in your editor. So suggestions are a lot more accurate and impactful than a generic LLM in a browser.
Smarter, Context-Aware Suggestions
Real-time Preview Before You Accept Changes

Let's say you're working on an HTML/CSS file and ask Cascade to tweak something. Before you hit "Apply," the Windsurf Editor shows you a live preview of the webpage, so you know exactly what you're getting.
No more guesswork. No more "Oh crap, that broke everything."
What about existing VS Code users?
Good news: Windsurf Editor can import your VS Code settings and extensions. So switching over doesn't feel like starting from scratch.
You still get:

The familiar layout
Your favorite themes
Your keyboard shortcuts But now with a smarter brain and tighter workflow.

So, should you switch?
If you're using Codeium (Windsurf Plugin) inside VS Code and you're happy with it, that's great.
But if you're ready to:
Work faster with deeper AI integration
Get more accurate, context-rich suggestions
Preview changes before applying them
Have a single editor that just flows

Then yes - Windsurf Editor is definitely worth the try.
Windsurf's MCP (Model Context Protocol)

What if your AI assistant could not only understand your code…
…but also your external data like PR comments from GitHub, your Slack threads, your Jira tickets, and even your Notion docs?
That's exactly what MCP is built for.
What does MCP do?
MCP allows the Windsurf Editor and Cascade to pull in relevant context from external platforms, giving it a much deeper understanding of what you're trying to do.
Currently, the number of tools that a user can have access to from the MCP servers at one time is limited to 50.
How to Setup ?

Already loving Codeium? Read my previous blog

Codeium :Visual Studio code Plugin | by Shreyas Hupare | Medium

Shreyas Hupare ・ Oct 13, 2024 ・
shreyashupare.Medium

Give it a try..

The Ultimate Guide to Dependency Injection in NestJS

Shreyas Hupare — Thu, 10 Apr 2025 09:00:29 +0000

Why do we use dependency injection?

When you’re developing a smaller component of your system, such as a module or a class, you often require functionality from other classes. For instance, you might need an HTTP service for making backend calls. Dependency Injection (DI) is a design pattern and mechanism that facilitates the creation and provision of certain application parts to other parts of the application that need them. DI allows you to decouple components and manage their dependencies more efficiently.

Why do we have separate modules?

Feature Module:
A feature module serves to organize code relevant to a specific feature, aiding in code organization and establishing clear boundaries. This practice helps manage complexity and encourages adherence to SOLID principles.
Shared Module:
A shared module is a modular component housing features, functionalities, or services intended for use across different parts of the application. It facilitates the organization and encapsulation of code that may be reused throughout the application, such as utility functions, common services, or custom decorators.
Global Module:
A global module is a specialized module providing services or functionality intended to be available throughout the entire application. These modules typically offer application-wide services like logging, configuration, database connections, or authentication services.

To denote a global module in NestJS, the @Global() decorator from the @nestjs/common package is employed. Decorating a module class with @Global() signifies to NestJS that the module and its provided services should be globally accessible throughout the application, eliminating the need for explicit imports in the modules where they are utilized.

Providers

Providers in NestJS serve as services or dependencies that can be injected into other components such as controllers, other services, or custom decorators.
NestJS initializes providers and resolves their dependencies during the startup phase of your application. This process occurs when your application begins running.
When you import modules containing providers, NestJS instantiates these providers and stores them in its built-in Dependency Injection (DI) container. Before creating a new instance, the DI container checks if an instance of the service already exists. Throughout the application’s lifecycle, the DI container maintains a registry of all providers and their instances. It manages the lifecycle of these instances, including their creation, resolution, and disposal.
In scenarios of nested service calls, where a service method is invoked within another service method, NestJS consistently utilizes the same instance of the service. This approach ensures that any modifications to the service’s state within the nested call hierarchy are consistently reflected throughout the application.
The @Injectable() decorator marks a class as a provider in NestJS. By applying @Injectable() to a class, you enable the injection of instances of that class into other components using constructor injection or property injection.

import { Injectable } from '@nestjs/common';
import { ExampleService } from './example.service';

@Injectable()
export class ExampleController {
  constructor(private readonly exampleService: ExampleService) {}

  // Controller logic...
}

Scope in NestJS determines the lifecycle and availability of providers. There are three primary scopes:

Singleton: This is the default scope where a single instance of a provider is shared across the entire application. Any component that injects this provider will receive the same instance.
Transient: In this scope, a new instance of a provider is created each time it is injected. This ensures that each component receives a fresh instance of the provider.
Request: Here, a new instance of a provider is created for each incoming HTTP request. This instance is available only within the scope of that particular request. Once the request is completed, the instance is discarded.
Issue Encountered with Dependency Service in NestJS Application

The problem arose when utilizing a configuration service responsible for providing config values throughout the application. Various services from different modules relied on this configuration service. Employing Dependency Injection (DI) enabled this service to be injectable with a default scope, typically singleton, meaning the same instance persisted throughout the application’s lifecycle. However, two distinct methods were employed to integrate this service into different modules.

One approach involved including the configuration service in the import array, as defined in Module C. Conversely, in Module B, the service was added to the providers array. This distinction led to a discrepancy: when updating the configuration service, the services within Module C received the latest configuration, while those within Module B retained outdated configuration values.

Understand the issue with an example of the code:

service A

import { Injectable} from '@nestjs/common';

@Injectable()
export class UserService {
  private user: string = '';

  getUser() {
    return this.user;
  }

  updateUser() {
    const x = ...  // db operation to get the value of x
    this.user = x;
  }
}

module A

import { Module } from '@nestjs/common';
import { UserService } from './user.service';
@Module({
  providers: [UserService],
  exports: [UserService], // Export UserService for injection
})
export class UserModule {}

module B

import { Module } from '@nestjs/common';
import { UserService } from '../user/user.service';

@Module({
  providers: [UserService],
})
export class ModuleB {}

module C

import { Module } from '@nestjs/common';
import { UserModule } from '../user/user.module';

@Module({
  imports: [UserModule],
})
export class ModuleC {}

Why was the above scenario occurring?

Every time you add a provider to a providers array, you’re telling Nest to create that provider in the current module’s context. That means a new instance is getting created, and different instances can have different values, which are causing this issue. If you only want one instance (usually the case), you just need to import the module that originally exports the provider.

How it typically works:

Creation of Provider Services: When you define a provider using the @Injectable() decorator, NestJS creates an instance of that provider and registers it within the DI container. This instance will be reused whenever it is requested within the same module context unless you specify otherwise (e.g., if you’re using a provider with the @Scope() decorator).
Disposal of Provider Services: The disposal of provider services typically happens when the application shuts down. NestJS handles the cleanup of resources automatically, so you generally don’t need to worry about explicitly disposing of services.
Updates on Class Properties: If you have class properties that get updated dynamically, you need to be careful about the scope and lifecycle of your provider instances. Changes to class properties will affect the instance of the class within the scope where it’s instantiated. If a provider is singleton-scoped (which is the default scope in NestJS), changes to its properties will affect all consumers within the same application instance.
Module Context: In NestJS, modules provide a way to organize the application into cohesive blocks of functionality. Each module has its own DI container, which means that providers registered within a module are scoped to that module. Therefore, changes to a provider’s properties will only affect other providers or components within the same module.
The instance created by providing it in the providers array of that module is scoped to the module and is independent of the singleton instance at the application level because they are separate instances with their own memory space. Any updates made to the properties of the service instance will not affect the instance in the context of the module.
Solution:

Using the global decorator, you don’t need to import it everywhere it’s required, as it is available throughout the application.
Import it in the module instead of providing it in the providers array.
Precautions:

Make sure you’re not redefining the service within the module using the providers array.
Make sure you’re not inadvertently importing or providing the service multiple times within the module or its parent modules.

Medium

Error handling in NestJS

Shreyas Hupare — Fri, 04 Apr 2025 18:33:00 +0000

What is Error Handling?

Error handling is the process of managing and responding to errors that occur during the execution of a program. It involves detecting, handling, and recovering from errors gracefully to ensure the stability and reliability of the application.

How Does NestJS Handle Exceptions?

When an exception is thrown in JavaScript, whether inside an asynchronous function or synchronous code, it interrupts the normal flow of execution. The JavaScript runtime immediately stops executing the current function and begins to unwind the call stack, looking for a suitable exception handler to handle the error. This is called “exception unwinding”.

Here’s how it works:

Exception Thrown: When an exception occurs, JavaScript immediately stops executing the current code block and starts to unwind the call stack.
Call Stack Unwinding: The JavaScript runtime begins to pop functions off the call stack, returning control to the functions that invoked them. This process continues until the exception is caught by a suitable exception handler or until it reaches the global scope.
Exception Handling: If there’s a try-catch block surrounding the code that threw the exception, JavaScript jumps to the appropriate catch block. If there’s no catch block in the current function, JavaScript continues unwinding the call stack, searching for a catch block in the calling function, and so on.
Global Exception Filter: If the exception isn’t caught in try-catch anywhere, then the exception filter intercepts and handles it gracefully. However, this doesn’t always work in the case of errors thrown in asynchronous functions.
Unhandled Exception: If the exception isn’t caught anywhere above, it becomes an “unhandled rejection”.
What Happens When an Exception is Thrown within an Asynchronous Function?

In NestJS, the global exception filter plays a crucial role in catching and handling errors that occur within the application. NestJS’s global exception filters operate synchronously, intercepting errors as they propagate up the call stack. However, when it comes to errors thrown in asynchronous functions, the global exception filter might not always catch them as expected.

This behaviour occurs because async functions in JavaScript return a Promise. When an error is thrown within an async function, it is encapsulated within that Promise. As a result, the error is not immediately thrown in the calling context but rather captured within the Promise’s rejection handler and the error thrown is queued within the event loop, i.e., it’s deferred until the Promise is either awaited or handled. This means that by the time the error propagates back to the global exception filter, it might have already passed the point where the filter could intercept it.

To address this issue, you can manually catch errors within the async functions and handle them appropriately.

You can find more information about exception filters in NestJS’s documentation — Exception Filters