DEV Community: Prayush Adhikari

I Spent a Weekend Binge-Watching LLM Content So You Don't Have To (Okay, You Still Should, But Here's the Map)

Prayush Adhikari — Sun, 27 Sep 2026 13:58:09 +0000

Real talk: everyone and their uncle is "using AI" right now, but ask most people what a token actually is and you get a blank stare. I was in that camp too, not long ago. So this month I did something slightly unhinged — I sat down and went through three completely different explanations of how LLMs actually work, back to back, and it clicked in a way that no single YouTube video was ever going to give me.

Here's the thing: each of these sources attacks the problem from a totally different altitude. One gets its hands dirty with code and whiteboard sketches. One skips theory entirely and just shows you how to build something. And one is basically a full grad-school course crammed into a lecture series. Stack them together and you get something close to an actual curriculum, minus the tuition.

If you're on the same journey — curious about AI beyond "type prompt, get answer" — I'm breaking down what I learned from each one, and honestly, I'd watch them in the same order I did.

Big credit up front to the people who actually made this stuff:

Piyush Garg — "How LLMs Works? - Overview"
Dev Weekends — "Level 0 and Level 1 - Gen AI Sessions"
Stanford Online — "CME295: Transformers and Large Language Models I, Autumn 2025" (Afshine and Shervine Amidi)

Let's get into it.

Part 1: What's Actually Happening Inside the Box

If you've ever nodded along in a conversation about AI while quietly having zero clue what "embedding" means, start with Piyush Garg's video. It's not a theory lecture — it's a "let me rip the hood off this thing" video, and it works because it stays concrete the entire time.

The core message is refreshingly deflating in a good way: ChatGPT, Gemini, Claude — none of it is magic, none of it is sentient. It's math, code, and a lot of data. Even the name gives it away. GPT is basically a spec sheet:

Generative — it makes new stuff on the fly instead of retrieving and ranking existing pages like a search engine.
Pre-trained — it already chewed through a mountain of internet text, books, and conversations before you typed anything.
Transformer — the architecture underneath all of it, from Google's 2017 paper "Attention Is All You Need."

From there the video walks you through the actual pipeline your sentence goes through:

Tokenization. Before a computer can do anything with your text, it needs numbers. A tokenizer chops your sentence into chunks based on a vocabulary, and the size of that vocabulary decides whether you get clean whole-word tokens or things get sliced into subwords and stray characters. Garg demos this live with Hugging Face's transformers library and Google's Gemma tokenizer, and honestly that's the moment it stops being abstract and starts being "oh, that's literally what's happening."

Vector embeddings. Once you've got tokens, each one gets mapped to a dense vector — we're talking hundreds or thousands of dimensions — that's supposed to encode meaning. The analogy that actually landed for me: think direction and distance. The path from Cat to Milk looks a lot like the path from Dog to Pedigree. Dog to Animal mirrors Man to Human. The model isn't memorizing a dictionary — it's storing relationships between concepts, and you can literally go poke at this yourself through the OpenAI embeddings API.

Positional encoding. Here's a detail a lot of people skip over: Transformers don't read left to right the way you do. Without help, "the dog chased the cat" and "the cat chased the dog" would look identical to the attention mechanism, which — yeah, that's a problem. Positional encoding bolts sine and cosine functions onto the embeddings so word order (and the meaning that comes with it) actually survives.

Self-attention and multi-head attention. This is the star of the show, and it's the actual innovation from the 2017 paper everyone name-drops. Self-attention lets every token look at every other token and update itself based on context. That's how the model knows "bank" in "river bank" has nothing to do with "bank" in "ICICI bank" — something the older RNN and CNN architectures genuinely struggled with. Multi-head attention just runs a bunch of these attention processes in parallel, so the model can track multiple relationships at once — a dog, on a train, doing something, being a specific color — all simultaneously instead of one at a time.

Feed-forward layers, then output. These attention blocks stack on top of each other, refining the representation layer by layer, until a final linear layer spits out a probability distribution over the entire vocabulary for "what token comes next." Softmax turns those raw scores into actual probabilities, and temperature decides how safe or how spicy the model gets with its pick — low temperature plays it safe, high temperature gambles on something less likely (and usually more interesting, sometimes more unhinged).

The video also draws a clean line between training (the model sees known input-output pairs, calculates loss, updates weights via backpropagation) and inference (live deployment — the model just predicts one token at a time, autoregressively, until it hits an end-of-sequence tag, with zero learning happening). Sounds obvious once you say it out loud, but it clears up a lot of confusion about what's actually happening when you're chatting with one of these things.

What makes this video worth your time isn't that any of it is secret — it's that Garg keeps everything tied to code you can actually run: AutoTokenizer, the OpenAI embeddings endpoint, a from-scratch PyTorch generation loop with AutoModelForCausalLM. You walk away with a mental model you can go verify yourself instead of just trusting some guy on YouTube (me included).

Part 2: Cool, Now How Do I Actually Build Something?

Understanding attention mechanisms doesn't teach you how to ship a product. I learned that gap the hard way trying to wire an LLM into a side project with zero idea what I was doing. This is exactly where Dev Weekends' "Level 0 and Level 1" session comes in, and it's the most immediately useful of the three if your goal is writing software instead of passing an exam.

It starts with the unglamorous stuff that actually matters: you pay for tokens, full stop, and your bill is input tokens (your prompt) plus output tokens (the response). If you've ever gotten a surprise API bill, you already know why this matters more than the fancy theory.

From there it breaks down the three roles you'll use in basically every single LLM API call:

System message — sets the model's personality and ground rules, invisible to whoever's using your app.
User message — whatever the human actually typed.
Assistant message — the model's response, generated using both of the above as context.

A few engineering patterns get covered here that I think people skip more than they should:

Streaming (stream=True) — instead of waiting for the full response, you get it chunk by chunk, which is the entire reason ChatGPT feels like it's "typing" instead of freezing and dumping a wall of text on you.
Structured output / JSON schemas — if you're plugging an LLM into a real system, you cannot have it randomly deciding to wrap its JSON in a friendly little paragraph. Define a schema up front and you kill an entire category of parsing bugs before they happen.
Tool calling / function calling — this is the mechanism that lets a model say "I don't know today's weather, but here's a function signature for a weather API, go call it and hand me the result." The model itself never executes anything — it just recognizes when it needs help and passes the ball back to your app.

On the prompting side, it runs through the standard toolbox: zero-shot (just ask), few-shot (show it examples first), chain-of-thought (make it reason step-by-step before answering), and ReAct (interleaving reasoning with actual tool calls to chew through multi-step problems). I'd read about all of these separately before, but seeing them laid out as a progression — from "just ask" to "reason and act" — made a lot more sense than any individual blog post had.

The part I found genuinely most useful, though, was the fine-tuning vs. RAG breakdown. Fine-tuning means retraining chunks of the network on your own data — expensive, heavy on compute, and static, since any new information means retraining the whole thing over again. RAG (Retrieval-Augmented Generation) sidesteps all of that by keeping the model frozen and just hooking it up to an external, updatable vector database instead.

The RAG pipeline breaks down into five steps:

Parse your source documents — PDFs, databases, scraped pages via BeautifulSoup, whatever.
Chunk the text into fixed-size pieces (think 512 tokens) with some overlap (150 tokens) so you're not losing context at the seams.
Embed and store those chunks in a vector database (ChromaDB, PgVector) along with metadata like source and timestamp.
Search — turn the user's query into an embedding and run cosine similarity to pull the top-k most relevant chunks.
Inject those chunks into the prompt so the model actually grounds its answer in your data instead of just guessing confidently.

And it doesn't stop at "ship it and pray" — it flags RAGAS as a framework for actually evaluating whether your retrieved context is faithful, your answers are relevant, and you're not quietly hallucinating despite technically having a "grounded" system. That last part is easy to forget. RAG lowers your hallucination risk. It does not erase it. Learn that the easy way, not the hard way.

Part 3: The Academic Backbone — Stanford CME295

If the first two are "how it works" and "how you build with it," Stanford's CME295 (taught by Afshine and Shervine Amidi) is the "why it works, rigorously, and where this is all headed" course. It's a full nine-lecture sequence, and it's the one I'd point to if your goal is going from "informed enthusiast" to "person who can actually reason about model design decisions in a room full of people who'd know."

The syllabus tracks a clean arc:

Transformer — core attention mechanics and encoder-decoder structure, covered with academic precision instead of intuition-first analogies.
Transformer-Based Models & Tricks — how BERT, GPT, and T5 diverge architecturally, different positional embedding schemes, and the tricks that make large-scale training actually converge instead of blowing up.
Transformers & LLMs — the jump from small task-specific models to today's massive general-purpose ones, scaling laws, and emergent capabilities that only show up once you're big enough.
LLM Training — pre-training objectives, dataset prep at scale, and the distributed-cluster/memory-efficiency tricks required to train something this large in the first place.
LLM Tuning — Supervised Fine-Tuning, Parameter-Efficient Fine-Tuning (LoRA and friends), and alignment via RLHF and Direct Preference Optimization.
LLM Reasoning — how post-training unlocks reasoning, and the increasingly hot idea of scaling test-time compute instead of just throwing more compute at training.
Agentic LLMs — designing autonomous agents: task decomposition, memory architectures, tool use, multi-agent coordination.
LLM Evaluation — systematic benchmarking, the "LLM-as-a-judge" approach, and safety/robustness red-teaming.
Recap & Current Trends — tying it all together and pointing at where frontier research is actually headed.

What this course adds that the other two structurally can't is the why. Garg's video tells you self-attention solves the context problem. Stanford's course is where you'd actually get the math behind scaled dot-product attention, the reasoning behind specific positional embedding choices, and the real tradeoffs between RLHF and DPO for alignment. It's also the only one of the three treating agentic systems and formal evaluation as first-class topics instead of an afterthought bolted on at the end — which, not coincidentally, is exactly where the field's energy is right now.

Putting It All Together

Lined up side by side, these three cover roughly the same ground a CS curriculum would, just compressed into a weekend of watching instead of a semester of tuition:

	Piyush Garg	Dev Weekends	Stanford CME295
Best for	Building intuition for the internals	Shipping real LLM-powered software	Deep theoretical and research literacy
Format	Single video, whiteboard + code	Hands-on workshop, live API/RAG demos	9-lecture university course
Core focus	Tokens → embeddings → attention → sampling	API roles, streaming, JSON schemas, tool calling, RAG vs. fine-tuning	Math foundations, scaling, alignment, reasoning, agents, evaluation
Tools shown	Hugging Face `transformers`, PyTorch, OpenAI API	OpenAI API, ChromaDB, LangChain, BeautifulSoup, RAGAS	Academic frameworks, frontier benchmarks

Honest take: none of these alone gives you the full picture, and that's fine, because they're not trying to. Garg hands you the mechanical model of how a token turns into a prediction. Dev Weekends shows you what to actually do with that model once it's sitting behind an API and your credit card is on the line. Stanford gives you the rigor to understand why the field made the choices it did, and where it's probably going next — reasoning models, agentic systems, evaluation frameworks that can actually keep pace.

If you're early in this journey, that's the order I'd go: intuition, then application, then theory. Same path I took, minus the part where I procrastinated for two weeks before starting.

Now go tokenize something.

Let's Connect

