I built a 3D Tic Tac Toe game in React and deployed it.

Not because I needed it. Just because I had just set up a terminal-based AI coding tool and I wanted to see what it would actually do. That small detour — typing a prompt, watching it scaffold something real, deploying it within the same session — is what convinced me to use it for something I actually cared about.

Why I Needed a Portfolio Right Then

I had just moved back home after living in a hostel. Fresh engineering grad, no job yet, trying to get visible in the developer community. I needed a portfolio. I could have built it the usual way — picking a template, writing everything manually, spending days on layout decisions. Instead, I decided to try building it entirely through OpenCode and see what that experience was actually like.

What OpenCode Is (For Anyone Who Has Not Heard of It)

OpenCode is an agentic ai coding tool that runs in your terminal. You describe what you want to build, it writes the code, you review and iterate. There is a desktop version too, but I used the terminal interface — which sounds intimidating if you have not used it before, but is genuinely just a conversation that produces code. It supports multiple models, and you can swap between them depending on what you are working on.

What Working With It Actually Felt Like

I built the entire portfolio on free-tier models. Mainly Minimax V3 and DeepSeek V3 Flash — switching between them depending on the task.

That switching is where things got interesting.

No single model was perfect for everything. DeepSeek V3 Flash was faster for generating structure and layout — when I needed a section scaffolded quickly, it moved. Minimax V3 handled longer, more detail-heavy prompts better when I needed something more considered, like writing out the skills section or getting the project cards to look right.

The honest version of this is: I was not following a plan. I was figuring out which model behaved better for which kind of prompt as I went. That is not a flaw in the tool — it is just what using free-tier AI actually looks like. You learn the shape of each model through use.

Where I Still Had to Think

The code was not the hard part. The decisions were.

OpenCode could generate a hero section. It could not tell me what to say in it. It could scaffold a projects section. It could not decide which projects were worth showing, or how to describe them in a way that would land with a recruiter reading for thirty seconds.

Every time I hit a content decision — what to include, how to frame my experience as a fresh grad with no full-time work history, which projects to lead with — I had to stop and think it through myself. The tool was waiting. The thinking was mine.

That is a useful thing to understand before you start: AI-assisted development with a tool like OpenCode accelerates the build. It does not replace the judgment calls about what you are building and why.

What the Portfolio Ended Up Looking Like

The final version has a hero section, an about section, a skills overview, a projects section showing the things I have actually built, and contact links.

As a fresh grad, I made one deliberate choice: lead with projects over credentials. I do not have years of experience to list. But I have things I have shipped — including the AI Resume Tailor I built and deployed recently. That is what the portfolio shows.

You can see it here: mohan-portfolio-v1-0.vercel.app

The One Thing I Would Tell Another Fresh Grad Before They Try This

OpenCode will move faster than you expect. The part that slows you down will not be the tool — it will be the moments where you have to decide what kind of developer you want to appear to be. No model can answer that for you.

Figure out what you want to say. Then let the tool help you say it faster.

If you have used OpenCode or any other terminal-based AI coding tool, I am curious — did you stick with one model or end up switching around like I did? Drop it in the comments.

I spent an entire day just trying to understand what I was about to build. Not watching tutorials. Not following along with someone else's repo. Just sitting with the concepts, asking questions, mapping out how the pieces connected. That decision is the reason this post exists — because if I had jumped straight to coding, I would have built something without understanding it. And I would have had nothing real to say about it afterward.

What the Project Actually Is

The idea is simple once you see it: instead of one AI doing everything, you break the work into roles.

My project — Multi-Agent Orchestration Sim — runs a three-agent pipeline. A Researcher agent gathers and processes information on a given topic. A Writer agent takes that output and turns it into structured content. An Editor agent reviews the draft and refines it. Each agent has one job. The output of one becomes the input of the next. That handoff chain is what makes it "multi-agent."

If you have used an assembly line as a mental model for anything, this clicks immediately.

