alt Hacker NewsBut I delegate checks to tools all the time. e.g. I could spend my time checking whether locks are all used correctly in our code, or I could use libraries designed to force correctness[0]. An LLM isn't an ideal solution to linting, but if you're stuck with a language with a weak type system maybe that's all you can reasonably do.
The actual problem is that you're using strings at all. The SQL solution (that the scala macros do) is to use prepared statements and bound parameters, not to escape the string substitution. Basically, work in the domain, not in the serialized representation (strings). Likewise with XSS, you put the stuff into a Text node or whatever and work directly with the DOM so the structural interpretation has all already happened before the user data is examined.
But "work in the domain as much as possible" is a good idea for a whole bunch of reasons (as chatgpt said).
It did also several times indicate there was more to the story. It didn't just say "because that way is safer"; it said it
> Builds a structured query object, not a raw string
> Parameterizes inputs safely (turns $id into ? + bound parameter)
> Often adds compile-time or runtime checks
> Instead of manipulating strings, you’re working with a query AST / fragment system
And concluded by saying there's absolutely more detail, and that it's important to understand:
> If you tell me which library you’re using (Doobie, Slick, Quill, etc.), I can show exactly what guarantees sql"..." gives in your stack—those details matter quite a bit.
On vibe coded "garbage", I expect there won't be much of a market for such things (why would there be when you can also just vibe it?), so it will more be a personal computing improvement, which already limits the blast radius (and maybe already improves the situation vs the precarious-by-default SaaS/cloud proliferation today even with poor security). I also think tooling and vibe security will be better than median professional level by the time it's actually as easy as people claim it is to vibe code an application anyway. i.e. security (which is an active area of improvement to sell to professionals) will probably be "solved" before ease-of-use. Partly exactly because issues like code injection are already "solved" in better programming languages (which are also more concise and have better tooling/libraries in general), so the bot just needs to default to those languages.