Forem: Konark Sharma

Vibe Coding Lessons Nobody Talks About

Konark Sharma — Wed, 06 May 2026 18:17:50 +0000

I love vibe coding and whenever I get bored, I vibe-code some websites for myself or for Dev Challenges.

I’m a little late sharing these because I wasn’t sure if I should even post them here. Most people are deploying huge full-stack apps with massive user bases, while my vibe-coded projects felt small in comparison.

But then I realized something. I’m proud of what I built. Not because these projects are extraordinary, but because I somehow managed to turn an idea in my head into a deployed app.

And honestly, that itself feels amazing.

When I first started vibe coding, I was terrible at it. I hated it. The outputs were messy, the hallucinations were frustrating, and nothing looked the way I imagined it.

But the more I built, the more I started understanding the pros and cons of vibe coding.

The biggest thing I learned is this: If you prompt properly, you can turn your ideas into real products. If you don’t, you’ll end up with a mess you won’t even want to show people.

So over time, I started learning small lessons and tiny tricks that helped me get much closer to the vision in my head.

These are some lessons from my experience so far, and feel free to share yours as well because I’m still learning too.

1. Clarity

Before turning my idea into a "$50,000 vibe-coded app," I always start with brainstorming sessions.

First with myself. Then with AI.

The reason for brainstorming is simple. I want multiple ideas so I can choose the one I actually want to build. For the April Fool Dev Challenge, the idea was to build something useful yet useless.

So I started brainstorming.

I got many ideas, but none of them really matched the challenge properly.

Then after thinking more, I came up with SpaceEstate, a website where you can purchase land in space.

Usually, I get 2–3 ideas I genuinely like and then I start writing:

Workflows
MVP ideas
How it should look
How it should feel to users

This helps me narrow down what I actually want to work on.

Then comes AI.

Sometimes I’m blank during challenges, and I need help understanding what can actually be built around the topic. AI helps me research ideas, improve concepts, and think differently.

After all the brainstorming and research, I choose the final idea and start vibe coding.

Lesson

Always be clear about your idea before building. Make a small plan, define the workflow, and create a rough design for clarity.

2. The Perfect Vibe Coding Tool Is?

This is honestly my favorite topic to talk about.

The perfect vibe coding tool is...There isn’t one.

The reality is that there’s no such thing as a perfect vibe coding tool. It all depends on the user, their prompting ability, their patience, and yes... tokens too.

You need the ability to make something out of nothing.

For example, if Claude shuts down tomorrow, does your entire workflow collapse with it? Or can you move to another tool and still make your ideas visible?

Initially, I used Gemini Studio, but I felt it had limitations. Then I moved to Antigravity and again felt the tool had limitations.

But later I realized the issue wasn’t always the tool.

Sometimes the issue was:

My prompts
My expectations
My inability to explain what I wanted properly

That changed how I think about vibe coding completely.

Now I believe the real power of a vibe-coded app lies in the hands of the person building it, not just the tool itself.

I used Gemini Studio to build SpaceEstate, and I genuinely loved the result. Funny enough, I was the same person who hated it initially for being "too dumb."

Lesson

Improve yourself before blaming the tool.

3. Prompts

Prompts play a massive role in vibe coding. If you are not good at prompting, you will most likely get mediocre outputs and then blame the tool for it.

The code generated depends on your prompts. A better prompt gets you closer to your actual vision. A weak prompt gives hallucinations, random UI decisions, or completely different outputs.

When I first started vibe coding, I used to hate it because the outputs always deviated from my vision. I got frustrated and blamed the tool instead of improving my prompts.

But after learning how prompting actually works and watching how others structure prompts, I started getting outputs much closer to what I imagined. The hallucinations reduced too.

And honestly, I feel the day you improve your prompts is the day your ideas start turning into reality faster. One of the best tricks I learned is using AI to improve my prompts first.

The generated prompts become:

Tighter
More structured
More specific
Easier for the AI to follow

Instead of: “Do this, do that”

It becomes: “Follow these steps carefully.”

Lesson

Better prompts create better results.

4. Errors and Hallucinations

Do hallucinations and random errors still frustrate you while vibe coding? Because they used to frustrate me a lot.

But one small trick genuinely helped me reduce hallucinations massively. Whenever I want a specific change, I end the prompt with: “Do this only.”

That one line helped more than I expected. It prevents the AI from randomly editing unrelated things and keeps the changes focused.

Another thing I started doing is mentioning the exact file name where I want changes. This narrows the edits and protects the rest of the project from unnecessary modifications.

These tiny tricks saved me from so much frustration.

For errors, I usually paste the error directly and ask the AI to fix it. Most of the time, it works.

And honestly, if the error is minor and doesn’t affect functionality, sometimes I just leave it alone.

Like they say: “If the code works somehow, don’t touch it.”

Lesson

Small prompt hacks can massively reduce hallucinations.

5. Quality Over Quantity

This is something I partially disagree with. Because honestly, quality comes after quantity.

Most of the lessons I learned came from building many vibe-coded apps.Tiny tricks that seem small actually create huge improvements over time.

For example: Adding “Do this only” in prompts helped reduce hallucinations massively for me.

Another example: I initially vibe coded using Gemini Studio, then moved to Antigravity. And Antigravity genuinely felt like VS Code on steroids because I could install libraries, customize workflows, and push things much further.

That flexibility changed a lot for me.

Recently, I also started learning about:

Agents
Skills
Vibe-Coded Websites

And I already found a few workflows that give a huge edge while vibe coding. There’s honestly a lot to learn and a lot to build.

So I’ll keep building, keep learning, and keep sharing those lessons too.

Lesson

Build. Break. Learn. Repeat.

6. Some Ideas Don’t Come to Reality

There were many times when I dropped ideas midway for different reasons.

Sometimes I stopped liking the idea while building it. Sometimes the vibe just didn’t feel right anymore. Sometimes the app didn’t turn out the way I imagined it in my head. And sometimes random errors kept appearing and completely killed the excitement of building it.

The reason could be anything, but the result was the same: Abandoning the idea and moving on to another one.

Earlier, this used to happen to me a lot. I would start building something exciting, get stuck midway, overthink everything, and then leave it unfinished.

But over time, one thing changed for me. I started focusing more on finishing ideas instead of just starting them.

Now I try to carefully think through the project before I start vibe coding and push myself to take it from idea to deployment.

There were many ideas I abandoned because they were too ambitious or simply not good enough yet.

And honestly, that’s okay. Not every idea is meant to become reality.

The important thing is to keep building new ideas instead of regretting the old ones and thinking: “What if I had completed that?”

One thing that helps me a lot now is using AI during the ideation phase itself. I ask it:

Is this idea actually worth building?
Can this become an MVP?
Is this solving something meaningful?
Is this realistically possible right now?

That clarity saves me from wasting energy on ideas I don’t truly care about.

And one more thing I learned: Don’t stop at just coding. Deploy it.

Even if it’s imperfect.

Take a proud break after deployment and reflect on what you learned from it. Every abandoned project still teaches something.

Use those lessons in the next idea and make it even better.

Lesson

Not every idea needs to succeed. But every idea should teach you something.

My Vibe-Coding Journey

I went from this

Wheel of Fun is a playful web app designed to turn short boring breaks into quick moments of joy.

I built it as a simple way to add randomness into my routine. Instead of endlessly scrolling, I could spin a wheel and instantly get a small fun task like grabbing coffee, chatting with someone, or taking a quick walk.

The app features:

a responsive spinning wheel
carnival-style lights
smooth animations
confetti effects
a result modal

