DEV Community: Akanksha Sharma

What If Your Procrastination Had to Explain Itself?

Akanksha Sharma — Sun, 04 Oct 2026 13:59:37 +0000

My friend has a very consistent productivity strategy.

“I'll do it after lunch.”

Then:

“Okay, after dinner.”

Then:

“I'll definitely do it tomorrow.”

And somehow, tomorrow always wins.

When I saw the Build for a Friend challenge, I knew I didn't want to build another generic chatbot.

And I definitely didn't want to build a to-do list with an “AI” button slapped onto it.

I wanted to build something around a problem I'd actually seen.

So I built Tomorrow.

An AI companion for one very specific problem:

What if the hardest part isn't finishing the task but starting it?

• So, What Is Tomorrow?

Tomorrow is an AI powered anti-procrastination companion.

It doesn't try to manage your entire life.

It doesn't give you a 47 step productivity plan.

And it definitely doesn't respond to every problem with:

“You got this!”

Instead, it asks:

“What's actually stopping you?”

You tell Tomorrow what you're avoiding.

It tries to understand why you're stuck, breaks the task into something smaller, picks one realistic next step and helps you start.

For example:

“I need to finish my React assignment but I don't know where to start.”

A typical productivity app might give you a checklist.

Tomorrow might say:

Don't finish the assignment yet.

Open the project.

Create the form component.

That's it. Give it 15 minutes.

Because sometimes the problem isn't the task.

It's the size of the first step.

• The Core Idea

The entire experience revolves around a simple loop:

                  ┌──────────────────┐
                  │ What are you     │
                  │ avoiding?        │
                  └────────┬─────────┘
                           ↓
                  ┌──────────────────┐
                  │ Understand the   │
                  │ blocker          │
                  └────────┬─────────┘
                           ↓
                  ┌──────────────────┐
                  │ Break the task   │
                  │ into smaller     │
                  │ actions          │
                  └────────┬─────────┘
                           ↓
                  ┌──────────────────┐
                  │ Pick ONE next    │
                  │ action           │
                  └────────┬─────────┘
                           ↓
                  ┌──────────────────┐
                  │ Focus session    │
                  └────────┬─────────┘
                           ↓
                  ┌──────────────────┐
                  │ Check in         │
                  └────────┬─────────┘
                           ↓
                     ┌─────┴─────┐
                     ↓           ↓
                   Done        Stuck
                     ↓           ↓
                Next step     Reassess
                     │           │
                     └─────┬─────┘
                           ↓
                       Start again

The interesting part isn't really the timer.

It's the feedback loop.

Tomorrow doesn't assume the first plan worked.

If the user gets stuck that becomes new information.

If the user finishes it moves forward.

If the task turns out to be bigger than expected it breaks it down again.

The goal isn't perfect planning.

The goal is progress.

• Why Procrastination?

This project started with a pretty simple observation.

Procrastination can look like this:

       Big Task
          ↓
   "I'll do it later"
          ↓
        Guilt
          ↓
      Avoidance
          ↓
   Task feels bigger
          ↓
      "Tomorrow."
          ↓
        Repeat

Tomorrow tries to interrupt that loop:

       Big Task
          ↓
    Tell Tomorrow
          ↓
   Find the blocker
          ↓
    Make it smaller
          ↓
   Start for 15 min
          ↓
       Progress

Not:

“Become a productivity machine.”

Just:

“Let's make starting a little easier.”

• What Does the AI Actually Do?

I didn't want the AI to generate motivational quotes and call that intelligence.

Its job is much more specific.

1. Understand the Situation

The user explains what they're avoiding.

For example:

“I need to apply for internships but there are so many websites and I don't know where to begin.”

The obvious response would be:

“You're procrastinating.”

Cool.

Not very helpful.

The actual problem might be overwhelm.

So Tomorrow tries to identify the blocker behind the task.

2. Find the Blocker

Different blockers need different responses.

Some examples:

The task feels too large
The first step isn't clear
The user doesn't know how to begin
They're overwhelmed
They're tired
They're afraid of doing it badly
The task feels boring
They've postponed it for so long that starting feels uncomfortable

If the problem is:

“I don't know where to start.”

Give them a starting point.

If it's:

“This feels huge.”

Shrink the task.

If it's:

“I'm scared I'll do it badly.”

The next step might simply be creating a rough first draft.

The AI isn't only asking:

“What should you do?”

It's also asking:

“Why aren't you doing it?”

3. Shrink the Task

Let's say the user enters:

Apply for internships

That's not really one task.

It's a tiny project pretending to be a task. 😭

Tomorrow can turn it into:

Open your resume.

Then:

Pick one internship.

Then:

Read only the requirements.

Then:

Decide whether you want to apply.

The goal isn't to solve the entire journey in one response.

It's to find the smallest useful action.

• What a Real Session Looks Like

This is where the idea becomes more than a chatbot.

Imagine the user says:

“I need to apply for internships but I'm overwhelmed and keep putting it off.”

Tomorrow first tries to understand the blocker.

Task:
Apply for internships

Possible blocker:
Overwhelm

Problem:
The task contains too many hidden steps.

Next action:
Open your resume.

Focus:
15 minutes

So instead of telling the user to spend the next three hours applying everywhere, Tomorrow gives them one thing:

Open your resume.

Now imagine the user comes back and says:

“I didn't do it.”

That's not treated as failure.

It's information.

Tomorrow can ask:

“What got in the way?”

The user says:

“I opened LinkedIn and started scrolling.”

Now the next response can change.

Original task
     ↓
Apply for internships
     ↓
Blocker
Overwhelm
     ↓
First action
Open resume
     ↓
User got distracted
     ↓
Reassess
     ↓
Smaller action
Open the resume file only

The AI isn't simply repeating:

“Try again!”

It's using the failed attempt to decide what to do next.

That's the part I cared about.

• From Chatbot to Workflow

A normal chatbot might work like:

User
 ↓
Question
 ↓
AI response
 ↓
Conversation ends

Tomorrow is designed more like:

User
 ↓
Task
 ↓
Blocker
 ↓
Next action
 ↓
Task state
 ↓
Focus session
 ↓
User check-in
 ↓
Updated context
 ↓
New action
 ↺

The response isn't just displayed as text.

It influences the next state of the task.

That's what turns the AI from a chat box into part of the workflow.

• Task State

I wanted the application to know where the user actually is instead of treating every message as a completely new conversation.

The basic state flow is:

NEW
 ↓
