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

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.

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.

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.

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.

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

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

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

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.

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.

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

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.