DEV Community: Mohanragul

I Wasted a Day, Then Built an AI That Identifies Bears — 4 Days of Real Learning

Mohanragul — Wed, 20 May 2026 17:34:07 +0000

May 17 was a write-off.

No learning. No building. Just YouTube, doom scrolling, and the slow awareness that I was avoiding everything I was supposed to be doing. I didn't spiral about it. I just watched it happen and let the day end.

Honest starting point.

Doing a Little When You Don't Feel Like It

Recovery doesn't look dramatic. It looks like sitting down and doing something small even when nothing feels like it matters yet.

I started FastAI from where I leave, got back into the course, handled some other things. Not a productive day by any measure — but motion is motion. The point wasn't output. It was direction.

The Workflow Started Making Sense

Completed FastAI Modules 1 and 2 with the book chapters, then built the classic dog-vs-cat image classifier.

Most of the code was course-guided, but something clicked about the core loop: feed labeled images in → model trains → pass a new image through → get a label and confidence score. Train, predict, evaluate. That's the foundation for everything else in this course.

Seeing it run on cats and dogs made it concrete in a way that reading about it hadn't.

The Bear Classifier

Module 3 done. Bear classifier built — classifies images as black bear, grizzly, or teddy bear.

It works. Watching it correctly label a grizzly I fed it was one of those moments that feels disproportionately satisfying. You know it's a beginner project. It's still your beginner project, and it ran.

One practical heads-up if you're following the same course: the FastAI content is a few years old, and the image collection section uses a Bing Search API free tier that no longer exists without entering card details. Hit that wall early. The fix: switch to DuckDuckGo image search via Python — fully free, works the same way for pulling training images. Worth knowing before you run into it.

What Four Days Actually Taught Me

May 17 didn't erase May 19 and May 20. Obvious in theory — easy to forget when you're in it, treating one bad day like it resets your streak to zero.

The more useful takeaway: small practical projects move understanding forward faster than rushing through theory. The dog-vs-cat and bear classifiers are simple. Neither required deep knowledge. But building them made concepts stick in a way that reading alone hadn't managed.

Consistency isn't about perfect productivity. It's about what you do after the wasted day.

May 18 wasn't impressive. It was just necessary.

What does your recovery day look like when you lose momentum — do you push through, or let yourself reset first? 👇

I Deleted My Working AI Project and Rebuilt It From Scratch. Here's What I Learned.

Mohanragul — Sat, 16 May 2026 18:18:51 +0000

I had a working prototype in a few hours. It ran. It looked like something real.

I deleted it anyway.

Not because it was broken — because I couldn't explain what it was doing. And that felt worse than having nothing at all.

The Build and the Discard

The project was an AI API Cost Optimizer — monitor usage across multiple LLMs, route requests by cost, handle fallback logic when a model fails. Solid concept. Portfolio-worthy.

Cursor generated the structure fast.

Then I sat down to actually review it. I could read the code. I couldn't explain it. There's a difference. If someone had asked me why a specific routing decision was made, or what happens when two circuit breakers trigger at once — I would've guessed. And I wouldn't have known if I was right.

I deleted it entirely. Not to fix it slowly and hope comprehension would come. Just: delete, start over. Felt more honest than shipping something I couldn't own.

One Lost Day

Laptop issues. Service center. Hours of waiting.

I knew the day was gone by mid-afternoon and didn't force it. Some days are just the cost of having a life outside of building.

The Rebuild — One Piece at a Time

I started over with Claude. But the tool wasn't really the point.

What changed was how I worked.
The first time: described the full project, let the AI generate most of it in one pass.

The second time: one small piece at a time. Got the basic API connection working and understood it before touching the next part. Then routing logic — built it, read it, asked questions, moved on. Then fallback handling. Each piece had to make sense before I added the next one.
Slower. But the project grew in a way I could actually follow.

By end of day, the MVP was rebuilt and deployed. Same project, same concept — but this time I could explain every decision in it.

