additionally modifying data in binary form was a longtime practice last time I looked, but I might not remember correctly.

Regardless of free software, capitalists control the means of production and obtain profits by exploiting the surplus labor time of workers.

Free software may make it more obvious though, at least for some.

> Humans reason

Are you sure? They reason in a way to match others predictions, right? The problem of humans transporting information from one individual to another remains. All reason can effectively only be prediction, as it requires two persons at minimum. And there is a lot of noise to filter.

> LLM predict.

Well, there is a human that needs to reason with what the LLM has predicted. So from that perspective, it should suffice already for the moment.

Not saying to make this achievement smaller than it is, quite the opposite, it's important there is more such research.

Clearly the "our craft" is "business minds" and the problem with increased Unity fees is that their add business is at risk despite all these "business minds" invested years to shape their model.

What an excellent shit-show.

Given the project itself is still strong, this might not be a problem, but then I see no reason why it has chosen it in the first place if not for that specific option.

- https://news.ycombinator.com/item?id=26887670

- https://news.ycombinator.com/item?id=26949539

- https://news.ycombinator.com/item?id=26955414

Nevertheless, things can be different, e.g. if CI passes, it merges already, no need to have a request for merge, which are often a blocker to keep a steady development flow. Naturally, this benefits from tests that are already run during development, if not driving the development.

And I didn't read you're against testing nor aligning white space and comments at all, more the localization. Actually the points you raise are looking important to me, because if alignment comes in late, this can cause a lot of erosion, which can hinder any review if not even provoke merge conflicts which are stopping the process quite early and require re-iteration.

Your approach should also work towards non-release blocking code reviews, a property I personally like, as I've seen teams struggle with code reviews, becoming more and more of a burden, even after practicing it has found its way. But that is only a subjective comment of mine, every project is different, which makes it an interesting topic for me.

As, IMHO it depends (as so often). Code review is commonly the place that puts the current style under test (hence automated otherwise you don't have the results during review) and under review.

E.g. Code review finds out if a code-style is missing, incomplete or even outright wrong.

If that approach is taken, passing tests and code-style must be in there, otherwise it is not useful to argue about violations. From my understanding I would therefore see those results be available during review.

It may also be that there is code-style for automated test-code, and that code part of the review. Without taken this into context of the code-review, I miss a bit the boundary of your comment.

Could you elaborate a bit where you draw the line and why? E.g. I can imagine there is a benefit to keep a distinct context for code-reviews so that they are still practically feasible and those parts that need further adoption are put into a different phase, like steps before (preparation of the current increment) or after (preparation of next increments) the code-review itself.

- It does not allow a reasonable decision as it does not show the data before it sends it

(They start to ruin that, but lets say, the idea is still visible.)

so if someone plans to extend the script so that it injects it iself into the container or what not.