The Day I Did Not Touch the Code

May 28 was a research day.

I went through the LangChain and LangGraph documentation, read about how state is passed between agents, and sat with questions I could not immediately answer: How do agents hand off context without losing information? What does LangGraph's state graph actually manage under the hood? Where does Groq fit into this — is it just the model provider, or does it change how I structure things?

Most of those questions did not have clean answers until I started building. But asking them first meant I was not reading error messages cold — I had enough mental context to understand what was breaking and why.

That phase is what separates a build you understand from one you just completed.

The Actual Build

The stack: LangChain for agent logic, LangGraph for orchestrating the pipeline and managing state across agents, Groq as the LLM provider for fast inference. FastAPI backend, NextJS and TypeScript frontend.

I structured the graph with each agent as a node and defined the edges — the handoff points — explicitly. LangGraph's StateGraph manages what gets passed forward at each step, which meant I did not have to wire the agents together manually. I defined the state schema, connected the nodes, and let the graph handle execution order.

It is not a complex architecture. But it is a real one. And building it meant making actual decisions, not just following a predefined template.

The Two Things That Broke

First: deprecated syntax.

I had learned LangChain from an older course. When I started building, a significant portion of the syntax I was relying on had been deprecated. Methods had been renamed, import paths had changed, some patterns had been replaced entirely. I spent time I had not planned for just searching for what the current replacements were — cross-referencing the docs, checking changelogs, testing whether the updated syntax behaved the same way.

It is a small thing in retrospect. But when you are a beginner and the code from your course stops working, it feels like the floor has moved.

Second: a CORS error from a trailing slash.

After deployment, API requests from the frontend were not reaching the backend. I opened the browser console and saw a CORS error — origin not allowed.

I already knew what CORS was, so I knew where to look. When I checked the backend configuration, I found it immediately: I had added the frontend production URL to the allowed origins list, but I had accidentally included a trailing slash at the end of the URL.

https://myapp.vercel.app/ instead of https://myapp.vercel.app

That single character blocked every request. Removed the slash, redeployed, everything worked. Ten seconds to fix, forty minutes to find.

Shipping It

The repo is live and the project is deployed. That matters more than it sounds.

Not because of what it does — it is a beginner project. But because it exists outside my machine, it has a URL, and someone else can look at the code. That is a different category of thing than a project that lives in a local folder.

→ GitHub repo

What Building Taught Me That Tutorials Never Did

Watching someone build a multi-agent system teaches you the steps. Building one teaches you something different.

You learn what the abstractions are actually hiding. LangGraph's state management felt clean in tutorials. When I had to define my own state schema and debug why context was not passing correctly, I understood what the library was doing — not just that it worked.

You learn that documentation has a version. Nothing in a course tells you that the method you just learned might be deprecated. Building forces you to read the actual docs, check the version, and understand that libraries change.

You learn that most errors are boring. The CORS error that blocked deployment was not a deep architectural failure. It was a slash. The deprecated syntax errors were not gaps in my understanding — they were just outdated. Beginners fear errors because they think they signal a fundamental misunderstanding. Usually they do not.

You learn that finishing is a skill. The gap between "I understand this concept" and "I have shipped this project" is real and it takes practice to close. Every project you finish makes the next one easier to start.

If you are stuck in tutorial loops right now — what is actually stopping you from just shipping something small?

The stack does not have to be impressive. The project does not have to be original. It just has to be finished.

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. Momentum gone. I did not spiral about it. I just watched it happen and let the day end.

That is the honest starting point for this week.

May 18 — Doing a Little When You Do Not Feel Like It

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

I worked on some communication materials, restarted FastAI, and got back into the course. Not a highly productive day by any measure. But motion is motion. The point of May 18 was not output — it was direction.

May 19 — The Workflow Started Making Sense

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