It was built entirely using HTML, CSS, and vanilla JavaScript without any backend. Simple, lightweight, and fun.

To This

The Seven is an interactive web experience inspired by Vought International’s superhero universe.

I built it to explore how modern frontend technologies can create immersive storytelling experiences.

Instead of creating a static showcase, I wanted users to feel like they were stepping into an actual corporate superhero universe.

The project includes:

cinematic UI
layered animations
dynamic character reveals
custom cursor interactions
smooth scrolling
parallax effects

I used:

React
TypeScript
Vite
Tailwind CSS

This project genuinely made me realize how far vibe coding can go when combined with strong frontend fundamentals.

And This

BiteMatch is a Tinder-style food discovery app built for live events and stadiums.

I created it to solve the problem of people getting overwhelmed by food choices at events.

So instead of scrolling endlessly, users swipe through food options like a dating app.

The app includes:

swipe interactions
food matching
animated reveal screens
smart recommendations
stall wayfinding
personality-based suggestions

Built with:

React
Vite
Tailwind CSS
Framer Motion

What makes this project special to me is that I built it within 3–4 hours while competing alongside many amazing builders.

And honestly, that’s what I love most about vibe coding. The speed at which ideas can become real.

Vibe coding is honestly one of the most fun things I started doing.

Not because it magically builds perfect apps, but because it helped me stop overthinking ideas and actually start building them.

Some projects turned out messy. Some broke completely. Some made me frustrated enough to close the tab and walk away.

But every single project taught me something.

The biggest lesson for me was realizing that vibe coding is not about replacing skills. It is about speeding up imagination.

The better your thinking, design sense, prompting, and development fundamentals become, the better your vibe-coded apps become too.

And honestly, seeing an idea that only existed in your head turn into a deployed website within hours still feels unreal to me.

I still have a lot to learn. But I’ll keep building, experimenting, breaking things, and sharing whatever I learn along the way.

Have you tried vibe coding yet? What’s the most fun, weird, or useful thing you have built with it?

I would genuinely love to see your projects and learn from your workflow too.

What’s Your Fear Score as a Developer?

Konark Sharma — Mon, 04 May 2026 20:22:48 +0000

Fear costs us everything.

I once heard this quote, “You miss 100% of the shots you don’t take,” and I really felt it in my career.

When I look back, I missed many opportunities just because I didn’t take a shot due to fear of not being good enough. I let them slide and watched someone else grab them and make something out of it.

So what fears am I talking about? Let's found out and find our fear score.

1. Fear of Missing Out (FOMO)

FOMO is the new fear in town, and it is slowly taking over everyone.

But what is FOMO doing in tech?

Tech has always lived with FOMO. Every new technology or tool gets picked up quickly because no one wants to miss out.

I remember when OpenClaw started booming. Suddenly, there were YouTube videos and articles everywhere. Everyone was writing about it, whether it was useful for them or not. Some were doing it for views, some because of FOMO.

If you feel FOMO, you need a reality check. Ask yourself: Am I writing or learning this because it aligns with me, or just because everyone else is doing it?

I also felt this. So I started learning and writing about topics more intentionally, trying to avoid blindly following trends and instead improve how I present myself.

How to reduce it

Set a trend filter rule: Only explore tech that aligns with your goals. Ignore the rest.
Follow a 70/20/10 model: 70 percent core skills, 20 percent adjacent, 10 percent experimental.
Schedule curiosity: Instead of reacting daily, review trends once a week.

2. FOBO (Fear of Becoming Obsolete)

This is one of the most common fears right now, especially after the rise of AI.

The classic thought is “AI will take our jobs.” But AI will only replace people who stop improving.

If you keep building skills that are hard to replace, you stay relevant.

Think of it like having multiple arrows in your arsenal. If one becomes obsolete, you pick another, sharpen it, and move forward.

Whenever I feel this fear, I try to make myself more valuable than AI by learning how to use it better and making it work for me.

How to reduce it

Stack skills instead of chasing tools: Combine domains like coding and product thinking.
Focus on fundamentals: Logic, systems thinking, and communication outlast tools.
Re-skill in cycles: Improve every 3 to 6 months instead of panic learning.

3. FUD (Fear, Uncertainty, and Doubt)

This is one of the most common internal fears.

It comes when you start questioning yourself:

Is my tech stack right ?
Are my projects good enough ?
Am I good enough for this company ?

Most people feel this, but no one talks about it.

This fear is dangerous because it slowly stops you from trying new things. You start holding back instead of taking risks.

I had this fear last year. I started working on it by attending events, talking to people in tech, building more projects, and sharing them on LinkedIn.

How to reduce it

Build proof over opinion: Instead of relying on what others say, build something real.
Follow adoption signals, not hype: Look at job postings and real usage instead of noise.
Time box your doubt: Give yourself a decision window and move forward.

4. FOCS (Fear of Choosing the Wrong Stack)

This fear comes when you choose a stack, start building, and then see others getting better opportunities with other stack.

You start questioning your choice. But the real issue is often not the stack.

It could be:

weak communication
basic projects
lack of depth

Before choosing a stack, ask yourself:

Do I like this
Do I see myself working on this long term

I started with MERN and never felt the need to switch just because others were doing something else.

How to reduce it

Choose proven defaults first: Stability matters more than novelty in the beginning.
Focus on learning, not perfection: Most skills are transferable.
Design for flexibility: Build systems where switching later is possible.

5. FOWO (Fear of Wasted Opportunity)

This fear comes from the past. Looking back and thinking: What if I had taken that chance

I have felt this a lot. In college, I often let my project partner lead everything. Because of that, I never got the chance to speak at big events or present my work.

I stayed in the background while others got the spotlight. Later, I realized how much I missed.

But I also learned from it.

Now, whenever I feel like participating, I do it. Whether it is a Dev challenge or building something random, I focus on the process. I experiment with tone as well. Some articles are fun, some are serious.

The important part is showing up.

How to reduce it

Shift your focus forward: Opportunities keep coming.
Act faster on small chances: Build a habit of taking action.
Document lessons: Turn regret into a system for better decisions.

My fear score is 4 out of 5. I still have work to do. But I am trying to get better and not let fear control my decisions.

Fear doesn’t disappear when you wait. It fades when you act. Take the shot.

What’s your fear score?

You’re Using GitHub Wrong (Here’s a Better Way)

Konark Sharma — Sat, 02 May 2026 19:24:19 +0000

Well, I have been on GitHub since 2019, even before the lockdown.

Back then, I did not properly use GitHub. I used to just make projects, upload the code, and share it with friends. But I never really understood the point of GitHub.

I think I missed my tutorials on GitHub. But now, I’ll share some key ways to actually make the best out of it.

1. Your GitHub Profile Is Your Developer Identity

Your GitHub profile is not just a bio page. It is your public engineering resume.

When I started using GitHub, I was amazed by it, but I mostly used it for uploading projects. I made my first GitHub profile page and thought it was great.

Then I met someone in my office, and they showed me their GitHub profile. It looked amazing.

That’s when I realized how much work I still had to do.

I went home, watched tutorials, explored profiles, and ended up mixing ideas from different places and curating my own profile. It felt like a mix fruit jam, but I liked it.

It’s not perfect, but it gets the job done.

Here’s my profile: GitHub

When someone visits your profile, they are not just looking at your code. They are evaluating:

How you think
What you build
How consistently you learn

What matters most

Profile README

This is the first impression. Use it to explain:

Who you are
What you are building
What technologies you use

Pinned Repositories

