sgrove
Some will take greater risks and win (or lose); others will play it safer and slowly accumulate wins (or be obsoleted).
Never mind the threat of letting these models write code that runs your business, or operate it agentically. Models trained by actors (corporate or nationstate) diametrically opposed to your interests.
Lots to take into account now, interesting time to be in business.
The combined use of faithful-chain-of-thought + mechanistic interpretation of LLM output to 1.) diagnose 2.) understand the source of, and 3.) steer the behavior is fascinating.
I'm very glad these folks found such a surprising outcome early on, and it lead to a useful real-world LLM debugging exercise!
Really looking forward to trying this out!
Meaning empirically, downtime seems to be tolerated by their customers up to some point?
> I feel that transforming such a wonderfully written story into a podcast with robot voices might result in a shallow and awkward rendition that doesn’t capture the essence of the original work.
I can definitely agree with that in the general sense! But I have a long commute, and I thought the content of it would still come through well enough, and I've appreciated it for a few other subjects. It's not as good as having professional voice actors read it out, but it still has some value to folks!
Better yet, if someone has already _done_ that Notebook Lm podcast and has a link to it, please share!
Definitely think this sort of idea could become the "serverless" equivalent for ml-using apps. I'm curious what you think re: versioning, consumption from various client languages, observability/monitoring/queueing, etc.? Feels like it could grow into a meaningful platform.
Although, 'script(/injection) kiddie' will be an interesting phenomenon in the future...
1. Take user task
2. Pass it to a prompt that requests a Product UI description of a component
3. Pass 1+2 to another that asks for which npm packages to use
4. Pass 1+2+3 to a templated prompt to write the code in a constrained manner
5. Run 4 in a sandbox to see if there are errors, if so pass it back to #4, looping
It’s currently quite slow, but that’s an implementation detail I think.
On the other hand, there are times where you want to ask the story teller if it's possible for you to do X - I think an iterative loop of that would probably be a happy middle ground (with next to no effort).
On the other other hand, maybe the original system prompt needs to include, "Don't let the player do anything that's out of place for the story". Lots and lots of ways to experiment here.
Oh, and it's also fun to hook up each "step" in the story to StableDiffusion to have it output a dramatic rendering of your story so far. I hooked up one scene from the YouTube video above to Midjourney and got quite a nice illustration out: https://media.discordapp.net/attachments/1051015357340602398...
----------------
(Midjourney prompt: "Dungeons and dragons comic book: "You find yourself at the entrance of a long-lost temple deep in the jungle... climb the temple to look for clues about the builders You take a step towards the jaguar, brandishing your sword and yelling at the top of your lungs. The jaguar hesitates for a moment, but then charges forward, claws bared. You ready yourself for the attack, determined to defend yourself "attack with sword' You and the jaguar continue to circle each other, both waiting for the other to make a move. Suddenly, the jaguar pounces, but you manage to dodge out of the way just in time. You counterattack with your sword" --v 5 ")
I don't know that it's actually effective at that (or if it is, that the inherent costs are worth it), but it's a bit of the reverse of most recent thinking: keep people for as long as you can if they're sufficiently useful.
I'm very bullish on the application of wasm in general at this point. It's such an interesting combination of:
* a reasonable compile target
* a reasonable-to-implement-safely runtime
* Already widespread deploy targets (in the form of browsers and now more and more cloud providers)
It feels like a sort of ouroboros is happening in front of us right now with a new infra layer about to bootstrap itself. That'll then enable tons of interesting new applications - wasm as a plugin runtime for applications, wasm3/wasmer for running wasm on the server (and elsewhere, like the Gameboy advance, of course!).> It's just a demo, and isn't supposed to be a real-world example of performance or best practices.
I also appreciate that it's still in an experimentation phase. Looks like a silly toy, like a lot of things do before they become mainstream.
Jason knew next to nothing about the current state of Netlify Graph (to keep the experience authentic), so it's pretty fun to see his reactions.
Also, the app is live for anyone to use! https://netlify-graph-nextjs.netlify.app/SpotifySearchForm
The whole flow works really, really well inside of vscode with the GraphQL extension - you get autocomplete, docs, etc. And upon save, it's that same as if you had edited it in the web UI. It should even be compatible with the GraphiQL explorer extension inside of vscode (though I haven't tried it yet) https://marketplace.visualstudio.com/items?itemName=GabrielN...
And it's always tempting fate to say "we have more planned", but, well, we have more planned...
Another simple one would be building a chart of Salesforce opportunities to serve as an office sales gong https://www.youtube.com/watch?v=ZTaETEkZ6hE
We have customers who build a product using Netlify Graph to manage Salesforce leads/opportunities/etc. inside of Slack, etc.
We already do this for a handful of frameworks (plain functions, next.js, remix, etc.). Here's a bit of an older example (with a much older UI) of how it works with a very plain project mapping various GraphQL operations to next.js https://youtu.be/0LJr15A0t4Y?t=73, including
- client-side forms
- server-side form validation
- auto-detecting when the user needs to log into a service client-side to do some query/action
- prompting the user to log into the service
- re-running the query on successful login
Basically, you should be able to click around in an API, run a test query, say, "Oh, I want that in my app", then click a button and have it inserted exactly how you and your team would have written it.This is what we have been working on since the Netlify acquisition https://news.ycombinator.com/item?id=29253069. Still early days and in beta, but excited to see all the DX pieces coming together bit by bit!
When we did our original Launch HN (back in summer 2018! https://news.ycombinator.com/item?id=17602951) this was one of the primary use-cases we had in mind. GraphQL provides such a rich layer for API tooling, but bringing it all together from a developer's point of view can be pretty challenging. Hopefully this spin on it (and the built-in integrations we're rolling out for specific frameworks) should make it significantly easier.
Lots of plans (a pure vscode workflow is high on my personal wishlist), but it's time to share the current state of things with all of you folks!
I haven't been following Rivian closely, but I was quite impressed by their PR event with Youtube folks recently https://www.youtube.com/watch?v=KGqexebCcUo - it definitely seems like a real, capable vehicle. Add to that their orders from Amazon (and presumably others at some point), and it seems like a plausible company.
Now, whether they have the margins and cash reserves to handle volatile markets / logistical concerns to survive long enough to become a long-term player, I'm not sure.
A nice in-the-middle solution that a number of people might appreciate!
YC hates anything specialized about a company re: this sort of thing - hence no special deals, etc., so I'd bet more on other normalization factors rather than no normalization.