1 click at most to install what I need to build, 1 click to build.

I ask the dev manager how long the build takes and get an answer that is within 20% of the ground truth.

If I were given an electrical design, I would expect a schematic, a parts list, a board layout, and a theory of operations" - a prose document explaining why the rest of the stuff is the way it is.

My last job, there was the code itself, and there were UML class and sequence diagrams. But there wasn't anything like a theory of operations. That made it very difficult to learn, because it was so object oriented that you couldn't tell what anything actually did. Or, more to the point, when you needed to make a modification, you couldn't find where to make it without heroic feats of exploration.

So I think that's the great need. A human needs to sit down and write out why the code does what it does, and why it's organized the way it is, and where the parts are that are most likely to be needed, and where to make the most likely changes. I'm not sure an AI can write that - certainly AIs at the current level cannot.

Totally depends on the org. I've worked as the 3rd employee of a months old startup and the biggest pain point was we owned no infrastructure and I did everything on my own computer, which was easy but limiting because were heavy into statistical modeling and needed more powerful compute, which we got but it took a few months. I've worked on a military/intelligence project that had been in operation for over 40 years. The oldest code had no commit history because it predated any modern VCS. Whoever wrote it was long retired if not dead. Pieces were spread across thousands of repos on many different forges. With large old-school Java OSGI and now with Kubernetes, which is basically Java written in Go, it's the abstraction and dependency injection. There is no possible way to tell until runtime what code is actually going to be used. Knowing the codebase means nothing if you can't mentally track where data flows because you don't know what the implementation is actually going to be from the code alone. With extreme HPC, it was damn near literally everything being bespoke. Custom filesystems. Custom network stacks. Expectations from running workloads on regular computers and software everyone else uses were always being subverted. With cloud environments, it's not having physical access to the machines. With on-prem labs, it's needing to provision and troubleshoot the physical layer. Either way has its drawbacks. With customer-facing software, it's customers not knowing what they want and not even knowing what they don't want until they have it, which turns out to be what they didn't want. With software for modeling and understanding the real world, it's that physics turns out to be really f'ing complicated.

Cursor, Sourcegraph Cody, and honestly just Claude with a well-maintained project README already solve the "ask questions about the codebase" part reasonably well. The actual hard part of joining a new team isn't the code (today, any longer). It's getting to know the people. Understanding their strengths, figuring out where you fit in, getting past imposter syndrome, not stepping on toes. No AI for that yet.

The problem isn't finding code. it's inheriting judgment. New engineers don't struggle to locate files. They struggle to know which files to trust, which patterns are intentional vs accidental, and which senior engineer silently owns what. That's not searchable. You're building a map. What they need is a compass.