Programming is a ton of fun. There are competing concerns though.
I recently wrote a 17x3 reed-solomon encoder which is substantially faster on my 10yo laptop than the latest and greatest solution from Backblaze on their fancy schmancy servers. The fun parts for me were:
1. Finally learning how RS works
2. Diving in sufficiently far to figure out how to apply tricks like the AVX2 16-element LUT instruction
3. Having a working, provably better solution
The programming between (2) and (3) was ... fine ... but I have literally hundreds of other projects I've never shipped because the problem solving process is more enjoyable and/or more rewarding. If AI were good enough yet to write that code for me then I absolutely would have used it to have more time to focus on the fun bits.
It's not that I don't enjoy coding -- some of those other unshipped projects are compilers, tensor frameworks, and other things which exist purely for the benefit of programmer ergonomics. It's just that coding isn't the _only_ thing I enjoy, and it often takes a back seat.
I most often see people with (what I can read into) your perspective when they "think" by programming. They need to be able to probe the existing structure and inject their ideas into the solution space to come up with something satisfactory.
There's absolutely nothing wrong with that (apologies if I'm assuming to much about the way you work), but some people work differently.
I personally tend to prefer working through the hard problems in a notebook. By the time the problem is solved, its ideal form in code is obvious. An LLM capable of turning that obvious description into working code is a game changer (it still only works like 30% of the time, and even then only with a lot of heavy lifting from prompt/context/agent structure, so it's not quite a game changer yet, but it has potential).
If you're curious, you might also be interested in Cauchy-Reed Solomon coding. This converts Galois field operations into XORs by treating elements of GF(2^n) as bit matrices. The advantage then is that instead of doing Galois field operations, you can just xor things for much better performance. The canonical paper is https://web.eecs.utk.edu/~jplank/plank/papers/CS-05-569.pdf.
https://www.usenix.org/system/files/fast19-zhou.pdf is a more modern paper that goes into some related problems of trying to reduce the number of XOR operations needed to encode data.