Hacker News Reader

Comment by ritzaco | Hacker News Reader

This seems like a really bad idea. Agents need to adapt to get good at using tools designed for humans (we have a lot), or use tools specifically designed for agents (soon we will have lots).

But to make your tool behave differently just causes confusion if a human tries something and then gets an agent to take over or vice versa.

View on HN

On the other hand, if you want to make your tool detect an agent and try a little prompt injection, or otherwise attempt to make the LLM misbehave, this seems like an excellent approach.

In other words, a supply chain attack? Let's call it what it is.

I think the term "supply chain attack" is frequently overused, and if I were feeling cantankerous, I might split hairs and argue that I was framing it more as a "watering hole attack" instead. But I agree that it could also be framed as a "supply chain attack", and you seem to have correctly realized that I was suggesting this was an excellent approach to either attack people using LLMs connected to agentic tooling or to render your gadget incompatible with such usage, if that was your goal.

I do not think it's a particularly good way to assist such users.

This seems like a really good idea for projects that reject AI-written code, to detect and early-fail in such environments.

I also don't see how this requires heuristics, but usecases do exist; eg I set `CLAUDE`, so that a git hook can mark vibe commits -- a prompt would be a waste of tokens and would introduce non-determinism, and MCP is yet another dependency that can get ignored in favour of the CLI equivalent anyway.

Tools can maintain consistent interfaces while still providing agent-aware optimizations through metadata or output formatting that doesn't disrupt the human experience.

Reply on news.ycombinator.com