You ask it something meaningful — “How did Vijay become CM of Tamil Nadu?” — and it just stares back. It can’t process intent. It can’t figure out context. All it can do is grep for the word “Vijay” in a column somewhere and hand you back a pile of rows that technically matched.

That’s it. That’s the whole trick.

Traditional databases — Postgres, MySQL, MongoDB — are built for exact matching. They’re fast, reliable, and genuinely excellent at what they do. But what they do is this:

SELECT * FROM posts WHERE title LIKE '%Vijay%'

Keyword. Match. Done.

Ask them what something means? Blank stare.

That’s the gap Vector Databases were built to fill.

What’s Actually Wrong With Traditional Databases for AI?

It’s not that relational databases are bad. They’re incredible tools — just for the wrong job.

CRUD apps (Create, Read, Update, Delete) are their sweet spot. You want all orders placed in Chennai last Tuesday? Postgres nails it in milliseconds. You want to find content related to a topic, or answer a question in natural language, or surface things a user will probably like? That’s where they fall apart.

The reason is simple: traditional databases store data as structured values — text strings, numbers, timestamps. They find things by matching those values exactly or filtering by range. They have no concept of meaning. They don’t know that “automobile” and “car” are the same thing. They don’t know that a question about Vijay’s political journey is related to articles about Tamil Nadu elections.

Vector databases do. And the way they pull this off is genuinely clever.

Vectors: Just Coordinates With More Dimensions

Here’s the core idea.

Everything that gets stored in a Vector DB — a sentence, an image, an audio clip — first gets converted into a vector. A vector is just a list of numbers. Something like:

"Vijay won the Tamil Nadu elections" → [0.12, -0.88, 0.43, 0.77, ...]

That list might be 768 numbers long. Or 1536. Depends on the embedding model.

What do those numbers mean? They’re coordinates. Each vector is a point in a multi-dimensional space. You can think of it like a map — except instead of longitude and latitude (2 dimensions), you’ve got 1536 dimensions.

On a real map, Tamil Nadu and Kerala sit near each other because they share geography, culture, language. Delhi is far from both. The coordinates reflect the relationship.

In a vector space, it works the same way — just with meaning instead of geography. Two sentences about Vijay’s political rise will have vectors that sit close together in that space. A sentence about cricket will be somewhere else entirely. The closer two vectors are, the more semantically similar the content.

This is what “semantic search” actually means. You’re not matching keywords. You’re measuring closeness in meaning-space.

The Embedding Model: The Translator

Vectors don’t appear from thin air. Something has to convert raw data — text, images, audio — into those coordinate lists. That’s the job of an embedding model.

You pass it a sentence. It passes back a vector. Same model, consistent space — so two sentences about similar things will always produce vectors that end up close to each other.

OpenAI’s text-embedding-3-large is a popular example. Google, Cohere, and others have their own. The model has been trained on massive amounts of data, so it’s learned how to encode meaning into numbers.

When you ask a question against a Vector DB, here’s the actual sequence:

1. Your query (”How did Vijay become CM?”) goes into the embedding model

2. The model converts it into a vector

3. The Vector DB searches for the most similar vectors it has stored

4. It converts those vectors back into actual content

5. You get results — not keyword matches, but semantically related content

The embedding model handles conversion. The Vector DB handles storage and search. Two different jobs, two different tools, working together.

Why You Can’t Just Brute-Force It

Here’s where it gets interesting — and where the real engineering happens.

Imagine you’ve got 100 million vectors stored, each 1536 dimensions long. A new query comes in. The naive approach: compare the query vector against every single stored vector, one by one, and find the closest ones.

That’s called brute-force search or exact nearest neighbor search. And for 100 million vectors? It’s punishingly slow. You’d be doing billions of floating-point calculations per query. Not viable at any real scale.

Vector databases solve this with approximate nearest neighbor (ANN) search — algorithms that trade a tiny bit of precision for massive speed gains. The most widely used is called HNSW.

How HNSW Works (And Why It’s Smart)

HNSW stands for Hierarchical Navigable Small World. The name sounds dense, but the idea behind it is elegant.

Think about that GPS analogy. If you’re in Chennai and you want to get to Delhi, you don’t walk house by house across India. You zoom out — take a flight or highway — get close to the destination, then zoom back in and navigate the last mile locally. You move at different levels of granularity.

HNSW builds exactly that kind of multi-level structure over your vectors.

It creates multiple graph layers. The top layer is sparse — only a few representative vectors, spread far apart. Lower layers get progressively denser. The bottom layer contains all your vectors.

When a query comes in:

1. Start at the top layer — find the closest vector at that coarse level

2. Move to the next layer down, using that entry point — find closer vectors

3. Keep drilling down through layers

4. At the bottom, do a precise local search among nearby candidates

Each step you only compare against a small number of neighbors. You’re navigating through the space, not scanning it. The result: queries that would take seconds with brute force finish in milliseconds.

To measure “closeness” between two vectors, HNSW uses cosine similarity — a formula that checks the angle between two vectors in multi-dimensional space. Angle near zero? The vectors are pointing in the same direction, meaning the content is semantically similar. Wide angle? Not related.

It’s the mathematical equivalent of saying “are these two things talking about the same kind of thing?”

What This Looks Like End-to-End

Put it all together and here’s a full picture of what happens when you query a Vector DB:

You have a database of, say, 10,000 news articles. Each article was passed through an embedding model and stored as a vector when it was added. The HNSW index was built over all those vectors.

Now you type: “Latest developments in Tamil Nadu politics”

• That query hits the embedding model → gets converted to a vector

• The vector goes into the HNSW index → the graph starts navigating from the top layer down

• At each layer, cosine similarity scores guide which direction to move

• The index identifies the top 10 most similar vectors — in milliseconds

• Those vectors map back to 10 actual articles

• You get semantically relevant results, not just keyword hits

This is what makes every modern AI app tick — RAG pipelines, chatbots, recommendation engines, semantic search. They all lean on this under the hood.

Traditional DB vs Vector DB — The Quick Version

Traditional DBVector DBStoresTables, documentsVectors (embeddings)Finds byExact match, filtersSemantic similarityGood forCRUD, structured queriesAI search, recommendationsUnderstands meaningNoYesSearch algorithmB-trees, indexesHNSW, IVF

They’re not competitors. They’re complements. Most production AI apps use both — a Postgres for structured user data, a Vector DB for the semantic search layer.

Your database isn’t broken. It’s just not built for meaning.

The moment you need software that understands what someone is trying to ask — not just the exact words they used — you need a different kind of storage. One that thinks in coordinates, navigates in dimensions, and finds answers by measuring closeness instead of matching strings.

That’s the whole game. And honestly, it’s a beautiful piece of engineering.

“What AI tools do you use?”

So here’s my actual answer. Not a curated list. Not sponsored picks. Just what I’ve settled on after trying a bunch of stuff, switching around, and wasting time figuring it out.

Before the tools — the mindset

I don’t use AI to replace my thinking.

I use it to

• move faster

• handle the boring stuff

• think through things better.

That’s it. I’m still in control of the actual work.

Okay. Let’s get to the AI tools.

1. Cursor — for coding

This is my main editor. It’s AI-powered, but it still feels like coding — which matters to me.

I’m not just prompting and copy-pasting. I’m still reading the code, tweaking things, debugging manually.

Cursor just sits alongside that and helps when I need it.

I tried Claude Code. Too abstracted for how I like to work. I don’t want to lose touch with what’s actually happening in the codebase.

2. Claude — for thinking and planning

This is where I go when something needs structure.

Not just writing — actual thinking. Script refinement, planning, and breaking down a messy idea into something usable.

One thing that genuinely surprised me is this.

I uploaded three months of bank statements and asked it to build a budget plan. What came back wasn’t generic advice. It broke everything down — investments, family expenses, subscriptions, my editing team costs, where I’m overspending, and where I can cut.

I really needed it, and this is just one example.

That’s how I use Claude — to do all the heavy-lifting tasks that can be automated.

3. ChatGPT — for everyday questions

This is my default tab. Always open.

Not for big tasks. More like having someone to think out loud with. Random questions, learning new concepts, quick research, clarifying something I half-understand.

Recent discussions:

• What BFF actually means in backend architecture (not best friends forever 😄)

• Difference between document and XHR/fetch requests

• Figuring out how to plan my week.

Small stuff, but it adds up.

4. Gemini — for visuals

Honest answer: I mainly use it for Nanobanana.

Headshots, image edits, and color grading. That’s my use case.

Sometimes a quick search, but mostly visuals.

5. Perplexity — for going deeper

When I don’t just want an answer but actually want to understand something, I open Perplexity.

Reading API docs, understanding what a product actually does, and exploring something like the stock market properly. It’s like Google search, but it doesn’t make you do all the work yourself.

6. Ideogram — for image generation

Underrated tool. I use it for Substack banners, LinkedIn posts, and my LinkedIn banner.

The reason I keep coming back: it handles text inside images really well. No broken words, no weird spelling. Just clean output. That’s rare.

Why this setup?

Each tool has one job.

• Cursor → building

• Claude → thinking and planning

• ChatGPT → learning and quick questions

• Gemini → visuals

• Perplexity → deep research

• Ideogram → design

I’m not trying to make one tool do everything. That never works well.

This is just what works for me right now. It’ll probably change. But if you’re building your own setup, hopefully this saves you some of the trial and error I went through.

