70% of the time I use AI agents on a pretty tight leash. I often reject edits and ask it to change things. The IDE integration is really efficient for this workflow compared to Claude (yes, I've tried the Claude extensions).

Autocomplete is still the best available (I've tried both Copilot and Zed); though admittedly it's not as important as it was circa last year.

For the 30% simpler or very well-specced tasks their cloud agents are last I compared way better than Claude Code's/Codex's version of the concept. @cursor for quick fixes in Slack works quite well. Don't get me wrong, it's still quite under-documented, but the others are worse. The integrations with linear, Slack and github are well executed

Composer 2.5 is really fast in their harness at code search/explanation/Q&A tasks (much faster than Sonnet/Opus). It's also really good at debugging, very proactive compared to other models in the same size/prices class IMO. Just due to the speed I actually prefer it to almost any other model for these tasks. I suspect at least some of this may be due to the harness and good codebase indexing.

I don't know why people are down on the Cursor harness. It's good. The main advantage of Claude Code/Codex are the token subsidies; but according to their dashboard I am costing my employer between $100-200/month on Cursor, so the overall price is comparable and only narrowing now that Anthropic is switching many enterprises to API usage.

I also don't understand the people complaining about VSCode bloat and in the same sentence praising Claude Code. Claude Code often uses MORE RAM than Cursor, has a super unstable UI (on my home machine there is input lag when typing ANYTHING in Claude Code) and the desktop app version of CC barely works. The Codex TUI is genuinely nice and snappy, on the other hand.

And that's when the agent even manages to construct a reasonable naive query. I've seen even Opus 4.6 ignore a `is_demo` column in the schema it was given when asked to construct a query for the number of active users.

Where I've seen text-to-SQL work well enough is when you're pointing it at data that's already been well-modeled for analytics such that the naive query a LLM will construct is correct by default. The data is either structured as a wide table such that no joins are necessary, or all the joins are 1:1 fact <-> dimension joins. All metrics are additive and so can be aggregated without asterisks. Columns follow a consistent naming convention, using the business domain terms a user would use in their prompt to the agent.

But that's a much thinner niche that what rawquery is proposing. You can't get around the analytics engineering effort involved in constructing a quality analytics dataset; the LLM will be a best a fuzzy fronted to your data warehouse, coextent with your BI tool.

Note: I do see value in value in rawquery's CLI-first approach to accessing data. In the right hands agents are very helpful at rapidly exploring datasets and validating assumptions on source data; but all the cloud data warehouse products I've interacted are all somewhat fiddly to access locally.

Comments URL: https://news.ycombinator.com/item?id=44426970

Points: 2

# Comments: 0