Mindfood on Gryt

The miracle of AI agent-assisted learning

robin@gryt.io (Robin Penea) — Thu, 02 Apr 2026 17:27:05 +0200

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.

### 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:
1. Read the changed files.
2. Critique: correctness, idioms, edge cases.
3. Suggest specific improvements if needed.
4. If the step is complete and solid: confirm and present the next step.
5. 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:

 1. Roll your own Node class — [...] gives you full control.
 2. 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

What Unit Tests tells about Human Nature

robin@gryt.io (Robin Penea) — Mon, 17 Jun 2019 10:35:32 +0100

It’s Friday night. after an intense week of work, you’re about to take off to enjoy your week-end. Your boss storms in the office:

“You’re still here! Great, I need you to add a hot fix in our Phronabulax System. We expect a demo Monday morning very early, everything has to be ready!”

Well. That was unexpected. You know your boss, he/she wouldn’t ask if it wasn’t really urgent. You grumble a bit but still go dig into the code to do the work.

My enthusiasm and fervor to do this on a Friday night cannot be overstated. Thank you boss.

30 minutes later, you commit your work and breathe a sigh of relief. Wait! You completely forgot the tests! You didn’t add a new test covering the modification. There might be unintended side effects. What shall you do?

Without a doubt, you shutdown your computer and leave. This can wait Monday, and the fix was trivial!

Are you a bad developer? An impostor? Nope, I certainly hope not. I think you’re just a Human.

What is a Unit Test?

I won’t delve into the details of Unit Testing, TDD (Test Driven Development) or any purely technical aspect. I’d like to scratch what is hidden beneath Unit Tests. More precisely, what it reveals about us, about our Human Nature.

The formal definition of a Unit test by Wikipedia states:

In computer programming, unit testing is a software testing method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine whether they are fit for use

As any proper formal definition, it’s absolutely opaque for anyone who doesn’t already know what is a Unit Test.

One might ask “What’s the point of the definition then?”. To look educated and unreachable my dear!

When you ask why the bridge is red and your friend starts explaining.

A Unit Tests is a piece of code that you write that will execute a subset of your real program to verify its behavior.

If I input 5, it should spit "Hello", If I input 42, it should crash, and so on.

I don’t have the time to write tests

And I agree with you, me neither. Writing tests requires time, the structure of the test is a craft in itself. Having a decent test coverage is a real effort. Still, I have a question for you:

Do you test what you develop?

I mean it in the simplest sense: you write some code, run the program and check if it works as intended. Chances are, you are doing it all the time. You might even yell at your computer because the compilation / startup time to test it takes more than 2,4 seconds.

Compilation took 4 seconds, my mug is empty and the Coffee Machine is broken. This is unbearable.

Unit Tests are merely an automated way of doing what you already do by hand. But I understand, it’s time consuming and the feature has to be delivered yesterday. So why write tests?

Human After All

Because you are just a Human! I believe testing reveals something very interesting about us, as Humans: we’re absolutely fallible, and even more while coding.

Don’t believe me?

What is the quality of you work when you slept 3 hours ? When there’s a disturbing noise in the office? When you neighbor keeps chewing that dreadful, juicy candy?

My sleep routine is tight, my work is perfect. Any question?

Let’s assume you always sleep 8 hours each night and that your noise canceling headphones does wonder.

What about that dark corner of the project? The one that makes everyone look at their feet when you need to modify it? It was written ages ago by a dark ninja-shaman on a moonless night? Nobody understands it and even less dares to touch it?

I don't want to make a fix below water level. PLEASE GOD NO!

Yes, it makes you cringe every time you approach it.

That’s exactly why Unit Tests exist: because you’re just a Human. You can be tired, angry, not concentrated. Because you don’t have the time nor the energy, the Unit Test will execute the 526 cases that you don’t want to check yet another time.

Down the Rabbit Hole

What I find incredible is not that the discovery that we are deeply flawed. The Atlantic Ocean could be filled with the ink spilled on this topic for the last 3000 years.

What is amazing is our resourcefulness. As soon as we admit that eating every dish of that damn Chinese self-serve buffet turns us into brainless oysters for the rest of the afternoon, we start constructing countermeasures.

I shall open at the afternoon break. Until then, let me die in my soy sauce.

Unit Test are for me the product of humble yet very sharp minds, who acknowledge their weakness but still want to get the job done, in the best possible way.

See it that way: we are tool builders. We don’t have claws or big furs, so we build tools to compensate. Writing tests is an answer to our daily stupidity.

The Beatitude Of The Fool

When I started doing tests, I was closer to the attitude of the rebel Teenager than the excited newbie: “Yeaaaah! Whatever. I still ship good code. Meh”.

