tango12

4 ms·

1.
by tango12 3mo ago
TL;DR: one Claude per slack channel.
2.
by tango12 3mo ago
How is this multiplayer? Claude-slackbot needs to inherit my permissions for accessing scoped context and data / tools. Sounds like I need to setup specific credentials for each instance of the agent. More importantly, claude-slackbot
3.
Killing Slack was the only way to make AI accurate(promptql.io)
2 points by tango12 6mo ago|0 comments
4.
AI native Slack/teams: Turning conversations to context(venturebeat.com)
1 points by tango12 6mo ago|0 comments
5.
The semantic layer is dead. Long live the wiki(promptql.io)
3 points by tango12 9mo ago|0 comments
6.
Static AI Is Already Cutting Jobs; What Happens When It Starts to Learn?(promptql.io)
1 points by tango12 1y ago|0 comments
7.
by tango12 1y ago
The AI being wrong problem is probably not insurmountable. Humans have meta-cognition that helps them judge if they're doing a thing with lots of assumptions vs doing something that's blessed. Humans decouple planning from executi
8.
by tango12 1y ago
Author here. You’re right in that it’s obviously not the only problem. But without solving this seems like no matter how good the models get it’ll never be enough. Or, yes, the biggest research breakthrough we need is reliable calibrated co
9.
Being “Confidently Wrong” is holding AI back(promptql.io)
155 points by tango12 1y ago|262 comments
10.
by tango12 1y ago
What’s the eventual goal of text to sql? Is it to build a copilot for a data analyst or to get business insight without going through an analyst? If it’s the latter - then imho no amount of text to sql sophistication will solve the problem
11.
Approaching 100% accuracy on RAG with planning(promptql.hasura.io)
2 points by tango12 2y ago|0 comments
12.
PromptQL: Data access agent with 5x accuracy, repeatability than Claude and MCP(promptql.hasura.io)
2 points by tango12 2y ago|0 comments
13.
Show HN: Hasura PromptQL: A new way of talking to your data
6 points by tango12 2y ago|4 comments
14.
AI will change smart endpoints dump
1 points by tango12 2y ago|0 comments
15.
How many R's in Strawberry Fix(twitter.com)
3 points by tango12 2y ago|0 comments
16.
by tango12 2y ago
Counter-opinion: I totally agree with the sentiment here, but disagree with the conclusion. 1. The rest of the world doesn't have facebooks data layer. Ergo, GraphQL is very hard for everyone who's not FB. 2. Turns out GraphQL is
17.
by tango12 2y ago
I’m the founder of Hasura - sharing some notes from how I’ve seen GraphQL usage evolve over the last few years. 1. GraphQL was and remains insanely hard to build without an underlying data layer that does the heavy lifting. Without projecti
18.
by tango12 2y ago
Love this! Curious, wouldn’t this be great for folks with internal APIs as well? Team 1 can consume team 2’s API with an SDK instead of a raw REST client.
19.
by tango12 3y ago
I think there are 2 subtleties here on where you optimize perf: 1. Frontend makes n+1 requests to the api. Either use GraphQL or build a custom endpoint that shapes a perfect response. 2. Build an api server that fetches data from the db ef
20.
by tango12 3y ago
@alex_lav: Your SQL query here is exactly what I meant! In SQL, this is easy, both to write and to optimize perf. Implementing this with GraphQL resolvers (how folks typically write GraphQL servers) is hard - there's a users function a
21.
by tango12 3y ago
Like you said, it's not the join cost that's significant :) But for the DB to be sending less data over the network means that the DB is doing less CPU work in helping process that data. Benchmarking should be straightforward for
22.
by tango12 3y ago
The problem is that it’s hard to get the articles resolver make one query to fetch all the recent articles. So you’ll end up with n+1 fetches from the db. In the articles resolver, you have to: Select from articles order by created where ar
23.
by tango12 3y ago
> it's often much easier to scale the application server layer that the DB layer on most cases. Hm…ignoring the specific design decision here on using json agg - I think the open question is - is that specific sentiment practically
24.
by tango12 3y ago
query { Users (first: x) { …, articles (first: y, sortBy: CREATED) { .. } } } How would one implement the users and articles resolvers - that would be as efficient as a most_recent_views in sql?
25.
by tango12 3y ago
True - but the important point worth discussing here is that most common GraphQL implementations make it really hard to think in joins. The resolver pattern and data loader pattern make joins really painful. eg: implement a simple top-N que
26.
by tango12 3y ago
Totally feel the pain. Ironically, most DBs have started supported really good json aggregation functions. Combined with lateral joins, it’s possible to even push this ser/de to the DB directly and have minimal unpacking and packing in
27.
by tango12 3y ago
IMHO: The way we often approach GraphQL execution is a little dated. It’s perhaps legacy thinking from times when we had data layers that couldn’t be expected to scale even for the majority of use cases. But that has completely changed over
28.
The Rise of the Serverless Monoliths(medium.com)
3 points by tango12 3y ago|0 comments
29.
by tango12 3y ago
(From hasura) Came across this blogpost that happens to describe where something like hasura sits and how it decouples product dev (app + bff) from data api (microservice + db) dev. Think of Hasura as a GraphQL BFD (backend for data) instea
30.
by tango12 3y ago
Given the complexity vs DX trade off with GraphQL presented in the post: perhaps GraphQL goes the way of SQL. SQL is a phenomenal API but nobody builds a “sql api server” at work. People do build products that present a sql api, because it’

More ›