Start simple. Pick one or two. Figure out what actually fits your work — then build from there.

Literally, perfect timing.

I didn’t realize how lucky I was when I got the offer. But two weeks later? I couldn’t thank the universe enough. That’s when it really hit me.

“Things will happen at the right time — not when you actually want it — just so you value how important it is. The universe has its own way of teaching you life.”

Okay. We can talk philosophy all day. Let’s get into what you’re actually here for — the interview process.

Round 1 — Written Test

Yes. A written test. And honestly? It was more interesting than I expected.

They covered API design, system design, and raw SQL queries — on paper. Writing code with a pen after so long felt oddly exciting. A little nostalgic, even.

You’ll likely see a mix of these:

• General Coding (e.g. Implement Fibonacci Series)

• DSA Questions

• SQL Queries

• API Design

• Database Design

My honest advice: be thorough with your core engineering skills. The fundamentals matter more than you think.

Duration: ~1.5 hours

Round 2 — DSA & Design

More system design, API design, and database design — and less DSA than I expected. They dug deep into the subject with follow-up questions that kept you on your toes.

The best part? They were patient. If you needed to clarify something, they let you. That made the whole thing feel more like a conversation than an interrogation.

Heads up though — this varies. Some interviewers lean heavily on DSA, others on design. It really depends on who you’re talking to and your experience level.

Duration: 1 hour

Round 3 — Architecture Design

This round was less about testing new knowledge and more about going deep on what you’ve already worked with — system architecture, tech stack decisions, system design, scalability.

Essentially: did you actually understand what you built? Did you ask the right whys along the way?

Also, be ready to talk about AI. There was a question on it, and honestly I think that’s becoming standard across most interviews right now.

Duration: 45 minutes

Round 4 — The Most Intense One

This was the most intense round of all — but you know what, I actually enjoyed it.

Heavy problem-solving, system design with edge cases, database design — and follow-up after follow-up to make sure you’d thought of everything.

It wasn’t just “here’s a problem, solve it.”

It was: how do you approach it? How do you implement it without hurting the user experience? How do you keep it scalable?

If you love thinking through hard engineering problems, you’ll actually have fun here. I did.

Duration: 45 minutes

Round 5 — Culture Fit

This one feels more conversational — but it’s still pretty engineering-heavy.

They want to hear you explain the architecture you’ve worked on: what it is, why you used it, and what problem it solved. They’re trying to gauge how well you know the tools and technologies you’ve actually used — not just whether you can name-drop them.

And yes, AI came up again. How much do you understand it? What tools have you used? How proficient are you?

Duration: ~45 minutes

So, that’s the full picture:

1 Written Test → 3 Technical Rounds → 1 Culture Fit Round. 5 rounds total.

And overall? A genuinely great experience. I walked away from each round having actually enjoyed it.

If you’re preparing for something similar — understand the things you’ve worked on deeply, sharpen your core engineering fundamentals, and don’t underestimate how much AI fluency matters right now.

Hope this helps someone out there.

Good luck — and remember, the timing might just be better than you think. 🙂

Got questions or doubts? Feel free to reach out — I’m always happy to help. business@naveenrkcreates.com

I just saw this girl on Instagram, talking about how engineers are the hottest guys she could ever find. I was confused because I am an engineer and……. (Realized not to think any further)

But that’s the reality. I see a lot of software engineers, hitting the gym every day, very conscious about what they eat, talking about their fitness routine all the time, and they are quite obsessed with it.

After thinking for some time, I got to know 5 healthy reasons.

1. Coping Mechanism → An engineer’s life is stressful. It’s never 9-5. So, the workout turns out to be a healthy coping mechanism. It used to be p*rn, stress eating, and all kinds of cheap pleasures. But now, it’s working out, and I feel proud of us.

2. Builds Confidence → Your appearance plays a role in your confidence. You need to perceive yourself as confident if you want someone else to do so. Looking good and having a structured physique in the mirror is one of the best ways to build confidence.

3. Flow State → You enter a different state when you enter the gym. Your mind shuts down. You focus only on your breadth, muscle contractions, and the hot girl at the gym. No distractions! You will be in a flow state.

4. The Domino Effect → If you go to the gym regularly, putting in your best effort, you don’t want to waste all that by eating sh*t. You prioritize your food intake & your sleep for recovery, you then build discipline, focus a lot better at work, it builds confidence, you feel good about yourself & so on.

5. The post-workout feel → I can’t explain this. The feeling you get after an intense workout is just…… You just have to feel it yourself. Seriously!

I believe these are some of the reasons that encourage people to hit the gym regularly.

I do hit the gym and believe it or not, the post-workout feel is just blissful. You feel really good. If you can afford to take a nap after that, that’s even better.

A good ideal day should be:

• 6:00 AM - Wake up

• 6:30 AM → Hit the gym

• 8:00 AM → Skin care routine

• 8:30 AM → Breakfast

• 9 AM to 5 PM → Work

• 6:30 PM → Personal Work (For Me: Content Creation, writing this article at 10:37PM & building my dream life)

• 9:30 PM → (READ or SCROLL or WATCH something) & Skin care routine

• 10:30 → Sleep

You do that every day. You life has no choice but to get better. 100%

What do you think you are being paid for as a software engineer, now?

Coding, AI. Right?…. You couldn’t be more wrong.

The thing is, it was never coding. You were/are hired to solve problems, and coding is just a way to do that. You are more responsible for understanding problems and offering comprehensive, reliable solutions. That’s where your problem-solving, system design, and core engineering skills come in.

So, this has been the expectation from the companies all along, if you didn’t know that by now.

But now, they expect much more than that.

That’s where being just a good software engineer doesn’t help anymore.

You need to be a product engineer. Here’s how

1) Coding is the easiest part now!

Writing code has always taken you quite a lot of time, right?

You have the requirements. You know what to do, but it still takes time. You need to first implement the requirements, fix the bugs, optimize the code, follow best engineering practices, and then you have to test the functionality and so on.

But now, with AI, you can do the same work in almost half the time.

You don’t need to keep searching on Google or Stack Overflow anymore, especially if you’re using tools like Cursor or Claude. We’ve clearly reached that stage.

The important thing is — you need to realize this. Because companies already have.

They now expect you to do much more than just write code.

2) Focus more on the strategic part!

Again. The billion-dollar question. What are you being paid for?

Strategic Thinking

This is what really matters now — your core engineering skills. Things like system design, architecture, writing clean code, optimizing it, doing proper research, and understanding trade-offs to pick the right solution for a problem.

That’s what companies are actually looking for.

It has always been important, but not all companies have focused on it before. Now, you can’t survive by just writing code anymore. Here are the ways you can get better at the strategic part:

• Learn how to design systems at a large scale → System Design

• Understand tradeoffs among multiple solutions - What suits and what doesn’t

• Writing clean and optimized code.

• Research and go in-depth on engineering concepts

• Read a lot of engineering blogs.

  ByteByteGo Newsletter

  Explain complex systems with simple terms, from the authors of the best-selling system design book series. Join over 1,000,000 friendly readers.

  By Alex Xu

3) Go In-Depth

Let me be honest — if you think you can crack interviews just by grinding LeetCode, that’s not enough anymore.

You need to go deeper into engineering.

Like, can you actually build an app from scratch? Do you understand things like caching, databases (not just using them, but writing SQL), a bit of DevOps, and how deployment works?

Also, you should be comfortable using AI tools.

Hiring has slowed down due to AI and excessive funding, so companies just hire people who already have strong basics and know things. It’s just easier for them to hire someone who can build and ship fast instead of training them.

So yeah, if you want better chances, focus on getting really solid with your fundamentals.

4) Understand Product/Service & Customers

Yeah! I know you will be wondering, “Why??????“. I get it, I did that too

Every company or startup has two main goals: increase revenue and reduce costs.

So how can you, as an engineer, help with that?

Let’s take a simple example. Imagine a customer request worth $4000 that needs to be done in two weeks. It sounds a bit complex.

First, you understand the requirement clearly. You talk with the product and design teams to make sure you know what’s expected. Then you research different ways to solve it, look for possible approaches, identify blockers, resolve them and choose the best approach.

While building it, you also think about costs — like storage, servers, or using AI tools. If the solution becomes too expensive, you discuss it with the product team and adjust if needed.

To do all this well, you need to truly understand the product:

• What problem are you solving?

• Who is the customer?

You’re not just writing code anymore. You’re building something for real users. When you understand both the product and the customer, you can create better, cleaner, and more useful solutions — and that’s what makes you stand out.

And that’s what is expected from you.

5) Own the product/service

Companies are not gonna be hiring you to do the basic stuff like fixing bugs anymore, especially in a startup environment.

You will be given a feature or enhancement to work on, and you need to own it end-to-end. Any questions or issues related to it — you’re responsible. Hence, product knowledge will play a key role here as well.

It’s actually a good thing. When you take ownership, you start caring more about what you’re building. It shows your managers that you can be trusted with bigger responsibilities.

The only way to prove that is by taking ownership and getting things done well and on time. It also gives you a strong sense of satisfaction, knowing your work is making a real impact.

6) Learn how to use AI efficiently

Anyone can use AI now. You don’t really need someone to teach you — it’s pretty straightforward.

But the real question is:

• How do you use it without spending too many tokens or credits?

• Which model should you use for each task?

• How can you use AI tools efficiently?

• How can you save costs?

• How can you automate your work with AI?

That’s what actually makes you stand out. Not many people focus on this.

