Here’s the thing about starting a new job - even when you’re experienced in the stack, you’re going to feel like a complete beginner again. And honestly? It’s humbling.

I recently started a new role, and despite having years of Elixir under my belt, I’ve been staring at codebases full of libraries I’ve never touched: Knigge for behaviour-based dependency injection, Nebulex for distributed caching, TypedStruct and Domo for struct definitions with compile-time guarantees. Oh, and Redis - a tool I’d somehow managed to avoid for my entire career until now. And macros. Macros everywhere.

It’s that familiar feeling of imposter syndrome creeping back in, whispering "maybe you don’t actually know Elixir that well after all."

The Temptation of Just Letting AI Do It

Now, the obvious solution these days is to just let Claude Code or Cursor do the heavy lifting. And look - these tools are genuinely incredible. You can throw a problem at them, and they’ll spit out working code that passes your tests and looks reasonable. Many developers have adopted LLM-first workflows, and while you’ll likely be productive, I’ve realised (at least for me): you don’t actually learn anything this way.

You get somewhere - which is good - but you don’t truly understand the underlying concepts and principles. You’re just reviewing output and agreeing it’s likely quite good. It’s like copying someone’s homework and calling it studying. Sure, you’ve got the answers, but good luck when the exam comes around and you need to solve a similar problem from scratch.

No bueno.

I found myself in this pattern a few weeks in - I’ll ask Cursor to help me with a ticket, then half way through realise that I wouldn’t have done it this way and I haven’t actually learnt anything from it - so I scrapped Cursor’s output and started from scratch with a new approach that’s proven to be far more effective.

The Solution: Teaching Mode

So I built something stupidly simple that’s been an absolute game-changer: a /teach command in Claude Code.

The entire prompt is this:

I want to learn how to do the thing that I'm asking of you - I want you to guide me into doing it but don't do it for me so I can learn.
Be a helpful teacher, be an expert, be patient and socratic and guide me towards what I'm asking with the ultimate goal of me completing the task and learning it well.

That’s it. That’s the whole thing.

Instead of Claude writing the code for me, it becomes a patient tutor. It asks me questions. It points me in the right direction. It explains concepts when I’m stuck. But critically - I’m the one writing the code.

How It Actually Works

Let me give you a real example. I started writing an LLM Eval library that would heavily leverage macros to make testing LLM calls easier in Elixir projects. I needed to write a custom DSL to execute the request, parsing and assertions in a nice way. Now, I’ve done metaprogramming in Elixir before, but when you don’t touch macros for a while, it’s embarrassingly easy to forget the fundamentals. What’s quote doing again? Why do I need unquote here? What on earth is Macro.escape for?

Instead of asking Claude to just write the macro (which it absolutely could have done), I ran /teach and said "I need to write a macro that generates getter functions for a list of fields."

Claude didn’t write the code. Instead, it asked me: "What do you know about how macros work in Elixir? Let’s start with what quote does."

We went back and forth. It would explain a concept, then ask me to try implementing a piece. When I got stuck, it would give me a hint rather than the answer. When I made a mistake, it would ask me questions that led me to spot the error myself.

By the end, I’d written everything myself - and more importantly, I actually understood it. The knowledge stuck because I’d wrestled with it, not just passively consumed it.

Where This Really Shines

This approach has been particularly useful for:

• Unfamiliar libraries: When I needed to implement caching with Nebulex, the teaching mode walked me through the concepts of cache topologies and adapters before I wrote a single line of code.
• Complex patterns: Understanding why the codebase uses Knigge for dependency injection made so much more sense when I had to reason through the problem myself.
• Rusty skills: Like my macro example - concepts I’d learned years ago but had let atrophy came back much faster through active practice than passive reading.

The beautiful thing is that it adapts to your level. If you’re completely lost, it starts from first principles. If you just need a nudge, it gives you that and gets out of the way.

Could This Be a Skill?

Probably. It could definitely be packaged up as a proper Claude Code skill with more structure and examples. But honestly, the simplicity is part of the appeal. It’s just a prompt that changes Claude’s behaviour from "code generator" to "patient teacher."

And sometimes the simplest solutions are the best ones.

The Broader Point

We’re in this weird moment where AI can do so much of our work for us that it’s tempting to just... let it. But if you’re trying to grow as an engineer - especially when ramping up at a new job - there’s real value in doing the work yourself, even if it’s slower.

The /teach command has become my default when I’m learning something new. I save the regular Claude Code experience for when I’m confident in what I’m doing and just need to move fast. But for new concepts, new libraries, new patterns? Teaching mode every time.

Don’t get me wrong - I love the capabilities that AI has imparted on us to do work faster than ever and feel incredibly productive - but this shouldn’t come at the expense of understanding the underlying concepts. I fear that by relying on AI to do all the work, we risk losing touch with the fundamentals. I’ll still be using LLMs to write Regex, SQL, Bash and quick scripts (and production code, let’s be honest), but I’ll also be using it to learn now while I do the work itself - with an infinitely patient teacher.

Give it a try. Your future self - the one who actually understands the codebase - will thank you.

I hope you found this post useful, subscribe to my Substack below for similar content and follow me on Twitter and Bluesky for more Elixir (and general programming) tips.

If you find that you struggle with becoming distracted while you work, I encourage you to take a look at Defer - my latest project that helps teach you concepts without interfering with your flow.