logoalt Hacker News

netburst • today at 6:37 PM • 5 replies • view on HN

What is are the benefits of supporting extremely high churn rate in version control? What is the code doing? What problems are being solved? Are changing requirements the driving factor, and if so, why are requirement changes accelerating?

> ..., the latent demand for merging code is practically infinite, and every bottleneck we remove immediately leads to a further increase in the amount of code we produce.

If the goal is to write software which solves real problems, how can the demand for code grow infinitely?


Replies

stephen_cagle • today at 8:15 PM

This is the main thing that raises my eyebrow.

If you are constantly churning your codebase to the point that you need to invent a system that handles your churn... then you must at least be admitting that the previous 6 refactors you wrote were not good, but NOW you have it right.

I feel that good, well designed code change by accretion, not by rewrites. Code that remains stable for a long period of time was likely better than code that needs be continuously rewritten (at least with humans writers).

But maybe this is just a human-centric view of what good code means? That LLM "slop it until it works" approach to development will have a different measure of what quality looks like?

➕ show 1 reply
pshc • today at 7:12 PM

Surely their goal is ever-faster recursive self-improvement.

➕ show 1 reply
anal_reactor • today at 9:09 PM

I think that they're essentially solving the wrong problem.

Imagine that you have git but you don't even have a concept of programming language more complex than assembly. All your commits and git history are pure assembly. Everything is cool, until one day C++20 randomly spawns into existence, and a bunch of guys decide to use it in the company. The issue is, the compiler generates so much assembly, that your existing workflow cannot keep up with it. Your assembly git repo grows into hundreds of gigabytes, with PRs that are pretty much complete rewrites coming every single day and there's no way to review any of that shit.

What Anthropic is doing is redoing git from scratch so that it can handle all that assembly, while the correct thing to do is to commit C++ code into the repo, with deep trust that you'll never hit a bug in the compiler - basically impossible for initial versions of compilers, taken for granted nowadays.

What I'm saying is, Anthropic should create a versioning system for prompts, because they are the true "source code". Given the same prompt and the same sequence of random numbers, LLM will generate exactly the same code, which sounds awfully close to how compilers work. Once in a while put the generated code as a point of reference+ caching and presto.

➕ show 1 reply
ciconia • today at 7:25 PM

I find the accelerationist mindset utterly ridiculous. All that busywork and for what exactly? What effect has all this overproduction of LOC had on the physical world and on our existence (beyond the externality of erecting huge data centers in every corner of the globe and the consequent ecological impact)? Is software getting better (in terms of quality, security, efficiency)? Are we getting better government services? Are we getting better food? A better environment (silly question)? Are we working less, as tech titans keep promising us? Are we getting anything better? Not to mention all the negative aspects of this technology and the financial apparatus driving it.

➕ show 5 replies
Wazzymandias • today at 7:43 PM

[flagged]

➕ show 2 replies