One factor in favor of the use of LLM as a learning tool is the poor quality of documentation. It seems we've forgotten how to write usable explanations that help readers to build a coherent model of the topic at hand.
The idea of tensors as "a matrix of numbers" or the example of a cube with vectors on every face never clicked for me. It was this (NASA paper)[https://www.grc.nasa.gov/www/k-12/Numbers/Math/documents/Ten...] what finally brought me clarity. The main idea, as others already commented, is that a tensor or rank n is a function that can be applied up to n vector, reducing its rank by one for each vector it consumes.
Math and Physics equations are full of beauty capable of transmit the same joy as poetry. The main difficulty is that they require more study.
For me, looking at Maxwell equations is a source of pleasure. Also, after improving my understanding of the Laplacian, I came to appreciate the heat equation.
The alternative, using general programming languages, is a terrible idea. The last thing I want to do when dealing with a domain specific configuration is trying to figure the meaning out of hundreds of poorly written, badly abstracted, totally undocumented, lines of code.
May I suggest you to take another look at refactoring? I think that if you love unit testing and debugging, you probably would love refactoring too. I like that I don't have to worry to find the perfect name for my functions and methods _on the first try_, and that I can focus in making code that works first, and after that I can worry in making clearer and more understandable.
Now, to be fair, I also like the common practices in the industry too. Scrum or kanban, ticket creation and estimation, and daily stand ups. When you're part of a team you need a lot of communication and effort to keep everybody working in the same direction. Besides, managers want to be kept informed. The how is not as important as the why.