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.

▲

0c3ca83 44 minutes ago | parent [-]

And, how do you learn it?

▲

StilesCrisis 32 minutes ago | parent [-]

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.

	▲	0c3ca83 a minute ago \| parent [-]
		If you had an electrician that told you "Oh, I didn't actually 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?