You only get a few spots, so use them wisely:

One strong project (your best work)
One learning project (shows growth)
One experimental or unique idea

Contribution Graph

It is not about being perfect. It is about consistency. A steady graph signals discipline more than perfection ever will.

You can check this article to create an amazing Profile Readme and check this Github repo for some inspiration.

The more creative you are, the more creative your profile should look. Since I like anime so much, I have kept mine mostly minimal anime themed.

Think of GitHub like LinkedIn, but here creativity is in your hands.

2. Basic GitHub Search (Most Underused Skill)

GitHub is not just a code host. It is a search engine for developers.

I love finding free and useful stuff on GitHub. Repositories, links, and the people behind them.

Earlier, I used to search on Google and then open GitHub links. Now I directly search on GitHub.

I search things like:

LLM projects
React projects
JavaScript projects

Most people search like this: react project . That barely scratches the surface.

Better usage

Filter by language
Sort by stars
Explore trending topics

Example searches

machine learning python project
react dashboard open source

This helps you find real world implementations, not just tutorials.

3. Advanced GitHub Search (Hidden Power Feature)

This is where GitHub becomes extremely powerful. I discovered this recently, and honestly, this was the seed for this article.

It felt like a secret door opened. Instead of random searching, you can filter like a pro.

Example queries

stars:200..5000 pushed:>2025 topic:system-design stars:<3000 "build your own" stars:200..10000

What this unlocks

Find active repositories
Avoid outdated or abandoned projects
Discover underrated tools before they go mainstream

This is how experienced developers find hidden gems early.

4. GitHub Trending vs Reality

The Trending page looks useful, but it can be misleading. I used to explore trending repositories and wonder what made them special.

The truth is: Trending = popularity spike. Not necessarily usefulness or depth.

What you should check instead

Last commit date (Is it active?)
Issue activity (Are people actually using it?)
Contributor count (Is it maintained?)

A small active repository is often more valuable than a large dead one.

5. How to Actually Learn From Repositories

I used to star many repositories to check later. But that “later” never comes. I think many developers can relate to this:

Star a repo
Maybe clone it
Forget about it

That is wasted potential.

A better approach

When you open a repository:

Read the README first
Check the examples folder
Look at issues (real problems users face)
Explore the architecture and folder structure

This turns GitHub into a learning platform, not just storage.

6. Finding Hidden Gems on GitHub

This was one of the main reasons behind this article. I was researching some repositories for my article and while exploring, I kept finding valuable repositories again and again. It almost felt like every new tab had something useful.

So I started noting them down.

If you want underrated, high value repositories

Do not rely only on Trending. Instead, search patterns like:

"build your own"
"system design notes"
"awesome"
"handbook"

Example

"build your own" stars:200..5000 "system design notes" stars:<5000

This is how you find repositories that are educational, not hype driven.

7. Follow Developers, Not Just Repositories

This is something I started doing recently. I began following developers whose work I found interesting. And it changed how I learn.

You start noticing:

How they write code
How they structure projects
How they write READMEs
What kind of problems they solve

Most people follow projects. Experienced developers follow people.

Why

Developers build multiple tools over time
Their starred repos reveal hidden resources
Their activity shows what is actually relevant

One good developer profile can lead you to 10 or more useful repositories.

8. Using Stars, Forks, and Watch Properly

These are not just buttons.

Stars = bookmarks + interest signal
Forks = experimentation or customization
Watch = staying updated on active development

Do not star everything. Use stars intentionally. I use stars to revisit repositories and learn from them later.

You can check my starred repositories. You might find something useful. Or share yours as well.

9. Turn GitHub Into a Learning System

These are things I have started doing to become a better developer:

Save repositories intentionally, not randomly
Revisit starred repositories monthly
Track what I actually learned
Explore one repository deeply every week

GitHub becomes powerful only when used consistently.

10. Contributions Show Real Understanding

Uploading code shows what you built. Contributions show how you think.

When you contribute to a repository, you are not just writing code, you are understanding someone else’s code, fixing real problems, and working with real-world standards.

It’s like joining someone else’s kitchen instead of cooking alone. You have to understand their process, their ingredients, and how they work before you can add anything.

Even small contributions matter. Fixing a typo in a README is like correcting a menu so customers don’t get confused. Improving documentation is like making instructions clearer for the next person walking in.

These small steps slowly build confidence, and over time, you start contributing more meaningfully.

GitHub is often treated like a code backup tool. But in reality, it is:

A discovery engine
A learning platform
A developer identity system
A map of modern software engineering

Most developers use GitHub. Very few actually use it properly.

Tell me your favorite GitHub repository?

System Design That Actually Makes Sense

Konark Sharma — Wed, 29 Apr 2026 19:11:38 +0000

I thought System Design was all about memorizing patterns for interviews. Turns out, that was the problem.

I used to think System Design was something abstract and only meant for interviews. But the more I learned, the more I realized it is actually about something very simple i.e. Handling growth.

Imagine you are opening a tiny pizza shop. At first, it is just you, a small oven, and a few neighbors stopping by. But what happens if suddenly 10,000 people want pizza at the exact same time?

That is the heart of System Design.

What is System Design and Why It Matters

System design is the process of defining the architecture, components, modules, interfaces, and data for a system to satisfy specific requirements. It is essentially creating a blueprint for a complex software system to ensure it is efficient, reliable, and scalable.

This is you drawing the floor plan for your pizza shop, deciding where the oven goes, how the pantry is organized, and how many chefs you need so the shop doesn't collapse when 1,000 customers show up.

Why It Matters in Real World Engineering

As developers level up, companies stop paying for just code and start paying for architectural decisions that handle high traffic and balance cost with performance.

A junior chef knows how to bake one pizza but a Senior Chef knows how to design a kitchen that can bake 500 pizzas an hour without the building catching fire.

Functional vs Non-Functional Requirements

Functional requirements are the specific features the system must offer (the "what"). Non-functional requirements are quality constraints like scalability, reliability, and security (the "how").

A functional requirement is "The user can order a pepperoni pizza.". A non-functional requirement is "The pizza must be ready in under 15 minutes" (latency) or "The shop must stay open even during a storm" (availability).

The technical trade-offs or limits you must work within, such as hardware capacity, budget, or the laws of physics.

You only have room for two ovens, or you cannot afford to hire 50 chefs.

How to Approach a Design Problem

Requirement Clarification

This is the process of asking questions to define the exact scope of a vague problem.

Before building the kitchen, you ask: "Are we a small local shop or a global delivery giant?"

Scope Definition

Deciding what features are included or excluded to manage complexity and time.

You decide, "Today we will focus on baking and delivery, but we will not build the pizza review system yet."

Back of the Envelope Estimation

Quick calculations to estimate the scale of the system, such as requests per second or storage.

If we have 10,000 customers and each orders one pizza, we need enough dough to make 10,000 pizzas every day.

Identifying Bottlenecks Early

Finding the slowest part of the system that will break first under heavy load.

You realize that even if you have 100 chefs, you only have one oven. That oven is your bottleneck.

Core System Concepts

Client-Server Architecture and Request Flow

A client-server model is where a client (like a browser) sends a request and a server responds to it.

The request lifecycle looks like this:

Customer places an order
Chef receives the order
Chef checks the pantry (database)
Pizza is prepared and sent back

The customer is the client. The pizza shop is the server.

Latency vs Throughput

Latency is the time it takes to complete a single action. Throughput is the number of actions completed in a given time.

Latency is how long you wait for your pizza. Throughput is how many pizzas the shop can make in one hour.

