Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LLM=True

blog.codemine.be

Post reply on HN
Print view View original

21–30 of 155 posts

Re: LLM=True

#21

Post by canto »

outime wrote: post #10
canto wrote: post #7

This is merely scratching the surface. LLMs (Claude Code in particular) will explicitly create token intensive steps, plans and responses - "just to be sure" - "need to check" - "verify no leftovers", will do git diff even tho not asked for, create python scripts for simple tasks, etc. Absolutely no cache (except the memory which is meh) nor indexing whatsoever. Pro plan for 20 bucks per month is essentially worthles…

>LLMs (Claude Code in particular) will explicitly create token intensive steps, plans and responses - "just to be sure" - "need to check" - "verify no leftovers", will do git diff even tho not asked for, create python scripts for simple tasks, etc. Absolutely no cache (except the memory which is meh) nor indexing whatsoever. Most of these things can be avoided with a customized CLAUDE.md .

Not in my projects it seems. Perhaps you can share your best practices? Moreover, avoiding these should be the default behaviour. Currently the default is to drain your pockets.

P.S CLAUDE.md is sometimes useful but, it's a yet another token drain. Especially that it can grow exponentially.

Re: LLM=True

#22

Post by Planktonne »

This all seems like a lot of effort so that an agent can run `npm run build` for you.

I get the article's overall point, but if we're looking to optimise processing and reduce costs, then 'only using agents for things that benefit from using agents' seems like an immediate win.

You don't need an agent for simple, well-understood commands. Use them for things where the complexity/cost is worth it.

Re: LLM=True

#23

Post by vidarh »

Rather than an LLM=true, this is better handled with standardizing quiet/verbose settings, as this is a question of verbosity, where an LLM is one instance where you usually want it to be quieter, but not always.

Secondly, a helper to capture output and cache it, and frankly a tool or just options to the regular shell/bash tools to cache output and allow filtered retrieval of the cached output, as more so than context and tokens the frustration I have with the patterns shown is that often the agent will re-execute time-consuming tasks to retrieve a different set of lines from the output.

A lot of the time it might even be best to run the tool with verbose output, but it'd be nice if tools had a more uniform way of giving output that was easier to systematically filter to essentials on first run (while caching the rest).

Re: LLM=True

#24

Post by teekert »

Planktonne wrote: post #22

This all seems like a lot of effort so that an agent can run `npm run build` for you. I get the article's overall point, but if we're looking to optimise processing and reduce costs, then 'only using agents for things that benefit from using agents' seems like an immediate win. You don't need an agent for simple, well-understood commands. Use them for things where the complexity/cost is worth it.

But those simple and well understood commands can be part of a huge workflow the LLM embarks on.

Re: LLM=True

#26

Post by vidarh »

vorticalbox wrote: post #4

could we not instruct the LLM to run build commands in a sub agents which could then just return a summary of what happened? this avoids having to update everything to support LLM=true and keep your current context window free of noise.

Make (or whatever) targets that direct output to file and returns a subset have helped me quite a bit. Then wrap that in an agent that also knows how and when to return cached and filtered data from the output vs. rerunning. Fewer tokens spent reading output details that usually won't matter, coupled with less context pollution in the main agent from figuring out what to do.

Re: LLM=True

#27

Post by lucumo »

> Then a brick hits you in the face when it dawns on you that all of our tools are dumping crazy amounts of non-relevant context into stdout thereby polluting your context windows.

Not just context windows. Lots of that crap is completely useless for humans too. It's not a rare occurrence for warnings to be hidden in so much irrelevant output that they're there for years before someone notices.

Re: LLM=True

#28

Post by iainmerrick »

syhol wrote: post #17
thrdbndndn wrote: post #11

Something related to this article, but not related to AI: As someone who loves coding pet projects but is not a software engineer by profession, I find the paradigm of maintaining all these config files and environment variables exhausting, and there seem to be more and more of them for any non-trivial projects. Not only do I find it hard to remember which is which or to locate any specific setting, their mechanisms…

You start with the cleanest most minimal config you can get away with, but over the years you keep adding small additions and tweaks until it becomes a massive behemoth that only you will ever understand the reasoning behind.

Right, and then when you don't work on it for 6 or 12 months, you come back and find that now you don't understand it either.

Re: LLM=True

#30

Post by [deleted] »

lucumo wrote: post #27

> Then a brick hits you in the face when it dawns on you that all of our tools are dumping crazy amounts of non-relevant context into stdout thereby polluting your context windows. Not just context windows. Lots of that crap is completely useless for humans too. It's not a rare occurrence for warnings to be hidden in so much irrelevant output that they're there for years before someone notices.

[deleted]
Post reply on HN