Live data from Hacker News

LLM=True

blog.codemine.be

91–100 of 155 posts

Re: LLM=True

#91
For Claude the most pollution usually comes from Claude itself.

It's worth noting thet just by setting the right tone of voice, choosing the right words, and instructing it to be concise, surgical in what it says and writes, things change drastically - like night and day.

It then starts obeying, CRITICALs are barely needed anymore and the docs it produces are tidy and pretty.

Re: LLM=True

#92
Seeing a JSON configuration file that stores environment variables makes me want to cry. Just to think that somewhere, somehow, it's going to launch an entire JavaScript VM (tens of megabytes) just to parse a file with 12 lines in it, then extract from a JavaScript the fields, munge it, eventually turn into more or less an array of VAR=val C strings which get passed to a forked shell....

Re: LLM=True

#93
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…

I assume you're using Opus.

I'm on the Pro plan. If I run out of tokens, which has only happened 2 or 3 times in months of use, I just work on something else that Claude can't do, or ...write the code myself.

You do have to keep a close eye on it, but I would be doing that anyway given that if it goes haywire it's wasting my time as well as tokens. I'd rather spend an extra minute writing a clearer prompt telling it exactly what I want it to do, than waste time on a slot machine.

Re: LLM=True

#94
post #92

Seeing a JSON configuration file that stores environment variables makes me want to cry. Just to think that somewhere, somehow, it's going to launch an entire JavaScript VM (tens of megabytes) just to parse a file with 12 lines in it, then extract from a JavaScript the fields, munge it, eventually turn into more or less an array of VAR=val C strings which get passed to a forked shell....

Granted, I have no idea how Claude Code operates internally, but if it’s already running in a JS VM, can’t it read the file itself?

Re: LLM=True

#95
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.

The old unix philosophy of "print nothing on success" looks crazy until you start trying to build pipes and shell scripts that use multiple tools internally. Also very quickly makes it clear why stdout and stderr are separate

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.

Re: LLM=True

#96
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…

> 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.

Re: LLM=True

#97
post #92

Seeing a JSON configuration file that stores environment variables makes me want to cry. Just to think that somewhere, somehow, it's going to launch an entire JavaScript VM (tens of megabytes) just to parse a file with 12 lines in it, then extract from a JavaScript the fields, munge it, eventually turn into more or less an array of VAR=val C strings which get passed to a forked shell....

Why do you presume it needs a JavaScript VM to parse JSON?

Re: LLM=True

#98
All of this because we only have stdout and stderr and nothing in between. I wish there was a stdlog or stddebug or something

Re: LLM=True

#99
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…

> 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.

Lots of tools have a --quiet or --output json type option, which is usually helpful

Re: LLM=True

#100
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…

> 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.

Post reply on HN