pythonaut_16

I have yet to see the churn ever go down. I'm not saying it won't but what I see is that current frontier LLMs are still bad at identifying functional abstractions or patterns that can actually scale.

I have not seen an LLM rewrite 2-3 times and then settle on what sticks, it just rewrites constantly and usually while leaving residue of previous attempts behind.

Which in some projects is still fine. Like I said, they are generally producing working code, but I haven't seen proof yet that it can actually scale and evolve well over time.

That’s not my experience. The frontier models produce ok code that works but it’s still very sloppy. Further evidence is that the number of massive PRs is increasing not decreasing, i.e. the LLMs are brute forcing changes rather than introducing quality code patterns.

Opus 5.5 is impressive and I'm happy using it to write a ton of code.

But it also still writes awful code with poor maintainability if you don't keep a very close eye on it.

Guess it's time for Anthropic's next round of fearmarketing.

Beneath the fear there does seem to be a cool technical demo here though.

Maybe process maturity too.

Like think about a software org with good CI/CD versus one without. The mature org can do consistent incremental releases because each one is safe and low overhead, the messier org will do fewer big releases because each release requires a big effort on its own.

As model developers mature we might expect to see more frequent point releases rather than the big bang evolutions.

What? You're the one attacking this project. Or attacking everyone in this thread?

Like seriously, what do you want here? Or are you just mad at everyone and lashing out?

Imagine a world where there's no innovation because everyone just accepts the current standard instead of trying something weird.

My very high level take:

Every tool is a trade off between effort to create vs power of the solution.

Effort is generally expensive so most things settle on some general purpose local maximum. If you had infinite effort available, you could build bespoke hardware and software from the ground up to solve every problem. It would be faster and more power efficient than any solution available today.

CPUs win out over integrated circuits because the same CPU can be used for ~every software problem, so by using a CPU you benefit from everyone pooling their efforts to improve the general purpose CPU rather than their own specific niche. But when you reach a certain scale/requirements it makes sense to do something more specific. This is one reason why we have standardized GPUs. Still general purpose but more specialized than a CPU. Or think about how Bitcoin mining moved to ASICs, because they need to do one specific thing as fast and as power efficiently as possible.

So for databases, when you get to specific scale and requirements the same kind of specialization starts to make sense. DuckDB or Clickhouse for analytical loads, TigerBeetle for high scale transactional stuff, etc. And that scale is aggregated across ~all software users, i.e. scale of analytical workloads being big enough to support analytical DBs.

Also as time goes on and industries develop the cost to develop specific solutions can go down.

Why are you moving the goal posts? You asked for a citation and were given one and now you just change to a different argument.

> With Github, we threw that away.

I see this repeated a lot and IMO it's simply not true.

The main decentralized advantage of Git is that you can continue to do VCS operations without network access or access to the remote host.

Most of what Github does is managing collaboration. The only thing we've "thrown away" by using Github is the email based workflows or directly pushing git branches to various hosts. But unless you're gonna have team members SSH into each other's machines you'd still need a central repo somewhere.

Presumably the site owner with Cloudflare providing enforcement.

Generally isn't a good bot one that respects robots.txt and is respectful of the site's resources by not being spammy?

These are valid push-backs on the "postgres everywhere" argument.

The two critical questions IMO are:

1. At what scale do these issues arise? 2. Does Postgres make it harder to solve them when you reach that scale than another solution would have?

Some of that probably depends on the libraries or tools you use on top of Postgres but being able to easily swap to Redis or a proper queue at scale should mitigate the risk of starting with Postgres if you don't already have the scale.

Is this a bot or LLM reply? Because you've given this exact comment word for word at least twice in this thread...