C1 can be achieved (I did it on 360 hours). C2 is academic level of language proficiency -- you have to either deliberately study for the difficult exam or get an university degree in German. Most of the Germans won't be able to pass a C2 test.
When a company sets C2 as a requirement, it can be interpreted as "must have a degree from German University".
I didn't interpret it as "automation bad". The invisible value, cancelled by automation, can also be negative.
Consider a doorman or a waiter in low-trust status based society: to get a service one must exaggerate status signaling and/or bribe the gatekeeper to be deemed worthy of a service. Kiosk doesn't accept bribes and you can trust "no vacancy" from kiosk more than from the doorman.
Depends on the organization and on the SWEs. I do share your understanding, which is making me unfit for organizations, where the authority over "what" is firmly held by POs and the whole vertical on top of them.
CTOs noticed it. When product pipeline is empty, because engineers finished all the outstanding tasks, the engineers are awarded with more work: "The new software engineer is a product leader. Someone thinking about what the product is, not just how it works", or, in other words, engineers are going to be tasked with putting more content "the what" into the product pipeline.
Considering all the possible levels of abstraction software can represent, I'm imagining it as a fractal. The worst case - a mistake can be introduced by generative AI at any of the abstraction levels at any moment. Meaning, at worst case the whole thing has to be in the head of at least one person to validate the result against. The moment a project is growing beyond a single person capacity to hold it in one head possibility of plausibly looking error introduced at any abstraction level is added to the usual multi-engineer coordination costs.
Personal (as in, "for personal use, not a product") conversation partner -- I speak in German, one level is correcting the mistakes, allowing me to reformulate the statement, another level is responding to the intended idea. Rinse, repeat.
I did a project with Claude. With unit and integration tests, whole shebang. First in Python. Reached 25% of MVP and understood that I spend more time fixing subtle type mismatches (int/str, function signature vs call etc.), than adding new code. I've switched to Go (note: I've also made sure tests/frontend/backend code are built within the same context) and finished the MVP, without encountering the same problems even once.
Vacuuming working age population from Ukraine since 2014. Poland did everything right, while Ukrainian governments and businesses were smirking "What are you going to do?" during salary discussions.
From my experience greenfield /brownfield is not the best dichotomy here. I observed, how same tooling is generating meaningless slop on greenfield project and 10kLoC of change (leading to an outage) on existing project in one hands and building a fairly complex new project and fixing a long (years) standing bug with a two lines patch in the other.
And I have more examples, where I, personally, was on the both sides of the fence: defined by my level of the same problem understanding, not by the tooling.
I remember GM cars in Herzliya, Israel with cables and cameras held by duct tape circa 2019 after Andrej Karpathy already presented end to end neural network training for Autopilot in Tesla. Looked like very late to the party.
Long time ago when I was managing ISP email relay and customers asked "Where is the message I've sent?" seeing in the logs message accepted by receiving SMTP server was the end of the debug for me: I just handed the customer the part of the log and suggested talking to the receiving side IT administrator.
These reports are not for engineers, but for businesses. HR will point to the statistic and state "we are paying top of the market". In reality, trying to hire a senior engineer below EUR100k is like looking for a black cat in a dark room (you can be certain, the cat is not there anymore).
If we assume the company runs N projects with positive Net Present Value (NPV) at the start of the project and after re-evaluation some of the project NPV turned to be negative, closing the project and laying off the staff will actually make company worth more.