BLOCKED
 ↓
BROKEN_DOWN
 ↓
STARTED
 ↓
COMPLETED

And when things don't go according to plan:

STARTED
   ↓
STUCK
   ↓
REASSESS
   ↓
NEW SMALLER STEP

That STUCK → REASSESS loop is important.

Because real people don't follow plans perfectly.

And honestly, if they did I probably wouldn't have built this. 😂

The system needs to treat a failed attempt as context not as a dead end.

The plan didn't work. So let's figure out why.

• How I Built It

I kept the architecture intentionally simple:

User Input
    ↓
React UI
    ↓
Task + Conversation State
    ↓
Context / Prompt Builder
    ↓
Open-Weight AI Model
    ↓
Blocker + Next Action
    ↓
Task State Update
    ↓
Focus Session
    ↓
User Check-In
    ↓
Updated Context
    ↺

The frontend handles the interaction.

The application state keeps track of where the user is.

The context layer gives the model the information it needs about the current task and previous interaction.

The model then helps determine things like:

What is the user trying to do?
        ↓
What is blocking them?
        ↓
How can the task be reduced?
        ↓
What is ONE useful next action?

The important part is what happens after the model responds.

The result is used to update the task workflow rather than simply being shown as another chat message.

• The AI Decision Flow

At a high level, the AI interaction can be thought of as:

User message
     ↓
Extract task
     ↓
Identify blocker
     ↓
Estimate task complexity
     ↓
Generate smaller actions
     ↓
Select one next action
     ↓
Return structured guidance
     ↓
Update task state

For example:

Input:
"I need to finish my React project but I'm overwhelmed."

        ↓

Task:
Finish React project

Blocker:
Overwhelm

        ↓

Breakdown:
- Identify missing feature
- Open relevant component
- Create component
- Connect component
- Test it

        ↓

Selected next action:
Open the project and identify the missing feature.

        ↓

State:
STARTED

This is important because I don't want the model to produce a giant wall of productivity advice.

I want the output to be useful to the application's workflow.

• Why This Isn't Just an “AI Button”

This was one of the biggest design decisions in the project.

If the AI were removed the app would lose the part that:

interprets the user's blocker
decides how much to break down the task
adapts to failed attempts
suggests the next smallest action

The model isn't decorating the interface.

It's helping determine what happens next.

That makes the open-weight AI part of the core product logic rather than an extra feature added to the UI.

• Why Open-Weight AI?

This is where the project became more interesting to me.

At first, the idea was simply:

“I'll use an AI model to help break down tasks.”

But then I thought about the kind of information Tomorrow could eventually handle:

Personal goals
Unfinished work
Study plans
Career plans
Notes
Routines
Previous conversations
Recurring struggles

That's a lot of personal context.

And I didn't want the long-term version of Tomorrow to require sending all of that to a closed AI provider.

So I designed the project around an open-weight AI model and a local-friendly architecture.

The open model isn't there just because the challenge asks for open AI.

It changes what the product can eventually become.

A productivity assistant that knows your unfinished work and personal struggles is dealing with information that can feel much more sensitive than an ordinary chatbot conversation.

That's why local inference is an especially interesting direction for this type of product.

• Why Local AI Makes Sense Here

Imagine telling your productivity assistant:

“I've been avoiding job applications because I'm scared I'll get rejected.”

That's much more personal than:

“Give me a pasta recipe.”

😂

For something like Tomorrow, privacy matters.

A long-term version could work like:

              User
                │
                ▼
        Personal Context
                │
                ▼
          Local AI Model
                │
                ▼
        Next Best Action
                │
                ▼
              User

The idea is:

Your personal productivity context shouldn't automatically have to leave your device just to get useful AI assistance.

And because the model is open-weight, the project isn't permanently tied to one proprietary AI provider.

• Tech Stack

Frontend

React
Vite
Tailwind CSS

AI

Open-weight AI model
Local-friendly inference

Application Logic

Task state management
Conversational workflow
Context/prompt construction
Blocker identification
Task decomposition
Focus-session flow
Check-in and reassessment loop

• What Was Actually Hard?

The interesting part of building an AI product isn't always getting the model to respond.

It's getting the response to be useful.

One problem I had to think about was task size.

If the user says:

“I need to finish my project.”

A technically correct response could be:

“Break the project into smaller tasks.”

But that's not actionable.

The user is still staring at the same giant project.

So the system needs to go one level deeper:

"Finish my project"
        ↓
"What part?"
        ↓
"Build the frontend"
        ↓
"What part of the frontend?"
        ↓
"Create the login page"
        ↓
"What's the smallest action?"
        ↓
"Open the project and create Login.jsx"

That's the difference between advice and an actionable next step.

Another challenge is what happens when the user doesn't complete that step.

A normal chatbot might simply suggest the same thing again.

Tomorrow needs to treat that as information.

The plan didn't work. So let's figure out why.

That feedback is what makes the workflow adaptive.

• Why I Built It for a Friend

This is probably the most important part of the challenge for me.

I could have started with:

“What cool AI application should I build?”

Instead, I started with:

“What does my friend actually struggle with?”

The answer was pretty obvious.

They didn't need another productivity lecture.

They didn't need a complicated dashboard.

They needed help getting past:

“I'll do it tomorrow.”

So I built around that.

And starting with a person instead of a technology changed the product.

It made me remove things that sounded cool but didn't really solve the problem.

No giant productivity dashboard.

No unnecessary streak system.

No pretending that waking up at 5 AM will magically fix everything.

Just:

What are you avoiding?

Why?

What's the smallest thing you can do next?

• What I Learned

The biggest thing I learned from this project was:

AI doesn't have to solve the entire problem.

Sometimes it just needs to solve the next 10 minutes.

That changed how I thought about the product.

I initially imagined features like:

Streaks
Analytics
Habit tracking
Productivity scores
Daily reports
Complex schedules

But then I asked myself:

Would any of this actually help my friend start?

Not necessarily.

So I kept stripping things back.

One problem.

One person.

One next step.

And honestly, I think the product got better every time I removed something.

• What's Next?

There are a few directions I'd love to explore.

Voice Mode

Instead of typing:

“I'm avoiding my assignment…”

the user could just say it.

That could make the interaction feel much more natural.

Procrastination Patterns

Over time, Tomorrow could notice recurring patterns.

For example:

“You tend to postpone tasks when the first step isn't clear.”

Or:

“You usually get started when the task is broken into smaller actions.”