Just research about it, experiment with it, understand how it works and you will slowly get better.

If you can do all that well, you’re GOLD.

So yeah, things have clearly changed.

It’s no longer just about writing code and getting tasks done. It’s about thinking deeper, understanding the product, using AI smartly, and actually solving real problems.

If you start focusing on these areas, you won’t just be another developer — you’ll be someone who truly adds value.

And that’s exactly the kind of engineer companies are looking for now.

In simple terms, Product Engineer → Engineering + Product + AI

Here’s every tool, what it does, and why you need it.

1. Cursor — Coding

Cursor is a code editor that seems like it’s built only with AI in mind. Instead of Googling syntax or copying Stack Overflow answers, you just describe what you want — “add a login page with Google sign-in” — and Cursor writes it. It reads your whole codebase, so suggestions actually fit your project.

Tip: Next.js as the framework and ShadCN for pre-built UI components — buttons, forms, modals, all of it — so you’re building, not designing from scratch.

Use it for: Everything for building the application from scratch.

2. Supabase — Simplified Backend

Supabase gives you a database, user authentication, and file storage — all without writing a backend from scratch. It runs on PostgreSQL (the most-trusted & most loved database, at least I love it) and comes with a clean dashboard for managing all your data.

Sign-ups, saved data, uploaded files — it all lives here.

Use it for: Storing data and handling user accounts. A simplified low-code version of a backend.

3. Stripe — Payments

Stripe is how the internet takes payments. Credit cards, Apple Pay, subscriptions, one-time purchases, refunds — it handles all of it. You never touch your users’ card details; Stripe deals with all the sensitive stuff and so you don't have to deal with any legal issues. Your job is simply to integrate Stripe into your app.

Use it for: Any time you want to charge someone money.

4. Resend — Emails That Don’t End Up in Spam

Every app sends emails — welcome messages, password resets, receipts. Getting those to actually land in the inbox (and not spam) is harder than it sounds. Resend is built specifically for developers, takes minutes to integrate, and has a well-known reputation for ensuring emails arrive in the inbox.

Use it for: Any automated, transactional email your app needs to send.

5. PostHog — Analytics

After you launch, the real question is: are people actually using it? PostHog tells you. It records user sessions, tracks clicks and page views, shows you where people drop off, and lets you run A/B tests. You can literally watch a replay of someone navigating your app.

Use it for: Understanding user behavior and making decisions based on data and generating end-user analytics as well.

6. Inngest — Background Processing (Queues)

Some tasks shouldn’t make a user sit and wait — processing a video, sending a batch of emails, retrying a failed API call. Inngest takes those jobs off the main process and runs them quietly in the background. It also handles scheduled tasks, like “run this every night at 2am.”

Key Feature: The problem with long-running tasks is that if a 10-minute job fails at minute 9 — network issue, API timeout, server restart — you have to start from zero. The data is lost. Step functions solve this by checkpointing (breaking down a single function into multiple step functions).

Use it for: Anything slow, scheduled, or that needs to retry automatically if it fails.

7. Vercel — Ship it!

Vercel hosts your app. You connect your GitHub (It’s a must; you need a version control system) repo, push your code, and it’s live. Every update you push redeploys automatically. Since Vercel is built by the same team behind Next.js, the two work together perfectly — Deployment is relatively much easier with zero configuration.

Use it for: Deploying and hosting your Next.js app.

8. Namecheap — Your Domain

This is where you buy your domain — yourstartup.com. It’s affordable, no-nonsense, and doesn’t spam you with upsells. You buy it, point it at Vercel, and your app has a real address instead of a random “.vercel.app” URL that Vercel provides.

Use it for: Day one. Buy the domain before someone else does.

9. Sentry — Error Tracking ✦

Sentry watches your app 24x7. The moment something crashes, it tells you exactly what broke, which line of code, and which user was affected. Without it, you find out your app is down when someone complains. With it, you’re already fixing it before they notice.

Use it for: Error monitoring from the day you go live.

10. Pinecone — AI ✦

Think about how Google works. You don't type exact words from a webpage — you describe what you're looking for, and it figures out what you mean. That's the kind of intelligence Pinecone brings to your app.

If you’re building anything AI-powered — smart search, “chat with your docs”, recommendation systems — you need Pinecone. It stores data as vectors, which are mathematical representations of your pre-defined text. So a search for “budget travel in summer” doesn’t just match those words — it finds everything semantically related to that idea, so it can generate. Makes sense?

Use it for: AI search, recommendation systems, RAG pipelines, and any feature that needs to understand meaning, not just match text.

How It All Fits Together

A user finds your domain (Namecheap) → hits your frontend (Cursor · Next.js · ShadCN) → served from (Vercel) → signs up via (Supabase) → gets a welcome email through (Resend) → pays via (Stripe) → their behavior is tracked by (PostHog) → background jobs run through (Inngest) → errors caught by (Sentry) → AI features powered by (Pinecone)

Ten tools. Each one does exactly one thing. Together, they give a solo developer the combined power of a full engineering team.

Now time to build that idea of yours.

✦ Optional but highly recommended · Stack: Next.js · ShadCN · Supabase · Stripe · Resend · PostHog · Inngest · Vercel · Namecheap · Sentry · Pinecone

Few years back, WhatsApp Web did nothing but just serve the chats from your WhatsApp application into your browser — Like mirroring. That’s it.

So, WhatsApp Web used to be completely dependent on your phone. If your phone were offline, WhatsApp Web would stop working too.

But now it’s different. It’s entirely dependent except for the authentication part.

1. QR Code Authentication

The first thing you see when you visit WhatsApp Web is a QR code.

What the heck is this QR code??

Behind the scenes, the browser immediately connects to the Whatsapp servers by opening a websocket connection. It’s a two-way connection protocol where the client can send messages to the server, and the server can send messages to the client.

Now, the server returns with the temporary login session details (Ex: session_id, login_id, device_id) which is then encoded into a QR Code format. That’s what you see on the screen.

This basically says, your browser is ready to connect to anyone’s whatsapp account.

2. Linked Devices - Scanner

When you visit the “Linked Devices” from your WhatsApp application, you open up the QR Code Scanner, which is responsible for authenticating Browsers or other sources to give access to your WhatsApp account.

Behind the scenes, when you scan the QR, the WhatsApp application decodes the QR, gets the details, and requests the WhatsApp server to approve the browser’s access.

Then the WhatsApp server links your browser to your WhatsApp account, hence you see it in the linked devices.

Then, through the same web socket connection, Whatsapp Server sends the login credentials to the respective browser & the browser logs you in.

That’s literally the whole process.

If you have experimented with ClawdBot, it pretty much does the same thing. Nothing fancy. To connect to WhatsApp, it displays a QR code, and then you scan it from your Linked Devices. The same process happens behind the scenes.

Here are some follow-up questions you can ask yourself!

1. Why use QR? Why not just use a simple OTP-based login like Instagram?

2. Can any QR code scanner work on this QR code, or just the WhatsApp app’s scanner?

Strategic Thinking? Problem Solving? Reasoning?…. Nope!

Let me explain. This will be interesting. So stay with me till the end.

As a developer, you spend around 8 to 12 hours in the office. And if you are a nerd with an inability to say “NO“, you will probably be spending 16 hours in the office.

But what tires you the most? Writing Code? Meetings? Coffee Breaks?…. Not at all.

You spend 80% of the time coding, and the remaining 20% is actually the thing that makes you tired at the end. It’s your effort in coming up with various approaches to solve a specific problem at hand, assuming you actually put in the effort.

In other words, STRATEGIC THINKING.

So, 80% Coding & 20% Strategic Thinking.

Now, in this AI era, what do companies actually expect from you?

Modern LLMs like ChatGPT and Claude are trained on massive amounts of content — Stack Overflow, blogs, research papers, thousands of GitHub repos, and more. Because of this, they’re extremely good at recognizing patterns. That’s why their answers usually make sense.

So we can safely say: AI is really good at implementation.

It can understand your codebase reasonably well and generate acceptable solutions.

In many ways, it automates a big chunk of the work — writing code.

But what it still struggles with — and likely will for a few more years — is thinking in terms of:

• Scalability

• Reliability

• Reducing redundancy

• Choosing the right design patterns

• Managing trade-offs

That’s where you come in.

The strategic part: analyzing impact, exploring different approaches, designing systems and architectures, researching, and making decisions.

AI can help with the 80% - The Implementation

You focus on the thinking - the 20%

That’s the real value now.

And sometimes, I even turn off agentic mode and code by myself.

Honestly… it feels good.

Now, here’s where you might think you’re screwed.

Companies have realized this.

They strongly believe that AI writes better code and that it writes faster.

Result? Tight deadlines, more features shipped in a month, fewer bugs & of course, fewer employees.

And we can’t blame them.

Their competitors are employing AI to speed up the work and in their products. So they have no choice but to do the same — More & More AI.

They just want you to write code faster and ship it, whether you use AI or not.

If AI takes care of writing code — The implementation, then what are you paid to do?

Simple, it’s STRATEGIC THINKING

Your ideas, your research, your learnings — That’s what matters.

If you are being hired, that’s what you are expected to do.

Makes sense?

But you know what? You don’t have to worry too much.

If you think about it, it has always been this way.

You were never hired just to write code. You were hired to solve problems — coding is simply the tool.

