I hope so, but it adds an extra difficulty
Easy to understand is not always an absolute metric, a project with many lines of code can be easy to understand for a team with a certain experience and difficult to understand for another team with a different experience (not less but different).
Now I will have to think about "easy to understand" for AI
I think I might be forced to do this by the metrics that measure me at work "things have to work right away and have to scale quickly to other low-skilled people"
I think this is true because I myself said to myself: "it is useless for me to create a library or abstraction for the developers of my project, much better to use everything verbose using the most popular libraries on the web".
Until yesterday having an abstraction (or a better library/framework) could be very convenient to save time in writing a lot of code.
Today if the code is mostly generated there is no need to create an abstraction.
AI understands 1000 lines of code in python pandas much better than 10 lines of code using my library (which rationalises the use of pandas).
The result will not only be a disincentive to use new technologies, but a disincentive to build products with an efficient architecture in terms of lines of code, and in particular a disincentive to abstraction.
Maybe some product will become a hell with millions of lines of code that no one knows how to evolve and manage.
I did a quick test and on my use case the performance improves mainly on a complex aggregation pipeline.
I still have to run extensive benchmarks.
I think one of the improvements is the New Query Engine: https://laplab.me/posts/inside-new-query-engine-of-mongodb/
I think it's different... I like high level languages, but this is not a programming language, this is a technique for writing tests in an existing language and leaving the implementation to the AI.
I like programming for problem solving, I don't really like writing tests, but that's personal taste, a lot of people like to just use PowerPoint and Jira and tell others what they need to implement, but these people are not software developers.
I appreciate that your workflow is so linear.
I often write tests, then the implementation, then I realize that the tests need to be corrected, then I change the implementation, then I change the tests, then I add other tests etc... etc...
I don't really like maintaining tests, it's often a lot of code that needs to be understood and changed carefully