Where the bug is a feature - using LLMs as a learning companion
Large Language Models are at a pivotal point. On one hand, we still don't understand how they work or why they work so well - could human thought be nothing more than a pattern that these models have somehow uncovered? On the other hand, there's growing concern that LLMs are hitting a wall1, that current approaches (i.e. throwing ever more money and computation on training) won't fix its biggest shortcomings (e.g. hallucinations), and that the alarmingly high valuations and expectations may come crushing down soon.
But whatever the future holds, as of early 2025, LLMs have demonstrated their usefulness in various ways. One specific use case - this blog's hobby horse - is using language models as a learning companion.
When the student is ready, the master will appear
What would an ideal teacher look like? Imagine the perfect mentor on your side. Someone who is vastly more knowledgeable than you, but capable of speaking in a language you understand. Someone who knows your strengths and weaknesses, and can support or challenge you in just the right way. Above all, someone who is always available, endlessly patient and never gets tired.
How do chatbots compare to these ideal traits?
Endless patience. This is an undeniable match. Your favorite chatbot is always available, never gets tired, is always nice and never offended (unless you somehow get beyond their guardrails). That is the unbeatable advantage of a machine.
Speaking your language. This is possible to accomplish, more or less, depending on how hard you try. Ask the chatbot to talk "as if to a child" and similar prompts can adjust the language to a level you understand.
Vast knowledge. True and false, depending on your level of expertise. While LLMs are surpassing any single human's knowledge after having devoured the entire internet (and running out of training data), they are also prone to hallucinations, which make them highly unreliable.
Understanding your strengths and weaknesses. LLMs don't know you, and have no agency to care for or plan your progress. However, with the right prompts and sufficient persistence, we can get them to emulate a useful mentor, as I explain below.
LLM-based chatbots are comparable to highly capable interns with endless ambition and energy, who are extremely well-read, but have no life or work experience and demonstrate a dangerous lack of common sense. They are helpful hands but require constant supervision.
They do bring something new, however - something that computers could not achieve before: the ability to adapt to any written input. Until recently, human-computer-interfaces have mostly been static. Input was limited to a predefined set of controls, and the same input lead to the same output. Two different people get the same Wikipedia page and search engine results (except where advertisement may skew what is presented). Variations in output, such as in computer games, have mostly been random, not tailored to the individual player.
LLMs are way more malleable than other systems. While randomness still exists, the key difference lies in their quantum leap in understanding of written input. The ability to describe the context of my question in my own words - and have the system adjust to even subtle changes in how I express my intent - opens up entirely new possibilities for merging my mental model with new knowledge. That is, if we use these tools the right way.
Every thought is a mental model
In the book "Why Don't Students Like School?"2, author Daniel T. Willingham describes the learning process in a beautiful way: "Understanding is remembering in disguise". We learn new ideas by comparing them to old ideas. However, not just any old ideas. Learning occurs if we are able to pull up the right existing ideas from long-term storage, bring them into working memory, and arrange them in a way such that new ideas fit in.
The act of “loading old ideas” into working memory is crucial process, one that we can make more efficient by deliberately describing, testing and extending our existing mental model. The best thing about LLMs is that we can do all that directly at the prompt. This not only leverages what makes chatbots so useful3 but also makes our learning efforts significantly more productive.
For example, if two users ask, "What is Kubernetes?", the chatbot will likely provide both users with similar responses. Using a language model that way, all we get is, at best, a better search engine.
However, if I begin with my personal mental model of Kubernetes—whatever it may be (and we always have a mental model) - I can engage with the chatbot building on what I already know. This makes the responses more useful.
For example, I may provide the following prompt:
I want to learn about Kubernetes. Here is what I believe.
Kubernetes is a framework to manage containerized applications. Kubernetes are built on top of containerization software like Docker. Kubernetes can use any kind of container run-time, but let us assume we are using Docker. Kubernetes extends Docker with new ways to define and manage applications.
On a high-level, Kubernetes creates two applications inside Docker: a control node and data nodes. The control node delivers the Kubernetes API and is the entry point to any Kubernetes cluster. The data nodes contain the application. There is at least one data node, but there can be more in case the application needs to scale up.
What I don't understand is how nodes are created and how Kubernetes uses Docker. Evaluate my understanding and explain what I don't know.
(I have added a sample response below).
This way of prompting achieves two things:
1) I am describing my existing mental model to the chatbot - and to myself. (It is my model - you may not understand at all what I say, find it trivial or completely wrong, depending where you are on your journey). This activity alone is immensely valuable. Even if I don't press send, the act of articulating my thoughts helps clarify my doubts and enabling me to engage more actively with the subject.
2) I provide the LLM with a more detailed context, allowing it to generate a response tailored specifically to my problem.
Of course, you can start with the Wikipedia-style question and answer and go from there. They key is to drill down to your specific areas where you need clarification.
Where the bug is the feature: an exercise in critical thinking
Like any powerful tool, AIs can be either a boon or a bane, depending on how they are used. While I've discussed advantages of LLMs, it's equally important to address the caveats.
LLMs are designed to write well and please the user, which can easily create a misleading impression of authority. They are prone to errors, or worse, to fabricating completely false information. This inherent unreliability may never allow us to fully trust their output. In many fields, this poses a significant problem that could hinder widespread adoption.
In our situation, however, we can turn this flaw into an advantage.
Like an unreliable narrator in fiction, who keeps us on our toes and makes us question the story in front of us, knowing that LLMs are flawed means we must always be ready to doubt their output. The first grave mistake to avoid, therefore, is to blindly trust any AI generated text, no matter how well articulated or convincing it may seem.
This is also called critical thinking, a basic skill useful in any context. By questioning and verifying the output, we are compelled to actively engage with the subject and continuously test our mental models. LLMs are particularly useful in areas that have verifiable truthiness. Engineering, for instance, is a suitable subject, because often it becomes immediately apparent if something works or not.
The unreliability of LLMs also prevent us from making the second grave mistake when using these new tools: outsource all our thinking to an AI. A chatbot may spit out the correct answer for you and fix your problem, but if your goal is to learn and grow intellectually, letting an AI do all thinking for you would achieve the opposite. It’s like saying, “Cars can get me from A to B much faster, so what's the point of exercising.”
Instead, we need to figure out what parts of the thinking process to automate and where to do the heavy lifting ourselves. For example, if you are an experienced developer, using a coding AI to generate boilerplate code can be helpful, allowing you to focus on more complex and valuable tasks.
What about surrendering the ability to read maps by relying solely on GPS? I am not sure about this. I would not deliberately turn off route guidance ("real men don't need GPS") but I believe that we may lose something deeper if we are not able to read maps anymore and orient ourselves in the world like generations before.
However, completely giving up on solving problems yourself and simply copying and pastings answers from an AI is a terrible idea. After all, if you stop thinking critically and let a machine do it for you, what's to stop someone replacing you with this machine?
Instead, use the LLM as a sparring partner. Let it generate ideas to spark your thinking and use it as a tool to find and fill gaps in your knowledge. Let it help you become smarter and focus on what is valuable and can not be automated.
Even if AIs were to become fully reliable, the third and ultimate mistake would be to replace human interaction with chatting to a bot. Humans are flawed, emotional, have hidden agendas, but the richness of human connection remains far beyond the reach of machines - and I doubt they'll ever come close (well, that's a topic for novelists to explore). A good human teacher connects with their students on multiple levels, offering a depth of engagement that no AI can replicate.
However, the LLM at your side can boost your efforts - for example, by helping you prepare a meeting with another human or by refining your writing to communicate more clearly (as it did for this post - thanks, dear AI editor).
Appendix: A sample response to my mental model
Your understanding of Kubernetes is generally correct, but there are a few nuances and details that need clarification to give you a more complete picture. Let’s break it down:
What You've Got Right:
Kubernetes and Containerized Applications: Kubernetes ... provides the orchestration needed to deploy, scale, and manage containerized applications.
Kubernetes and Docker: Kubernetes ... can work with other container runtimes as well, like containerd or CRI-O. Docker was historically the default container runtime for Kubernetes, though it's no longer the default in recent Kubernetes versions.
Control Plane and Worker Nodes: Your description of the control plane (which you referred to as the "control node") and worker nodes (which you called "data nodes") is broadly correct. The control plane is responsible for managing the cluster, including scheduling applications (pods), maintaining the desired state, and exposing the Kubernetes API. Worker nodes run the actual containerized applications.
Scaling: ... Kubernetes allows applications to scale by adding more worker nodes.
What Needs Clarification:
Nodes and Their Creation:
Node Types: Kubernetes clusters consist of two types of nodes: the control plane nodes and worker nodes (not just one control node). The control plane typically consists of multiple nodes (for high availability), which collectively manage the cluster.
Node Creation: Nodes are typically physical or virtual machines (VMs) that you add to the Kubernetes cluster. These machines are prepared (or “provisioned”) and then registered with the Kubernetes control plane. Kubernetes doesn’t create these nodes by itself; they are provisioned through external systems or cloud providers like AWS, GCP, or Azure, which can automate the creation and addition of these nodes to the cluster.
How Kubernetes Uses Docker:
Docker and Kubernetes: When using Docker as the container runtime, Docker is responsible for running the containers, but it does so under the orchestration and management of Kubernetes.
Kubernetes Components and Docker: The Kubernetes control plane manages everything. When a new application (or “pod”) is scheduled on a worker node, the kubelet (a Kubernetes component that runs on each node) instructs Docker to pull the necessary container image and start the container. The kubelet then continuously monitors these containers and reports back to the control plane.
Pods and Containers: Kubernetes doesn’t directly create Docker containers; it creates pods. A pod is the smallest deployable unit in Kubernetes and can contain one or more containers. When Kubernetes schedules a pod, Docker (or the container runtime) runs the containers inside the pod. Thus, Kubernetes abstracts away the direct handling of Docker containers and instead manages pods.
Control Plane Details:
The control plane consists of multiple components, including the API server (which exposes the Kubernetes API), the etcd database (which stores the cluster state), the scheduler (which decides which node runs a new pod), and the controller manager (which enforces the desired state of the cluster).
Worker Nodes:
Worker nodes run a kubelet, which communicates with the control plane, and a container runtime (e.g., Docker) to run the containers. They also have a kube-proxy component that manages networking for the pods.
What You Don't Know (Based on Your Description):
Node Provisioning: Nodes are not automatically created by Kubernetes; they need to be provisioned and added to the cluster through an external process. Kubernetes then manages these nodes once they are part of the cluster.
Pods vs. Containers: Kubernetes doesn’t manage individual containers directly; it manages pods, which can contain one or more tightly coupled containers. The concept of a pod is central to Kubernetes and is a layer of abstraction above containers.
Control Plane Components: The control plane is not a single application or node but a set of components working together across potentially multiple nodes to manage the entire cluster.
In Summary:
You have a good foundational understanding of Kubernetes, ... However, to fully grasp Kubernetes, it's essential to understand the concepts of nodes (control plane and worker nodes), pods as the basic unit of work, the interaction between Kubernetes and Docker, and the broader architecture involving multiple components working together to manage the cluster.
It is an open discussion whether or not LLMs have peaked.
Why Don't Students Like School? by Daniel T. Willingham is a intriguing book for teachers and learners, that provides a few counter intuitive insights, for example, debunking the myth attributed to Einstein that "Imagination is more important than knowledge" - that fuzzy notion that we all can dream up innovative thoughts without the need to study hard facts, were in reality, knowing a lot of facts (which Einstein certainly did) is the precondition to build any kind of expert skill.
AIs ability to adapt to user input is very useful, but others might say dangerous - depending on how you look at it, e.g. from a security standpoint (or your intentions).