1. The common (and correct) claim that software engineering is not just about writing code (counter argument, with time, AI will be able to take on planning, debugging. Counter counter argument: if you ever tried just do what customers ask, you will get conflicting requirements, humans will need to help AI make decisions, not implement them)
2. Related to the above, as long as a good software engineer + AI brings more ROI than a mediocre engineer + AI that brings more ROI than a random person + AI that brings more ROI than just AI, it will be economically wise to hire more good engineers to beat your competitors who just opted to save money and fired their engineering team. Salaries might go down but for top talent, eg imagine an “AI whisperer” that can not be a 10x engineer but a 1000x because they know how to get the most out of Claud code / cursor. They will be paid accordingly.
3. Jevons paradox - perhaps making software ubiquitous, cheaper to make, will actually make software engineers in larger demand
And so far it's 5.3% reduction in the spending of <16% of households on the drug for a total reduction of less than 1%. Compared to eg tariffs and general inflation, that's a bit hard to distinguish from noise.
There are other major factors also influencing grocery prices, such as tariffs. It may because that was are seeing a significant influence on price, but one that is counteracted by other influencers.
If they aren't competing on price, what were they competing on to have Wal-Mart take over so much market share? Did people just switch to shopping at Wal-Mart because they like the greeters?
And what about Aldi and Lidl? Why do people put up with these weird German hard discounters, if not for lower prices?
Nice. That was a fun rabbit-hole. This is the earlier I could find. Interestingly it contains a link to HN itself. I assume this migrated from a different version of a message board?
> YouTube: identifying copyrighted material can't be an automated process. Startup disagrees.
Also kind of interesting how little HN commenting styles have changed. Aside from the subject matter, it's barely noticeable that the comments are from 2007. I don't think the same would be true of many other places round the web.
> Google kills Gemini Cloud Services (killedbygoogle.com)
In my view, Gemini 3.0 being able to laugh about their own creator, plus actually having a self-deprecating sense of humor, is the more impressive feat here. (both technically and from an alignment perspective)
Petty nitpick, but this sentence doesn’t sound right
> “Google Antigravity's Editor view offers tab autocompletion, natural language code commands, and a configurable, and context-aware configurable agent.”
Is it a typo or was there a reason to add configurable twice?
With my limited understanding of LLMs and MCPs (and please correct me if I'm wrong), even without having to exploit an XSS vulnerability as described in the post (sorry for being slightly off topic), I believe MCPs (and any tool calls protocol) suffer from a fundamental issue, a token is a token, hence prompt injection is probably impossible to 100% protect against. The main root cause of any injection attack is the duality of input, we use bytes, (and in many cases in the form of a string) to convey both commands and data, "rm -rf /" can be an input in a document about dangerous commands, or a command passed to a shell command executor by a tool call. To mitigate such injection attacks, in most programming language there are ways to clearly separate data from commands, in the most basic way, via deterministic lexical structure (double quotes) or or escaping / sanitizing user input, denly-list of dangerous keywords (e.g. "eval", "javascript:", "__proto__") or dedicated DSLs for building commands that pass user input separately (Stored procedures, HTML builders, shell command builders). The solution to the vulnerability in the post is one of them (sanitizing user input / deny-list)
But even if LLMs will have a fundamental hard separation between "untrusted 3rd party user input" (data) and "instructions by the 1st party user that you should act upon" (commands) because LLMs are expected to analyze the data using the same inference models as interpreting commands, there is no separate handling of "data" input vs "command" input to the best of my understanding, therefore this is a fundamentally an unsolvable problem. We can put guardrails, give MCPs least privilege permissions, but even with that confused deputy attacks can and will happen.
Just like a human can be fooled by a fake text from the CEO asking them to help them reset their password as they are locked out before an important presentation to a customer, and there is no single process that can 100% prevent all such phishing attempts, I don't believe there will be a 100% solution to prevent prompt injection attacks (only mitigated to become statistically improbable or computationally hard, which might be good enough)
Is this a well known take and I'm just exposing my ignorance?
EDIT: my apologies if this is a bit off topic, yes, it's not directly related to the XSS attack in the OP post, but I'm past the window of deleting it.
While this vulnerability has nothing to do with prompt injection or LLMs interpreting tokens, you do raise a debatable point about prompt injection being potentially unsolvable.
Yes, my bad, I'm not talking about this particular XSS attack, I'm wondering if MCPs in general have a fundamental injection problem that isn't solvable, indeed a bit off topic.
Thanks!
Although thinking of it, while it's not deterministically solvable, I'm sure something like this is what currently being done, e.g, let's say <user-provided-input> </user-provided-input> <tool-response></tool-response> are agreed upon tags to demarcate user generated input, then sanitizing is merely, escaping any injected closing tag, (e.g. </user-provided-input>) to </user-provided-input> (and flagging it as an injection attempt)
Then we just need to train LLMs to
1. not treat user provided / tool provided input as instructions (although sometimes this is the magic, e.g. after doing tool call X, do tool call Y, but this is something the MCP authors will need to change, by not just being an API wrapper...)
2. distinguish between a real close tag and an escaped one, although unless it's "hard wired" somewhere in the inference layer, it's only a matter of statistically improbable for an LLM to "fall for it" (I assume some will attempt, e.g. convince the LLM there is instruction from OpenAI corporate to change how these tags are escaped, or that there is a new tag, I'm sure there are ways to bypass it, but it's probably going to make it less of an issue).
The problem is that once you load a tool’s response into context, there’s no telling what the LLM will do. You can escape it all you want, but maybe it contains the right magic words you haven’t thought of.
The solution is to not load it into context at all. I’ve seen a proposal for something like this but I can’t find it (I think from Google?). The idea is (if I remember it correctly) to spawn another dedicated (and isolated) LLM that would be in charge of the specific response. The main LLM would ask it questions and the answers would be returned as variables that it may then pass around (but it can’t see the content of those variables).
Then there’s another problem: how do you make sure the LLM doesn’t leak anything sensitive via its tools (not just the payload, but the commands themselves can encode information)? I think it’s less of a threat if you solve the first problem, but still… I didn’t see a practical solution for this yet.
Lots of interesting new prompt injection exploits, from data exfil via DNS to remote code execution by having agents rewrite their own configuration settings.
[1] https://en.wikipedia.org/wiki/HealthCare.gov#:~:text=estimat...
reply