Most of the code was course-guided, but something clicked about the training and prediction workflow: you feed labeled images in, a model trains on them, and then you pass a new image through — it returns a label and a confidence score. That loop — train, predict, evaluate — is the foundation for everything else in this course. Seeing it run on something as simple as cats and dogs made it concrete in a way that reading about it had not.

May 20 — The Bear Classifier

Module 3 done. Bear classifier built.

The model classifies images into three categories: black bear, grizzly bear, or teddy bear. It works. Watching it correctly label a grizzly I fed it was one of those small moments that feels disproportionately satisfying — you know it is a beginner project, but it is your beginner project and it ran.

One thing worth mentioning for anyone following the same course: the FastAI content is a few years old at this point, and the image collection section uses Bing Search API with a free tier that no longer exists without entering card details. I ran into that wall early. The fix was switching to DuckDuckGo image search via Python — fully free, works the same way for the purpose of pulling training images. Small detour, but worth knowing before you hit it.

Also started thinking more seriously about career direction today — researching job hunting resources, posting in dev communities, beginning to think about what comes after the learning phase.

What Four Days Actually Taught Me

May 17 did not erase May 19 and May 20. That sounds obvious, but it is easy to treat one bad day like it resets your streak to zero.

The more useful thing I took from this week: small practical projects move understanding forward faster than rushing through theory. The dog-vs-cat classifier and the bear classifier are both simple. Neither of them required deep knowledge. But building them made concepts stick in a way that reading had not managed.

Consistency is not about perfect productivity. It is about what you do after the wasted day — whether you quietly get back in motion or let one day become three.

May 18 was not impressive. It was just necessary.

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

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 could not explain what it was doing — and that felt worse than having nothing at all.

May 13 — The Build and the Discard

The project was an AI API Cost Optimizer. The idea was solid: monitor usage across multiple LLMs, route requests based on cost, handle circuit breakers and fallback logic when one model fails. Useful, technical, the kind of thing that looks impressive in a portfolio.

I used Cursor. It generated the structure fast — faster than I expected.

Then I sat down to review what had been built.

I could read the code. I could not explain it. There is a difference. If someone had asked me why a specific routing decision was made, or how the fallback chain was structured, or what would happen if two circuit breakers triggered at once — I would have guessed. And I would not have known whether I was right.

That moment — sitting with a working project I did not understand — is the one I keep coming back to.

I made the call to discard it entirely. Not to fix it, not to read through it slowly and hope comprehension would come. Delete and start over. It felt more honest than shipping something I could not own.

May 14 — The Day I Could Not Recover

Laptop issues. A long trip to the service center. Hours of waiting and logistics that drained whatever focus I had left.

I knew the day was gone by mid-afternoon. I could not get back into the right headspace to do anything meaningful, so I did not force it. Some days are just the cost of having a life outside of building.

May 15 — The Rebuild

I started over with Claude. But the tool was not really the point.

What changed was how I worked.

On May 13, I had described the full project and let Cursor generate most of it in one pass. On May 15, I built one small piece at a time. I got the basic API connection working and understood it before touching the next part. Then the routing logic — built it, read it, asked questions about it, moved on. Then the fallback handling. Each piece had to make sense to me before I added the next one.

It was slower. The project grew in a way I could follow.

By the end of the day, the MVP was rebuilt and deployed. Same project, same concept — but this time I could explain every decision in it. That is the difference between a project you built and a project that was built for you.

May 16 — The RAG Knowledge Assistant

The next project was simpler in concept: a RAG Knowledge Assistant that answers questions from uploaded files. Upload a document, ask questions, get answers grounded in that document's content.

The development part went smoothly. Deployment did not.

Free-tier hosting limitations. Unexpected constraints. Hours of debugging infrastructure that had nothing to do with the AI logic itself. The kind of problems that do not show up in tutorials because they assume everything just works.

It still shipped (Frontend only). But the real lesson from that day was not about RAG pipelines — it was about deployment. Getting something running locally is one thing. Getting it running somewhere else, under real constraints, with free-tier limits fighting you the whole way, is a completely different skill. That part is just as important to learn as the AI logic, and it gets skipped over constantly.