That could make the assistant more personalized without requiring the user to explain everything from scratch every time.

Fully Local Mode

The long-term goal is to make the entire experience work locally:

UI
 ↓
Local Data
 ↓
Local AI
 ↓
Personalized Guidance

No cloud AI dependency for the core experience.

Just a private AI companion running on your own machine.

• Agent Session

The project was built and tested through an agent-assisted development workflow as part of the challenge.

The agent workflow helped iterate on the application logic, task flow and user experience while keeping the core idea focused on one question:

What's the smallest useful action the user can take next?

• Final Thought

My friend didn't need another app telling them:

“Wake up at 5 AM.”

They didn't need a 12-step morning routine.

They didn't need another productivity guru.

They needed something that could say:

“Forget the whole thing for a second. What's the smallest thing you can do right now?”

That's what I wanted Tomorrow to become.

Not an AI that manages your entire life.

Not another to-do list.

Not another chatbot that gives you motivational paragraphs and disappears.

Just a small, private, open-AI companion that helps you take the first step.

Because sometimes the hardest part of getting something done...

is simply starting.

Git Without the Confusion: The Commands You’ll Actually Use

Akanksha Sharma — Tue, 29 Sep 2026 15:43:31 +0000

If you're new to Git, you've probably seen a command like this:

git checkout -b feature/login

…and thought:

“Okay… but what exactly am I supposed to remember?”

Git has a lot of commands.

The good news?

You don't need to memorize all of them.

For everyday development there's a small set of commands you'll use again and again.

So instead of throwing 50+ commands at you here's a practical Git cheat sheet for beginners that you can bookmark and come back to whenever Git decides to confuse you.

⚡ The Quick Git Cheat Sheet

Before getting into the details, here's the short version:

I want to...	Command
Set my Git name	`git config`
Start Git in a project	`git init`
Download a repository	`git clone`
See what's changed	`git status`
Review my changes	`git diff`
Stage changes	`git add`
Save a checkpoint	`git commit`
View commit history	`git log`
Create a branch	`git branch`
Switch branches	`git switch`
Merge a branch	`git merge`
Upload commits	`git push`
Get remote changes	`git pull`
Check remote changes without integrating	`git fetch`
Temporarily save changes	`git stash`
Safely undo a commit	`git revert`

You don't need to memorize this table.

*Bookmark it. That's literally what it's here for. *

1. Configure Git

Before using Git, tell it who you are.

• Set Your Name

git config --global user.name "Your Name"

Tells Git which name to associate with your commits.

• Set Your Email

git config --global user.email "you@example.com"

Sets the email associated with your commits.

• Check Your Configuration

git config --list

Useful when you want to verify your Git settings.

Think of this as telling Git:

“Hey, these commits belong to me.”

2. Start Working With a Repository

There are two common ways to start working with Git.

• Create a New Repository

git init

Initializes Git inside your current project folder.

Use this when you already have a project on your computer and want Git to start tracking it.

• Clone an Existing Repository

git clone <repo_url>

Downloads an existing repository to your computer.

Use this when a project already exists on a remote platform such as GitHub and you want a local copy.

• Easy way to remember:

git init → start Git here

git clone → bring an existing repository here

3. Track and Save Your Changes

This is where you'll probably spend most of your time.

Imagine this:

You changed three files and now have absolutely no idea what Git thinks happened.

Start with:

• Check What Changed

git status

Shows modified, staged and untracked files.

When you're confused about what's happening in your repository:

Run git status.

Seriously.

• Review Your Changes

git diff

Shows changes that haven't been staged yet.

It's useful when you want to review your work before staging it.

Think:

“What exactly did I change?”

→ git diff

• Stage a Specific File

git add <file>

Example:

git add index.html

This tells Git:

“Include this file's changes in my next commit.”

• Stage Everything

git add .

Stages changes under the current directory and its subdirectories.

It's convenient when you're sure you want to include those changes.

Still, it's a good habit to check:

git status

before committing.

If you only want to stage a specific file:

git add <file>

• Create a Commit

git commit -m "Add login form"

A commit is basically a checkpoint for your project.

Instead of:

git commit -m "changes"

prefer something descriptive:

git commit -m "Fix navbar responsiveness"

Good commit messages make your project history much easier to understand.

Think:

Commit = save a checkpoint of your staged changes.

• See Your Commit History

git log

Shows previous commits along with information such as the author, date and commit message.

Want a shorter version?

git log --oneline

This gives you a compact view of your commit history.

4. Work With Branches

Branches let you work on features, experiments or fixes separately from your main branch.

For example:

main
 │
 ├── feature/navbar
 ├── feature/login
 └── fix/mobile-layout

Instead of experimenting directly on main, you can create a separate branch for your work.

• See Your Branches

git branch

Lists your local branches.

• Create a Branch

git branch <name>

Example:

git branch feature/navbar

Creates a new branch but does not switch you to it.

• Switch Branches

Modern Git provides git switch specifically for changing branches:

git switch <branch>

Example:

git switch feature/navbar

You may also see this older, still-common command:

git checkout feature/navbar

You don't necessarily need to use checkout for everyday branch switching but you should recognize it because you'll encounter it in older tutorials and projects.

• Create and Switch to a Branch

With modern Git:

git switch -c <branch>

Example:

git switch -c feature/navbar

This does two things:

Create branch → Switch to branch

You may also see:

git checkout -b feature/navbar

Both patterns are worth recognizing.

• Merge a Branch

Suppose you're currently on main and want to bring changes from feature/navbar into it:

git merge feature/navbar

Git combines the changes from the specified branch into your current branch.

The important part:

Git merges into the branch you're currently on.

So if you're on main:

git merge feature/navbar

means:

“Bring feature/navbar into main.”

5. Work With Remote Repositories

Your local Git repository and a remote repository such as GitHub are separate.

These commands help you synchronize them.

• See Connected Remotes

git remote -v

Shows the remote repositories connected to your project.

• Add a Remote

git remote add origin <url>

origin is simply the conventional name for the remote repository.

• Push Your Commits

git push origin <branch>

Example:

git push origin main

Uploads your local commits to the remote repository.

Think:

push → send my commits to the remote

• Pull Remote Changes

git pull

Gets changes from the remote repository and integrates them into your current branch.

Depending on your Git configuration that integration may involve merging or rebasing.

For beginners, remember:

pull → get remote changes + integrate them

• Fetch Remote Changes

git fetch

Downloads information about remote changes without automatically integrating them into your current branch.