That’s exactly why interviews focus on DSA and System Design. They don’t really care which language you use. What they’re evaluating is your thinking — how you approach a problem, how you reason about it, and how strong your fundamentals are.

If that part is solid, you’re good.

So the point is simple: in this AI era, companies are looking for problem solvers — people with deep knowledge in a domain who also know how to leverage AI to get things done.

In my opinion, that’s what you should aim for.

Expertise.

Build that, and you’ll be just fine.

OpenAI just saw a massive 200% uninstallation rate, all because of a major conflict between Anthropic & the US Government.

Not to mention, haters even started a “Quit ChatGPT“ protest.

In July 2025, Anthropic signed a $200 Million agreement with the US Government for the use of Claude and its AI capabilities in their government services and classified networks.

The agreement had two important guardrails — security restrictions.

1. Don’t use Claude for mass surveillance

2. Don’t use Claude for weapon development.

That’s it.

Now, recently, the government claimed that they conducted a secret operation to capture the Venezuelan president with the help of Claude tools. But there’s no specific mention of how they utilized it.

My guess is that they must have used it in their surveillance technologies.

Here comes the conflict.

Realizing the potential and the power of Claude, the U.S. Department of Defense (Pentagon) wanted Anthropic to drop the restrictions from the contract.

When asked, the Pentagon said:

• They are not planning to do mass surveillance or weapon development without a human in the loop right now

• But they just don’t want to be restricted by the contract.

But Anthropic refused to drop the safeguards, claiming that it was not part of the original agreement and it should not be now.

So, the Pentagon sent a revised agreement that would allow the government to override safety safeguards whenever it wanted, which is not so good.

But, Anthropic standing true to their ethical standards, rejected the revised agreement, saying that they would rather happily walk away from the contract than be part of something that promotes mass surveillance or weapon development.

Then it turned into a threat.

Pete Hegseth (the U.S. Defense Secretary) gave Anthropic a deadline.

He basically said:

• Agree to let us use your AI without any restrictions, or we’ll cancel the contract.

• We might officially label you a “supply chain risk” (which makes it harder for you to work with the government).

• We could use a powerful law called the Defense Production Act to force you to give full access to your technology if needed.

Despite the pressure, Anthropic refused to remove its two safety protections.

So the administration (under Donald Trump) decided to:

• Start cutting ties with Anthropic across U.S. government agencies.

• Gradually remove their systems from Pentagon use.

• Look for other AI companies willing to accept their conditions.

This is where OpenAI enters.

Right after this incident, OpenAI initiates a conversation with the government and signs a new agreement, agreeing to what the government is asking for.

Literally the next day, there’s a huge spike in the uninstallation rate of ChatGPT of up to 200%. Earlier, they just had 9%.

Clearly, people were supporting Anthropic’s decisions in this matter. Anthropic did nothing wrong. They wanted to stay true to their ethical standards, and people respected that.

But now, when OpenAI signed a similar deal that Anthropic refused, OpenAI is now being hated.

People started uninstalling OpenAI just like that and shifted to Claude instead, whose installation rate just spiked!

This surprisingly led to the “Quit ChatGPT” protest.

Didn’t expect this, by the way.

Okay, so this is the whole story. OpenAI’s reputation was already slightly sinking due to the release of ChatGPT Ads, but this would definitely drown it.

From a common perspective, what do you think?

Later, I came to know that the recommended setup process (the cURL command) by OpenClaw had bugs.

So people are suggesting going with a different installation setup, which is seamless.

npm i -g openclaw@2026.2.17

This exact version seems to be right! No issues as explained in the GitHub Issue

Don’t worry! I am going to explain with this type of installation.

First, let me give a surprising fact about OpenClaw.

OpenClaw is not an AI tool. The name, how they portray it, and how the social media influencers are explaining the tool. These things make us believe it’s AI, but it’s not.

In simple words, it’s a message-orchestrator platform. It’s the platform that connects with various tools include AI, to perform actions by sending messages to the respective integration or AI. That’s it!

Here’s what it does:

1) Acts as a Persistent AI Assistant:

It does this by making API calls to pre-existing models and answering you, just like any other ChatBot (Claude, OpenAI, etc)

2) Automates Real-World Tasks:

This is where the real power comes in!

• Manage your email and calendar

• Send daily AI updates at exactly 8 AM by researching the web

• Create, Read, Modify your local files

• Integration with Slack, Notion, WhatsApp, Telelgram or any integration just via the chat interface and build a whole automation platform.

You might be thinking, “What doesn’t it do?”

3) OpenSource:

It can be self-hosted. Can run anywhere. On your system, AWS EC2 instance, or probably a separate MAC MINI (That’s what people are doing these days)

So, with that said, let’s get to the setup guide.

Setup Guide

Just know these 2 terminologies! - Gateway & Channels

Gateway: It’s the bridge between OpenClaw & the external world. Without it, OpenClaw can’t send or receive data from anyone.

Channels: Messaging platforms(Slack, Telegram, WhatsApp) where you can talk to or listen to the chats via Gateway.

1) Install Node version 22

nvm install 22

// Then use the node 22 version
nvm use 22

2) Install OpenClaw

npm i -g openclaw@2026.2.17

The Result:

You should be seeing this!

Run the command below to check if it’s installed successfully.

openclaw --version

3) Onboard OpenClaw

openclaw onboard

This will take you through a series of steps.

You are on your own, buddy! It’s risky, but it’s worth it. Choose “Yes“ and continue.

Next, you will be prompted with QuickStart or Manual. Choose “Manual” — Let’s learn.

Choose Local Gateway - Will be running on your localhost.

Workspace Directory - This is where OpenClaw stores all your sessions, data, etc.

Next, the model providers. Connect your favourite model or the one you can afford. I choose Moonshot (Kimi K2.5)

Note: Keep in mind that the API calls made by OpenClaw to the models consume a lot of tokens. So, just be cautious.

Purchase a $5 credits from Claude for the best results. Anthropic is the best for OpenClaw.

Don’t worry - I will deactivate this API key, so don’t even think of stealing it.

The following steps are simple! Just choose as it is in the image.

We need an authorization to connect to the gateway. Choose “Token”

Turn this off!

Just click “Enter“ - It will generate its own token.

You can find it here ( ~/.openclaw/openclaw.json ).

In Windows, it should be (C:\Users\<YourUsername>\.openclaw\openclaw.json)

Skip all the following steps now. Btw, this is the Channels.

Highly, highly recommended. Install the Gateway Service and choose Node.

Oh! You want to see OpenClaw in UI. Here it is. Choose “Web UI“. TUI is

Then you should be seeing this in your terminal.

And this in your browser

That means. The setup is complete. Good Job.

The UI is serving from the gateway and is always running in the background, along with OpenClaw.

Now, you can chat with this.

Connecting to WhatsApp

Run the following command

openclaw channels add

You will see the options below. Click “Yes“

Select “WhatsApp“ Channel. And

Then, you will be prompted with a QR. It’s the same mechanism as WhatsApp Web.

You go to your WhatsApp, choose “Linked Devices“ from settings, and scan this QR, and you will be connected.

Then enter your number, and you are pretty much done.

Enter your number. Ensure it’s in this format - +917358343424 — Your country code followed by your number with no spaces.

After it’s done. Go to the UI, refresh it.

Click on the “Config” tab on the bottom-left. Click on the “Channels” within settings. Then you will see your WhatsApp connected. That’s it.

From the chat interface, you can now ask OpenClaw to send messages. It will do.

OpenClaw doesn’t use any API to send WhatsApp messages. It works in the same mechanism as WhatsApp Web.

That’s it.

You are now officially an OpenClaw developer.

We can do a lot more.

You’re a student trying to figure out why your code isn’t working. So you open Google, type in your doubt, and spend the next 45 minutes going down a rabbit hole — Stack Overflow, MDN docs, some random blog from 2015 that somehow explains it perfectly. It’s a little painful. But by the end of it? You get it. Like, actually get it.

Now picture 2025.

Same problem. You open ChatGPT, type the question, and get a clean answer in 10 seconds. Done.

Faster, right? Sure. But here’s the thing — Are you actually learning?

I came across this post on Reddit recently. A senior engineer at a FAANG company was venting about the new grads on his team.

He noticed that about 90% of their code looked like it was straight out of an AI prompt. When he sat down with them one-on-one, things got worse. One of them didn’t understand that a JavaScript function could return another function. Another couldn’t explain why he wrote the code he did — because the code had nothing to do with the feature he was building.

These weren’t bad students. They cracked FAANG interviews. That’s no joke. But when it came to real work? They were lost.

This is what I call shallow knowledge — and it’s quietly becoming an epidemic.

Surface vs. Core

There are two kinds of knowledge.

Shallow knowledge is when you know what something does but not how or why. You can use it, but you can’t think with it. The moment something breaks or goes out of context, you’re stuck.

Deep knowledge is when you understand the fundamentals so well that you can apply them anywhere — even in situations you’ve never seen before.

Those new grads? They had enough shallow knowledge to pass interviews. But they didn’t have the deep knowledge to survive on the job. They couldn’t review AI-generated code. They couldn’t catch when it was wrong. They couldn’t explain their own PRs.

And honestly, it makes sense. If you’ve never had to struggle through understanding something — if the answer always came before you even felt the pain of not knowing — why would your brain bother building those deep foundations?

What We Lost in the Shortcut

Here’s the thing nobody talks about: the struggle was the learning.