The Realization

AI can move fast. That speed is real and genuinely useful.

But speed without understanding creates a different kind of problem — you end up with things you cannot maintain, cannot debug, and cannot honestly call your own work. The impressive-looking project that you cannot explain in an interview is not an asset.

What I am changing: I am not generating whole projects anymore. I am building in pieces, staying at the edge of what I understand, and using AI to help me move that edge forward — not to jump past it entirely.

The goal is not to ship fast. The goal is to understand what I am shipping.

Where Things Stand

Two more projects deployed in the last few days. The fast.ai course running alongside. The workflow is still being figured out, but it is moving in a direction that feels more solid than it did a week ago.

If you have ever accepted generated code you did not fully understand just to keep moving — what made you stop and question it, or did you ship it anyway?

Detailed prompts. System design notes. Tech stack decisions. Workflow documents. A content strategy. I had spent days preparing so that when I finally sat down to build, nothing would slow me down.

Then I started building. And almost all of it fell apart.

May 10 — The Day the Plan Fell Apart

I opened my notes with genuine excitement. Everything was documented. This was supposed to be the easy part.

The prompts I had crafted did not produce what I expected. Outputs were inconsistent. Quality kept dropping below what I needed. I spent hours refining them — restructuring, rewording, testing again, getting slightly better results, then slightly worse ones.

At some point in the middle of that loop, I hit a wall.

I realized I was not building. I was still preparing — just in a different form. The planning had shape-shifted into prompt obsession, and I had not noticed the switch.

That is when I made the only decision that actually moved things forward: stop chasing the perfect setup and focus on creating a workable foundation instead.

It sounds obvious when you write it down. It did not feel obvious at hour four of testing prompts that were close but never quite right. The shift was not dramatic. I just stopped optimizing for ideal and started building for functional. That change in how I was thinking about the day is what made May 11 possible.

May 11 — The Day It Actually Worked

I started the morning differently. Instead of jumping straight into building, I used AI as a thinking partner — asking questions, stress-testing my understanding of the concepts, filling gaps I had not noticed during prep. Not generating outputs. Just understanding the problem properly.

Once I felt grounded in what I was actually building, I started coding.

By the end of the day, I had built and deployed AI Resume Tailor — an AI-powered web app that analyzes a user's resume against a job description and returns a match score along with an AI-tailored version of the resume. Flask backend, React frontend, Gemini Flash API handling the intelligent text processing.

It is live: Live App

What that day confirmed for me: learning accelerates when combined with real implementation. The prep I had done for days started clicking into place only once I was building with it. Theory alone did not do that. The combination did.

There was one bottleneck. I hit the AI usage limit partway through the day. It forced a pause I did not want, but it also forced me to think about something I had been ignoring — my workflow is not organized for limits. I rely heavily on AI-assisted momentum, and when that cuts off, I do not always have a clean fallback. Something to fix.

May 12 — The Day That Fought Back

I accidentally deleted an important AI conversation.

It had concept explanations I had been building on for Project 1 — the kind of working context that is annoying to reconstruct because you cannot remember exactly what you asked or how the explanation landed the first time.

I sat with that frustration for a moment. Then I redid it.

Not gracefully. Not without muttering about it. But I redid it, moved on, and kept working through the concepts I needed for the next project despite a day full of small interruptions that kept breaking my focus.

That night, I started fast.ai's Deep Learning for Coders and finished Lesson 1.

It was a small move. But it was a deliberate one — I was behind where I wanted to be and I made a choice to keep the forward motion going even when the day had been mostly friction.

The Pattern I Noticed

Three days is not a lot of data. But it was enough to see something clearly.

I move fast. I rely heavily on structured AI workflows. I sometimes overprepare — building elaborate systems before I have tested whether the foundation is solid. And I occasionally lose momentum to overthinking or poor organization, like not having a backup for important AI conversations, or not accounting for usage limits in my daily workflow.

