[9rx]

AI (and humans) know why something was done if it was for technical reasons as it would be necessary to have those technical reasons described in the test suite/type system.

It wouldn't be able to reverse engineer why something was done when the "why" is some arbitrary decision that was made based on the engineer not having had his morning coffee yet, but those "whys" aren't an important property of the system, so who cares? Even in the unlikely event that someone documented that they zigged instead of zagged because it was just the vibes they were feeling in that moment, nobody is going to ever bother to read it anyway.

[Zak]

If something could be important and a decision about it was arbitrary, it's valuable to capture that. "There are three viable algorithms here and I don't know which will perform best with our live data so I picked the one that's mathematically beautiful for now" tells whoever is optimizing that system a couple years later that they should try the other two.

[9rx]

Wouldn't the intent of that be captured in your benchmark tests? And especially now that code generation is essentially free, wouldn't you include all three with the benchmark tests showing why a particular choice was chosen? This reads like an important property of the system, so tests are necessary.

[antonvs]

You're assuming a perfect system in which all relevant properties are tested for. That doesn't match probably 99.9% of real world systems.

The issue with AIs reverse engineering code is that context is very important - in fact knowledge and understanding of the context is one of the few things humans can still bring to the table.

Unless every relevant fact about that context has been encoded in a recoverable way the system and tests, AIs can only do so much. And there are essentially no non-trivial systems where that's the case.

[9rx]

You would test all important properties. That matches all real world systems you are responsible for. There is no reason to accept a lower standard for yourself.

Absolutely you have no control over what others have written, but you also have no way to access their lost context, so you are no further ahead than an LLM in that situation. The available information is the same for you as any other system.

[Zak]

> wouldn't you include all three with the benchmark tests

Maybe. If I know that the performance of this particular code path is going to be critical to the project's future success, sure. It's more common for something like that to be premature optimization though and the extra code is dead weight. I am not convinced by the idea that LLMs make that kind of dead weight much less undesirable.

[9rx]

If a choice comes down to simply guessing about the future then it isn't an important property of the system and therefore it makes no difference which algorithm was chosen or why. You are right about that being a premature optimization, but that equally applies to trying to decipher "why". When the future comes and an important property emerges, the historical "why" won't even matter as it wasn't rooted in anything relevant.

[Zak]

The load-bearing word in my original comment is could.

An experienced developer will often have a good intuition about what might deserve attention in the future but isn't worth the effort now.

It's also useful for social reasons. Maybe the CTO wrote the original code and a junior developer working on the optimization thinks they know a better way but isn't sure about questioning the CTO's choice of algorithm. A comment saying it was arbitrary gives them permission.

[9rx]

> Maybe the CTO wrote the original code and a junior developer working on the optimization thinks they know a better way but isn't sure about questioning the CTO's choice of algorithm.

If changing the algorithm is going to negatively affect the program then the CTO would have written tests to ensure that the important property is preserved. There is really no reason for the junior to be concerned as if he introduces an algorithm that is too slow, for example, then the tests aren't going to pass.

Yes, it is most definitely possible the CTO was a hack who didn't know how to build software and the junior was brought in to clean up his mess. However, in that case the information is simply lost. An LLM will not be able to recover it, but neither will a human.