wearhere
Joined 16 years ago
Joined 16 years ago
Instead, we get five (5) "Not an actual product render" illustrations.
This is also potentially terrible from a privacy standpoint. That "staying on top of your expenses" example suggests that you upload "a list of the entire [receipts] inbox" to the model. It _seems_ like they're using OpenAI's API, which doesn’t use customer data for training (unlike ChatGPT), but they should be crystal clear about this. Even if OpenAI doesn't retain/reuse the data, would Brex's customers be happy with this 3rd-party sharing?
The expenses example seems like sloppy engineering too—there's no reason to share expense amounts with the model if you just want it to count the number of expenses. Merchant names could be redacted too, replaced with identifiers that Brex would map back to the real data. These suggestions would save on tokens too.
Despite Brex saying they're using this in production, I suspect it's mostly a recruiting exercise. It's still a very bad look for their engineering.
How much of the public plans rides in advance, for a limited service area, via the web? I want to hear when these services finally have the capability and capacity to match the experience of Uber and Lyft: get a ride when and wherever you need one.
> one thing we wanted to prevent was developers including the stock SDK directly in the extension
(and I feel for Streak, having worked on a Gmail extension (Mixmax) until recently), but this seems to be exactly what manifest v3 will require. Curious if you have another strategy, @alooPotato.
Now that you explain your reasoning a bit, and upon re-reading https://en.wikipedia.org/wiki/Serverless_computing, I think using "serverless" in this context makes sense. I see "serverless" used so much more often to describe compute runtimes like AWS Lambda than databases that, I confess, I thought you might be trying to ride that wave's popularity; and/or that you might be using "serverless" _just_ because the servers were managed by you not the users, whereas you allocate capacity on a more granular level than the server.
I do still recommend you take out the "cloud hardware" bit ;D
Thanks for the explanation, and best of luck! Cool model.