Simple AI habits you need to unlock effortless learning

Hello, Go. Where are my exceptions?

So, we write most of the services at work in Go, not some, but most of them. At least in my team.

In short, this means learning Go is not a nice weekend project for me, but a “you will be reviewing my PR on Monday” kind of situation.

After years in C#, .NET and OOP, a lot of things feels painfully wrong to me. However, two of them turned out to be exceptionally difficult to process for my map-world-to-objects brain. Firstly, errors are just values, no try/catch, no exceptions politely bubbling up to some middleware that deals with them. Secondly – no classes, no inheritance, no base class with X-teen virtual methods that every single developer is afraid to touch.

My OOP brain was (still is) not amused.

So I did what every responsible and self-respectable developer would’ve done in my position in 2026 – opened an ✨ AI chat ✨. And then I spent a few weeks figuring out how to use it, so that it actually elevates the speed of my learning, instead of only making me feel like I learn faster. Those are two very different things.

AI doesn’t learn for me

Let’s do this our #noHypeAI style.

AI didn’t learn anything FOR me, I didn’t become a Go expert in a weekend (or at all actually – I still have a long long way ahead of me). Moreover, nobody can do that this way – whatever LinkedIn gurus says.

What it did, however, is cutting the most annoying part of learning anything new. The “I don’t even know where to start” and “I don’t even know what to google” phase. The one when you feel like crying in front of the opened docs and every page already assumes you know the other pages.

AI became my tutor who never gets tired of your questions (unless you fill in the context, then you have to pick up a new one). Even the stupid ones. Or rather – especially the stupid ones. At the same time it is a tutor who will be more than happy to teach you C# written in Go syntax, if you let it.

The trap: translating instead of learning

Probably one of the most tempting prompt for a .NETter learning Go would be something like:

Convert this C# to Go.

And it will work! Kinda. You will get a code that compiles. You will feel productive, You will also learn exactly nothing, and your code will look like C# init’s Halloween costume. For example: base “classes” rebuilt out of embedded structs, interfaces declared up front for everything, just in case, or sometimes even panic used like throw.

This is more-or-less what a .NET developer would’ve written

public User GetUser(int id)
{
    var user = _repo.Find(id);
    if (user is null)
        throw new NotFoundException($"user {id} not found");
    return user;
}

And this is how the same thing looks like in a Go-ers head

func (s *Service) GetUser(id int) (*User, error) {
    user, err := s.repo.Find(id)
    if err != nil {
        return nil, fmt.Errorf("get user %d: %w", id, err)
    }
    return user, nil
}

It’s not the syntax that’s important. It’s the idea, the way of thinking. Errors being part of the function’s contract, right there in the signature. Dealing with it right away.

A translation won’t teach you that idea. You have to be the one asking for it

My learning loop

After only a few days I found my routine. It turned out to be 5, simple steps. Nothing fancy. It’ll work for anything, not only my Go-journey, and I say it from experience. Similar process helped me elevate my Norwegian.

1. Map. Start from what you already know and ask what’s the same, what’s different and what doesn’t exist at all.
2. Ask why. For every difference, ask why is it done like this.
3. Write it myself (usually, not always). Me typing, not AI. Ugly is ok. Uncomfortable is ok.
   1. If you are in fully automated AI flows, you are the reviewer, you ask questions, but that path is much more difficult.
4. Get reviewed. Ask AI to review your code like a strict reviewer would.
5. Explain it back. Explain what you think you’ve learned and let it find holes.
6. Loop back to point 1

Boring? Yes. Works? Like a charm.

Practical tips

So some of the steps from the loop above come with more details, tricks, and you don’t need a paid subscription plan to learn them.

Ask for map, not a tutorial

Tutorials usually start from zero. If you are only just starting your coding journey, that’s a great path for you. However, if you are only switching between technologies/languages (bot programming and human ones) you are not at the ground level anymore. Tell the AI who you are and ask it to build on that.

I’m a senior C#/.NET developer. Map the C# concepts I use every day to their Go equivalents. Flag the ones that have no equivalent at all.

