Forem: Akhil

Prompt Engineering Is a Real Skill Here's What Actually Works

Akhil — Sat, 28 Mar 2026 11:48:47 +0000

Everyone's building AI features now. Most of them are getting mediocre results from capable models and blaming the model when the problem is actually the prompt.
Prompt engineering isn't about magic phrases. It's about understanding how language models process context and structuring your input so the model has everything it needs to do the job well.
Here's what actually moves the needle.

Be Specific About Output Format
The single highest-leverage thing you can do is tell the model exactly what format you want the output in. Vague prompts produce vague outputs.
javascript// Vague
const prompt = Analyze this customer review and tell me if it's positive or negative. Review: ${review};

// Specific
const prompt = `Analyze the following customer review and respond with ONLY a JSON object 
in this exact format:
{
  "sentiment": "positive" | "negative" | "neutral",
  "confidence": 0.0 to 1.0,
  "key_topics": ["topic1", "topic2"],
  "flags": {
    "mentions_competitor": boolean,
    "requests_refund": boolean,
    "has_profanity": boolean
  }
}

Review: ${review}

Respond with only the JSON. No explanation, no markdown code block.`;

Use a System Prompt to Set Behavior, Not the User Turn
The system prompt defines who the model is and how it should behave. The user turn is where the actual task goes. Mixing them creates inconsistent behavior.
javascriptconst response = await client.messages.create({
model: 'claude-sonnet-4-20250514',
max_tokens: 1024,
system: You are a code review assistant. You review code for correctness, performance, and security issues. You are direct and specific. You cite line numbers when pointing out issues. You do not compliment code or add positive framing — just identify problems and suggest fixes. Format your output as a numbered list.,
messages: [{
role: 'user',
content: Review this function:\n\n${code}
}]
});

Chain Prompts for Complex Tasks
If you're trying to get the model to do multiple things in one prompt (extract, then analyze, then format), split it into separate calls. Each step produces cleaner output.
javascript// Step 1: Extract the facts
const extractionResponse = await client.messages.create({
model: 'claude-sonnet-4-20250514',
max_tokens: 512,
messages: [{
role: 'user',
content: Extract only the factual claims from this text. Output as a JSON array of strings. Text: ${articleText}
}]
});

const facts = JSON.parse(extractionResponse.content[0].text);

// Step 2: Verify each claim
const verificationResponse = await client.messages.create({
model: 'claude-sonnet-4-20250514',
max_tokens: 1024,
messages: [{
role: 'user',
content: For each claim, rate it as "likely_true", "uncertain", or "likely_false" based on general knowledge. Return JSON. Claims: ${JSON.stringify(facts)}
}]
});
Two focused prompts beat one complex prompt almost every time.

Give the Model a Way Out for Uncertainty
If you don't, it will make things up.
javascriptconst prompt = `Answer the following question based ONLY on the provided context.
If the answer is not clearly stated in the context, respond with exactly:
{"answer": null, "reason": "not_in_context"}

Context: ${context}
Question: ${question}`;
This prevents hallucination by giving the model an explicit path when it doesn't know something.

Few-Shot Examples Are Powerful
If you want consistent output format or style, show the model examples of what you want rather than just describing it.
javascriptconst prompt = `Convert raw support ticket text to structured data. Here are examples:

Input: "My order #12345 hasn't arrived and it's been 2 weeks. I need this fixed ASAP."
Output: {"order_id": "12345", "issue": "delivery_delay", "urgency": "high", "action_needed": "investigate_shipment"}

Input: "How do I change my password?"
Output: {"order_id": null, "issue": "account_help", "urgency": "low", "action_needed": "send_help_article"}

Now process this:
Input: "${ticketText}"
Output:`;
The model will match the pattern you've shown rather than inventing its own format.

Temperature: When to Change It
Most people don't touch temperature. Here's when to:

Creative writing, brainstorming: temperature 0.8–1.0 (more varied, less predictable)
Data extraction, classification, structured output: temperature 0.0–0.2 (more consistent, deterministic)
General Q&A: default (0.7 or whatever the API default is) is usually fine

For any production feature that needs consistent behavior, keep temperature low.
javascriptconst response = await client.messages.create({
model: 'claude-sonnet-4-20250514',
max_tokens: 256,
temperature: 0.1, // Low for structured extraction
messages: [{ role: 'user', content: prompt }]
});

