This is surprising to me because I found that I am able to invest even more of my time in considering the good abstractions and idioms that I want to employ for a particular problem, and now most of my day is spent in discussing patterns and architecture rather than what brackets I have left to close.

Although, full disclosure: I have quibbled with Gemini quite a bit over the trailing comma, which clutters the diff, and buries the lede at code review.

But it's been very gratifying to refer to modules entirely by their role in a given design pattern (eg "driven adapter") and be understood. To define the idiom, and see it adhered to.

But am I operating still at too low a level? Would I be penalized, at these "some companies" for not producing shitty code?

Ah, but in my particularly forward-deployed line, there's always an element of showmanship compelling me to write demonstrable code.

But, also, how can I specify the behavior if I can't name the component? Is it really possible to "vibe" code à sophisticated piece of software entirely from the user's domain terminology? Without any intermediate abstractions in mind? Inconceivable, frankly. There are invisible walls, invisible shapes beneath the surface.

Then again, I'm young enough to have never allocated memory manually in my professional life.

A programmer thinks and directly engages ("works with their hands") at many abstraction layers at once. You must admit the scope of this has been dramatically reduced. You may personally love one of those abstraction layers so much that you can be happy without the others, and without even the hands-on half of the one layer you love. Many people aren't so lucky.