Field notes

6 min read

No course was perfect for me, so I used AI to build one

No course was perfect for me, so I used AI to build one

Since the beginning of my career as a software engineer, I've focused on one tech stack and one programming language. Earlier this year I decided I wanted to widen my range and pick up another language and framework, to become an engineer who could contribute wherever the work happened to need me, not just in the one corner I already knew.

Since the beginning of my career as a software engineer, I've focused on one tech stack and one programming language. Earlier this year I decided I wanted to widen my range and pick up another language and framework, to become an engineer who could contribute wherever the work happened to need me, not just in the one corner I already knew.

BY Joren Van Looveren

Engineer

Joren is a mobile engineer at November Five who spent most of his career building native Android apps and Kotlin Multiplatform libraries, and is now finding his way around React Native. He's the engineer who notices the four pixels nobody else does, and who would rather fix the design system than patch the same screen twice.

TL;DR

TL;DR

  • At November Five you own what you ship, agent-written or not, so I need to actually understand what I am building.

  • When I started learning a new programming language and framework, hunting for “the right course” online led to analysis paralysis: too many options, no way to tell which one fit me.

  • So I built a learning environment around myself instead, using an AI skill called /teach that starts by asking why you're learning and what success looks like.

  • It leaned on what I already knew, and held onto every correction I made.

I could have skipped learning any of this and let an agent write the code in the new stack instead. But then I would have no way to tell whether what it produced was actually correct, and my name would still be on it. At November Five, ownership doesn't come with an asterisk: you own what you ship, whether you typed every line yourself or not. If something goes out with my name on it, I need to understand it well enough to stand behind it.

The old way

When starting this learning process, I did what most people do: I went looking for the right course. A few weeks of foundational material, then a search for what should come next. That's where things slowed down. There was no shortage of tutorials, bootcamps, and crash courses. The problem was that every one of them was written for a generic learner, and I wasn't one. I already had years of relevant experience to draw on. I didn't need the basics explained from scratch. I needed to know where my existing instincts would help and where they'd quietly mislead me. None of the courses could tell me that, because none of them knew who I was. Analysis paralysis hit me. There was no lack of options, but no way to tell which option was actually mine.

Building my own

The thing that got me moving wasn't a better course. It was giving up on the idea of finding a pre-made one at all.

I started using an AI skill called /teach, built by Matt Pocock, also known for creating other skills like /grill-me. Instead of pointing me at existing material, it builds a local learning environment around me specifically. Before it writes a single lesson, it asks two questions: why are you learning this, and what does the outcome look like? That’s it. But those two questions do most of the work a generic course never can, because the answers become the filter everything else runs through.

What that actually looks like in practice is a folder of material that keeps growing the more you use it. It's not a chatbot you interrupt with questions, and it's not a fixed set of chapters either. It holds the mission you set out at the start. It holds what you already knew coming in, what you've already covered, where you got stuck, and any preference you've stated out loud. All of that gets read back in before the next lesson gets written. Each lesson is its own HTML file, generated on-demand, built around exactly where you are at that moment. The content is pulled from official docs and recognized sources in the space, not just whatever the model already knew.

My answers on the skill's initial questions became a short mission statement: broaden my range, get comfortable contributing to unfamiliar parts of the stack. From there it built a roadmap ordered by what actually moved me toward that goal.

What made it work

Right from that first lesson, it leaned on what I already knew. New ideas got explained by comparing them to concepts I'd already mastered, instead of starting from zero. None of the courses I'd tried before had any idea what I already knew. This one did.

The first lesson still felt a bit thin in places. So I told the agent I wanted more depth: more of the why, not just the syntax. Every lesson since has been deeper. I said it once, and it stayed true throughout the whole process.

That same persistence showed up in smaller decisions too. One tricky concept got pushed later than a standard course would teach it, until I actually had knowledge to build on and ran into the real problem it explains. Another topic used to matter a lot in my old way of working, but barely came up in this one, so it got a short, shallow pass instead of a deep dive. Recognizing it was enough. Writing it myself was never going to come up.

The roadmap also reshaped itself around real work, not just my preferences. When I was asked to do my first contribution to a real project, I told the agent about the project before jumping in. The plan shifted to match exactly the tools I'd actually be using in the codebase, instead of teaching the topic in the abstract.

That preparation paid off the moment the ticket actually landed. I wasn't learning the tools and the feature at the same time. I already recognized the patterns in the code, so I could spend my time on the actual problem instead of the unfamiliar setup around it. I was up and running in no time.

The rough edges

It wasn't perfect, though. Left alone, the lessons lean toward a lot of reading, and I had to steer them more than once toward hands-on exercises instead of another wall of explanation. It also has a habit of reaching for advanced ideas earlier than I needed them: technically correct, not yet useful. I said so, and it slowed down. Those are steering problems, not dealbreakers.

Why this, why now

I'm aware that as AI models get better at writing correct code on their own, the case for deep, hard-won mastery gets a little more complicated. Maybe in a not-so-distant future the argument for learning the fundamentals yourself looks different than it does today.

But right now, two things make that the right call. One is the ownership reasoning from before. The other is that AI-generated code still isn't perfect. It gets things wrong in ways that need real understanding to catch, not just a sense that something looks off. That's why I chose to learn the new stack thoroughly and deliberately. It was the right call for this moment, even knowing it might not stay the right call forever.

NOVEMBER FIVE

If the product is core to your business, you can't afford to get the team wrong.

Get in touch

When your digital product is the business, the margin for error is different. So is the team you need.

If that's where you are, let's talk.

Get in touch

When your digital product is the business, the margin for error is different. So is the team you need.

If that's where you are, let's talk.