When you used to Google something, you didn’t just find an answer. You read three wrong answers first. You tried something, broke it, tried again. You built intuition — that quiet, background sense of how things work that kicks in when you’re stuck at 2am and Stack Overflow has nothing.

AI skips all of that. And in doing so, it quietly takes away the most important part of learning — the curiosity to figure things out.

When answers are instant, questions stop feeling interesting. And when questions stop feeling interesting, learning stops.

So... Is AI the Problem?

No. I want to be clear about that.

The problem isn’t AI. The problem is how we’re using it.

Think about it this way. Before, you’d search Google and visit a bunch of links to understand something. Now, you go to ChatGPT instead. The tool changed, but the approach doesn’t have to.

The question is: are you using AI to find answers, or to understand them?

There’s a big difference. If you get an answer and move on — you’ve found it. If you get an answer and then ask “wait, why does that work?” and keep digging — you’re understanding it.

One builds shallow knowledge. The other builds deep knowledge. The tool is the same. The choice is yours.

The Right Way to Learn in 2026

Use AI. Seriously, use it. It’s an incredible resource. But treat it like a really smart tutor, not like a copy-paste machine.

When you’re learning something new — don’t just take the first answer. Ask follow-up questions. Break things on purpose. Try to explain the concept back to the AI and see if it corrects you. Go down the rabbit hole, just with a faster guide.

The fundamentals still matter. Variables, functions, how data flows, why systems are built the way they are — these things don’t change just because AI can write the code for you. If anything, they matter more now, because the only thing that separates a good engineer from an AI is the ability to think about the problem.

The graduates in that Reddit post didn’t fail because they used AI. They failed because they used it to skip understanding. Don’t make that mistake.

The fastest way to learn has always been to actually care about how things work. AI just lets you do that faster now — if you let it.

A man was rushed to the hospital after a heart attack.
Four hours later, in the emergency room, he passed away.

Everything happened too fast.
There was no time to process the loss. The family was still in shock.

And then, days later, another shock arrived.

The Bill That Changed Everything

The hospital sent the final medical bill.

$191,000.

The number didn’t even feel real.
For many families, that amount is a lifetime of savings.

But the problem wasn’t just the amount.

It was the question that haunted them for days:

“Did it really cost this much?”

Something Felt… Off

At first, the family tried to accept it.
Hospitals are expensive. Emergency care is complex.

But curiosity turned into suspicion.

They went through the bill line by line.

The charges were long.
The descriptions were vague.
Many pages, but very little clarity.

One line stood out:

Cardiology Services – $70,000

No explanation.
No breakdown.
Just a massive number.

That’s when the family knew something wasn’t right.

Asking the Right Questions

The family requested the billing codes used for each procedure.

In the U.S., hospitals usually bill using standard medical codes (like CPT and HCPCS codes). These are the same codes Medicare uses to decide what it will pay for.

The hospital responded with something unusual:

“We use custom internal codes for many procedures.”

That raised even more red flags.

So the family pushed further. They asked:

• What are the custom codes?

• What are the equivalent Medicare codes for each one?

That’s when the excuses started.

Months of Excuses

The hospital delayed for weeks.

Then months.

They blamed:

• Computer issues

• Missing records

• Internal audits

Honestly, the kind of excuses you’d expect to see in a movie.

But eventually, after constant pressure, the hospital handed over the codes.

That’s when the family did something unexpected.

Enter AI

They took:

• The full hospital bill

• The procedure codes

• Medicare billing rules and guidelines

And fed everything into Claude AI.

Then they asked one simple question:

“If this case were billed under Medicare rules, how much would Medicare actually allow?”

The answer was shocking.

What the AI Found

The AI didn’t guess.
It followed public Medicare billing rules.

Here’s what stood out.

1. Improper Unbundling of Procedures

Under Medicare rules, many smaller procedures are bundled into a larger one.

That means:

• You bill for the main procedure

• You do not bill separately for included sub-procedures

But the hospital did exactly that.

They billed:

• The main cardiology procedure

• And multiple bundled sub-procedures separately

This alone inflated the bill by tens of thousands of dollars.

2. Duplicate Charges

Some procedures appeared more than once.

Same code.
Same description.
Same service.

Billed twice.

This is one of the most basic billing errors — and yet, it happened.

3. Overbilling for Mechanical Ventilation

The hospital billed for mechanical ventilation as if it was used continuously.

But records showed:

• The patient was not on a ventilator the entire time

• In some periods, the ventilator was on standby

• In others, the patient was breathing on their own

Under Medicare rules, ventilation is billed based on actual usage time, not assumptions.

The Real Number

When the AI calculated everything according to Medicare’s allowed amounts and rules, the total came out to around $33,000.

Not $191,000.

Taking Action

The family didn’t post on social media.
They didn’t argue emotionally.

Instead, they used AI to:

• Draft a formal legal notice

• Cite specific Medicare billing violations

• Demand a corrected bill

• Threaten legal action if the hospital refused

Weeks passed.

Then the hospital responded.

The Outcome

The hospital revised the bill.

The final amount?

$33,000.

The family saved $158,000.

Not through connections.
Not through luck.
But through information.

The Real Lesson

This story isn’t about hospitals being evil.
And it’s not about AI being magical.

It’s about asking better questions.

AI didn’t invent new rules.
It simply:

• Read the fine print

• Applied existing regulations

• Did the work humans rarely have time to do

For $20, the family gained clarity, confidence, and leverage.

Final Thought

AI isn’t just for writing code or generating images.

Used correctly, it can:

• Expose hidden errors

• Protect people from financial harm

• Turn confusion into clarity

This is how AI should be used.

Efficiently. Responsibly. And for good.

If you’re using Cursor or any AI code editor, you’re probably doing it wrong. And I say this as someone who uses it every single day.

You know the drill: paste a prompt, hit Enter, watch the magic happen, smash that “Accept All” button without reading a single line. Boom. Feature shipped. You’re a 10x developer now, right?

Wrong.

Here’s the uncomfortable truth:

you’re slowly turning your brain into mush.

But here’s the good news—it doesn’t have to be this way. You can use AI to actually become a better developer, not just a faster copy-paster. And that’s exactly what this guide is about.

Problem #1: Your Brain is Getting Lazy (And It’s Not Your Fault)

Here’s what nobody tells you about “vibe coding.”

When you let AI handle everything, you’re not just saving time. You’re literally rewiring your brain to be worse at coding.

I know that sounds dramatic, but here’s the neuroscience version: when you don’t actively solve problems, your brain stops building neural pathways. It’s like a muscle. Stop using it, and it weakens.

You lose three critical abilities:

1. Critical Thinking — You stop analyzing problems deeply. You just throw prompts at the wall and hope something sticks.

2. Patience — You expect instant solutions. That 10-minute debugging session? Unbearable now.

3. Focus — Complex tasks become impossible. Your attention span shrinks to the size of a TikTok video.

And then? Burnout. You get fed up with coding entirely.

The fix is simple (but not easy): learn first, implement after.

Yes, it takes a few extra minutes. But here’s what you gain:

• You know exactly what you’re building

• When bugs appear (and they will), you know where to look

• You’re actually learning, not just shipping features

Think of it this way: would you rather be a developer who can build anything, or someone who can only build what AI tells them to build?

How to Actually Learn With AI (Ask Mode)

Here’s where things get interesting.

Any AI code editor can be your personal tutor—if you use it right. Cursor has a feature called “Ask Mode” that’s criminally underused.

Instead of applying changes to your code, it just... answers your questions. Like a senior dev who has infinite patience and never gets annoyed when you ask “why” for the 47th time.

Let me give you real examples:

Example 1: You’re building a Medium clone. Each article needs two versions—a draft and a published one. Readers see the published version; you edit the draft. Once you’re done, you publish the changes.

Instead of asking Cursor to build this, ask: “How should I architect a dual-version article system? What are the tradeoffs of different approaches?”

Example 2: Your codebase uses Kafka, Clickhouse, Redis, session-based auth, Postgres, and Docker. Your manager says, “Understand these before touching the code.”

Instead of Googling each one, ask Cursor: “Explain how Kafka works in our codebase. Why did we choose it over alternatives?”

Example 3: You see this in your codebase: “Don’t use ‘return await’ in async functions.”

Your brain: “Why tho?”

Ask Mode: Perfect use case.

Here’s my workflow:

1. Before building a feature, ask how it should work

2. Keep asking follow-up questions until it clicks

3. Ask about alternative approaches and why they’re bad

4. Understand the tradeoffs

Then—and only then—do you start coding.

This isn’t slower. It’s smarter. You’re building knowledge, not just features.

Planning Like a Senior Engineer (Plan Mode)

Let’s get something straight: writing code is the easy part.

Programming languages are just tools. The hard part—the part that actually makes you valuable—is solving problems and preventing future ones.

How? Planning.

A great developer isn’t someone who codes for 12 hours straight. It’s someone who thinks for 2 hours and codes for 30 minutes, building systems that won’t explode in production.

Enter Plan Mode.

When you’re building something that touches multiple files (which is basically everything), you tell Cursor what you want to build. It then creates a .md file with every single task it’s about to execute.

Here’s what makes this powerful:

• You see the complete strategy before a single line changes

• You catch issues before they happen

• You understand the “why” behind each change

• You can switch to Ask Mode to dig deeper into any step

Once you’ve reviewed and approved the plan, you click “Build” and watch it execute.

The .md file auto-deletes after. Clean and simple.