A simple way to remember the difference:

fetch = get the information

pull = get + integrate

6. Undo and Manage Changes

This is where Git can start feeling a little scary.

But you don't need to memorize every recovery command.

Here are some common situations.

• Unstage a File

If you've staged a file but want to remove it from the staging area while keeping your changes:

git restore --staged <file>

Example:

git restore --staged index.html

Think:

“Keep my changes, but take this file out of staging.”

You may also see:

git reset <file>

in older tutorials and workflows.

• Safely Undo a Commit

git revert <commit_id>

Creates a new commit that reverses the changes introduced by an earlier commit.

This is useful when you want to undo a committed change while keeping the existing history intact.

• Temporarily Save Your Changes

git stash

Imagine you're working on something unfinished and suddenly need to switch branches.

You don't want to commit the unfinished work.

That's where stash can help.

git stash

Temporarily stores your local changes.

• Bring Stashed Changes Back

git stash pop

Restores the most recently stashed changes and removes that stash entry if the changes are applied successfully.

Easy way to remember:

stash → put it away

stash pop → bring it back

• Remove a File

git rm <file>

Removes the file and stages that removal.

Example:

git rm old-file.js

• Rename or Move a File

git mv <old> <new>

Example:

git mv old.js new.js

Renames or moves a file while letting Git track the change.

7. The Git Workflow You'll Actually Use

For many everyday tasks, the workflow looks like this:

Make changes
     ↓
git status
     ↓
git diff
     ↓
git add .
     ↓
git commit -m "Describe your changes"
     ↓
git push

Think of it as:

Change → Check → Review → Stage → Commit → Push

That's the basic rhythm you'll repeat constantly while working with Git.

Once you understand this flow, individual commands become much easier to remember.

8. What to Remember First

If you're completely new to Git, don't try to memorize everything at once.

Start with these:

git status
git diff
git add
git commit
git log
git switch
git pull
git push

Then gradually add:

git init
git clone
git branch
git merge
git fetch
git stash
git revert
git restore

You don't need to know Git perfectly before using Git.

Use the commands. Understand what they do. Look them up when you forget.

Eventually, they become second nature.

And when you forget one?

That's what cheat sheets are for.

Bookmark This

Git isn't about memorizing hundreds of commands.

It's about understanding the workflow:

Change
  ↓
Check
  ↓
Review
  ↓
Stage
  ↓
Commit
  ↓
Push

Once that workflow makes sense, Git becomes much less intimidating.

You don't need to remember every command today.

You just need to know what you're trying to do and which command helps you do it.

And yes...

you'll probably still Google git stash six months from now.

Save this for the next time Git decides to humble you.

And tell me:

Which Git command took you the longest to understand? 👇

The AI Was Right. The Answer Was Still Wrong.

Akanksha Sharma — Fri, 25 Sep 2026 14:37:12 +0000

Have you ever asked AI to do something very specific and it did almost everything right?

Except the one thing you specifically told it not to do.

That made me curious.

Instead of asking “Which AI model is smartest?” I wanted to test something much more specific:

Can AI actually follow small instructions while solving a task?

What I Benchmarked

I created a benchmark focused on instruction following in coding tasks.

For example:

Fix this JavaScript function.
Don't use map().
Return only the corrected code.

The model isn't only expected to fix the bug.

It also needs to follow every instruction.

So I check:

Did it solve the problem?
Did it use the requested language?
Did it avoid the prohibited method?
Did it follow the required output format?
Did it change anything that wasn't requested?

Because sometimes the answer is correct but the task isn't.

How I Tested the Models

The testing flow is simple:

Same prompt → Multiple models → Same evaluation → Compare

For every task, I:

Give the exact same prompt to each model.
Collect their responses.
Check whether the main problem was solved.
Check each instruction separately.
Record which instructions were followed or violated.
Compare the results across models.

This keeps the test focused on the model's behavior rather than changing the task for each model.

How I Measured It

I didn't want a simple right/wrong score.

A response can solve the coding problem while still breaking one of the instructions.

So I measure two things separately:

1. Task Correctness
Did the model actually solve the underlying coding problem?

2. Instruction Compliance
Did it follow the individual constraints in the prompt?

For example if a task contains four requirements and the model follows three:

3 / 4 = 75% instruction compliance

Across the benchmark these scores can show whether a model is not only capable of solving the problem but also capable of doing exactly what was asked.

Why This Interested Me

AI is becoming a bigger part of everyday coding.

We often focus on whether a model can generate working code but real developer tasks usually come with constraints:

“Don't change this.”

“Use this approach.”

“Return only the code.”

“Don't use this method.”

Those tiny instructions can completely change whether the response is actually useful.

That's the behavior I wanted to investigate.

What I'm Looking For

The interesting part isn't simply finding a model with the highest number.

I'm looking for patterns.

Do models struggle more when there are several constraints?

Does solving the code correctly make instruction following more reliable?

Which types of instructions are most commonly ignored?

And can a model be technically right while still being practically wrong?

Those are the questions this benchmark is designed to explore.

What I'd Test Next

If I expand the benchmark I'd add:

Multi-turn instructions
Longer prompts
More constraints in a single task
Conflicting instructions
Ambiguous instructions
More complex code editing tasks
Self correction after an instruction following mistake

That could reveal whether instruction following remains reliable as tasks become more realistic.

Your Turn

Now I'm curious about your experience.

What's the smallest instruction you've given an AI that it completely ignored? 😭

Drop it in the comments.

Maybe your most frustrating AI moment becomes the next benchmark task.

An AI Agent That Checks Before It Answers

Akanksha Sharma — Fri, 18 Sep 2026 18:04:16 +0000

I’ve had this happen more times than I’d like to admit.

I ask AI a technical question.

It gives me a beautifully written answer.

I think:

“Wow. That makes sense.”

Then I check the documentation.

And suddenly:

“Oh.” 😭

The answer wasn't completely useless.

It just didn't have enough context.

That little problem became the idea behind ContextGuide.

What if an AI agent looked things up before answering?

Instead of expecting an AI model to magically know everything, I wanted to give it something better:

a reliable place to look.

ContextGuide is an AI agent that queries a structured Knowledge Base through Sanity Context + MCP before generating an answer.

The idea is simple:

Don't just ask the AI what it knows. Give it somewhere useful to look.