Vertical vs Horizontal Scaling

Vertical scaling is adding more power to a single machine. Horizontal scaling is adding more machines to share the load.

Vertical scaling is buying a super oven. Horizontal scaling is buying five ovens and hiring five more chefs.

Networking Basics

HTTP vs HTTPS

HTTP is the protocol used to transfer data. HTTPS is the secure version that encrypts that data.

HTTP is like shouting your order across the street. HTTPS is like handing your order in a locked briefcase.

DNS Resolution

DNS translates a domain name into an IP address.

You know the shop name, but DNS gives you the exact location so you can reach it.

TCP vs UDP

TCP is reliable and ensures data arrives correctly. UDP is faster but may lose some data.

TCP is like a pizza delivery where the rider waits until you confirm you received the order correctly. UDP is a promo flyer about pizza deals thrown at your door you might get it, you might not.

Load Balancers

A load balancer distributes incoming requests across multiple servers.

It is like a manager at the entrance telling customers which chef to go to so no one gets overwhelmed.

Data Storage Basics

SQL vs NoSQL

SQL databases store data in structured tables with fixed schemas. NoSQL databases are more flexible and can store data in multiple formats.

SQL is like a structured recipe book. NoSQL is like sticky notes where anything can be written.

When to Use Which

Use SQL when relationships and structure matter. Use NoSQL when data is large, flexible, and needs to scale quickly.

Use SQL for payments and orders. Use NoSQL for user-generated content.

Indexing

An index helps the database find data quickly. Instead of scanning everything, it jumps directly to the required data. It is like a table of contents in a book.

Instead of checking every order slip, the chef uses a labeled rack (veg, non-veg, pending) to instantly find the right order.

ACID Properties

ACID stands for Atomicity, Consistency, Isolation, and Durability. It ensures transactions are reliable.

If a customer pays, either the money is transferred completely or nothing happens. There is no partial state.

Atomicity: Either the pizza order is fully placed or not placed at all
Consistency: Order details (price, items) are always correct
Isolation: Two customers ordering at the same time don’t mix up orders
Durability: Once the order is confirmed, it won’t disappear even if the system crashes

Caching Fundamentals

What Problem Caching Solves

Caching stores frequently used data in faster storage so it can be accessed quickly. Instead of checking the database repeatedly, the system uses cached data.

Think of a pizza shop. Popular pizzas (like Margherita) are kept ready on the counter. Instead of making it from scratch every time (database), the shop serves the ready pizza (cache) instantly.

Cache-Aside Pattern

The system checks the cache first. If the data is not found, it fetches it from the database and stores it in the cache.

Customer asks for a pizza:

If it’s already on the counter, serve immediately
If not kitchen prepares it, then keeps a copy ready for the next customer

TTL (Time-to-Live)

TTL defines how long data stays in the cache before it is refreshed. This ensures outdated data is not used.

Pizzas can’t sit forever. After some time, they’re thrown away and made fresh again. That “expiry time” is TTL.

Monolith vs Microservices

Monolith

A monolith is a single system where everything is tightly connected. It is easier to build but harder to scale.

One big kitchen where the same team handles orders, cooking, billing, and delivery. Simple setup but if too many orders come in, everything slows down.

Microservices

Microservices break the system into smaller independent services. Each service does one thing and communicates with others.

It is harder to build but easier to scale.

Separate teams:

One for taking orders
One for cooking
One for delivery

Each team works independently, so the system handles more customers efficiently.

When Each Works

Monolith works well for small systems. Microservices work well for large, complex systems with multiple teams.

Monolith when small pizza shop with limited orders and one kitchen is enough. Microservices when large pizza chain with separate teams and scalable operations.

Beginner Design Case Studies

Topic	URL Shortener	To-Do App	Chat System
Purpose	Redirect	Tasks	Messaging
Focus	Fast reads	Simplicity	Real-time
Bottleneck	Redirect speed	DB writes	Message delivery
Architecture	DB lookup	CRUD	Persistent connection
Protocol	HTTPS	HTTPS	WebSockets
Scaling	Horizontal	Minimal	Horizontal
Database	NoSQL	SQL	NoSQL
Load Balancer	Required	Optional	Critical

System Design is not about memorizing answers. It is about understanding how systems behave when they grow. It is about thinking ahead.

Take a simple system and think through it.

Where will it break
How will you scale it
What decisions will you make

Because at the end, every system is just a pizza shop trying to serve more people without breaking.

If this helped you understand things better, I would love to know.

What should I break down next?

From APIs to Agents: The Real Shift at Google Next ‘26

Konark Sharma — Tue, 28 Apr 2026 12:24:59 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

I watched Google Cloud Next ‘26 thinking I’ll just see better models, faster APIs, maybe some cool demos.

But I didn’t expect this. This felt different. Not like “AI is improving”. More like the way we build software is changing.

The Moment That Stuck With Me

It started simple. JayTee Hazard was creating music. Tina Tarighian was generating visuals.

But the interesting part wasn’t the demo. It was what was happening behind it.

Gemini was:

listening to the music
generating code
updating visuals in real time

And it just kept going. No “run again”. No “generate once”

It was a loop. That’s when it clicked for me. This is not prompt to output anymore. This is: input → reasoning → tool use → execution → feedback → repeat

The difference is not just output. It’s the system behind it.

That loop is the foundation of agentic systems.

Then This Number Hit Me

Sundar Pichai mentioned:

~75% of new code at Google is AI generated and reviewed by engineers

I had to pause there. Not because it’s surprising. But because it confirms something we already feel. We’re not writing everything anymore.

We’re:

guiding
reviewing
correcting

Almost like we moved from writing functions to reviewing systems.

The Part That Felt Real

The most interesting part wasn’t the models. It was how they’re actually using this internally. They gave an example of a complex code migration.

Instead of one system, they had:

a Planning Agent
an Orchestrator Agent
a Coding agent
and Engineers

Working together. And they completed it 6x faster. That’s not “AI helping”. That’s a team.

So What Does This Mean for Us?

This is where things started making sense for me.

1. We’re Not Writing Prompts. We’re Designing Systems

With the Agent Development Kit (ADK), you don’t just create one agent. You define:

roles
capabilities
tool access
execution flow

Each agent becomes: a stateful unit with memory + tools

It felt like building microservices, but instead of APIs you’re wiring intelligence.

2. The API Layer Is Getting Abstracted (MCP)

This was subtle but huge. With Model Context Protocol (MCP) inbuilt now:

tools expose capabilities in a standard format
models understand how to use them
context is passed in a structured way

Instead of:

writing REST calls
parsing responses
handling retries

Your agent does tool invocation via context. Think of MCP as a contract between models and tools

3. Agents Talking to Agents (A2A)

With A2A (Agent-to-Agent). Agents can:

discover other agents
request capabilities
validate outputs

Each agent exposes something like:

{
"name": "evaluator",
"capabilities": ["validate", "score", "simulate"]
}

And another agent can:

evaluator.evaluate(plan)

This creates dynamic multi-agent coordination.

4. The UI Part Was Unexpected

This one felt weird at first. Instead of building dashboards manually. Agents generate UI based on context.

Using A2UI:

data → structured output
output → UI components

So instead of build dashboard → connect data. It becomes generate data → UI gets created

This flips the flow completely.

5. Memory Makes Agents Actually Useful

One of the biggest limitations I’ve felt AI forgets everything

With:

session state
memory bank

Agents can:

store context
recall past decisions
refine outputs

So instead of stateless prompt → response. You get stateful system → evolving behavior