I am not writing this as a resolved problem. I have not fixed any of it yet.

But I have noticed it. And there is something useful in noticing a pattern before you can name a solution — it means the next time it happens, you will recognize it faster.

Despite wasted time, mistakes, and imperfect days, I still continued building, learning, and moving forward. That is the only part I am confident about right now.

What Is Live

AI Resume Tailor is deployed and working.

→ GitHub repo → Live app → Backend on Render

Three messy days still shipped something real. Preparation alone does not guarantee progress — but apparently, neither does its absence.

What Comes Next

The next project is already in progress. The fast.ai course is running alongside it. The workflow is imperfect, the usage limits are still a problem, and the tendency to overprepare has not disappeared — but things are moving.

Have you ever prepared so thoroughly for something that the preparation itself became the obstacle?

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 am still not sure how that happened. But I want to write it down before the feeling fades.

Where this fits in the journey

I am 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 is not a course review. It is an account of what building actually felt like.

Course 5 — Flask and backend development

I went in thinking the backend would be manageable.

I had 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 did not account for was that after first year, I completely stopped touching backend. My focus drifted entirely to frontend. For two years I wrote UI, helped friends debug their projects occasionally, and let everything else fade. By third year, even that stopped.

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

What surprised me more was unit testing.

I had seen it mentioned in Job roles, Internet and even in Course Works. I had always skipped past it mentally — something I filed under "I will 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 is not extra work but part of writing real software.

Here is the part I am still thinking about: during campus placements in my final year, the first company that came to our college selected me through a hackathon round and called me for a final interview. They asked if I was comfortable with a testing role.

I said I did not know much about testing and would prefer frontend, web development, or AI.

I did not get the offer.

I am not saying that was definitely why. But 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.

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 something clearly: in my experience, it was not BlenderBot. It was BlunderBot.

It did not answer questions the way I expected. The responses were off — sometimes irrelevant, sometimes just strange. I spent time trying to figure out if I had built it wrong before I realized the model itself was the issue. Using a better model would have changed the experience completely.

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 was not accessible from my setup. So I found my own path.

I used Whisper for speech-to-text and Piper for text-to-speech. What I did not know going in: Piper requires downloading an ONNX model file separately. I did not know that. The app broke. I searched, figured it out, downloaded the file.

Then I found out Japanese voice models were not available in the configuration I was using. Then the audio format Piper produced was not compatible with the frontend.

Each of those was a small wall. I went over each one. The final app worked. It was not 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 has moved to langchain_classic. The course materials had not been updated.

The application simply would not run. No obvious error message pointing at the real cause. I eventually found it — either downgrade the package version or update every import.

I updated the imports. This is the kind of thing that does not come up in passive learning — you encounter it only when you are 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 the earlier courses had only described.

The honest part — and the most important paragraph in this post

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

But here is what I will say clearly: 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 does not teach you what happens when they break. Understanding RAG conceptually does not show you what building the pipeline actually feels like. You find out what you do not know only when the code does not 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 plan and 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 is next

Phase one is done. The foundation is there.

Phase two is building without a guide. That is where I will find out what actually stuck.

I will write about it when I do — including the parts that do not work.

If you have 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 am genuinely trying to figure out where that line is.

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

Then **kwargs showed up.

A quick timeline before I get into it

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

On May 3, I started Course 4 — the Python one. Finished a major portion of it the same day.

May 4, I wrapped it up.

Two days. But they did not feel easy.

This one was different from the start

The earlier IBM courses — Introduction to AI, Generative AI, Prompt Engineering — were heavy on concepts. I could follow along, absorb the ideas, take notes.

This one required me to actually do things.

You cannot 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 to.

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. I had 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 had never actually used this. I had 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="John", role="Developer", learning="Python")
# name: John
# role: Developer
# learning: Python