That's the difference between a project you built and a project that was built for you.

The Next Project — and a Deployment Reality Check

The next one was a RAG Knowledge Assistant: upload a document, ask questions, get answers grounded in its content. Dev went smoothly.
Deployment did not.

Free-tier hosting limits. Unexpected constraints. Hours debugging infrastructure that had nothing to do with the AI logic. The kind of problems tutorials skip because they assume everything just works.

It shipped. But the real lesson wasn't about RAG pipelines — it was that getting something running locally and getting it running somewhere real are completely different skills. That gap doesn't get talked about enough.

What I'm Actually Changing

AI speed is real and useful. But speed without understanding creates a problem — you end up with things you can't maintain, can't debug, and can't honestly call your own. The impressive-looking project you can't explain in an interview isn't an asset.

I'm not generating whole projects anymore. I build in pieces, stay at the edge of what I understand, and use AI to push that edge forward — not jump past it entirely.

The goal isn't to ship fast. It's to understand what I'm shipping.

Have you ever accepted generated code you didn't fully understand just to keep moving — did you ship it anyway, or did something make you stop? Let's talk in the comments 👇

I Over-Prepared for My First AI Project. Then Everything Failed on Day One.

Mohanragul — Wed, 13 May 2026 08:21:09 +0000

I had everything ready before I wrote a single line of code.

Detailed prompts. System design notes. Tech stack decisions. Workflow docs. Days of prep so that when I finally sat down to build, nothing would slow me down.

Then I started building. Almost all of it fell apart.

Day 1 — The Plan Collapsed

The prompts I'd crafted didn't produce what I expected. Outputs were inconsistent. I spent hours refining — restructuring, rewording, testing, getting slightly better results, then slightly worse ones.

Then it hit me: I wasn't building. I was still preparing — just in a different form.

So I made the only call that actually moved things forward: stop chasing the perfect setup. Build something functional instead.

Obvious in hindsight. Not obvious at hour four of testing prompts that were close but never quite right.

Day 2 — The Day It Actually Worked

Instead of jumping into code, I used AI as a thinking partner first — filling gaps, stress-testing my understanding. Not generating outputs. Just actually understanding the problem.

Then I started coding.

By end of day, I'd built and deployed AI Resume Tailor — a web app that analyzes your resume against a job description, returns a match score, and generates an AI-tailored version. Flask backend, React frontend, Gemini Flash API for the processing.

→ GitHub → Live app

What clicked for me: theory alone didn't make the prep make sense. Building with it did.

One real bottleneck — I hit my AI usage limit mid-build. Forced pause I didn't want. It also exposed something I'd been ignoring: my workflow has no clean fallback when AI-assisted momentum cuts off. Filed that under "things to fix."

Day 3 — The Day That Fought Back

I accidentally deleted an important AI conversation. Concept explanations I'd been building on — the kind of context that's annoying to reconstruct.

I sat with that frustration. Then I redid it.

Not gracefully. But I redid it, kept working through the concepts I needed for the next project, and that night started fast.ai's Deep Learning for Coders — Lesson 1 done.

Small move. Deliberate one.

The Pattern I Noticed

Three days isn't a lot of data. But it was enough.

I move fast. I rely heavily on structured AI workflows. I sometimes overprepare before testing whether the foundation is even solid. And I lose momentum to small things — no backup for important conversations, no plan for usage limits.

I haven't fixed any of it yet. But I've noticed it. And noticing a pattern before you have a solution means you'll recognize it faster next time.

Three messy days still shipped something real.

Have you ever prepared so hard for something that the preparation became the obstacle? How did you break out of it? Drop it in the comments 👇

I Built 10 AI Applications in 5 Days as a Beginner — Here's What Actually Happened

Mohanragul — Sat, 09 May 2026 09:31:03 +0000

Four days ago I was reading about what an API is.

