For larger systems you create your own modules and abstractions, so comprehensibility at higher level does not depend so much on the language.
For larger systems you create your own modules and abstractions, so comprehensibility at higher level does not depend so much on the language.
The tools the language gives you to create those abstractions make a lot of difference, however.
But every abstraction that an LLM has to write is a choice. Your way of writing Python may not match that choice. The next run of the agent might not choose the same way.
Because the language gives you many different tools, an LLM generated codebase can get inconsistent and overly complicated quickly. The flexibility of Python is a downside when you’re having an LLM generate the code. If you’re working in an existing codebase, it’s great - those choices were already made and it can match your style.
When an LLM has to derive its own style is when things can devolve into a jumbled mess.
To me applying LLMs to a python (or similarly dynamic) code base where it’s currently spaghetti and monkey patched, it can miss things just like I can.
But… I have to admit Opus 4.7 has been very pragmatic in detecting root causes and proposing sensible fixes to bugs in this situation (ie bugs encountered in production not compile time).
It’s also fine at matching current styles and conventions (which is great if they are good styles and conventions).
In terms of new code, rust would have been near impossible to write with such a high degree of non-local reasoning, so I’m assuming these bugs wouldn’t be present.