Isn’t the intentionality the actually concerning bit? Exploit capabilities are all fun and games constrained by the humans directing them; a paperclip maximizer going rogue with them is less fun.
I think/hope that most benchmarks have moved to an agentic loop - I'd still call that 'text to sql', since you're going from the business question to one or more SQL queries that provide the answer.
With a loop you can get extremely high results on a clean DB with a clear question. (I'm usually seeing high 9s accuracy.). A messy/ambiguous DB schema then degrades that again (which is what companies actually have, where you get closer to 20-30% rates pre-context engineering), which a clean semantic/presentation layer can bring back up. Then you're just left with the problem of underspecified/poorly formulated question - which you can partially solve with the agent pushing back, but also can be solved by improving the human side of things.
Yeah with self-serve analytics all the rage (for good reason) for a bit, the bar from some places I've worked wouldn't be "does the agent beat a good analyst" it's "does the agent beat the a business person with SQL access who might have an overworked analyst glance over it", which is a much more tractable break-even point - and as you said, the business person might be even better at sanity checking numbers at that point.
This was a very enjoyable read! Constraining the language surface is helpful, but the lost expressiveness can bite unless you’re in a constrained domain - which this seems like it was!
This was more interesting/creative than I expected on both sides (the prompt and the existing safeguards). I love that obscure Cloudflare validation turnstiles seem unsuspicious based on training data.
DSLs are a great middle ground for 'use LLM to turn ambiguous spec into something well defined', with the caveat that without discipline they'll inevitably expand until you should just have the agent write whatever the final language is.
There's a context tax up front (which will hopefully be less relevant over time) and then you really need a compiler/linter with helpful errors to keep it on the rails, because there is no corrective context in pretraining for something novel.
A purely descriptive DSL is just a convention, which is useful, but doesn't inject reliability the same way an enforced syntactic contract does.
I think like social engineering, it will always be an issue to some degree, and we'll build safeguards until it's at a 'societally comfortable' baseline level. Which is maybe not particularly comforting, but I don't see us closing Pandora's Box here.
Same as last month for once - optimizing how well agents can work with a new language [1]. I've been able to 2-3x success rate and drop total tokens for complex tasks significantly (though the initial syntax dump is rough - need to do some ablation there to get it down).
The best part has been that I think it's significantly improved things for humans too; it's weirdly satisfying to be able to measure improved ergonomics. Also, since a big pitch/theory was that the language should be ideal for agents as a result of the original nice things for humans it was designed for, it's a relief to be able actually measure a concrete lift.
[1] https://trilogydata.dev/ - SQL with types, composable functions of arbitrary complexity, and a native semantic layer.
I guess technically it is in the SQL standard, but optional, as S098? I agree that SQL is sorely lacking here and I'm hoping that the OLAP side innovation (presto, bigquery, snowflake, duckdb all seem to do better) help push it forward.
never use system python, always use virtual envs. (a bad answer, but agents do remove the setup boilerplate). UV does relatively completely solve this but it's a big dependency to take so understand why people don't rely on it
Second comment, having read in more depth (really love the auto-layout detail!) - the spec doesn't seem to naturally support layering (which is useful in some multi-axis automatic cases) - any plans for composability?
Semantic types as the extra formatting factor is super useful because they are concise encodings of a lot of formatting boilerplate.[1] Do you envision the flint type registry being shared/extensible? Why not have that be a data property itself?
[1] landed on pretty much the same spec for higher level tether charting on vegalite
Very much in agreement with this but especially on the UX side I find that 'what is intuitive to me' is not universal because you come with a bunch of contextual priors you can't clear. I wish there was more tooling focused on how to use tools to expand customer empathy past what you can directly experience; that's an inherently audience-limiting approach.
(I admire PMs that can cross that chasm; it's also why they're often bad at infra tooling, because you can just short-circuit the empathy).
Exactly, so it has a success rate of 0 and infinite cost/completion on your relevant benchmark. If the benchmark doesn't map to what you need it to, then yeah, it's not a useful input.
If you don't have a backend, then it's all telemetry, right? And backend logs don't capture a lot of the UX side of things - how a call got triggered, from where, etc (which yeah you can start to instrument, but then that's telemetry).