Message Queues: When and How to Stop Doing Work Inside HTTP Requests

Akhil — Sat, 28 Mar 2026 11:42:35 +0000

There's a habit in early-stage backend development where everything happens inside a request handler. User signs up → create the record, send the welcome email, notify Slack, sync to the CRM, trigger the analytics event — all before the response goes back.
This works until it doesn't. The response takes 3 seconds. One of those services goes down and the whole signup breaks. Traffic spikes and the queue of requests backs up.
Message queues are the fix. Here's when to use them and how to actually set one up.

The Mental Model
An HTTP request is synchronous — the client waits for your response. A message queue decouples the work: the request handler publishes a message and responds immediately. A separate worker process picks up the message and does the actual work.
Client → POST /signup →
[Create user record]
[Publish "user.created" message] ← takes milliseconds
[Respond 201 Created]

Background worker picks up "user.created" →
[Send welcome email]
[Notify Slack]
[Sync to CRM]
[Fire analytics event]
The client gets a fast response. The background work happens reliably, with retries if anything fails.

When to Use a Queue
Use a queue when the work:

Doesn't need to be done before the response (email, notifications, analytics)
Could take variable time (third-party API calls, file processing)
Should be retried automatically if it fails
Needs to be rate-limited (bulk email sends, external API rate limits)
Could overwhelm a downstream service if done in parallel (sending 10,000 emails at once)

Don't use a queue when:

The client needs the result immediately (payment processing, inventory check)
The work needs to be transactional with the database operation

Setting Up BullMQ with Redis
BullMQ is the current standard for job queues in Node.js. It's built on Redis.
bashnpm install bullmq ioredis

javascript// queues/index.js
const { Queue } = require('bullmq');
const Redis = require('ioredis');

const connection = new Redis(process.env.REDIS_URL, {
  maxRetriesPerRequest: null  // Required by BullMQ
});

const emailQueue = new Queue('emails', { connection });
const analyticsQueue = new Queue('analytics', { connection });

module.exports = { emailQueue, analyticsQueue, connection };
javascript// In your route handler
const { emailQueue } = require('./queues');

app.post('/signup', async (req, res) => {
  const user = await User.create({
    email: req.body.email,
    password: await bcrypt.hash(req.body.password, 12)
  });

  // Queue the follow-up work — non-blocking
  await emailQueue.add('welcome', {
    userId: user.id,
    email: user.email,
    name: user.name
  }, {
    attempts: 3,           // retry up to 3 times on failure
    backoff: {
      type: 'exponential',
      delay: 2000          // wait 2s, then 4s, then 8s between retries
    }
  });

  res.status(201).json({ id: user.id, email: user.email });
});

The Worker Process
This runs separately from your web server — either a different file/process or a different container:
javascript// workers/email.worker.js

const { Worker } = require('bullmq');
const { connection } = require('../queues');

const worker = new Worker('emails', async (job) => {
  const { type } = job.name;
  const { userId, email, name } = job.data;

  if (job.name === 'welcome') {
    await sendWelcomeEmail({ to: email, name });
    console.log(`Welcome email sent to ${email}`);
  }

  if (job.name === 'password-reset') {
    await sendPasswordResetEmail({ to: email, token: job.data.token });
  }

}, {
  connection,
  concurrency: 5  // process 5 jobs at once
});

worker.on('failed', (job, err) => {
  console.error(`Job ${job.id} failed: ${err.message}`);
  // Send to error tracking (Sentry, etc.)
});

Running Both Together in Development
Add a script to package.json:

json{
  "scripts": {
    "dev": "nodemon src/index.js",
    "worker": "nodemon workers/email.worker.js",
    "dev:all": "concurrently \"npm run dev\" \"npm run worker\""
  }
}

In production, run the worker as a separate process or container. This means you can scale them independently — if email sending falls behind, add more worker containers without scaling the web server.

Monitoring Your Queues
Add BullBoard for a visual dashboard:
javascriptconst { createBullBoard } = require('@bull-board/api');
const { BullMQAdapter } = require('@bull-board/api/bullMQAdapter');
const { ExpressAdapter } = require('@bull-board/express');
const { emailQueue } = require('./queues');

const serverAdapter = new ExpressAdapter();
serverAdapter.setBasePath('/admin/queues');

createBullBoard({
queues: [new BullMQAdapter(emailQueue)],
serverAdapter
});