How ContextGuide Works

              👤 USER
                 │
                 │ asks a question
                 ↓
        ┌─────────────────┐
        │  ContextGuide   │
        │                 │
        │ Understand the  │
        │ question        │
        └────────┬────────┘
                 ↓
        ┌─────────────────┐
        │ Sanity Context  │
        │                 │
        │ Find relevant   │
        │ knowledge       │
        └────────┬────────┘
                 ↓
        ┌─────────────────┐
        │  KNOWLEDGE BASE │
        │                 │
        │ Docs • Guides   │
        │ References      │
        └────────┬────────┘
                 ↓
        📚 Relevant Context
                 │
                 ↓
        🤖 Agent Reasoning
                 │
                 ↓
        💬 Answer + Sources

The important part is that the agent doesn't immediately jump from:

Question → Answer

There is a middle step:

Question → Context → Answer

And that middle step is the whole point.

Why Sanity?

Let's say I ask:

“Which authentication method should I use here?”

A basic search might find ten pages containing the word authentication.

Great.

Except... which one actually answers my question? 😅

That's where structured content becomes useful.

With Sanity, information can be organized into meaningful content instead of being treated as one giant pile of text.

ContextGuide can then retrieve the relevant information through Sanity Context and access it through MCP.

So the agent isn't just matching words.

It's trying to find the right context for the question.

The Part That Interests Me Most

What happens when the knowledge base contains conflicting information?

Imagine:

📄 Guide A
"Use Method X."

        +

📄 Guide B
"Method X is outdated."

        ↓

      Agent

"These sources disagree."

That's actually more interesting to me than an agent that confidently picks one answer.

Because sometimes the honest answer isn't:

“Here's the answer.”

Sometimes it's:

“Here's what the sources say and here's where they disagree.”

That is information I can actually work with.

Where Each Piece Fits

Sanity
   ↓
Organizes the knowledge

Sanity Context
   ↓
Makes that knowledge queryable

MCP
   ↓
Connects the agent to it

ContextGuide
   ↓
Uses the retrieved context

User
   ↓
Gets an answer backed by the relevant content

Each piece has a job.

Sanity isn't there just because the challenge says to use Sanity.

It's part of the reason the agent can work this way.

What I Wanted to Build

I wasn't trying to build an AI that knows everything.

Honestly, that sounds exhausting. 😭

I wanted to build an AI that knows when it should look something up.

Because maybe the future of useful AI isn't just:

“I know the answer.”

Maybe it's:

“Let me check the right information first.”

And that's the idea behind ContextGuide.

I Vibe-Coded a Website for Moods That Shouldn’t Exist

Akanksha Sharma — Fri, 18 Sep 2026 17:14:16 +0000

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange.

I wanted to build something useful.

Then I changed my mind. 😭

Instead, I decided to build MoodShelf -a tiny website for fictional moods that are weirdly relatable.

Think:

☕ Monday Coffee
Tastes like unread emails.

🛏️ The 5-Minute Nap
Somehow lasted 3 hours.

💻 Deadline Mode
Activated exclusively at 11:57 PM.

Basically, a tiny museum for feelings that probably shouldn't have names.

What I Built

MoodShelf is a collection of strange, fictional moods.

Each mood has things like:

Name
Description
Category
Vibe score
Image
Related moods

The fun part?

Instead of hardcoding all of this into the website, I used Sanity to manage the content.

How MoodShelf Works

The workflow is pretty simple:

  Create a weird mood
          ↓
  Add the content in Sanity
          ↓
  Sanity stores the structured data
          ↓
  MoodShelf displays it
          ↓
  People browse the moods
          ↓
  "Why is this so relatable?"

The idea is to keep content and the website separate.

If I want to add a new ridiculous mood, I can add it in Sanity without rewriting the whole website.

So the next time I invent something like “Sunday Scaries Lite™”, I just add it to the collection and let MoodShelf do the rest.

Which feels like an excellent use of technology. 😂

The Vibe-Coding Part

My development process was basically:

  "I have an idea."
        ↓
    Prompt AI
        ↓
    Generate
        ↓
  Look at what happened
        ↓
  Something breaks
        ↓
  Ask AI why
        ↓
     Fix it
        ↓
     Repeat

Very scientific.

Very professional.

Definitely not me staring at an error message wondering what I did. 😭

But that was actually one of the interesting parts of the challenge.

Vibe coding wasn't just:

“AI, build everything for me.”

It was more like:

“Here's what I want. Now help me get there.”

I still had to decide what the app should do, what the content should look like, what needed fixing and whether the generated code actually made sense.

Why Sanity?

MoodShelf doesn't need complicated content.

But it was a fun way to understand the difference between content and the website displaying that content.

Sanity handles the content.

MoodShelf handles the experience.

That means I can keep adding completely unnecessary moods without constantly changing the app itself.

Which feels like an excellent use of technology. 😂

What I Learned

The biggest thing I learned wasn't how to make a website about fictional moods.

It was how different development feels when you can describe an idea first and then iteratively shape the result with AI.

You still need to:

understand what you're building
give clear instructions
inspect the output
catch mistakes
make decisions
and occasionally tell the AI, “No. That's not what I meant.” 😭

AI can speed up the building process.

But you still need to be the person holding the steering wheel.

Final Thought

Does the world need another website containing fictional moods?

Probably not.

Did I enjoy building one anyway?

Absolutely.

Sometimes the best way to learn a new tool isn't to build another serious dashboard or task manager.

Sometimes you just need to build something slightly ridiculous and see where it takes you.

And apparently, I had a lot of imaginary moods to catalogue. 🫠

Now I'm curious...

What weird mood would you add to MoodShelf? 👀

Give it a name and a one-line description in the comments.

I might just have to add the best ones. 😂

💙 KindLink - Because “I Want to Help” Is Not a Plan 😭

Akanksha Sharma — Sat, 05 Sep 2026 16:04:05 +0000

This is a submission for the Weekend Challenge: Generosity Edition.

Have you ever thought:

“I really want to help people.”

…and then immediately:

“Okay, but HOW?” 🤔

Same.

We often want to be generous but turning that feeling into an actual action isn't always easy.

That little gap between wanting to help and knowing how to help is what made me think:

What if something could connect the two?

So for this challenge, I came up with KindLink. 💙

🌱 What I Created

KindLink is an AI powered platform concept designed to help people discover practical ways to give back based on what they already have.

Because generosity isn't always about money.

You might have:

Free time
A useful skill
Knowledge to share
Resources someone needs
Money to donate

The idea is simple:

“What can I give?” → “Here’s how I can use it.”