Pro tip: Don’t skip the review. This is where you learn system design, not from a textbook.

Debugging Without the Pain (Debug Mode)

Ah, debugging. The thing that makes developers question their career choices at 2 AM.

You’ve been there: stuck on a bug for three days, only to discover it’s a missing semicolon or a typo in a variable name. Soul-crushing doesn’t even begin to describe it.

Debug Mode is designed specifically for this nightmare.

Here’s how it works:

1. Paste the error from your terminal (or describe the bug)

2. Cursor identifies the root cause

3. It adds logs to your codebase to trace the issue

4. It reads those logs, pinpoints the problem

5. It fixes it

What would take you days now takes minutes.

I’m not exaggerating. This feature alone has saved me dozens of hours.

When to Actually Use Agent Mode

Agent Mode is the “just do it” button. You prompt, it codes, and changes apply directly.

Most people live here. That’s the problem.

Here’s when Agent Mode is actually perfect:

• Adding/removing logs across multiple files

• Checking for unused functions

• Adding try-catch blocks everywhere

• Writing boilerplate code

• Simple, repetitive changes

For everything else? Stick with Ask, Plan, and Debug. Those modes force you to think, understand, and grow.

Agent Mode is for automation. The others are for education.

The Secret Weapon: Cursor Rules

Most developers ignore this feature. Big mistake.

Cursor Rules tell the AI what standards to follow before answering or making changes.

Think of them as your team’s coding constitution.

Example rules:

• Never use “return await” in async functions

• Always wrap async functions in try-catch

• Move private functions to a separate {file}-private.service.ts files

Cursor has three levels of rules:

1. Project Rules (Codebase Level) Stored in .cursor/rules folder. Version-controlled. Team-wide. You can push this to GitHub so everyone benefits.

2. User Rules (Account/Global Level) Found in Settings → General → Rules for AI. Apply to every project you work on.

3. Team Rules For Team/Enterprise plans. Manage rules across your entire organization.

Set these up once, benefit forever.

Choosing the Right AI Model

When it comes to coding, there are only two models that matter:

• Claude Opus 4.6 (or latest version)

• Claude Opus 4.5

• Claude Sonnet 4.5

Always prefer Claude models. They’re very powerful.

Here’s my strategy:

• Complex tasks, refactoring, architecture decisions → Claude Opus 4.6

• Simple implementations, boilerplate, quick fixes → Claude Sonnet 4.5

If you’re hitting monthly limits on Opus, this split will extend your usage significantly.

Also, you will have 3 different variations of the same model

• Claude Opus 4.5 (Normal)

• Claude Opus 4.5 (Thinking)

• Claude Opus 4.5 (Fast + Thinking)

As you move down, the cost consumption increases. So, always prefer Normal for 80% of the tasks and Thinking for the difficult tasks.

I personally didn’t feel the need to use Fast + Thinking. But it’s up to you!

Leave a comment

The Bottom Line

Cursor is a $29 billion tool for a reason—it’s genuinely revolutionary.

But like any powerful tool, it can either make you incredibly skilled or completely dependent.

The choice is yours:

• Use Ask Mode to learn

• Use Plan Mode to think strategically

• Use Debug Mode to solve problems faster

• Use Agent Mode sparingly

• Set up Cursor Rules for consistency

• Choose the right model for the task

Do this, and you won’t just ship code faster. You’ll become the developer who actually understands what they’re building.

And trust me—that’s worth way more than being able to hit “Accept All” really fast.

The most respected and effective engineers combine technical skills with influence, trust, and a deep understanding of their environment.

This is something I learned from my peers and a YouTube video. Thought I could share this with you all!!

🔑 What It Means to Be a Competitive Engineer

Instead of just working tirelessly (which can lead to burnout), aim to become a competitive engineer — someone who:

• Earns trust from both engineers and business stakeholders.

• Gets to choose what projects to work on.

• Has the freedom to sometimes bend rules to get things done.

• Is frequently requested to be on high-impact projects.

• Accumulates “social capital” through reputation and relationships.

🧠 It’s Not Just About Code

Engineering isn’t only about systems and syntax. It’s also about:

• Influence and relationships.

• Understanding who has decision-making power.

• Knowing how people and teams interact.

• Recognizing that not everyone has the same level of impact.

🚀 Make the Most of Your Start

Your first 1–2 weeks at a new company are a grace period — a unique window to explore without pressure to deliver code. Use it wisely.

✅ What to Focus On:

• Understand the System: How are the systems built? Where does data flow?

• Seek Tribal Knowledge: Look for important, undocumented insights.

• Meet People: Begin forming relationships across teams.

• Observe Culture: How do people work, communicate, and make decisions?

🛠️ Core Practices of High-Impact Engineers

Here are actionable strategies to develop your influence and become a go-to engineer:

1. Use Your Start Wisely

• Don’t rush to push code.

• Explore, ask questions, and observe.

• Build a mental map of systems and people.

2. Learn How Things Are Built

• Study existing codebases.

• Follow how experienced engineers structure and approach problems.

• Use code reviews as learning opportunities.

3. Understand vs. Use

• Learn to treat some parts of the codebase as black boxes.

• Understand what they do, not necessarily how they work internally.

• Focus on using them effectively.

4. Identify the “Wizards”

• Watch who others turn to for help.

• Pay attention to who gets mentioned in tough situations.

• These are your key people — the ones who drive impact.

5. Get Close to the Wizards

• Learn from them by observing, asking questions, and joining discussions.

• Aim to earn their respect and become someone they enjoy working with.

• Ideally, turn one into a mentor.

6. Be Friendly and Easy to Work With

• Make a consistent effort to be kind and approachable.

• Even when busy, maintain a positive and respectful attitude.

• Likability matters — people prefer to work with those they enjoy being around.

7. Remember Personal Details

• Pay attention to your coworkers’ interests, backgrounds, and preferences.

• You can even keep informal notes to help you build stronger relationships (just like a good salesperson might).

8. Do Great Work

• Deliver high-quality code and solutions.

• Take initiative to improve processes or systems.

• Let your work speak for itself — but don’t be afraid to talk about it.

9. Connect Across Teams

• Build relationships with non-engineers, especially in product, design, and business.

• Understand how your work impacts the broader organization.

10. Be Helpful (Even on Small Things)

• Don’t shy away from small or unglamorous tasks.

• Helpfulness builds reputation and trust.

11. Communicate Clearly

• Explain your ideas in simple, structured ways.

• Regularly update others on your progress.

• Make your work visible.

12. Make Real Friends

• Aim to build genuine relationships at work.

• Trusted friendships can unlock better collaboration and support.

🎯 The Long-Term Goal

Your aim is to be trusted, respected, and visible across the company. When high-priority work comes up, your name should naturally be suggested, not just because you’re technically strong, but because you’re someone people want to work with.

And let me tell you, it shook the world. Everyone started freaking out because, guess what? The DeepSeek R1 outperforms the best AI models on the planet—OpenAI's O1 and O1 Pro.

And here's the kicker: It's totally FREE! Yeah, you heard that right.

So, it’s obvious to believe that OpenAI, Anthropic, and other large AI enterprises are not so happy about it.

Speaking of which, do you remember, when Sam Altman said “It’s hopeless to compete with OpenAI“—I think now it has become vice-versa with Deepseek😂

I don’t know how Sam’s gonna respond to this now!😂

Due to rise of Deepseek R1, NVIDIA's stock recently faced a significant decline, dropping approximately 17% and losing nearly $600 billion in market value.

This downturn was primarily triggered by the announcement of the DeepSeek R1. It reportedly achieves performance levels comparable to all the powerful AI models but at a significantly lower cost with limited access to powerful Nvidia chips like A100 or H100.

This lead people to believe that, “We don’t need so as many hardware chips/resources as we think“.

And we can’t blame them.

This emergence of DeepSeek R1, disrupting the entire AI industry, is what experts call the "AI's Sputnik moment”

And I don’t think DeepSeek is going to stop anytime soon.

Now, The Accusation🔥

Whenever something revolutionary happens, so do the accusations—it's practically a package deal! 😂

OpenAI is accusing DeepSeek of stealing their data. Here’s what they mean.

The controversy centers around allegations that DeepSeek used a process called “distillation” to train its model.

Distillation ✴️

Distillation is a technique where a smaller AI model (the “student”) learns from a larger, more advanced model (the “teacher”), making the student model nearly as powerful but much more efficient.

This is commonly used in AI research, but in this case, it’s being suggested that DeepSeek didn’t train its model entirely from scratch.

Instead, it allegedly used responses from OpenAI models, refined them using reinforcement learning, and created a competitive AI—without going through the same costly research process.

U.S. officials, including David Sacks, the AI and crypto czar, have spoken out, saying there is “substantial evidence” of this happening.

“I would love to see that evidence, please😂”

He hinted that American AI companies might take steps to block distillation-based training to prevent what he called “copycat models.” This is a very bold statement.

My Thoughts!

If DeepSeek really trained their model using OpenAI, the only way they could’ve pulled it off is through API calls.

Because let’s be real—there’s no way in hell OpenAI just hands over its models to anyone. They give you a platform, an API to access their model’s outputs, but that’s it. No backstage passes.

So, how exactly did a Chinese company manage to make a massive number of API calls to a US company without OpenAI raising an eyebrow?

OpenAI has rate limits, monitoring, and all the usual safeguards that come with commercial AI services. Even if DeepSeek had multiple API keys, pulling off large-scale data extraction without triggering alarms seems... highly unlikely.

