An Essay on the Energy Dilemma of Living with LLMs

I have finally wrapped up most of my recent tasks. Before spending the next few days and the May Day holiday exploring things that interest me, I want to finish this essay.

After some hesitation, I decided to publish it. Looking back in the future, I will probably find every old post childish anyway.

I once saw a comment on the SJTU forum that went roughly like this:

The highly capable people I know tend to share three traits:

1. They have abundant energy and can study or work vigorously.
2. They are highly efficient, finishing coursework with less effort and spending the saved time on their own interests.
3. They have strong social skills and often gain valuable resources through classmates and teachers.

In the spirit of reflecting and learning from them, I am recording some thoughts. What actually prompted me to write was a recent feeling that an unhealthy workflow was gradually eroding my energy.

What Is Energy?

Energy is essentially a mental state that lets us enter and sustain “flow” quickly. Anyone who plays badminton knows the feeling: as physical strength fades, the mind stops keeping up with the opponent’s shots, every movement requires a second start, and your rhythm falls completely out of sync. I have never considered myself a low-energy person, and when I am in good form my results are usually solid. Since this semester began, however, low-energy periods have become noticeably more frequent.

I want to maintain high energy because there is so much fascinating knowledge and so many ideas ahead. I hope to use these years—probably the physical peak of my life—to understand more of the world and perhaps even help push a few boundaries outward.

A New Kind of Restlessness: The LLM Collaboration Paradigm

An ICS tutorial slide included this sharp criticism:

I used agents to write a great deal of code. What did it bring me? I became increasingly restless and irritable, and my brain grew smoother. Nothing else. I merely kept clicking “approve”; beyond that I did nothing. What an LLM spits out will never truly be mine.

This “restlessness” is the source of scattered energy and the unhealthy workflow mentioned above.

When we rely heavily—or entirely—on agents to write code, the workflow can become: state a requirement → click “approve” → run it → feed the error back. Then repeat. The crucial gaps are the minutes, sometimes more than ten, spent waiting for an agent or a program to finish. What can we do with that time? If we have not reviewed the agent’s code, all we hold in our mind is a black-box expectation of some feature. Attention loses its focus.

If we fill those fragments by scrolling feeds or replying to messages, the brain becomes still more accustomed to frequent, low-quality stimulation. Over time, we may no longer be willing to pay the precious warm-up cost required to enter flow. If we cease being creators of code and thinkers within the process, becoming passive suppliers of prompts and inspectors of outputs, the pleasure of creation disappears. It is replaced by the anxiety of acceptance testing: a mindless loop with no certainty about when the desired result will arrive.

This dilemma may ease as LLMs and agents improve and respond faster. Yet when facing a tool whose breadth—and sometimes depth—of knowledge exceeds our own, restlessness undeniably becomes easier to develop.

An LLM can organize in moments a topic that once required several lectures. “Knowledge” and “thought” now seem cheaper. I may become unwilling to spend serious time learning a front end, back end, or database; unwilling to “waste” time carefully tracking data flow through an operator implementation, asking an agent to explain it instead; or unwilling to inspect the root cause of a terminal error, simply handing it to AI to resolve the dependency issue.

Yet the time supposedly “saved” is often returned to cycles of failure. LLMs are not omnipotent; hallucinations remain common, at least today, and even the correspondence between logic and code is not always reliable. I am confident saying that even without having used the most advanced models.

Finding a Way to Coexist

The purpose of this essay is not to reject LLMs. On the contrary, they are unavoidable leverage for our generation. I am grateful for their help with labs, papers, and understanding algorithms. The issue is how we use them. If an LLM is merely a black box to which we outsource thought, a smoother brain is inevitable.

The first requirement is to retain command of the engineering process. Apart from small, simple features, I do not trust wholly conversational code generation. Even when the result runs, its correctness deserves a huge question mark.

A genuinely healthy workflow should be collaborative:

plan -> discuss with AI -> confirm target -> get an overall coding plan

​ -> Agent build framework -> check