🔄 How Would KindLink Work?

Imagine opening KindLink and seeing:

┌──────────────────────┐
│     YOUR PROFILE     │
│                      │
│   Free Time          │
│   Skills             │
│   Interests          │
│   Knowledge          │
│   Resources          │
└──────────┬───────────┘
           ↓
     🤖 KINDLINK AI
           ↓
┌──────────────────────┐
│   YOUR KIND MATCHES  │
│                      │
│    Design for NGO    │
│    Mentor Students   │
│    Social Media Help │
└──────────┬───────────┘
           ↓
       ❤️ TAKE ACTION

No resume required. 😂

1️⃣ Tell KindLink what you can give

For example:

“I have 2 hours every weekend, I'm good at graphic design and I want to help children.”

That's enough for KindLink to understand what you might be able to offer.

2️⃣ AI connects the dots 🤖

Instead of throwing 500 random volunteering opportunities at you, the idea is for KindLink to consider:

Your skills + Your interests + Your availability + Your limitations

…and find opportunities that actually fit.

For example:

┌──────────────┐
│ WHAT I HAVE  │
│              │
│ 2 hrs/week   │
│ Design skill │
└──────┬───────┘
       │
       +
       │
┌──────▼───────┐
│ WHAT I CARE  │
│    ABOUT     │
│              │
│ Helping kids │
└──────┬───────┘
       │
       +
       │
┌──────▼───────┐
│ MY LIMITS    │
│              │
│ Weekends     │
│ Online only  │
└──────┬───────┘
       ↓
   🤖 AI MATCH
       ↓
┌────────────────────┐
│ 🎯 95% MATCH       │
│                    │
│ Create educational │
│ materials for kids │
└────────────────────┘

So instead of:

“Here are thousands of ways to volunteer. Good luck.” 😭

KindLink could say:

“This one looks like you.”

💡 What Could You Actually Do?

For our imaginary graphic designer, KindLink might suggest:

🎨 Create educational materials
Help a nonprofit create worksheets or learning resources.

📱 Help with social media
Use design skills to help a small organization improve its online presence.

📚 Mentor students online
Spend a couple of hours helping students learn something you're already good at.

The goal isn't simply to tell people:

“Go volunteer.”

It's to answer:

“Here’s something YOU can realistically do.”

❤️ From Intention to Action

Because there's a big difference between:

“I should help someday.”

and

“I'm helping this Saturday.”

The journey could look like this:

💭 "I want to help"
          ↓
      🤔 "But how?"
          ↓
     🤖 KindLink
          ↓
   🎯 Find my match
          ↓
   📅 Pick a time
          ↓
     ❤️ "I'll help"

That's the whole idea.

Less friction. More action.

🤖 Why AI?

I didn't want to add AI just because every project apparently needs a chatbot now. 😭

The actual problem is finding the right match.

There are countless ways to help but not every opportunity is suitable for every person.

AI could make that process more personal by connecting:

What you can offer
What you care about
What you actually have time for
What you're realistically able to do

A realistic way to make an impact. 🌱

💭 Why This Idea?

This challenge made me think about generosity beyond donating money.

Sometimes helping someone means giving:

Two hours of your weekend.
A skill you've spent years learning.
Something you know how to teach.
A resource you no longer need.

Or even:

“Hey, I know someone who can help.”

Everyone has something they can give.

Sometimes we just need help figuring out where it can make a difference.

That's the idea behind KindLink.

Less “I should help.”

More “Okay, I know how I can help.” 💙

Thanks to the DEV team for the challenge. It got me thinking about how technology can encourage small, realistic acts of generosity instead of just helping us order food faster. 😂❤️

🤖 Can Vibe Coding Get You Hired as a Developer?

Akanksha Sharma — Tue, 01 Sep 2026 11:26:25 +0000

Yes. But There's a Catch.

Or are you just really good at asking AI to fix the code AI wrote? 😭

Let's be honest.

A few years ago, getting hired as a developer meant proving you could write code.

Today?

You can type:

“Build me a full-stack app with authentication, payments, AI, dark mode and absolutely no bugs.”

30 seconds later…

Congratulations! You are now the CTO. 💀

Welcome to vibe coding.

🤔 What is vibe coding?

It's basically:

Describe → Generate → Run → Break → Ask AI to fix it → Repeat.

And honestly?
It feels amazing.

Don't remember the syntax?
AI knows it.

Don't remember the API?
AI knows it.

Created 17 errors?

AI is already typing:

“I understand the issue.”

Meanwhile you're thinking:

“Same bro. I also understand the issue.” 😭

Except sometimes…

AI doesn't.

And that's the important part.

🧠 Can it actually get you hired?

Yes, but “I can vibe code” isn't the skill companies are hiring for.

The valuable skill is:

“I can use AI to build something, understand what it generated, debug it and make the right technical decisions.”

That's very different from:

“AI built my entire app.”

Companies still need developers who understand:

Programming → APIs → Databases → Git → Debugging → Testing → Security → Architecture

Because AI can generate code that looks perfect…

…and still be completely wrong. 🥲

💻 And here's where vibe coding gets really powerful

You don't even have to be a professional developer to benefit from it.

A designer can build a prototype.

A founder can build an MVP.

A marketer can automate a repetitive task.

A data analyst can create a dashboard.

A product manager can test an idea.

For these people, vibe coding removes the barrier between:

“I have an idea.”

and

“I built something.”

That's genuinely revolutionary.

But if software engineering is your actual job, the bar is different.

Professional software isn't just:

“Does it work?”

It's:

“Why does it work, what can break and is this the right solution?”

🧩 Vibe coding ≠ skipping fundamentals

You don't need to memorize every syntax rule.

You don't need to write repetitive boilerplate for hours.

If AI can save you two hours of boring coding…

LET IT.

But you still need enough fundamentals to judge its output.

Because when AI gives you 400 lines of code, someone has to ask:

“Is this actually a good solution?”

That someone should be you.

AI reduces the amount of code you type.
It doesn't reduce the amount of engineering you need to understand.

⚡ AI can make you faster. Not automatically better.

Imagine two developers.

Developer A:
AI writes everything.
Copies the solution.
Can't explain the architecture.
Something breaks → “ChatGPT, fix this.”

Developer B:
Uses AI for boilerplate, debugging, testing and exploring solutions.

But still:

Reads the code.
Questions the code.
Tests the code.
Owns the final decision.

Who would you hire?

Exactly.

🚀 So what's the future?

