There are a fair number of “developers” that I think will be displaced.
There was a guy on my team from an offshoring site. He was utterly incompetent and never learned. He produced garbage code that didn’t work. However he managed to stay in for about 4 years, and even then he left on his own terms. He managed to go 4 years and a grand total of 12 lines of code from him made it into any codebase.
Dealing with an LLM was awfully familiar. It reminded me of the constant frustration of management forcing me to try to work with him to make him productive. Excrpt the LLM was at least quick in producing output, and unable to go to management and blame everyone else for their shortcomings.
He’s an extreme case, but in large development organizations, there’s a fair number of mostly useless developers that I think LLM can rationalize away to a management team that otherwise thinks “more people is better and offshoring is good so they most be good developers”.
Also, enhanced code completion where a blatantly obvious input is made less tedious to input.
Actually, the lower level may likely be less efficient, due to being oblivious about the nature of the data.
For example, a traditional RAID1 mirror on creation immediately starts a rebuild across all the potential data capacity of the storage, without a single byte of actual data written. So you spend an entire drive wipe making “don’t care” bytes redundant.
Similarly, for snapshotting, it can only track dirty blocks. So you replace uninitialized data that means nothing with actual data, the snapshot layer is compelled to back up that unitiialized data, because it has no idea whether the blocks replaced were uninialized junk or real stuff.
There’s some mechanisms in theory and in practice to convey a bit of context to the block layer, but broadly speaking by virtue of being a mostly oblivious block level, you have to resort to the most naive and often inefficient approaches.
That said, block capacity is cheap, and doing things at the block level can be done in a ‘dumb’ way, which may be easier for an implementation to get right, versus a more clever approach with a bigger surface for mistakes.