olive-n

I like to imagine that LLM's ability to optimize code is like an extension of the training-loop in deep learning. The loss function is some kind of metric representing security and/or performance (or the lack of it) of the code and we use the LLM as the gradient/diff generator to iterate in batches over the code and fine tune it.

Imagine the current state being for the most part a collection of local maxima in security. To push the system in a more optimal state, you either need skilled people and time to overcome the barrier to a new local maximum or you throw AI at it and evaluate whether you land in a more optimal state.

I think after some time of turbulent exploit/patch cycles we will reach a stable state again, where the code converges against a new local minimum that even with AI requires significant effort (time and tokens) to overcome. Or ideally a global maximum.

With time, the LLMs improve, so the diffs/gradients get better and we will be able to reach optimal points for any software faster.

My problem with the idea is that apparently it is assumed that OSS contributors and especially maintainers will generously donate their time to get this machinery into a state that makes the optimization loop work well - just for the AI labs to turn around and sell access to the optimized models for increasingly larger amounts of money.

AI generated code can be great. Hand rolled code can be bad. The rules are the same in both cases. Make sure your code changes are focused (no random changes just because you happen to be in the file/dir or notice something) and make sure you don't break anything else along the way.

It is a horrible setup that the manufacturers would much rather sell you a new car than a new battery.

We saw this play out with phones. We used to have easily swappable batteries. And since battery chemistry was (and hopefully still is and will continue) improving, by the time you actually swapped the battery there were ones around with a higher capacity than the battery the phone shipped with. And typically for little money.

Now everything is glued and messy to swap so the manufacturer can sell you a battery swap for much much more money than it used to cost.

I believe cars should have swappable somewhat standardized batteries. Even if not swappable by the user, it should not be a more than 1h job at the mechanic (ANY mechanic, not just the manufacturer).

Imagine picking a car and not caring about battery at all. You want a Tesla but BYD batteries are better - so get a Tesla without a Battery and put a BYD one it it. Or maybe Tesla has the best batteries right now, so you get that. And once you have to swap the battery, you again just pick the best manufacturer at the time - who might not even be a car manufacturer at all but rather someone specialized in batteries exclusively.

And since hopefully 10 years have passed since you bought the last battery, chemistry has improved so you pick from options that are all (hopefully a lot) better than the battery you had initially.

We could have some proper competition where manufacturers would have to compete on pricing and performance.

But car manufacturers don't care. They want as much of your money as they can get. And opening their cars to third party batteries and not keeping up as many walls as they can is the opposite of that.

So until forced by regulation every manufacturer will continue to put batteries in their cars that only they themselves will sell and put a slightly different one in every car. So guess what, even if you swap your battery in 10 years, they will sell you the same battery you can buy right now. Because the newer stuff is for new cars only and compatible with your car.

I installed the beta a week or two ago. Many of the files I tried opening in it just did not work at all. It can only open utf-8 encoded files.

That is not a problem for code, but if you just want to open some random .txt file or .csv file, these are often enough not utf-8 encoded, especially if they contain non English text.

The github issue for this is showing progress, but I think it's a mistake to promote the editor to stable as is.

I'll take csv over xlsx any time.

I work a lot with time series data, and excel does not support datetimes with timezones, so I have to figure out the timezone every time to align with other sources of data.

Reading and writing them is much slower than csv, which is annoying when datasets get larger.

And most importantly, xlsx are way more often fucked up in some way than any other format. Usually, because somebody manually did something to them and sometimes because the library used to write them had some hiccup.

So I guess a hot take indeed.

We evaluated poetry about what must be now two years ago. The hype for it was there.

But it was rather underwhelming. It's better than pip. But not worth the effort to migrate.

We recently tried uv and it felt like the next step for python project management. We have not made the jump yet, but will probably do so this year.

Autark might be a more common word in another language the author speaks.

It's a well defined word. Nothing wrong with using it.