I had a lot of fun using Sora and got a lot of laughs with absurd videos of me in various situations.

But like everyone else, I kind of got it out of my system after a couple weeks. Not to mention that my family got sick of seeing them. And so my usage collapsed to zero. And that seems to have also been the pattern writ large.

But this kind of flash-in-the-pan dynamic is devastating for a product with this kind of profile, which requires insane amounts of compute hardware to serve while also having no short-term monetization path.

Meta could afford to invest in IG Reels even when it was burning money and costing them a fortune for hardware because it was building up what turned out to be sustainable usage patterns which persisted long after the initial spending ramp.

It’s basically impossible to effectively monetize anything that’s not sustainable on the order of multiple years.

A subscription-based model would see excessively high churn that would be ruinous to the economics, and also advertisers wouldn’t be interested either, for the obvious reasons.

So why couldn’t this work? I don’t think that it was because the models weren’t good enough or that the depictions weren’t realistic or lifelike enough. I still marvel at some of the better outputs I was able to get from Sora.

I think the fundamental problem that Sora faced is actually much broader and more general, and it comes down to the basic Pareto math of any content generation or creative app, which is that 95%+ of the users just want to passively consume content from the 5% or less that actually wants to generate it (and is capable of making anything that other people want to watch).

It was really dismal to see the repetitive, trite ideas that 99% of users generated in the public feed. Just the same few dumb jokes and things they copied from other users.

Or putting themselves in a scene with their favorite fictional or cartoon characters or whatever, which of course got banned pretty quickly for copyright issues.

Most people are not creative and don’t have a lot of original, interesting ideas. So that means that the vast majority of the content is always going to come from a vanishingly small number of creators in a power law distribution.

And those super-creators aren’t going to want to be limited to a simple text-based interface that can only generate for 10 seconds at a time with no continuity and where large portions of things you might want to try are strictly forbidden.

They’ll instead gravitate to more customized solutions for power users that regular users would find as overwhelming to use as AutoCAD.

And that’s what you’re seeing now with all the new viral AI slop videos that are made by a handful of creators who have figured out the workflows and are pumping out the worst junk you can imagine that gets people to click and watch.

Anyway, RIP Sora; it was fun while it lasted. Thanks, Sam, for blowing a few hundred million bucks so we could get some laughs.

Comments URL: https://news.ycombinator.com/item?id=47178208

Points: 3

# Comments: 1

https://frankentui.com/

https://frankentui.com/web_react

Comments URL: https://news.ycombinator.com/item?id=46986644

Points: 22

# Comments: 10

Comments URL: https://news.ycombinator.com/item?id=46971782

Points: 2

# Comments: 2

https://github.com/Dicklesworthstone/frankentui/blob/main/CH...

And here are the beads tasks (courtesy of my bv project, check it out!), over a thousand in total:

https://franken-tui-beads-viewer.pages.dev/#/graph

Comments URL: https://news.ycombinator.com/item?id=46911912

Points: 4

# Comments: 0

Get it from the GitHub link and install with the convenient one-liner.

A tool like dcg has several competing goals that make it a careful balancing act and tough engineering problem:

1. Since it runs for every single tool call, it must be FAST. Hence why it is written in Rust and an extreme amount of focus has been placed on making it as fast as possible.

2. It must avoid annoying false positives that waste your time, add friction, and re-introduce you as the bottleneck unnecessarily. I run dozens of agents at once and don’t want them wasting time waiting for me unless it’s needed. Usually, the messages from dcg are enough to get the agent to be more thoughtful about what it’s doing.

3. It’s not enough to just use a simple rulebook where you look for canned commands like “rm -rf /” or “git reset --hard HEAD.” The models are very resourceful and will use ad-hoc Python or bash scripts or many other ways to get around simple-minded limitations. That’s why dcg has a very elaborate, ast-grep powered layer that kicks in when it detects an ad-hoc (“heredoc”) script. But wherever possible, it uses much faster simd optimized regex.

4. A tool like this should really be expandable and have semantic knowledge of various domains and what constitutes a destructive act in those domains. For instance, if you’re working with s3 buckets on aws, you could have a highly destructive command that doesn’t look like a normal delete. That’s why dcg comes out of the box with around 50 presets which can be easily enabled based on your projects’ tech stacks (just ask CC to figure out which packs to turn on for you by analyzing your projects directory).

5. dcg is designed to be very agent friendly. It doesn’t just block commands, it explains why and offers safe alternatives based on an analysis of the specific command used by the agent. For instance, it might stop the agent from deleting your Rust project’s build directories but suggest using “cargo clean” instead. Often, these messages are enough to knock sense into Claude.

I really can’t exaggerate just how much time and frustration dcg has already saved me. It should be known and used by everyone who has had these kinds of upsetting experiences with coding agents.

dcg is included along with all my other tooling in my agent-flywheel.com project. All free, MIT licensed, with extensive tutorials and other educational resources for people with less experience. Give it a try, you won’t regret it!

Comments URL: https://news.ycombinator.com/item?id=46835674

Points: 3

# Comments: 0

This was largely inspired by the work of Sydney Brenner, which became the basis of my brennerbot.org project.

In particular, I became very fascinated by phages, which are viruses that attack bacteria. They're the closest thing to the "fundamental particles" of biology: the minimal units of genetic code that do something useful that allows them to reproduce and spread.

They also have some incredible properties, like having a structure that somehow encodes an icosahedron.

I always wondered how the DNA of these things translated into geometry in the physical world. That mapping between the "digital" realm of ACGT, which in turn maps onto the 20 amino acids in groups of 3, and the world of 3D, analog shapes, still seems magical and mysterious to me.

I wanted to dig deeper into the subject, but not by reading a boring textbook. I wanted to get a sense for these phages in a tangible way. What are the different major types of phages? How do they compare to each other in terms of the length and structure of their genetic code? The physical structure they assume?

I decided to make a program to explore all this stuff in an interactive way.

And so I'm very pleased to present you with my open-source Phage Explorer:

phage-explorer.org

I probably went a bit overboard, because what I ended up with has taken a sickening number of tokens to generate, and resulted in ~150k lines of Typescript and Rust/Wasm.

It implements 23 analysis algorithms, over 40 visualizations, and has the complete genetic data and 3D structure of 24 different classes of phage.

It actually took a lot of engineering to make this work well in a browser; it's a surprising amount of data (this becomes obvious when you look at some of the 3D structure models).

It works fairly well on mobile, but if you want to get the full experience, I highly recommend opening it on a desktop browser in high resolution.

As far as I know, it's the most complete informational / educational software about phages available anywhere. Now, I am the first to admit that I'm NOT an expert, or even that knowledgeable, about, well, ANY of this stuff.

So if you’re a biology expert, please take a look and let me know what you think of what I've made! And if I've gotten anything wrong, please let me know in the GitHub Issues and I'll fix it:

https://github.com/Dicklesworthstone/phage_explorer

Comments URL: https://news.ycombinator.com/item?id=46833754

Points: 127

# Comments: 35

https://www.youtube.com/watch?v=68VVcqMEDrs

My full stack is detailed here on this site I made recently:

https://agent-flywheel.com/

I’ve been able to productively run 12+ agents from CC, Codex, Gemini-cli at the same time this way and it works really well.

https://github.com/Dicklesworthstone/brenner_bot

Comments URL: https://news.ycombinator.com/item?id=46437139

Points: 3

# Comments: 0