From YouTube Tutorials to Claude Code: How I Learned to Build Software, and How That Keeps Changing

I've been writing software for more than six years now, first in Nepal and now in Sydney. When I look back, the code I write hasn't changed as much as how I get to it. The place I go when I'm stuck has moved again and again: from a YouTube video, to a Stack Overflow answer, to a chat window, to an editor that edits itself, and now to an agent that runs in my terminal.

I want to write down that journey from a developer's point of view, because I think each step taught me something, and each step also took something away.

Stage 1: YouTube tutorials and "code along" videos

Like a lot of developers I know from Nepal, I learned much of my early C# and ASP.NET from YouTube. You found a playlist, opened Visual Studio next to it, and typed exactly what the person on the screen typed. Pause, type, rewind, type again.

It was slow, but it worked. YouTube was free, it was patient, and you could watch someone think through a problem in real time. For a beginner that matters a lot. You don't only learn the syntax, you learn the rhythm of building something: create the project, add the model, wire up the controller, run it, fix the error.

The downside was that tutorials only take you down the happy path. The moment your project did something the video didn't, you were on your own. And very often, the video was made for an older version of the framework, so half of the menus looked different.

Around the same time there were also books, blogs and the official Microsoft docs. I still think the docs are underrated. But for a long time my real learning loop was: watch a video, get stuck, Google the error.

Stage 2: Stack Overflow and the art of Googling the error

Googling the error almost always ended on Stack Overflow. For years it was the most important website in my working day.

Stack Overflow taught me a skill that I think is still valuable: reading other people's problems and recognising your own in them. The question was never exactly yours. You had to read three answers, understand why the accepted one worked, notice that the second one was better for your version, and then adapt it to your code.

It also taught me humility. If you ever asked a question there, you learned very quickly to include your code, your error, what you tried, and what you expected. That habit of writing a clear problem statement turned out to be the most useful skill for everything that came next, including prompting AI.

The weakness was speed and fit. Answers were often old, for a different version, or for a slightly different problem. Sometimes the right answer was buried under a 2014 answer with 900 upvotes. You spent a lot of time searching and filtering before you could start fixing.

Stage 3: GitHub Copilot, the first time the editor guessed my next line

The first time GitHub Copilot finished a whole method for me, it felt like a magic trick. I typed a method name and a comment, and it suggested the body. Sometimes it was wrong, often it was almost right, and occasionally it was better than what I would have written.

Copilot was the first AI tool that lived inside my editor instead of in a browser tab. That was a bigger change than it sounds. I didn't have to leave my code to ask for help, and the help already knew the file I was in.

But early Copilot was autocomplete. It was great at the next ten lines and had no idea about the bigger picture: the architecture, the other projects in the solution, or why we did something in a certain way.

Stage 4: ChatGPT, a senior developer who never gets tired of questions

Then ChatGPT arrived, and for me Stack Overflow slowly stopped being the first tab I opened.

Instead of searching for someone else's question, I could ask my question, with my code, and ask follow-ups. "Why does this deadlock?" "What's the difference between IQueryable and IEnumerable here?" "Explain this like I'm new to EF Core." It felt like having a patient senior developer next to me at 2am.

It changed how I learn new things too. When I picked up something unfamiliar, I'd ask for an explanation, then a small example, then ask it to quiz me. For interview preparation, this was huge.

The problems were also obvious, though:

• It could be confidently wrong, with APIs that didn't exist or methods from another library.
• There was a lot of copy and paste. Copy the code into the chat, copy the answer back, fix the compile errors, repeat.
• It only knew what I pasted. It didn't see the rest of my solution, my configuration, or my tests.

That last point is what the next generation of tools set out to fix.

Stage 5: Cursor, when the editor itself became the chat

Cursor was the first time I felt the chat and the code were really in the same place. It is an editor built around AI, so I could select code, ask for a change, and see a proper diff across several files that I could accept or reject.

The big shift was context. It could look at my whole project, follow references, and make a change in the controller, the service and the test at the same time. I stopped copying code into a browser. I started describing what I wanted and reviewing what it did.

That is also when I noticed my job changing. I was typing less and reading and reviewing a lot more. My own MCP server for interview questions and this blog's tooling were both built with a lot of help from AI editors, and the hardest part was never generating code. It was knowing whether the generated code was right.

Stage 6: Claude Code, an agent that works in my terminal

The latest step for me is Claude Code. It runs in the terminal, reads the repository, runs the build and the tests, and works through a task step by step: read the code, make a plan, change files, run the tests, fix what failed, and repeat.

The way I use it now looks a lot like working with a junior teammate:

1. I write a clear task, with the context and the definition of done.
2. It explores the code and proposes a plan.
3. It makes the change, runs dotnet build and dotnet test, and fixes its own errors.
4. I review the diff carefully before anything is merged.

A good example: I recently asked Claude to test all the blog tools on my MCP server in UAT and write a bug report. I then gave that report to Claude Code to fix the issues, and asked Claude to re-test the fixes. A tester, a developer and a reviewer, with me in the middle making the decisions. A few years ago that would have been a few days of my own time.

I also keep a small instructions file in the repository so the agent knows how the project works:

# Project notes for the agent
- .NET 9, ASP.NET Core, EF Core with SQL Server
- Run: dotnet build && dotnet test before saying a task is done
- Never change migrations that are already applied
- Follow the existing folder structure: Features/<Name>/

Writing that file felt a lot like writing a good Stack Overflow question. Clear context in, better answer out.

What each stage taught me

What hasn't changed

After all of these tools, a few things are exactly the same as when I was rewinding YouTube videos:

• You still have to understand the code. If you can't explain a change, you shouldn't merge it, whether it came from a tutorial, Stack Overflow or an agent.
• A clear problem statement is the most valuable skill. Good Stack Overflow questions, good prompts and good agent tasks are the same thing.
• Fundamentals matter more, not less. Knowing how HTTP, databases, async code and security really work is what lets you catch the mistakes AI makes.
• Testing is your safety net. The faster code is written, the more you need tests to trust it.

What I'd tell a new developer today

If you're starting out now, it's tempting to skip straight to the agent and let it build everything. I'd suggest a balance:

1. Build a few small things by hand first, even if it's slower. Struggle a bit. That's where understanding comes from.
2. Use AI as a teacher before you use it as a typist. Ask it why, not just what.
3. Read the code the AI writes as if a stranger submitted it as a pull request.
4. Learn to write clear tasks: context, constraints, and what "done" means.

Final thoughts

When I started, the best help I could get was a video recorded years earlier by someone I would never meet. Today I can hand a task to an agent that reads my code, runs my tests and comes back with a working change. That's an incredible shift in just a few years.

But every tool on this journey has been a different answer to the same question: "I'm stuck, where do I get help?" The developers who do well, I think, are the ones who keep getting better at asking that question clearly, and at judging the answer.

I'm curious how your own path looked. Did you start with YouTube too, or with books, a bootcamp or university? And which tool are you using most right now? Let me know in the comments.