In my previous article I discussed about the necessary evil to change the coding tests to filter engineers.

As LLMs become the ultimate coders (producing boilerplate infinitely, instantly, and without fatigue) the software engineering workflow is rapidly shifting, and day-to-day work is moving heavily toward auditing and reviewing AI-generated code.
But because of this shift, a dangerous corporate fantasy is taking root: the belief that engineers should simply become project managers. But let us not confuse this evolution with a retreat.

Becoming an auditor does not mean keeping your hands clean.

Expecting engineers to simply shuffle tickets and prompt LLMs is a profound misunderstanding of the craft. An engineer’s primary output has never been code but has always been deep thought on how to efficiently solve a problem.

To solve a problem, you will need intuition.
To develop intuition you need experience.
And to gain experience you definitely need to put your hands in the mud and break your teeth on walls of complex archiecture.

You might ask yourself: “if writing boilerplate syntax is no longer the mud, so what is?”.
We need to redefine where the hard work actually happens in software engineering. The mud is no longer writing REST controllers, or scaffolding a CRUD application. The mud is profiling memory leaks in production. It is tracing unpredictable latency spikes across a distributed system. It is staring at obscure telemetry logs at 3 AM because your beautifully Claude-generated architecture introduced a silent race condition that only appears under heavy load.

That is where engineering happens and where engineers are needed.
That is the mud.

And this brings us to the ultimate reality check: accountability.
You can automate the creation, but you cannot automate the responsibility, because LLMs and Agents can write the boilerplate but they cannot suffer the consequences of a bad design. At the end of the day, you do, and this is what you get paid for.

Companies that confuse engineering with mere ticket-shuffling will inevitably build fragile, incomprehensible black boxes, and if an organization expects you to be a PM rather than a deep technical thinker, they have already lost the plot.
In this special case I have an advice: ignore them, and solve problems in places where the real problems to solve are.