But, as the test coverage grew, I started to notice an interesting pattern:

Customer requests feature X
I implement feature X
I don’t write any test, feeling confident. The day was sunny, my focus was Zen-like while writing the code
I ship the feature X
Customer gets back to me “Thanks Robin! X works great, however Y is broken!”
I’m sorry what? I dig in, and see the regression
I (finally) write a test, the test fails. I fix the bug and ship again

Rince and repeat. That feeling, between the “I’m sorry what?” and the understanding that by simply adding a couple of tests, the bug could have been prevented is priceless. It’s a mix of shame and anger.

After a couple of iterations, I systematically wrote a test for any feature. And that my friends, was a pure Dopamine shot.

We have a great Tests Coverage. The project is bulletproof!

Now, I see my tests as a handcrafted parachute. I can code and feel the bliss of the Fool. I can be Human, stupid, tired, and my tests have my back. Oh, what a feeling!

Side Effects and Cult

A beautiful side-effect of testing your program, is that it puts you in the shoes of the user of your API. You write an incredibly efficient program, great! How usable it is?

Remember, you don’t have the time to write tests, do you think your colleague will have the time to understand your crazy Logorrhea of functions, variables and convoluted classes? Of course not!

Testing gives you a feedback on how your API feels. This is extremely useful, because you won’t be able to know that before having to modify it again.

However, I want to add a big nuance:

Not everything should be tested

You know how it’s called when someone tells you “If you don’t test X, you’re worthless”? Religion Fever.

In my humble opinion, it’s as stupid to refuse to test anything than to insist on testing absolutely everything.

Our brother Robin did not write a test for the project POC-to-be-dropped-and-rewritten-anyway. He shall be excommunicated from the Church Of The Right Software.

Some situations makes the tests impossibly hard to write or maintain.

In many cases, I don’t write any UI test. Why? Because I have a limited time, and I honestly care little about UI testing. It makes perfect sense for huge projects, with very strict UI designs.

I see testing more as a state of mind, a humbling affirmation of our imperfection and a celebration of our imagination to face it.

As with any craft, it has to be practiced and repeated. Sometimes your tests will be useless and badly written. Other times it will fit perfectly to your project.

It takes time, but it’s worthwhile. You’ll thank yourself for doing it, trust me.

Powerpoint and Chickens

robin@gryt.io (Robin Penea) — Thu, 20 Dec 2018 15:32:12 +0100

Do you remember that day — probably a rainy one — when you sat in a conference room? Your heart was filled with eagerness to dive into the speaker’s mind. You even prepared by documenting about the topic, to fully comprehend the genius striding in front of you.

The common purpose

And then, as the drama unfolded in the room and the rain kept pouring outside, this slide came up:

Here's a short summary of my ideas, in 5 small bullet points.

“Oh dear”, you whispered, “Not again… Not this Powerpoint presentation…”. You know it when you see it. The Powerpoint to end all Powerpoints. The one with slides so dense, that a pair of opera-binoculars should be provided on each chair.

The mandatory tool to brain numbing presentations.

Yes my friend, you’re about to spend a long, excruciating hour. You’ll watch the speaker spit 3 zillion data per minute, while your brain turns into a mishmash of tears, agony, and forgotten eastern curses inherited from your mother side. Who would have guessed that these memories could be retrieved? Bonkers!

I call this phenomenon the Chicken Hypnosis, or the Gallus Gallus Apathy — Latin makes things so chic —. We have all seen dozens of Powerpoint presentations where you ask yourself: What is the point of this Powerpoint? To help the speaker or to hypnotize chickens, namely, the audience?

The real purpose

Much ink has been spilled on the Powerpoint issue: Back in 2003, the NASA pointed that Powerpoint makes you dumb, some physicists chose to ban Powerpoint altogether and searching for “Powerpoint hate” on Google yields 24 400 000 results.

But still, (almost) everybody uses a form of Powerpoint to do a presentation. It can’t be for nothing! Indeed, I believe that a Powerpoint has a great purpose: to support the speaker. To provide some anchor, in the turmoil of a long explanation.

A Powerpoint purpose is 2-folded:

Condense information in a digestible format to sum important points
Provide multimedia content to animate the presentation

But, what really matters is the explanation of the speaker. Filling slides up to death is an innocent act of laziness, not malevolence.

How did we get there?

Tool & User

I think Powerpoint is a very efficient tool. Without any prior knowledge, you can put together titles, bullet points and incredible-yet-utterly-useless animations.

However, who is using Powerpoint? For the vast majority, people who are not professional speakers (me too!). They are business men, developers, physicists, or anything that is not directly centered on a Speaker / User Experience. For them, making a presentation is mandated by their job, but they surely didn’t study to do presentations or animate conferences.