app.use('/admin/queues', serverAdapter.getRouter());
This gives you a UI at /admin/queues showing active jobs, failed jobs, completed jobs, and the ability to retry failures manually.

Dead Letter Queues for Jobs That Keep Failing
Some jobs will fail permanently (invalid email address, deleted user record). After the retry limit is exhausted, move them to a dead letter queue for inspection rather than losing them:
javascriptemailQueue.add('welcome', jobData, {
attempts: 3,
backoff: { type: 'exponential', delay: 2000 }
});

worker.on('failed', async (job, err) => {
if (job.attemptsMade >= job.opts.attempts) {
// Move to dead letter queue
await deadLetterQueue.add(job.name, {
originalData: job.data,
failureReason: err.message,
failedAt: new Date().toISOString()
});
}
});

How browsers, servers, HTTP, and APIs really work

Akhil — Sat, 07 Mar 2026 12:17:38 +0000

You have written your first lines of HTML. You have styled a button. You have maybe even made something move on screen. But then someone says the words "client-server architecture" and your brain quietly closes a tab.

Do not worry. Nobody explains this well the first time. So let's fix that with food.

Every time you load a webpage, you are placing an order at a restaurant. The internet is just a very big, very fast dining room.

The Restaurant You Never Noticed

Imagine you walk into a restaurant. You sit down and tell the waiter: "I'd like the pasta, please." The waiter walks to the kitchen, the chef makes your pasta, and the waiter carries it back to your table.

That is literally the internet. Every single time you type a URL and press Enter.

You are the browser. Chrome, Firefox, Safari your browser sits at the table and asks for things on your behalf. The waiter is HTTP, the set of rules that carries your request to the kitchen and brings the food back. The kitchen is the server a computer somewhere in the world that you never see, but that does all the actual work. And the food? That is the HTML, CSS, images, and data that load on your screen.

That is the entire model. Everything else in web development is just details inside this loop.

The Address on the Envelope

Now let's talk about URLs. When you type https://google.com/search?q=cats, what exactly is happening?

Think of a URL like a postal address. google.com is the building. /search is which floor and room you want. ?q=cats is the sticky note you tuck into the envelope that says "also, specifically, I want the cats version of this."

The browser reads this address, packs up your request like a letter, and sends it out into the internet. The server at the other end reads the address, finds what you need, and sends it back.

But here is the part most people skip: your request has a method. A verb. It is not just "here is my address" it is "here is my address, and this is what I want to do."

The Four Things You Can Ask For

There are only four. That is it.

GET means "Can I see this?" You are asking to read something. Like asking the waiter what is on the menu. Nothing changes. You just want to look.

POST means "I want to add something new." You are sending new information to the server. Submitting a sign-up form. Posting a tweet. You are handing the kitchen a brand new order.

PUT means "I want to change something." Like calling the waiter back and saying "actually, make that pasta with no garlic." You are updating something that already exists.

DELETE means "Take this away." You are asking the server to remove something. Like asking the waiter to clear a dish from the table.

These four — GET, POST, PUT, DELETE are the whole vocabulary. Every interaction between a browser and a server uses one of these. Every. Single. One.

What the Server Writes Back

When the server gets your request, it sends a response. That response always has two parts: a status code and a body.

Think of it like sending a letter and getting a reply. The reply starts with a short signal "Yes, here it is" or "I moved, try this address" or "Sorry, I don't have that" or "Something exploded in the kitchen." Status codes are exactly this. A short, numbered way for the server to say how things went before giving you the actual content.

200 means everything worked. Here is what you asked for. 404 means the server looked everywhere and that page does not exist. 500 means something broke on the server's end — not your fault, just wait. 401 and 403 mean you are not allowed in. Members only.

You will see these numbers constantly once you start building things. They will stop feeling mysterious very quickly.

*What is an API, Then?
*
You will hear this word constantly. API. Application Programming Interface. It sounds like a government document. It is not.

An API is just a menu. A list of things you are allowed to ask for, and what you will get back.

When a restaurant prints a menu, they are saying: "These are the things we make. Ask for these using these names. Do not ask for things not on this list." An API is a server doing the exact same thing except instead of food items, it lists URLs and methods you can call.

Here is a real example. You are building a weather app. You do not have weather data. Nobody does, except a weather company. That weather company built an API. It says: "Send a GET request to /weather?city=Paris and we will send you back Paris's weather." You do exactly that. You get back a tidy package of data. Your app shows it. Done. You did not build the weather system. You just knew how to order from its menu.

