If you're saying AI has _never_ found a more elegant solution than your original idea, you're not using it right or you're only using the cheapo models.
(Before someone asks: "not using it right" could mean a lot of things, but intentionally constraining its search by telling it how to do everything is one example. Or by not giving it a way to hill-climb: no tests, no iteration on a solution, etc.)
A lot of devs are micromanagers who think they’re smarter than everyone else. You’ve probably at least met a couple if you’ve had a long career. They typically leave lots of nits on code that is mostly meaningless noise or personal preference.
These types of people will get the least out of AI as their ego prevents them from letting it outshine themselves.
If you've given up on understanding your code base, AI will give you a better solution than you could come up with. Not because AI is better, but because you've become a low performer.
AI is reasonable at reviewing code, with only a 50-60% false-positive rate, and its persistence at broadening scope often finds things human reviewers would miss. It's still actually still pretty shitty at writing code, though, again, with enough ground truth and persistence, it'll often generate something that's a functional turd. It will sometimes come up with better suggestions if you prompt for it, but it needs a ton of hand-holding at the moment. And usually the suggestions are still overly complicated messes that you can trim down to 1/10th the size, while keeping the core idea.
Congrats to you if you're working in a codebase small enough to know it all. Do you know every knob in your database? Every tuning option on your webserver? Every warning and lint setting on your compiler? Wish I did! Do you read every PR that comes through the system, every day? You must keep busy.
Generally, I know a LOT about my team's code, and then in concentric circles I know less and less of the periphery. I work on <feature X> and know almost everything. That's a subsystem of <project Y> which I know well. That's part of <product Z> which I know in varying amounts.
And of course, there are things like build systems (CMake, ninja, blaze) where I know the basics, but I've never been an expert and don't care to be. Before I'd offload build features to another team; now I'd offload it to an AI. It's not something I need to be an expert in. I just want builds to work well.
That is a wonderful question. I think you might be confusing "full vibe mode" with "using AI as a tool." I don't know where some code paths lead, so I can use AI to help ("who ingests .XYZ outputs? where are the tests?"). I don't always know if policies exist so I can ask ("do we have guards around XYZ going offline? where?"). After learning the lay of the land, I decide what we need and how it fits in with the current design, and ask the agent to verify that my understanding of the flow makes sense. I'll of course review all the code that comes out.
Sometimes in review I'll be surprised that my understanding was flawed and the AI subtly misled me during the discussion, but that's super rare and that's honestly still helping me learn and understand.
Frankly it's no different than if I were pair-coding with a teammate who happened to type 25,000 wpm, and who never takes a day off.
If you had an electrician that told you "Oh, I don't learn by running wires, but if I didn't immediately see where a wire lead, I'd ask someone who knew, and then I read wiring diagrams after the other person did the work", would you hire them?
When they stop working at the site when they make the blueprints -- or worse, only look at them, you should run, or at least make sure they're only involved in management, and not any important technical decision making.
They are not going to do a good job.
Software engineers used to mock non-coding architects for good reason.
Again, it sounds like you are against vibe coding ("stop working at the site") and so am I. There's a middle ground worth acknowledging: we've built an automatic wire pulling machine and there's no reason to hand-pull anymore unless it's a really weird bend. If you just load up the machine with a spool and come back in 24 hours, though, it'll make a mess of wire all over the place.
My point is that reading is not enough for learning the rules of the system. Again, architects that don't write code were mocked for the entire history of software engineering.
They were mocked because they became mentally detached from the actual rules of the system, and because they weren't in the trenches landing PRs. Trust me, I know, I worked with one. (He was also a huge proponent of AI)
I'm not saying that at all. What I am saying is that I've never grown more mentally sharp by punting to AI. Learning a better solution is not the same as becoming more sharp.
(Before someone asks: "not using it right" could mean a lot of things, but intentionally constraining its search by telling it how to do everything is one example. Or by not giving it a way to hill-climb: no tests, no iteration on a solution, etc.)