Mix the ease of use of Powerpoint with the lack of interest of its users, and you get this new Super-Villain: The Destroyer Of Minds (DOM for the closest friends).

Misuse of the Tool

From here, the resulting presentation has many chances of being failed. We already covered the densely-packed slides, but there’s another killer hiding in plain sight: The lifeless presentation.

Will he finish the talk? Will he jump? Will the restaurant still have my favorite Cheesecake?

Everything feels empty. There can be a lot on each slide… Or not. The speaker is slow and monotonous. Add a last slide, and the abyss will swallow you in the eternal bliss of infinite boredom.

In this case, the Powerpoint has taken the driver seat. The trigger to speak is the “Next Slide Button” — not what the speaker intends to say.

Down the Rabbit Hole

It gets even worse. To be so easy to use, Powerpoint has a killer-feature: The Bullet Point.

It might seem innocuous, but I think it’s exactly the reason for which presentations get such a bad press: it transforms complex ideas into a sequence of bullet points, waiting to be unstacked, one by one.

A presentation can have multiple purposes: make you think, spark a heated debate, provide a different perspective on a known issue.

A set of bullet points is a drowning of creativity. Said plainly, you cannot express complex ideas with bullet points. It’s like describing a car with karate moves: it’s not meant for that.

"Here are the seats, and you can lower the windows like so." — Damn, this picture could almost make the opposite point! Note to self: choose a worse karate picture.

Still, why do we cram so much data in our slides? Because we have the illusion that the audience must know everything. WRONG! 90% of the time, you are presenting your deep work to people who might not have the slightest idea of your passion.

They are just curious / forced to be here / bored / sitting in the wrong conference room.

Oh dear, this is about the Java programming language? I’m just a Peruvian Coffee Beans aficionado!

As you can see, the Abstract Factory Pattern makes it so easy to spawn new objects.

How should we approach it?

You might yell at me:

“Very well then, should I empty my slides? Fill them? Simplify everything? Put only complex diagrams?”

Breath. I understand. You think about that presentation you already hated even before finishing it. We all have been culprit of such an abomination.

I will calmly answer with 2 questions: Who is your audience? What are your constraints?

If you can’t answer, the presentation is already doomed. Call it a day and start doing some improv class, you’ll have better chances.

Is your audience young children, discovering science? International astrophysists waiting for your Boson revelation? Do you have 20 mins or 2 hours? Can you draw something while talking? Is it online or in a real room, with real people?

They told me that it will be in Sydney's Opera with Kung-Fu Senseis. Something's Wrong.

This is going to determine the shape and content of your presentation. Who cares if you used a distributed micro-service architecture if your audience can’t tell the difference between Internet and Google Chrome?

If the answer to these questions keeps Powerpoint in the race, I can see 2 possible presentation general “shapes”.

TBP aka The Big Presentation

You give an important talk, on a topic you have been working on for months / years. By God, reduce the load per slice, add schemas and animations to make it easier to grasp the idea. Yes, use bullets point to sum up and the end of a section, but not to articulate a complex topic.

Your hard work deserves a proper presentation. It would be a shame to flush your years-long sweat in the toilet of “Slides Mediocrity”. Your audience will probably not have the same depth as you do. And if they do, the questions is the perfect time to dig in.

If you already know you’re dealing with specialists, add references, data, but remember: YOU are the reason they’re wasting their life in this small room for an hour. Not your slides. Not your fancy animations.

Machine-gun Slides

If you have (like myself in recent instances) have to produce hundreds of slides on a topic, you have to be efficient rather than beautiful.

Getting your point across without spending 2 hours on each Powerpoint can make a difference. Again, know your constraints and deal with it.

Some people have such a mastery of the content that the Powerpoint becomes a character of the presentation. For example, Larry Lessig, with his “Lessig Method” is known to fire many, many slides for a single presentation. And it works!

A tool — nothing more, nothing less —

Everyone has a love / hate relationship with Powerpoint. In the end, it’s just a tool. Like any tool, it can be properly used and misused.

Because it’s easy to start with, you can dump your Ph.D thesis in your slides. Job done, back to real work. Not so fast!

Your presentation is a part of your work. Don’t spoil it by doing a cheap stunt. You deserve better.

The Gallus Gallus Apathy can, and should be prevented! To arms my fellow Powerpointers!

Powerpoint is a tool, not the tool. When you only have a hammer, every problem looks like a nail.

Surrendering is transforming yourself into a nail, while Powerpoint is happily smashing on you.

Surrendering, is transforming your audience into chickens.

You’re not a Nail nor a Chicken. You’re a Human. Embrace it.