That data usually comes back as JSON. JSON stands for JavaScript Object Notation, but forget the name. It is just a structured way to write information so both humans and computers can read it. Labeled boxes inside labeled boxes. The browser reads it and knows exactly where everything is.

Putting It All Together

Let's walk through what happens the moment you type a URL and press Enter the full story, no gaps.

First, your browser reads the address and looks up the IP address of the server using something called DNS. Think of DNS as the internet's phone book. It turns "google.com" into a real numeric address that computers understand.

Second, the browser builds a GET request like writing a letter and sends it through the internet to that address.

Third, the server receives it, reads what you want, fetches it from its database or files, and packs everything into a response.

Fourth, the server sends back a status code and the HTML, CSS, JavaScript, and images for the page.

Fifth, your browser reads all that code and paints the page you see on screen. What looks like magic is just a browser reading instructions very, very quickly.

From step one to step five, in most cases, this takes under a second. Every single page load. Every single time.

Want to see it yourself? Open any webpage, right-click anywhere, and choose Inspect. Click the Network tab. Refresh the page. You will see every single request your browser made, what status code came back, and how long each one took. The restaurant's full order history — live.

Why This Changes How You Think

Once you understand this model, everything in web development starts to make sense. Why does a login form submit to a URL? Because it is sending a POST request to the server. Why does clicking a delete button sometimes need a confirmation? Because DELETE is permanent the waiter is taking the plate away and washing it.

Why do some pages load fast and others do not? Because some kitchens are better organised than others. The browser asked for food. The question is how quickly the kitchen can make it.

Every framework you will ever learn React, Vue, Next.js, Django, Express is just a different way of either asking the question faster or answering it better. But the request and response cycle underneath? That never changes.

You do not need to understand everything at once. You just need one good mental model. Then everything else has a place to attach to.

The internet is a restaurant. Your browser is the customer. HTTP is the waiter. The server is the kitchen. You are now the kind of developer who knows what is happening when the page loads — even if the food takes a while to arrive.

Now go open that Network tab and watch the requests fly. It will never look the same again.

Tool Overload: Why Developers Waste 2 Hours Daily Switching Between 12 Apps

Akhil — Fri, 27 Feb 2026 17:44:46 +0000

