Read and forgotten
Almost every good course lesson expects you to try something out: on your own project, on an example, in your own work. The trouble is that it’s usually hard to find somewhere to start. At a certain stage of life our habits are fairly settled, and there isn’t much room left in them to do something differently. Advice like that is easy to ignore, so the lesson ends at reading it.
To try something out, we usually need a push from outside or a guide who takes us through it. An LLM can serve as that guide. We then don’t have to think about what to try, how to do it, what it connects to and what it doesn’t really. We can focus on the core of the lesson without taking care of all the organizational overhead.
That’s how I go through material, and from start to finish it’s about trying things out. Even just getting to know the content requires me to think about what it means for me and what in my work it relates to.
How I go through a lesson
I start with context. Before the first question is asked, I settle what I’m holding the material up against: something I work with every day, something that concerns me, where the content could change something. Each course also has its own set of questions through which I look at its content, for example “does this go into my process” or “does this change my offer”.
Then an AI agent breaks the lesson down into elements (practices, tools, rules) and for each one checks what I do in that area today. Next it interviews me, element by element. The interview forces me to answer what this piece of information means for me and how I would translate it into my work.
Each element ends with a verdict: adopt, reject, or leave open, with a condition for when to come back to it. Every “adopt” goes where it changes the work: into a task, a file, a decision record. A verdict without such a place stops existing on the day the session ends.
Technical courses add a trial. Before any verdicts are made, I run the course’s tools in a separate session on my own project, in my case Loop, a game I’m building. Adopted things then go into my way of working on a product, and there they go through a second trial. I don’t carry code from the trial into the product, only the knowledge written down in the verdict.
An article can be gone through the same way. Usually there’s nothing to try it out on, but the interview and the verdicts stay, so an article also leaves decisions behind.
What trying it out showed
It gets most interesting when trying something out shows something different from the text I read. Three examples from the 10xDEVS course.
A list that filtered out good options. The lesson on choosing technology gives a list of traits that make a technology convenient for an AI agent, among them good documentation and popularity. Had I only read it, I would have adopted the list as a filter: a technology missing any of the traits is out. In the trial the list worked exactly like that and filtered out options for purely formal reasons. One was dropped because its documentation didn’t state a version number. Another lost because the agent found no proof that it was widely used, even though the one it recommended instead gave my game no advantage at all. I chose the one that lost. Without the trial, my way of working would have a rule that quietly cuts out good options. The list stayed, but it only carries weight in the comparison, it doesn’t throw anything out of it.
A document nobody opens. The lesson on deployment advises writing everything about the infrastructure into one document: where the application runs, how to deploy it and roll it back, where the passwords and keys are. In the trial the agent wrote such a document, concrete, 145 lines long. Except that no step in the whole process read it. A document like that “doesn’t answer any question”, it’s just a collection of things about infrastructure. I adopted the content, but I spread it out to where it gets reached for: why I chose this hosting goes into the decision record, and how to deploy goes into the instructions the agent uses when deploying.
A question that found a bug straight away. The lesson on the interface says to start by reviewing the existing screens and asking a simple question: what will someone see who comes in straight from a link, with no data at all? On the old version of the game it hit straight away: coming in from a link, the player saw a blank page until the game loaded the save. The review also found something the lesson didn’t ask about: the same color meant different things on different screens. It’s easy to dismiss as cosmetic, but it makes the player read the game wrong. The question from the lesson became a permanent part of reviewing screens.
Most of it falls away
Across eleven lessons of the course, 217 elements went through. I adopted 48, rejected 153, and left 16 open with a condition for when to come back to them. In the lesson on code review I rejected all 24 elements, because my way of working already has its own reviews.
I don’t reject things because they’re worthless. In most cases they either don’t fit my way of working, or I already do them, so there’s nothing to adopt.
In the end
Only this way of going through material made me actually learn sensibly, rather than just read about something valuable or cool. Before, my learning was haphazard and usually dragged out over time. Now it’s much closer to my everyday life and affects it much faster and much more sensibly than it used to.
If you want to try it, start with the first step. Before you open your next lesson or article, settle what you’ll hold it up against: a project you’re working on, your own way of working, something the content could actually change.