That’s a big shift.

6. DevOps Is Turning Into System-Level Reasoning

This part felt unreal. Using Cloud Assist:

infra migration → prompt
debugging → automated reasoning
fixes → suggested patches

Under the hood: model + logs + context + tool execution

So instead of:

checking logs manually
tracing errors

The system does root-cause reasoning + suggestion

What This Means in a Real Project

If I think about building something today:

Before:

write backend
connect APIs
manage state
build UI

Now:

define agents (planner, executor, validator)
connect via A2A
use MCP-enabled tools
let UI emerge via A2UI

The shift is not just speed. It’s how I think about building systems.

The Real Takeaway

I’m not thinking “AI will replace developers”. I’m thinking the role is changing

Before: “How do I write this?”
Now: “How do I design a system that can solve this?”

And honestly, I’m still figuring out what that means for me.

If you’re building with AI right now, are you still writing prompts? Or are you starting to design systems?

From Distracted to Focused: Mac Apps That Actually Made a Difference

Konark Sharma — Sun, 26 Apr 2026 20:04:49 +0000

I kept thinking I’ll write this someday.

But every time I sat down, I felt like I’m not “productive enough” to talk about productivity. Some days I get a lot done. Some days I just open my laptop, switch between tabs, and wonder where the time went.

I’m still figuring it out.

But in the middle of all this, there were a few apps that actually helped me. Not perfectly, not magically, but enough to make a difference. Enough to help me start when I didn’t feel like starting.

So this is not a perfect productivity guide. It’s just what worked for me.

Trying to Focus When I Didn’t Feel Like Starting - Countdown

I like to work with Pomodoro technique and work for a while and then take a break. I usually work in time interval of 25 min productive work and 5 min break and then repeat it again and then after a while take a longer break.

I used to use Flow for this but recently I got a new app to play with Countdown.

What I love about this app is that it provides a small tool in the dock to control and you can pull to set the timer and it will start the timer in the bottom left corner.

Doing things with a timer puts the sense of urgency in me that I have to finish this work in this limited amount of time and be fast and productive.

There are days when even starting feels hard, and this timer is the only thing that pushes me to begin.

This helps me gets more things done and get better.

Stopping the Constant Window Switching - Rectangle

Whenever I used to watch tutorials and write the code along I was so much frustrated by shifting windows back and forth again and again and till then I discovered splitting on Mac was available then I used it and I got bored of it pretty easily as there was no keyboard shortcut to adjust them.

So then randomly watching YouTube I came across Rectangle.

It is a free app that let me snap windows and move and resize the window however I like and plus there is an awesome and easy keyboard shortcut.

It might sound like a small thing, but saving those few seconds again and again actually made me less frustrated while learning.

Completing Work before Deadlines - Lockera

I loved it when Mac starting providing widgets for Home Screen. I was so amazed by it and wanted to add widgets to acts as a reminder for me to keep looking at them and remind myself of the deadlines.

That’s where I found out about Lockera and its amazing features. All of the features of Lockera are amazing but the one I love is Days left.

I can provide it a task and the deadline and it will stick as a widget and remind us with the deadlines and to complete work faster.

I tend to forget things, especially when I’m focused on something else, so having something constantly reminding me helps more than I expected.

Reducing Distractions While Browsing - Brave Browser

I have tried most of the browser to find the ultimate one but for me nothing tops Brave browser. It is easy, safe and fast and blocks most of the ads.

Well, I can’t stop talking about brave browser.

I watch most of the videos on YouTube and I don’t have a premium and without premium I’ll get the ads first before watching any YouTube video so I can’t afford that so I use brave browser for it.

It also seamless connection to brave browser on phone. Other features it mimics just like chrome it adds all the web tools and features and it functions perfectly well.

The most loving feature that I use is opening tabs and not closing them. I keep website and YouTube videos for later seeing sometimes and I left it there on my tabs for hours.

I used to have my Motherboard heated and air blowing out of the fans like I’m cooking something but that doesn’t happen anymore due to Brave Browser and a secret extension.

Not seeing ads actually helped me stay focused longer without getting distracted.

Writing Things Down Before I Forget Them - Notion / Notes

I used to love notion back then but since I moved to another MacBook. I’m using notes app to create and use and the retrieval and opening of the app is quite fast.

I love using these and love creating and saving a lot of notes.

Notes are a big part of my life and since I started writing on dev.to. I use notes app to write the drafts so that they are saved there and I can revisit my first drafts when I became a better writer.

Trying to Be Consistent With My Thoughts - Journal

I started writing some journals but although I am not a daily journal guy yet but I love the idea of writing journals and I love the journal app.

It is fun and calm and easy to use and I can make a streak for keep writing daily and it keeps tracks of how many journals have I written, words used in them and all the entries made.

I keep a reminder but still I forget to keep up the journal.

I’m not consistent with journaling, but whenever I do it, I feel a bit more clear about everything.

Fixing a Skill I Kept Ignoring - Typist

Since I love writing my typing has been pretty bad so to keep and take lessons from start to finish and accomodate my brain to know and remember all the typing keys.

For all this I use typist. It is an app that teaches you from start like F and J and the more you practice the more keys it will teach you.

It was the ultimate app for me to use and learn typing from start with no ads straight typing lesson and the best part before the next lesson a small recap of the previous lesson.

It is so awesome app for me to use to get better at typing.

It’s frustrating at times, but I know this is one of those skills that will help me for life.

Cleaning the Mess I Didn’t Notice - App Cleaner

I loving using and installing a lot of apps and every new app if you delete it leaves it’s marks so in order to make it working and delete all the subfolders or the hidden folders I use app cleaner.

It mostly works magically for apps and deletes everything they are hiding from me. But just there are times that it just can’t delete everything but it gets the job done for me and I love the app for it.

I didn’t realize how much clutter builds up until I started cleaning things properly.

I’m still trying to figure out what productivity really means for me.

Some days I follow everything perfectly. Some days I don’t. But these tools help me stay a little more consistent, a little more focused, and a little more in control of my time.

These are the apps that worked for me. But I’m always on the hunt for better ways to improve.

What are the apps that help you stay productive and should I bring more articles like this?

It Might Already Be Too Late to Fix This

Konark Sharma — Sun, 19 Apr 2026 22:48:17 +0000

This is a submission for Weekend Challenge: Earth Day Edition

It might already be too late to fix this.

Yes, you heard it right. It’s an Earth Recovery Protocol. A plan to help Earth recover from all the damage it has endured. But the deeper you go, the harder it gets to ignore the truth. Some things can’t be undone.

We could have waited for another century, but who knows whether the resources would still be available till then.

So, why not start the recovery protocol today itself and do what we can do best to help Earth start its recovery journey.

What I Built

Earth Recovery Protocol is a haunting interactive simulation that dares users to "undo" humanity's greatest environmental sins: species extinction, deforestation, fossil fuel emissions, plastic pollution, and ocean acidification.

Through a terminal like interface with cinematic animations and typewriter effects, it reveals the cold truth: many ecological wounds are irreversible.

My goal was simple — to make people pause.

Not just read about climate change, but feel it. To jolt complacency, spark urgent action, and remind us that our planet isn’t a game with save points.

You don’t “retry” extinction. You don’t “reload” forests.

Dive in, confront the consequences, and walk away thinking differently.

Demo

Try the protocol yourself: Earth Recovery Protocol

See how it unfolds:

Fair warning this is not a feel good experience. It’s meant to make you uncomfortable. Because that’s where awareness begins.

Code

Explore the project here:

