The second half of your question is the part the thread has not touched, so I will take that one. I hire and I teach, so I see both ends of it.
What changed is not whether a junior can produce working code. They can, quickly, and that is the problem: producing working code stopped being evidence of anything. So the expectation moves to whether they can break their own work. The question that separates people in a classroom is not can you build it, it is what input makes this fail. A junior who can answer that about code they submitted an hour ago is worth hiring. One who cannot has not read what they shipped.
The next expectation is reading. The volume of code a junior now reviews rather than writes is the real change in the job. A junior who generates four hundred lines and reads none of them is slower than one who writes forty, because someone senior pays the review cost either way.
Then the part that sits with us rather than with them. The old apprenticeship ran on seniors handing down small, bounded, slightly boring work. That is exactly the work agents now do well. If we hire a junior and give them only that, we have put them in a role with no learning gradient, and in eight months we will conclude that juniors do not work out. The honest version of giving someone a chance is handing them work one step above what the agent handles cleanly, and treating the review time as training cost rather than overhead.