fishtoaster

That would 100% been the right move. Some friends of mine with networking and ops backgrounds told me, "never trust an electrician to do low-voltage work right." After my experience with this one, I think I should have listened!

I had a lot of trouble with this when having my contractors run cat6 in my house during a recent renovation. Their electrician kept saying "it's done!" and then I'd test it and find that I was getting only 100mbps. Then they'd re-terminate the ends and a few more of the runs would get full speed when I re-tested. Repeated this cycle a few times until they all worked.

I'll miss the era when we could care about the craft of coding. I'll probably continue to do so in my spare time. Hobbyist woodworkers and hand-crafted furniture makers still exist, even if 99% of all chairs are made by machine now.

But code craft not the job. The job is to produce business value. Code craft used to aid that, but now it's an impediment.

Your job is no longer to produce code - it's to build systems that produce code. Tests and CI and Linters and custom lint rules and adversarial review and agent docs and automations and the next dozen tools we come up with as part of figuring out best practices around all of this. If you're getting woken up by agent-written code, the fix isn't to review every line of code - the fix is to improve your system so that class of error doesn't get written.

It's understandable if you don't want to do that work. It's almost entirely different from the work of reading and writing code. But if you don't, you're delivering less business value than someone who will. They don't employ hand woodworkers at Ikea.

Reminds me of an old hack project I did: https://tabdb.io/ Edit + query an SQL database whose data is stored exclusively in your browser tabs.

But the Amish are heavily excluded from society. Amish that refuse to use computers can't work most jobs. Amish that won't use credit cards can't buy things at cashless stores/restaurants. Amish that don't use electricity basically can't live in major cities.

There are no legal carveouts for that.

We arrived at a similar concept, though ours it the negation of this: we have a series of deterministic checks that can potentially add the `needs-human-review` tag to a PR. If that tag isn't present, you can merge your own PR; otherwise you need at least one human.

I think we're probably around 50/50 needing human review vs not.

Our rules for whether something needs a human review are currently mostly filepath-based: are you touching the api, or an important internal contract, or adding db migrations? Though I'd like to make it a bit smarter as we're definitely getting false positives.

Sounds about right. What have you (and/or fellow commenters) had good experiences with?

In San Francisco, there's a bit of a push right now to re-allow single-stair design ("Single Stair Reform") for certain buildings (eg up to 4 or up to 6 stories). Requiring two stairways makes sense from a fire safety perspective, but it's made it incredibly difficult to cost-effectively build medium-size buildings on oddly-shaped lots.

It's tradeoffs all the way down!

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.