But okay—let’s play along and assume they did get the data. How is that even a crime? They paid for the API, used it to its full potential, and built a better model. Sounds like smart business to me.

So, what’s the problem here? 🤔

I’d love to hear your thoughts on this one...

I mean, they are so great that they don’t give us any reason to look elsewhere. But the problem is its constraints and capabilities in the “FREE“ plan. I really hate that!!

But what if I say you can now use a better version of OpenAI and Claude Sonet 3.5 for almost free? Sounds too good to be true, right?

Well! You are in for a surprise…

Introducing Deepseek—A company based out of China that specializes in building large-scale ultra-powerful, high-performing models and releasing them out to the public for almost free(Open-source)

When I say, “Almost Free“, I mean they do have small charges on the API which is 0.014 dollars which is way less than OpenAI or Claude

The best part is that Deepseek’s models are purely open-source. You can run it on your machine and exploit it to the fullest. The link is given below!

Link: https://github.com/deepseek-ai/DeepSeek-V3

Now, the performance:

I myself was surprised when I got to know that DeepSeek-V3, one of their models performed better than Claude Sonet 3.5 and much better than OpenAI 4o—sharing the graph below!

Well, they didn’t stop at that!

Few days back, to make it even more unbelievable, they launched DeepSeek-R1.

And again! It’s entirely open-source

They claim that DeepSeek seems to be performing on par with o1, OpenAI’s most advanced model

Explore DeepSeek Chat Website here: https://chat.deepseek.com

Okay then, why it’s so great?

DeepSeek models use the Mixture Of Experts(MOE) architecture. DeepSeek V3 or R1 is not a single big model. It’s a collection of multiple specialized sub-models, each designed, trained, and optimized to handle a specific subset of tasks.

The model will simply call upon the necessary sub-models based on the prompts/requests. This way, it doesn’t have to use the entire model’s capabilities, consumes less computational resources, and of course, it has faster performance.

What more do you need?…

But there’s a catch. In order to compete or perform even better than OpenAI or Claude, they need what?

More computing power and more hardware resources.

This brings me to my next point!

The Fear:

Both OpenAI and Claude have access to NVIDIA's most powerful chips A100 and H100 GPUs. So, they were able to increase the parameters to trillion and train the model for better results. They do have access because they are American companies.

But DeepSeek is a Chinese company.

So, due to U.S. export restrictions, DeepSeek has faced challenges in accessing NVIDIA's most advanced chips. In colloquial terms, they are not allowing DeepSeek to have anything from the US, because they are ______(You fill in the blanks)

I can only imagine what’s running in the minds of the people in OpenAI and Claude.

But, hypothetically. Let’s say DeepSeek somehow got access to those powerful chips of Nvidea.

If DeepSeek can outperform the two biggest AI companies with just 671 billion parameters and limited resources, how unstoppable could they be with access to cutting-edge NVIDIA chips?

That’s a Billion Dollar Question…

Table Of Contents

1. What is TypeScript?

2. Initial Setup With Express Server

3. Configure tsconfig.json

4. Install ts-node

5. Configure nodemon.json

6. Build an express server

Node Js + Express Js is a great and popular choice for the backend. But what if you are building a huge application where the code only gets longer and longer? Then, TypeScript is your application.

Node Js + Express Js + TypeScript can improve the development phase by preventing unwanted errors in production.

1. What is TypeScript?

You don’t have to specify any data type for declarations in JavaScript. But TypeScript allows you to add Types to your regular JavaScript. It is an extra measure to easily debug and have more control over what data is running around the application.

Below is a sample code in JavaScript.

let name = "Naveen"

let details = {
  name: name,
  age: 20,
  college: "SRM"
}

Here’s the same code in TypeScript.

let name: string = "Naveen";

let details: {
  name: string;
  age: number;
  college: string;
} = {
  name: name,
  age: 20,
  college: "SRM"
};

Got it?

Note: The browser doesn’t really understand what TypeScript is. So, when we serve the application to the browser, we first convert it into JS and then serve it to the browser. This process is called transpiling.

2. Initial Setup With Express Server

Create an empty directory and run the command below from the root to get the package.

npm init -y

Install the following packages.

npm install typescript -g
npm install express
npm install @types/express --save-dev
npm install @types/node --save-dev

• typescript — This provides the TypeScript compiler for compiling typescript code to JavaScript.

• express — It allows to set up a server and perform other functionalities that come with it.

• @types/express — Since we are using TypeScript, we might need the actual types of all imported modules. Hence, we are using the Types of Express.

• @types/node — We might also need the Types of Node Js’s built-in packages.

Create a folder named src in the root directory and within the folder, create a file named server.ts and copy-paste the following code. The code includes initialization of the express app, running the server at port 8000, and a route to handle GET requests.

import express, { Express, Request, Response, NextFunction } from "express";

const app: Express = express();

app.get("/", (req: Request, res: Response, next: NextFunction) => {
    try {
        return res.json({
            message: "TypeScript Node set up successfully",
        });
    } catch (err) {}
});

app.listen(8000, () => {
    console.log("Server is running at port 8000");
});

Run the below command to compile TypeScript code to JavaScript.

tsc server.ts

A JavaScript file named server.js will be generated on the same location as server.ts

3. Configure tsconfig.json

Now that we are done with the basic setup, let’s move on to creating a common configuration file for executing the TypeScript code.

Create a file named tsconfig.json and copy-paste the following code.

{
    "compilerOptions": {
        "lib": ["es5"],
        "target": "es5",
        "module": "commonjs",
        "moduleResolution": "node",
        "outDir": "dist",
        "resolveJsonModule": true,
        "emitDecoratorMetadata": true,
        "esModuleInterop": true,
        "experimentalDecorators": true,
        "sourceMap": true
    },
    "include": ["src/**/*.ts"],
    "exclude": ["node_modules", "**/*.spec.ts"]
}

target — It denotes the JavaScript version that the compiler should convert the TypeScript code to.

outDir — The location of the JavaScript files to be stored after the compilation of the TypeScript files.

Earlier, when the TypeScript file is compiled, the generated JS file is placed in the same location but this time all the TS files will be stored in the dist folder. When you just run the below command in the root directory, it will detect all the TypeScript files in the src directory, compile them, and put the JS files in the dist folder.

tsc

Please refer to this documentation for explanations of all the above fields.

4. Install ts-node

Now that the compilation is done which is not enough. Because the tsc command only compiles the code. So, we want something to execute the TypeScript code for the application to run and for the server to start listening to requests.

That’s where we need to install ts-node — An NPM package (CLI) that executes the TypeScript code without generating the JavaScript versions of the same code.

npm install ts-node -g

Now, run the below command to start your application.

ts-node ./src/server.ts

You will get the following message down in the console — Server is running at port 8000

5. Configure nodemon.json

Here, you must have noticed that your server doesn’t restart every time a new change occurs. Hence, you need something that performs hot-reloading and restarts the server to reflect the changes on the application. So, you basically need two things.

1. On every change, the TypeScript code should be compiled into JavaScript code and the changes should be reflected on the respective JavaScript files. This is what’s called hot-reloading.

2. The TypeScript code should also be executed for the server to run.

That’s where we need Nodemon—It is an interesting tool used only for development which allows us to write code while the server is running. It restarts the server on every change thereby ensuring that the changes are reflected.

So, please install Nodemon!

npm install nodemon -g

Then, create a file named nodemon.json on the root directory and copy-paste the following code.

{
    "watch": ["src"],
    "ext": ".ts,.js",
    "ignore": [],
    "exec": "ts-node ./src/server.ts"
}

watch — It specifies which folder the nodemon needs to keep track of.

ext — It specifies what extension the nodemon needs to keep track of.

exec — It specifies what commands are to be executed by nodemon.

• tsc — This command performs the compilation process from TypeScript to JavaScript

• ts-node ./src/server.ts — This executes the server.ts file which is all we need for running the server.

Note: We are running both commands simultaneously using the “&&” symbol as these should be executed on every change along with restarting the server.

6. All done! Let’s run the application.

In the package.json, remove all the properties within the scripts, add the below code.

"server":"nodemon"

Your package.json should look roughly like the below code.

{
    "name": "typescript-test",
    "version": "1.0.0",
    "description": "",
    "main": "index.js",
    "scripts": {
        "server": "nodemon"
    },
    "keywords": [],
    "author": "",
    "license": "ISC",
    "devDependencies": {
        "@types/express": "^4.17.21",
        "@types/node": "^20.11.19",
    },
    "dependencies": {
        "express": "^4.18.2"
    }
}

Run the below command from the root directory and you can see your running.

npm run server

Hope everything works well for you. If you have any doubts, please comment them down and I will be more than happy to resolve them.

Happy coding!

Remember, when Elon Musk said, “AI is far more dangerous than Nukes”? Now that you’ve seen what’s happening in the AI world, you have no reason to deny his statement. AI has started to replace jobs and reduce the need for people in certain roles, and there are a lot more to come.

Well, it all started with a product called ChatGPT. When it was launched in November 2022 by OpenAI, it was considered the most advanced chatbot that can answer anything that has ever been recorded on earth. The CEO of OpenAI, Sam Altman has become one of the most influential personalities all over the world.

Now, Elon Musk, a former co-founder of OpenAI filed a lawsuit against OpenAI claiming that OpenAI breached the founding agreement by pursuing profits over helping humanity.

