I think I agree with all you said. But I can’t let go of a clean codebase yet. It’s stronger than me. And I’m not sure I should. Or at least not yet, not until the agent can better understand what I actually want.

And you’re right, with a bit of direction and further prompting it’s quite easy to get your code in a reasonable shape. So that is what I do now: the agent does all the work but I still whip the output in shape.

Mostly my hope is that at some point soon the agents will start writing clean code. But then again, maybe clean code for a galaxy brained agent is not the most optimal code from a all-in token efficiency perspective.

> have prided myself on keeping a clean codebase, making 'art-not-science' decisions of when and what to abstract, scope boundaries, then implementing them cleanly, specifically to be easily grok'd by other developers

That’s more of an artist thinking than an engineering thinking, favoriting elegance (cleanness, readability) over practicality. This was not really valuable even though you prided yourself on doing so. It’s like endlessly gushing on the design aspect of the report (the medium) instead of just providing a well-written one (the message).

Code is a medium, and being an artist about it can feel good, but the information processing mechanism (the message), is what’s important. If, after using AI, you can’t reason about the mechanism (nothing about code, files,…), you can’t essentially justify anything about what happens in the software. Meaning data given to it has a non-zero chance of giving garbage answer.

> but new skills are replacing those (context/AI/agent engineering) in equal measure

This is still highlighting surface activities, not anything pertaining to engineering.