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

131–140 of 155 posts

Re: LLM=True

#131

Post by SubiculumCode »

rel_ic wrote: post #120

> The environment wins (less tokens burned = less energy consumed) This is understandable logic, but at a systemic level it's not how things always go. Increasing efficiency can lead to increased consumption overall. You might save 50% in energy for your workload, but maybe now you can run it 3 times as much, or maybe 3 times more people will use it, because it's cheaper. The result might be a 50% INCREASE in energy…

This is the standing reason that is always given for why we must all sit in freeway traffic clogs, and I think it's B.S., because it assumes that there are viable alternatives available in near-medium term, but that isn't always the case. The alternative to freeways that are supposed to compensate is a joint combination of denser housing and mass transit, which in California, is not happening at all...zoning laws and the slow pace of building mass transit due to regulation slow-down and the need to service urban sprawl, prevent that solution from relieving traffic pressure. Don't speak of busses, because taking two hours to get to work is not better than one hour. So..the freeways stay the same number of lanes and my commute time continues to grow, and I am tired of hearing it is for the best.

So yes, lower LLM costs would probably lead even more LLM usage and greater energy expenditures, but then again, so does having a moving economy, and all that comes with that.

Re: LLM=True

#132

Post by simsla »

esafak wrote: post #128
skerit wrote: post #54

> 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. I've found that letting the agent write its own optimized script for dealing with some things can really help with this. Claude is now forbidden from using `gradlew` directly, and can only use a helper script we made. It clears, recompiles…

How is it forbidden? I tell agents to use my wrappers in AGENTS but they ignore it half the time and use the naked tool.

Permissions scoping

Re: LLM=True

#133

Post by esafak »

simsla wrote: post #132
esafak wrote: post #128

Earlier quoted context omitted.

How is it forbidden? I tell agents to use my wrappers in AGENTS but they ignore it half the time and use the naked tool.

Permissions scoping

Then they attempt to download the missing tool or write a substitute from scratch. Am I the only one who runs into this??

Re: LLM=True

#134

Post by co_king_5 »

quintu5 wrote: post #57
skerit wrote: post #54

> 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. I've found that letting the agent write its own optimized script for dealing with some things can really help with this. Claude is now forbidden from using `gradlew` directly, and can only use a helper script we made. It clears, recompiles…

This has been my exact experience with agents using gradle and it’s beyond frustrating to watch. I’ve been meaning to set up my own low-noise wrapper script. This post just inspired me to tackle this once and for all today.

[dead]

Re: LLM=True

#135

Post by Squid_Tamer »

esafak wrote: post #128
skerit wrote: post #54

> 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. I've found that letting the agent write its own optimized script for dealing with some things can really help with this. Claude is now forbidden from using `gradlew` directly, and can only use a helper script we made. It clears, recompiles…

How is it forbidden? I tell agents to use my wrappers in AGENTS but they ignore it half the time and use the naked tool.

If you get desperate, I've given my agent a custom $PATH that replaces the forbidden tools with shims that either call the correct tool, or at least tell it what to do differently.

~/agent-shims/mvn:

    #!/bin/bash
    echo "Usage of 'mvn' is forbidden. Use build.sh or run-tests.sh"
That way it is prevented from using the wrong tools, and can self-correct when it tries.

Re: LLM=True

#136

Post by dcrazy »

kimixa wrote: post #100
majewsky wrote: post #96

Earlier quoted context omitted.

> Claude is now forbidden from using `gradlew` directly, and can only use a helper script we made. It clears, recompiles, publishes locally, tests, ... all with a few extra flags. And when a test fails, the stack trace is printed. I think my question at this point is what about this is specific to LLMs. Humans should not be forced to wade through reams of garbage output either.

Humans have the ability to ignore and generally not remember things after a short scan, prioritize what's actually important etc. But to an LLM a token is a token. There's attempts at effectively doing something similar with analysis passes of the context - kinda what things like auto-compaction is doing - but I'm sure anyone who has used the current generation of those tools will tell you they're very much imperfect…

Isn’t the purpose of self attention exactly to recognize the relevance of some tokens over others?

Re: LLM=True

#137

Post by rokob »

CuriouslyC wrote: post #117
bonesss wrote: post #61

Earlier quoted context omitted.

I don’t think those web tooling piles are over-engineered per se, they address huge challenges at Google and Facebook, but the profession is way too driven by hype and fashion and the result is a lot of cargo culting of stuff from Big Dogs unquestioningly. Wrong tooling for the job creates that bubble of over complicated app development. Inventing GraphQL and React and making your own PHP compiler are absolutely insa…

Not sure why you lumped React in there. Hack is loopy, and GraphQL was overhyped but conditionally useful, but React was legitimately useful and a real improvement over other ways of doing things at the time. Compare React to contemporary stuff like jQuery, Backbone, Knockout, Angular 1.x, etc.

I agree with you very much, if what you are building actually benefits from that much client side interactivity. I think the counterpoint is that most products could be server rendered html templates with a tiny amount of plain js rather than complex frontend applications.

Re: LLM=True

#138

Post by Planktonne »

teekert wrote: post #24
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.

Again, if your priority is to minimise costs, then not forcing every part of that huge workflow through the agent is a good start.

Re: LLM=True

#139

Post by skydhash »

sdsd wrote: post #124
skydhash wrote: post #121

Earlier quoted context omitted.

There’s a function isatty that detect if a file descriptor (stdout is one) is associated with a terminal https://man.openbsd.org/man3/ttyname.3 I believe most standard libraries has a version.

I was about to comment the same thing. Usually I don't call the function directly, but via the tty command in my shell scripts: if tty -s; then echo "Standard input is a TTY (interactive mode)." else echo "Standard input is not a TTY (e.g., piped or redirected)." fi Now I wonder how _isatty_ itself detects whether a file descriptor is associated with a terminal!

In OpenBSD, with the fcntl system call

https://github.com/openbsd/src/blob/master/lib/libc/gen/isat...

https://man.openbsd.org/fcntl

https://github.com/openbsd/src/blob/master/sys/sys/fcntl.h

https://github.com/openbsd/src/blob/ba496e5267528b649ec87212...

https://github.com/openbsd/src/blob/ba496e5267528b649ec87212...

Re: LLM=True

#140

Post by sgarland »

adwn wrote: post #114
sgarland wrote: post #95

Earlier quoted context omitted.

Also becomes rapidly apparent that most modern tooling takes an extremely liberal view of logging levels. The fact that you’ve successfully processed a file is not INFO, that’s DEBUG.

"Finished conversion of xyz.mp3 to xyz.ogg" is valuable progress information to a regular user, not just to developers, so it belongs in INFO, not DEBUG.

I suppose this is subjective, but I disagree. If I want to know the status of each item, I’d pass -v to the command. A simple summary at the end is sufficient; if I pass -q, I expect it to print nothing, only issuing a return code.
Post reply on HN