

So, now, when I see senior developers (which I am not) vibe code green field projects, I am just astounded as to how they manage the architecture + understanding + optimization + maintenance context.
My experience is, they’re not. Like the article says they are just focused on MOAR and not on the quality of the output. It may take years for the unmaintainable code to cause problems, and they may have already been laid off by the time that happens, anyway .
I don’t write much code anymore, but when I did, there was a fair amount of embedded code, where fixing a bug is more costly than just pushing out a build to a production server. I actively sought out automation back then, but the purpose of the automation was to help cover edge cases and better test the embedded code for flaws that traced through multiple layers of code.
Whenever I start a new software project, it usually starts with a short period of experimentation when I try out several things. Then, I coalesce on an architecture in my head (and eventually document it), and once I do that I can add more structure to the code.
Given the state of the AI tools today, I can see myself using them to accelerate all the little fiddly parts of this (especially if I can give it a coding standard and have it stick to it). But I wouldn’t trust it more than that. I would always keep the archictecture separate, because I don’t trust the AI tools to change it on me for no good reason.

The article only calls out the “Acting” and “Writing” categories, and the language suggests they are mainly concerned with a human doing the actual substantive work. So in this case, stunt work that is duly credited will probably still be eligible, even if they alter it as you suggest. The whole point of stunt work is to have a stand-in do it, but have it look like the main character in the final product.
Even before AI ate everything, a lot of visual effects have been created with CGI, and they still gave out Oscars for visual effects.