LLMs can be exhausting

Source: Hacker News

Some days I get in bed after a tortuous 4‑5 hour session working with Claude or Codex wondering what the heck happened. It’s easy to blame the model—there are so many options to choose from:

• They’re dumbing down the model to save money.
• Context rot!
• Codex/Claude Code/[insert harness] is getting bloated.

It’s not uncommon for me to come back to the problem the next day, my own context window cleared from rest, and find a fast and fulfilling path forward with the help of the LLM. What’s going on?

I’m tired & experiments are too slow

As I get more tired, the quality of my prompts degrades

If I am becoming mentally fatigued, I write worse prompts, and because of that the AI does a worse job. For example, I kick off a somewhat meaty prompt (after 30 % of context was used to align with the AI on the problem), realize right after submitting that I missed some key context, interrupt the LLM, provide the missing context, and then have it proceed. Interrupting Claude Code or “steering” in Codex leads to worse outcomes.

Feedback loop is too slow and context is bloated

Some of the work I’m doing right now requires parsing large files. Bugs in that parsing logic need to be worked through with the LLM. Every tweak requires re‑parsing, which is a slow process—I liken it to a slot machine that takes 10 minutes to spin. By the end of the parsing job, the LLM is close to its context limit, which leads either to a very dumb AI or an AI that pretends to know what’s going on with the recent experiment.

The happy path with AI

Avoiding the doom‑loop psychosis caused by bad prompting

If I reach the point where I am not getting joy out of writing a great prompt, that’s the first signal to take a break. When I’m half‑assing it, being short, interrupting, and getting frustrated, I need to step away.

Metacognition is required: am I being less descriptive because I haven’t actually thought through the problem and I’m hoping the AI will fill the gaps? That trap is seductive. AIs are getting good at filling undefined requirements, but they’re not perfect yet.

Sometimes I write a prompt with so much clarity about the desired end‑state that I’m already celebrating the result when I submit it, because I know the AI will crush it. That feeling of confidence is what I should look for in every prompt. If the feeling is uncertainty or impatience, the prompt is unlikely to pan out.

Recognizing slow feedback loops and making them the problem

In the parsing problem mentioned above, the feedback loop was painfully slow. I want my “slot machine” to take seconds or minutes, not 15–30 minutes. In these cases I start a new LLM session, lay out the problem with a focus on feedback‑loop speed, express a desire for a sub‑5‑minute loop, give an example of a failure case, and ask the model to reproduce that failure as quickly as possible. It starts to sound familiar… TDD anyone?

I’ve always been a scrappy engineer. I write tests, but I’m reluctant to create elaborate test cases or integration tests for bespoke problems because they feel time‑consuming. Working with an LLM changes that calculus. If you give the model clear success criteria—e.g., “Reproduce this specific failure case and ensure the execution time is under 5 minutes. Feel free to experiment with optimizations or omit unnecessary pieces”—the AI will not only reproduce the problem (perhaps slowly the first time) but also suggest levers for a faster feedback cycle. A faster feedback cycle consumes less context and makes the LLM smarter, saving hours of debugging time.

Conclusion

When I am exhausted from working with an LLM, it might actually be a “skill issue.” I need to recognize when I’m tired and entering the doom‑loop psychosis. Cognitive outsourcing of requirements is seductive, but it’s a trap. If I’m not enjoying the act of writing the perfect prompt and I’m not confident I’ll get a result I’m at least 95 % happy with, I need to take a break or reconsider whether I’ve truly thought through the problem. If things are moving slowly and context fills up too quickly, I should make that the problem to solve: find a path, with the help of the LLM, to iterate faster and use less context.