By day four I had a working RAG application running locally on my machine — one that could answer questions using documents I fed it, without sending anything to an external server.

I'm still not sure how that happened. But I want to write it down before the feeling fades.

Where this fits in the journey

I'm midway through the IBM Applied AI Developer Professional Certificate. Courses 5 and 6 are where everything shifted — from understanding concepts to actually building things. Ten projects across five days.

This isn't a course review. It's an account of what building actually felt like.

Course 5 — Flask and backend development

I went in thinking the backend would be manageable.

I'd learned Node.js in my first year of college during a MERN stack module. I remembered the basics — routing, requests, how a server works. Enough to feel like I had a foundation.

What I didn't account for: after first year, I completely stopped touching backend. My focus drifted entirely to frontend. For two years I wrote UI, helped friends debug occasionally, and let everything else fade.

So when Flask came up, I didn't remember Node as much as I thought. What I remembered was the concept — how a backend is supposed to work. That was enough to adapt, even though the syntax was completely different.

What surprised me more was unit testing.

I'd seen it mentioned in coursework and always skipped past it mentally — something I filed under "I'll care about this later." During Course 5, I actually understood what it was for the first time. What it checks. Why it matters. Why writing tests isn't extra work but part of writing real software.

Here's the part I'm still thinking about.

During campus placements in my final year, a company selected me through a hackathon and called me for a final interview. They asked if I was comfortable with a testing role.

I said I didn't know much about testing and would prefer frontend, web development, or AI.

I didn't get the offer.

Sitting in a Flask unit testing module two years later, understanding what I casually dismissed in that room — that landed.

The Finance Tracker, Sentiment Analyzer, and Emotion Detector came out of Course 5. First time I connected a real frontend to a Flask backend. First time I saw how AI output fits into an application as a feature rather than the whole thing.

Course 6 — Building GenAI powered applications

This is where the ten projects came together. Image Captioner, Chatbot, Voice Assistant, Meeting Assistant, Translation Assistant, Job Application Coach — and the one I want to spend the most time on.

But let me be honest about a few things first.

The BlenderBot problem

The chatbot in the course used BlenderBot model from Meta. I want to say this clearly: in my experience, it was not BlenderBot. It was BlunderBot.

Responses were off — sometimes irrelevant, sometimes just strange. I spent time trying to figure out if I'd built it wrong before I realized the model itself was the issue. That was a useful lesson in its own way — the model matters as much as the application around it.

The translation app detour

The IBM translation API I was supposed to use wasn't accessible from my setup. So I found my own path.

I used Whisperfor speech-to-text and Piperfor text-to-speech. What I didn't know going in: Piper requires downloading an ONNXmodel file separately. The app broke. I searched, figured it out, downloaded the file.

Then Japanese voice models weren't available in my configuration. Then the audio format Piper produced wasn't compatible with the frontend.
Each of those was a small wall. I went over each one. The final app worked. It wasn't the one the course intended — but it was mine.

The LangChain version issue

This one cost me more time than anything else. The course imports used langchain.chains. In the current version of LangChain, that's moved to langchain_classic. The course materials hadn't been updated.

The application simply wouldn't run. No obvious error pointing at the real cause. I eventually found it — either downgrade the package or update every import. I updated the imports.

This is exactly the kind of thing that doesn't come up in passive learning. You only hit it when you're actually building something.

The Private RAG Application

RAG — Retrieval-Augmented Generation — is when an AI application retrieves relevant information from your own documents before generating a response. Instead of relying purely on what the model was trained on, it pulls from a source you control.

Building this one felt different from the others.

It was the first project where I could see how a real AI system is actually structured — not just a model answering questions, but a pipeline. Documents go in, get processed, get stored, get retrieved, and the model uses them to respond. Local. Private. Yours.

That architecture made something click that earlier courses had only described.

The honest part — most important paragraph in this post

Most of these were guided projects. I followed instructions. I used provided code as a starting point.

