fishtoaster

Because we all contain multitudes, I can simultaneously accept that:

1. I hate everything about this because I vastly prefer text over video for the same content, especially AI generated video

2. There are a lot of people for whom video is their preferred medium and so this will be valuable to them.

It's a technically cool project and your cost-per-video is impressively low. Best of luck!

If you like this, I highly recommend https://projectionlab.com/ for scenario-modeling your future income and retirement.

It's been discussed here a number of times and I've been a happy customer for years.

https://news.ycombinator.com/item?id=36849502 https://news.ycombinator.com/item?id=26969173

Does Seattle allow pet deposits? That seems like a straightforward way to handle that, and it's what I've seen when renting elsewhere.

Well, a coworker recently rigged up eleven's api to a coffee machine sensor. It now sings, loudly, an original composition to the effect of "make a new pot you asshole" whenever it gets low. We've gotten country, symphonic metal, southern hip hop, smooth british singing, accusatory broadway musical, 20's-style jazz singer, and more - it's different every time.

While the advisability of this particular project is up for debate, I do think it's something that could only exist with an API like eleven's.

Can't say I've tried the CLI. I've mostly focused on the cloud agents, which I was explicitly looking for. I compared against cursor's cloud agents, ampcode, and hoplite, and came out surprisingly enjoying devin.

I will say that the lack of parity between Devin cloud and Devin desktop is downright embarrassing. It's very clear that the latter is a thinly-reskinned Windsurf. A visually similar UI with vastly different capabilities. Definitely a black mark on the whole thing.

A friend recently pushed me to try out their coding platform, Devin, after I decided to move away from Cursor. I had the same reaction: "What, the con artists from like 2024?" But after some cajoling, I gave it a shot and was pleasantly surprised. I guess they learned their lessons, grew up, and are doing good work now, maybe?

The weight is interesting: 8.96 ounces (254 grams).

Not much more than the 18 pro max - 8.78 ounces (249 grams). The Duo sure looks chonky, but that's not the end of the world.

I quite like the idea of a tablet I can keep in my pocket. If there was some sort of first-party attachable keyboard (a la the iPad magic keyboard), I'd be strongly considering getting this. In the age of AI and increasingly-mature cloud agents, I can get a lot of my work done from a setup like that.

I think the answer is no - this would affect any Rails app with default settings that uses ActiveStorage. The "Preconditions" recap at the bottom here has all the appropriate caveats: https://ethiack.com/info-hub/research/kindarails2shell-how-a...

As a cyclist, I couldn't agree more. Cars are crazy murder machines, pedestrians will jump out at you just for fun, and the worst of the bunch is other cyclists!

But a bus- with a bus you know where you stand. They're slow, they're predictable, you can see the coming a mile away- I've never felt unsafe around SF Muni.

So the chain here is:

- 1password contributes the Omarchy foundation

- Omarchy is a project by DHH

- DHH has some evil opinions

I agree with all of that - DHH has a long history of being awful - but I think it's a little stretched to boycott 1password as a result, or to think it'll materially impact 1password.

Same thing as:

- "Cloud Agents" on cursor

- "Cloud Coding Agents" on Hoplite.sh

- "Sessions" in Devin cloud (they don't make a big deal of them being remote)

Amp is just trying to pitch an increasingly-commodity experience as a special sauce.

It's a fair question!

My attempt at an answer: no, databases are not solved.

Specifically, different databases are better or worse for different use-cases.

For example, Postgres is a great "all around database" - you can use it for a lot of different things. As a "relational" database, it's really good if you have a table full of users, a table full of order, and you want to see all orders made by a user with ID=123. You need to answer questions like that a lot (eg every time someone on a website loads a page) and you need the answer fast (hundreds of miliseconds at most)

However, say your use-case is more like... you've got 100 billion rows of billing data ("joe was charged $123.45 on 2026-03-07 for a shirt, blue, size 11, brand foobar") in one table. You don't care much about joe, but you want to be able to find out how much was billed, total, in 2026-03 for blue shirts (or all year for brand foobar, or all time, for size 11). Postgres would struggle with data of that volume - you'd need a really big expensive database. A "columnar" database like duckdb (or clickhouse) might be able to answer those questions better.

Anyway, different databases are better/worse for:

- Large piles of data that you need to query in seconds

- Huge (petabytes) of data that you need to query in minutes, but can query in parallel

- Many related piles (like a standard relational database)

- Cases where you're mostly getting or retrieving single items (key-value stores)

- Huge piles of data that represent a long stream of events in time (time-series datbases)

- Piles of data that look and act more like files (object stores)

- When you need strict transactions

- When your need is very write-heavy

- When your need is very read-heavy

- and probably many others - I'm not even a huge data guy :)

So it all depends on your use-case. There are still cases that are not served well by any existing database - eg "filtering billions of rows, in milliseconds, by an arbitrary portion of several dozen very-high-cardinality columns" (to use an example that came up recently for me IRL) :)

Since we're deep enough in this thread where we're talking about steak rather than AI, I'd like to lean into that.

I used to sous-vide a lot. It was certainly great to get perfectly-done steak. but I still didn't love the result and it took me a while to figure out.

Specifically: sous-viding at 130 doesn't reliably render fat. So it's great for a lean filet mignon like your suggesting, but kept giving me rubbery fat in anything with more fat or significant marbling. I eventually switched away from sous-vide (I usually either grill or reverse sear, depending on my effort/time availability) for most cuts these days.

Took me a minute to see the value - my first thought was "this is just cursor's cloud agents..."