The “no equivalent” list is your gold. For me it was things like: exceptions, inheritance, LINQ and attributes, not to mention classes and inheritance. That list is your learning path.

Ask “what will feel wrong to me?”

I’m a bit afraid to write it, but syntax is easy. Mindset is hard. So ask for the necessary shift in mindset.

What will feel wrong to a C# developer in Go, and why does Go do it that way?

You get errors as values, composition over inheritance, interfaces nobody declares, zero values instead of null checks. Knowing what’s coming makes it much less annoying when it arrives.

Converting is banned

Even if you decide at any point to rewrite Go -> .NET (or the other way around), it’s never just a “convert”. Instead:

How would an experienced Go developer solve this problem? Don’t translate my code.

Then write your own version anyway, and ask the AI to review it against Effective Go. Your wrong guesses are exactly the bits that stick.

Always ask “why”

“The 5 whys” is one of my favorite techniques to get to the bottom of something. Why does Go return (value, error)? Why are interfaces defined where they’re used, not where they’re implemented?

A rule you memorise is gone in a week. A reason you understand turns into a decision you can make yourself.

Make AI quiz you!

After the end of session/task/feature whatever:

Give me 5 questions about what we covered today. One at a time. Don’t show the answer until I reply.

Rereading feels like learning. Answering questions actually is. And AI is the most patient quiz master you will ever meet.

Explain it back

Explain goroutines or context.Context in your own words and ask the AI to find the gaps. This is the fastest way I know to find out that I only thought I understood something. Humbling. Useful.

Learn on real work, in small slices

Toy projects are fine, but real work sticks better. Pick something tiny from your actual job: a small CLI tool, one endpoint, one test. Then ask the AI to split it into steps where each step teaches exactly one new concept.

Keep a learning log

Keep a small markdown file of “things that surprised me”. Paste it into new chats so the AI knows where your gaps are and stops explaining what you already know. Bonus: it’s a great source for blog posts. Ask me how I know.

How I keep AI honest

Confession: AI hasn’t given me a single wrong Go answer so far. Partly luck, partly because Go’s basics are stable and very well documented (or I just still know too little to detect it).

But “so far” is doing a lot of work in that sentence. If you’ve read my posts on AI hallucinations, you know a confident answer and a correct answer are not the same thing. So a few habits stay on:

• Check which Go version the answer assumes. Go changes too. Generics arrived in 1.18, net/http routing got much smarter in 1.22, and 1.22 also fixed the classic loop variable gotcha. Older answers still carry workarounds you no longer need.
• Compare with the official docs. go.dev, Effective Go and the standard library docs are short and readable. Use them as the referee.
• Let the compiler have the last word. Run it. Run go vet. Run the tests. The compiler has no opinions, only facts.

What it is all about

AI won’t learn a new language for you. It won’t learn anything for you, actually.

On top of that the very uncomfortable question can arise: do we even need this knowledge anymore? If AI can/will write most of the code, why learn to write it by hand? To be frank, I’m asking myself the same thing. My answer for now: someone still has to review that code, debug it at 2 a.m. and notice when it’s C# in a Go costume. That someone is me. But ask me again in a year.

What it does really well is shorten the road from “I have no idea” to “I know what to ask”. After that, the understanding still has to happen in your own head. Slowly, with your own typos.

Use it as a tutor, not a translator. Ask for maps, reasons, reviews and quizzes. Write the code yourself. Check the docs. Trust the compiler.

And if your OOP brain still screams every time it sees if err != nil… same. That’s exactly what part 2 is about: what feels wrong in Go after years of C#, and how AI helped me make peace with it. Follow on LinkedIn so you don’t miss it.

What are you learning with AI right now? Drop it in the comments, along with your favourite learning prompt. I’m collecting them. Wink, wink.

Fair note: AI helped me with some grammar, but only some. You will be probably able to see it pretty clearly.
Bonus tip: replace all .NET -> Go references with whatever you want (English -> Norwegian, guitar -> ukulele theory, Arm -> Teraform, Docker -> K8s) sky is the limit. But also physical feedback is a limit. AI still probably won’t be able to heaar you mastering your ukulele, or will it…