But wherever I could, I built my own version. I swapped APIs. I changed the frontend. I broke things and fixed them.

And even in the guided parts — practical implementation exposes gaps that passive learning hides. Reading about LangChain imports doesn't teach you what happens when they break. Understanding RAG conceptually doesn't show you what building the pipeline actually feels like.

You find out what you don't know only when the code doesn't run.

Day 5 is less about building fast and more about slowing down.

Today, I’m revisiting everything I’ve learned so far — reviewing my work, filling gaps, and understanding things more deeply instead of just moving on.

I’m also starting to explore what comes next: AI Agents and Practical Deep Learning.

But before jumping into another structured path, I want to build something independently first.

No tutorials. No step-by-step course.
Just a real problem, curiosity, and the tools I’ve learned so far.

What's next

Phase one is done. The foundation is there.

Phase two is building without a guide. That's where I'll find out what actually stuck. I'll write about it when I do — including the parts that don't work.

If you've built guided projects before — when did it start feeling like your own work? Was there a specific moment, or did it happen gradually?

Drop it in the comments. I'm genuinely trying to figure out where that line is. 👇

I Thought I Knew Python. I Was Wrong — Here's What Relearning It Actually Felt Like

Mohanragul — Tue, 05 May 2026 09:16:03 +0000

I opened IBM Course 4 — Python for Data Science, AI and Development — fully expecting to breeze through it.

I'd used Python before. In college. In personal projects. It was supposed to be the comfortable one.

Then **kwargs showed up.

A quick timeline

My previous post went up on May 2. After that, I finished IBM Course 3 on Prompt Engineering.

May 3 — started Course 4. Finished a major chunk of it the same day.

May 4 — wrapped it up.

Two days. But they didn't feel easy.

This one was different from the start

The earlier IBM courses — Intro to AI, Generative AI, Prompt Engineering — were concept-heavy. I could follow along, absorb ideas, take notes.

This one required me to actually do things.

You can't half-pay-attention your way through a coding module. The moment you try to rush it, you get stuck. And I got stuck more than I expected.

That gap — between passively understanding something and actively using it — is something nobody really warns you about. I felt it clearly here.

The moment it stopped feeling familiar

I was fine with *args. Used it before. Pass in multiple positional arguments, collect them as a tuple — fine.

Then **kwargs came up.

Collect keyword arguments as a dictionary. I'd never actually used this. I'd probably seen it in someone else's code and skimmed past it. The syntax looked familiar enough that my brain filed it under "things I know."

It was not.

def introduce(**kwargs):
    for key, value in kwargs.items():
        print(f"{key}: {value}")

introduce(name="Arun", role="Developer", learning="Python")
# name: Arun
# role: Developer
# learning: Python

Not a complicated concept. But I had to stop, reread it, try it, and actually think about when you'd want this over a regular dictionary parameter.

That pause told me something. There were gaps I hadn't accounted for.

What I actually relearned

Beyond **kwargs, the course pushed me back through things I thought I'd covered:

