Item — HN Reader

The idea of using the first search results as an input for GPT is a good compromise between the static/"smart" (static in time) GPT and the dynamic/"dumber" search engines.

I also agree it is a good idea to give control to the user to choose

- How to expand : between “breadth-first” and “depth-first”

- Then, how to filter : using dynamic keywords/references

This is what I’ve been telling people all day long these days. It is not an either/or. Good UX design (I like the citations system in your result!) can take the best of both words: The classic search engine (or any other classic UI), and AI functions/conversational UI.

The business model is unclear, but you are definitely into something here.

Good luck !

1 comments

Good ideas.

Business model wise, beyond this interface we have a demo of natural language to data-code (SQL and Python pandas/matplotlib/etc. APIs).

> Good ideas.

Well, I just reformulated some key ideas in your post. Nothing added really.

> natural language to data-code (... Python pandas/matplotlib/etc)

You mean something like this? https://news.ycombinator.com/item?id=33876826

hal9 is cool, and in a similar spirit. One thing we've observed with many approaches being explored lately is that they generate code into an IDE like experience. We are more of the camp of making the code gen and code run happen under the hood, so that you get an end-to-end experience ("ask question" -> "see result of running generated code").

Then still allow the user to inspect the code generated, fix it if necessary, and re-run. It's a bit of a subtle distinction but we think that UI/UX makes a big difference in the utility of these LLM applications.

Yeah, it is more in the spirit of "no code first" [0]

I suspect generic data-driven low code platforms like pipedream [1] and autocode [2] could do it this way at some point.

[0] https://zupa.hu/posts/no-code-first [1] https://pipedream.com/ [2] https://autocode.com/

Yeah, exactly "no code first", which I hadn't heard of before. Cool.