I 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.
> 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.
How many times have we been down the path of “travel website making it easy to find the best deal and book your flight”. I don’t see how AI will do it any differently and how AI won’t inevitably run into all the same constraints.
I agree with this. I do like the general points about AI in the original post but writing your own compiler doesn't seem like the best solution.
Sure, it's unique and people can't just copy it but it will also be a massive amount of work to maintain it, considering all the languages it supports.
For me this additional layer of abstraction does have a bit of the 'factory-factory-factory' vibe.
> 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
Think that's debatable. Firstly the same argument could apply to non-AI stuff - there are dozens of websites that do basically the same thing as Google Flights which are big businesses, and frankly "AI" gives a lot more room for specialisation than flight search.
Secondly, the quality of the general language model really isn't the most important thing in a specialised task chatbot (now that baseline language parsing is good) . A travel booking chatbot that's attuned to my preferences and integrated with lots of APIs of relevant niche stuff isn't blown away by something that parses my questions slightly better but then tries to book everything through Expedia. Plus that's the sort of market where people are going to have brand loyalty or rejection of the notionally superior app because they once got a really good/bad recommendation, so I don't think it's anywhere near winner-takes-all.
> What's particulry bad about the author's example is that it's arguably completely unnecessary for the task at hand.
I entirely missed the compiler on the first read through and I don't know why so many commenters are fixated on that specifically. That wasn't what the blog post was actually about.
Their advice isn't "just add a compiler, bruh". Their advice is to see how far you can get solving your problem with ordinary code, then add the most limited AI on top necessary to finish solving the problem.
Their product is a tool to automatically translate a Figma design file to React code. So the ordinary code to solve the problem is a compiler. They're not telling everyone to write a compiler.
Your general criticism of adding compilers doesn't make sense in this context. Their alternative would be using ChatGPT as a compiler, and they convincingly argue that'd be worse. Or are you arguing that it's bad to offer a product that generates react code?
This is a thought-provoking post and I agree with the "avoid using AI as long as possible" point. AI is best used for things that can only be accomplished with AI--if there's any way to build the feature or solve the problem without it, then yeah, do that instead. Since everyone now has more or less equal access to the best models available, the best products will necessarily be defined by everything they do that's not AI--workflows, UIs, UX, performance, and all that other old-fashioned stuff.
I'm not so sure about the "train your own model" advice. This sounds like a good way to set your product up for quick obsolescence. It might differentiate you for a short period of time, but within 6-12 months (if that), either OpenAI or one of its competitors with billions in funding is going to release a new model that blows yours out of the water, and your "differentiated model" is now a steaming pile of tech debt.
Trying to compete on models as a small startup seems like a huge distraction. It's like building your own database rather than just using Postgres or MySQL. Yes, you need a moat and a product that is difficult to copy in some way, but it should be something you can realistically be the best at given your resources.
100%, worked with a founder who thought the AI hype was overblown 5 years ago so focused on "workflows, UIs, UX, performance, and all that other old-fashioned stuff" while all his competitors focused on building AI models. Then ChatGPT came out and all his competitors work was instantly obsolete, and he could achieve AI feature parity in weeks.
He was right about what to build but for the wrong reasons and it's been a huge boon to his business.
Not doing so will produce same boring Chatgpt based bot, everyone have already seen and tired off. I mean, differention is quite important thing actually.
This 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.
For most of us technologists, figuring out user need is way way harder than doing research or building something. That's the reality. So we tend to take comfort in building technology and figuring out the user need later on.
Even discovering a real problem, a problem that warrants the expense on technology, is unfortunately out of the comfort zone for a lot of technologists. We often assume that the problem is real, or worse hope that the problem be real and jump into solving it right away because that's our comfort zone, building stuff.
There ain't nothing wrong with this attitude or process. In most cases, where technologists have solved real problems, the real problem has been a serendipitous unraveling during the build-iterate-shut process. So the best shot at figuring out a real problem for technologists is not spending time in problem discovery, but in a better ship-iterate-shut cycle. A cycle, in which in one can look at current usage and postulate the future and take rapid decisions on what to build, or what not to build.
Having read the biographies of many tech leaders, I have come to the understanding that the key skill that has set them apart is that exponential growth in their ability to hone the intuition about future demand, in a very short span of time, starting from a barebones MVP.
> I think most people I know offline hate interacting with chat bots as products
It's hilarious to me when people are bringing back chat bots as a concept.
We had chat bots a few years ago and it was something that almost all larger companies had built strategies around. The idea being that they could significantly reduce call centre staff and improve customer experience.
And it wasn't just that the quality of the conversations were poor it was that for many users it's about being the human connection of being listened to that is important. Not just getting an answer to their problem.
>> This is regardless of quality, bots are rarely as good as speaking with a real human being
I avoid calling organizations as I know I will be on hold forever, when I finally do get through to someone usually they provide another number to call and the process repeats. I just want the thing done, as fast as possible - I don't care if I talk to a real person or not. The reason chatbots haven't helped the process so far is they just add more time and annoyance to the process as step 0 is often to get the chatbot to spit out a phone number or (finally) connect you to an agent. This is because, naturally, pre OpenAI chatbots were terrible. If post OpenAI chatbots are awesome, I can't see why people would not use them.
>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.
That's basically Steve Jobs' advice: "One of the things I've always found is that you've got to start with the customer experience and work backwards to the technology. You can't start with the technology and try to figure out where you're going to try to sell it."
I think it's a great idea if you're a serial founder and want some money for the idea that's going nowhere. People love to throw money at buzzwords.
A couple of years ago it was blockchain. Not sure what the next one is, but I already see all the "technologists" in my LinkedIn network have pivoted from crypto startups to AI startups.
This. Avoid the “If have hammer, everything looks like a nail” strategy. Find a customer pain point and use the right blend of tools. You can also make a new tool where tools dont exist
> Like all decent startup ideas the obviously crucial thing is to start with a real user
But if it's funding you want, slap the buzzword du jour in front of what you're trying to do, and you've vastly improved your prospects. In the frequent case when "the stock is the product", that's what you want.
Of course, this is basically a question of semantics: you're talking about actual companies that sell products, I'm talking about your typical tech-flavored grift.
>in applications where text isn't meant to be read word-for-word, and the entire response is expected before proceeding to the next step in the workflow, this can pose a significant issue.
Your take seems to narrow the application of AI chat down to customer service.
Taking a broader view, AI chat or really LLMs
have a very wide range of applications. As discussed in the article, script and code producing AI is not meant to be "read" so much as utilized post generation.
Either way, the reality is that just like any other advancement, this will slowly start to become integral to many business networks and workflow models, all having no interface with the consumer. The current fascination is wearing thin for the unimaginative who've asked a few generic questions to ChatGPT and then failed to recognize any applications of that product in their own life.
All the better, but the more products built now means the more likely something is produced that niche markets are looking to buy.
> This is regardless of quality, bots are rarely as good as speaking with a real human being.
I actually have enjoyed my limited experience with Amazon's customer service bots. And that's only because I have an account with them since forever.
And I can see why they are now the target of refund scammers.
In many cases, the conversation is as simple as "I recently bought [x] and I would like to return it" resulting in "You can keep it, we will send you another one".
That, to me, is a wildly better outcome than anything I could get on a phone. Nothing to do with the fact they told me just to keep what they sent me, but how quickly it can be resolved.
"Another satisified customer"
This is obviously based off my past purchase history, my rate of returns is, etc.
> I think most people I know offline hate interacting with chat bots as products.
At my company a chatbot is one of the main products, but I think the key is that it is used in bulk/triage situations where there's 0% chance a company would ever hire humans to do it instead.
So the real question is whether to to use a complex tax-filing-like form, or a chatbot, and whether either of those routes are done well.
For the vast majority of technologies i would agree but i think AI has enough buzz behind it that it’s punched through the technology bubble in to the general business world.
So slapping the term all over your product provides value to your customers.
So when you've taken 6-12 months to ship and everybody already iterated twice by directly using a hosted model and is building a real customer base you are only at v0.1 with your first customers who are telling you they actually wanted something else and now you have go and not just massage some prompts but recode your compiler and tool chain and everything else up and down the stack.
Perhaps if you already know your customers and requirements really really well it can make a lot of sense but I'd be very sceptical about "given how easy it is to do, why are you not validating your concept early with a fully general / expensive / hosted model". Premature optimisation being root of evil type stuff.
People are overthinking this from a competitive perspective. Create something that isn't easy to replicate - there are several ways to do that, but it's the only rule required from a competitive perspective.
Not sure... Look, even ChatGPT is still only used by an overwhelming minority of users.
100% (or close enough) of the entire market is still up for the taking, in pretty much every vertical.
Technical differentiation is only a small piece of the pie ; I think the game is about reach first.
It's a race to a billion users (or for B2B like us, maybe a race to a million), and a race to the best value (problem solved + UX) ; not a race to the best tech specs.
1000%. If your business case involves technical differentiation then build an AI stack. If your differentiation is something that can’t be replicated by someone else using OAI then you’re in the clear to use OAI. If your only differentiation is that you use OAI… well you’re hosed anyway.
To preface, I largely agree with the end state presented here -- we use LLMs within a state machine-esque control flow in our product. It's great.
With that said, I disagree with the sentiment of the author. If you're a developer who's only used the ChatGPT web UI, you should 100% play with and create "AI wrapper" tech. It's not until you find the limits of the best models that you start to see how and where LLMs can be used within a traditional software stack.
Even the author's company seems to have followed this path, first building an LLM-based prototype that "sort of" worked to convert Figma -> code, and then discovering all the gaps in the process.
Therefore, my advice is to try and build your "AI-based trading card grading system" (or w/e your heart desires) with e.g. GPT-4-Vision and then figure out how to make the product actually work as a product (just like builder.io).
I think soon AI will be build into a lot of different software. This is when it will really get awesome and scary.
One simple example are e-mail clients. Somebody asks for a decision or clarification. The AI could extract those questions and just offer some radio buttons, like:
Accept suggested appointment times: [Friday 10:00] [Monday 11:30] [suggest other]
George whats to know if you are able to present the draft: [yes] [no]
I think Zendesk (ticketing software for customer support) already has some AI available. A lot of support requests are probably already answered (mostly) automatic.
Human resources could use AI to screen job applications and let an AI resarch additional information about the applicant on the internet, and then create standardized database entries (which may be very flawed).
I think those kind of applications are the interesting ones. Not another ChatGPT extension/plugin.
I 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.
This post seems pretty focused on the How of building AI products, but personally I think that whether or not an "AI product" succeeds or fails mostly wont come down to differentiation / cost / speed / model customization, but rather whether it is genuinely useful.
Unfortunately, most products I've seen so far feel like solutions in search of problems. I personally think the path companies should be taking right now is to identify the most tedious and repetitive parts of using the product and looking for ways that can be reliably simplified with AI.
Blockchain isn't anywhere near as useful as a hammer. If you were gullible enough to fall for the promises of the blockchain, then of course you're going to be disappointed that AI isn't a get-rich-quick pyramid scheme that will make you millions of dollars without any investment of time or energy or original thought, because if that's all you're looking for, you're going to be continuously disappointed (and deserve to be). There's a lot more to AI than to the blockchain, and comparing the two as equal shows you don't understand what either of them are.
> One awesome, massive free resource for generating data is simply the Internet.
Isn't that building AI products _exactly_ the way everyone else is doing it? There are things in the world the internet doesn't know much about, like how to interpret sensor data. There are lots of transducers in the world, and the internet knows jack about most of them.
The article mentions the need to differentiate, which is valid. A related concept here is negative differentiation. You can differentiate yourself negatively by not implementing certain things or doing them poorly. You always differentiate (positive or negative) relative to your competitors. If they do a better job than you, you might have a problem.
Adding AI and then doing a poor job isn't necessarily creating a lot of value. So, if you follow the author's advice, you might end up spending a lot of money on creating your own models. And they might not even be that good and differentiate you negatively.
A lot of companies want to add AI not just because it looks cool but because they see their competitors doing the same and don't want to differentiate negatively.
There is so much available in the open model world. Take a look at the Hugging Face Hub - there are 1000s of models that can be used as-is or as a starting point.
And those models don't have to be LLMs. It's still a valid approach to use a smaller BERT model as a text classifier.
>..when we started talking to some large and privacy-focused companies as potential early beta customers, one of the most common pieces of feedback was that they were not able to use OpenAI or any products using OpenAI.
It's interesting to me that there are apparently companies that won't let OpenAI see their data, but will let a random startup see it. What's going on with that? Does OpenAI have a lax privacy policy or something?
I'd assume that you have a lot more leverage over a random small startup than OpenAI who serves half the world. This leverage can be used to ensure better privacy/etc..
* Never build your own model unless you have proven your model, and you have expertise to build it. Generic models will take you long way before cost/quality becomes an issue. Just getting all the data to train an LLM will be pain. 1000s of smartest people are spending n Billions to improve upon it. Don't compete with them. and if downstream you believe open source or your own is better use it then.
* Privacy is overrated. Enterprises are happy to use Google Docs, Office 365 exchange and cloud and ChatGPT itself. Unless you are in a domain where you know it will be a concern, trust Azure/OpenAI or Google.
* Let it be an AI startup. It should solve some problem but if VC and customer want to hear AI and Generative, that's what you are. Don't try to bring sanity in hand feeding you.
Great 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!
Shortcuts in early product can definitely affect flexibility as new things keep arriving to tryout and further handcuffing things.
I love speed and frequency of shipping but sometimes thinking about things just a bit, but not too much doesn't always hurt.
Sometimes simple is using a standard to keep the innovation points for the insights to implement.
Otherwise innovation points can be burnt on infrastructure and maintaining it instead of building that insight that arrives.
Finding a sweetspot between too little, and too much tooling is akin to someone starting with vanilla javascript to learn the value of libraries, and then frameworks, in that order rather than just jump into frameworks.
> When passing an entire design specification into an LLM and receiving a new representation token by token, generating a response would take several minutes, making it impractical.
Woe is me, it takes minutes to go from user-designed mockup to real, high-quality code? Unacceptable, I tell you!
But seriously, if there are speed improvements that you can make and are on the multiple-orders-of-magnitude then I do get it, those improvements are game-changing. But also, I think we're racing too quickly with expectations here; where minutes is unacceptable now when it used to take a human days? I mean, minutes is still pretty good! IMO.
[+] [-] ravenstine|2 years ago|reply
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.
[+] [-] goalieca|2 years ago|reply
How many times have we been down the path of “travel website making it easy to find the best deal and book your flight”. I don’t see how AI will do it any differently and how AI won’t inevitably run into all the same constraints.
[+] [-] reason5531|2 years ago|reply
[+] [-] notahacker|2 years ago|reply
Think that's debatable. Firstly the same argument could apply to non-AI stuff - there are dozens of websites that do basically the same thing as Google Flights which are big businesses, and frankly "AI" gives a lot more room for specialisation than flight search. Secondly, the quality of the general language model really isn't the most important thing in a specialised task chatbot (now that baseline language parsing is good) . A travel booking chatbot that's attuned to my preferences and integrated with lots of APIs of relevant niche stuff isn't blown away by something that parses my questions slightly better but then tries to book everything through Expedia. Plus that's the sort of market where people are going to have brand loyalty or rejection of the notionally superior app because they once got a really good/bad recommendation, so I don't think it's anywhere near winner-takes-all.
[+] [-] lamontcg|2 years ago|reply
I entirely missed the compiler on the first read through and I don't know why so many commenters are fixated on that specifically. That wasn't what the blog post was actually about.
[+] [-] iudqnolq|2 years ago|reply
Their product is a tool to automatically translate a Figma design file to React code. So the ordinary code to solve the problem is a compiler. They're not telling everyone to write a compiler.
Your general criticism of adding compilers doesn't make sense in this context. Their alternative would be using ChatGPT as a compiler, and they convincingly argue that'd be worse. Or are you arguing that it's bad to offer a product that generates react code?
[+] [-] danenania|2 years ago|reply
I'm not so sure about the "train your own model" advice. This sounds like a good way to set your product up for quick obsolescence. It might differentiate you for a short period of time, but within 6-12 months (if that), either OpenAI or one of its competitors with billions in funding is going to release a new model that blows yours out of the water, and your "differentiated model" is now a steaming pile of tech debt.
Trying to compete on models as a small startup seems like a huge distraction. It's like building your own database rather than just using Postgres or MySQL. Yes, you need a moat and a product that is difficult to copy in some way, but it should be something you can realistically be the best at given your resources.
[+] [-] JamesBarney|2 years ago|reply
He was right about what to build but for the wrong reasons and it's been a huge boon to his business.
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] SomeoneFromCA|2 years ago|reply
[+] [-] BillFranklin|2 years ago|reply
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.
[+] [-] deepGem|2 years ago|reply
Even discovering a real problem, a problem that warrants the expense on technology, is unfortunately out of the comfort zone for a lot of technologists. We often assume that the problem is real, or worse hope that the problem be real and jump into solving it right away because that's our comfort zone, building stuff.
There ain't nothing wrong with this attitude or process. In most cases, where technologists have solved real problems, the real problem has been a serendipitous unraveling during the build-iterate-shut process. So the best shot at figuring out a real problem for technologists is not spending time in problem discovery, but in a better ship-iterate-shut cycle. A cycle, in which in one can look at current usage and postulate the future and take rapid decisions on what to build, or what not to build.
Having read the biographies of many tech leaders, I have come to the understanding that the key skill that has set them apart is that exponential growth in their ability to hone the intuition about future demand, in a very short span of time, starting from a barebones MVP.
[+] [-] threeseed|2 years ago|reply
It's hilarious to me when people are bringing back chat bots as a concept.
We had chat bots a few years ago and it was something that almost all larger companies had built strategies around. The idea being that they could significantly reduce call centre staff and improve customer experience.
And it wasn't just that the quality of the conversations were poor it was that for many users it's about being the human connection of being listened to that is important. Not just getting an answer to their problem.
[+] [-] osigurdson|2 years ago|reply
I avoid calling organizations as I know I will be on hold forever, when I finally do get through to someone usually they provide another number to call and the process repeats. I just want the thing done, as fast as possible - I don't care if I talk to a real person or not. The reason chatbots haven't helped the process so far is they just add more time and annoyance to the process as step 0 is often to get the chatbot to spit out a phone number or (finally) connect you to an agent. This is because, naturally, pre OpenAI chatbots were terrible. If post OpenAI chatbots are awesome, I can't see why people would not use them.
[+] [-] Amorymeltzer|2 years ago|reply
That's basically Steve Jobs' advice: "One of the things I've always found is that you've got to start with the customer experience and work backwards to the technology. You can't start with the technology and try to figure out where you're going to try to sell it."
[+] [-] duped|2 years ago|reply
A couple of years ago it was blockchain. Not sure what the next one is, but I already see all the "technologists" in my LinkedIn network have pivoted from crypto startups to AI startups.
[+] [-] fillskills|2 years ago|reply
[+] [-] FFP999|2 years ago|reply
But if it's funding you want, slap the buzzword du jour in front of what you're trying to do, and you've vastly improved your prospects. In the frequent case when "the stock is the product", that's what you want.
Of course, this is basically a question of semantics: you're talking about actual companies that sell products, I'm talking about your typical tech-flavored grift.
[+] [-] upsidesinclude|2 years ago|reply
Your take seems to narrow the application of AI chat down to customer service.
Taking a broader view, AI chat or really LLMs have a very wide range of applications. As discussed in the article, script and code producing AI is not meant to be "read" so much as utilized post generation.
Either way, the reality is that just like any other advancement, this will slowly start to become integral to many business networks and workflow models, all having no interface with the consumer. The current fascination is wearing thin for the unimaginative who've asked a few generic questions to ChatGPT and then failed to recognize any applications of that product in their own life.
All the better, but the more products built now means the more likely something is produced that niche markets are looking to buy.
[+] [-] EMM_386|2 years ago|reply
I actually have enjoyed my limited experience with Amazon's customer service bots. And that's only because I have an account with them since forever.
And I can see why they are now the target of refund scammers.
In many cases, the conversation is as simple as "I recently bought [x] and I would like to return it" resulting in "You can keep it, we will send you another one".
That, to me, is a wildly better outcome than anything I could get on a phone. Nothing to do with the fact they told me just to keep what they sent me, but how quickly it can be resolved.
"Another satisified customer"
This is obviously based off my past purchase history, my rate of returns is, etc.
That's fine. It works.
[+] [-] Terr_|2 years ago|reply
At my company a chatbot is one of the main products, but I think the key is that it is used in bulk/triage situations where there's 0% chance a company would ever hire humans to do it instead.
So the real question is whether to to use a complex tax-filing-like form, or a chatbot, and whether either of those routes are done well.
[+] [-] austhrow743|2 years ago|reply
So slapping the term all over your product provides value to your customers.
[+] [-] fillskills|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] zmmmmm|2 years ago|reply
So when you've taken 6-12 months to ship and everybody already iterated twice by directly using a hosted model and is building a real customer base you are only at v0.1 with your first customers who are telling you they actually wanted something else and now you have go and not just massage some prompts but recode your compiler and tool chain and everything else up and down the stack.
Perhaps if you already know your customers and requirements really really well it can make a lot of sense but I'd be very sceptical about "given how easy it is to do, why are you not validating your concept early with a fully general / expensive / hosted model". Premature optimisation being root of evil type stuff.
[+] [-] epolanski|2 years ago|reply
All of this talk about the technology and pipeline but none of this had any relevance without a product to build and a problem to solve.
It's like debating if soap or rest is best for the user, user doesn't care how it's built.
[+] [-] danielmarkbruce|2 years ago|reply
[+] [-] sebastiennight|2 years ago|reply
100% (or close enough) of the entire market is still up for the taking, in pretty much every vertical.
Technical differentiation is only a small piece of the pie ; I think the game is about reach first.
It's a race to a billion users (or for B2B like us, maybe a race to a million), and a race to the best value (problem solved + UX) ; not a race to the best tech specs.
[+] [-] aabhay|2 years ago|reply
[+] [-] jumploops|2 years ago|reply
With that said, I disagree with the sentiment of the author. If you're a developer who's only used the ChatGPT web UI, you should 100% play with and create "AI wrapper" tech. It's not until you find the limits of the best models that you start to see how and where LLMs can be used within a traditional software stack.
Even the author's company seems to have followed this path, first building an LLM-based prototype that "sort of" worked to convert Figma -> code, and then discovering all the gaps in the process.
Therefore, my advice is to try and build your "AI-based trading card grading system" (or w/e your heart desires) with e.g. GPT-4-Vision and then figure out how to make the product actually work as a product (just like builder.io).
[+] [-] andix|2 years ago|reply
One simple example are e-mail clients. Somebody asks for a decision or clarification. The AI could extract those questions and just offer some radio buttons, like:
I think Zendesk (ticketing software for customer support) already has some AI available. A lot of support requests are probably already answered (mostly) automatic.Human resources could use AI to screen job applications and let an AI resarch additional information about the applicant on the internet, and then create standardized database entries (which may be very flawed).
I think those kind of applications are the interesting ones. Not another ChatGPT extension/plugin.
[+] [-] infixed|2 years ago|reply
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.
[+] [-] tqi|2 years ago|reply
Unfortunately, most products I've seen so far feel like solutions in search of problems. I personally think the path companies should be taking right now is to identify the most tedious and repetitive parts of using the product and looking for ways that can be reliably simplified with AI.
[+] [-] hubraumhugo|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] DonHopkins|2 years ago|reply
[+] [-] sevensor|2 years ago|reply
Isn't that building AI products _exactly_ the way everyone else is doing it? There are things in the world the internet doesn't know much about, like how to interpret sensor data. There are lots of transducers in the world, and the internet knows jack about most of them.
[+] [-] jillesvangurp|2 years ago|reply
Adding AI and then doing a poor job isn't necessarily creating a lot of value. So, if you follow the author's advice, you might end up spending a lot of money on creating your own models. And they might not even be that good and differentiate you negatively.
A lot of companies want to add AI not just because it looks cool but because they see their competitors doing the same and don't want to differentiate negatively.
[+] [-] dmezzetti|2 years ago|reply
And those models don't have to be LLMs. It's still a valid approach to use a smaller BERT model as a text classifier.
[+] [-] 0xDEAFBEAD|2 years ago|reply
It's interesting to me that there are apparently companies that won't let OpenAI see their data, but will let a random startup see it. What's going on with that? Does OpenAI have a lax privacy policy or something?
[+] [-] rf15|2 years ago|reply
[+] [-] own2pwn|2 years ago|reply
[+] [-] adrwz|2 years ago|reply
[+] [-] thuuuomas|2 years ago|reply
[+] [-] blackoil|2 years ago|reply
* Never build your own model unless you have proven your model, and you have expertise to build it. Generic models will take you long way before cost/quality becomes an issue. Just getting all the data to train an LLM will be pain. 1000s of smartest people are spending n Billions to improve upon it. Don't compete with them. and if downstream you believe open source or your own is better use it then.
* Privacy is overrated. Enterprises are happy to use Google Docs, Office 365 exchange and cloud and ChatGPT itself. Unless you are in a domain where you know it will be a concern, trust Azure/OpenAI or Google.
* Let it be an AI startup. It should solve some problem but if VC and customer want to hear AI and Generative, that's what you are. Don't try to bring sanity in hand feeding you.
[+] [-] mmoustafa|2 years ago|reply
[+] [-] ShamelessC|2 years ago|reply
[+] [-] esafak|2 years ago|reply
[+] [-] j45|2 years ago|reply
I love speed and frequency of shipping but sometimes thinking about things just a bit, but not too much doesn't always hurt.
Sometimes simple is using a standard to keep the innovation points for the insights to implement.
Otherwise innovation points can be burnt on infrastructure and maintaining it instead of building that insight that arrives.
Finding a sweetspot between too little, and too much tooling is akin to someone starting with vanilla javascript to learn the value of libraries, and then frameworks, in that order rather than just jump into frameworks.
[+] [-] cryptoz|2 years ago|reply
Woe is me, it takes minutes to go from user-designed mockup to real, high-quality code? Unacceptable, I tell you!
But seriously, if there are speed improvements that you can make and are on the multiple-orders-of-magnitude then I do get it, those improvements are game-changing. But also, I think we're racing too quickly with expectations here; where minutes is unacceptable now when it used to take a human days? I mean, minutes is still pretty good! IMO.