Konarksharma13 / Earth-Recovery-Protocol

Earth Recovery Protocol

🌍 Earth Recovery Protocol

A stark reminder: Some wounds to our planet cannot be healed. This interactive AI-powered simulation confronts us with the irreversible consequences of environmental destruction.

🚨 The Harsh Reality

In the face of climate change, biodiversity loss, and ecological devastation, humanity often dreams of "undoing" the damage. But the truth is chilling: many environmental changes are irreversible. Species extinction, ocean acidification, plastic pollution. These aren't just problems. They're permanent scars on our planet.

Earth Recovery Protocol is not a tool for optimism. It's a wake-up call. Through an immersive, AI-driven simulation, users attempt to "reverse" environmental catastrophes, only to confront the cold, unyielding facts of ecological limits.

✨ What Makes This Project Amazing?

🎭 Immersive Experience: Terminal style interface with typewriter effects, glitch animations, and cinematic transitions.
📚 Educational Impact: Each "recovery attempt" reveals scientific truths about irreversibility, backed by real environmental data.
⚡…

View on GitHub

Feel free to fork it, improve it, or build your own version of reality.

How I Built It

Immersive Experience: Terminal style interface with typewriter effects, glitch animations, and cinematic transitions.
Educational Impact: Each "recovery attempt" reveals scientific truths about irreversibility, backed by real environmental data.
Modern Tech Stack: Built with React 19, Vite, TypeScript, and Tailwind CSS for lightning-fast performance.
Environmental Advocacy: Every interaction serves as a powerful reminder to act now, before it's too late.

Key Features

Interactive Simulation: Attempt to undo deforestation, species extinction, fossil fuel emissions, plastic pollution, and ocean acidification.
Realistic Outcomes: Discover why some actions lead to failure, partial recovery, or systemic dependencies.
Progressive Revelation: As you interact, the simulation builds to a critical warning about the planet's fragility.
No Happy Endings: Designed to confront users with uncomfortable truths, inspiring real-world action.
Responsive Design: Works seamlessly on desktop and mobile devices.

How to Use

Request Access: Enter the simulation with a warning about irreversible systems.
Choose Actions: Select from devastating environmental issues to "attempt" reversal.
Witness Outcomes: Experience the harsh reality through animated, typed responses.
Reflect: After 3 attempts, receive a critical warning that forces contemplation.
Restart?: Discover that even restarting isn't possible there are no backups for our planet.

Why This Matters

Our planet is not a video game with save points. Earth Recovery Protocol drives home this message:

Species Extinction: Once gone, ecological roles can't be restored.
Deforestation: Regrowth takes centuries; biodiversity is forever altered.
Fossil Fuel Emissions: Atmospheric CO₂ persists for generations.
Plastic Pollution: Microplastics endure across ecosystems.
Ocean Acidification: pH changes require massive, long-term intervention.

The time to act is NOW. Reduce your carbon footprint, support conservation, advocate for policy change, and live sustainably. Every small action counts before it's too late.

Prize Categories

Best Use of GitHub Copilot

I used Copilot as a true development partner across every stage of this project. It helped me quickly understand the existing React and TypeScript codebase, identify the core experience in App.tsx, and refine it without losing the cyber-terminal aesthetic that defines the project.

Copilot played a key role in elevating both the code and the narrative. It suggested cleaner component structures, more expressive action metadata, and stronger user-facing messaging for recovery outcomes. These improvements made the experience feel more intentional, immersive, and emotionally impactful.

We often think we still have time. This project questions that. What if we don’t? What if this is already the recovery phase?

And more importantly, What are you doing now to make sure it doesn’t get worse?

If you could undo one thing, what would it be?

I Couldn’t Afford Earth, So I Built Something Better

Konark Sharma — Sat, 11 Apr 2026 13:20:05 +0000

This is a submission for the DEV April Fools Challenge

The day has finally come. I am launching my dream project. For months I had been thinking about what to pitch and now I finally am pitching my startup.

What I Built

I have been working on this for months and I have a secret partner as well. The partner has really helped me in negotiations.

For the past 1 month there was always a back and forth with some aliens. There was a lot of negotiation going on with them. But after their approval, I’m presenting to you:

SpaceEstate : a place where you can buy property in space.

Since Earth is quite crowded and the prices are skyrocketing, why limit yourself?

With the help of my website, you can check out all the planets and choose the best habitat for you and your family. It is a safe space to secure your future and build a legacy.

Why just dream of a house on Earth when you can have one on Mars, Jupiter, or something slightly radioactive on Venus?

I have provided a lot of planets for you to choose from, and some of them have limited time offers, so you better act fast before someone else grabs your dream planet.

For better trust, I have talked to a lot of aliens and added their reviews for authenticity. Nothing builds trust like a 5-star review from someone with 3 eyes.

You have three options:

100m
1000m
The whole planet (for people who don’t like neighbors)

Then our servers run these steps in the background:

Connecting with Galactic Bank
Verifying your oxygen rights
Negotiating with local aliens
Bribing Intergalactic Authority

After this highly legal and completely ethical process, we generate a 100% authentic certificate that proves you now own space.

Demo

Welcome to the future of real estate: SpaceEstate

Try it yourself before someone else buys your dream planet and turns it into a parking lot. One click and you’re officially a space landlord. Worst case, you just own a very expensive rock.
Go ahead, your future in space is just one questionable decision away.

Code

Konarksharma13 / SpaceEstate

SpaceEstate

🚀 SpaceEstate: Own a Piece of the Universe

💰 The HOTTEST Real Estate Market in the Galaxy 🪐

Forget boring Earth condos. Own prime real estate on Mars, Venus, and Jupiter's moons!

What is SpaceEstate? 🌌

Ever dreamed of owning beachfront property? How about crater-front property on the Moon? 🌙

SpaceEstate is a cutting-edge web3-enabled (okay, AI-powered 😎) platform that lets you browse, explore, and purchase prime interplanetary real estate. Whether you're looking for a cozy studio apartment on Mars or a sprawling mansion on Europa, we've got you covered.

Why You NEED to Own Space Real Estate NOW:

Limited Inventory - Only one Mars per solar system! Once it's gone, it's gone.
Infinite Upside - Elon's buying, VCs are buying, crypto bros are buying. Don't be left behind!
Escape Earth's Problems - Mercury too hot? Venus even worse? Pick your perfect plot today!
AI-Powered Insights - Our…

View on GitHub

How I Built It

Sleepless Nights & Cosmic Nightmares

Building SpaceEstate was like training for a Mars mission, except the mission was my sanity. I averaged 3 hours of sleep in the one last month. My coffee maker became a deity.

Alien Negotiations Were INSANE

Getting planet data was easy. Getting exclusive listings? That required dealing with the Martian Real Estate Consortium. They don’t do Zoom calls. Only psychic telepathy. Which kept disconnecting.

Their lawyer demanded 47 clauses about meteor damage.

A Saturn broker tried selling me “crater-adjacent property” that turned out to be space dust.

I almost quit.

Other Hilarious Horrors

TypeScript errors at 3 AM questioning my existence
Gemini hallucinated a moon that doesn’t exist (almost sold it)
React crashed every time I added Neptune
Accidentally purchased a real asteroid during testing
Explained Web3 to an alien using hand gestures
UI broke because different planets have different gravity

Technology Stack

React + TypeScript - For a robust, scalable experience
Vite - Lightning-fast dev experience (like rockets, but for your code)
Google Gemini API - AI that understands interplanetary economics
Beautiful UI Components - Custom built for the space age
Component Library - Pre-built UI elements that are out of this world

