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

81–90 of 155 posts

Re: LLM=True

#81

Post by tovej »

m0rde wrote: post #34
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.

Feedback loops are important to agents. In the article, the agent runs this build command and notices an error. With that feedback loop, it can iterate a solution without requiring human intervention. But the fact that the build command pollutes the context in this case is a double-edge sword.

If you really need that, the easy solution here is to get a list of errors using an LSP (or any other way of getting a list of errors, even grep "Error:"), and only giving that list of errors to the LLM if the build fails. Otherwise just tell the LLM "build succeeded".

That's an extremely simple solution. I don't see the point in this LLM=true bullshit.

Re: LLM=True

#82

Post by cornyhorse »

mikkupikku wrote: post #69
ralfd wrote: post #65

Earlier quoted context omitted.

Similarly law professor Rob Anderson joked on X that llm hallucinated cases are good law: https://x.com/ProfRobAnderson/status/2019078989348774129 > Indeed hallucinated cases are "better law." Drawing on Ronald Dworkin's theory of law as integrity, which posits that ideal legal decisions must "fit" existing precedents while advancing principled justice, this article argues that these hallucinations represent emergent…

Seems naive. You can get an LLM to agree with almost anything if you say the right things to it, and it will hallucinate citations to back you up without skipping a beat. You can probably get it to hallucinate case law to legalize murder on Mondays.

[dead]

Re: LLM=True

#83

Post by kubanczyk »

troethe wrote: post #13

On a lot of linux distros there is the `moreutils` package, which contains a command called `chronic`. Originally intended to be used in crontabs, it executes a command and only outputs its output if it fails. I think this could find another use case here.

Useful enough to justify registering on HN. Thank you!

Re: LLM=True

#84

Post by gormen »

Most of what helps LLMs here is exactly what helps humans: less noise, clearer signals, predictable output.

Re: LLM=True

#85

Post by hrpnk »

Looks like the blog could use a HN=True. Hope the author won't get banned...

> Error: API rate limit exceeded for app ID 7cc6c241b6e6762bf384. If you reach out to GitHub Support for help, please include the request ID E9FC:7BEBA:6CDB3B4:6485458:699EE247 and timestamp 2026-02-25 11:51:35 UTC. For more on scraping GitHub and how it may affect your rights, please review our Terms of Service (https://docs.github.com/en/site-policy/github-terms/github-t...).

Re: LLM=True

#86

Post by Lerc »

I think the concept has value, but I think targeting today's LLMs like this is short sighted.

It's making what is likely to be a permanent change to fix a temporary problem.

I think the thing that would have value in the long term is an option to be concise, accurate, and unambiguous.

This isn't something that should be considered to be only for LLMs. Sometimes humans want readability to understand something quickly adding context helps a great deal here, but sometimes accuracy and unambiguity are paramount (like when doing an audit) if dealing with a batch of similar things, the same repeated context adds nothing and limits how much you can see at once.

So there can be a benefit when a human can request output like this for them to read directly. On top of this is the broad range of of output processing tools that we have (some people still awk).

So yes, this is needed, but LLMs will probably not need this in a few years. The other uses will remain

Re: LLM=True

#87

Post by MITSardine »

vidarh wrote: post #23

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 conte…

Yes, what's preventing the LLM from running myCommand > /tmp/out_someHash.txt ; tail out_someHash.txt and then greping or tailing around /tmp/out_someHash.txt on failure?

Re: LLM=True

#88

Post by avh3 »

hrpnk wrote: post #85

Looks like the blog could use a HN=True. Hope the author won't get banned... > Error: API rate limit exceeded for app ID 7cc6c241b6e6762bf384. If you reach out to GitHub Support for help, please include the request ID E9FC:7BEBA:6CDB3B4:6485458:699EE247 and timestamp 2026-02-25 11:51:35 UTC. For more on scraping GitHub and how it may affect your rights, please review our Terms of Service ( https://docs.github.com/en/…

Author here. Thanks for flagging. Let me look into it

Re: LLM=True

#89

Post by vidarh »

MITSardine wrote: post #87
vidarh wrote: post #23

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 conte…

Yes, what's preventing the LLM from running myCommand > /tmp/out_someHash.txt ; tail out_someHash.txt and then greping or tailing around /tmp/out_someHash.txt on failure?

There isn't really anything other than training, but they generally don't. You probably can get them to do that with some extra instructions, but part of the problem - at least with Claude - is that it's really trigger-happy about re-running the commands if it doesn't get the results it likes, assuming the results reflects stale results. Even with very expensive (in time) scripts I often see it start a run, pipe it to a file, put it in the background, then loop on sleep statements, occasionally get "frustrated" and check, only to throw the results away 30 seconds after they are done because it's made an unrelated change.

A lot of the time this behaviour is probably right. But it's annoyingly hard to steer it to handle this correctly. I've had it do this even with make targets where the makefile itself makes clear the dependencies means it could trust the cached (in a file) results if it just runs make . Instead I regularly find it reading the Makefile and running the commands manually to work around the dependency management.

Re: LLM=True

#90

Post by bool3max »

rustybolt wrote: post #70

Surprisingly often people refuse to document their architecture or workflow for new hires. However, when it's for an LLM some of these same people are suddenly willing to spend a lot of time and effort detailing architecture, process, workflows. I've seen projects with an empty README and a very extensive CLAUDE.md (or equivalent).

That could be because Claude offers a dedicated /init command to generate a CLAUDE.md if it doesn't exist.
Post reply on HN