It is not a complicated concept. But I had to stop, reread it, try it, and actually think about when you would want this over a regular dictionary parameter.

That pause told me something. There were gaps I had not accounted for.

What I actually relearned

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

• Variables, data types, control structures — the bones of Python

• Functions, including how to document them properly using docstrings and how they connect to the help() function (genuinely did not know this was a thing)

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

• Exception handling — and this is where it got messy

The errors vs exceptions thing — I still have not fully resolved this

I went in thinking I understood the difference. I came out less sure.

Technically, errors in Python are things like SyntaxError — problems the interpreter catches before your code even runs. Exceptions are runtime issues — ValueError, TypeError, FileNotFoundError — things that happen while the code is executing.

But in practice? The line gets blurry. Developers use the terms interchangeably all the time, and even experienced ones do not always handle exceptions properly.

Research on mobile app development found that around 80% of exception bugs cause serious problems like crashes or unstable behavior. That is not a beginner problem — that is an industry-wide one. [arxiv]

A study analyzing 16 open-source Java and C# projects found exception handling anti-patterns in every single one of them. Every. Single. One. [arxiv]

And it is not just academic research flagging this. Developers on platforms like [Dev.to] have written about how one of the most common mistakes — especially among newer developers — is using exceptions as a mechanism for regular control flow, when exceptions are meant to signal genuinely abnormal conditions. [DEV Community]

The bare except block in Python is one version of this — catching everything indiscriminately, including errors you never intended to handle, and silently hiding bugs in the process.

I got confused during the course. I still am, a little. I am leaving it here honestly rather than pretending I have a clean answer, because I think that is more useful.

May 4 — finishing the course

The second day covered:

• Working with files and different file formats

• pandas and NumPy — first real exposure to these in a structured way

• Basics of web scraping

• Working with APIs in Python

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

The actual realization

There is a difference between familiarity and understanding.

I was familiar with Python. I had used it enough to feel comfortable. But familiarity is not 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 is also — once you get past the initial deflation — one of the more useful things you can do.

What I am walking away with

Familiarity is not the same as fluency. Assuming you know something is a good way to stop learning it.

**kwargs is small. The lesson behind it is not.

Exception handling is something I need to sit with longer. I will come back to it.

What I will try next

Projects. That is the only way any of this becomes real.

The courses gave me the foundation. Now I need to build something with it — break things, debug things, and find out what I actually retained versus what I just read.

I will share it when I do.

Have you ever gone back to something you thought you knew and found gaps you did not expect? How did you handle that feeling — push through, or start over?

Drop it in the comments. Genuinely curious.

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 went past me without landing.

I could have waited until I felt ready to talk about any of this.

Instead, I decided to relearn it in public.

Who I am

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

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

What I am relearning and building

Four things are 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 want to stop avoiding it

These are not goals I set to sound ambitious. They are the gaps I noticed when I looked at job listings and honest with myself.

Where I am in the learning path

I started with Elements of AI from the University of Helsinki — a good, low-pressure way to rebuild the foundation.

Then Generative AI for Beginners from Google.

Right now I am 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 for me. I have been using ChatGPT and Claude for a while. I thought prompts were just — type what you need, maybe fix your grammar, get an answer. That was it.

Turns out prompts have types. Paradigms. Building blocks. There are tools built specifically to optimize them. There is an entire process called prompt engineering that I had seen mentioned a hundred times but never actually understood.

The fact that I specialized in AI in college and still missed this tells me everything about the gap between academic curricula and where the field actually is.

The Intro to AI course also introduced me to responsible AI — why it matters now and why it will matter more as these systems get bigger. That one I want to come back to in a future post.

What comes next

Projects.

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

I will also share dev news, tools, and things 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. I am not hiding that.

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

If you are somewhere in a similar phase — relearning, rebuilding, or just starting — I would genuinely like to know.

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

Drop it in the comments. I am curious.

#beginners #ai #webdev #career