let me paint you a picture of my Monday. 9 AM, fresh coffee, ready to crush
some TreeGuard features. Slack pings: "Prod login broken!" Cool, jump to thread – 18
messages, screenshot from user, no error logs. Copy issue ID, open Jira – ticket #348 exists but
assignee empty, no reproduction steps. Paste link to GitHub repo, check main branch (clean),
staging branch (3 open PRs, which one?). Click PR #67, scan 45 comments for "auth" keyword.
No luck. Open VSCode, pull latest code, run locally – login works.
Now Postman collection – prod endpoint 401s, local 200. CORS headers missing? Check nginx
container logs (docker logs treeguard-nginx). 403 forbidden. SSH to EC2 prod server, tail
/var/log/nginx/error.log – rate limited. Back to Slack asking who changed rate limits. Meanwhile
Jenkins build failed silently yesterday – no email. Figma link in Jira shows designer moved
OAuth button. Datadog dashboard? Prod CPU spiking. Vercel deploy logs show frontend build
passed. Sentry frontend errors? Console flood of hydration warnings.
3 hours later. Actual nginx config fix: 10 minutes. That's my daily reality – 12 tabs open across
3 browsers, 4 terminal windows, 2 apps (Slack+VSCode). Neck pain from constant
head-turning. Brain mush by lunch. Sound familiar?
This isn't just me being disorganized. Developer tool sprawl is an epidemic. GitHub (code),
Jira/Linear (tickets), Slack/Discord (chat), Postman/Insomnia (API), Docker Desktop
(containers), Jenkins/GitHub Actions (CI/CD), Figma (design), Datadog/New Relic (monitoring),
Notion (docs), Vercel/Netlify (deploys), Sentry (errors), VSCode extensions (everything else).
Each tool specializes perfectly... at making you context-switch constantly.
The cognitive cost is brutal. Psychology research proves each context switch costs 23
minutes of flow state recovery. 5 switches morning = 2 hours gone. 8-hour day becomes 6 hours
effective. Multiply across team: 4 devs x 2hrs x 5 days x 50 weeks = 2000 hours lost yearly.
That's 2.5 full-time salaries wasted on tool navigation instead of shipping features.
Hackathon teams suffer worst. 48-hour sprints turn into 36-hour tool fights. Me + 3 friends last
weekend: I owned GitHub+Docker, Rahul handled Jira+Postman, Priya did Figma+Slack,
Vikrant watched Jenkins+Vercel. Communication overhead killed us: "Rahul check PR #23
Postman results"
→
"Figma changed auth flow"
→
"Jenkins log line 847"
→
"Docker volume not
mounting.
" Nobody coded past midnight. Placed 4th instead of 1st. Judges saw half-baked
demo, thought we lacked skills.
College students get crushed. Professors demand "production-grade" projects but zero
budget for tools. Free GitHub Actions: 2000 minutes/month limit. Heroku free sleeps after 30
minutes. Render: 750 hours shared monthly. We hack around limits instead of building ML
models or polish UX. My TreeGuard smart campus app? Perfect locally, broken on free Vercel
(build timeout), half-functional on Heroku (sleeps during prof demo). GPA suffers.
Freshers take 2-3 weeks onboarding. Seniors document nothing because "everyone should
know Jira workflows.
" Tool sprawl hides real code issues – juniors fix symptoms (nginx 403s)
instead of root causes (rate limiter config). Imposter syndrome skyrockets: "Am I stupid, or is
this normal?"
Industry impact? Devastating. McKinsey says fragmented tools cost enterprises
$100K/engineer/year in lost productivity. 67% of devs report burnout from tool fatigue (Stack
Overflow survey). Mid-level engineers spend 15 hours/week in status meetings asking "where's
the spec?" instead of coding. VCs fund startups with "beautiful dashboards" that track DORA
metrics but ignore dev happiness.
Corporate trap: Management sees shiny integrations (Slack→Jira→GitHub) as progress.
Reality? Each integration breaks during upgrades. Jira plugin conflicts with GitHub OAuth. Slack
bot floods #random with build notifications. Result: devs mute everything, return to email chains.
Mental health crisis: Context switching triggers dopamine crashes. Deep code flow → Slack
notification → Jira ticket → GitHub PR review → back to code (where was I?). By Thursday I'm
typo-ing everywhere, Friday I'm recovering. Weekend coding sessions? Impossible when
Monday's 12-tab circus haunts me.
Global teams amplify pain. India 11 PM = US 1:30 PM. Async Slack → Jira → GitHub PR
cycles mean waiting 18 hours for approvals. Time zone math kills momentum. Pune/Nashik
freshers compete with Bangalore seniors who "know the tool stack"
– unfair advantage.
Economic ripple: Indian IT services giants (TCS, Infosys) charge $50/hour billing but deliver 30
hours effective work. Clients complain "slow velocity.
" Startups burn runway on tool licenses
($12K/engineer/year) without ROI. Students graduate thinking software = tool management, not
problem-solving.
Hackathon culture normalizes chaos. Winners demo polished apps on single-stack (Next.js +
Vercel + Supabase). Losers juggle poly-stack (React+Flask+K8s+Heroku+Mongo). Judges
reward simplicity, not tool mastery.
My personal toll: TreeGuard (smart campus app) took 3x longer than planned. Synapse ML
models trained perfectly locally, failed Jenkins 7 times (Docker networking). Lost weekend
hackathon placing. GPA slipping from tool debugging. Friends dropping CS –
"too much admin
work.
"
The irony: We built computers to automate tedium. Now computers force us to automate
between their own tools. Original sin: no "universal dev inbox" showing what's actually broken
right now across entire stack.
Student reality check: Recruiters ask "built production apps?" Answer: "Yes but spent 60%
time on tools, 40% coding.
" They hear incompetence.
Industry wake-up call: Tools serve devs, not opposite. GitHub Copilot writes perfect code, Jira
buries it under 18 status updates. Progress = fewer tabs open, not more tools licensed.
This tool sprawl isn't "part of the job.
" It's killing creativity, velocity, GPAs, hackathon rankings,
startup runways, and dev mental health. One dashboard showing PRs + builds + alerts + tickets
could save 2 hours/day. Imagine what we'd build with that time back.
Who's fighting the biggest tool battle? Drop your 12-tab horror stories below. Let's
commiserate and maybe fix this together.