I'm Prayush Adhikari, currently grinding through the 8th semester of computer engineering and running an IT club on the side while trying to actually understand the stuff I keep building with. If you've watched any of these three (or have a better resource I'm missing), drop it in the comments — I'm always collecting more.

Which one are you starting with: the internals video, the build-something workshop, or going straight for the Stanford deep end?

LinkedIn: https://linkedin.com/in/adhikareeprayush
GitHub: https://github.com/adhikareeprayush
Portfolio: https://prayushadhikari.com.np

Tutorial Hell Is Real: I Watched 40 Hours of Videos and Built Nothing (Here's How I Escaped)

Prayush Adhikari — Sat, 26 Sep 2026 01:43:16 +0000

Hey there! Let me guess how your week went.

You watched a full-stack course. Then another one. You nodded along, pausing at the right moments, typing out everything the instructor typed. Everything worked. You felt like a genius.

Then you opened a blank file to build something on your own, and your brain went completely white.

Welcome to tutorial hell. I've lived there. I paid rent there for way too long. This post is the map I wish I'd had on the way out.

1. How to Know You're Stuck in Tutorial Hell

Be honest with yourself. Tick these off:

You've finished more courses than you've built projects
You feel like you "get it" while watching, but can't start without a video
You keep switching to a new language or framework because the old one "wasn't clicking"
Your bookmarks folder is bigger than your GitHub profile
You've said the words "I'll start my own project after this course" more than twice

If you ticked two or more, you're in. No shame in it. Almost every self-taught developer visits at some point, and plenty of CS students too, because college can be tutorial hell with a syllabus.

2. Why It Feels So Good (and Why That's the Trap)

Here's the 5-year-old version.

Watching a tutorial is like watching someone cook on TV. You see the knife skills, the perfect sear, the plating. Everything looks easy, and you feel like you learned to cook.

Then you walk into your kitchen with raw ingredients and no instructions. Suddenly you don't know how hot the pan should be, how to tell if the chicken is done, or what to do when the onions start burning.

The show never showed you that part. It showed you the finished path, with every decision already made, every wrong turn already edited out.

That's the trap. Tutorials remove the exact thing that makes you learn: the struggle of not knowing what to do next. Your brain gets the warm feeling of progress without any of the actual muscle-building.

Same as the gym. Watching someone lift doesn't make you stronger.

3. The Real Skill Nobody Teaches

Here's the thing. Programming isn't really about knowing syntax. It's about taking a vague problem and breaking it down into small steps you can actually solve.

Tutorials never teach that, because the instructor already did the breaking down before hitting record. You only ever see the solved version.

So to escape, you need to practice the part they skipped: staring at a fuzzy idea, figuring out the first tiny step, doing it, then figuring out the next one. It feels slow and uncomfortable. That discomfort is the learning. Real talk: if it feels easy, you're probably still watching.

4. My Escape Method: Watch, Rebuild, Remix

This is the system that actually works for me and for the people in our IT club. Three steps for every tutorial:

Step 1: Watch (once)

Follow the tutorial once, start to finish. Type along if it helps. This is the only time you're allowed to follow along.

Step 2: Rebuild (from memory)

Close the tab. Delete the code. Open a blank file and build the same thing again without the video.

You will get stuck. You will forget things. Good. Every time you get stuck, spend 15 minutes trying to figure it out yourself before peeking. When you peek, look at only the one piece you need, then close it again.

This step alone is worth more than five extra tutorials.

Step 3: Remix (make it yours)

Now change something the tutorial never covered. Building a weather app? Add a feature for saving favorite cities. A to-do app? Add tags or a deadline reminder. A landing page? Rebuild it for a real local business.

The remix is where you stop being a follower and become a builder. It's also the part that makes your project different from the thousands of identical tutorial clones on GitHub. Recruiters can spot those from a mile away.

5. Project Ideas That Actually Work for Beginners

Stuck on what to build? Here's a starter list. Pick something small enough to finish in a week.

A tool that solves a tiny annoying problem in your daily life
A website for a local shop, a relative's business, or your college club
A tracker for something you already track in a messy spreadsheet (expenses, workouts, study hours)
A quiz app for a subject you're studying
A bot that sends you a daily reminder or summary
A simple dashboard showing data from a free public API
A personal site that's actually deployed and live
A cleaner, better-looking version of an app you use and find ugly

Notice the pattern? They all start from a real problem you have. Motivation is way easier when you're building something you'll actually use.

6. When You Get Stuck (You Will)

Getting stuck isn't a sign you're bad at this. It's the job. Here's how I handle it now:

Read the error message. Actually read it. Most beginners skip straight to panic. The error usually tells you the file, the line, and what it expected.
Explain the problem out loud to a friend, a rubber duck, or your wall. Half the time you solve it mid-sentence.
Shrink the problem. Delete everything unrelated until you have the smallest piece that still breaks.
Search with specifics, not "my code doesn't work". Paste the exact error.
Then ask AI to guide you, not to hand you the answer. Say "give me a hint, not the solution." I wrote about this in my last post, so check it out if you missed it.

Real talk: the developers who improve fastest aren't the ones who never get stuck. They're the ones who get comfortable being stuck.

7. The Comparison Trap

One more thing, because it quietly kills more beginners than bad tutorials do.

You'll see someone your age on social media shipping a startup, landing an internship, or posting a huge project. Ignore the urge to compare. You're seeing their highlight reel next to your behind-the-scenes.

I learned the hard way that the only comparison worth making is you today versus you a month ago. Can you build something now that you couldn't then? Then you're moving.

8. A 30-Day Plan to Break Out

If you want something concrete, here's the plan I'd give to a friend:

Week 1: Rebuild
Pick one tutorial project you already finished. Rebuild it from scratch without the video. Expect to struggle.

Week 2: Remix
Add two features to that project that were never in the tutorial. Deploy it somewhere public.

Week 3: Build your own
Choose a tiny original idea from the list above. Write down the smallest working version in one sentence, then build only that.

Week 4: Polish and share
Write a proper README explaining what it does and why you built it. Put it on GitHub. Post about it, or show it to your club or a friend.

That's one shipped, original project in a month. That alone puts you ahead of most people still on their fourth course.

9. Honest Takes

Tutorials aren't evil. They're great for starting. They're terrible as a destination.
A finished ugly project beats ten perfect plans.
Copying code isn't the sin. Not understanding it is.
Consistency beats intensity. One hour a day beats one heroic weekend.
Nobody feels ready. Start anyway.

That's It. Now Go Build Something.

Close this tab. Close the course you're halfway through. Open a blank file and start something small and slightly embarrassing.

It won't feel great at first. That means it's working.

Let's Connect

I'm Prayush Adhikari, currently grinding through computer engineering, leading an IT club, and building my own company on the side. I write about Linux, productivity, and the honest side of learning to code.

If you're stuck in tutorial hell right now, drop a comment and tell me what you're trying to build. I read every one.

LinkedIn: linkedin.com/in/adhikareeprayush
GitHub: github.com/adhikareeprayush
Portfolio: prayushadhikari.com.np

What project are you building to escape tutorial hell? And what should the next post be: how to build a GitHub profile that gets you noticed, or how to survive your first coding interview?

Should You Still Learn to Code in 2026? An Honest Take From a Student Who's Still Grinding

Prayush Adhikari — Thu, 24 Sep 2026 16:32:29 +0000

So you've seen the videos. "Coding is dead." "AI writes everything now." "Don't bother learning to program."

Cool. Now you're three weeks into learning Python, staring at a SyntaxError, wondering if you're wasting your time.

I get it. I'm a computer engineering student in my final semester, I run an IT club, and I get this exact question all the time: "Bro, is it even worth learning to code anymore?"

Short answer: yes. Long answer: yes, but the way you learn has to change. Let me break it down with no hype and no doom.

1. The Panic Is Real (Let's Not Pretend Otherwise)

I'm not going to tell you everything is fine. It's not all fine.

Entry-level developer job postings have dropped hard. One 2026 breakdown puts the drop in junior postings at about 67% since 2022, with actual hiring falling even more. That hurts to read when you're the one about to apply.

But here's the thing most doom videos skip. Stanford's August 2026 revision found a real employment gap for young workers in AI-exposed jobs, yet the researchers themselves call it descriptive rather than proof of cause. And the U.S. Bureau of Labor Statistics still projects growth for software developer roles over the next decade.

So what's actually happening? The jobs aren't vanishing. They're being rewritten. The old "take a ticket, write boilerplate, submit a pull request" junior role is under pressure. The new junior role is closer to "understand the problem, direct the AI, check what it gave you, and explain why it's right."

Real talk: that's a skill you can learn. But only if you learn the basics first.

2. What AI Actually Replaced

Here's the 5-year-old version.

Think of AI as a really fast intern who never sleeps, never complains, and types 100x faster than you. Sounds amazing, right?

The catch: this intern is confidently wrong once in a while, and it will never tell you when. It'll hand you something that looks perfect, runs fine on the first try, and quietly breaks three days later.

If you don't understand the work, you can't tell the difference between "correct" and "almost correct." And that gap is exactly where beginners get burned.

It's the same story as calculators. Calculators didn't kill math. They killed the arithmetic grind. People who understood math got faster. People who never learned it just got confident wrong answers, faster.

3. The Vibe Coding Trap

You've probably heard of "vibe coding": describe what you want, let AI write it, don't read the output, go with the feeling. And honestly? It's fun. It went from a joke to something a huge share of developers now use daily, and you can ship a working prototype in an afternoon.

But look at what happens when the code breaks.

I learned this the hard way. I once had an AI generate a chunk of a project that I didn't fully understand. It worked. I moved on. Then something small changed, it broke, and I had zero idea where to even start looking. I spent more time debugging code I never wrote than it would've taken to write it myself.

The data backs this up. In Anthropic's own study of around 400,000 coding sessions, sessions rated as novice reached verified success about 15% of the time, versus roughly 28 to 33% for intermediate or expert sessions. That's vendor research, so take it as a signal, not gospel. But it lines up with what I see: AI makes experts faster. It doesn't turn beginners into experts.

And ask any working developer what annoys them most about AI code. In a Stack Overflow survey, the top frustration for about two-thirds of respondents was solutions that are "almost right". Almost right is the most dangerous kind of wrong. You only catch it if you understand what right looks like.

4. What You Should Actually Learn

If you're a beginner, stop trying to learn everything. Here's the short list that actually works.

1. One language, properly

Pick Python or JavaScript. Not both. Not five. Get to the point where you can write a small program from a blank file without copy-pasting. Fundamentals beat frameworks every time.

2. Debugging

This is the new superpower. When AI gives you broken code, the person who can read an error message and trace the problem wins. Learn to use print statements, read stack traces, and Google (or ask AI) specific questions.

3. Git and GitHub

Every job expects this. Learn to commit, branch, and push. It's boring. Do it anyway. It's also your public proof that you build things.

4. Basic SQL and how data is stored

Almost every app is a fancy wrapper around a database. If you understand tables, queries, and why things get slow, you're already ahead of most beginners.

5. Reading code

Sounds weird, but most of your career is reading code someone else wrote. Now that includes code an AI wrote. Practice reading before you write.

6. Explaining what you built

Being able to say "here's the problem, here's what I built, here's why I made this choice" is worth more than a fancy tech stack. Communication is the skill nobody puts on a roadmap.

5. How to Use AI While Learning (Without Rotting Your Brain)

I'm not telling you to avoid AI. That's silly, and employers expect you to use it. I'm telling you to use it like a tutor, not a vending machine.

Here are the rules I follow and tell everyone in my club:

Try first, ask second. Spend at least 15 minutes fighting the problem yourself. The struggle is where the learning actually happens.
Never paste code you can't explain. If you can't explain a line out loud, you don't own it yet. Ask the AI to explain it like you're new, then explain it back.
Ask it to quiz you. "Give me 5 questions on this topic and don't show the answers until I try." This alone changes everything.
Break it on purpose. Take working code, change one thing, and predict what will break. If you can predict it, you understand it.
Ask "why," not just "how." The best prompt for a beginner isn't "write me a login system." It's "why do we hash passwords instead of encrypting them?"

Use AI to go deeper, not to skip the work.

6. Build Proof, Not Tutorials

Here's the honest hiring reality right now. Companies are picky. A certificate of completion won't cut it.

What works instead is two or three real projects that are actually deployed and solve a real problem. Not a to-do app copied from a tutorial. Something specific: a tool for your college, a small site for a local business, a bot that fixes an annoying thing in your daily life.

Then do the part everyone skips: write a proper README explaining what it does, why you built it, and what you'd improve. If you used AI along the way, say how and where you checked its work. That's exactly the kind of maturity hiring managers want to see.

And join something. A club, an open-source project, a Discord community. Being around people who build things keeps you honest and gets you noticed. Running our IT club taught me that most opportunities come from people who know you build stuff, not from cold applications.

7. Things I'd Tell My Younger Self

Nobody is "too late." Every generation of developers thought the field was already crowded.
Tutorial hell is real. If you've watched 40 hours and built nothing, stop watching.
The goal isn't to write code faster than AI. It's to be the person who knows whether the code is good.
Consistency beats intensity. One hour a day for six months beats a 12-hour weekend binge.
Your first projects will be ugly. Ship them anyway.

That's It. That's the Honest Take.

Coding isn't dead. The lazy version of coding is. The version where you understand what you're building, can debug when things break, and use AI as a power tool instead of a crutch? That version is more valuable than ever.

Now go close that "coding is dead" video and open your editor. Write something small. Break it. Fix it. Repeat.

Let's Connect

If this hit home, drop a comment and tell me where you're stuck right now. I read every one.

LinkedIn: linkedin.com/in/adhikareeprayush
GitHub: github.com/adhikareeprayush
Portfolio: prayushadhikari.com.np

What's your biggest fear as a beginner right now: AI taking your job, or never getting your first one? Tell me, and I'll write the next post about it.

Sources for the numbers above:

How to Get Your First Developer Job in 2026 (daily.dev)
Are Vibe Coders Replacing Junior Developers? (Wavect), which covers the Stanford revision, the BLS projection, the Anthropic study, and the Stack Overflow survey

Top 10 AI Coding Tools You Need in 2026 (Or You're Basically Coding With One Hand Tied Behind Your Back)

Prayush Adhikari — Sun, 20 Sep 2026 20:02:48 +0000

So here's the thing nobody warned us about: the "AI will help you code" era quietly turned into the "AI will just... code" era, and if you blinked you probably missed it. One day you're accepting autocomplete suggestions like a normal person, the next day your terminal is opening pull requests without you. Wild times. Anyway, here's ten tools that are actually worth your time right now, ranked by "how often do I personally open this."

1. Claude Code

This one lives in your terminal and just... does things. Refactors, writes tests, reads your whole repo before making a suggestion instead of guessing from three open tabs like some tools I won't name. It feels less like autocomplete and more like handing a task to a very fast, slightly overcaffeinated junior dev who actually read the codebase first.

Check It Out

2. Cursor

Cursor took "VS Code but the AI actually understands your project" and ran with it. Multi-file edits, chat that doesn't forget what file you're in, the whole deal. If you've been Copilot-only, this is the upgrade that makes you go "oh, we're doing THIS now."

Check It Out

3. GitHub Copilot Workspace

Copilot grew up. It's not just finishing your sentences anymore — you can hand it an issue and it drafts an actual plan before touching code. Feels less like a suggestion box and more like a very eager teammate who reads tickets before Slacking you questions.

Check It Out

4. Windsurf

The agentic-editor space got crowded fast, and Windsurf earned its spot by being genuinely good at holding context across a big session without you re-explaining your entire architecture every ten minutes. Underrated for long refactor sessions.

Check It Out

5. v0 by Vercel

Describe a UI, get actual working React components back. It's the closest thing to "type a sentence, get a webpage" that doesn't look like it was built in 2013. Frontend prototyping got stupidly fast.

Check It Out

6. Qodo (formerly CodiumAI)

Test coverage is the vegetables of software development — you know you should, you usually don't. Qodo writes actually-relevant tests based on what your code does instead of generic boilerplate. Slightly less guilt at code review time.

Check It Out

7. Tabnine

For the "I like AI help but I'd also like my proprietary codebase to not leave the building" crowd. Local/private deployment options make it the pick for teams with strict data policies. Boring in the best way.

Check It Out

8. Warp

A terminal that understands natural language and has an AI baked directly in for command lookup and debugging weird shell errors. If you've ever googled "how to undo a git rebase" at 1am, this is for you.

Check It Out

9. Graphite

Code review, but the AI actually summarizes the diff for your reviewers instead of them scrolling through 40 files going "sure, looks fine, ship it." Stacked PRs plus AI summaries make review way less of a chore.

Check It Out

10. Replit Agent

Full apps from a prompt, deployed and running, no local setup required. It's the tool that makes non-devs go "wait, I could build this?" — which is either exciting or terrifying depending on your job security anxiety that day.

Check It Out

The honest takeaway: nobody's job is "type code" anymore, it's "know what to ask for and whether the answer is actually good." Worth spending a weekend poking at two or three of these instead of doomscrolling about how AI is coming for your job. Pick one, break something small in a side project, learn from it.

Security Pitfalls in React Apps I Learned the Hard Way

Prayush Adhikari — Sat, 20 Jun 2026 15:05:53 +0000

A few months back I was doing a code review for a friend's project and noticed they were storing JWTs in localStorage. I almost said nothing because honestly, I had done the same thing in like three projects before someone pointed it out to me. That's kind of the problem with frontend security. Nobody really teaches it properly, so we all just copy patterns from tutorials that were written to be quick, not safe.

So here's what I've picked up, mostly from messing things up myself or catching bugs before they became actual incidents.

XSS is more common than you think

Cross-Site Scripting is when attacker-controlled JavaScript ends up running in your user's browser. Sounds dramatic. It's also surprisingly easy to introduce by accident.

The most common way I've seen it happen in React is through dangerouslySetInnerHTML. Someone needs to render rich text from a CMS or a user comment, they google how to do it, find this prop, use it, and move on.

function Comment({ userInput }) {
  return <div dangerouslySetInnerHTML={{ __html: userInput }} />;
}

If userInput is coming from anything a user typed or any external source, this is a problem. An attacker can craft input that includes script tags and now that runs in every other user's browser that loads the comment.

The fix is pretty straightforward. React escapes content by default when you render it normally, so just do that when you can:

function Comment({ userInput }) {
  return <div>{userInput}</div>;
}

And when you genuinely need to render HTML, run it through DOMPurify first. It strips out anything dangerous before it hits the DOM.

import DOMPurify from 'dompurify';

function Comment({ userInput }) {
  const clean = DOMPurify.sanitize(userInput);
  return <div dangerouslySetInnerHTML={{ __html: clean }} />;
}

Not perfect, but significantly better than nothing.

CSRF is the one people forget about entirely

I genuinely forgot CSRF was a thing for a while. It doesn't come up much in React tutorials because the React part isn't really where the vulnerability lives.

The short version: if your app uses cookies for auth, an attacker can get a logged-in user to make requests to your server from a completely different site. The browser sends the cookies automatically, your server sees a valid session, and whatever that request was supposed to do just... happens.

The standard defenses are CSRF tokens (a secret value the attacker can't read from their site) and setting SameSite=Strict or SameSite=Lax on your cookies. The SameSite attribute alone cuts off most of these attacks without much extra work.

Set-Cookie: session=abc123; SameSite=Strict; Secure; HttpOnly

If you're using a backend framework, there's usually middleware that handles CSRF token generation and validation. Worth checking if it's actually enabled rather than assuming.

localStorage is fine until it isn't

I know the feeling. Tutorial says put the JWT in localStorage, you put it in localStorage, app works, you ship it. And most of the time nothing bad happens.

The issue is that localStorage is readable by any JavaScript running on the page. So if you ever end up with an XSS vulnerability (a bad npm package, a forgotten dangerouslySetInnerHTML, whatever) the attacker's script can just read your token straight out of storage and send it somewhere.

localStorage.setItem('token', data.token);
// readable by literally any JS on this page

HttpOnly cookies solve this because JavaScript can't read them at all. The browser sends them with requests automatically, but no script can access the value. The tradeoff is that your backend needs to set the cookie for you, which adds a bit of coordination. But if you're already building an API, it's not that much extra work.

Security headers exist and you're probably not sending them

This took me embarrassingly long to actually implement. Security headers are HTTP response headers your server sends that tell the browser how to behave. Most apps don't send them because nobody ever runs into a direct error from not having them.

Content Security Policy is the big one. It tells the browser which sources are allowed to load scripts, styles, images, etc. A solid CSP adds a meaningful second layer against XSS because even if a script gets injected, the browser may refuse to run it.

Content-Security-Policy: default-src 'self'; script-src 'self'

There's also X-Content-Type-Options: nosniff which stops browsers from sniffing content types, and X-Frame-Options: DENY which prevents your app from being iframed on other sites (relevant for clickjacking).

If you're running an Express backend, the Helmet package sets most of these in a few lines. If you're on Vercel or Netlify, you can set them in a config file. Either way it's not a big lift once you actually sit down to do it.

Accidentally shipping secret keys

This one has bitten people I know. React apps bundle environment variables into the JavaScript that ships to the browser, which means anyone can open DevTools and read them.

In Create React App, only variables prefixed with REACT_APP_ get included in the bundle. In Vite, it's VITE_. The problem is people forget this rule and prefix something they shouldn't.

# now visible to anyone who opens the network tab
REACT_APP_STRIPE_SECRET_KEY=sk_live_abc123

Secret keys belong on the server. If your frontend needs to charge a card, it should call your own API endpoint, which then calls Stripe using the secret key from a server-side environment variable. The frontend never needs to touch the key directly.

Honestly

Most of this stuff isn't complicated once you know it exists. The gap is that nobody really lays it out together in one place during the "learn React" phase, so you end up shipping apps with several of these issues without realizing it.

I'm still finding old projects of mine where I got lazy about some of this. If you're in the same boat, pick one thing from this list and fix it this week. That's usually how I approach it rather than trying to audit everything at once.

If you've hit a security bug in production or caught one before it went out, I'd genuinely like to hear what it was in the comments.

Let's Connect!

LinkedIn: adhikareeprayush
Portfolio: prayushadhikari.com.np

I Built a Free Public Random Quotes API — No Key, No Auth, Just Use It

Prayush Adhikari — Wed, 06 May 2026 16:44:54 +0000

Hey there! So you've been Googling for a free quotes API that doesn't require signing up, doesn't throttle you after 100 requests, and actually has useful filters?

Yeah, I built that. It's live, it's public, and I want you to use it.

Base URL: https://quotesapi.prayushadhikari.com.np/api

No API key. No authentication. No credit card. Just copy the URL and start fetching quotes. Let me show you everything it can do.

Why Another Quotes API?

Most random quotes APIs I found while building projects were either:

Dead (domain expired, RIP)
Rate-limited to the point of uselessness
Behind a signup wall for basic features
Returning the same 20 quotes forever

I needed something with real filtering — by author, category, text search, quote length. So I built it. And since I built it anyway, I hosted it publicly so you don't have to.

Try It Right Now

Open your browser or terminal and hit this:

curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes/random"

You'll get back:

{
  "data": [
    {
      "quote": "I feel bare. I didn't realize I wore my secrets as armor until they were gone and now everyone sees me as I really am.",
      "author": "Veronica Roth, Insurgent",
      "category": ["armor", "secrets"]
    }
  ],
  "meta": {
    "total": 499708,
    "limit": 1,
    "offset": 0,
    "order": "random",
    "returned": 1
  }
}

Notice category is an array — a single quote can belong to multiple categories. And yeah, meta.total is 499,708. Nearly half a million quotes. That's not a typo.

That's it. No setup, no tokens, no nonsense. It just works.

All Available Endpoints

Hit the discovery endpoint first — it gives you the full route map:

curl -s "https://quotesapi.prayushadhikari.com.np/api"

Here's what's available:

Endpoint	What it does
`GET /api`	Route map — your starting point
`GET /api/quotes`	Paginated quotes with all filters
`GET /api/quotes/random`	Random quote(s), default `limit=1`
`GET /api/categories`	All available categories
`GET /api/authors`	Searchable author list
`GET /api/health`	Load status + diagnostics

The Random Quotes Endpoint

The most popular use case — get a random quote:

# Single random quote (default)
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes/random"

# 5 random quotes at once
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes/random?limit=5"

This is what you want for daily quote widgets, Discord bots, browser extensions, email footers — anything that needs a surprise every time.

Filters That Actually Work

This is where this free quotes API beats most alternatives. You're not stuck with just "give me random." Let me show you what's possible.

Filter by Category

# Quotes about wisdom
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?category=wisdom&limit=5"

# Multiple categories (OR — matches either)
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?categories=wisdom,motivation&limit=10"

# Multiple categories (AND — must match all)
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?categories=wisdom,motivation&match_categories=all"

# Exclude a category
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?exclude_category=politics&limit=10"

Filter by Author

# Partial match, case-insensitive
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?author=oscar&limit=5"

# Exact match
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?author_exact=Oscar%20Wilde"

# Exclude specific author
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?exclude_author=Napoleon&limit=10"

Full-Text Search

# Search inside quote text
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?q=journey&order=text&limit=20"

Quote Length Filters

Perfect when you have a UI constraint — like a widget that only fits a tweet-length quote:

# Short quotes only (under 100 characters)
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?max_len=100&limit=5"

# Medium length range
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?min_len=80&max_len=200&limit=5"

Discover What's in the Dataset

Before you build filters, explore what categories and authors exist:

# All categories
curl -s "https://quotesapi.prayushadhikari.com.np/api/categories"

# Categories with quote counts
curl -s "https://quotesapi.prayushadhikari.com.np/api/categories?counts=true"

# Search authors by name
curl -s "https://quotesapi.prayushadhikari.com.np/api/authors?q=einstein&limit=10"

# All authors (up to 100)
curl -s "https://quotesapi.prayushadhikari.com.np/api/authors"

The counts=true on categories returns { name, count }[] which is exactly what you need to build a category picker UI.

The Seed Param — My Favorite Feature

This is the most underrated param in this random quotes API.

curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?order=random&seed=42&limit=10"

Same seed = same "random" order, every single time. Use cases:

Daily quote of the day — use today's date as the seed (seed=20250506)
Shareable quote lists — send someone a seed and they see what you see
Reproducible testing — no flaky randomness in your test suite

Pagination for the Full Dataset

Random order doesn't support offset — that's intentional. But if you switch to deterministic ordering, pagination works perfectly:

# Page 1
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?order=text&limit=20&offset=0"

# Page 2
curl -s "https://quotesapi.prayushadhikari.com.np/api/quotes?order=text&limit=20&offset=20"

The meta field in every response gives you total and returned so you can compute pages on your end.

Using the API in JavaScript

This quotes API supports CORS, so you can call it directly from the browser — no backend needed.

// Fetch a single random quote
const getRandomQuote = async () => {
  const res = await fetch('https://quotesapi.prayushadhikari.com.np/api/quotes/random');
  const { data } = await res.json();
  return data[0];
};

// Fetch quotes by category
const getQuotesByCategory = async (category, limit = 5) => {
  const params = new URLSearchParams({ category, limit });
  const res = await fetch(`https://quotesapi.prayushadhikari.com.np/api/quotes?${params}`);
  const { data, meta } = await res.json();
  return { quotes: data, total: meta.total };
};

// Daily quote using date as seed
const getDailyQuote = async () => {
  const today = new Date().toISOString().slice(0, 10).replace(/-/g, '');
  const params = new URLSearchParams({ order: 'random', seed: today, limit: 1 });
  const res = await fetch(`https://quotesapi.prayushadhikari.com.np/api/quotes?${params}`);
  const { data } = await res.json();
  return data[0];
};

// Example usage
const quote = await getRandomQuote();
console.log(`"${quote.quote}" — ${quote.author}`);

Using It in Python

import requests
from datetime import date

BASE_URL = "https://quotesapi.prayushadhikari.com.np/api"

def get_random_quote(category=None, limit=1):
    params = {"limit": limit}
    if category:
        params["category"] = category

    res = requests.get(f"{BASE_URL}/quotes/random", params=params)
    data = res.json()
    return data["data"]

def get_daily_quote():
    seed = date.today().strftime("%Y%m%d")
    res = requests.get(f"{BASE_URL}/quotes", params={"order": "random", "seed": seed, "limit": 1})
    return res.json()["data"][0]

# Get a random motivation quote
quotes = get_random_quote(category="motivation")
for q in quotes:
    print(f'"{q["quote"]}" — {q["author"]}')

# Get today's quote (same every time you call it today)
daily = get_daily_quote()
print(f'Daily: "{daily["quote"]}"')

All Query Parameters at a Glance

Here's the full reference for GET /api/quotes and GET /api/quotes/random:

Parameter	Description	Example
`author`	Substring match on author name	`author=einstein`
`author_exact`	Exact author name	`author_exact=Albert%20Einstein`
`exclude_author`	Exclude this author	`exclude_author=Napoleon`
`category`	Must include this category	`category=wisdom`
`categories`	Comma-separated, OR logic	`categories=wisdom,love`
`match_categories=all`	Require ALL listed categories	`match_categories=all`
`exclude_category`	Exclude this category	`exclude_category=politics`
`q`	Substring search in quote text	`q=courage`
`min_len` / `max_len`	Quote character length range	`min_len=50&max_len=200`
`limit`	Results per page (default 10, max 100)	`limit=25`
`offset`	Pagination offset (not for random)	`offset=40`
`order`	`random`, `author`, `text`, `none`	`order=author`
`seed`	Deterministic shuffle for random	`seed=42`
`legacy=true`	Returns bare JSON array	`legacy=true`
`meta=false`	Omit meta object from response	`meta=false`

What Can You Build With This?

Here's what I'd love to see people building:

Daily quote bots for Discord, Telegram, or Slack
New tab browser extensions with category-filtered quotes
Motivational widgets on personal portfolio sites
Quote-of-the-day email newsletters using the seed param
Mobile apps that match quote moods to user input
Screensaver or wallpaper generators with random quotes
Obsidian plugins that pull quotes into your daily notes
CLI tools that show a quote on every terminal open

The API handles CORS for all GET requests, so browser-direct calls work without a proxy backend.

Troubleshooting

Getting empty data: []?

Hit the health endpoint first:

curl -s "https://quotesapi.prayushadhikari.com.np/api/health"

It'll tell you if the full dataset loaded correctly or if there's a fallback in use.

Filters returning fewer results than expected?

You might be combining too many strict filters. Try loosening them one at a time. The q text search is a substring match, so q=inspiration won't match a quote containing "inspire."

Need ALL quotes, not just 10?

Use order=text (or order=author) with offset for pagination. meta.total tells you how many exist total. Don't use order=random with offset — it won't work.

Wrapping Up

I built this free random quotes API because I was tired of hitting dead endpoints and rate limits every time I wanted to add a quote feature to a side project. Now you don't have to be.

It's free. It's public. It's not going anywhere.

Start here: https://quotesapi.prayushadhikari.com.np/api

Drop a comment with what you're building — I read every single one and it helps me figure out what to add next. Want me to cover setting up your own instance, adding new quote datasets, or building a Discord bot with this? Let me know.

I'm Prayush Adhikari, grinding through computer engineering and shipping things in public.

LinkedIn: adhikareeprayush
GitHub: adhikareeprayush
Portfolio: prayushadhikari.com.np

Now go fetch some quotes.

MongoDB: Zero to Advanced (The Real Guide Nobody Else Will Write)

Prayush Adhikari — Tue, 24 Feb 2026 08:14:10 +0000

Hey there! So you've heard about MongoDB and now you're wondering what the heck it actually is and why everyone keeps talking about it. I've been down this rabbit hole and I'm going to save you from the confusion, the bad tutorials, and the Stack Overflow rabbit holes.

This is the guide I wish existed when I started.

Let's Talk About Databases First (Bear With Me)

Before we jump into MongoDB, we need to talk about what a database actually is. And no, I'm not going to give you the boring textbook definition.

Think of it this way: you're building a web app. You have users, their profiles, their posts, their comments. Where does all this data live when you close your laptop? Not in your code. Not in RAM. It lives in a database.

A database is just an organized way to store, retrieve, and manage data. That's it. No magic.

Now here's where it gets interesting. There are two main types of databases and understanding the difference is going to save you a LOT of confusion.

SQL vs NoSQL: The Fight That Never Ends

SQL databases (PostgreSQL, MySQL, SQLite) are like super strict spreadsheets. You define the columns upfront, every row must follow the same structure, and everything is neatly organized in tables. Want to change the structure? Hope you like writing migration scripts.

NoSQL databases (MongoDB being the king here) are more like a folder full of documents. Each document can look completely different from the others. Some can have 5 fields, some can have 50. Nobody's going to yell at you.

So when should you use MongoDB? Here's my honest take:

You're building a modern web or mobile app
Your data structure might change a lot (early stage projects)
You need to store nested or complex data (like a user profile with embedded addresses and preferences)
You want to move fast without worrying about schema migrations

When should you NOT use MongoDB? If you're dealing with super complex relationships and need a lot of joins (think banking systems, ERPs), a relational database might serve you better. MongoDB added transactions and lookup operations, but SQL databases still shine there.

Setting Up MongoDB (The Easy Way)

Forget local installation for now. Seriously. The number of people who've given up on MongoDB because of installation headaches is criminal.

We're using MongoDB Atlas — it's free, it's cloud-based, and it's exactly what real companies use in production.

Step 1: Create Your Atlas Account

Head to mongodb.com/products/platform/atlas-database and sign up. It's free. No credit card needed for the free tier.

Step 2: Create Your First Cluster

Once you're in, click "Build a Database" and choose the M0 Free option. Pick whichever cloud provider and region is closest to you. Name your cluster whatever you want — I usually just call it MyCluster.

Step 3: Set Up Access

Atlas will ask you to:

Create a database user (username + password — save these!)
Your current IP address will be added as the part of auto setup process. (If not head to Database and Network access menu from sidebar you will find the way)

Step 4: Get Your Connection String

Click Connect on your cluster → Connect using MongoDB Compass or Connect your application. Copy that connection string. You'll need it later.

Step 5: Install MongoDB Compass

MongoDB Compass is the GUI for MongoDB. It lets you visually browse your data, run queries, and manage collections without writing a single line of code. This is your new best friend.

Download it, install it, paste your connection string, and hit connect. You're in.

Core Concepts: The Building Blocks

Alright, let's get into the actual meat of MongoDB. There are 4 things you need to understand before anything else makes sense.

1. Database

A database in MongoDB is exactly what it sounds like — a container for your data. Think of it like a project folder. If you're building a blog app, you'd probably have a blog database.

2. Collection

A collection is like a table in SQL — except it has no fixed structure. It holds a bunch of documents. In your blog database, you might have a posts collection and a users collection.

3. Document

This is where MongoDB gets cool. A document is a single record — like a row in SQL — but it's stored as JSON-like format called BSON. It looks like this:

{
  "_id": "64f3a1b2c3d4e5f6a7b8c9d0",
  "name": "Prayush Adhikari",
  "email": "prayush@example.com",
  "skills": ["JavaScript", "MongoDB", "Linux"],
  "address": {
    "city": "Kathmandu",
    "country": "Nepal"
  }
}

See that? An array inside a document. An object inside a document. This flexibility is what makes MongoDB powerful.

4. `_id` Field

Every document in MongoDB gets a unique _id field automatically. MongoDB generates it as an ObjectId unless you provide your own. It looks ugly but it's your document's unique fingerprint.

CRUD Operations: The Heart of Everything

CRUD stands for Create, Read, Update, Delete. If you master these four operations, you can build basically anything with MongoDB.

I'll show you both the shell commands (mongosh) and what they look like in Compass so you get the full picture. First create a database and a collection using the gui. I am creating the database named myDatabase and collection named users.

Create: Adding Data

// use the created database
use myDatabase

// Insert a single document
db.users.insertOne({
  name: "Prayush",
  email: "prayush@example.com",
  age: 21,
  joined: new Date()
})

// Insert multiple documents at once
db.users.insertMany([
  { name: "Alice", email: "alice@example.com", age: 25 },
  { name: "Bob", email: "bob@example.com", age: 30 }
])

Read: Finding Data

This is where you'll spend most of your time, so pay attention.

// Find ALL documents in a collection
db.users.find()

// Find documents that match a condition
db.users.find({ age: 21 })

// Find one specific document
db.users.findOne({ email: "prayush@example.com" })

// Find users older than 20
db.users.find({ age: { $gt: 20 } })

// Find users and only return name and email (projection)
db.users.find({}, { name: 1, email: 1, _id: 0 })

// Sort by age ascending
db.users.find().sort({ age: 1 })

// Limit to 5 results
db.users.find().limit(5)

Those $gt, $lt, $gte things are called query operators and they're incredibly powerful. Here's a quick cheat sheet:

Operator	Meaning	Example
`$gt`	Greater than	`{ age: { $gt: 18 } }`
`$lt`	Less than	`{ age: { $lt: 65 } }`
`$gte`	Greater than or equal	`{ age: { $gte: 21 } }`
`$lte`	Less than or equal	`{ score: { $lte: 100 } }`
`$ne`	Not equal	`{ status: { $ne: "banned" } }`
`$in`	In an array of values	`{ role: { $in: ["admin", "mod"] } }`

Update: Changing Data

// Update ONE document
db.users.updateOne(
  { name: "Prayush" },          // Filter: find this document
  { $set: { age: 22 } }         // What to change
)

// Update MULTIPLE documents
db.users.updateMany(
  { age: { $lt: 18 } },
  { $set: { status: "minor" } }
)

// Increment a value
db.users.updateOne(
  { name: "Prayush" },
  { $inc: { loginCount: 1 } }   // Adds 1 to loginCount
)

// Add item to an array
db.users.updateOne(
  { name: "Prayush" },
  { $push: { skills: "Docker" } }
)

The $set, $inc, $push are called update operators. NEVER update a document without using these operators — if you skip them, you'll overwrite the entire document and lose all your data. Ask me how I know.

Delete: Removing Data

// Delete ONE document
db.users.deleteOne({ name: "Bob" })

// Delete MULTIPLE documents
db.users.deleteMany({ age: { $lt: 18 } })

// Delete ALL documents in a collection (use carefully!)
db.users.deleteMany({})

Data Modeling: The Part That Actually Matters

Here's the thing nobody tells beginners — getting your data model right is more important than knowing all the fancy MongoDB features. A bad data model will haunt you for the entire life of your project.

In MongoDB, you have two ways to relate data: embedding and referencing.

Embedding (Nesting Data Inside a Document)

{
  "_id": "user123",
  "name": "Prayush",
  "address": {
    "street": "123 Kathmandu St",
    "city": "Kathmandu",
    "zip": "44600"
  },
  "orders": [
    { "item": "Keyboard", "price": 50 },
    { "item": "Mouse", "price": 25 }
  ]
}

Use embedding when:

The embedded data is always accessed with the parent (you always need the address when you get the user)
The embedded data doesn't change often
The array won't grow unboundedly (don't embed 10,000 comments in a blog post)

Referencing (Like Foreign Keys in SQL)

// users collection
{
  "_id": "user123",
  "name": "Prayush"
}

// posts collection
{
  "_id": "post456",
  "title": "My MongoDB Guide",
  "authorId": "user123"   // References the user
}

Use referencing when:

The data is frequently updated independently
The data is shared across many documents
The array could grow very large

My rule of thumb: embed for read-heavy relationships, reference for write-heavy or large growing relationships.

Intermediate Queries: Leveling Up

Now that you know the basics, let's get into some more powerful queries.

Querying Arrays

// Find users who have "MongoDB" in their skills array
db.users.find({ skills: "MongoDB" })

// Find users who have BOTH "MongoDB" AND "JavaScript"
db.users.find({ skills: { $all: ["MongoDB", "JavaScript"] } })

// Find users where at least one skill matches a condition
db.users.find({ 
  skills: { $elemMatch: { $eq: "Docker" } }
})

Querying Nested/Embedded Documents

Use dot notation to query inside nested objects:

// Find users in Kathmandu
db.users.find({ "address.city": "Kathmandu" })

// Find orders over $100 within user documents
db.users.find({ "orders.price": { $gt: 100 } })

Logical Operators

// AND: find users who are 21 AND from Kathmandu
db.users.find({ 
  $and: [
    { age: 21 },
    { "address.city": "Kathmandu" }
  ]
})

// OR: find users who are admins OR moderators
db.users.find({
  $or: [
    { role: "admin" },
    { role: "moderator" }
  ]
})

// NOT: find users who are NOT banned
db.users.find({ status: { $not: { $eq: "banned" } } })

The Aggregation Framework: Where the Real Magic Happens

This is the part that separates beginners from intermediate developers. The aggregation framework lets you process and transform your data through a pipeline of stages.

Think of it like a factory assembly line — your data goes in one end, gets processed at each stage, and comes out transformed on the other end.

db.orders.aggregate([
  // Stage 1: Filter (like find)
  { $match: { status: "completed" } },

  // Stage 2: Group by category and sum revenue
  { $group: {
    _id: "$category",
    totalRevenue: { $sum: "$price" },
    orderCount: { $sum: 1 }
  }},

  // Stage 3: Sort by revenue descending
  { $sort: { totalRevenue: -1 } },

  // Stage 4: Only return top 5
  { $limit: 5 }
])

This pipeline would give you the top 5 product categories by revenue. Try doing that with just find().

Common Aggregation Stages

Stage	What it does
`$match`	Filter documents (like `find`)
`$group`	Group documents and compute values
`$sort`	Sort results
`$project`	Include/exclude/transform fields
`$limit`	Cap the number of results
`$unwind`	Deconstruct an array into separate documents
`$lookup`	Join with another collection

Real Example: Blog Stats

// Get total posts and average views per author
db.posts.aggregate([
  { $group: {
    _id: "$authorId",
    totalPosts: { $sum: 1 },
    avgViews: { $avg: "$views" },
    totalViews: { $sum: "$views" }
  }},
  { $sort: { totalViews: -1 } }
])

Indexing: Making Your Database Fast

Here's a fact: without indexes, MongoDB scans EVERY document in a collection to find matches. That's fine when you have 100 documents. It's catastrophic when you have 10 million.

An index is like the index at the back of a textbook — instead of reading every page to find "MongoDB," you look at the index, get the page number, and jump straight there.

// Create an index on the email field
db.users.createIndex({ email: 1 })   // 1 = ascending, -1 = descending

// Create a compound index (on multiple fields)
db.users.createIndex({ age: 1, city: 1 })

// Create a unique index (no duplicate emails!)
db.users.createIndex({ email: 1 }, { unique: true })

// Check existing indexes
db.users.getIndexes()

// See how MongoDB executes a query (is it using an index?)
db.users.find({ email: "prayush@example.com" }).explain("executionStats")

When to Add an Index

Add indexes on fields that you:

Query frequently (filters, search)
Sort on often
Use in joins/lookups

Don't add indexes on everything — they take up space and slow down writes. Index what you query. That's the rule.

Transactions: When You Need ACID Guarantees

Here's something that surprises a lot of people: MongoDB supports multi-document transactions since version 4.0. Yes, the same kind of transactions you get in PostgreSQL.

This matters when you need multiple operations to either ALL succeed or ALL fail. Classic example: transferring money between two accounts.

const session = client.startSession();

try {
  session.startTransaction();

  await db.collection('accounts').updateOne(
    { userId: "user1" },
    { $inc: { balance: -100 } },
    { session }
  );

  await db.collection('accounts').updateOne(
    { userId: "user2" },
    { $inc: { balance: 100 } },
    { session }
  );

  await session.commitTransaction();
  console.log("Transfer successful!");

} catch (error) {
  await session.abortTransaction();
  console.log("Transfer failed. Rolled back.");
} finally {
  session.endSession();
}

If the second update fails, the first one is automatically rolled back. No partial transfers. No corrupted data.

Connecting MongoDB to Node.js (Let's Build Something Real)

Theory is cool but let's actually use this thing. Here's how to connect MongoDB to a Node.js app.

Setup

mkdir mongo-demo && cd mongo-demo
npm init -y
npm install mongodb dotenv

Create a .env file:

MONGODB_URI=your_connection_string_from_atlas

Basic Connection

// db.js
const { MongoClient } = require('mongodb');
require('dotenv').config();

let client;

async function connectDB() {
  if (client) return client;

  client = new MongoClient(process.env.MONGODB_URI);
  await client.connect();
  console.log("Connected to MongoDB!");
  return client;
}

module.exports = { connectDB };

Building a Simple CRUD API

// app.js
const { connectDB } = require('./db');

async function main() {
  const client = await connectDB();
  const db = client.db("blogDB");
  const posts = db.collection("posts");

  // CREATE
  const newPost = await posts.insertOne({
    title: "My First Post",
    content: "MongoDB is actually pretty cool",
    author: "Prayush",
    views: 0,
    tags: ["mongodb", "tutorial"],
    createdAt: new Date()
  });
  console.log("Created:", newPost.insertedId);

  // READ
  const allPosts = await posts.find({ author: "Prayush" }).toArray();
  console.log("Posts:", allPosts);

  // UPDATE
  await posts.updateOne(
    { _id: newPost.insertedId },
    { $inc: { views: 1 } }
  );

  // DELETE
  // await posts.deleteOne({ _id: newPost.insertedId });

  await client.close();
}

main();

Mongoose: The Better Way to Use MongoDB with Node.js

If you're building a real app with Node.js, you'll want to use Mongoose instead of the raw MongoDB driver. Mongoose adds schema validation, middleware, and a bunch of quality-of-life features.

npm install mongoose

const mongoose = require('mongoose');

// Define a schema
const postSchema = new mongoose.Schema({
  title: { type: String, required: true },
  content: { type: String, required: true },
  author: { type: String, required: true },
  views: { type: Number, default: 0 },
  tags: [String],
  createdAt: { type: Date, default: Date.now }
});

// Create a model
const Post = mongoose.model('Post', postSchema);

// Connect and use
async function run() {
  await mongoose.connect(process.env.MONGODB_URI);

  // Create
  const post = new Post({
    title: "Mongoose is Great",
    content: "Schema validation saves lives",
    author: "Prayush"
  });
  await post.save();

  // Find
  const posts = await Post.find({ author: "Prayush" }).sort({ createdAt: -1 });
  console.log(posts);

  await mongoose.disconnect();
}

run();

The big win with Mongoose? If you try to save a document without a required field, it throws an error before it even hits the database. That's validation at the schema level.

Atlas Search and Vector Search: The 2025-2026 Stuff

This is where MongoDB gets genuinely exciting for modern applications.

Atlas Search

Built on Apache Lucene, Atlas Search lets you add full-text search to your app without spinning up a separate Elasticsearch instance.

// Full-text search on posts
db.posts.aggregate([
  {
    $search: {
      index: "default",
      text: {
        query: "mongodb tutorial",
        path: ["title", "content"]
      }
    }
  },
  { $limit: 10 }
])

Vector Search (For AI Apps)

If you're building RAG applications or any AI-powered feature that needs semantic search, MongoDB Atlas Vector Search is a game changer. You store embeddings (vectors from AI models) right alongside your data and query by similarity.

// Search for semantically similar documents
db.articles.aggregate([
  {
    $vectorSearch: {
      index: "vector_index",
      path: "embedding",
      queryVector: [0.1, 0.25, -0.3, ...],  // Your query embedding
      numCandidates: 100,
      limit: 10
    }
  }
])

This is the technology that powers modern AI chatbots that can "remember" things from documents. MongoDB lets you build this without stitching together 5 different services.

Time Series Collections (MongoDB 8.x)

Got IoT data? Logs? Metrics? MongoDB 8.x introduced optimized time series collections that store time-based data WAY more efficiently than regular collections.

// Create a time series collection
db.createCollection("sensorData", {
  timeseries: {
    timeField: "timestamp",
    metaField: "sensorId",
    granularity: "seconds"
  }
})

// Insert time series data
db.sensorData.insertMany([
  { timestamp: new Date(), sensorId: "sensor1", temperature: 23.5, humidity: 60 },
  { timestamp: new Date(), sensorId: "sensor2", temperature: 25.1, humidity: 55 }
])

MongoDB automatically handles compression and optimized storage for you. This stuff used to require specialized databases like InfluxDB. Now MongoDB handles it natively.

The Real Secret to MongoDB Mastery

Here's what nobody tells you: knowing all the commands is the easy part. The hard part is knowing which tool to reach for.

Every concept I've covered comes down to one question: what is the most efficient way to store and retrieve THIS specific data for THIS specific use case?

Embedding vs referencing is a design decision, not a rule.
Indexes are solutions to performance problems, not defaults you add to everything.
Aggregations are for analytics and transformations, not for basic reads.
Transactions are for when correctness absolutely cannot be compromised.

Start building something. A blog. A todo app. A movie tracker. Break it. Fix it. Look at your slow queries. Add indexes. Refactor your data model when it starts hurting. That's how you actually learn MongoDB.

What's Next?

Here are some things I'd cover in separate deep dives if you want me to:

Full REST API with Express + MongoDB — Let's build it properly
Authentication system with MongoDB — JWT, sessions, the whole thing
Sharding and scaling — When your app hits a million users
MongoDB Change Streams — Real-time notifications without polling
Atlas Triggers and Functions — Serverless functions that react to database events

Drop a comment with which one you want first and I'll get to it.

Let's Connect

I'm Prayush Adhikari, grinding through computer engineering and writing content that actually helps. If this guide saved you from a bad tutorial or a confusing Stack Overflow thread, we're even.

LinkedIn: adhikareeprayush
GitHub: adhikareeprayush
Portfolio: prayushadhikari.com.np

What do you want me to cover next? Drop it in the comments.

Now go build something with MongoDB.

Database Indexing Explained Like You're 5 (Then Like You're a Senior Dev)

Prayush Adhikari — Wed, 12 Nov 2025 19:51:22 +0000

Hey there! So you want to understand database indexing? Cool. Let me break this down in a way that actually makes sense, starting from the absolute basics and working our way up to the stuff that'll make you look like a genius in your next code review.

The 5-Year-Old Explanation

Imagine you have a massive book with 10,000 pages about different animals. No table of contents, no organization, just random animals on random pages.

Now, your teacher asks: "Find me information about elephants."

What do you do? You flip through every single page until you find elephants. Page 1, nope. Page 2, nope. Page 3, nope... this is going to take forever, right?

That's your database without indexes.

Now imagine the same book, but at the front, there's a special page that says:

Elephants: Page 4,521
Lions: Page 892
Penguins: Page 7,234

Boom. You jump straight to page 4,521. Found it in seconds.

That's an index.

Simple, right? Now let's get into the real stuff.

The Real World Problem

Let's say you're building an app. Could be anything, a blog, an e-commerce site, whatever. You've got a users table with 1 million records. Someone tries to log in, and you run this query:

SELECT * FROM users WHERE email = 'prayush@example.com';

Without an index, your database does what's called a full table scan. It literally checks every single one of those 1 million rows. Every. Single. One.

On my machine, that query took 2.3 seconds without an index.

With an index? 0.003 seconds.

Yeah, you read that right. From 2.3 seconds to 3 milliseconds. That's not just fast, that's "your users don't rage-quit your app" fast.

How Indexes Actually Work (Getting Technical)

Alright, now we're getting into the good stuff. Let's talk about what's really happening under the hood.

The B-Tree Structure

Most databases use something called a B-Tree (Balanced Tree) for indexes. And no, despite what everyone thinks, the B doesn't stand for "binary." It actually stands for "balanced" or possibly "Bayer" (the guy who invented it).

Here's the deal: a B-Tree organizes your data in a tree structure where:

The root node contains pointers to other nodes
Intermediate nodes contain more pointers
Leaf nodes contain the actual data (or pointers to the actual data)

When you search for something, the database traverses this tree. Instead of checking 1 million rows, it might only need to check 3-4 nodes to find what it's looking for.

Let me show you what I mean with a real example from a project I worked on:

-- Creating a simple users table
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(255),
    username VARCHAR(100),
    created_at TIMESTAMP
);

-- Insert a million records (not showing the full script here, trust me)
-- Now let's see the difference

Without index:

EXPLAIN ANALYZE SELECT * FROM users WHERE email = 'random@email.com';
-- Seq Scan on users (cost=0.00..25833.00 rows=1 width=89) (actual time=2347.921..2347.922 rows=1 loops=1)

With index:

CREATE INDEX idx_users_email ON users(email);

EXPLAIN ANALYZE SELECT * FROM users WHERE email = 'random@email.com';
-- Index Scan using idx_users_email on users (cost=0.42..8.44 rows=1 width=89) (actual time=0.038..0.039 rows=1 loops=1)

The numbers don't lie. The cost dropped from 25833 to 8.44. That's massive.

Types of Indexes (Because One Size Doesn't Fit All)

1. Single Column Index

The basic one we've been talking about:

CREATE INDEX idx_email ON users(email);

Use this when you're frequently searching by a single column.

2. Composite Index

Multiple columns in one index:

CREATE INDEX idx_email_username ON users(email, username);

Here's where it gets interesting. The order matters. This index is great for:

SELECT * FROM users WHERE email = 'x' AND username = 'y'; -- Fast
SELECT * FROM users WHERE email = 'x'; -- Also fast
SELECT * FROM users WHERE username = 'y'; -- Slow! Doesn't use the index

Why? Because the index is organized by email first, then username. It's like a phone book sorted by last name, then first name. You can't efficiently find someone by just their first name.

3. Unique Index

Enforces uniqueness AND speeds up queries:

CREATE UNIQUE INDEX idx_unique_email ON users(email);

Perfect for emails, usernames, or anything that should be unique.

4. Partial Index

This one's cool. Index only part of your data:

CREATE INDEX idx_active_users ON users(email) WHERE is_active = true;

If you only ever query active users, why index the inactive ones? Save space, save time.

5. Full-Text Index

For searching text content:

CREATE INDEX idx_post_content ON posts USING GIN(to_tsvector('english', content));

This is what makes your blog search actually work. I use this on my own projects and it's a game changer for search functionality.

The Dark Side: When Indexes Hurt You

Here's what nobody tells beginners: indexes aren't free. They come with a cost.

Storage Cost

Every index is basically a copy of your data in a different structure. More indexes = more disk space. I learned this the hard way when my database size doubled because I got index-happy.

Write Performance

Every time you INSERT, UPDATE, or DELETE, the database has to update all your indexes too.

Real talk: I once had a table with 12 indexes. Inserts were taking forever. Dropped it down to 4 strategic indexes, and suddenly my batch inserts went from 5 minutes to 30 seconds.

The Wrong Index Is Worse Than No Index

True story: I once created an index on a column with only 3 possible values (status: pending, active, inactive). The database was spending more time maintaining and reading the index than it would have just scanning the table.

Rule of thumb: If a column has low cardinality (not many unique values), skip the index.

Common Indexing Mistakes (Learn from My Pain)

Mistake 1: Indexing Everything

I did this. You'll probably do this too. Don't.

The Fix: Index based on your actual queries. Use EXPLAIN ANALYZE to see what's slow, then index specifically for that.

Mistake 2: Ignoring Index Order in Composite Indexes

Remember that email + username example? Put the most selective column first.

-- Bad: username has duplicates, email is unique
CREATE INDEX idx_bad ON users(username, email);

-- Good: email is unique, username has duplicates  
CREATE INDEX idx_good ON users(email, username);

Mistake 3: Not Analyzing Your Indexes

Indexes can get bloated over time. In PostgreSQL:

REINDEX TABLE users;

I do this monthly on my production databases. Keeps things running smooth.

Mistake 4: Forgetting About Covering Indexes

If your query only needs data that's in the index, the database doesn't even need to touch the main table.

CREATE INDEX idx_covering ON users(email, username, created_at);

-- This query only touches the index, super fast
SELECT email, username FROM users WHERE email = 'x';

Mistake 5: Over-Optimizing Too Early

I wasted weeks optimizing queries that ran once a day on 1000 rows. Focus on what matters: frequent queries on large tables.

Advanced Strategies (Senior Dev Territory)

Strategy 1: Index-Only Scans

Structure your indexes so queries can be answered without touching the table:

CREATE INDEX idx_posts_covering ON posts(user_id, created_at, title);

-- This query is lightning fast
SELECT title, created_at FROM posts WHERE user_id = 123 ORDER BY created_at DESC;

Strategy 2: Conditional Indexes with Expressions

You can index the result of a function:

CREATE INDEX idx_lower_email ON users(LOWER(email));

-- Now this is fast
SELECT * FROM users WHERE LOWER(email) = 'prayush@example.com';

Strategy 3: Index Hints (Use Sparingly)

Sometimes the query planner gets it wrong. In MySQL:

SELECT * FROM users USE INDEX (idx_email) WHERE email = 'x';

But honestly, if you need hints, you probably need better indexes.

Strategy 4: Monitoring Index Usage

Find unused indexes and kill them:

-- PostgreSQL
SELECT schemaname, tablename, indexname, idx_scan
FROM pg_stat_user_indexes
WHERE idx_scan = 0;

I do this every month. Found 15 unused indexes once. Dropped them all, freed up 2GB of space.

Real-World Example: My Blog Optimization

Let me show you something from an actual project. I have a blog posts table:

CREATE TABLE posts (
    id SERIAL PRIMARY KEY,
    user_id INTEGER,
    title VARCHAR(255),
    content TEXT,
    status VARCHAR(20),
    created_at TIMESTAMP,
    updated_at TIMESTAMP
);

Initial problem: Homepage query was taking 800ms to load recent posts.

SELECT * FROM posts 
WHERE status = 'published' 
ORDER BY created_at DESC 
LIMIT 10;

My indexing solution:

-- Partial index for published posts only
CREATE INDEX idx_published_posts ON posts(created_at DESC) 
WHERE status = 'published';

-- For author pages
CREATE INDEX idx_author_posts ON posts(user_id, created_at DESC)
WHERE status = 'published';

-- For full-text search
CREATE INDEX idx_post_search ON posts 
USING GIN(to_tsvector('english', title || ' ' || content));

Results:

Homepage: 800ms → 12ms
Author pages: 450ms → 8ms
Search: Actually works now (was timing out before)

Three strategic indexes. Not twelve random ones. That's the key.

The Practical Checklist

Here's what I do for every new table:

Primary key gets an index automatically (don't create one manually)
Foreign keys ALWAYS get indexed

   CREATE INDEX idx_posts_user_id ON posts(user_id);

Columns in WHERE clauses get indexed (if the query runs often)
Columns in ORDER BY get indexed (especially with LIMIT)
Run EXPLAIN ANALYZE on slow queries before creating indexes
Monitor index usage monthly and drop the dead ones

Tools I Actually Use

pgAdmin

For PostgreSQL, pgAdmin's query analyzer is solid. Shows you exactly what's happening.

MySQL Workbench

Same thing for MySQL. The visual EXPLAIN is chef's kiss.

Database Monitoring

I run a self-hosted Grafana dashboard that tracks:

Query execution times
Index usage stats
Table scan counts
Cache hit ratios

Want a tutorial on setting this up? Let me know because monitoring is half the battle.

The Bottom Line

Indexing isn't rocket science, but it's not something you can just wing either. Here's the real strategy:

Start without indexes (except primary keys and foreign keys)
Build your app, collect real usage data
Find the slow queries (EXPLAIN ANALYZE is your friend)
Add indexes strategically
Monitor and adjust
Don't over-optimize early

And remember: the best index is the one that solves a real performance problem. Not the one that looks cool in your schema.

Let's Connect

I'm Prayush Adhikari, grinding through computer engineering and breaking down complex topics into actually useful content. If database performance gets you excited (or frustrated), you're in the right place.

Got questions? Want me to cover something specific about databases? Drop a comment. I read every single one.

LinkedIn: adhikareeprayush
GitHub: adhikareeprayush
Portfolio: prayushadhikari.com.np

Next up, I'm thinking about diving into database sharding or maybe query optimization techniques. What would you rather read about? Let me know.

Now go index something. But not everything.

Setting Up Your Command Line Assistant with Google Services (The Complete Guide)

Prayush Adhikari — Tue, 04 Nov 2025 07:27:06 +0000

Hey there! Welcome back. It's been a minute since my last blog on 7 Productivity Hacks That Changed My Life. Remember hack number 3? The wild command line assistant that manages your entire Google workspace from the terminal?

Yeah, that one blew up in the comments. Everyone wanted the full breakdown. So here it is, the complete no-BS guide to setting up your own command line assistant with access to Gmail, Google Drive, Calendar, and basically your entire Google ecosystem.

Why This Setup is Absolutely Insane

Before we dive in, let me paint you a picture of what your life looks like once this is running:

Send emails without ever opening a browser
Schedule meetings with a single command
Upload files to Drive from your terminal
Search your Gmail like you're querying a database
Manage calendar events faster than you can say "productivity"

And the best part? It's all happening in your terminal. No clicking. No switching windows. Just pure, efficient command-line magic.

What You'll Need (The Boring But Necessary Stuff)

Look, I'm not gonna sugarcoat it. You need:

A computer (obviously)
Stable internet connection (wild requirement in 2024, I know)
Basic familiarity with terminal/command line
A Google account
About 30-45 minutes to set this up properly

One-time setup, lifetime benefits. Let's go.

Step 1: Install Gemini CLI (And Why Version Matters)

Here's where most people mess up. You can't just install the latest version and call it a day.

Why Gemini CLI?

Simple. It integrates seamlessly with Google Apps Script, giving us a robust MCP (Model Context Protocol) server for our command line agent. The integration is chef's kiss level smooth.

The Version Trap:

I spent hours debugging before I figured this out. You MUST use version 0.1.12. The latest versions? Broken. Buggy. Frustrating.

Save yourself the headache and install the specific version:

npm install -g @google/generative-ai-cli@0.1.12

Verify it installed correctly:

gemini --version

You should see 0.1.12. If not, uninstall and try again.

Step 2: Set Up Google Cloud Console (The Foundation)

This is crucial. Don't skip this step or you'll run into permission issues later.

Create Your Project:

Head over to Google Cloud Console
Click "New Project" in the top dropdown
Name it something memorable (I called mine "CLI-Assistant")
Click Create

Enable the APIs:

You need to enable these APIs for your project:

Go to "APIs & Services" > "Library"
Search and enable each of these:
- Gmail API
- Google Drive API
- Google Calendar API
- Google Docs API (optional but recommended)
- Google Sheets API (optional but recommended)

Generate Your Gemini API Key:

In the Cloud Console, go to "APIs & Services" > "Credentials"
Click "Create Credentials" > "API Key"
Copy this key somewhere safe (you'll need it multiple times)
(Optional but recommended) Click "Restrict Key" and limit it to only the APIs you enabled

Pro tip: Keep this key private. Like, seriously private.

Step 3: Create Your Google Apps Script

Time to build the brain of the operation.

Set Up the Project:

Go to script.google.com
Click "New Project"
Name it something like "MCP Server for CLI"

Write the Code.gs File:

Delete the default code and paste this:

const apiKey = "YOUR_GEMINI_API_KEY_HERE";

const doPost = (e) => main(e);

function main(eventObject) {
  const m = ToolsForMCPServer;
  m.apiKey = apiKey;

  // Enable the tools you want to use
  // Play around with these flags
  m.enableBaseTools = true;
  m.enableClassroomTools = false;
  m.enablePeopleTools = false;
  m.enableAnalyticsTools = false;
  m.enableMapsTools = false;

  const object = { eventObject, items: m.getServer() };
  return new MCPApp.mcpApp({ accessKey: "sample" })
    .setServices({ lock: LockService.getScriptLock() })
    .server(object);
}

Replace YOUR_GEMINI_API_KEY_HERE with the API key you generated earlier.

About those flags:

enableBaseTools: This is the core. Gmail, Drive, Calendar. Keep this true.
The others are specialized. Enable them if you need Classroom, Analytics, or Maps integration.

Create the appsscript.json File:

This is where permissions live. It's critical.

In your Apps Script project, click "Project Settings" (gear icon)
Check "Show 'appsscript.json' manifest file in editor"
Go back to the editor, you'll see appsscript.json appear
Replace its contents with this:

{
  "timeZone": "YOUR_TIMEZONE_HERE",  // e.g., America/Los_Angeles
  "exceptionLogging": "STACKDRIVER",
  "runtimeVersion": "V8",
  "dependencies": {
    "enabledAdvancedServices": [
      {
        "userSymbol": "Drive",
        "serviceId": "drive",
        "version": "v3"
      },
      {
        "userSymbol": "Gmail",
        "version": "v1",
        "serviceId": "gmail"
      },
      {
        "userSymbol": "Calendar",
        "version": "v3",
        "serviceId": "calendar"
      }
    ],
    "libraries": [
      {
        "userSymbol": "MCPApp",
        "libraryId": "1TlX_L9COAriBlAYvrMLiRFQ5WVf1n0jChB6zHamq2TNwuSbVlI5sBUzh",
        "version": "18"
      },
      {
        "userSymbol": "ToolsForMCPServer",
        "libraryId": "1lnE7UL1jQgPDbTB9yjhiwZM0SaS9MObhzvWUWb_t8FisO6A3bLepvM2j",
        "version": "39"
      }
    ]
  },
  "webapp": {
    "executeAs": "USER_DEPLOYING",
    "access": "ANYONE_ANONYMOUS"
  },
  "oauthScopes": [
    "https://www.googleapis.com/auth/gmail.modify",
    "https://www.googleapis.com/auth/gmail.send",
    "https://www.googleapis.com/auth/drive",
    "https://www.googleapis.com/auth/drive.file",
    "https://www.googleapis.com/auth/calendar",
    "https://www.googleapis.com/auth/calendar.events",
    "https://www.googleapis.com/auth/spreadsheets",
    "https://www.googleapis.com/auth/documents",
    "https://www.googleapis.com/auth/presentations",
    "https://www.googleapis.com/auth/forms",
    "https://www.googleapis.com/auth/script.external_request"
  ]
}

Important notes:

Change timeZone to your timezone
The oauthScopes are the permissions. This setup requests access to Gmail, Drive, Calendar, Docs, Sheets, etc.
The libraries (MCPApp and ToolsForMCPServer) are essential. Don't change these IDs.

Save everything (Ctrl+S or Cmd+S).

Step 4: Deploy Your Script

This is where your code becomes accessible.

In Apps Script, click "Deploy" > "New deployment"
Click the gear icon next to "Select type"
Choose "Web app"
Fill in the details:
- Description: "MCP Server v1" (or whatever you want)
- Execute as: "Me"
- Who has access: "Anyone"
Click "Deploy"
Authorize the app (Google will ask you to review permissions)
- Click "Review Permissions"
- Choose your Google account
- Click "Advanced" (if it says the app is unverified)
- Click "Go to your project name"
- Click "Allow"
Copy the Web App URL that appears. It looks like: https://script.google.com/macros/s/SOME_LONG_ID/exec

Keep this URL handy. You're almost there.

Step 5: Configure Gemini CLI to Use Your MCP Server

Now we connect everything together.

Initialize Gemini CLI:

Open your terminal and run:

gemini config

Follow the prompts to set up your Gemini API key if you haven't already.

Add the MCP Server:

Run:

gemini

Once Gemini CLI starts, type:

/mcp

This opens the MCP configuration menu. Follow the interactive prompts:

Choose "Add new MCP server"
Enter a name: google-services (or whatever you prefer)
Paste your Web App URL from Step 4
Confirm the configuration

Test the Connection:

Try a simple command:

Check my latest emails

Or:

What's on my calendar today?

If it works, you'll see Gemini accessing your Google services and returning results. If not, double-check:

Your API key is correct in Code.gs
The Web App URL is correct
You authorized the script properly

Step 6: Start Living in the Future

You're done. Seriously. Now you can:

Send Emails:

Send an email to john@example.com with subject "Meeting Tomorrow" and body "Hey John, are we still on for 3pm?"

Schedule Meetings:

Create a calendar event for tomorrow at 2pm titled "Team Standup"

Search Gmail:

Find all emails from boss@company.com from last week

Upload to Drive:

Upload document.pdf to my Google Drive

And So Much More

The possibilities are endless. The more you use it, the more you'll discover what's possible.

Pro Tips and Troubleshooting

Common Issues:

"Permission denied" errors:

Go back to your Apps Script and re-deploy with fresh permissions
Make sure all APIs are enabled in Google Cloud Console

"Version mismatch" errors:

Confirm you're using gemini-cli version 0.1.12
Uninstall and reinstall if needed: npm uninstall -g @google/generative-ai-cli && npm install -g @google/generative-ai-cli@0.1.12

MCP server not responding:

Check your Web App URL is correct
Make sure the deployment is set to "Anyone" access
Verify your API key is valid

Make It Better:

Customize the flags in Code.gs based on what you actually use
Add more oauth scopes if you need access to other Google services
Create aliases in your shell for common commands
Experiment with different prompts to see what works best

The Real Impact

Here's what changed for me after setting this up:

I send emails 5x faster
Scheduling meetings takes seconds instead of minutes
I never lose track of files because I can search Drive from anywhere
My workflow is completely keyboard-driven (no more mouse clicking through UIs)

It's not just about speed. It's about staying in flow. When you can do everything from the terminal, you're not context-switching. Your brain stays focused. That's the real productivity boost.

What's Next?

Want me to dive deeper into:

Custom automation workflows with this setup?
Advanced MCP server configurations?
Integrating other services beyond Google?

Drop a comment and let me know what you want to see next.

Let's Connect

I'm Prayush Adhikari, computer engineering student and productivity nerd. I'm documenting my journey of building systems that actually work.

If this guide helped you (or if you got stuck somewhere), let's connect:

LinkedIn: adhikareeprayush
GitHub: adhikareeprayush
Portfolio: prayushadhikari.com.np

Drop a comment below with:

Which part of the setup you found most useful
What you're automating first
What guide you want next

Thanks for reading! Now go build something that makes your life easier.

P.S. If you're stuck on any step, drop a comment. I read and respond to everything.

7 Productivity Hacks That Changed My Life (And Will Change Yours Too)

Prayush Adhikari — Wed, 15 Oct 2025 08:19:43 +0000

Hey there! I am glad you ended up here. Look, I've tried every productivity hack under the sun, and most of them? Complete garbage. But the ones I'm about to share? These actually work. And I'm using them right now as I write this.

Let's Talk About Productivity (The Real Deal)

I like to be productive and who doesn't? But wtf is productivity in the first place?

Here's the thing most people get wrong: productivity isn't about grinding 16 hours a day or having 47 tabs open while pretending to multitask. It's about doing things more efficiently or better yet, doing repetitive things more efficiently.

And no, efficiency isn't just speed. It's about finding the best approach to get the best possible result. Sometimes that means slowing down to automate something that'll save you hours later.

Since we have gone through some of the basics, lets dive into the actual hacks that have transformed how I work.

The Hacks That Actually Matter

1. Ditch Chrome, Seriously

One of the unavoidable things in our life is a web browser. We're constantly living in our browsers when we're online. I have tried almost all the web browsers out there and have finally settled on one that doesn't make me want to throw my laptop out the window.

Enter Vivaldi.

Yeah yeah, it eats 2-3gb of RAM like it's nothing, but hear me out. If your computer has 16gb+ RAM or you're already using Chrome (which is basically a RAM black hole), you need to try this.

Why Vivaldi slaps:

It's chromium based so all your favorite extensions work
Mouse gestures that make you feel like a wizard
Keyboard shortcuts for literally everything
Multiple workspaces to keep your 600 tabs organized
Themes that don't look like they're from 2010
Zero bugs in my experience (and I push software to its limits)

The customization is insane. You can make it look and work exactly how your brain operates. And that's the key to productivity, working with tools that match your workflow, not against it.

2. Automate Your Social Media Like a Boss

Social medias like Discord and Telegram are goldmines for automation. And no, you don't need to be a coding wizard to make this happen.

I've been running self-hosted n8n on my VPS and it's changed the game. Here's what I've built:

Stream Suggester - Because decision fatigue is real
Gemini in Telegram - My AI buddy on the go
Techy - Sends me tech news from multiple RSS feeds automatically

The best part? You set it up once and forget about it. While everyone else is manually checking feeds and posting updates, you're three steps ahead.

Want me to drop a full tutorial on setting up n8n locally or on a VPS? Drop a comment and let me know because this deserves its own deep dive.

3. Command Line Assistant (This One's Wild)

Alright, here the things go pure wild. I have a command line assistant that basically runs my digital life. I'm talking:

Creating Google meetings with a single command
Adding calendar events instantly
Scanning my Gmail for important stuff
Sending emails without opening a browser
Managing all Google services from the terminal

This setup is chef's kiss level productivity. Here's the quick rundown:

The Setup (Simplified):

Install gemini-cli (the MCP server integration is smooth)
Create a Google Apps Script (hit me up if you want my exact script)
Configure Google Cloud Console permissions
Grab your Gemini API key
Authorize and boom, you're living in the future

This needs its own blog because the full process is meaty, but trust me, once you have this running, you'll feel like Tony Stark.

4. Your IDE Matters More Than You Think

Hot take: Your code editor can make or break your productivity.

I use Neovim and yes, I know what you're thinking. "Oh great, another Neovim evangelist." But hear me out.

I felt the exact same way when people recommended it to me. Thought they were just trying to be elitist. But after customizing it with the right plugins, I'm never going back.

Real talk though: Don't just jump into Neovim cold turkey. Use VS Code AND Neovim side by side at first. Slowly transition when you're comfortable. The learning curve is real, but the productivity gains are worth it.

Want a Neovim setup tutorial? Let me know and I'll break down my entire config.

5. Build Your Second Brain

Obsidian has changed how I think.

No, seriously. Having all your knowledge in one searchable, linked system is like having superpowers. And the best part? It's completely free if you set up sync yourself (I wrote a whole blog about this).

Why Obsidian wins:

Massive community plugins
Works on all devices
Free sync if you're smart about it
Everything is markdown (lightweight and future-proof)
Themes that don't hurt your eyes
Integration with everything

Your brain isn't meant to remember everything. It's meant to make connections. Let Obsidian handle the storage, you handle the thinking.

6. Your Terminal Shouldn't Suck

One of the biggest headaches was my terminal. I wanted it to look cool, suggest past commands, and generally not feel like I time-traveled to 1995.

Solution? Zsh with oh-my-zsh.

The productivity boost is subtle but massive. Auto-suggestions, better history, plugins for days, and honestly, when your terminal looks good, you want to use it more. And the more comfortable you are in the terminal, the more powerful you become.

It has surely helped me become more productive without even realizing how much I've improved at command line.

7. Make The Switch to Linux (Yes, Really)

I would highly recommend all of you to switch to Linux on your personal computers. And no, I'm not one of those "I use Arch btw" people (okay maybe a little).

Here's why Windows is holding you back:

Less secure by design
Bloated with stuff you'll never use
Ads in the START MENU (seriously Microsoft?)
Limited customization
Constant forced updates at the worst times
You don't actually own your OS

Linux gives you:

Complete control
No bloat
Better security
Customization freedom
Better performance
Actually free (as in freedom)

Need help choosing a distro? Want a full guide on making the switch? Drop a comment. I can write a whole series on this.

The Real Secret

Here's what nobody tells you about productivity: it's not about the tools. It's about designing systems that work FOR you, not against you.

Every hack I've shared comes down to one thing: removing friction. The less mental energy you spend on repetitive tasks, the more you have for what actually matters.

So start with one hack. Just one. Get it working. Then move to the next. Don't try to overhaul your entire workflow overnight because that's how you end up productive for exactly two days before burning out.

Let's Connect

I'm Prayush Adhikari, currently grinding through computer engineering and building my online presence one blog at a time. I'm bringing more content like tutorials, deep dives, and honest takes on tech.

If this helped you (or if you think I'm completely wrong about something), let's connect:

Drop a comment below with which hack you're trying first
Follow me for more content that actually helps
Share this if you know someone stuck in productivity hell

Connect with me:

Linkedin: adhikareeprayush
Github: adhikareeprayush
Portfolio: prayushadhikari.com.np

What productivity hack should I cover next? Let me know in the comments.

Thanks for reading! Now go automate something.

Stop Paying for Obsidian Sync: Here's How I Actually Did It

Prayush Adhikari — Mon, 06 Oct 2025 19:26:04 +0000

So you've fallen into the Obsidian rabbit hole. Good. Now you're realizing that having your notes on just one device is annoying as hell, and Obsidian wants $10/month to fix that problem.

I get it—the devs deserve support, they built something genuinely useful. But I'm also not about to pay a subscription for syncing text files. Yes, I said it. That's all your vault is. A bunch of .md files sitting in a folder.

So I rolled my own sync setup with Syncthing-Fork, and it's been running flawlessly across my laptop, phone, and a VPS for months. Zero cost, zero drama. Let me show you how.

The Beauty of Obsidian: It's Just Files

Here's why this works at all: Obsidian doesn't trap your data in some proprietary hellscape. Your vault is literally just a folder on your filesystem. Open it. Look at it. Those are markdown files. You could edit them in Notepad if you wanted to punish yourself.

This isn't revolutionary—it's how software should work. But in 2025, when every app wants to be a SaaS product with your data held hostage on their servers, Obsidian's approach feels almost rebellious.

No database. No API calls to authenticate your right to access your own thoughts. Just files and folders, like it's 1995 and we still believed in owning our data.

Which means if you can sync a folder, you can sync your entire Obsidian vault. And you absolutely can sync a folder without giving someone money every month.

Syncthing-Fork: The Unsexy Solution That Actually Works

Syncthing is that rare piece of software that does one thing, does it well, and doesn't try to upsell you on AI features or premium tiers. It's open source, peer-to-peer, and once you set it up, you genuinely forget it exists.

Syncthing-Fork is the Android variant that actually gets maintained.

What sold me: I edit a note on my phone at 2 AM because my brain won't shut up. By the time I walk to my desk in the morning, that note is already on my laptop. No sync button. No "waiting for upload." It just is.

The whole thing runs device-to-device. Encrypted. No cloud middleman harvesting your data to train their next AI model.

My Setup: Three Devices Playing Nice

I'm running this across:

Laptop (Arch BTW)
Android phone (Syncthing-Fork from Nickola Hristov)
VPS (Docker container, always online)

The VPS is technically optional. But here's the thing: if my laptop's off and I change something on my phone, the VPS catches it immediately. Then when my laptop wakes up, it syncs from the VPS. It's basically a relay that ensures changes never get stuck in limbo. I am also planning to use static site generator out of .md files for future so it will be helpful ig.

Plus it's an automatic off-site backup. My laptop could spontaneously combust and my vault's still sitting on that VPS.

How I Actually Set This Up

Making Syncthing Run Without Thinking About It

Laptop: Installed Syncthing, made it a systemd service so it starts on boot. I never want to manually start this thing. If I have to remember to run it, I'll forget, and then I'll have sync conflicts. Automate or die.

VPS: Spun up a Docker container. Wrote a basic docker-compose.yml, ran it, forgot about it. Docker handles restarts, keeps it isolated, makes updates trivial. The VPS isn't doing anything else demanding—it's just sitting there being reliable, which is what servers are actually for.

Phone: Installed Syncthing-Fork, gave it the permissions it was crying about, set it to auto-start. Battery impact is negligible. We're syncing text, not mining crypto.

The Connection Dance

Every Syncthing instance has a device ID. I added all three devices to each other. Think of it like exchanging SSH keys, except it's actually user-friendly.

Then I pointed Syncthing at my Obsidian vault folder and told it to share that folder with all my devices. That's it. That's the setup.

Watching It Actually Work

Change a file on any device. Syncthing detects it within seconds. The change propagates to the other devices. Obsidian notices the file changed and updates its view.

It's not magic—it's just file watching and network sockets. But it feels magic when you're used to cloud sync services that randomly decide they need five minutes to "think about it."

Why Syncthing Doesn't Suck

Block-level syncing means it only transfers what changed. Edit one paragraph? It sends that delta, not the entire file. This matters when you're on mobile data or have a 50MB vault full of images.

Conflict handling is reasonable. If you somehow edit the same file on two disconnected devices (how?), it creates a conflict copy instead of randomly picking a winner. You manually merge. Annoying, but better than silent data loss.

Everything's encrypted in transit. Your existential crisis notes aren't flying across the internet in plaintext for your ISP to judge.

The VPS Piece

Two devices can sync directly without a VPS. Phone talks to laptop when both are online. But the VPS makes this bulletproof.

I'm paranoid about losing data. Having an always-online third node means changes always have somewhere to go. Plus, it's offsite. My apartment could burn down and my notes would survive.

Running in Docker is just good practice. Isolated, reproducible, updateable. One docker-compose up -d and it's running forever.

What This Actually Feels Like

I've been running this for months. I don't think about it. That's the highest compliment I can give any infrastructure.

I dump thoughts into Obsidian on my phone while walking. Those thoughts are on my laptop by the time I get home. I refactor my notes at my desk, and they're on my phone instantly. The VPS quietly keeps everything synchronized without me ever SSHing in to check on it.

Zero conflicts. Zero "oops, I edited the old version" moments. Zero subscription fees.

If You're Technical Enough to Care

You're probably already sold or already running something similar. If you're on the fence: one Saturday afternoon to set this up, then you never think about it again.

No subscription. No trusting a third-party with your data. No wondering if the sync service will still exist in five years or if they'll get acquired and enshittified.

Just files, syncing between your devices, like we've been doing since rsync was invented.

If you're still paying for Obsidian Sync after reading this... I mean, that's your choice. But at least know you have options.

Lets Connect:
LinkedIn
Github
Portfolio

Top 10 Visual Studio Code Extensions for Enhanced Productivity

Prayush Adhikari — Sat, 28 Sep 2024 13:25:00 +0000

Top 10 VS Code Extensions You Absolutely Need (or Else!)

So, you’ve hopped on the Visual Studio Code train, huh? Welcome aboard! It’s sleek, it’s lightweight, and, oh boy, those extensions! They’re like sprinkles on a cupcake—totally necessary. Whether you’re a coding wizard or still figuring out the difference between a variable and a function, here’s a curated list of the top 10 VS Code extensions that you should definitely check out (because why not?).

1. Prettier - Code Formatter

Ever looked at your code and thought, “Yikes, what a mess”? Prettier is here to save the day! This opinionated code formatter works its magic on multiple languages, enforcing a consistent style. It's like having a professional organizer for your codebase. Trust me, your team will thank you (and maybe even throw you a party).

Get Started with Prettier!

2. ESLint

For all you JavaScript and TypeScript aficionados, ESLint is like that annoying friend who always points out your mistakes—except this one helps you write cleaner code. It spots and fixes issues in real-time, so you can avoid those embarrassing “uh-oh” moments during code reviews.

Learn More About ESLint

3. Live Server

Web developers, rejoice! The Live Server extension is your best friend. It sets up a local server and gives you live reload capabilities. So while you're frantically changing your HTML, CSS, and JavaScript, you’ll see those changes in real-time. No more refresh, refresh, refresh. Just sit back and watch the magic unfold!

Check Out Live Server

4. GitHub Copilot

Imagine having an AI-powered coding buddy who gets your coding style. GitHub Copilot offers suggestions for entire lines of code or functions, helping you tackle repetitive tasks and even suggesting cool solutions you might not have thought of. It’s like magic for your code!

Explore GitHub Copilot

5. Docker

For those of you diving into the world of containers (not the ones you keep your leftovers in), the Docker extension is a game changer. Manage and deploy Docker containers right from VS Code like a boss. It’s like having a personal assistant for your containerized applications, minus the coffee runs.

Get Docker Here

6. Vim

If you’re a fan of Vim’s powerful keybindings, you’re in luck. The Vim extension brings all those shortcuts to VS Code, so you can navigate and edit like a pro without ever lifting your fingers from the keyboard. It’s like giving your IDE superpowers, and you’ll feel unstoppable!

Try Vim for VS Code

7. Auto Rename Tag

For all the HTML/XML folks out there, Auto Rename Tag is a lifesaver. It automatically updates paired tags when you edit one of them, helping you avoid mismatches and keeping your code neat. It’s like having a cleanup crew for your tags.

Check Out Auto Rename Tag

8. Error Lens

Let’s face it: errors are a fact of coding life. But Error Lens makes spotting them way easier by showing error and warning messages directly in your code, right where the problem is. No more scrolling around looking for the issues—just fix it and move on!

Get Error Lens

9. CodeSnap

Love sharing your code online? CodeSnap makes it simple to take beautiful screenshots of your code, perfect for blog posts, social media, or documentation. Say goodbye to clunky screenshots and hello to polished, professional snaps.

Get CodeSnap

10. Thunder Client

Testing APIs has never been easier! Thunder Client is a super-lightweight REST API client right inside VS Code, making it a fantastic alternative to bulky tools like Postman. Test APIs without ever leaving your editor.

Discover Thunder Client

If you're looking to elevate your development experience with these extensions and more, feel free to check out my link to Visual Studio Code. It’s a fantastic resource that can help you get set up and make your coding life smoother than ever. So, gear up, download VS Code, and let’s make some code magic happen!

Join the PrayushDev Community!

Before you go, I'm excited to announce the launch of my weekly newsletter: PrayushDev! 🎉

Why should you subscribe? Here's what you'll get:

Bite-sized introductions to hot tech topics
Insider tips and tricks from the world of development
Early access to upcoming "React Unmasked" episodes
A chance to be part of a growing community of passionate devs

Don't miss out on this opportunity to stay at the cutting edge of tech. Subscribe now and let's grow together!

Portfolio: prayushadhikari.com.np