The Result

A masterpiece built on caffeine, confusion, and intergalactic negotiations.

Prize Category

Community Favorite

SpaceEstate makes space ownership accessible to everyone.

From developers who just wanted to try something fun, to people who now proudly own 100 meters on Mars, this project brings a shared experience.

It’s simple, fun, slightly addictive, and makes you question your financial decisions in the best way possible.

No rocket science degree required. No SpaceX membership needed.

Just curiosity, imagination, and questionable investment choices.

We always dreamed of owning a house. We just never thought it would be outside the planet.

So, which planet are you buying first? And more importantly, are you going for a small plot or the whole planet?

I Know It’s AI, But It Still Feels Real

Konark Sharma — Mon, 06 Apr 2026 19:30:49 +0000

Lately, I’ve been thinking about how we talk to AI.

Not just for code or answers, but for understanding, for comfort, for something that feels a little more human.

And that thought led me here.

Can LLMs finally understand emotions?

I recently came across Anthropic’s latest research about LLMs understanding emotions, and I was surprised by it. It feels like this could change how LLMs respond to us. But does that mean the job of psychiatrists and therapists is done? Yes and no.

LLMs still don’t understand emotions like humans.

If someone scolds me for losing my favorite thing, I’ll feel angry and sad. That doesn’t happen with LLMs. They are still machines.

What has changed is their ability to understand patterns of emotions.

Because they are trained on a vast amount of human-written text like fiction, conversations, news, and forums, they start picking up how emotions are expressed.

This doesn’t mean they truly feel emotions.

But they are getting better at recognizing and responding to them, step by step.

What does this look like in practice?

If I tell an LLM: “I failed my exam.”

With an emotional pattern active, it might respond: “I’m sorry, that must feel really hard.”

Without that pattern, it might simply say: “You failed your exam.”

This creates a new kind of interaction. Responses that feel emotionally aware.

Not because the model feels something, but because it has learned what that kind of response should look like.

What’s actually happening?

The LLM is not feeling emotions. It is predicting them. During generation, it leans toward responses that match emotional patterns it has learned.

So instead of just predicting correct words, it predicts words that also fit the emotional context.

That small shift changes everything.

What does the future hold for us?

I feel LLMs are becoming more and more advanced. But in some ways, this might also make us more dependent. We already rely on people in our lives to share emotions, to feel understood, to be comforted.

If LLMs become really good at this, we might start replacing those human connections.

We all have someone we talk to. Someone who listens, understands, and comforts us. Now imagine an AI that can do this perfectly every time.

Since these models keep improving, they will get better at predicting exactly what to say to make someone feel better. With voice interactions, it could feel even more real.

Like talking to someone who always understands you.

What’s happening behind the scenes?

The more emotional data LLMs learn from, the better they become at recognizing patterns. They don’t feel. But they get better at predicting emotional responses.

Because they already have context about what we say and how we say it, their responses can feel very personal.

Over time, it might become harder to distinguish whether you’re talking to a human or an AI.

Should we fear it?

Maybe yes. Maybe no.

But one thing is clear. LLMs are becoming more advanced and more comparable to human-like behavior.

First, it was intelligence. Now it’s emotions.

What’s next?

Maybe the real question is not whether AI understands emotions.

But whether we start treating it like it does. Because the moment something responds in a way that feels right, we start trusting it.

We start sharing more. We start depending on it. Not because it feels. But because it responds like it does.

And that might be enough.

Should AI be able to simulate emotions this well? Or should there always be a clear line between human and machine?

You’re Not Stuck. You’re Just Growing Roots

Konark Sharma — Wed, 01 Apr 2026 09:45:34 +0000

The other day, I was walking in a park, just looking around, not thinking about anything in particular.

And then this thought hit me. A plant’s life feels very similar to a developer’s life. At first, it sounded strange. But the more I thought about it, the more it started making sense.

Both need time, care, patience, and the right environment to grow.

It Starts Small

Plants grow from seeds, and a developer also starts from a seed.

A plant’s life begins with a seed. We take a seed, place it in fresh soil, water it, give it sunlight, and take care of it until it finally starts to grow.

The moment it starts growing, that small happiness kicks in. We start taking even more care of it. Watering it daily, making sure the soil is good, giving it proper sunlight and nutrients.

This is everything the plant needs to grow.

The same goes for a developer.

We choose a seed, maybe Web Development, Mobile Development, DevOps, or anything else. We plant it in our mind and start growing it.

We learn languages like Python, C++, or Golang. We fail, but we keep watering it daily with practice. We give it sunlight by building small projects.

And one day, when we stop just watching tutorials and actually write our own code, that is when we grow out of the seed and begin a new journey.

Growing, But Still Fragile

With continuous care, a plant becomes a sapling. Then we move it into a bigger pot so it can grow into a strong tree.

New soil is added. More nutrients. More water. Now the plant needs more effort to grow further.

The same happens with a developer.

We start building projects, reading other people’s code, solving problems, and sometimes copying projects from tutorials. This gives us confidence.

We take on bigger projects, face more errors, and start solving them. Using our basics with new challenges helps us grow.

Every error becomes a way to grow bigger.

Growing Roots (The Hardest Phase)

This is the phase where most people think they are stuck.

The plant is growing, getting water, sunlight, and nutrients. But one day, the weather changes. Heavy winds and rain test its strength.

If the roots are strong, the plant survives. If not, it gets uprooted.

The same happens with developers.

Sometimes we skip basics and jump directly to projects. We copy code, build projects, and add them to our resume.

But when interviews come, reality checks everything. If we truly understand what we built, we can answer confidently. If not, it becomes obvious. That is why basics matter.

Even when learning from tutorials, always ask why. Why this line? Why this approach?

That is what makes your roots strong.

When Things Start Making Sense

With strong roots, the plant becomes a tree. It grows bigger, stronger, and more stable. It starts giving back.

People sit under its shade. Its soil helps other plants grow.

The same happens with a developer.

Now the developer works on real projects, helps others, and uses their knowledge effectively.

People start coming to them for help. They guide juniors, train interns, and contribute more.

They start earning well and moving closer to their goals.

When Everything Falls Apart

Then comes a difficult phase.

The tree starts shedding leaves. It looks empty. Dry. People avoid it. Some even complain about it.

The same phase comes in a developer’s life.

Sometimes, they lose their job.

After putting in so much effort, suddenly they are no longer needed. People who once reached out for help slowly disappear.

It feels empty.

Starting Again, Stronger

But this is not the end.

If the tree is given water and nutrients again, it grows back. Stronger. Fuller. Better.

The same is true for developers.

If we keep learning, keep applying, and stay positive, things change. A new opportunity comes. A better path appears.

And life moves forward again.

Keep Going

Growth is not always visible.

Where things are quiet. Where results are not visible. Where it feels like nothing is working.

But that is where roots grow.

Roots don’t show on the surface. But they decide how strong you will stand when things get better.

Every developer goes through this phase.

Some quit here. Some stay, keep learning, keep trying, and slowly grow stronger.

If you feel lost right now, maybe you are not falling behind. Maybe you are just growing roots.

And when the time comes, you will grow in ways you cannot see yet.

What phase do you think you are in right now?

I Almost Didn’t Go to My First Tech Event

Konark Sharma — Mon, 30 Mar 2026 18:03:01 +0000

I almost didn’t go to my first tech event.

I kept thinking I wouldn’t fit in. Everyone there would know more than me. I wouldn’t know what to say or how to even start a conversation.