You will only understand Musk’s out-of-the-blue lawsuit when you know the whole story.

Let’s talk a walk to 2015!

Disclaimer: Everything that is said in this article is based on the facts provided in various news articles.

The backstory

In 2015, Sam Altman and Greg Brockman convinced Elon Musk to fund and co-found a startup called OpenAI. The OpenAI was initially built to produce the most advanced Large Language Model, which is none other than the ChatGPT. Elon Musk agreed with the promise that OpenAI’s products were supposed to be non-profitable and should be available to the public for free.

Makes sense, so far?

Then, the startup registered its name as OpenAI, Inc. in Delaware. But, the startup was registered as a non-profitable entity. That is, OpenAI should not make any money from the products it builds. It should solely serve humanity with no profits in return.

Sounds interesting, right?

Elon Musk was totally behind this idea. But in late 2019, he backed out from OpenAI, saying “AI is dangerous” — or something of that sort. Well, he wasn’t wrong, was he?

The next year, 2020, OpenAI slowly started to drift towards turning their AI research into a cash-flowing machine. They started their for-profit subsidiary called OpenAI Global, LLC. The majority of investments were thrown into the for-profit subsidiary and not the non-profit one.

The non-profit one is still there, you know, for helping humanity!

When Sam Altman was asked about this shift, he explained that OpenAI started as a non-profit but then they realized that they needed to raise far more capital to run the non-profit entity and hence the for-profit entity was formed.

Now, OpenAI calls itself the capped-profit hybrid organization. Let’s decode the terminologies.

capped profit: It is defined as placing a limit on the amount of profit that can be generated by the company.

Hybrid Organization: An organization that holds both non-profit and for-profit entities.

The current Scenario

A common perception is Elon Musk was not entirely happy with the idea that OpenAI was making a ton of money when it was supposed to be a non-profit.

He also stated that their for-profit entity has shifted towards commercializing its AGI(Artificial General Intelligence) research after partnering with Microsoft.

Now, Microsoft’s cumulative investment in OpenAI has increased to 13 Billion dollars. I believe all the investments and partnerships must have destroyed whatever patience he had left and triggered him to submit the lawsuit.

The funny thing to note here, based on an article, is Elon Musk repeatedly mentioned in the lawsuit that according to the founding agreement, OpenAI should run as a non-profit entity. But, so far, there was no such “founding agreement” presented as evidence along with the lawsuit. Basically, there is no written agreement tied to what Musk was claiming, which is a terrible sign for him.

Along with the lawsuit, there were attached references to emails between the defendants and the plaintiff. If you have watched any detective shows, you would know these emails won’t stand in the court.

Elon Musk’s claim of “breach of contract” references a specific email sent from Sam Altman to Elon Musk. In short, it states “OpenAI develops for the good of the world”.

Below is an attachment of the email sent by Sam Altman which was replied to by Elon Musk saying — “Agree on all”.

Up until now, we have seen Elon Musk’s moves which are not very surprising but what’s more exciting is how Sam Altman is going to retaliate. We all know the incident where Sam Altman showed his true power when he made OpenAI’s board of directors request him to come back to the same position from which he was fired two days earlier. Based on that incident, my expectations have only gone up.

Let’s wait and watch!!

Imagine this: Justin Bieber posts a new photo on Instagram. Within seconds, millions of fans worldwide rush to hit the “like” button. Now, think about the technical challenge this presents.

How does Instagram handle this sudden surge without crashing?

Believe it or not, there was one incident of Justin Bieber in 2019, where there were too many likes flooding his posts which almost crashed Instagram. Woah!

In this article, we dive into the ingenious solutions that Instagram has implemented to tackle this problem.

The Initial Challenge

In the beginning, Instagram had a straightforward approach to tracking likes on posts.

Here’s a simple example of posts and likes table:

/* POSTS TABLE */
CREATE TABLE posts (
  id BIGINT PRIMARY KEY,
  user_id BIGINT,
  image_url TEXT,
  caption TEXT,
  created_at TIMESTAMP
);

/* LIKES TABLE */
CREATE TABLE likes (
  id BIGINT PRIMARY KEY,
  post_id BIGINT,
  user_id BIGINT,
  created_at TIMESTAMP
);

In this schema, the posts table stores post details, while the likes table records every like with a many-to-one relationship to posts. To get the total likes on a post, Instagram would run a query like this:

SELECT COUNT(*) AS total_likes 
FROM likes
WHERE post_id = {post_id};

This query worked fine for everyday posts, but it fell short when celebrities like Bieber posted. The sudden influx of likes would overwhelm the database, leading to slowdowns and crashes.

Denormalized Counters: A Game Changer

Instagram’s first significant improvement was the introduction of denormalized counters. Instead of dynamically counting likes, they decided to store the total like count directly in the posts table:

ALTER TABLE posts ADD COLUMN like_count BIGINT DEFAULT 0;

With this new structure, every time a user liked a post, two operations occurred:

1. Insert the like into the likes table:

INSERT INTO likes (post_id, user_id, created_at) VALUES (?, ?, .. , NOW());

2. Increment the like count in the posts table:

UPDATE posts  SET like_count = like_count + 1 WHERE id = {post_id};

Similarly, when a like was removed, the operations were:

1. Delete the like from the likes table:

DELETE FROM likes WHERE post_id = ? AND user_id = {user_id};

2. Decrement the like count in the posts table:

UPDATE posts SET like_count = like_count - 1 WHERE id = {post_id};

This approach allowed Instagram to quickly retrieve the total likes for a post without performing expensive COUNT(*) operations, significantly enhancing performance and scalability.

Is count(*) better than two operations combined?

Yes. In simple words, When executing a COUNT(*) query, databases must scan the entire table, which can be very slow for large tables due to sequential scanning(row by row).

In contrast, performing insertions and updates is often more efficient because the database can directly modify the relevant data without scanning the entire table, with the help of indexes.

This makes insertions and updates generally faster and more efficient than counting rows in large datasets.

Ensuring Data Consistency with PgQ

Handling millions of likes is one thing, but ensuring data consistency across different regions, database overload, and caches is another challenge. For this, Instagram turned to PgQ, a PostgreSQL extension that queues and processes events reliably.

When a like was added or removed, an event was queued in PgQ:

/* An Example */
SELECT pgq.insert_event('likes_queue', 'like_added', ?::TEXT);

A background worker handles these events, thereby updating the like count in the posts table.

1. Fetch the next batch of events:

SELECT * FROM pgq.next_batch('likes_queue', 1000);

2. Update the like count for each event:

/* The below logic applies to deleting like
and other operations can be queued as well */
UPDATE posts SET like_count = like_count + 1 WHERE id = event_data::BIGINT;

3. Mark the batch as processed:

SELECT pgq.finish_batch();

Disclaimer: The above example is a simplified version of a more robust mechanism implemented in Instagram but more than enough to explain the idea behind it.

The Result: Seamless Performance Under Pressure

With these architectural changes, Instagram was able to handle the massive spikes in likes generated by high-profile posts without significant performance issues or outages.

The combination of denormalized counters and reliable event processing with PgQ provided a robust solution to the challenge of managing sudden surges in activity.

Conclusion

By implementing denormalized counters and leveraging tools like PgQ, Instagram can now handle the likes of Bieber’s posts — and many others — with ease.

So, next time you see a celebrity’s post gobbling millions of likes in real-time, you’ll know the tech magic working behind the scenes to keep everything running smoothly!

But by the late ’70s, the world was changing. Software was becoming proprietary, locked behind licenses, and companies were now selling what had once been freely distributed. For Stallman, this shift felt like a betrayal. This is not how software should be used!

The Turning Point

Stallman’s frustration came to a head over something seemingly mundane: a printer. The AI lab at MIT had been using a printer for which Stallman had modified the software to notify users when their jobs were complete. When the lab got a new printer, Stallman requested the source code to make the same modifications — but the company refused. They had made their software proprietary.

For Stallman, this was more than an inconvenience — it was a sign that the entire software industry was heading in the wrong direction, towards restricting users’ freedom to modify and share programs.

The Bold Decision: Quitting MIT

In 1983, Stallman made a life-changing decision: he quit his job at MIT to start a revolutionary project. He publicly announced that he would create a free operating system — one that anyone could use, modify, and share without restrictions. This project became the GNU Project (short for “GNU’s Not Unix”), a free Unix-like operating system.

Stallman’s vision was not just about creating software; it was about preserving freedom in utilizing software. He believed users should have control over their software, and the GNU Project would ensure that by creating completely free software.

Building GNU: A Free Software Foundation

Over the next few years, Stallman and his collaborators began building the essential components for the GNU system. Tools like Grep, Tar, and Bash — programs still widely used today — were developed as part of the GNU Project. But just as important as the software was the legal framework Stallman created to protect it: the GNU General Public License (GPL). The GPL ensured that any software distributed under its terms would remain free for all users. It was a legal and philosophical statement that software should be open and modifiable.

However, despite this progress, the GNU system lacked one crucial component: a working kernel. The team initially worked on building a fully functional kernel that could power the GNU Operating System, thereby making a fully functional OS. But unfortunately, the Hurd didn’t perform all that well and they had to drop it!

The kernel is the core part of any operating system, responsible for managing hardware and system resources. Without it, GNU was incomplete.

But there was a student at the University of Helsinki, Finland, who was working on a hobby project. Well, he had the ultimate solution!

Guess who?