But the key thing here for me is "Every sandbox boots your app on a live URL." Cursor doesn't easily have that, and that's what would allow me to ditch my local env entirely - the ability to actually try out a PR without needing to check it out locally.

So on that note: how does that work? We've had trouble with getting our dev env running in other cloud envs because it requires a few things (clickhouse, localstack, pg, etc) running which we manage via docker compose locally.

Also, some minor pricing feedback: it'd be really great if there were a version with pay-as-you-go and a cheaper fixed cost. I think your 99/seat/mo model is fine for professional work, but it's a lot to commit to for personal work.

As I mentioned explicitly in the comment you're replying to: yes, I did read that section. Did you not bother to read my whole comment before telling me to read more?

There's some good ideas and points in here, but this bit threw me:

> # We tried this > In July 2025 we went full lights-off

Isn't it pretty well-accepted at this point that the models underwent a step-change in usefulness around fall 2025 / spring 2026? I know that I was able to start handing agents whole features after that, but not before.

I feel like any perspective/experience on "what agents can/can't do" from before that period is... maybe less than relevant to the modern era. TFA calls it out a few sections later with "But surely the models have gotten better since then", but then just writes off any improvement. That does not match my experience.

Unfortunately I never got around to trying it! I remember it being a contender around the time of Backbone, but then Ember and Angular were the main options thereafter.

Sounds like your argument is with SPAs, not React in particular?

"React is actually a library, not a framework" is definitely a thing people have said here and there since its inception. It's a distinction that doesn't seem to buy anything in terms of explanatory power or clarity, so I tend to ignore it.

As someone who lived through all major waves of JS for the last ~16 years, I do love react, in a sense:

React is the worst JS framework except for all the others we've tried.

I'd take React over the Angular 1 days any time. I'd take Angular 1's full-bodied MVC over the "build it yourself from scratch every time" approach of Backbone. I'd take Backbone's minimal MVC structure over the classic JQuery Soup architecture. And I'd take JQuery's dom manipulations and standard-library improvements over the native apis (of that era) in an instant.

React has its tradeoffs, but we got here after a long slog of other things that don't work.

Interesting! Given the obvious AI-written nature of this, I'd probably want to double-check the math, but it's a neat concept.

As a homebrewer, the standard approach is to look up / measure your tap water's profile, buy a few grams of additives (gypsum, calcium chloride, epsom salt, etc), and add them to compensate. But if you don't have your water profile handy, this could work in a pinch. 5 gallons of bottled water is an expensive approach, though!

I landed on something similar for my own game, though it's been pretty tricky.

I'm building a physics-based 2d game involving slingshotting around planets. The realtime nature of it has meant that it's nearly impossible for the AI to test using a browser mcp. It'll take one screenshot, then another, and in the intervening time the player shot off the map and into deep space.

Instead I gave it both a code-level api to step forward and backward the physics engine and a browser-based, `window.game` api to do it via a browser mcp console. The former helps it work out physics bugs and the latter helps it test animation and UI issues.

It's still not great. I keep occasionally getting "I tested it and it works perfectly!" as I stare at the mcp'd browser with the player stuck clipped halfway into a planet. I think, if anything, I need to lean harder into this approach: building really solid tooling for the AI to inspect every aspect of state. I would kill for a turn-based game like OP XD

This is not to say that things haven't gotten worse over time, but...

I don't think that chart shows what it seems like it shows. There were plenty of pre-2018 outages that don't show up there: https://hn.algolia.com/?dateEnd=1545696000&dateRange=custom&...

An alternate interpretation of that chart is "After the microsoft acquisition, they got serious about actually tracking outages."

That said, anecdotally, it's felt much worse over the last 6 months. I'd guess it's a combination of MS-induced quality drops and AI-induced scale increases.

Yeah, I think all style comments should be handled by either a linter/formatter or be written in a style guide. Everything else is up to personal preference.

Then, when a style comment comes up in a PR, the answer is "Oh, do you think we should add that to our style guide? If so, let's discuss that in slack. Until then, though, that's not blocking."

Winning 2000 games in a row sounds statistically unlikely unless the Windows version of solitaire does something behind the scenes to make the game more winnable.

https://en.wikipedia.org/wiki/Klondike_(solitaire)#Probabili...

> This is the part that doesn’t demo well. ETL pipelines feeding into BigQuery from every operational system: Salesforce, Zendesk, and a dozen other internal tools. dbt transformations that normalize and document the data. Column-level descriptions for every table in the warehouse, because an AI agent that doesn’t know what a column means will write SQL that looks right and returns wrong numbers.

I'm glad they called this out. For the first half of this, I kept thinking: "Either your answers are confidently wrong or you've done a ton of prep work to let your AIs be effective BI analysts." Sounds like it's the latter, and they're well aware of it!

Is the pre-2018 data actually accurate? There seem to have been a number of outages before then: https://hn.algolia.com/?dateEnd=1545696000&dateRange=custom&...

Maybe that's just the date when they started tracking uptime using this sytem?

Why do you assume I assume it's doable? :P

For real, I'm not certain we will ever be able to merge AI code without human review. But:

1. Every time I've confidently though "AI will never be able to do X" in the last year, I've later been proven wrong, so I'm a bit wary to assume that again without strong reasons.

2. I see blog posts by some of the most AI-forward people that seems to imply some people are already managing large codebases without human review of raw code. Maybe they're full of crap - there are certainly plenty of over-credulous bs artists in the AI space - but maybe they're not.

3. The returns on figuring this out are so incredibly high that, if it's possible, people will figure it out.

All that to say: it's far from certain, but my bias is that it is possible.