I don't think the future belongs to the developer who writes the most code.

It belongs to the developer who can:

Think clearly.
Build quickly.
Understand deeply.
Use AI intelligently.

Don't become:

Prompt → Copy → Paste → Pray 🙏

Become:

Understand → Think → Prompt → Review → Test → Improve

Because when AI-generated code breaks in production at 2 AM…

your manager isn't going to ask the AI what happened. 💀

They're going to ask you.

💡 The goal isn't to code without AI.

It's to become a developer who is better because AI exists.

There's a big difference between:

“AI built this for me.”

and

“I built this with AI.”

And I think that difference is going to matter more and more.

👇 Your turn

Would you hire a developer who can build an entire application using AI but can't explain the code without AI?

Where do you draw the line between an AI-assisted developer and a professional vibe coder? 👀

5 Years Ago, Git & I Met… 💀

Akanksha Sharma — Sat, 29 Aug 2026 12:46:29 +0000

5 years ago, I encountered Git & GitHub for the first time.

And let me tell you…

It was NOT love at first commit. 😭

I watched someone casually type:

git add .
git commit -m "Initial commit"
git push origin main

And I was sitting there like:

“Damn. I’m officially a developer now.” 😎💻

Meanwhile, my brain was running on 2% battery:

"git add ." → “Add WHAT?”
"git commit" → “Commit to WHAT?”
"git push" → “Push WHERE?”
"origin" → “WHO IS ORIGIN? 😭”

But did I ask?

Absolutely not.

Because apparently, beginner confidence is just confusion with good posture. 💀

So I did what every totally confident beginner does:
Copy → Paste → Enter → Pray. 🙏🏻

And then…

💥 ERROR.

Me: “Hmm… interesting.”
Git: another error
Me: “Okay…”
Git: another error
Me: “Why does this feel personal?” 😭

My debugging process was basically:

Google the error 🔎
↓
Open Stack Overflow
↓
Find a command written in 2017
↓
Copy it without understanding anything
↓
Paste
↓
Press Enter
↓
Stop breathing

And when it finally worked?
“Yeah, yeah… I knew what I was doing.” 😌

Narrator:
She absolutely did not. 💀

Back then,
GitHub was basically:
“That website where I upload my code.”

And Git?
“Those scary commands I hope I don't accidentally destroy everything with.” 😭

But eventually, I realized something:

I didn't want to just memorize Git commands.
I wanted to actually understand what Git was doing behind the scenes.

So I started my Git & GitHub Zero to Hero series, starting from absolute zero and explaining things without assuming you already know everything.

Because honestly…

Nobody should have to pretend they know what "origin" is. 😂🤝

And if you're currently in the:

“WHO IS ORIGIN?”

phase…

Welcome. You're among friends. 💀😂

Be honest,what was the first Git command that made absolutely ZERO sense to you?

AI Isn’t Killing Tech Jobs. But It Is Changing Who Gets Hired. 🤖

Akanksha Sharma — Mon, 24 Aug 2026 13:37:11 +0000

If you don't want to read the whole thing, here's the short version:

Yes, AI is affecting the tech industry.

But I don't think the story is simply:

“AI will replace developers.”

I think the bigger story is:

AI is changing what companies expect from developers.

And honestly, that shift has already started.

AI can generate code, explain errors, write unit tests, create documentation, refactor functions, analyze logs and automate repetitive development tasks.

A task that might once have taken an hour can sometimes take 15 minutes with the right AI tools.

And yes, that can affect hiring.

If a smaller team can deliver the same amount of work because every developer is more productive, companies may need fewer people for certain types of work.

That's the part we shouldn't ignore.

But software engineering isn't just typing code.

AI can generate code. Engineering is more than code.

Imagine you're building a payment system.

AI can help you write an API endpoint.

It can generate a database query.

It can suggest error handling.

It can even write tests.

But who decides:

Should the API be REST or event-driven?
How should authentication work?
What happens if the payment succeeds but the database update fails?
How do we prevent duplicate transactions?
What data should be logged?
How should sensitive information be protected?
Will this architecture scale when traffic increases?

Those aren't simply code-generation problems.

They're engineering problems.

AI can suggest solutions, but developers still need to understand the trade-offs and validate those solutions.

AI can generate code. But code isn't the same thing as engineering.

AI is changing the development workflow

Think about a typical development cycle.

Before AI, a developer might:

Requirement → Research → Code → Debug → Test → Review → Deploy

With AI assistance, parts of that workflow can become:

Requirement → AI-assisted research → Generate → Review → Test → Debug → Deploy

The difference is important.

The developer's job doesn't necessarily disappear.

The developer's time shifts toward higher-value decisions.

Instead of spending 30 minutes writing boilerplate, you might spend that time reviewing architecture.

Instead of manually writing every test case, you might use AI to generate a starting point and then verify edge cases yourself.

Instead of searching through documentation for every small syntax issue, you can ask AI for an explanation and validate it against the actual documentation.

That's productivity.

But there's an important catch.

AI can also create problems faster

If you don't understand the code AI generates, you're essentially turning your lack of understanding into technical debt.

AI-generated code can contain:

Logic errors
Security vulnerabilities
Poor database queries
Incorrect assumptions
Unnecessary dependencies
Performance problems
Outdated APIs

And sometimes the code looks perfectly reasonable.

That's what makes it dangerous.

A developer who understands the fundamentals can ask:

“Why did AI choose this approach?”

A developer who doesn't may simply ask:

“Does this code run?”

Those are very different questions.

And that's why fundamentals such as data structures, algorithms, databases, networking, system design, security and debugging still matter.

Possibly more than before.

The developer skill set is changing

The valuable skill isn't simply:

“I can write JavaScript.”

It's becoming:

“I can use JavaScript, understand the system I'm building and use AI to solve problems more efficiently.”

For example, knowing React is useful.

But understanding:

component architecture
state management
rendering behavior
API communication
performance
accessibility
security
testing

is much harder to replace with a code generator.

The same applies to backend development.

Knowing how to generate an Express or FastAPI endpoint is useful.

Understanding authentication, authorization, database indexing, caching, concurrency, API design, observability and scalability is much more valuable.

AI can help you learn and implement these concepts.

But it doesn't remove the need to understand them.

So who is actually at risk?

Probably not simply “developers.”

The bigger risk is for developers whose work consists largely of predictable, repetitive tasks and who don't expand their skill set as the tools around them improve.

And this creates an interesting situation for entry-level developers.

