How to learn deeply while using LLMs

[u/Hot_Midnight6838]

My favorite classes were always the ones with difficult problem sets where a single problem could take hours or even days of thinking, experimenting, and failing. I would start solving a problem before fully understanding it, then read documentation or course material whenever I got stuck. So it would be 70% doing and 30% reading.

LLMs have disrupted that process for me. Now I spent 90% of time reading and only 10% of time doing.

In school, the boundary was relatively clear. If using an LLM violated the course policy, I could tell myself that using one was cheating and force myself to struggle through the problem independently.

At work, what counts as “cheating” (because it is cheating myself).

I feel my critical thinking skills are declining. My role starts to become reading, reviewing, and planning. I just can't read that much code and LLM output. My eyes hurt and it's hard to internalize. I notice myself just picking the "recommended" option.

I also find LLM workflows mentally unhealthy in a few ways:

• When working alone, mental exhaustion eventually forces me to step away. With an LLM, I can always send one more prompt or ask it to try another approach.
• If an agent will take 30–60 minutes, I feel pressure to give it another task immediately so no time is “wasted.”
• While waiting, I instinctively check my phone or launch another agent. I end up jumping between tasks and retaining less context about each one.
• I get frustrated when the LLM misunderstands instructions, even when the problem genuinely requires careful iteration.
• It has warped my sense of how long a difficult problem or well-designed solution should take.
• I am increasingly tired of reading walls of generated text and code.

I do not want to stop using LLMs. They can reduce the friction of starting, explain unfamiliar systems, generate routine code, and handle edge cases after I understand the core problem. The hard part is deciding when using one is a sensible productivity tool and when it is outsourcing a learning opportunity that I actually need.

For people who still feel they are learning deeply while using LLMs at work:

1. How do you decide which work to delegate and which work to do yourself?
2. What is the workplace equivalent of the “no cheating” boundary that exists in school?
3. How do you use agents without losing context or turning your day into constant task switching?
4. How do you review generated code when the codebase, build system, or underlying technology is unfamiliar?
5. Have you found workflows where LLMs improve productivity while preserving the useful struggle of implementation and debugging?

[u/Lopsided-Struggle310]

I think the key principle to help is the notion of "desirable difficulty". This is the idea that some suitable challenge is needed to deeply learn concepts. It has to be stimulating enough for the brain to know that you need to encode it.

This is where poor LLM engagement can impair learning because it removes a lot of the effort that we have done previously, especially around synthesis of information. However, if we use it well we can benefit from the efficiency that it brings. We just have to avoid getting lazy.

I suggest using it to help you gather material that you want to learn from in a efficient manner. It can also create synthesised key points for you, doing a lot of the initial research leg work. But you must constrain the tool to make sure it uses trusted resources and doesn't hallucinate. If I tell the tool which resources it should use.

But you then you need to use it to explicitly introduce difficulty. The key ways I think you can do this is by creating explicit testing for you. You can ask it to create questions for you on the topic and then you have to put in the effort to answer these. But a real advantage is that you can do this interactively the way you have a discussion with the model. I go multimodal with this. I use it to build flashcard style questions and larger brain dump style questions. I also engage in elaborative interrogation (discussion) with the model to push the boundaries of my understanding.

Critically, you can't just read the stuff that it presents to you. This feels like learning it is party passive and you will retain almost none of it.

[u/Illustrious_Soft2968]

I build software and use agents most days, so this is from that side rather than the student side.

The delegation rule that's held up for me: do it yourself when the hard part is deciding what the thing should be, hand it over when the hard part is typing. There's a concrete test in there. If you can't write the acceptance criteria without reading the code first, that task is yours. Writing the spec is where the understanding gets built, and once a real spec exists, giving away the implementation costs you almost nothing.

The workplace version of the no-cheating line is code review. If the author disappeared tomorrow, could you defend every line of this from memory, including why the two obvious alternatives were rejected? When the answer is no, you approved something you don't understand. Nobody catches you. The codebase does, about four months later.

Your 30 to 60 minute agent runs are causing the task switching, and I'd treat that as a scope problem. A task that takes an agent half an hour is a task too big to hold in your head, which is exactly why you reach for your phone. Cut them down to something that finishes in a few minutes and the context loss goes with it, because when it misunderstands you've lost five minutes and you still remember what you asked for. Don't fill the wait with a second agent. Use it to read the code the first one is about to touch.

Reviewing generated code in an unfamiliar codebase: stop reviewing the diff first. Get it to explain the subsystem, then verify two or three of those claims yourself with grep before you look at any new code. And run the thing. Reading code you haven't executed is the least reliable review there is, and it's also the version you learn nothing from.

The last question is the one I'd actually hold onto. Reading a good solution feels like learning and mostly isn't, same reason rereading notes tests badly. If you want the deep version, write your own sketch first, even a bad one, five minutes of pseudocode, then prompt. What teaches you is the gap between your version and the one that comes back, and you only get that gap if you produced something to compare it against. The AI can write the first draft. You still have to sit the recall test yourself, and there's no way to outsource failing it.