sgrove

Likely many points along the pareto frontier.

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.

There's a followup study to identify the actual cause of such a surprising outcome https://www.arxiv.org/abs/2506.19823

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!

I think it's not going well? I keep getting to the start a new call page, it fails, and takes me back to the live page. I assume your servers are on fire, but implementing some messaging would help ("come back later") or even better, a queueing system ("you're N in line") would help a lot.

Really looking forward to trying this out!

Or even run doom in TypeScript's type system!

All of your examples have had multiple cases of going down, some for multiple days (2011 AWS was the first really long one I think) - or potentially worse, just deleting all customer data permanently and irretrievably.

Meaning empirically, downtime seems to be tolerated by their customers up to some point?

I asked ChatGPT to rephrase your emotive reply into an expression of personal preference (which I think you were trying to express):

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!

Does anyone have a pdf of all of the pages together? This seems great to listen to as a NotebookLM podcast on a commute to work on Monday.

Better yet, if someone has already _done_ that Notebook Lm podcast and has a link to it, please share!

Interesting! Always interesting to see the ideas in the air at the same time!

https://linzumi.com/

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.

My absolute favorite overview of this - the video goes over both the explanation of the spaces, but also how it relates to a sort of understanding of reality itself!

https://youtu.be/YX40hbAHx3s

That sounds pretty fun (once you're finished with it, I'm sure)! How does sniffing the USB work? Do you do that via some software/kernel extension, via special hardware, or something simpler? Do you find there are some USB devices where the manufacturer would rather you didn't sniff their traffic and make it more painful to piece together?

Yes, that wasn't a priority here, but I also don't think it's much of a concern with e.g. GPT-4's `system` vs `assistant` vs `user` roles. Would be another thing to work on, but nothing worth doom and gloom.

Although, 'script(/injection) kiddie' will be an interesting phenomenon in the future...

I’ve been doing the same thing with a number of projects, building chains of prompts from one api call to another e.g. for ConjureUI (self-creating, iterable UIs that come into existence, get used, then disappear) https://youtu.be/xgi1YX6HQBw how it works to generate a full self-contained react component:

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.

I haven't put much effort into it yet, but I've found it to be somewhere in the middle of an independent story teller and a human-amplifying story teller. For example, having it give you options that you can choose from (e.g. https://www.youtube.com/watch?v=vff-8H-cZ7w ) can help keep the story focused.

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 ")

"Up or out" is perhaps a form of this - keep a stream of pressure over the org so you don't have any careerist settling in and (eventually) clogging up the productivity.

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 strongly suspect you might be disappointed. Battery collection and recycling - even as “raw ore” - should be easily profitable with plenty of motivated parties eventually. In the meantime, redwood materials will probably make quite a bit of money.

You should add a “tweet this movie” button that pre-populates the image and the title! I immediately wanted to share one of the funny suggestions.

It uses php-wasm, which is a WebAssembly build of PHP.

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'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.

Thanks so much, Darby!

Great to hear it Gavin, thank you for the kind words!

Plenty of plans, now we just need to execute on 'em!

Just finished an episode of Learn with Jason showing how to use this to build a small Spotify app using the Netlify Graph tooling: https://www.twitch.tv/videos/1299016321?t=0h25m21s (the link starts at the first step of the new app and dives right into the experience)

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

It's technically possible on our backend, but we haven't opened it up in a user-facing way yet. Definitely high on the priority list though!

Thanks!

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...

There are quite a few, but as a recent public one - https://oss.love is built using Netlify Graph. It pulls in data via the GitHub API using Netlify Graph, as an example.

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.

Ah, then you're in luck! Down the road, you should be able to tell Netlify Graph how to map the boilerplate-y bits from the API to the screen, so you always get something that works (with your best practices implemented) that you can start tweaking from.

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

One of the founders of OneGraph here, happy to answer any questions or talk about ideas!

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 think the concern is that they've delivered zero vehicles (but even then as you say, with the caveat that they've delivered to employees).

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.

Seems like it'd be nice to have a bot that you could add, so you could click a button on the message and respond, "Hey, would you mind giving me your email and I'll follow up on this as soon as I get a few minutes?", and then when they respond, have it create an email draft with the previous message quoted and with their email pre-filled.

A nice in-the-middle solution that a number of people might appreciate!

It's an interesting question, but I suspect that there are other, easier ways of normalizing companies from those regions to be Delaware-based (or something that prevents it, perhaps in Singapore's case, not sure), whereas outside of those there's really only this nuclear "company flip" option.

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.

The simpler, less cynical answer is that it's not just a US-based company, it has to be a Delaware-based company.

This is because all of the laws around founding, investing, selling, etc. a company are extremely well-trodden in Delaware, and there are very few question marks as to how some strange eventuality or disagreement might be handled.

Since startups are already incredibly difficult, this is a way of normalizing away some of the weird situations that could cause a startup to fail (and likely would never cause them to succeed), so that everyone is putting energy into the real unknown unknowns around the startup.