Junior developers traditionally learn by working on smaller tasks:

Fix this bug.
Build this component.
Write this API.
Add this validation.

AI can increasingly assist with many of those tasks.

So beginners may need to differentiate themselves through something beyond simply being able to produce code.

Problem-solving.

Debugging.

Understanding systems.

Communication.

Learning quickly.

And most importantly:

Knowing why the code works, not just how to generate it.

So, what should developers do?

Don't panic.

Don't blindly trust AI.

And don't ignore it either.

Instead:

Strengthen your fundamentals.

Use AI for repetitive work and exploration.

Learn to review AI generated code critically.

Understand security and performance implications.

Get better at debugging.

Learn system design and architecture.

And build projects where you can explain every major technical decision you made.

Because the future probably isn't:

AI vs Developers

It's more likely:

Developers who use AI vs developers who don't.

But there's an even bigger distinction:

Developers who understand what AI generates vs developers who simply copy it.

So maybe the question isn't:

“Will AI take my job?”

Maybe the better question is:

“If AI makes my current skills cheaper, what valuable skills should I build next?”

Because the developers who can combine strong fundamentals + engineering judgment + AI tools may end up being the most valuable ones.

And now I'm curious:

Do you think AI will mostly reduce junior jobs, senior jobs or change both? 👇

I Blamed React for 45 Minutes. The Bug Was One return. 😭

Akanksha Sharma — Thu, 20 Aug 2026 15:19:52 +0000

There are two types of Developers:

People who write clean, predictable code.
People who add console.log() until the browser starts feeling like a crime scene.

I am, unfortunately, Team #2. 🫠

And this story is about the time I spent 45 minutes debugging React only to discover that JavaScript was waiting for me to type one tiny word.

return

It started innocently enough...

I had a React component fetching data from an API and displaying it on the page.

Pretty normal stuff.

The API was working. ✅
The data was coming back. ✅
The component was rendering. ✅

The UI?
Nothing.

Just an empty page.
Beautiful.
Minimalist.
Very intentional-looking.
Definitely not broken.🙂

So obviously, I started investigating.

First thought:

“Maybe the API isn't working.”
Checked it.
Working.

Then:

“Maybe the state isn't updating.”
Checked it.
Working.

Then:

“Maybe something is wrong with the component.”
Checked it.
Also working.

At this point, I reached the most logical conclusion:

React is broken.

Obviously.

So I did what every experienced developer does when they have absolutely no idea what's happening:

console.log("Component rendered");
console.log("API called");
console.log("Data received:", data);
console.log("Users:", users);
console.log("WHY IS THIS EMPTY???");

My console was slowly becoming a conversation with myself.

Then I found the crime scene.

This was the code:

{users.map(user => {
  <div key={user.id}>
    <h3>{user.name}</h3>
  </div>
})}

I stared at it.
It looked fine.

I stared at it again.
Still fine.

Then I noticed it.

There was no return.😭

The problem wasn't React.
The problem wasn't the API.
The problem wasn't my state.

The problem was...

"ME"

When you use curly braces with an arrow function, you need an explicit return.

So instead of:

{users.map(user => {
  <div key={user.id}>
    <h3>{user.name}</h3>
  </div>
})}

I needed:

{users.map(user => (
  <div key={user.id}>
    <h3>{user.name}</h3>
  </div>
))}

And just like that...

THE UI APPEARED.

I genuinely sat there for a few seconds thinking:
“You have got to be kidding me.”

45 minutes.

Forty.

Five.

Minutes.

I had checked the API.
I had checked the state.
I had checked the component.

I had added enough console.log() statements to qualify as a documentary.

I was mentally preparing to rewrite the entire component.

Meanwhile, JavaScript was basically sitting there like:
“You forgot to return the thing.”

Fair enough.

My highly sophisticated debugging methodology

Minute 1:
“This should work.”

Minute 5:
“Maybe it's the API.”

Minute 10:
“Let's check the state.”

Minute 15:
“Let me add a console.log().”

Minute 20:
“Okay, another one.”

Minute 30:
“Why is React doing this to me?”

Minute 40:
“Maybe I'll just rewrite the component.”

Minute 45:
“Oh.”

return. 😭

The actual lesson

The funny thing is, this wasn't some complicated React bug.
I didn't discover some hidden rendering issue.
I didn't need a fancy debugging tool.
I just missed one tiny JavaScript rule.

And honestly, that's probably one of the most annoying things about debugging:

The longer you stare at a bug, the harder it can become to see the obvious.

Sometimes the problem is genuinely complicated.

And sometimes you've spent 45 minutes investigating your entire application because you forgot one word.

So now, before I start blaming React, I'm trying to go through the boring checklist first:

Is the component rendering?
Is the data actually there?
Is the state updating?
Is my .map() returning something?
Did I spell the variable correctly?
Did I accidentally comment something out?
Did I, in fact, forget something incredibly obvious? 👀

Because apparently, that's a real debugging step now.

And yes, I still use console.log().

I'm not going to pretend this experience magically turned me into a debugging expert.

The next time something breaks, I'll probably still do:

console.log("HERE");
console.log("HERE 2");
console.log("HERE 3");

And then I'll stare at the screen.
And refresh.
And refresh again.
And blame React.

But maybe...

I'll check the return first. 😂

Your turn 👇

What's the stupidest bug you've spent way too long debugging?

The kind where you finally find the problem and just sit there thinking:

“...I cannot believe I just did that.”

Please tell me I'm not alone. 😭

First Post on DEV 🚀

Akanksha Sharma — Wed, 19 Aug 2026 12:27:14 +0000

Hello, DEV Community! 👋

After spending a lot of time learning, building, breaking things, fixing them and occasionally wondering “Why is this not working? ” 😅 -I finally decided to make my first post here.

I’m a Software Engineer and my journey so far has taught me something important:

Software engineering isn’t just about writing code.

• It’s about solving problems when there’s no obvious answer.
• It’s about debugging something you were sure was working.
• It’s about making mistakes, learning from them and trying again.

And sometimes, it’s simply about figuring things out one step at a time. 💻

I’ve had my share of challenges, unexpected bugs, learning curves and those small wins that make all the frustration worth it.

From now on, I want to share more of that journey here -not just the final results, but the problems behind them, the mistakes, the solutions and the lessons learned along the way.

No “I know everything” posts.

Just learning, building, experimenting and growing in public.🌱

What’s one lesson software engineering has taught you that you wish you knew when you started?