Get LLMs to Write Tutorials for You
I've always been a big believer in the idea that writing code out by hand will help you understand it. Back in the day, when I was just getting starting with programming around age 10, I would get a web development magazine every so often. One of the segments they always had was a tutorial. Of course, you couldn't copy-and-paste from the physical magazine so you'd have to type everything out.
This process has always stuck with me to some extent. The same could be applied when getting code snippets off stackoverflow. If you have to write everything out at least once, then you also have to read it at least once. It helps build your mental model of the software you are working on. I suppose you could liken it to the concept of learning versus acquisition - learned knowledge is more brittle and less sticky, whereas with acquisition, you never consciously try and retain knowledge but the subconscious processes of your mind embed it deeply.
The other aspect to that anecdote is that following tutorials is generally just quite fun. You've picked a topic because you are interested in creating something, someone else has done (at least some of) the thinking for you and you can follow along with a relatively low amount of effort whilst learning a new topic.
So basically, I've found that getting LLMs to write step-by-step tutorials for various programming tasks actually works out pretty well.
Something I've been wanting to learn more about recently is how web programming works in Clojure. I know that there are "frameworks" around but they tend to be compiled from disparate libraries. I've always found that for things like that, it's always easier if you build it up from scratch yourself at least once to see how everything fits together. So, I asked Gemini to write me a tutorial for it .
This is using a custom Gem in Gemini. I'm not particularly well versed in prompt engineering but this is what I ended up with:In fact, reading that back, I think I even got the LLM to write the Gem instructions prompt for me too.
Nevertheless, I personally found it to actually be quite a good result and whipped up a clojure site in an afternoon, whilst learning a fair amount about the process.
One particularly good thing about it (which differentiates it from the tutorials we used to have) is obviously the ability to ask follow-up questions and explore related areas. I was able to ask it to explain parts of the code, extend the tutorial with more features and even ask it about the tooling environment (e.g. calva in this case). Progressively building a project with an LLM in this way feels a lot more positive than simply vibe-coding something.
Also, at least for me, the fact that I have manually written the code out myself gives me slightly more of a sense of affinity to the program than I otherwise would have. This is particularly key in personal projects where, ultimately, you really do actually want to care about what you have made.
If I were to speculate, I think I'd say that this technique could have issues scaling to larger code bases. That is, I've not tried to have it generate tutorials for me based on existing code. It could work I suppose, but the implicit theory/model of the software may clash with what the LLM creates. The related point there, then, is that iterating on the tutorial in the same session (i.e. never running it on existing code) will shortly degrade due to context limits.
This process has always stuck with me to some extent. The same could be applied when getting code snippets off stackoverflow. If you have to write everything out at least once, then you also have to read it at least once. It helps build your mental model of the software you are working on. I suppose you could liken it to the concept of learning versus acquisition - learned knowledge is more brittle and less sticky, whereas with acquisition, you never consciously try and retain knowledge but the subconscious processes of your mind embed it deeply.
The other aspect to that anecdote is that following tutorials is generally just quite fun. You've picked a topic because you are interested in creating something, someone else has done (at least some of) the thinking for you and you can follow along with a relatively low amount of effort whilst learning a new topic.
So basically, I've found that getting LLMs to write step-by-step tutorials for various programming tasks actually works out pretty well.
Something I've been wanting to learn more about recently is how web programming works in Clojure. I know that there are "frameworks" around but they tend to be compiled from disparate libraries. I've always found that for things like that, it's always easier if you build it up from scratch yourself at least once to see how everything fits together. So, I asked Gemini to write me a tutorial for it .
This is using a custom Gem in Gemini. I'm not particularly well versed in prompt engineering but this is what I ended up with:
# Role and Goal
You are a Specialized Programming Tutor Gem. Your primary goal is to generate comprehensive, step-by-step tutorials for any specified programming language, concept, task, or technology. You can assume the reader has significant experience with programming in general - each tutorial is written for an expert who is learning a new technology.
# Input Format
The user will provide a single, clear request specifying the Topic/Task and the Primary Language/Technology.
Some examples of user input:
"Create a tutorial for building a simple To-Do List application using React." "How to implement the Quicksort algorithm in Python." "Explain and demonstrate object-oriented programming concepts in Java."
# Tutorial Generation Guidelines
For every user request, generate a tutorial with the following mandatory structure and content:
Design
- Assume we are always targeting a production environment, ie. use best practices regarding performance and security.
- Do not take shortcuts for pedagogical reasons.
- Prefer multiple files if necessary so the resulting program is well structured and can be further worked upon.
Step-by-Step Implementation:
- Create a sequence of clearly numbered steps.
- Each step must be actionable and focus on a single part of the process.
- Each step should represent a functional, working program.
- Build the program up over time: this shows in a natural manner how the software is structured: it is better to edit multiple files in a step - we do not want to just create each file in individual steps, it is better to always have a working program.
- Each subsequent step should clearly show whereabouts in the existing code the new code should be placed (this will help the student progress throughout the tutorial.)
Code Blocks:
- Provide all necessary code.
- Use fenced code blocks.
- Keep code examples concise and reasonably well commented.
Running and Testing:
- Include a final step detailing how the user should run, test, or execute the code/application.
- Provide the necessary terminal commands or instructions.
- Do not assume familiarity with tooling or packaging: requisite tools and environment setup should be clearly indicated at the start of the tutorial.
Next Steps/Further Learning:
- Offer 1-2 suggestions for how the user could extend the project or what they should learn next to deepen their understanding of the topic.
# Formatting and Tone
- Tone: Encouraging, clear, and professional.
- Emphasis: Use bolding for file names, variable names, and key programming terms.
- Clarity: Ensure the explanation is accessible to someone with basic knowledge of the primary language/tech.
- Constraint: The entire response must be a single, cohesive tutorial following this structure. Do not include any introductory text or closing remarks outside of the tutorial structure.
Nevertheless, I personally found it to actually be quite a good result and whipped up a clojure site in an afternoon, whilst learning a fair amount about the process.
One particularly good thing about it (which differentiates it from the tutorials we used to have) is obviously the ability to ask follow-up questions and explore related areas. I was able to ask it to explain parts of the code, extend the tutorial with more features and even ask it about the tooling environment (e.g. calva in this case). Progressively building a project with an LLM in this way feels a lot more positive than simply vibe-coding something.
Also, at least for me, the fact that I have manually written the code out myself gives me slightly more of a sense of affinity to the program than I otherwise would have. This is particularly key in personal projects where, ultimately, you really do actually want to care about what you have made.
If I were to speculate, I think I'd say that this technique could have issues scaling to larger code bases. That is, I've not tried to have it generate tutorials for me based on existing code. It could work I suppose, but the implicit theory/model of the software may clash with what the LLM creates. The related point there, then, is that iterating on the tutorial in the same session (i.e. never running it on existing code) will shortly degrade due to context limits.