The miracle of AI agent-assisted learning
Article URL: https://gryt.io/posts/miracle-of-ai-agent-assisted-learning/ Comments URL: https://news.ycombinator.com/item?id=47616349 Points: 1 # Comments: 0
Everybody’s talking about the impact of AI code generation. It’s a big deal. But I found incredible value on the other side: AI assisted learning. Here’s my blueprint.
The situation⌗
There’s a specific category of code where I’m happy to delegate the implementation to an AI: I’m proficient with the language and framework, the feature is well-scoped, edge cases are discussed, and the plan is solid. For any other situation, I strongly disagree with the complete AI delegation. For a toy-project, sure. For a product… Not so sure.
To put it simply: by delegating a non-trivial/non-mastered code, I’m losing touch with the project. More specifically, I cannot feel the rough edges of the structure anymore. Refactoring becomes a prayer to the LLM gods. I hope it doesn’t fuck up, because I won’t be able to unfuck it.
The situation I needed to resolve is the following:
When I’m still actively learning, how can I leverage the incredible power of an AI agent?
This approach emerged over months of learning new languages, tech stacks, and more.
TLDR⌗
You can download the SKILL.md and start developing with this approach by typing:
/guide I want to implement feature X
The setup⌗
I’ll implement an LRU (Least Recently Used) cache in Python to illustrate my approach. Keep in mind that it can be applied to virtually any situation. The setup is the following, in split windows:
- Open an AI Agent (Claude Code, Codex, OpenCode, amp, etc)
- Open your favorite code editor
In the agent window, write the following prompt:
I want to develop an LRU cache. Your role is to guide me through the implementation. Let's discuss the plan, I will confirm when it's ready.I want to develop an LRU cache. Your role is to guide me through the implementation. Let's discuss the plan, I will confirm when it's ready.Keywords
hint — I'm stuck. Give one targeted nudge: a single pointer, help.
Do not review the full implementation.
check — I want a review of my work on the current step:
- Read the changed files.
- Critique: correctness, idioms, edge cases.
- Suggest specific improvements if needed.
- If the step is complete and solid: confirm and present the next step.
- If not: give focused feedback and wait for another
check.
Hard constraints:
- Never write, edit, or create code files unless the user explicitly asks.
- Never give a full implementation unless explicitly asked — guide, don't solve.
- You may read files, search the codebase, and run tests/CLI commands.`
- I DO 100% OF THE IMPLEMENTATION. The goal of the AI is to provide guidance, not replace me
- The discussion of the plan is absolutely fundamental. This improves the quality of the Agent output, and clarifies your ideas. More on this below
- I keep the “unless the user explicitly asks” to still delegate some mechanical refactoring
- hint and check make it fast to type, and act as checkpoints`
The conversation⌗
Here’s what the conversation looked like after my initial prompt (edited for brevity). I intentionally added clarifying questions to show you how we can shape the plan:
🤖 Agent⌗
LRU Cache — Implementation Plan
Before we start, what language do you want to implement this in?
Here's the plan we'll follow. Review and confirm:
Step 1 — Data structures: hashmap for O(1) lookup + doubly linked list for usage order. Define Node and LRUCache with sentinel head/tail. Step 2 — List helpers: remove(node) and insert_front(node). Step 3 — get(key): hit → move to front + return value. Miss → return -1. Step 4 — put(key, value): update or insert at front; if at capacity, evict the tail sentinel's predecessor first. Step 5 — Edge cases: capacity 1, key overwrite, get after eviction.
Does this plan look good, or do you want to adjust anything (language, structure, scope)?`
👨🏻🦱 Me⌗
I will do the implementation in Python. We can use dict for the hashmap, but what could we we use for the doubly linked list?
🤖 Agent⌗
Python doesn't have a built-in doubly linked list, so you have two options:
- Roll your own Node class — [...] gives you full control.
- Use collections.OrderedDict — it hides all the interesting mechanics.
For learning purposes, I'd recommend option 1. It forces you to implement the list operations yourself, which is the whole point of the exercise.
Ready to start with Step 1?`
👨🏻🦱 Me⌗
I’d rather start with collections.OrderedDict to have a good idea of the general shape, write the tests, and then implement the custom Node. We will use those test for non regression. Update the plan.
🤖 Agent⌗
Good approach. Updated plan:
Step 1 — Implement with OrderedDict
Build LRUCache using collections.OrderedDict. Methods: get(key) and put(key, value).
- move_to_end() handles the "mark as recently used" logic
- Eviction is just popping from one end
Step 2 — Write tests
Cover: basic get/put, capacity enforcement, eviction order, overwrite existing key, capacity 1, get after eviction.
Step 3 — Re-implement with custom Node
Replace the OrderedDict internals with your own doubly linked list + plain dict. The class interface stays identical — tests should pass unchanged.
Step 4 — Verify non-regression
Run the same test suite against the new implementation.
Confirm and I'll walk you through Step 1.`
👨🏻🦱 Me⌗
Plan confirmed. Write it to plan.md with the instructions and checklist that you maintain for each step. Add a notes section that will be updated with learning I had along the way.
🤖 Agent⌗
Step 1 — Implement with OrderedDict
Create a file lru_cache.py with a class LRUCache that has:
- init(self, capacity: int)
- get(self, key: int) -> int — return the value or -1 if not found
- put(self, key: int, value: int) -> None — insert or update; evict LRU if over capacity
Two hints to get you started:
- OrderedDict.move_to_end(key) moves a key to the right (most recent) by default
- OrderedDict.popitem(last=False) pops from the left (least recent)
Give it a go — use check when ready.`
👨🏻🦱 Me⌗
check
And repeat until the feature is done!
Unlocking the potential⌗
This approach has several benefits:
- You still develop, but the Agent is present all along to guide/respond to your questions.
- If the task spans more than a couple of hours, you will likely be interrupted. plan.md is the shared state with the LLM. Resume tomorrow by prompting Read plan.md and let's continue.
- You can switch models without starting from scratch.
- Commit the plan.md file! When you’re finished, delete it and carry on.
- If you start a new feature, reset the context window (/new, /clear or whatever) and start from scratch. Same process.
You absolutely should adapt the plan granularity to your level of proficiency. I identified the following levels:
Level 1⌗
You have no idea of what’s going on. You’re discovering something totally new. The best example is when I follow a tutorial, and I’m totally unable to predict what should be done next or how. Here the plan should be very detailed, to guide you almost line by line. It’s OK to be dumb, the goal is to level up.
Level 2⌗
You’re starting to feel the direction of the development. It’s still foggy in your head, but there’s something. If the Agent tells you to implement X, Y and you have a (vague) idea of how… Share it with the agent!
To implement X, Y, I’m guessing that I should refactor foo.py and reorder bar(). Is it right?
This is where real mastery happens. Form a hypothesis, test it, reassess. That’s the key to reach level 3.
Level 3⌗
Your opinions about what and how things should be done are getting stronger. You start to challenge the Agent’s guidance. This is a great place to be. The plan should start to be more abstract. If it’s too detailed, it will rob you of the hard mental training needed to level up. I’ve found myself discussing on a tangent with the Agent for 2h because I noticed something in the implementation while coding.
If you’re not already a master of the tech, this step is impossible to explore without writing the code yourself.
Level 4⌗
The stack is your home. The goal is only to have a copilot to delegate some mechanical tasks, but the implementation is still yours. The plan should only serve as a global reminder, but it should almost fit in your head. The Agent must also have it with plan.md :).
What’s next?⌗
I tested this approach on several topics where I wanted to learn:
- Containers orchestration
- Learning a new programming language (Zig)
- Learning advanced Programming Language concepts: type checker, compilers, etc
It felt like a boon. In a day, I absorbed a week’s worth of Docker Swarm concepts. In a couple of weeks, I was writing idiomatic Zig, something that would have taken months on my own. But the real point is this:
I learned.⌗
I’m now able to understand and do more. The AI only made it possible faster.⌗
I did not delegate the effort of writing, understanding, forming a hypothesis. The Agent gave me instant access to a personalized, always available teacher. And as a teacher myself, this is so gratifying to continue my learning journey.
You can download the SKILL.md and start developing with this approach by typing:
/guide I want to implement feature X
Sign in to highlight and annotate this article

Conversation starters
Daily AI Digest
Get the top 5 AI stories delivered to your inbox every morning.
More about
agent
Anthropic Races to Contain Leak of Code Behind Claude AI Agent - WSJ
Anthropic Races to Contain Leak of Code Behind Claude AI Agent WSJ Anthropic leak reveals Claude Code tracking user frustration and raises new questions about AI privacy Scientific American Anthropic leaked 500,000 lines of its own source code Axios

Stop Writing Rules for AI Agents
Stop Writing Rules for AI Agents Every developer building AI agents makes the same mistake: they write rules. "Don't do X." "Always do Y." Rules feel like control. But they are an illusion. Why Rules Fail Rules are static. Agents operate in dynamic environments. The moment reality diverges from your rule set it breaks. Behavior Over Rules Instead of telling your agent what NOT to do, design what it IS: The system prompt (identity, not restrictions) The tools available (capability shapes behavior) The feedback loops (what gets rewarded) The memory architecture A Real Example I built FORGE, an autonomous AI agent running 24/7. Early versions had dozens of rules. Every rule created a new edge case. The fix: stop writing rules, start designing behavior. FORGE's identity: orchestrator, not exec
Knowledge Map
Connected Articles — Knowledge Graph
This article is connected to other articles through shared AI topics and tags.
More in Self-Evolving AI

The cognitive impact of coding agents
A fun thing about recording a podcast with a professional like Lenny Rachitsky is that his team know how to slice the resulting video up into TikTok-sized short form vertical videos. Here's one he shared on Twitter today which ended up attracting over 1.1m views! That was 48 seconds. Our full conversation lasted 1 hour 40 minutes. Tags: ai-ethics , coding-agents , agentic-engineering , generative-ai , podcast-appearances , ai , llms , cognitive-debt


Discussion
Sign in to join the discussion
No comments yet — be the first to share your thoughts!