Variables, data types, control structures — the bones of Python
Functions, including documenting them with docstrings and how they connect to help() (genuinely didn't know this)

Parameter handling — *args for positional, **kwargs for keyword arguments as a dictionary

Exception handling — and this is where it got messy

The errors vs exceptions thing — I still haven't fully resolved this

I went in thinking I understood the difference. I came out less sure.
Technically, errors in Python — like SyntaxError — are things the interpreter catches before your code even runs. Exceptions — ValueError, TypeError, FileNotFoundError — happen at runtime while the code is executing.

But in practice? The line gets blurry. Developers use the terms interchangeably all the time.

And it's not a beginner problem. Research on mobile app development found that around 80% of exception bugs cause serious issues like crashes or unstable behavior. A separate study analyzing 16 open-source Java and C# projects found exception handling anti-patterns in every single one of them.

One of the most common mistakes — especially for newer developers — is using exceptions as regular control flow, when they're meant to signal genuinely abnormal conditions. The bare exceptblock in Python is a classic version of this — catching everything indiscriminately and silently hiding bugs in the process.

I got confused during the course. I still am, a little. Leaving it here honestly rather than pretending I have a clean answer — I think that's more useful.

Day 2 — finishing the course

The second day covered:

Working with files and different file formats
pandasand NumPy— first real structured exposure to these
Basics of web scraping
Working with APIs in Python

These felt like what the whole course was building toward. The day-one fundamentals started making sense in context.

The actual realization

There's a difference between familiarity and understanding.

I was familiar with Python. Familiar enough to feel comfortable. But familiarity isn't the same as knowing why something works, or when to use one approach over another, or what happens when you get it wrong.

Relearning made that distinction very clear.

Going back to something you already "know" and finding gaps is uncomfortable. It's also — once you get past the initial deflation — one of the more useful things you can do.

What I'm walking away with

Familiarity is not fluency. Assuming you know something is a good way to stop learning it.
**kwargs is small. The lesson behind it is not.
Exception handling needs more time. I'll come back to it.

Next up: projects. That's the only way any of this becomes real. I'll share it when I do.

Have you ever gone back to something you thought you knew and found gaps you didn't expect? Did you push through or start over?

Drop it in the comments — genuinely curious. 👇

I Am Starting Over in Public

Mohanragul — Fri, 01 May 2026 18:51:18 +0000

I have a computer science degree with a specialization in AI and Data Science. And I still didn't know what prompt engineering actually was.
Not really. Not until three weeks ago.

That's the honest starting point.

I graduated, looked at my skills, and realized that a lot of what the real world is talking about — GenAI, prompt design, modern full-stack tools — either wasn't covered in my coursework or just went past me without landing.
I could have waited until I felt ready. Instead, I decided to relearn it in public.

Who I am

Fresh engineering grad. Coimbatore-based. Interested in AI and full-stack development, and currently figuring out how to get better at both at the same time.

I'm not here to perform expertise I don't have. I'm here to build, document what I learn, and eventually land a job that lets me keep doing this.

What I'm relearning and building

Four things on my plate right now:

AI/ML fundamentals — from the ground up, not just theory
MERN stack — building real full-stack projects
React → Next.js — making the transition properly
JavaScript → TypeScript — because I keep seeing it everywhere and I need to stop avoiding it

These aren't goals I set to sound ambitious. They're the gaps I noticed when I looked at job listings and got honest with myself.

Where I am right now

Started with Elements of AI from University of Helsinki — low pressure, good foundation reset.

Then Generative AI for Beginners from Google.
Currently working through the IBM Applied AI Developer Professional Certificate. Three courses done:

Introduction to AI ✅
Generative AI – Introduction and Applications ✅
Generative AI – Prompt Engineering Basics ✅

Three more to go.

The prompt engineering course is where something actually clicked. I'd been using ChatGPT and Claude for a while and thought prompts were just — type what you need, maybe fix your grammar, get an answer.

Turns out prompts have types. Paradigms. Building blocks. There are tools built specifically to optimize them. I had seen "prompt engineering" mentioned a hundred times and never actually understood what it meant.

The fact that I specialized in AI in college and still missed this says a lot about the gap between academic curricula and where the field actually is.

What comes next

Projects. Real ones.

I'll share what I build, what breaks, what I figure out, and what I wish someone had told me earlier — not just polished final results, but the messy middle too.

I'll also share dev news and tools I come across that seem worth passing on. This won't only be about my own work.

The honest goal

I want to land a job in AI or full-stack development. Not hiding that.

But I also want to keep growing after I get there. Building in public is how I plan to stay accountable — not just during the job hunt, but after it.

If you're in a similar phase — relearning, rebuilding, or just starting out — I'd genuinely like to hear from you.

What's one thing you wish your college had actually taught you about working in tech?

Drop it in the comments. Let's compare notes. 👇