MCP as an env-var ;)
LLM=True
111–120 of 155 posts
Re: LLM=True
#112This seems like a really solid idea: using an environment variable in command line tools and small apps to control output for AI vs. human digestion. Even given efficient attention mechanisms, slop tokens in the context window are bad.
I also like a discussion in this thread: using custom tools to reduce the frequency of tool calls in general, that is, write tool wrappers specific for your applications or agents.
Re: LLM=True
#113Earlier quoted context omitted.
That's a good call. It's a big problem for JSON configs given pure JSON's strict no-comments policy. I like tools that let you use .js or better yet .ts files for config.
Or consider jsonc - json with comments - or jwcc - which is json with comments and trailing commas to make life a little easier. https://jsonc.org/ https://nigeltao.github.io/blog/2021/json-with-commas-commen... There are a lot of implementations of all of these, such as https://github.com/tailscale/hujson
I like this idea a lot, and pushed for json5 at a previous job, but I think there are a few snags:
- it's weird and unfamiliar, most people prefer plain JSON
- there are too many competing standards to choose from
- most existing tools just use plain JSON (sometimes with support for non-standard features, like tsconfig allowing trailing commas, but usually poorly documented and unreliable)
Much easier just to make the leap to .ts files, which are ergonomically better in almost every way anyway.
Re: LLM=True
#114Earlier quoted context omitted.
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.
"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.
Re: LLM=True
#115Earlier quoted context omitted.
cc is the C compiler. Please don't overload that term with trendy LLM products. You can use the full name.
Surely any distinguished connoisseur of terminology gatekeeping such as yourself is able to distinguish between 'cc' and 'CC'. My terminal is able to spot the difference, you should be able to as well.
CC is an environment variable / internal variable used by most build tools to identify the current C compiler. cc is the standardized name of the executable, now usually an alias for gcc.
Both CC and cc refer to the C compiler, in slightly different ways.
Re: LLM=True
#116Many unix tools already print less logging when used im a script, ie. non-interactively. (I don't know how they detect that.) For example, `ls` has formatting/coloring and `ls | cat` does not. This solution seems like it would fit the problem from the article?
Re: LLM=True
#117Earlier quoted context omitted.
Software folks love over-engineering things. If you look at the web coding craze of a few years ago, people started piling up tooling on top of tooling (frameworks, build pipelines, linting, generators etc.) for something that could also be zero-config, and just a handful of files for simple projects. I guess this happens when you're too deep in a topic and forget that eventually the overhead of maintaining the tooli…
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.
Re: LLM=True
#118I've been using CODING_AGENT=true
Re: LLM=True
#119Earlier 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…
The “a token is a token” effect makes LLMs really bad at some things humans are great at, and really good at some things humans are terrible at.
For example, I quickly get bored looking through long logfiles for anomalies but an LLM can highlight those super quickly.
Re: LLM=True
#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 consumed.