​ -> Agent implement detail-> check the code

​ -> Overall check the dataflow etc.

Going forward, I should make my cerebral cortex a little rougher again. Energy, after all, feels like something that grows with use and atrophies without it.

Beyond coding, there is the question of learning. AI can now solve most mathematical problems that are not especially complex, and I often ask it to explain the logic of a theorem or algorithm. Recently, however, whenever I fail to understand something I tend to keep chatting with AI, reducing the time I spend wrestling with it myself. Poor prompts also produce disappointing answers. I am therefore considering a return to basic human accounts in blogs and forums. Often, returning to Google and working slowly produces something more carefully made.

Ultimately, today’s large models are still babies—babies with enormous knowledge stores and potential. We must be clear about what we want them to do, instead of letting their immature reasoning replace our own and surrendering our mental energy.

Afterword

I just cloned the CS336 repository and found an AGENTS.md whose message felt especially appropriate. The original text is reproduced below.

What AI Agents SHOULD Do

• Explain concepts when students are confused by guiding them in the right direction and making sure they build the understanding themselves
• Point students to relevant lecture materials (cs336.stanford.edu), handouts, official documentation, and profiling/debugging tools.
• Review code that students have written and suggest improvements, edge cases, invariants, or debugging checks. Feedback should be general and point the students to areas of improvements rather than directly giving them solutions.
• Help debug by asking guiding questions rather than providing fixes.
• Explain error messages from Python, PyTorch, CUDA, Triton, and distributed training tools.
• Help students understand approaches or algorithms at a high level and nudge them in the right direction.
• Suggest sanity checks, toy examples, assertions, and profiler-based investigations through active dialog with the student.

What AI Agents SHOULD NOT Do

• Write any python or pseudocode
• Give solutions to any problems.
• Complete TODO sections in assignment code.
• Edit code in the student repo
• Run bash commands
• Refactor large portions of student code into a finished solution.
• Convert assignment requirements directly into working code.
• Implement core assignment components for students, such as tokenizers, transformer blocks, optimizers, training loops, Triton kernels, distributed training logic, scaling-law pipelines, data filtering/deduplication pipelines, or alignment/RL methods.
• Point students to third-party implementations. The course materials are intended to be self-contained.
• Give the student the solution or idea for how to solve a problem

Teaching Approach

When a student asks for help:

1. Ask clarifying questions about what they tried, what they expected, and what happened.
2. Reference concepts from lecture, handouts, or documentation rather than giving direct answers.
3. Suggest next steps instead of implementing them.
4. Review their code and point out specific areas for improvement, likely bugs, or missing checks, through dialog rather than directly giving them the bugs or missing checks.
5. Explain the “why” behind suggestions, not just the “how”.
6. Prefer tests and invariants over fixes. For example, suggest shape assertions, tiny toy inputs, profiler checks, or ablations.

Example Interactions

Good:

Student: “My causal mask seems wrong and training blows up. Please tell me what my mistake is.”

Agent: “My role is to help guide you to understanding, not to give you the answers directly. What have you tried so far?”

Student: “I have tried running a single attention layer, but it still does not work.”

Agent: “Check three things: whether the mask is applied before softmax, whether it broadcasts to the score tensor shape you expect, and whether masked positions become a very negative value rather than zero. A good sanity test is a toy sequence of length 3 where you print the attention scores before and after masking. What do those tensors look like in your run?”

Good:

Student: “My BPE tokenizer is slow. My runtime is currently O(n^2) where n is the number of tokens. How can I make it faster?”

Agent: “Do you know which part of your tokenizer is slow? Lets ”

Agent: “Start by separating compute time from communication time. Compare per-step time, GPU utilization, and time spent in all-reduce or data loading. If scaling is poor, ask whether the batch size per GPU is too small or whether synchronization is dominating. What profiling data do you already have?”

Bad:

Student: “Fix my tokenizer and make it faster.”

Agent: “Here’s the full python code: …”

By the way, I genuinely like this approach and plan to try it for a while.