For a moment, I even thought of skipping it. But somehow, I still showed up.

After quitting my job, one thing I did was I started attending tech events. Once I started attending more events, it felt really good.

Every tech event comes with its own perks. Some are good, some are exceptionally well organized. Some provide practical knowledge about tools, while others give deep insights into tech.

What I Thought Tech Events Were

These are mostly community events, either paid or free, where you attend as a participant or a speaker. So far, I have only attended as an attendee. Maybe someday I will attend as a speaker.

What fascinates me the most is seeing speakers with immense knowledge explain complex things in simple ways while keeping the audience engaged.

Most companies organize these events to either share knowledge or promote their products through talks and demos.

I personally feel that smaller, more closed events are more interesting because you get more time to talk to speakers. In larger events, everyone wants to talk to them, so the interaction becomes limited.

Most of the events I attended were offline, which helped me meet new people and learn a lot more. I have also worked as a volunteer in a few events, so I have seen both sides.

Why I Still Decided to Go

1. What I Learned Just by Showing Up

I attend every event with one goal, to learn something new.

This mindset has made every event valuable for me. Every speaker comes with something to share, and picking even one useful idea makes the event worth it.

I always check the agenda beforehand and get excited about topics I want to learn. I keep my notes ready to capture ideas, project thoughts, or anything interesting.

One of the most memorable events for me was an OpenAI event. I got to see and hear Sam Altman. Many startups were built on top of ChatGPT, and founders were discussing real problems with the team.

That was the first time I heard terms like Context Window, RAG, Embeddings, Hallucinations, Model Weights, Temperature, Max Tokens, Vector Databases, and Context Length.

I was completely amazed. That same evening, I came back home and started exploring AI seriously.

2. Talking to People Was the Hardest Part

If you are a student, tech events can open many doors.

You meet people from different universities, exchange ideas, and sometimes even build things together. You can prepare together, practice interviews, or even work on projects that may turn into something bigger.

For working professionals, these events help in finding better opportunities, referrals, or even hiring.

For me, I have not deeply connected with many people yet, but I have had great conversations, learned a lot, and enjoyed interacting with others.

Since I was somewhere in between, having a degree but not working, I sometimes felt I did not fully belong to either side.

3. Learning by Doing Changed Everything

I always look forward to hands-on sessions more than talks.

Learning by doing and breaking things teaches more than just listening. I try to reach early whenever there is limited seating.

Through these sessions, I have learned things like re-ranking, built small MCP servers, explored AI Studio, and even got introduced to tools like Antigravity.

I also got to see demos of tools like Stitch before release, just by attending events.

4. The Unexpected Small Wins

My first event was special because I did not return empty handed. I got stickers and a pin, and it felt amazing.

Since then, every event gives something different. Some I use, some I keep. I have collected a lot of swags, though I don’t put stickers on my laptop, otherwise it would be completely filled.

And yes, almost every event had good food.

5. Seeing the Effort Behind the Scenes

Since I worked as a volunteer in some events, I got to see how things work behind the scenes.

Handling people, organizing sessions, managing chaos so that everything runs smoothly. Most volunteers were developers too, and everyone was helpful and humble.

It gave me a different perspective of how much effort goes into organizing a good event.

6. Why I Kept Going Back

Every event I attend leaves me with motivation. I always come back wanting to build something better, learn more, and improve.

These events give me the push to keep going.

I also have a goal now, someday I want to be on that stage and share my own experiences.

Many of the events I attended required shortlisting. Being unemployed made me feel like I might not get selected. But surprisingly, I got selected for many, and yes, I got rejected from some too.

It feels like luck sometimes, but being there and showing up made a difference.

7. What Changed in Me After Attending Events

I am an introvert. But I challenged myself to talk to people at events. Even when I felt less qualified, I still tried. Talking to people gave me confidence.

I started listening more, observing more, and slowly getting comfortable. I go to events with the intention to learn more and speak less.

I keep my expectations low and stay open to unexpected experiences. And many times, I ended up meeting amazing people who shared valuable insights.

Sometimes Just Showing Up Is Enough

Being at the right place at the right time matters.

I read the article from @maame-codes about getting an internship just by attending a tech event.

That is the kind of unexpected outcome these events can create.

If You Are Thinking About Going, Just Go

If you have never attended a tech event, try attending one. You might not get everything from the first event.

But you will definitely take something back.

Have you attended any tech events? How was your experience?

Small Prompt Tweaks That Saved Me Hours

Konark Sharma — Wed, 25 Mar 2026 17:43:11 +0000

I have been experimenting with AI these days and what I found from watching tutorials and prompting myself is that prompting isn’t really a skill. It is about thinking clearly.

If your thinking is vague, your output will be vague. If your thinking is structured, your output becomes structured. Being vague won’t get you results. Being specific and knowing exactly what you want will.

I’ll share some observations that helped me move from generic AI outputs to something more controlled and intentional. The gap between an average AI website and the ones you see on X isn’t the tool. It is the process.

Start With a Breakdown, Not a Prompt

We all build websites these days. Even non-coders are building cool websites using AI. But there is one problem. Most of them look the same.

Generic. Repetitive. Forgettable.

I tried building multiple websites using simple prompts and most of the outputs looked plain and basic.

To make them feel more refined and intentional, I realized two things matter:

The breakdown
The master prompt

Before writing any code, I now start with inspiration.

Instead of saying: 'Build me a modern website'

I prompt like this:
'Generate a complete design spec sheet including layout system, spacing, typography, color palette, animations and components for Figma.'

This gives me structure. Then I refine it. Then I convert it into a master prompt. Then I build.

The key rule: Fix one thing at a time

Always say: Fix only these items

This reduces hallucination and keeps the system focused.

Constraints Make AI Better

AI performs better with constraints.

Instead of saying: 'The layout feels off'

I prompt like this: 'Hero section max-width 1200px, centered, with proper padding and spacing'

Instead of: 'Fix design'

I prompt like this: 'Fix only spacing between sections and alignment of navbar'

Constraints reduce randomness.

Prompting Is Iteration, Not Perfection

Most people try to write one perfect prompt. That rarely works.

The real process looks like this:

Prompt → Output → Fix → Refine → Repeat

The faster you iterate, the better your results.

Let AI Write Better Prompts for You

Instead of trying to write perfect prompts yourself, use AI to generate better prompts.

I prompt like this: 'Convert this idea into a high-quality diffusion model prompt.'

LLMs understand structure better than us in many cases. Let them help you think.

Ask AI What You’re Missing

One of the most underrated uses of AI.

I prompt like this: 'Whatever you know about me based on that what am I missing in this? or What gaps exist in my knowledge?'

This shifts AI from answering questions to improving your thinking.

Add Constraints to Reduce Hallucination

When conversations get long, hallucinations increase. Instead of blindly trusting outputs, guide it.

I prompt like this: 'If you are not sure, say I don’t know. Provide a confidence score for your answer'

This makes responses more grounded.

Control the Way AI Writes

AI has a very predictable writing pattern. To avoid that, guide it.

I prompt like this: 'Avoid sentence structures like “not just X but Y”. Use direct and clear sentences. Be creative but avoid generic phrasing'

This improves output quality instantly.

What I Realized

Prompting is not about writing better sentences. It is about thinking better.

Most bad outputs come from unclear thinking. Not bad models.

The better you think:

the better you structure
the better you guide
the better you iterate

The better your results.

The difference is not in tools. It is in how you use them. AI doesn’t replace thinking. It amplifies it.

What is one prompting technique that actually worked for you?