Don't build AI products the way everyone else is doing it
1–10 of 261 posts
Re: Don't build AI products the way everyone else is doing it
#2good points ! :+1:
Re: Don't build AI products the way everyone else is doing it
#3> The solution: create your own toolchain
No thanks. I have an actual job & customer needs to tend to. I am about 80% of the way through integrating with the OAI assistant API.
The real secret is to already have a viable business that AI can subsequently improve. Making AI the business is a joke of a model to me. You'd have an easier time pitching javascript frameworks in our shop.
Our current application of AI is a 1:1 mapping between an OAI assistant thread and the comment chain for a given GitHub issue. In this context of use, latency is absolutely not a problem. We can spend 10 minutes looking for an answer and it would still feel entirely natural from the perspective of our employees and customers.
Re: Don't build AI products the way everyone else is doing it
#4Great tips. I tried to do this with SVG icons in https://unstock.ai before a lot of people started creating text-to-vector solutions. You also have to keep evolving!
Re: Don't build AI products the way everyone else is doing it
#5> "One way we explored approaching this was using puppeteer to automate opening websites in a web browser, taking a screenshot of the site, and traversing the HTML to find the img tags.
> We then used the location of the images as the output data and the screenshot of the webpage as the input data. And now we have exactly what we need — a source image and coordinates of where all the sub-images are to train this AI model."
I don't quite understand this part. How does this lead to a model that can generate code from a UI?
Re: Don't build AI products the way everyone else is doing it
#6> The solution: create your own toolchain No thanks. I have an actual job & customer needs to tend to. I am about 80% of the way through integrating with the OAI assistant API. The real secret is to already have a viable business that AI can subsequently improve . Making AI the business is a joke of a model to me. You'd have an easier time pitching javascript frameworks in our shop. Our current application of AI is a…
[deleted]
Re: Don't build AI products the way everyone else is doing it
#7This is a nice post, and I think it will resonate with most new AI startups. My advice would be don't build an AI product at all.
To my mind an "x product" is rarely the framing that will lead to value being added for customers. E.g. a web3 product, an observability product, a machine vision product, an AI product.
Like all decent startup ideas the obviously crucial thing is to start with a real user need rather than wanting to use an emerging technology and fit it to a problem. Developing a UI for a technology where expectations are inflated is not going to result in a user need being met. Instead, the best startups will naturally start by solving a real problem.
Not to hate on LLMs, since they are neat, but I think most people I know offline hate interacting with chat bots as products. This is regardless of quality, bots are rarely as good as speaking with a real human being. For instance, I recently moved house and had to interact with customer support bots for energy / water utilities and an ISP, and they were universally terrible. So starting with "gpt is cool" and building a customized chatbot is to my mind not going to solve a real user need or result in a sustainable business.
Re: Don't build AI products the way everyone else is doing it
#8With the pace of AI, that (large) investment into a custom toolchain could be obsolete in a year. It feels like ChatGPT is going to gobble up all AI applications. Data will be the only differentiator.
Re: Don't build AI products the way everyone else is doing it
#9I think the prose in the pre-amble is a bit over-flowery and heavy handed (e.g. LLMs really aren't that expensive, I very much doubt the WSJ claim that Copilot is losing money per user, LLMs aren't always "painfully slow", etc.)
Having said that, the actual recommendations the article offers are pretty reasonable:
- Do as much as you can with code
- For the parts you can't do with code, use specialized AI to solve it
Which is pretty reasonable? But also not particularly novel.
I was hoping the article would go into more depth on how to make an AI product that is actually useful and good. As far as I can tell, there have been a lot of attempts (e.g. the recent humane launch), but not a whole lot of successes yet.
Re: Don't build AI products the way everyone else is doing it
#10I appreciate the overall sentiment of the post, but I can't say I would choose anything like the implementation the author is suggesting.
My takeaway is to avoid relying too heavily on LLMs both in terms of the scope tasks given to them as well as relying too heavily on any specific LLM. I think this is correct for many reasons. Firstly, you probably don't want to compete directly with ChatGPT, even if you are using OpenAI under the hood, because ChatGPT will likely end up being the better tool for very abstract interaction in the long run. For instance, if you are building an app that uses OpenAI to book hotels and flights by chatting with a bot, chances are someday either ChatGPT or something by Microsoft or Google will do that and make your puny little business totally obsolete. Secondly, relying too heavily on SDKs like the OpenAI one is, in my opinion, a waste of time. You are better off with the flexibility of making direct calls to their REST API.
However, should you be adding compilers to your toolchain? IMO, any time you add a compiler, you are not only liable to add a bunch of unnecessary complexity but you're making yourself dependent upon some tool. What's particulry bad about the author's example is that it's arguably completely unnecessary for the task at hand. What's so bad about React or Svelte that you want to use a component cross-compiler? That's a cool compiler, but it sounds like a complete waste of time and another thing to learn for building web apps. I think every tool has its place, but just "add a compiler, bruh" is terrible advice for the target audience of this blog post.
IMO, the final message of the article should be to create the most efficient toolchain for what you want to achieve. Throwing tools at a task doesn't necessarily add value, nor does doing what everyone else is doing necessarily add value; and either can be counterproductive in not just working on LLM app integration but software engineering in general.
Kudos to the author for sharing their insight, though.